I want to know how to write a lcd driver with spi interface

I want to know how to write a lcd driver with spi interface

[peter meng]

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/

Re: I want to know how to write a lcd driver with spi interface

[Iwo Mergler]

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

Re: I want to know how to write a lcd driver with spi interface

[peter meng]

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 <iwo@call-direct.com.au> wrote:

> From: Iwo Mergler <iwo@call-direct.com.au>
> Subject: Re: I want to know how to write a lcd driver with spi interface
> To: mengsanshui@yahoo.com.cn
> Cc: linux-kernel@vger.kernel.org
> 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


      

Re: I want to know how to write a lcd driver with spi interface

[Iwo Mergler]

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

Re: I want to know how to write a lcd driver with spi interface

[Pavel Machek]

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