Re: [RFC 2.6.26-rc9 1/5] pxafb: add shared framebuffer interface

["Jaya Kumar" <jayakumar.lkml@gmail.com>]

On Tue, Jul 29, 2008 at 10:41 PM, Eric Miao <eric.y.miao@gmail.com> wrote:
> On Sat, Jul 26, 2008 at 11:30 AM, Jaya Kumar <jayakumar.lkml@gmail.com> wrote:
>>
>> I took a look at doing the above, ie: adjusting bpp instead of
>> custom_xfer_size. I've realized that I would still need to adjust lccr
>> in at least one other place:
>>
>>        fbi->reg_lccr1 =
>>                LCCR1_DisWdth(var->xres) +
>>
>> I'll try to improve my explanation. :-)
>>
>> The reason for this is that metronome requires a different bus width
>> (16 bit) for AMLCD transfers than it requires for its expected bits
>> per pixel ( 8 bits). To get LCDC to use 16 bits on the AMLCD bus, we
>> need to set 16bpp in LCCR3. So we then need to divide down the x
>> resolution in LCCR1. Eg: 800 pixels at 8bpp is the framebuffer. We
>> need 16-bit transfers so we set the desired pixels per line in LCCR to
>> = 800 pixels / ( 16 custom bus bits / 8 bits per pixel ) = 400 pixels
>> per line. So the code would be like:
>>
>> pix_per_line = var->xres / ( inf->custom_lccr_bpp / var->bits_per_pixel )
>>
>> I hope I was able to explain my reasoning for this above.
>>
>
> Sorry for the delay, I begin to understand the way this metronome is
> working, so each transfer is 16-bit wide and contains two 8-bit pixels?

Correct, the AMLCD xfer is 16-bit wide and is treated by Metronome as
2 8-bit pixels.

>
> Then the most simple way is to treat this display as 16-bit, and
> adjust the resolution parameters in the platform data with a nice
> comment.

I originally had it as .bpp = 16 ( in v6 and before) and used
custom_xfer_data to divide down the buffer sizes. The resolution needs
to stay at 800x600 so that the reported resolution for the display is
correct. So've I changed that to .bpp = 8 and used custom_lccr_bpp to
set LCCR3 to 16bpp in v7. Let me know if the implementation in v7 is
consistent with your suggestion.

>
> The problem of doing so is that:
> 1) framebuffer console cann't work anymore, and will show garbage
> instead of showing the nice penguine logo
>
> 2) the framebuffer application has to be aware of this, and handles
> the pixel format correctly.
>
> Provided the fact of this weird organized pixel format, I don't see many
> chances that X window or console can be run on top of this, but a
> specialized application, no?

Deferred IO converts the pixel data organization for the Metronome
controller so the latter is transparent to anything above fbdev. I
have tested with Xfbdev and it works quite well. So no specialized
applications needed. :-) Some video clips of it running here:
http://youtube.com/watch?v=Or3R3Q8oyuE and also a LinuxJournal article
showing the display with dillo and other standard applications.
http://www.linuxjournal.com/article/10110

Thanks,
jaya

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/