* Framebuffer driver using SM501 hardware.
@ 2005-08-16 13:34 Surendra Yadav
2005-08-16 16:38 ` Dan Malek
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Surendra Yadav @ 2005-08-16 13:34 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I am writing framebuffer driver using SM501. This graphics driver chip can
drive CRT and TFT panel. I have written two seperate framebuffer driver, one
for CRT and one for TFT Panel.
But I am not able to test both the devices. Any one of them work at a time.
I have created two files /dev/fb0 and /dev/fb1. These two can be open
successfully and mmap is also successful from userspace. If I am trying to
write on fb0 and fb1 with different data, they displayed on either CRT or
TFT panel.
Can any one help me How to test two different framebuffer devices?
Thanks.
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Framebuffer driver using SM501 hardware. 2005-08-16 13:34 Framebuffer driver using SM501 hardware Surendra Yadav @ 2005-08-16 16:38 ` Dan Malek 2005-08-16 18:23 ` Clemens Koller 2005-08-16 19:42 ` Framebuffer " Wolfgang Denk 2 siblings, 0 replies; 15+ messages in thread From: Dan Malek @ 2005-08-16 16:38 UTC (permalink / raw) To: surendra.yadav; +Cc: linuxppc-dev On Aug 16, 2005, at 9:34 AM, Surendra Yadav wrote: > I am writing framebuffer driver using SM501. This graphics driver chip > can > drive CRT and TFT panel. I have written two seperate framebuffer > driver, one > for CRT and one for TFT Panel. I hope you didn't start from scratch. There is already an SM501 framebuffer driver that works for both CRT and TFT panel. > But I am not able to test both the devices. Any one of them work at a > time. > I have created two files /dev/fb0 and /dev/fb1. I don't think you want to do that unless you want two completely separate images on the different outputs. Normally, both the CRT and TFT display the same images from the single framebuffer, and you use the capability of the graphics engine to resize as necessary. > .... These two can be open > successfully and mmap is also successful from userspace. If I am > trying to > write on fb0 and fb1 with different data, they displayed on either > CRT or > TFT panel. If that's what you really want to do, I suspect you will have to register the driver twice as two separate frame buffers and then manage that within the single driver. I would also consider allocating different areas of the single frame buffer and then configure the planes to use the different areas within the single buffer. Good luck. -- Dan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Framebuffer driver using SM501 hardware. 2005-08-16 13:34 Framebuffer driver using SM501 hardware Surendra Yadav 2005-08-16 16:38 ` Dan Malek @ 2005-08-16 18:23 ` Clemens Koller 2005-08-16 19:48 ` Wolfgang Denk 2005-08-16 19:42 ` Framebuffer " Wolfgang Denk 2 siblings, 1 reply; 15+ messages in thread From: Clemens Koller @ 2005-08-16 18:23 UTC (permalink / raw) To: surendra.yadav; +Cc: linuxppc-dev [-- Attachment #1: Type: text/plain, Size: 1488 bytes --] Hi! I was working with the SM501 framebuffer for a while on linux-2.6. It is heavily based on old silicon motion code and not in good shape, so I didn't dare to publish it ;-) But it's working on ppc, linux-2.6 and X was running on it. There is a color-mapping issue left (RGB is swapped on powerpc) and it needs lots of code cleanup or a complete rewrite. Due to my project schedule, it will take me some month until I can focus on the voyagerfb again. But take what you want... Best 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 Surendra Yadav wrote: > Hi all, > > I am writing framebuffer driver using SM501. This graphics driver chip can > drive CRT and TFT panel. I have written two seperate framebuffer driver, one > for CRT and one for TFT Panel. > > But I am not able to test both the devices. Any one of them work at a time. > I have created two files /dev/fb0 and /dev/fb1. These two can be open > successfully and mmap is also successful from userspace. If I am trying to > write on fb0 and fb1 with different data, they displayed on either CRT or > TFT panel. > > Can any one help me How to test two different framebuffer devices? > > Thanks. > > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > [-- Attachment #2: voyager-0.2.tar.gz --] [-- Type: application/octet-stream, Size: 25402 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Framebuffer driver using SM501 hardware. 2005-08-16 18:23 ` Clemens Koller @ 2005-08-16 19:48 ` Wolfgang Denk 2005-08-17 10:11 ` [F]Framebuffer " Andrey Volkov 0 siblings, 1 reply; 15+ messages in thread From: Wolfgang Denk @ 2005-08-16 19:48 UTC (permalink / raw) To: Clemens Koller; +Cc: linuxppc-dev, surendra.yadav In message <43022F05.3050409@anagramm.de> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-16 19:48 ` Wolfgang Denk @ 2005-08-17 10:11 ` Andrey Volkov 2005-08-17 11:04 ` Clemens Koller 2005-08-17 11:18 ` Geert Uytterhoeven 0 siblings, 2 replies; 15+ messages in thread From: Andrey Volkov @ 2005-08-17 10:11 UTC (permalink / raw) To: Wolfgang Denk; +Cc: linuxppc-dev, surendra.yadav 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 <43022F05.3050409@anagramm.de> 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 ---------------- > > In message <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com> you wrote: > >>> >>> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 10:11 ` [F]Framebuffer " Andrey Volkov @ 2005-08-17 11:04 ` Clemens Koller 2005-08-17 11:50 ` Matej Kupljen 2005-08-17 11:18 ` Geert Uytterhoeven 1 sibling, 1 reply; 15+ messages in thread From: Clemens Koller @ 2005-08-17 11:04 UTC (permalink / raw) To: Andrey Volkov; +Cc: linuxppc-dev 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: > >>In message <43022F05.3050409@anagramm.de> 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 > > ---------------- > >>In message <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com> you wrote: >> >> >>>>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. > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 11:04 ` Clemens Koller @ 2005-08-17 11:50 ` Matej Kupljen 2005-08-17 12:37 ` Andrey Volkov 0 siblings, 1 reply; 15+ messages in thread From: Matej Kupljen @ 2005-08-17 11:50 UTC (permalink / raw) To: Clemens Koller; +Cc: linuxppc-dev 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 11:50 ` Matej Kupljen @ 2005-08-17 12:37 ` Andrey Volkov 0 siblings, 0 replies; 15+ messages in thread From: Andrey Volkov @ 2005-08-17 12:37 UTC (permalink / raw) To: Matej Kupljen; +Cc: linuxppc-dev Matej Kupljen wrotq: > 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 > Thanks all for (keen) interest, I'll create cvs/git during nearest days. -- Regards Andrey Volkov ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 10:11 ` [F]Framebuffer " Andrey Volkov 2005-08-17 11:04 ` Clemens Koller @ 2005-08-17 11:18 ` Geert Uytterhoeven 2005-08-17 12:15 ` Andrey Volkov 1 sibling, 1 reply; 15+ messages in thread From: Geert Uytterhoeven @ 2005-08-17 11:18 UTC (permalink / raw) To: Andrey Volkov; +Cc: Linux/PPC Development, surendra.yadav 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). 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 11:18 ` Geert Uytterhoeven @ 2005-08-17 12:15 ` Andrey Volkov 2005-08-17 12:42 ` Geert Uytterhoeven 0 siblings, 1 reply; 15+ messages in thread From: Andrey Volkov @ 2005-08-17 12:15 UTC (permalink / raw) To: Geert Uytterhoeven, linux-fbdev-devel Cc: Linux/PPC Development, surendra.yadav 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 12:15 ` Andrey Volkov @ 2005-08-17 12:42 ` Geert Uytterhoeven 2005-08-17 14:23 ` Andrey Volkov 2005-08-17 14:31 ` Clemens Koller 0 siblings, 2 replies; 15+ messages in thread From: Geert Uytterhoeven @ 2005-08-17 12:42 UTC (permalink / raw) To: Andrey Volkov Cc: Linux/PPC Development, Linux Frame Buffer Device Development, surendra.yadav 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 12:42 ` Geert Uytterhoeven @ 2005-08-17 14:23 ` Andrey Volkov 2005-08-17 14:31 ` Clemens Koller 1 sibling, 0 replies; 15+ messages in thread From: Andrey Volkov @ 2005-08-17 14:23 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Linux/PPC Development, Linux Frame Buffer Device Development, surendra.yadav 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 12:42 ` Geert Uytterhoeven 2005-08-17 14:23 ` Andrey Volkov @ 2005-08-17 14:31 ` Clemens Koller 2005-08-17 14:52 ` Andrey Volkov 1 sibling, 1 reply; 15+ messages in thread From: Clemens Koller @ 2005-08-17 14:31 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Linux/PPC Development, Linux Frame Buffer Device Development, surendra.yadav 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [F]Framebuffer driver using SM501 hardware. 2005-08-17 14:31 ` Clemens Koller @ 2005-08-17 14:52 ` Andrey Volkov 0 siblings, 0 replies; 15+ messages in thread From: Andrey Volkov @ 2005-08-17 14:52 UTC (permalink / raw) To: Clemens Koller Cc: Linux/PPC Development, Geert Uytterhoeven, Linux Frame Buffer Device Development, surendra.yadav 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Framebuffer driver using SM501 hardware. 2005-08-16 13:34 Framebuffer driver using SM501 hardware Surendra Yadav 2005-08-16 16:38 ` Dan Malek 2005-08-16 18:23 ` Clemens Koller @ 2005-08-16 19:42 ` Wolfgang Denk 2 siblings, 0 replies; 15+ messages in thread From: Wolfgang Denk @ 2005-08-16 19:42 UTC (permalink / raw) To: surendra.yadav; +Cc: linuxppc-dev In message <BPEMKMADCCCPHPEDDKOOMEHFCFAA.surendra.yadav@softdel.com> you wrote: > > I am writing framebuffer driver using SM501. This graphics driver chip can Why are you re-inventing the wheel? > drive CRT and TFT panel. I have written two seperate framebuffer driver, one > for CRT and one for TFT Panel. Why didn't you use the existing framebuffer driver? 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 If a group of N persons implements a COBOL compiler, there will be N-1 passes. Someone in the group has to be the manager. - T. Cheatham ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2005-08-17 14:52 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-08-16 13:34 Framebuffer driver using SM501 hardware Surendra Yadav 2005-08-16 16:38 ` Dan Malek 2005-08-16 18:23 ` Clemens Koller 2005-08-16 19:48 ` Wolfgang Denk 2005-08-17 10:11 ` [F]Framebuffer " Andrey Volkov 2005-08-17 11:04 ` Clemens Koller 2005-08-17 11:50 ` Matej Kupljen 2005-08-17 12:37 ` Andrey Volkov 2005-08-17 11:18 ` Geert Uytterhoeven 2005-08-17 12:15 ` Andrey Volkov 2005-08-17 12:42 ` Geert Uytterhoeven 2005-08-17 14:23 ` Andrey Volkov 2005-08-17 14:31 ` Clemens Koller 2005-08-17 14:52 ` Andrey Volkov 2005-08-16 19:42 ` Framebuffer " Wolfgang Denk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).