outcome of DRM/KMS DT bindings session

[Thierry Reding]

On Fri, Nov 01, 2013 at 10:10:41AM +1000, Dave Airlie wrote:
> >> After looking at some of the ordering issues we've had with x86 GPUs
> >> (which are really just a tightly coupled SoC) I don't want separate
> >> drivers all having their own init, suspend/resume paths in them as I
> >> know we'll have to start making special vtable entry points etc to
> >> solve some random ordering issues that crop up.
> >
> > The DRM device has to be initialized/suspended/resumed as a whole, no
> > doubt about that. If that's not the case you indeed open up the door for
> > all kinds of ordering issues.
> >
> > Still the different components can be multiple devices, just initialize
> > the drm device once all components are probed. Remove it again once a
> > component is removed. Handle suspend in the DRM device, not in
> > the individual component drivers. The suspend in the component drivers
> > would only be called after the DRM device is completely quiesced.
> > Similarly the resume in the component drivers would not reenable the
> > components, this instead would be done in the DRM device when all
> > components are there again.
> 
> But why? why should we have separate drivers for each component of a
> tightly coupled SoC?
> 
> it makes no sense, having a driver node per every block in the chip
> isn't an advantage, it complicates
> things for no advantage at all. If we don't have hotplug hw removing
> one device shouldn't be possible
> this idea that removing a sub-driver should teardown the drm is crazy as well.

In my opinion separating things out into separate drivers makes it less
complicated. For instance it makes it very easy to manage the various
resources used by each driver (registers, interrupts, ...).

The only added complexity lies in the fact that we need some code to
synchronize the DRM device setup and teardown (and suspend and resume
for that matter). It's been discussed elsewhere that most SoCs are very
similar in their requirements, so I think we should be able to come up
with a piece of code that can be shared between drivers. Perhaps it
would even be possible to share that code between subsystems, since ALSA
and V4L2 may have similar requirements.

That's effectively not very different from what you're proposing. As far
as I can tell the only difference would be that this works in sort of a
"bottom-up" fashion, whereas your proposal would be "top-down".

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131101/7108e206/attachment.pgp>