Re: [PATCH v2] cirrus-logic-framebuffer-i2c-support.patch

[Antonino A. Daplas]

Krzysztof Halasa wrote:
> "Antonino A. Daplas" <adaplas@xxxxxxxxx> writes:
> 
>> 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.
> 
> Doesn't matter, what is important is that you know the stuff.
> 
>> 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).
> 
> I mean I'm using (simplified):

Yes, I realized that.

>>> 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.
> 
> It's quite big... While I haven't investigated that, I rather thought
> about some small lock for vga_rseq() and vga_wseq(). Not sure.

Yes, the console semaphore is quite heavy. It's also used to flush the
printk buffer.  Since the framebuffer can be called in any context,
spinlocks may be the least expensive.

> 
> Another thing... How is access to VGA registers shared between
> X11 and the framebuffer?

This is no-man's land.  Basically X grabs the VT with KD_GRAPHICS mode
set.  When in KD_GRAPHICS mode, the framebuffer console will not
send any commands to the drivers. The problem is trying to do
framebuffer operation while in X, we don't have any guards on that.
Just try fbset mymode while in X.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/