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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Sean,

Sorry for the late reply.

On Wednesday 30 October 2013 11:56:18 Sean Paul wrote:
> On Wed, Oct 30, 2013 at 11:45 AM, Laurent Pinchart wrote:
> > 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/2d19e74ab8d86aaf5d54
> > c34c6bc940508f793512
> > http://git.linuxtv.org/pinchartl/fbdev.git/commitdiff/e8c4380ca4a6a62fa9d
> > 8bc340a6dcbd123b4f674
> > 
> > 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 ?
> 
> Laurent,
> I really don't care how the functionality gets in, or what form it takes.
> This isn't NIH, I just want something that can be merged.

Great :-)

> When we talked about CDF at plumbers, I thought the plan was to split it up
> into the logical pieces and integrate it into drm. I haven't seen any
> movement on this front, is that still your intention? If so, I look forward
> to the patch.

Yes, it's still my intention, and the DT bindings + notifier code will be the 
first piece. I hope to post a first version at the end of the week(end). Sorry 
for the delay.

-- 
Regards,

Laurent Pinchart