[RFC PATCH 0/3] drm/panel: Support panel detection

[Daniel Vetter]

On Mon, Apr 30, 2018 at 7:43 PM, Boris Brezillon
<boris.brezillon at bootlin.com> wrote:
> On Mon, 30 Apr 2018 10:22:19 -0700
> Eric Anholt <eric at anholt.net> wrote:
>
>> Boris Brezillon <boris.brezillon at bootlin.com> writes:
>>
>> > Some panels are connected through extension boards an provide an easy
>> > way for the main board to detect when they are present (like checking
>> > for a working I2C communication with a device and making sure a
>> > specific reg in this device has a consistent value).
>> >
>> > When this is the case, we might want to support dynamic panel detection
>> > and only expose the display (and its display modes) when the panel is
>> > detected, similar to the monitor detection we use for regular
>> > connectors (HDMI, DVI, ...).
>> >
>> > This solves a problem we have on the Rpi when the panel is not
>> > connected to the board but described in the DT. This prevents the whole
>> > display pipeline from being exposed because one of the element (the
>> > panel) is missing.
>> >
>> > This was posted as an RFC because I'm not sure dynamically detecting
>> > panels or supporting panel hotplug is actually something we want to do.
>>
>> I want to clarify here: we're not trying to do panel hotplug.  We're
>> trying to boot-time-only detection of whether or not the standard panel
>> is plugged in.
>>
>> Since this is something like the 6th variation of trying to get this
>> driver to work whether or not the panel is plugged in at boot, I'm
>> leaning toward just asking the closed source firmware to hack the DT to
>> add/remove the panel's node depending on whether it can probe it on I2C.
>> Relying on more closed source software in order to work around something
>> so trivial is really frustrating, though.

Ugh, sorry, I didn't remember the entire story here when I replied.

> Well, we could still have this hack in the rpi-touchscreen-panel driver
> and expose the panel without any display modes when the device is
> actually not responding on the I2C bus. This way we could have the DRM
> device registered and the panel display would just be unusable.

Yeah that sounds like a reasonable hack to me, but I have no idea
whether this was one of the earlier pile of ideas or not. Another
thing that I just thought of (so might be bogus) would be a dummy
bridge which only exists to transport an errno, which would then be
returned from drm_of_find_panel_or_bridge instead of 0. Probably only
reasonable case would be to return -ENODEV. No good idea though how to
somewhat cleanly wire this through the entire stack, simplest might be
to add an in errno to drm_panel. Since we use an embedded list for
of_drm_find_panel we can't do the usual trick of storing the errno in
the pointer.

Hm, maybe we could encode panel->funcs == NULL as "sorry this panel
isn't really there" and use that. Assuming we only ever want to encode
ENODEV and not a pile of other errno values.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch