From: Eric Anholt <eric@anholt.net>
To: Thierry Reding <thierry.reding@gmail.com>,
dri-devel@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>,
Boris Brezillon <boris.brezillon@bootlin.com>
Subject: Re: [RFC PATCH 0/3] drm/panel: Support panel detection
Date: Mon, 30 Apr 2018 10:22:19 -0700 [thread overview]
Message-ID: <87d0ygzk1g.fsf@anholt.net> (raw)
In-Reply-To: <20180430144323.9233-1-boris.brezillon@bootlin.com>
[-- Attachment #1.1: Type: text/plain, Size: 1496 bytes --]
Boris Brezillon <boris.brezillon@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.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-04-30 17:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-30 14:43 [RFC PATCH 0/3] drm/panel: Support panel detection Boris Brezillon
2018-04-30 14:43 ` [RFC PATCH 1/3] " Boris Brezillon
2018-04-30 16:08 ` Daniel Vetter
2018-04-30 16:34 ` Boris Brezillon
2018-04-30 14:43 ` [RFC PATCH 2/3] drm/bridge: panel: Make use of the panel detection infrastructure Boris Brezillon
2018-04-30 14:43 ` [RFC PATCH 3/3] drm/panel: rpi-touchscreen: Implement ->detect() Boris Brezillon
2018-04-30 17:22 ` Eric Anholt [this message]
2018-04-30 17:43 ` [RFC PATCH 0/3] drm/panel: Support panel detection Boris Brezillon
2018-04-30 19:48 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0ygzk1g.fsf@anholt.net \
--to=eric@anholt.net \
--cc=airlied@linux.ie \
--cc=boris.brezillon@bootlin.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=thierry.reding@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.