[F]Framebuffer driver using SM501 hardware.

[Andrey Volkov]

Geert Uytterhoeven wrote:
> On Wed, 17 Aug 2005, Andrey Volkov wrote:
> 
>>Geert Uytterhoeven wrote:
>>
>>>On Wed, 17 Aug 2005, Andrey Volkov wrote:
>>>
>>>
>>>>Todo:
>>>>- 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
>>>
>>>
>>>Can you please elaborate? For 2.6, there should be no such problems (for 2.4,
>>>there are).
>>
>>Sorry for inexactitude, problem (as usually :)) in next (for case of
>>MPC5200 connected through PCI to SM501): PCI on PPC (and hence SM501) is
>>a little endian, PPC - big endian.
>>Currently (up to 2.6.13-rc6) frame buffer routines use
>>__raw_writeXX for write to fb memory. Result - garbage with colors in
>>RGB565/RGB888 modes (but pixels, meanwhile, are in place). If using
>>write[lw] - colors are diplayed correctly, but all image pixels are
>>shifted for (RGB565). This is not bug of frame buffer, this is lack of
>>some define in .config which tell fb/device driver how palette must be
>>generated (more precisely it is unknown when must be RGB565, but when
>>must be BGR565).
> 
> 
> Sorry, I cannot follow.

Ok, I'll try more clearly:
> 
>  1. If it's a palette issue, your setcolreg() routine doesn't fill in correctly
>     the pseudo palette,
>  2. If it's a RGB565 vs. BGR565 issue, you don't fill in correctly the offsets
>     in the color bitfields in fb_var_screeninfo,
Yes, due to duality of SM501: in memory mapped mode, its endian same as
on the host, BUT in PCI mode it work only as little endian
(theoretically it could be switched to big endian too, but for PPC it
have not meaning).

Both above problems could be solved by #ifdef/#else in SM5xx driver (as
I said before, my driver in prerelease stage :) ).
But it will be more useful, IMHO, if somewhere in Kconfig will be
defined something like CONFIG_PCI_LITTLE_ENDIAN/
CONFIG_FB_TARGET_LITTLE_ENDIAN.

>  3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
Right. As I wrote before, when SM501 blitter work as PCI bus master, it
read/write from/to host memory in little endian mode. But situation
changed when HOST (MPC), read/write from/to framebuffer - PCI subsystem
of MPC convert endian on the fly :(.

 Currently I've two workarounds:
 1) Don't use SM501 as bus master (more preferably, since SM501 anyway
    have some silicon bugs when work as bus master)
 2) Try use different functions for accelerated/unaccelerated bitblit.

>     And then there's no much we can do...
> 


-- 
Regards
Andrey Volkov