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.