Hi Tomi, On Wednesday 10 April 2013 13:00:15 Tomi Valkeinen wrote: > On 2013-03-13 10:57, Tomi Valkeinen wrote: > > 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. > > > > So that's what we have now. In the distant future I see omapfb and > > omap_vout disappear totally, I'm all for that, but we need a migration plan. I plan to port my omap3-isp- live application to omapdrm, I'll report any issue with my use cases. > > the panel drivers would be made generic using Common Display Framework, > > and omapdss and omapdrm would more or less be merged together. However, > > all that is still far away, and we need some plan to go forward for now. > > > > Most pressing question is how to get OMAP display patches merged. It > > seems that there's not really an fbdev maintainer for the time being, > > and fbdev tree has been the route for omapdss, panels and omapfb in the > > past. Now that omapdrm is the new main driver for omap display, fbdev > > would be somewhat wrong in any case. > > > > Dave, how would you feel about merging changes to all the above > > components through DRM tree? Merging all the above together would be the > > easiest way, as the changes may have dependencies to each other. > > > > As I said, most of the development should be in omapdss, panels and > > omapdrm. There would be an occasional fix for omapfb and omap_vout, or > > small changes when omapdss changes require changes elsewhere. > > Ping. Do you have any thoughts of the above? > > We have a few patches for omapdrm for 3.10 that depend on omapdss > patches. I'm currently acting as a fbdev maintainer (well, more like > somebody who collects the fbdev patches that are quite surely ok), so I > can take the problematic omapdrm patches via fbdev tree with the omapdss > patches, if that's ok for you. And send the other omapdrm patches to be > merged via drm tree. > > Or, I could take all the omapdrm patches via fbdev tree, if that's > better. There aren't too many of them for 3.10. -- Regards, Laurent Pinchart
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
