Re: How to manage OMAP display drivers in the future

From
Tomi Valkeinen <hidden>
Date
2013-03-19 11:56:54
Also in
dri-devel
Reply to
Rob Clark, 2013-03-18
On 2013-03-18 22:46, Rob Clark wrote:
On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen [off-list ref] wrote:
quoted
Hi Dave,

I'm writing this mail to get some ideas how we should manage OMAP's
display drivers in the future.

As a short intro, we have the following players around:

omapdss - omapdss handles the DSS (display subsystem) hardware. omapdss
doesn't do any buffer management or expose any userspace API (except a
few sysfs files), so it doesn't do anything by itself.
(drivers/video/omap2/dss/)

panel drivers - Drivers for various panel models. The panel drivers use
omapdss API to manage the video bus. (drivers/video/omap2/displays/)

omapfb - Framebuffer driver, uses omapdss to handle the HW.
(drivers/video/omap2/omapfb/)

omap_vout - V4L2 driver for showing video, uses omapdss to handle the
HW. (drivers/media/platform/omap/)

omapdrm - DRM driver, uses omapdss to handle the HW.
(drivers/gpu/drm/omapdrm/)

omapdss and the panel drivers form the lowest level layer. omapfb and
omap_vout can be used at the same time, but omapdrm must be used alone,
without omapfb or omap_vout.

omapfb and omap_vout are not much developed anymore, even though they
are still commonly used. Most of the development happens in omapdss,
panel drivers and omapdrm.
I'd guess if changes in omapfb or omap_vout are mainly just updates
resulting from omapdss changes, maybe merging it all via drm tree
would make most sense..

Although I tend to think life would be easier w/ some copy/paste.. Ie.
just move a copy of omapdss into omapdrm directory and start
refactoring.. Offhand I think at least in the hdmi code, I think we
could jettison the big timings table, and avi-infoframe stuff and use
drm helpers.  Probably other places where we could get rid of code
that duplicates stuff that drm does (or could) provide helpers for..
I've been playing with that idea, but copying omapdss is not so
straightforward either. The panel drivers, headers, kconfig options,
board file code related to dss... It could easily create a rather
confusing mess.

I'm hoping that CDF in some form would realize soon, and then copying
omapdss would be at least somewhwat easier, as there's no need to drag
the panel drivers along.

 Tomi

Attachments

Thread (5 messages) 5 messages, 4 authors, 2013-04-11
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help