lkml.org 
[lkml]   [2011]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Proposal for a low-level Linux display framework
Date
Hi,

Am Donnerstag, 15. September 2011, 14:07:05 schrieb Tomi Valkeinen:
> Now, I'm quite sure the above framework could work quite well with any
> OMAP like hardware, with unified memory (i.e. the video buffers are in
> SDRAM) and 3D chips and similar components are separate. But what I'm
> not sure is how desktop world's gfx cards change things. Most probably
> all the above components can be found from there also in some form, but
> are there some interdependencies between 3D/buffer management/something
> else and the video output side?
If I have read your proposal right, it could also help in better supporting
epaper-displays.

The current drivers each (re-)implement the deferredIo logic needed to drive
such systems (catching and combining updates to the framebuffer) and combine
this with the actual display driver which issues specific commands to the
display hardware. Also a board-specific driver is needed to implement the
actual transport to the display which seems be done via this i80 command
protocol over GPIOs or the LCD controllers of SoCs.

If one were to split this it could be realised like

---------------- --------------- -------------
| deferredIOFb | - | DisplayCtrl | - | Transport |
---------------- --------------- -------------

An interesting tidbit is that on the ereaders I'm working on the LCD
controller should be able to do some sort of pseudo DMA operation.
The normal way to transmit data to epaper displays is:
- issue update command with dimension of the regions to update
- read relevant pixeldata from fb and write it to the i80 in a loop
- issue stop-update command

On the S3C2416 it could go like:
- issue update command
- describe to the lcd controller the source memory region
- let the lcd controller transmit exactly one frame
- issue stop update command
So the transport would need to get the memory addresses of the region to
update from the framebuffer driver.

Also this system could possibly use some of the drawing routines from the
S3C2416 SoC.

Essentially needed would be a s3c-fb with deferredio-addon and the lcd
controller separated from it. I'm still not sure how this all could fit
together but I would guess separating framebuffer and display control would
help.


Heiko


\
 
 \ /
  Last update: 2011-09-21 15:29    [W:0.104 / U:28.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site