On Mon, Apr 30, 2018 at 7:43 PM, Boris Brezillon <boris.brezillon@xxxxxxxxxxx> wrote: > On Mon, 30 Apr 2018 10:22:19 -0700 > Eric Anholt <eric@xxxxxxxxxx> wrote: > >> Boris Brezillon <boris.brezillon@xxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
