From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Krishna Manikandan <mkrishn@codeaurora.org>,
dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
freedreno@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, kalyan_t@codeaurora.org,
tanmay@codeaurora.org, abhinavk@codeaurora.org,
robdclark@gmail.com, vinod.koul@linaro.org,
dianders@chromium.org, khsieh@codeaurora.org, robh+dt@kernel.org,
sean@poorly.run, robh@kernel.org
Subject: Re: [PATCH v17 1/4] dt-bindings: msm: disp: add yaml schemas for DPU bindings
Date: Fri, 21 May 2021 16:29:16 -0500 [thread overview]
Message-ID: <20210521212916.GG2484@yoga> (raw)
In-Reply-To: <CAE-0n53y2_icuPf+j8hd1hGyWRbD2V0Fye+aGSe0M9zku_0DOA@mail.gmail.com>
On Fri 21 May 15:51 CDT 2021, Stephen Boyd wrote:
> Quoting Bjorn Andersson (2021-05-21 09:00:29)
> > On Fri 21 May 05:27 CDT 2021, Krishna Manikandan wrote:
> > > diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> > [..]
> > > + ports:
> > > + $ref: /schemas/graph.yaml#/properties/ports
> > > + description: |
> > > + Contains the list of output ports from DPU device. These ports
> > > + connect to interfaces that are external to the DPU hardware,
> > > + such as DSI, DP etc. Each output port contains an endpoint that
> > > + describes how it is connected to an external interface.
> > > +
> > > + properties:
> > > + port@0:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: DPU_INTF1 (DSI1)
> > > +
> > > + port@2:
> > > + $ref: /schemas/graph.yaml#/properties/port
> > > + description: DPU_INTF0 (DP)
> >
> > Why is port@0 INTF1 and why is port@2 INTF0? In the binding you're
> > translating the two ports that are described are 0 and 1, representing
> > INTF1 and INTF2, or DSI1 and DSI2, respectively.
> >
> > Further more, I have a need for somehow describing the pairing of 4 DP
> > INTFs (INTF 0, 3, 4 and 5) and how they are connected to the 3+1 DP+eDP
> > controllers.
> >
> > Downstream this seems to be handled by adding cell-index to the DP
> > controllers and then matching that against the numbering in the driver's
> > INTF array. But rather than adding cell-index to map this, can't we
> > define that the port index is the INTF-number here?
> >
> >
> > This would obviously break compatibility with existing DTBs, but we
> > could start by doing it selectively for the new compatibles, fix up the
> > existing dts files and then drop the selective application after 1 or 2
> > LTS releases.
>
> I requested that the existing DT not change a while ago when the DP
> interface was being added to this binding. Is it possible to figure out
> what interface it is that the port is for from the binding? It feels
> like the problem is that the driver wants to look through the graph and
> make connectors for each one, but it doesn't know what type of connector
> to make.
Today there's a single priv->dp pointer which is initialized as the one
and only displayport controller component is bound.
_dpu_kms_set_encoder_mode() has no knowledge about which interface this
single controller is attached to, so dpu_encoder_setup_display() will
always just pick INTF_DP index 0.
So in its current form if your single DP port isn't sitting on the
platform's first DP INTF you need to hack dpu_hw_catalog and remove the
previous ones.
But with my desire to reuse the DP controller code for eDP, and the fact
that I have 3 DP controllers in my laptop we need something more.
But after considering my proposal further I realized that it is too
static for my use case anyway. SC8180x has INTF 0 and 4 are wired to
the DP controllers associated with the two primary USB ports and then
INTF 3 is dynamically switched between them for MST purposes.
So using port indices would prevent me from doing this dynamic dance.
Regards,
Bjorn
next prev parent reply other threads:[~2021-05-21 21:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-21 10:27 [PATCH v17 1/4] dt-bindings: msm: disp: add yaml schemas for DPU bindings Krishna Manikandan
2021-05-21 10:27 ` [PATCH v17 2/4] dt-bindings: msm: dsi: add yaml schemas for DSI bindings Krishna Manikandan
2021-05-21 17:14 ` Bjorn Andersson
2021-05-21 18:37 ` Rob Herring
2021-05-21 20:47 ` Stephen Boyd
2021-05-21 10:27 ` [PATCH v17 3/4] dt-bindings: msm: dsi: add yaml schemas for DSI PHY bindings Krishna Manikandan
2021-05-21 17:18 ` Bjorn Andersson
2021-05-21 18:29 ` Rob Herring
2021-05-21 20:47 ` Stephen Boyd
2021-05-21 10:27 ` [PATCH v17 4/4] dt-bindings: msm/dp: Add bindings of MSM DisplayPort controller Krishna Manikandan
2021-05-21 17:19 ` Bjorn Andersson
2021-05-21 18:37 ` Rob Herring
2021-05-21 20:46 ` Stephen Boyd
2021-05-21 16:00 ` [PATCH v17 1/4] dt-bindings: msm: disp: add yaml schemas for DPU bindings Bjorn Andersson
2021-05-21 17:11 ` Bjorn Andersson
2021-05-21 20:51 ` Stephen Boyd
2021-05-21 21:29 ` Bjorn Andersson [this message]
2021-05-21 18:29 ` Rob Herring
2021-05-21 20:47 ` Stephen Boyd
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=20210521212916.GG2484@yoga \
--to=bjorn.andersson@linaro.org \
--cc=abhinavk@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=kalyan_t@codeaurora.org \
--cc=khsieh@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkrishn@codeaurora.org \
--cc=robdclark@gmail.com \
--cc=robh+dt@kernel.org \
--cc=robh@kernel.org \
--cc=sean@poorly.run \
--cc=swboyd@chromium.org \
--cc=tanmay@codeaurora.org \
--cc=vinod.koul@linaro.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).