On Wed, May 09, 2018 at 03:00:38PM +0200, Boris Brezillon wrote:
Hello,
This is a new attempt at fixing the "panel is missing" issue (described in this thread [1]). I lost track of Eric's proposal, but I recently proposed to address this problem through a new ->detect() hook in the panel_funcs interface [2], which was rejected.
So here is a new version based on the feedback I had from Daniel, Thierry and Rob.
The idea is to allow of_drm_find_panel() to return -ENODEV and let the DRM driver decide what to do with that (silently ignore the missing component and register the DRM device, or fail to register the DRM device).
Patch 1 changes the semantic of of_drm_find_panel() so that it returns an ERR_PTR() instead of NULL when the panel is not found. This way we'll be able to differentiate the "panel is missing" from "panel has not been probed yet" errors.
Patch 2 and 3 are adding new tests in of_drm_find_panel() and drm_of_find_panel_or_bridge() to return -ENODEV when the status property of the DT node is not set to "okay".
Patch 4 is patching the VC4 DSI encoder driver to gracefully handle the -ENODEV case and allow the registration of the DRM device when the DSI device is disabled.
Note that patch 6 which was modifying the panel status prop from the I2C driver has been dropped because I'm not sure yet how to solve the "force probe of deferred-probe devices even if no new devices have been bound to drivers" problem. Anyway, even without this patch, the series still makes sense to handle the case where devices are described in the DT but marked "disabled" (either at compilation time or tweaked by the bootloader).
Regards,
Boris
Changes in v3:
- Dropped patch 1 since it's been acked by Thierry and should be applied soon (either through the drm-tegra or drm-misc tree)
- Dropped patch 6 because we are still discussing who should mark the device "disabled" or "fail" and how we should trigger the re-probe of deferred-probe devices in this case
Changes in v2:
- Everything :-)
[1]https://lists.freedesktop.org/archives/dri-devel/2017-November/157688.html [2]https://www.spinics.net/lists/dri-devel/msg174808.html
I don't exactly remember what we decided should be the merge path for this, but I suspect someone else was supposed to pick it up because I ended up acking these patches. However, since this hasn't been applied yet, I decided to go ahead and apply this to drm-misc-next.
Thierry