Re: [F]Framebuffer driver using SM501 hardware.

Geert Uytterhoeven wrote:

On Wed, 17 Aug 2005, Andrey Volkov wrote:

quoted

Geert Uytterhoeven wrote:

quoted

On Wed, 17 Aug 2005, Andrey Volkov wrote:

quoted

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf