2011-06-16 19:11:47     Framebuffer driver for controller with indirect addressing?

Document created by Aaronwu Employee on Aug 27, 2013
Version 1Show Document
  • View in full screen mode

2011-06-16 19:11:47     Framebuffer driver for controller with indirect addressing?

Steve Strobel (UNITED STATES)

Message: 101327   

 

I am trying to support a Tianma TM023KDH18 QVGA LCD display (1) via a 16-bit parallel bus interface on a BF537.  Built into the display is a ILITEK ILI9342 controller (2).  The controller has built-in memory for the framebuffer and handles refreshing the display automatically.  Changing the contents of the framebuffer is done by sending commands to set the starting pixel position, then writing repeatedly to the same address with the data for each successive pixel. 

 

I am wondering if there is an existing driver for something that works in a similar way that I could use as a model.  The framebuffer hardware drivers I have looked at all seem to either use the PPI interface or provide a memory-mapped framebuffer with direct addressing (the Epson S1D13XXX).  I think I am going to need to create a shadow framebuffer in system memory (maybe using the virtual framebuffer) and DMA it to the graphics controller whenever the displayed information changes.  Ultimately I would like to use Qt, so building on the framebuffer API seems like a good idea. 

 

Suggestions?

 

Thanks,

 

Steve

 

(1) Datasheet at   www.tianma-usa.com/web/uploads/spec/0906123532_TM023KDH18%20V1.0.pdf

 

(2) Datasheet at   linkcomm.com/temp/ILI9342.pdf

QuoteReplyEditDelete

 

 

2011-06-17 04:26:49     Re: Framebuffer driver for controller with indirect addressing?

Aaron Wu (CHINA)

Message: 101379   

 

If you can connect the 16bit data bus to the blackfin EBIU, then your on-chip LCD RAM become part of the blackfin adress space, you can directly adress it  and take the on-chip LCD RAM as framebuffer memory. Then it's a standard frambuffer device and your QT Benefit from the framebuffer API

QuoteReplyEditDelete

 

 

2011-06-17 11:05:40     Re: Framebuffer driver for controller with indirect addressing?

Steve Strobel (UNITED STATES)

Message: 101386   

 

I can see how that would work with one of the Epson graphics drivers, as the framebuffer memory inside those chips appears like (slow) SRAM on the bus.  But this driver chip doesn't have any address lines, just the data lines and a D/CX pin (which we are treating like an address line) that controls whether the read/write operation is treated as data or a command.  To set the color of a pixel somewhere on the screen, you have to write a command to set the cursor position then write the data at that position.  The following pixels can be updated more quickly by just writing the data because the cursor position advances automatically.

 

Steve

QuoteReplyEditDelete

 

 

2011-06-17 18:11:51     Re: Framebuffer driver for controller with indirect addressing?

Mike Frysinger (UNITED STATES)

Message: 101398   

 

most of the Blackfin framebuffers assume 1 frame and then always leave DMA running.  i havent looked at any drivers for a device like this, so i'm not aware of what is out there.

 

i imagine you could treat it as a double buffered device ... you still only have one buffer in memory like the other devices, but when people sync/flip the buffers, you take care of pushing the local version into the remote at that time.

 

if you have the ability to only update certain parts rather than the whole screen, you could probably even optimize things a bit by implementing the blit functions in the driver, and then when userspace used those functions, you would only push out the updated region rather than the whole thing.

 

you could try posting your question to the linux-fbdev@vger.kernel.org mailing list and see if anyone there could point you at a relevant driver quickly ...

QuoteReplyEditDelete

 

 

2011-06-17 18:45:04     Re: Framebuffer driver for controller with indirect addressing?

Steve Strobel (UNITED STATES)

Message: 101399   

 

Thanks Mike for the suggestions.  I hadn't considered using the double-buffer flip logic to trigger outputting the changes.  I will try posting on the fbdev list.

 

Steve

Attachments

    Outcomes