Thierry Reding <> writes:

> [ Unknown signature status ]
> 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]
>> [2]
> 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.

Since you'd been engaged on previous versions, I was waiting for an ack
on patch 1.  Thanks for taking care of this now!

Attachment: signature.asc
Description: PGP signature

dri-devel mailing list

Reply via email to