Re: [F]Framebuffer driver using SM501 hardware.

Re: [F]Framebuffer driver using SM501 hardware.

[Andrey Volkov]

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).

Problem redouble when hw accel, as bus muster, entered in the game:
for accelerated imageblit pixels must be in RGB565 mode :((

-- 
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

Re: [F]Framebuffer driver using SM501 hardware.

[Geert Uytterhoeven]

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.

 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,
 3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
    And then there's no much we can do...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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

Re: [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


-------------------------------------------------------
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

Re: [F]Framebuffer driver using SM501 hardware.

[Clemens Koller]

Hi Geert, Andrey and friends...

I am working on ppc, MPC8540, SM501 on PCI,
drivers=voyagerfb-0.2.tar.gz from last post.
on linux-2.6

Geert wrote:
> Sorry, I cannot follow.
> 
>  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,
>  3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG, right?
>     And then there's no much we can do...

It looks for me like 3. = bytes are flipped = an endian issue:
In 32 (RGBAlpha) mode (the one we want to use) the colors appear
wrong. I get my /dev/fb0 appear as 

BB GG RR aa BB GG RR aa BB GG RR aa ...

In the great SM501 Databook Version 1.02, Page 2-39, it says:
Configuration 2, Endian Control at MMIO_base+0x00005c:
write 0x00000000 for little endian or
write 0xffffffff for big endian
into this register before touching any other register of the sm501.
I've tried that, but it didn't change anything on my system. :-(
(Well, we can flip the DAC outputs in our hw design ;-)

Best greets,

Clemens
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany

http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19

------------------------------------------------
details:

$ cp red /dev/fb0 
gives me a some red color...
$ bvi red
00000000  00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
00000010  00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
00000020  00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
...
$ cp green /dev/fb0 
gives me a some green color...
00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00
...
$ cp blue /dev/fb0
well... blue
FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00


-------------------------------------------------------
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

Re: [F]Framebuffer driver using SM501 hardware.

[Andrey Volkov]

Clemens Koller wrote:
> Hi Geert, Andrey and friends...
> 
> I am working on ppc, MPC8540, SM501 on PCI,
> drivers=voyagerfb-0.2.tar.gz from last post.
> on linux-2.6
> 
> Geert wrote:
> 
>> Sorry, I cannot follow.
>>
>>  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,
>>  3. If it's an endian issue, it's RRRRRGGGGGGBBBBB vs.GGBBBBBRRRRGGGG,
>> right?
>>     And then there's no much we can do...
> 
> 
> It looks for me like 3. = bytes are flipped = an endian issue:
> In 32 (RGBAlpha) mode (the one we want to use) the colors appear
> wrong. I get my /dev/fb0 appear as
> BB GG RR aa BB GG RR aa BB GG RR aa ...
> 
> In the 
> great 
You're forget qutation here :)

SM501 Databook Version 1.02, Page 2-39, it says:
> Configuration 2, Endian Control at MMIO_base+0x00005c:
> write 0x00000000 for little endian or
> write 0xffffffff for big endian
> into this register before touching any other register of the sm501.
> I've tried that, but it didn't change anything on my system. :-(
> (Well, we can flip the DAC outputs in our hw design ;-)
As I understand, but I'm not sure, LE/BE controlled only by some GPIO
pin (GPIO4 was on rev A/B). I try write to this reg too, with same result.

> 
> Best greets,
> 
> Clemens
> _______________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
> 
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
> 
> ------------------------------------------------
> details:
> 
> $ cp red /dev/fb0 gives me a some red color...
> $ bvi red
> 00000000  00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> 00000010  00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> 00000020  00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 ................
> ...
> $ cp green /dev/fb0 gives me a some green color...
> 00 FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00
> ...
> $ cp blue /dev/fb0
> well... blue
> FF 00 00 00 FF 00 00 00 FF 00 00 00 FF 00 00 00
> 

-- 
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