From: Wolfgang Denk <hidden> Date: 2005-08-16 19:48:37
In message [off-list ref] you wrote:
I was working with the SM501 framebuffer for a while on
linux-2.6.
...and we did in the context of our 2.4 kernel.
There is a color-mapping issue left (RGB is swapped on powerpc)
and it needs lots of code cleanup or a complete rewrite.
I think we fixed some of these problems, and I have a couple of other
patches sitting in my queue. Anybody interested can (1) have a look
at our tree and (2) mail me.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"A little knowledge is a dangerous thing." - Doug Gwyn
I (now :)) working on it too.
Unfortunately, due to terrible SM docos/examples,
I rewrite/write some parts from scratch :(
(mainly based on Applied Data Systems drivers for PXA).
Currently my driver(s) in prerelease stage. It provide:
- PCI/bus infra.
- CRT or LCD fb (dual head in progress,
I hope, on next week it will be done).
- hwd cursor
- hwd accel (bitblit/fill rect/color expand)
- I2C/DDC (software, due to silicon bug in SM501)
- CI (Command List Interpreter) partially supported
(problems in PCI mode: when it work as master with
MPC5200, some data are lost, needed investigation).
Todo:
- 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
- Alpha (have not ideas how to use it in fb/X)
- Video (same as above)
- Platform driver (it will not too hard to write it,
but all boards, which I have, are PCI based)
- USB host (in progress)
- USB slave
- Full CI support.
- UART/SPI/AC97....
To whom it is interesting, I could send my current code
(not too little). And, if smb will wish fix/expand...,
I could (temporally) create cvs on sf.net.
Wolfgang Denk wrote:
In message [off-list ref] you wrote:
quoted
I was working with the SM501 framebuffer for a while on
linux-2.6.
...and we did in the context of our 2.4 kernel.
quoted
There is a color-mapping issue left (RGB is swapped on powerpc)
and it needs lots of code cleanup or a complete rewrite.
I think we fixed some of these problems, and I have a couple of other
patches sitting in my queue. Anybody interested can (1) have a look
at our tree and (2) mail me.
Best regards,
Wolfgang Denk
----------------
In message [off-list ref] you wrote:
quoted
quoted
I am writing framebuffer driver using SM501. This graphics driver chip can
Why are you re-inventing the wheel?
Because I (for ex.) don't use nor QT, nor X :) and I use 2.6 kernel.
Also I need USB/AC97... support.
--
Regards
Andrey Volkov
From: Clemens Koller <hidden> Date: 2005-08-17 11:04:29
Hi, Andrey!
It would be great to have our code collected somewhere in a public
cvs/git archive.
There are also some patches to add (accelerated) SM501 support to
the latest X somewhere in atmosphere:
https://bugs.freedesktop.org/attachment.cgi?id=1775
I will be able to help you with some hacking/testing with the
SM501 on PCI on ppc/MPC8540 in the future.
Greets,
Clemens Koller
_______________________________
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
Andrey Volkov wrote:
I (now :)) working on it too.
Unfortunately, due to terrible SM docos/examples,
I rewrite/write some parts from scratch :(
(mainly based on Applied Data Systems drivers for PXA).
Currently my driver(s) in prerelease stage. It provide:
- PCI/bus infra.
- CRT or LCD fb (dual head in progress,
I hope, on next week it will be done).
- hwd cursor
- hwd accel (bitblit/fill rect/color expand)
- I2C/DDC (software, due to silicon bug in SM501)
- CI (Command List Interpreter) partially supported
(problems in PCI mode: when it work as master with
MPC5200, some data are lost, needed investigation).
Todo:
- 16 bpp colormap (needed reverse endian support in fbcon/fbmem)
- Alpha (have not ideas how to use it in fb/X)
- Video (same as above)
- Platform driver (it will not too hard to write it,
but all boards, which I have, are PCI based)
- USB host (in progress)
- USB slave
- Full CI support.
- UART/SPI/AC97....
To whom it is interesting, I could send my current code
(not too little). And, if smb will wish fix/expand...,
I could (temporally) create cvs on sf.net.
Wolfgang Denk wrote:
quoted
In message [off-list ref] you wrote:
quoted
I was working with the SM501 framebuffer for a while on
linux-2.6.
...and we did in the context of our 2.4 kernel.
quoted
There is a color-mapping issue left (RGB is swapped on powerpc)
and it needs lots of code cleanup or a complete rewrite.
I think we fixed some of these problems, and I have a couple of other
patches sitting in my queue. Anybody interested can (1) have a look
at our tree and (2) mail me.
Best regards,
Wolfgang Denk
----------------
quoted
In message [off-list ref] you wrote:
quoted
quoted
I am writing framebuffer driver using SM501. This graphics driver chip can
Why are you re-inventing the wheel?
Because I (for ex.) don't use nor QT, nor X :) and I use 2.6 kernel.
Also I need USB/AC97... support.
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).
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
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
From: Matej Kupljen <hidden> Date: 2005-08-17 12:20:45
Hi Clemens
It would be great to have our code collected somewhere in a public
cvs/git archive.
There are also some patches to add (accelerated) SM501 support to
the latest X somewhere in atmosphere:
https://bugs.freedesktop.org/attachment.cgi?id=1775
I also did some testing with X and SM501 using SM501 and MPC5200
on local bus, but I am not working on that board at the moment.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=312
If I find some time, I'll probably be able to help you
with some testing.
BR,
Matej
It would be great to have our code collected somewhere in a public
cvs/git archive.
There are also some patches to add (accelerated) SM501 support to
the latest X somewhere in atmosphere:
https://bugs.freedesktop.org/attachment.cgi?id=1775
I also did some testing with X and SM501 using SM501 and MPC5200
on local bus, but I am not working on that board at the moment.
See:
https://bugs.freedesktop.org/show_bug.cgi?id=312
If I find some time, I'll probably be able to help you
with some testing.
BR,
Matej
Thanks all for (keen) interest, I'll create cvs/git during nearest days.
--
Regards
Andrey Volkov
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
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.
From: Clemens Koller <hidden> Date: 2005-08-17 14:31:57
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
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:
quoted
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