From: Rob Clark <robdclark@gmail.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
freedreno <freedreno@lists.freedesktop.org>,
aarch64-laptops@lists.linaro.org,
Rob Clark <robdclark@chromium.org>,
Mark Rutland <mark.rutland@arm.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] dt-bindings: chosen: document panel-id binding
Date: Mon, 1 Jul 2019 07:41:52 -0700 [thread overview]
Message-ID: <CAF6AEGvRXZAannGisHjsaW4Pg3v2ma5WHK2phqg8TaF53pR8XQ@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqKMULJJ9CERRBpqd7Y2dtovEJ6jcDKy6J4yR6rAdjibUg@mail.gmail.com>
On Mon, Jul 1, 2019 at 7:03 AM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Sun, Jun 30, 2019 at 2:36 PM Rob Clark <robdclark@gmail.com> wrote:
> >
> > From: Rob Clark <robdclark@chromium.org>
> >
> > The panel-id property in chosen can be used to communicate which panel,
> > of multiple possibilities, is installed.
> >
> > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > ---
> > Documentation/devicetree/bindings/chosen.txt | 69 ++++++++++++++++++++
> > 1 file changed, 69 insertions(+)
>
> I need to update this file to say it's moved to the schema repository...
>
> But I don't think that will matter...
>
> > diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt
> > index 45e79172a646..d502e6489b8b 100644
> > --- a/Documentation/devicetree/bindings/chosen.txt
> > +++ b/Documentation/devicetree/bindings/chosen.txt
> > @@ -68,6 +68,75 @@ on PowerPC "stdout" if "stdout-path" is not found. However, the
> > "linux,stdout-path" and "stdout" properties are deprecated. New platforms
> > should only use the "stdout-path" property.
> >
> > +panel-id
> > +--------
> > +
> > +For devices that have multiple possible display panels (multi-sourcing the
> > +display panels is common on laptops, phones, tablets), this allows the
> > +bootloader to communicate which panel is installed, e.g.
>
> How does the bootloader figure out which panel? Why can't the kernel
> do the same thing?
see jhugo's response, he has I guess more access to the bootloader than I
> > +
> > +/ {
> > + chosen {
> > + panel-id = <0xc4>;
> > + };
> > +
> > + ivo_panel {
> > + compatible = "ivo,m133nwf4-r0";
> > + power-supply = <&vlcm_3v3>;
> > + no-hpd;
> > +
> > + ports {
> > + port {
> > + ivo_panel_in_edp: endpoint {
> > + remote-endpoint = <&sn65dsi86_out_ivo>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + boe_panel {
> > + compatible = "boe,nv133fhm-n61";
>
> Both panels are going to probe. So the bootloader needs to disable the
> not populated panel setting 'status' (or delete the node). If you do
> that, do you even need 'panel-id'?
I don't think we can rely on bootloader knowing a thing about DT on
these devices..
OTOH I don't really think it is a big problem for both panels to
probe. But I suppose it might be possible to have something somewhere
in the kernel that realizes and disables the unused panels.
> > + power-supply = <&vlcm_3v3>;
> > + no-hpd;
> > +
> > + ports {
> > + port {
> > + boe_panel_in_edp: endpoint {
> > + remote-endpoint = <&sn65dsi86_out_boe>;
> > + };
> > + };
> > + };
> > + };
> > +
> > + display_or_bridge_device {
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ...
> > +
> > + port@0 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + reg = <0>;
> > +
> > + endpoint@c4 {
> > + reg = <0xc4>;
>
> What does this number represent? It is supposed to be defined by the
> display_or_bridge_device, not a specific panel.
it matches /chosen/panel-id.. in this case I'm not sure how the
panel-id's are assigned, but for our purposes all that matters is that
they are assigned.
> We also need to consider how the DSI case with panels as children of
> the DSI controller would work and how this would work with multiple
> displays each having multiple panel options.
In the non-bridge case (panel hooked directly to dsi controller), the
dsi controller could use the same ports {} mechanism.
For multiple displays, we could extend, I suppose, /chosen/panel-id to
be an array of id's indexed by display. I think this is the type of
extension we could do later when the use-case comes up. Just having
this solved upstream for single display would already be a huge
advancement. (You don't want to look at how this is solved downstream
for android phones.)
Btw, if you are curious how this works on windows/ACPI, the ACPI
tables have entries for each of the panels. The kernel is expected to
take the panel-id from that EFI variable that jhugo mentioned, and
pass it to a _ROM method which returns the appropriate panel table.
(Not entirely sure how the orchestrate reading the EFI variable early,
since it does not appear to be available after ExitBootServices)
BR,
-R
next prev parent reply other threads:[~2019-07-01 14:42 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-30 20:36 [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Rob Clark
2019-06-30 20:36 ` [PATCH 1/4] dt-bindings: chosen: document panel-id binding Rob Clark
2019-07-01 14:03 ` Rob Herring
2019-07-01 14:28 ` Jeffrey Hugo
2019-07-01 14:41 ` Rob Clark [this message]
2019-11-30 18:37 ` Rob Clark
2019-11-30 18:39 ` Rob Clark
2019-06-30 20:36 ` [PATCH 2/4] efi/libstub: detect panel-id Rob Clark
2019-07-02 20:26 ` Ard Biesheuvel
2019-07-02 20:35 ` Ard Biesheuvel
2019-07-02 21:01 ` Rob Clark
2019-07-02 21:53 ` Ard Biesheuvel
2019-07-02 22:36 ` Rob Clark
2019-07-02 21:59 ` Leif Lindholm
2019-07-02 22:48 ` Rob Clark
2019-07-03 16:33 ` Leif Lindholm
2019-07-03 17:41 ` Rob Clark
2019-07-03 17:54 ` Ard Biesheuvel
2019-06-30 20:36 ` [PATCH 3/4] drm: add helper to lookup panel-id Rob Clark
2019-06-30 20:36 ` [PATCH 4/4] drm/bridge: ti-sn65dsi86: use " Rob Clark
2019-06-30 21:17 ` Laurent Pinchart
2019-06-30 21:50 ` Rob Clark
2019-06-30 21:57 ` Laurent Pinchart
2019-06-30 22:04 ` Rob Clark
2019-06-30 20:47 ` [PATCH 0/4] drm+dt+efi: support devices with multiple possible panels Laurent Pinchart
2019-06-30 21:05 ` Rob Clark
2019-06-30 21:15 ` Laurent Pinchart
2019-06-30 21:35 ` Rob Clark
2019-07-02 12:50 ` Rob Clark
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=CAF6AEGvRXZAannGisHjsaW4Pg3v2ma5WHK2phqg8TaF53pR8XQ@mail.gmail.com \
--to=robdclark@gmail.com \
--cc=aarch64-laptops@lists.linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robdclark@chromium.org \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).