How to manage OMAP display drivers in the future

[Laurent Pinchart]

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
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: 

Re: How to manage OMAP display drivers in the future

[Laurent Pinchart]

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


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

How to manage OMAP display drivers in the future

[Tomi Valkeinen]

Hi Dave,

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, 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.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 

Re: How to manage OMAP display drivers in the future

[Tomi Valkeinen]

Hi Dave,

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, 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.

 Tomi




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

How to manage OMAP display drivers in the future

[Tomi Valkeinen]

On 2013-03-18 22:46, Rob Clark wrote:
> On Wed, Mar 13, 2013 at 4:57 AM, 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.
> 
> 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


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 

Re: How to manage OMAP display drivers in the future

[Tomi Valkeinen]

On 2013-03-18 22:46, Rob Clark wrote:
 On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen to...@iki.fi 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.
 
 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




signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

How to manage OMAP display drivers in the future

[Rob Clark]

On Wed, Mar 13, 2013 at 4:57 AM, 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.

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..

BR,
-R

> So that's what we have now. In the distant future I see omapfb and
> omap_vout disappear totally, 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.
>
>  Tomi

Re: How to manage OMAP display drivers in the future

[Rob Clark]

On Wed, Mar 13, 2013 at 4:57 AM, Tomi Valkeinen to...@iki.fi 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.

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..

BR,
-R

 So that's what we have now. In the distant future I see omapfb and
 omap_vout disappear totally, 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.

  Tomi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

How to manage OMAP display drivers in the future

[Tomi Valkeinen]

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, 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.

 Tomi

How to manage OMAP display drivers in the future

[Tomi Valkeinen]

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, 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.

 Tomi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel