1. I want to know how to write a lcd driver with spi interface on
linux(2.6.24) ? I'm using a tft-lcd(FT-G128160UTSW-123W-E vendor --TRULY)
with s6d0151(IC) that connected to s3c2412 with spi .
interface : SDI --> GPG6 WR-->GPG7 CSB -->GPG3 RS-->GPB1 RESET -->GPB2 )
2.How the framebuffer related with spi interface ? I mean how the
framebuffer know it transfer the data with spi interfcae not the
RGB/80-System interface.
3. Where i can get the example driver on linux ?
Thanks advanced .
Best Regards .
peter meng
___________________________________________________________
?????ؿ????㷢???????ؿ?ȫ?????ߣ?
http://card.mail.cn.yahoo.com/
peter meng wrote:
> 1. I want to know how to write a lcd driver with spi interface on
> linux(2.6.24) ? I'm using a tft-lcd(FT-G128160UTSW-123W-E vendor --TRULY)
> with s6d0151(IC) that connected to s3c2412 with spi .
> interface : SDI --> GPG6 WR-->GPG7 CSB -->GPG3 RS-->GPB1 RESET -->GPB2 )
>
> 2.How the framebuffer related with spi interface ? I mean how the
> framebuffer know it transfer the data with spi interfcae not the
> RGB/80-System interface.
The main difference is that a framebuffer is memory mapped, whereas an SPI
connected display is more suitable for a function call abstraction. The two don't
relate very well.
Your SPI display has an internal frame buffer, which you can access via SPI,
but cannot memory map. A function call interface would easily map to the
SPI transfer, but requires applications written for such an API.
If you absolutely have to use a framebuffer abstraction, you can create a fake
framebuffer in RAM. Now, you have to solve the problem of keeping the display's
framebuffer in sync with the RAM one.
The simplest approach is to have a kernel timer fire a few times per second
and transfer the whole RAM fb via SPI every time. The faster you refresh, the
better the synchronisation, but you'll hit CPU or SPI bus limits eventually. It
also causes image artefacts with fast updating content, e.g. video.
If your CPU+RAM is much faster than SPI, it might be beneficial to detect
which part of the display was changed and only update that stripe/rectangle.
In practice, it is best to use a combination of methods. Have a timer based
update for most GUI-type applications and then modify the more demanding
applications to control the refresh directly, for instance through a IOCTL.
If your applications use a graphics library on top of the framebuffer (e.g. QTE),
you may be able to add synchronisation calls into that library, for better
efficiency.
One more avenue to look at is to use the MMU for synchronisation. That is,
you map the RAM fb as read only, such that if an application writes to it, it triggers
an exception. In the exception handler you remap the memory as read/write,
execute the write, update the display and remap r/o. This would be very inefficient,
so you may want to leave the memory mapped r/w and start a timer to collect a
number of changes before mapping r/o again.
The best method very much depends on your use case, applications, relative
speeds of CPU and SPI, size of display, etc.
>
> 3. Where i can get the example driver on linux ?
A well documented framebuffer skeleton: drivers/video/skeletonfb.c
A RAM-based framebuffer: drivers/video/vfb.c
A simple SPI driver (EEPROM): drivers/spi/at25.c
Kind regards,
Iwo
Hi,Iwo
Thank you very mach .
I'm a newbie on video driver .
Could you recommended the lcd driver that already use spi interface on Linux to me ?
I want to emulate it .
Best Regards
Peter
--- On Tue, 12/2/08, Iwo Mergler <[email protected]> wrote:
> From: Iwo Mergler <[email protected]>
> Subject: Re: I want to know how to write a lcd driver with spi interface
> To: [email protected]
> Cc: [email protected]
> Date: Tuesday, December 2, 2008, 7:09 AM
> peter meng wrote:
> > 1. I want to know how to write a lcd driver with spi
> interface on
> > linux(2.6.24) ? I'm using a
> tft-lcd(FT-G128160UTSW-123W-E vendor --TRULY)
> > with s6d0151(IC) that connected to s3c2412 with spi
> .
> > interface : SDI --> GPG6 WR-->GPG7 CSB
> -->GPG3 RS-->GPB1 RESET -->GPB2 )
> >
> > 2.How the framebuffer related with spi interface ? I
> mean how the
> > framebuffer know it transfer the data with spi
> interfcae not the
> > RGB/80-System interface.
>
> The main difference is that a framebuffer is memory mapped,
> whereas an SPI
> connected display is more suitable for a function call
> abstraction. The two don't
> relate very well.
>
> Your SPI display has an internal frame buffer, which you
> can access via SPI,
> but cannot memory map. A function call interface would
> easily map to the
> SPI transfer, but requires applications written for such an
> API.
>
> If you absolutely have to use a framebuffer abstraction,
> you can create a fake
> framebuffer in RAM. Now, you have to solve the problem of
> keeping the display's
> framebuffer in sync with the RAM one.
>
> The simplest approach is to have a kernel timer fire a few
> times per second
> and transfer the whole RAM fb via SPI every time. The
> faster you refresh, the
> better the synchronisation, but you'll hit CPU or SPI
> bus limits eventually. It
> also causes image artefacts with fast updating content,
> e.g. video.
>
> If your CPU+RAM is much faster than SPI, it might be
> beneficial to detect
> which part of the display was changed and only update that
> stripe/rectangle.
>
> In practice, it is best to use a combination of methods.
> Have a timer based
> update for most GUI-type applications and then modify the
> more demanding
> applications to control the refresh directly, for instance
> through a IOCTL.
>
> If your applications use a graphics library on top of the
> framebuffer (e.g. QTE),
> you may be able to add synchronisation calls into that
> library, for better
> efficiency.
>
> One more avenue to look at is to use the MMU for
> synchronisation. That is,
> you map the RAM fb as read only, such that if an
> application writes to it, it triggers
> an exception. In the exception handler you remap the memory
> as read/write,
> execute the write, update the display and remap r/o. This
> would be very inefficient,
> so you may want to leave the memory mapped r/w and start a
> timer to collect a
> number of changes before mapping r/o again.
>
> The best method very much depends on your use case,
> applications, relative
> speeds of CPU and SPI, size of display, etc.
>
> >
> > 3. Where i can get the example driver on linux ?
> A well documented framebuffer skeleton:
> drivers/video/skeletonfb.c
> A RAM-based framebuffer: drivers/video/vfb.c
> A simple SPI driver (EEPROM): drivers/spi/at25.c
>
> Kind regards,
>
> Iwo
peter meng wrote:
> Hi,Iwo
>
> Thank you very mach .
> I'm a newbie on video driver .
> Could you recommended the lcd driver that already use spi interface on Linux to me ?
> I want to emulate it .
>
>
> Best Regards
> Peter
>
>
Sorry, as far as I know, there isn't one.
Yours could be the first. :-)
Kind regards,
Iwo
On Tue 2008-12-02 11:40:14, peter meng wrote:
> Hi,Iwo
>
> Thank you very mach .
> I'm a newbie on video driver .
> Could you recommended the lcd driver that already use spi interface on Linux to me ?
> I want to emulate it .
>
drivers/auxdisplay should be interesting reading.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html