Krzysztof Halasa wrote:
> "Antonino A. Daplas" <[email protected]> writes:
>
>> Eventually, I'm the one who's going to maintain the code, most
>> of the drivers in the video directory are practically abandoned.
>
> BTW, it's fortunate that you are maintaing it.
David Eger is the author, the last I heard from him was 2 years ago.
But I haven't received that many problem reports on cirrusfb.
However, changes that affect all drivers are my responsibility.
> The I2C code in cirrusfb
> uses vga_wseq() and vga_rseq(). Is it safe WRT races between I2C
> adapter code and fb code? I don't see any locking here, and both
> functions are non-atomic (write merging and posting will not break it,
> but it looks like I need a lock for concurent access).
The only register touched by the i2c code is EEPROM control (CL_SEQR8).
This is never touched by the rest of the cirrusfb code. So I don't
think concurrent access is a problem (unless the hardware has restrictions
such as no other register accesses are allowed while this register is being
accessed).
The framebuffer layer is serialized by
acquire_console_sem()/release_console_sem(). If you think concurrent access
is a problem, you can always use that.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
