On Wednesday 30 of October 2013 13:02:29 Sascha Hauer wrote: > On Tue, Oct 29, 2013 at 01:52:57PM +1000, Dave Airlie wrote: > > So we had a sessions at kernel summit to discuss the driver model and > > DT interactions for a display pipeline, > > > > we had good attendance from a few sides and I hope to summarise the > > recommendations below, > > > > a) Device Tree bindings > > > > We should create a top-level virtual device binding that a top level > > driver can bind to, like alsa asoc does. > > > > We should separate the CDF device tree model from CDF as a starting > > point and refine it outside of CDF, and produce a set of bindings that > > cover the current drivers we have, exynos, imx, tegra, msm, armada > > etc. This set of bindings should not be tied on CDF being merged or > > anything else. > > > > Display pipelines should be modelered in the device tree, but the > > level of detail required for links between objects may be left up to > > the SoC developer, esp wrt tightly coupled SoCs. > > > > Externally linked devices like bridges and panels should be explicitly > > linked. > > > > b) Driver Model > > > > The big thing here is that the device tree description we use should > > not dictate the driver model we use. This is the biggest thing I > > learned, so what does it mean? > > > > We aren't required to write a device driver per device tree object. > > > > We shouldn't be writing device drivers per device tree object. > > > > For tightly-coupled SoCs where the blocks come from one vendor and are > > reused a lot, a top level driver should use the DT as configuration > > information source for the list of blocks it needs to initialise on > > the card, not as a list of separate drivers. There may be some > > external drivers required and the code should deal with this, like how > > alsa asoc does. > > > > To share code between layers we should refactor it into a helper > > library not a separate driver, the kms/v4l/fbdev can use the library. > > > > This should allow us to move forward a bit clearer esp with new > > drivers and following these recommendations, and I think porting > > current drivers to a sane model, especially exynos and imx. > > > > Now I saw we here but I'm only going to be donating my use of a big > > stick and review abilities to making this happen, but I'm quite > > willing to enforce some of these rules going forward as I think it > > will make life easier. > > > > 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. > > This way all components could be proper (driver model)devices with > proper drivers without DRM even noticing that multiple components are > involved. > > Side note: We have no choice anyway. All SoCs can (sometimes must) > be extended with external I2C devices. On every SoC the I2C bus master > is a separate device, so we have a multicomponent device (in the sense > of driver model) already in many cases. +1 Best regards, Tomasz _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
