Re: [RFC v2 0/5] Common Display Framework

[Sascha Hauer <s.hauer@pengutronix.de>]

On Thu, Dec 27, 2012 at 09:54:55AM -0600, Rob Clark wrote:
> On Mon, Dec 24, 2012 at 7:37 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > Hi Rob,
> >
> > On Tuesday 18 December 2012 00:21:32 Rob Clark wrote:
> >> On Mon, Dec 17, 2012 at 11:04 PM, Dave Airlie <airlied@gmail.com> wrote:
> >> >> Many developers showed interest in the first RFC, and I've had the
> >> >> opportunity to discuss it with most of them. I would like to thank (in
> >> >> no particular order) Tomi Valkeinen for all the time he spend helping me
> >> >> to draft v2, Marcus Lorentzon for his useful input during Linaro Connect
> >> >> Q4 2012, and Linaro for inviting me to Connect and providing a venue to
> >> >> discuss this topic.
> >> >
> >> > So this might be a bit off topic but this whole CDF triggered me
> >> > looking at stuff I generally avoid:
> >> >
> >> > The biggest problem I'm having currently with the whole ARM graphics
> >> > and output world is the proliferation of platform drivers for every
> >> > little thing. The whole ordering of operations with respect to things
> >> > like suspend/resume or dynamic power management is going to be a real
> >> > nightmare if there are dependencies between the drivers. How do you
> >> > enforce ordering of s/r operations between all the various components?
> >>
> >> I tend to think that sub-devices are useful just to have a way to probe hw
> >> which may or may not be there, since on ARM we often don't have any
> >> alternative.. but beyond that, suspend/resume, and other life-cycle aspects,
> >> they should really be treated as all one device. Especially to avoid
> >> undefined suspend/resume ordering.
> >
> > I tend to agree, except that I try to reuse the existing PM infrastructure
> > when possible to avoid reinventing the wheel. So far handling suspend/resume
> > ordering related to data busses in early suspend/late resume operations and
> > allowing the Linux PM core to handle control busses using the Linux device
> > tree worked pretty well.
> >
> >> CDF or some sort of mechanism to share panel drivers between drivers is
> >> useful.  Keeping it within drm, is probably a good idea, if nothing else to
> >> simplify re-use of helper fxns (like avi-infoframe stuff, for example) and
> >> avoid dealing with merging changes across multiple trees. Treating them more
> >> like shared libraries and less like sub-devices which can be dynamically
> >> loaded/unloaded (ie. they should be not built as separate modules or
> >> suspend/resumed or probed/removed independently of the master driver) is a
> >> really good idea to avoid uncovering nasty synchronization issues later
> >> (remove vs modeset or pageflip) or surprising userspace in bad ways.
> >
> > We've tried that in V4L2 years ago and realized that the approach led to a
> > dead-end, especially when OF/DT got involved. With DT-based device probing,
> > I2C camera sensors started getting probed asynchronously to the main camera
> > device, as they are children of the I2C bus master. We will have similar
> > issues with I2C HDMI transmitters or panels, so we should be prepared for it.
> 
> What I've done to avoid that so far is that the master device
> registers the drivers for it's output sub-devices before registering
> it's own device.  At least this way I can control that they are probed
> first.  Not the prettiest thing, but avoids even uglier problems.

This implies that the master driver knows all potential subdevices,
something which is not true for SoCs which have external i2c encoders
attached to unrelated i2c controllers.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |