On Wed, Oct 30, 2013 at 11:45 AM, Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> 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/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 ?
>
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.
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.
Sean
>> I hope that made sense ;)
>
> --
> Regards,
>
> Laurent Pinchart
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
