[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

[Laurent Pinchart]

On Wednesday 30 October 2013 11:32:24 Sean Paul wrote:
> On Tue, Oct 29, 2013 at 4:50 PM, Tomasz Figa wrote:
> > On Tuesday 29 of October 2013 16:36:47 Sean Paul wrote:

[snip]

> >> An example: exynos_drm_drv would be a platform_driver which implements
> >> drm_driver. On drm_load, it would enumerate the various dt nodes for
> >> its IP blocks and initialize them with direct calls (like
> >> exynos_drm_fimd_initialize). If the board uses a bridge (say for
> >> eDP->LVDS), that bridge driver would be a real driver with its own
> >> probe.
> >> 
> >> I think the ideal situation would be for the drm layer to manage the
> >> standalone drivers in a way that is transparent to the main driver,
> >> such that it doesn't need to know which type of hardware can hang off
> >> it. It will need to know if one exists since it might need to forego
> >> creating a connector, but it need not know anything else about it.
> >> 
> >> To accomplish this, I think we need:
> >> (1) Some way for drm to enumerate the standalone drivers, so it can
> >> know when all of them have been probed
> >> 
> >> (2) A drm registration function that's called by the standalone
> >> drivers once they're probed, and a hook with drm_device pointer called
> >> during drm_load for them to register their drm_* implementations
> >> 
> >> (3) Something that will allow for deferred probe if the main driver
> >> kicks off before the standalones are in, it would need to be called
> >> before drm_platform/pci_init
> >> 
> >> I think we'll need to expand on the media bindings to achieve (1).
> > 
> > Could you elaborate on why you think so?
> > 
> > I believe the video interface bindings contain everything needed for this
> > case, except, of course, some device/bus specific parts, but those are to
> > be defined by separate device/bus specific bindings.
> 
> AFAICT, there is no way for drm to enumerate all of the pieces that
> need probing before it loads (ie: how do you enumerate all device
> nodes with pipe {} subnode[s]). I've given this more thought, and I
> think the following could work without forcing unified/split drivers
> (ie: it can be left to the driver author to choose).
> 
> If there was some way for drm to know all of the pieces that need to
> be probed/initialized before calling drm_load, it could provide an API
> for various drivers to "claim" nodes. This API would accept the
> device_node being claimed as well as an initialize hook that will be
> called back to give the standalone driver a pointer to the drm_device.
> 
> The main drm driver, which is responsible for calling
> drm_platform/pci_init, would claim the nodes it plans on implementing
> in the probe. It would then check drm to see if all requred nodes had
> been claimed. If they have not been claimed, that probe would defer
> and try again later.
> 
> Once all required nodes have been "claimed", the main driver's probe
> would call drm_platform/pci_init to kick off load(). After load() has
> finished, the drm layer would then call the various standalone driver
> hooks that were previously registered when it claimed its node. These
> hooks would allow the driver to register its
> crtc/encoder/bridge/connector.
> 
> Multi-driver solutions could work within this framework, as could
> integrated ones. This would also allow things like bridge drivers to
> be completely transparent.

Have you all configured your spam filters to reject anything that is or has 
been related to CDF ?

Split in two patches, the first one adding the infrastructure, the second one 
adding OF support.

http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/2d19e74ab8d86aaf5d54c34c6bc940508f793512
http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/e8c4380ca4a6a62fa9d8bc340a6dcbd123b4f674

The code can be extracted as a stand-alone solution, either specific to DRM, 
or at the struct device level. As the problem is not DRM-specific, the later 
would probably make more sense (if I'm not mistaken Grant Likely - CCed- 
mentioned during the kernel summit was in favor of adding the code in the 
device core).

We've solved the exact same problem in V4L, do we *really* need to adopt the 
NIH approach and reinvent the wheel ?

> I hope that made sense ;)

-- 
Regards,

Laurent Pinchart