The primary goal of this series is to try to properly fix EDID reading for eDP panels using the ti-sn65dsi86 bridge.
Previously we had a patch that added EDID reading but it turned out not to work at bootup. This caused some extra churn at bootup as we tried (and failed) to read the EDID several times and also ended up forcing us to use the hardcoded mode at boot. With this patch series I believe EDID reading is reliable at boot now and we never use the hardcoded mode.
High level note: in this series the EDID reading is driven by the panel driver, not by the bridge chip driver. I believe this makes a reasonable amount of sense since the panel driver already _could_ drive reading the EDID if provided with the DDC bus and in future planned work we'll want to give the panel driver the DDC bus (to make decisions based on EDID) and the AUX bus (to control the backlight). There are also planned patches from Laurent to make ti-sn65dsi86 able to drive full DP monitors. In that case the bridge chip will still be in charge of reading the EDID, but it's not hard to make this dynamic.
This series is the logical successor to the 3-part series containing the patch ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk") [1].
This patch was tested against drm-misc-next commit 60a6b73dd821 ("drm/ingenic: Fix pixclock rate for 24-bit serial panels") on a sc7180-trogdor-lazor device.
At v7 now, this patch series grew a bit from v6 because it introduces the DP AUX bus.
Between v2 and v3, high-level view of changes: - stop doing the EDID caching in the core.
Between v3 and v4, high-level view of changes: - EDID reading is actually driven by the panel driver now. See above. - Lots of chicken-and-egg problems solved w/ sub-devices.
Between v4 and v5, high-level view of changes. - Some of the early patches landed, so dropped from series. - New pm_runtime_disable() fix (fixed a patch that already landed). - Added Bjorn's tags to most patches - Fixed problems when building as a module. - Reordered debugfs patch and fixed error handling there. - Dropped last patch. I'm not convinced it's safe w/out more work.
Between v5 and v6, high-level view of changes: - Added the patch ("drm/dp: Allow an early call to register DDC i2c bus") - Many patches had been landed, so only a few "controversial" ones left.
Between v6 and v7, high-level view of changes: - New AUX DP bus!
[1] https://lore.kernel.org/r/20210304155144.3.I60a7fb23ce4589006bc95c64ab8d15c7...
Changes in v7: - pm_runtime_dont_use_autosuspend() fix new for v7. - List hpd properties bindings patch new for v7. - ti-sn65dsi86: Add aux-bus child patch new for v7. - Patch introducing the DP AUX bus is new for v7. - Patch to allow panel-simple to be DP AUX EP new for v7. - Patch using the DP AUX for DDC new for v7. - Remove use of now-dropped drm_dp_aux_register_ddc() call. - Beefed up commit message in context of the DP AUX bus. - Set the proper sub-device "dev" pointer in the AUX structure. - Patch to support for DP AUX bus on ti-sn65dsi86 new for v7. - Adjusted commit message to talk about DP AUX bus. - Panel now under bridge chip instead of getting a link to ddc-i2c
Changes in v6: - Use new drm_dp_aux_register_ddc() calls.
Douglas Anderson (10): drm/panel: panel-simple: Add missing pm_runtime_dont_use_autosuspend() calls dt-bindings: display: simple: List hpd properties in panel-simple dt-bindings: drm/bridge: ti-sn65dsi86: Add aux-bus child drm: Introduce the DP AUX bus drm/panel: panel-simple: Allow panel-simple be a DP AUX endpoint device drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC arm64: dts: qcom: sc7180-trogdor: Move panel under the bridge chip
.../bindings/display/bridge/ti,sn65dsi86.yaml | 22 +- .../bindings/display/panel/panel-simple.yaml | 2 + arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 30 +- drivers/gpu/drm/Kconfig | 5 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 111 ++++-- drivers/gpu/drm/drm_dp_aux_bus.c | 322 ++++++++++++++++++ drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-simple.c | 66 +++- include/drm/drm_dp_aux_bus.h | 57 ++++ 11 files changed, 563 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/drm_dp_aux_bus.c create mode 100644 include/drm/drm_dp_aux_bus.h
The PM Runtime docs specifically call out the need to call pm_runtime_dont_use_autosuspend() in the remove() callback if pm_runtime_use_autosuspend() was called in probe():
Drivers in ->remove() callback should undo the runtime PM changes done in ->probe(). Usually this means calling pm_runtime_disable(), pm_runtime_dont_use_autosuspend() etc.
We should do this. This fixes a warning splat that I saw when I was testing out the panel-simple's remove().
Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Signed-off-by: Douglas Anderson dianders@chromium.org ---
Changes in v7: - pm_runtime_dont_use_autosuspend() fix new for v7.
drivers/gpu/drm/panel/panel-simple.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 9be050ab372f..21939d4352cf 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -798,6 +798,7 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc) return 0;
disable_pm_runtime: + pm_runtime_dont_use_autosuspend(dev); pm_runtime_disable(dev); free_ddc: if (panel->ddc) @@ -814,6 +815,7 @@ static int panel_simple_remove(struct device *dev) drm_panel_disable(&panel->base); drm_panel_unprepare(&panel->base);
+ pm_runtime_dont_use_autosuspend(dev); pm_runtime_disable(dev); if (panel->ddc) put_device(&panel->ddc->dev);
Hi Doug,
Thank you for the patch.
On Mon, May 17, 2021 at 01:08:58PM -0700, Douglas Anderson wrote:
The PM Runtime docs specifically call out the need to call pm_runtime_dont_use_autosuspend() in the remove() callback if pm_runtime_use_autosuspend() was called in probe():
Drivers in ->remove() callback should undo the runtime PM changes done in ->probe(). Usually this means calling pm_runtime_disable(), pm_runtime_dont_use_autosuspend() etc.
~/src/kernel/linux $ git grep pm_runtime_use_autosuspend -- drivers | wc -l 209 ~/src/kernel/linux $ git grep pm_runtime_dont_use_autosuspend -- drivers | wc -l 80
Seems like a lost battle :-(
The fix is right, but I wonder if this shouldn't be handled automatically by the runtime PM core. The runtime PM API is notoriously difficult to use correctly.
We should do this. This fixes a warning splat that I saw when I was testing out the panel-simple's remove().
Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Signed-off-by: Douglas Anderson dianders@chromium.org
Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
Changes in v7:
- pm_runtime_dont_use_autosuspend() fix new for v7.
drivers/gpu/drm/panel/panel-simple.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 9be050ab372f..21939d4352cf 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -798,6 +798,7 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc) return 0;
disable_pm_runtime:
- pm_runtime_dont_use_autosuspend(dev); pm_runtime_disable(dev);
free_ddc: if (panel->ddc) @@ -814,6 +815,7 @@ static int panel_simple_remove(struct device *dev) drm_panel_disable(&panel->base); drm_panel_unprepare(&panel->base);
- pm_runtime_dont_use_autosuspend(dev); pm_runtime_disable(dev); if (panel->ddc) put_device(&panel->ddc->dev);
Hi,
On Mon, May 24, 2021 at 1:22 PM Laurent Pinchart laurent.pinchart@ideasonboard.com wrote:
Hi Doug,
Thank you for the patch.
On Mon, May 17, 2021 at 01:08:58PM -0700, Douglas Anderson wrote:
The PM Runtime docs specifically call out the need to call pm_runtime_dont_use_autosuspend() in the remove() callback if pm_runtime_use_autosuspend() was called in probe():
Drivers in ->remove() callback should undo the runtime PM changes done in ->probe(). Usually this means calling pm_runtime_disable(), pm_runtime_dont_use_autosuspend() etc.
~/src/kernel/linux $ git grep pm_runtime_use_autosuspend -- drivers | wc -l 209 ~/src/kernel/linux $ git grep pm_runtime_dont_use_autosuspend -- drivers | wc -l 80
Seems like a lost battle :-(
The fix is right, but I wonder if this shouldn't be handled automatically by the runtime PM core. The runtime PM API is notoriously difficult to use correctly.
No kidding.
We should do this. This fixes a warning splat that I saw when I was testing out the panel-simple's remove().
Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") Signed-off-by: Douglas Anderson dianders@chromium.org
Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
Thanks! I have pushed just this patch for now.
-Doug
These are described in panel-common.yaml but if I don't list them in panel-simple then I get yells when running 'dt_binding_check' in a future patch. List them along with other properties that seem to be listed in panel-simple for similar reasons.
Signed-off-by: Douglas Anderson dianders@chromium.org --- I didn't spend tons of time digging to see if there was supposed to be a better way of doing this. If there is, feel free to yell.
Changes in v7: - List hpd properties bindings patch new for v7.
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index b3797ba2698b..4a0a5e1ee252 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -298,6 +298,8 @@ properties: enable-gpios: true port: true power-supply: true + no-hpd: true + hpd-gpios: true
additionalProperties: false
On Mon, May 17, 2021 at 3:09 PM Douglas Anderson dianders@chromium.org wrote:
These are described in panel-common.yaml but if I don't list them in panel-simple then I get yells when running 'dt_binding_check' in a future patch. List them along with other properties that seem to be listed in panel-simple for similar reasons.
If you have HPD, is it still a simple panel? I don't see this as an omission because the use of these properties for simple panels was never documented IIRC.
Not saying we can't add them, but justify it as an addition, not just fixing a warning.
Signed-off-by: Douglas Anderson dianders@chromium.org
I didn't spend tons of time digging to see if there was supposed to be a better way of doing this. If there is, feel free to yell.
That's the right way to do it unless you want to allow all common properties, then we'd use unevaluatedProperties instead of additionalProperties.
Changes in v7:
- List hpd properties bindings patch new for v7.
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index b3797ba2698b..4a0a5e1ee252 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -298,6 +298,8 @@ properties: enable-gpios: true port: true power-supply: true
- no-hpd: true
- hpd-gpios: true
additionalProperties: false
-- 2.31.1.751.gd2f1c929bd-goog
Hi,
On Tue, May 18, 2021 at 5:42 AM Rob Herring robh+dt@kernel.org wrote:
On Mon, May 17, 2021 at 3:09 PM Douglas Anderson dianders@chromium.org wrote:
These are described in panel-common.yaml but if I don't list them in panel-simple then I get yells when running 'dt_binding_check' in a future patch. List them along with other properties that seem to be listed in panel-simple for similar reasons.
If you have HPD, is it still a simple panel? I don't see this as an omission because the use of these properties for simple panels was never documented IIRC.
I would say so. It is currently supported by panel-simple in Linux. Of course, you could make the argument that panel-simple is no longer really "simple" because of things like this...
I guess I'd say this: I believe that the HPD properties eventually belong in the generic "edp-panel" that I'm still planning to post (and which will be based on this series). I justified that previously [1] by talking about the fact that there's a single timing diagram that (as far as I've been able to tell) is fairly universal in panel specs. It's a complicated timing diagram showing some two dozen timings (and includes HPD!), but if you support all the timings then you've supported pretty much all panels. IMO the original intent of "simple-panel" was to specify a panel that's just like all the other panels w/ a few parameters.
NOTE: I'd also say that for nearly all eDP panels HPD is important, but in many designs HPD is handled "magically" and not specified in the device tree. This is because it goes to a dedicated location on the eDP controller / bridge chip. I added the HPD GPIO support (and no-hpd) to simple-panel because my bridge chip has a fairly useless HPD line and we don't use it. Even though the fact that we need the HPD specified like this is a function of our bridge chip, back in the day I was told that the property belonged in the panel and so that's where it lives.
Not saying we can't add them, but justify it as an addition, not just fixing a warning.
Sure, I'll beef up the commit message.
Signed-off-by: Douglas Anderson dianders@chromium.org
I didn't spend tons of time digging to see if there was supposed to be a better way of doing this. If there is, feel free to yell.
That's the right way to do it unless you want to allow all common properties, then we'd use unevaluatedProperties instead of additionalProperties.
Ah, perfect. Thanks!
[1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrE...
-Doug
On Tue, May 18, 2021 at 3:58 PM Doug Anderson dianders@chromium.org wrote:
On Tue, May 18, 2021 at 5:42 AM Rob Herring robh+dt@kernel.org wrote:
On Mon, May 17, 2021 at 3:09 PM Douglas Anderson dianders@chromium.org wrote:
These are described in panel-common.yaml but if I don't list them in panel-simple then I get yells when running 'dt_binding_check' in a future patch. List them along with other properties that seem to be listed in panel-simple for similar reasons.
If you have HPD, is it still a simple panel? I don't see this as an omission because the use of these properties for simple panels was never documented IIRC.
I would say so. It is currently supported by panel-simple in Linux. Of course, you could make the argument that panel-simple is no longer really "simple" because of things like this...
I think it should be renamed panel-panacea at this point. I think I pointed it out before. But not my pick so I rest my case.
Yours, Linus Walleij
We want to be able to list an eDP panel as a child of a ti-sn65dsi86 node to represent the fact that the panel is connected to the bridge's DP AUX bus. Though the panel and the bridge chip are connected in several ways, the DP AUX bus is the primary control interface between the two and thus makes the most sense to model in device tree hierarchy.
Listing a panel in this way makes it possible for the panel driver to easily get access to the DP AUX bus that it resides on, which can be useful to help in auto-detecting the panel and for turning on various bits.
NOTE: it's still possible to continue using the bridge chip and point to a panel that _isn't_ listed as a child of the bridge chip (since it's worked that way previously), but that should be deprecated since there is no downside to listing the panel under the bridge chip.
The idea for this bus's design was hashed out over IRC [1].
[1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2...
Signed-off-by: Douglas Anderson dianders@chromium.org --- Possibly we might want something fancier that could be included by other eDP controller bindings. If we want to do this, I'd love to be pointed at a good example to follow.
Changes in v7: - ti-sn65dsi86: Add aux-bus child patch new for v7.
.../bindings/display/bridge/ti,sn65dsi86.yaml | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 26932d2e86ab..51f5a29e216c 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -70,6 +70,11 @@ properties: const: 1 description: See ../../pwm/pwm.yaml for description of the cell formats.
+ aux-bus: + description: + It is recommended that you place your panel under the aux-bus node + here to represent the control hierarchy. + ports: $ref: /schemas/graph.yaml#/properties/ports
@@ -201,11 +206,26 @@ examples:
port@1 { reg = <1>; - endpoint { + sn65dsi86_out: endpoint { remote-endpoint = <&panel_in_edp>; }; }; }; + + aux-bus { + panel { + compatible = "boe,nv133fhm-n62"; + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&sn65dsi86_out>; + }; + }; + }; + }; }; }; - |
On Mon, May 17, 2021 at 01:09:00PM -0700, Douglas Anderson wrote:
We want to be able to list an eDP panel as a child of a ti-sn65dsi86 node to represent the fact that the panel is connected to the bridge's DP AUX bus. Though the panel and the bridge chip are connected in several ways, the DP AUX bus is the primary control interface between the two and thus makes the most sense to model in device tree hierarchy.
Listing a panel in this way makes it possible for the panel driver to easily get access to the DP AUX bus that it resides on, which can be useful to help in auto-detecting the panel and for turning on various bits.
NOTE: it's still possible to continue using the bridge chip and point to a panel that _isn't_ listed as a child of the bridge chip (since it's worked that way previously), but that should be deprecated since there is no downside to listing the panel under the bridge chip.
The idea for this bus's design was hashed out over IRC [1].
[1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2...
Signed-off-by: Douglas Anderson dianders@chromium.org
Possibly we might want something fancier that could be included by other eDP controller bindings. If we want to do this, I'd love to be pointed at a good example to follow.
Changes in v7:
- ti-sn65dsi86: Add aux-bus child patch new for v7.
.../bindings/display/bridge/ti,sn65dsi86.yaml | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 26932d2e86ab..51f5a29e216c 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -70,6 +70,11 @@ properties: const: 1 description: See ../../pwm/pwm.yaml for description of the cell formats.
- aux-bus:
As this is a node:
type: object
- description:
It is recommended that you place your panel under the aux-bus node
here to represent the control hierarchy.
- ports: $ref: /schemas/graph.yaml#/properties/ports
@@ -201,11 +206,26 @@ examples:
port@1 { reg = <1>;
endpoint {
sn65dsi86_out: endpoint { remote-endpoint = <&panel_in_edp>; }; }; };
aux-bus {
panel {
We should perhaps have a separate aux-bus schema. Something should define the child node is 'panel' and nothing else. Though perhaps connectors are valid too?
compatible = "boe,nv133fhm-n62";
power-supply = <&pp3300_dx_edp>;
backlight = <&backlight>;
hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>;
port {
panel_in_edp: endpoint {
remote-endpoint = <&sn65dsi86_out>;
};
};
};
};}; };
- |
-- 2.31.1.751.gd2f1c929bd-goog
Hi,
On Wed, May 19, 2021 at 1:02 PM Rob Herring robh@kernel.org wrote:
On Mon, May 17, 2021 at 01:09:00PM -0700, Douglas Anderson wrote:
We want to be able to list an eDP panel as a child of a ti-sn65dsi86 node to represent the fact that the panel is connected to the bridge's DP AUX bus. Though the panel and the bridge chip are connected in several ways, the DP AUX bus is the primary control interface between the two and thus makes the most sense to model in device tree hierarchy.
Listing a panel in this way makes it possible for the panel driver to easily get access to the DP AUX bus that it resides on, which can be useful to help in auto-detecting the panel and for turning on various bits.
NOTE: it's still possible to continue using the bridge chip and point to a panel that _isn't_ listed as a child of the bridge chip (since it's worked that way previously), but that should be deprecated since there is no downside to listing the panel under the bridge chip.
The idea for this bus's design was hashed out over IRC [1].
[1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2...
Signed-off-by: Douglas Anderson dianders@chromium.org
Possibly we might want something fancier that could be included by other eDP controller bindings. If we want to do this, I'd love to be pointed at a good example to follow.
Changes in v7:
- ti-sn65dsi86: Add aux-bus child patch new for v7.
.../bindings/display/bridge/ti,sn65dsi86.yaml | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 26932d2e86ab..51f5a29e216c 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -70,6 +70,11 @@ properties: const: 1 description: See ../../pwm/pwm.yaml for description of the cell formats.
- aux-bus:
As this is a node:
type: object
- description:
It is recommended that you place your panel under the aux-bus node
here to represent the control hierarchy.
- ports: $ref: /schemas/graph.yaml#/properties/ports
@@ -201,11 +206,26 @@ examples:
port@1 { reg = <1>;
endpoint {
sn65dsi86_out: endpoint { remote-endpoint = <&panel_in_edp>; }; }; };
aux-bus {
panel {
We should perhaps have a separate aux-bus schema.
Yeah. Before spending lots of time digging into how to do this I wanted to see if anyone was going to give me a big-old NAK on the whole approach. ;-)
I guess I'd make a file called "dp-aux-bus.yaml" (maybe right under bindings/display?) and then I'd include it like this:
aux-bus: $ref: "../dp-aux-bus.yaml#"
Something should define the child node is 'panel' and nothing else.
At the moment the code also requires that the node name is 'aux-bus'. Any objections to that?
Though perhaps connectors are valid too?
They might be. We could always add it later?
On Wed, May 19, 2021 at 4:06 PM Doug Anderson dianders@chromium.org wrote:
Hi,
On Wed, May 19, 2021 at 1:02 PM Rob Herring robh@kernel.org wrote:
On Mon, May 17, 2021 at 01:09:00PM -0700, Douglas Anderson wrote:
We want to be able to list an eDP panel as a child of a ti-sn65dsi86 node to represent the fact that the panel is connected to the bridge's DP AUX bus. Though the panel and the bridge chip are connected in several ways, the DP AUX bus is the primary control interface between the two and thus makes the most sense to model in device tree hierarchy.
Listing a panel in this way makes it possible for the panel driver to easily get access to the DP AUX bus that it resides on, which can be useful to help in auto-detecting the panel and for turning on various bits.
NOTE: it's still possible to continue using the bridge chip and point to a panel that _isn't_ listed as a child of the bridge chip (since it's worked that way previously), but that should be deprecated since there is no downside to listing the panel under the bridge chip.
The idea for this bus's design was hashed out over IRC [1].
[1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2...
Signed-off-by: Douglas Anderson dianders@chromium.org
Possibly we might want something fancier that could be included by other eDP controller bindings. If we want to do this, I'd love to be pointed at a good example to follow.
Changes in v7:
- ti-sn65dsi86: Add aux-bus child patch new for v7.
.../bindings/display/bridge/ti,sn65dsi86.yaml | 22 ++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 26932d2e86ab..51f5a29e216c 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -70,6 +70,11 @@ properties: const: 1 description: See ../../pwm/pwm.yaml for description of the cell formats.
- aux-bus:
As this is a node:
type: object
- description:
It is recommended that you place your panel under the aux-bus node
here to represent the control hierarchy.
- ports: $ref: /schemas/graph.yaml#/properties/ports
@@ -201,11 +206,26 @@ examples:
port@1 { reg = <1>;
endpoint {
sn65dsi86_out: endpoint { remote-endpoint = <&panel_in_edp>; }; }; };
aux-bus {
panel {
We should perhaps have a separate aux-bus schema.
Yeah. Before spending lots of time digging into how to do this I wanted to see if anyone was going to give me a big-old NAK on the whole approach. ;-)
I guess I'd make a file called "dp-aux-bus.yaml" (maybe right under bindings/display?) and then I'd include it like this:
aux-bus: $ref: "../dp-aux-bus.yaml#"
Right.
Something should define the child node is 'panel' and nothing else.
At the moment the code also requires that the node name is 'aux-bus'. Any objections to that?
No. There's 2 ways to do that. The above does and adding $nodename in dp-aux-bus.yaml will. The latter also means the schema will be applied automatically to any node named 'aux-bus'. That means the schema will be applied twice unless you have 'select: false'. The main advantage of the latter case is it gets applied even without all the users converted to schema.
Though perhaps connectors are valid too?
They might be. We could always add it later?
Sure.
Rob
Historically "simple" eDP panels have been handled by panel-simple which is a basic platform_device. In the device tree, the panel node was at the top level and not connected to anything else.
Let's change it so that, instead, panels can be represented as being children of the "DP AUX bus". Essentially we're saying that the hierarchy that we're going to represent is the "control" connections between devices. The DP AUX bus is a control bus provided by an eDP controller (the parent) and consumed by a device like a panel (the child).
The primary incentive here is to cleanly provide the panel driver the ability to communicate over the AUX bus while handling lifetime issues properly. The panel driver may want the AUX bus for controlling the backlight or querying the panel's EDID.
The idea for this bus's design was hashed out over IRC [1].
[1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2...
Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Lyude Paul lyude@redhat.com Cc: Rajeev Nandan rajeevny@codeaurora.org Suggested-by: Laurent Pinchart laurent.pinchart@ideasonboard.com Signed-off-by: Douglas Anderson dianders@chromium.org --- There's a whole lot of boilerplate code here. I've tried my best to grok what all of it should be, drawing inspiration from other similar bus drivers (auxiliary, i2c, serdev, platform) and I've tried to test several of the corner cases, but I can't actually believe that I've touched every code path. Please yell if you see something dumb.
Changes in v7: - Patch introducing the DP AUX bus is new for v7.
drivers/gpu/drm/Kconfig | 5 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/drm_dp_aux_bus.c | 322 +++++++++++++++++++++++++++++++ include/drm/drm_dp_aux_bus.h | 57 ++++++ 4 files changed, 386 insertions(+) create mode 100644 drivers/gpu/drm/drm_dp_aux_bus.c create mode 100644 include/drm/drm_dp_aux_bus.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index d3a9ca4b1cec..307a6487c8fd 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -35,6 +35,11 @@ config DRM_MIPI_DSI bool depends on DRM
+config DRM_DP_AUX_BUS + bool + depends on DRM + depends on OF + config DRM_DP_AUX_CHARDEV bool "DRM DP AUX Interface" depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index a91cc7684904..e1a295e550ea 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -33,6 +33,8 @@ drm-$(CONFIG_PCI) += drm_pci.o drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
+drm-$(CONFIG_DRM_DP_AUX_BUS) += drm_dp_aux_bus.o + drm_vram_helper-y := drm_gem_vram_helper.o obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
diff --git a/drivers/gpu/drm/drm_dp_aux_bus.c b/drivers/gpu/drm/drm_dp_aux_bus.c new file mode 100644 index 000000000000..2046fef323e6 --- /dev/null +++ b/drivers/gpu/drm/drm_dp_aux_bus.c @@ -0,0 +1,322 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright 2021 Google Inc. + * + * The DP AUX bus is used for devices that are connected over a DisplayPort + * AUX bus. The devices on the far side of the bus are referred to as + * endpoints in this code. + * + * Commonly there is only one device connected to the DP AUX bus: a panel. + * Though historically panels (even DP panels) have been modeled as simple + * platform devices, putting them under the DP AUX bus allows the panel driver + * to perform transactions on that bus. + */ + +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/of_device.h> +#include <linux/pm_domain.h> +#include <linux/pm_runtime.h> + +#include <drm/drm_dp_aux_bus.h> +#include <drm/drm_dp_helper.h> + + +/** + * dp_aux_ep_match() - The match function for the dp_aux_bus. + * @dev: The device to match. + * @drv: The driver to try to match against. + * + * At the moment, we just match on device tree. + * + * Return: True if this driver matches this device; false otherwise. + */ +static int dp_aux_ep_match(struct device *dev, struct device_driver *drv) +{ + return !!of_match_device(drv->of_match_table, dev); +} + +/** + * dp_aux_ep_probe() - The probe function for the dp_aux_bus. + * @dev: The device to probe. + * + * Calls through to the endpoint driver probe. + * + * Return: 0 if no error or negative error code. + */ +static int dp_aux_ep_probe(struct device *dev) +{ + struct dp_aux_ep_driver *aux_ep_drv = to_dp_aux_ep_drv(dev->driver); + struct dp_aux_ep_device *aux_ep = to_dp_aux_ep_dev(dev); + int ret; + + ret = dev_pm_domain_attach(dev, true); + if (ret) + return dev_err_probe(dev, ret, "Failed to attach to PM Domain\n"); + + ret = aux_ep_drv->probe(aux_ep); + if (ret) + dev_pm_domain_detach(dev, true); + + return ret; +} + +/** + * dp_aux_ep_remove() - The remove function for the dp_aux_bus. + * @dev: The device to remove. + * + * Calls through to the endpoint driver remove. + * + * Return: 0 if no error or negative error code. + */ +static int dp_aux_ep_remove(struct device *dev) +{ + struct dp_aux_ep_driver *aux_ep_drv = to_dp_aux_ep_drv(dev->driver); + struct dp_aux_ep_device *aux_ep = to_dp_aux_ep_dev(dev); + + if (aux_ep_drv->remove) + aux_ep_drv->remove(aux_ep); + dev_pm_domain_detach(dev, true); + + return 0; +} + +/** + * dp_aux_ep_shutdown() - The shutdown function for the dp_aux_bus. + * @dev: The device to shutdown. + * + * Calls through to the endpoint driver shutdown. + */ +static void dp_aux_ep_shutdown(struct device *dev) +{ + struct dp_aux_ep_driver *aux_ep_drv; + + if (!dev->driver) + return; + + aux_ep_drv = to_dp_aux_ep_drv(dev->driver); + if (aux_ep_drv->shutdown) + aux_ep_drv->shutdown(to_dp_aux_ep_dev(dev)); +} + +static struct bus_type dp_aux_bus_type = { + .name = "dp-aux", + .match = dp_aux_ep_match, + .probe = dp_aux_ep_probe, + .remove = dp_aux_ep_remove, + .shutdown = dp_aux_ep_shutdown, +}; + +static ssize_t modalias_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + return of_device_modalias(dev, buf, PAGE_SIZE); +} +static DEVICE_ATTR_RO(modalias); + +static struct attribute *dp_aux_ep_dev_attrs[] = { + &dev_attr_modalias.attr, + NULL, +}; +ATTRIBUTE_GROUPS(dp_aux_ep_dev); + +/** + * dp_aux_ep_dev_release() - Free memory for the dp_aux_ep device + * @dev: The device to free. + * + * Return: 0 if no error or negative error code. + */ +static void dp_aux_ep_dev_release(struct device *dev) +{ + kfree(to_dp_aux_ep_dev(dev)); +} + +static struct device_type dp_aux_device_type_type = { + .groups = dp_aux_ep_dev_groups, + .uevent = of_device_uevent_modalias, + .release = dp_aux_ep_dev_release, +}; + +/** + * of_dp_aux_ep_destroy() - Destroy an DP AUX endpoint device + * @dev: The device to destroy. + * @data: Not used + * + * This is just used as a callback by of_dp_aux_depopulate_ep_devices() and + * is called for _all_ of the child devices of the device providing the AUX bus. + * We'll only act on those that are of type "dp_aux_bus_type". + * + * This function is effectively an inverse of what's in the loop + * in of_dp_aux_populate_ep_devices(). + * + * Return: 0 if no error or negative error code. + */ +static int of_dp_aux_ep_destroy(struct device *dev, void *data) +{ + struct device_node *np = dev->of_node; + + if (dev->bus != &dp_aux_bus_type) + return 0; + + if (!of_node_check_flag(np, OF_POPULATED)) + return 0; + + of_node_clear_flag(np, OF_POPULATED); + of_node_put(np); + + device_unregister(dev); + + return 0; +} + +/** + * of_dp_aux_depopulate_ep_devices() - Undo of_dp_aux_populate_ep_devices + * @aux: The AUX channel whose devices we want to depopulate + * + * This will destroy all devices that were created + * by of_dp_aux_populate_ep_devices(). + */ +void of_dp_aux_depopulate_ep_devices(struct drm_dp_aux *aux) +{ + device_for_each_child_reverse(aux->dev, NULL, of_dp_aux_ep_destroy); +} +EXPORT_SYMBOL_GPL(of_dp_aux_depopulate_ep_devices); + +/** + * of_dp_aux_populate_ep_devices() - Populate the endpoint devices on the DP AUX + * @aux: The AUX channel whose devices we want to populate. It is required that + * drm_dp_aux_init() has already been called for this AUX channel. + * + * This will populate all the devices under the "aux-bus" node of the device + * providing the AUX channel (AKA aux->dev). + * + * When this function finishes, it is _possible_ (but not guaranteed) that + * our sub-devices will have finished probing. It should be noted that if our + * sub-devices return -EPROBE_DEFER that we will not return any error codes + * ourselves but our sub-devices will _not_ have actually probed successfully + * yet. There may be other cases (maybe added in the future?) where sub-devices + * won't have been probed yet when this function returns, so it's best not to + * rely on that. + * + * If this function succeeds you should later make sure you call + * of_dp_aux_depopulate_ep_devices() to undo it, or just use the devm version + * of this function. + * + * Return: 0 if no error or negative error code. + */ +int of_dp_aux_populate_ep_devices(struct drm_dp_aux *aux) +{ + struct device_node *bus, *np; + struct dp_aux_ep_device *aux_ep; + int ret; + + /* drm_dp_aux_init() should have been called already; warn if not */ + WARN_ON_ONCE(!aux->ddc.algo); + + if (!aux->dev->of_node) + return 0; + + bus = of_get_child_by_name(aux->dev->of_node, "aux-bus"); + if (!bus) + return 0; + + for_each_available_child_of_node(bus, np) { + if (of_node_test_and_set_flag(np, OF_POPULATED)) + continue; + + aux_ep = kzalloc(sizeof(*aux_ep), GFP_KERNEL); + aux_ep->aux = aux; + + aux_ep->dev.parent = aux->dev; + aux_ep->dev.bus = &dp_aux_bus_type; + aux_ep->dev.type = &dp_aux_device_type_type; + aux_ep->dev.of_node = of_node_get(np); + dev_set_name(&aux_ep->dev, "aux-%s", dev_name(aux->dev)); + + ret = device_register(&aux_ep->dev); + if (ret) { + dev_err(aux->dev, "Failed to create AUX EP for %pOF: %d\n", np, ret); + of_node_clear_flag(np, OF_POPULATED); + of_node_put(np); + + /* + * As per docs of device_register(), call this instead + * of kfree() directly for error cases. + */ + put_device(&aux_ep->dev); + + /* + * Following in the footsteps of of_i2c_register_devices(), + * we won't fail the whole function here--we'll just + * continue registering any other devices we find. + */ + } + } + + of_node_put(bus); + + return 0; +} + +static void of_dp_aux_depopulate_ep_devices_void(void *data) +{ + of_dp_aux_depopulate_ep_devices(data); +} + +/** + * devm_of_dp_aux_populate_ep_devices() - devm wrapper for of_dp_aux_populate_ep_devices() + * @aux: The AUX channel whose devices we want to populate + * + * Handles freeing w/ devm on the device "aux->dev". + * + * Return: 0 if no error or negative error code. + */ +int devm_of_dp_aux_populate_ep_devices(struct drm_dp_aux *aux) +{ + int ret; + + ret = of_dp_aux_populate_ep_devices(aux); + if (ret) + return ret; + + return devm_add_action_or_reset(aux->dev, + of_dp_aux_depopulate_ep_devices_void, + aux); +} +EXPORT_SYMBOL_GPL(devm_of_dp_aux_populate_ep_devices); + +int __dp_aux_dp_driver_register(struct dp_aux_ep_driver *drv, struct module *owner) +{ + drv->driver.owner = owner; + drv->driver.bus = &dp_aux_bus_type; + + return driver_register(&drv->driver); + +} +EXPORT_SYMBOL_GPL(__dp_aux_dp_driver_register); + +void dp_aux_dp_driver_unregister(struct dp_aux_ep_driver *drv) +{ + driver_unregister(&drv->driver); +} +EXPORT_SYMBOL_GPL(dp_aux_dp_driver_unregister); + +static int __init dp_aux_bus_init(void) +{ + int ret; + + ret = bus_register(&dp_aux_bus_type); + if (ret) + return ret; + + return 0; +} + +static void __exit dp_aux_bus_exit(void) +{ + bus_unregister(&dp_aux_bus_type); +} + +subsys_initcall(dp_aux_bus_init); +module_exit(dp_aux_bus_exit); diff --git a/include/drm/drm_dp_aux_bus.h b/include/drm/drm_dp_aux_bus.h new file mode 100644 index 000000000000..4f19b20b1dd6 --- /dev/null +++ b/include/drm/drm_dp_aux_bus.h @@ -0,0 +1,57 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright 2021 Google Inc. + * + * The DP AUX bus is used for devices that are connected over a DisplayPort + * AUX bus. The devices on the far side of the bus are referred to as + * endpoints in this code. + */ + +#ifndef _DP_AUX_BUS_H_ +#define _DP_AUX_BUS_H_ + +#include <linux/device.h> +#include <linux/mod_devicetable.h> + +/** + * struct dp_aux_ep_device - Main dev structure for DP AUX endpoints + * + * This is used to instantiate devices that are connected via a DP AUX + * bus. Usually the device is a panel, but conceivable other devices could + * be hooked up there. + */ +struct dp_aux_ep_device { + /** @dev: The normal dev pointer */ + struct device dev; + /** @aux: Pointer to the aux bus */ + struct drm_dp_aux *aux; +}; + +struct dp_aux_ep_driver { + int (*probe)(struct dp_aux_ep_device *aux_ep); + void (*remove)(struct dp_aux_ep_device *aux_ep); + void (*shutdown)(struct dp_aux_ep_device *aux_ep); + struct device_driver driver; +}; + +static inline struct dp_aux_ep_device *to_dp_aux_ep_dev(struct device *dev) +{ + return container_of(dev, struct dp_aux_ep_device, dev); +} + +static inline struct dp_aux_ep_driver *to_dp_aux_ep_drv(struct device_driver *drv) +{ + return container_of(drv, struct dp_aux_ep_driver, driver); +} + +int of_dp_aux_populate_ep_devices(struct drm_dp_aux *aux); +void of_dp_aux_depopulate_ep_devices(struct drm_dp_aux *aux); +int devm_of_dp_aux_populate_ep_devices(struct drm_dp_aux *aux); + +#define dp_aux_dp_driver_register(aux_ep_drv) \ + __dp_aux_dp_driver_register(aux_ep_drv, THIS_MODULE) +int __dp_aux_dp_driver_register(struct dp_aux_ep_driver *aux_ep_drv, + struct module *owner); +void dp_aux_dp_driver_unregister(struct dp_aux_ep_driver *aux_ep_drv); + +#endif /* _DP_AUX_BUS_H_ */
On Mon, May 17, 2021 at 10:09 PM Douglas Anderson dianders@chromium.org wrote:
Historically "simple" eDP panels have been handled by panel-simple which is a basic platform_device. In the device tree, the panel node was at the top level and not connected to anything else.
Let's change it so that, instead, panels can be represented as being children of the "DP AUX bus". Essentially we're saying that the hierarchy that we're going to represent is the "control" connections between devices. The DP AUX bus is a control bus provided by an eDP controller (the parent) and consumed by a device like a panel (the child).
The primary incentive here is to cleanly provide the panel driver the ability to communicate over the AUX bus while handling lifetime issues properly. The panel driver may want the AUX bus for controlling the backlight or querying the panel's EDID.
The idea for this bus's design was hashed out over IRC [1].
[1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2...
Cc: Laurent Pinchart laurent.pinchart@ideasonboard.com Cc: Lyude Paul lyude@redhat.com Cc: Rajeev Nandan rajeevny@codeaurora.org Suggested-by: Laurent Pinchart laurent.pinchart@ideasonboard.com Signed-off-by: Douglas Anderson dianders@chromium.org
I like the concept and the general idea behind this, clean and helpful design. Acked-by: Linus Walleij linus.walleij@linaro.org
Yours, Linus Walleij
The panel-simple driver can already have devices instantiated as platform devices or MIPI DSI devices. Let's add a 3rd way to instantiate it: as DP AUX endpoint devices.
At the moment there is no benefit to instantiating it in this way, but: - In the next patch we'll give it access to the DDC channel via the DP AUX bus. - Possibly in the future we may use this channel to configure the backlight.
Signed-off-by: Douglas Anderson dianders@chromium.org ---
Changes in v7: - Patch to allow panel-simple to be DP AUX EP new for v7.
drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-simple.c | 52 +++++++++++++++++++++++++--- 2 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index ef87d92cdf49..b1ea86d9fdaf 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -82,6 +82,7 @@ config DRM_PANEL_SIMPLE depends on BACKLIGHT_CLASS_DEVICE depends on PM select VIDEOMODE_HELPERS + select DRM_DP_AUX_BUS help DRM panel driver for dumb panels that need at most a regulator and a GPIO to be powered up. Optionally a backlight can be attached so diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 21939d4352cf..d3b5ae22d939 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -36,6 +36,7 @@
#include <drm/drm_crtc.h> #include <drm/drm_device.h> +#include <drm/drm_dp_aux_bus.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_panel.h>
@@ -4957,6 +4958,38 @@ static struct mipi_dsi_driver panel_simple_dsi_driver = { .shutdown = panel_simple_dsi_shutdown, };
+static int panel_simple_dp_aux_ep_probe(struct dp_aux_ep_device *aux_ep) +{ + const struct of_device_id *id; + + id = of_match_node(platform_of_match, aux_ep->dev.of_node); + if (!id) + return -ENODEV; + + return panel_simple_probe(&aux_ep->dev, id->data); +} + +static void panel_simple_dp_aux_ep_remove(struct dp_aux_ep_device *aux_ep) +{ + panel_simple_remove(&aux_ep->dev); +} + +static void panel_simple_dp_aux_ep_shutdown(struct dp_aux_ep_device *aux_ep) +{ + panel_simple_shutdown(&aux_ep->dev); +} + +static struct dp_aux_ep_driver panel_simple_dp_aux_ep_driver = { + .driver = { + .name = "panel-simple-dp-aux", + .of_match_table = platform_of_match, /* Same as platform one! */ + .pm = &panel_simple_pm_ops, + }, + .probe = panel_simple_dp_aux_ep_probe, + .remove = panel_simple_dp_aux_ep_remove, + .shutdown = panel_simple_dp_aux_ep_shutdown, +}; + static int __init panel_simple_init(void) { int err; @@ -4965,15 +4998,25 @@ static int __init panel_simple_init(void) if (err < 0) return err;
+ err = dp_aux_dp_driver_register(&panel_simple_dp_aux_ep_driver); + if (err < 0) + goto err_did_platform_register; + if (IS_ENABLED(CONFIG_DRM_MIPI_DSI)) { err = mipi_dsi_driver_register(&panel_simple_dsi_driver); - if (err < 0) { - platform_driver_unregister(&panel_simple_platform_driver); - return err; - } + if (err < 0) + goto err_did_aux_ep_register; }
return 0; + +err_did_aux_ep_register: + dp_aux_dp_driver_unregister(&panel_simple_dp_aux_ep_driver); + +err_did_platform_register: + platform_driver_unregister(&panel_simple_platform_driver); + + return err; } module_init(panel_simple_init);
@@ -4982,6 +5025,7 @@ static void __exit panel_simple_exit(void) if (IS_ENABLED(CONFIG_DRM_MIPI_DSI)) mipi_dsi_driver_unregister(&panel_simple_dsi_driver);
+ dp_aux_dp_driver_unregister(&panel_simple_dp_aux_ep_driver); platform_driver_unregister(&panel_simple_platform_driver); } module_exit(panel_simple_exit);
If panel-simple is instantiated as a DP AUX bus endpoint then we have access to the DP AUX bus. Let's stash it in the panel-simple structure, leaving it NULL for the cases where the panel is instantiated in other ways.
If we happen to have access to the DP AUX bus and we weren't provided the ddc-i2c-bus in some other manner, let's use the DP AUX bus for it.
Signed-off-by: Douglas Anderson dianders@chromium.org ---
Changes in v7: - Patch using the DP AUX for DDC new for v7.
drivers/gpu/drm/panel/panel-simple.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index d3b5ae22d939..b09be6e5e147 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -37,6 +37,7 @@ #include <drm/drm_crtc.h> #include <drm/drm_device.h> #include <drm/drm_dp_aux_bus.h> +#include <drm/drm_dp_helper.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_panel.h>
@@ -186,6 +187,7 @@ struct panel_simple {
struct regulator *supply; struct i2c_adapter *ddc; + struct drm_dp_aux *aux;
struct gpio_desc *enable_gpio; struct gpio_desc *hpd_gpio; @@ -658,7 +660,8 @@ static void panel_simple_parse_panel_timing_node(struct device *dev, dev_err(dev, "Reject override mode: No display_timing found\n"); }
-static int panel_simple_probe(struct device *dev, const struct panel_desc *desc) +static int panel_simple_probe(struct device *dev, const struct panel_desc *desc, + struct drm_dp_aux *aux) { struct panel_simple *panel; struct display_timing dt; @@ -674,6 +677,7 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc) panel->enabled = false; panel->prepared_time = 0; panel->desc = desc; + panel->aux = aux;
panel->no_hpd = of_property_read_bool(dev->of_node, "no-hpd"); if (!panel->no_hpd) { @@ -708,6 +712,8 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc)
if (!panel->ddc) return -EPROBE_DEFER; + } else if (aux) { + panel->ddc = &aux->ddc; }
if (desc == &panel_dpi) { @@ -4633,7 +4639,7 @@ static int panel_simple_platform_probe(struct platform_device *pdev) if (!id) return -ENODEV;
- return panel_simple_probe(&pdev->dev, id->data); + return panel_simple_probe(&pdev->dev, id->data, NULL); }
static int panel_simple_platform_remove(struct platform_device *pdev) @@ -4913,7 +4919,7 @@ static int panel_simple_dsi_probe(struct mipi_dsi_device *dsi)
desc = id->data;
- err = panel_simple_probe(&dsi->dev, &desc->desc); + err = panel_simple_probe(&dsi->dev, &desc->desc, NULL); if (err < 0) return err;
@@ -4966,7 +4972,7 @@ static int panel_simple_dp_aux_ep_probe(struct dp_aux_ep_device *aux_ep) if (!id) return -ENODEV;
- return panel_simple_probe(&aux_ep->dev, id->data); + return panel_simple_probe(&aux_ep->dev, id->data, aux_ep->aux); }
static void panel_simple_dp_aux_ep_remove(struct dp_aux_ep_device *aux_ep)
On its own, this change looks a little strange and doesn't do too much useful. To understand why we're doing this we need to look forward to future patches where we're going to probe our panel using the new DP AUX bus. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus").
Let's think about the set of steps we'll want to happen when we have the DP AUX bus:
1. We'll create the DP AUX bus. 2. We'll populate the devices on the DP AUX bus (AKA our panel). 3. For setting up the bridge-related functions of ti-sn65dsi86 we'll need to get a reference to the panel.
If we do #1 - #3 in a single probe call things _mostly_ will work, but it won't be massively robust. Let's explore.
First let's think of the easy case of no -EPROBE_DEFER. In that case in step #2 when we populate the devices on the DP AUX bus it will actually try probing the panel right away. Since the panel probe doesn't defer then in step #3 we'll get a reference to the panel and we're golden.
Second, let's think of the case when the panel returns -EPROBE_DEFER. In that case step #2 won't synchronously create the panel (it'll just add the device to the defer list to do it later). Step #3 will fail to get the panel and the bridge sub-device will return -EPROBE_DEFER. We'll depopulate the DP AUX bus. Later we'll try the whole sequence again. Presumably the panel will eventually stop returning -EPROBE_DEFER and we'll go back to the first case where things were golden. So this case is OK too even if it's a bit ugly that we have to keep creating / deleting the AUX bus over and over.
So where is the problem? As I said, it's mostly about robustness. I don't believe that step #2 (creating the sub-devices) is really guaranteed to be synchronous. This is evidenced by the fact that it's allowed to "succeed" by just sticking the device on the deferred list. If anything about the process changes in Linux as a whole and step #2 just kicks off the probe of the DP AUX endpoints (our panel) in the background then we'd be in trouble because we might never get the panel in step #3.
Adding an extra sub-device means we just don't need to worry about it. We'll create the sub-device for the DP AUX bus and it won't go away until the whole ti-sn65dsi86 driver goes away. If the bridge sub-device defers (maybe because it can't find the panel) that won't depopulate the DP AUX bus and so we don't need to worry about it.
NOTE: there's a little bit of a trick here. Though the AUX channel can run without the MIPI-to-eDP bits of the code, the MIPI-to-eDP bits can't run without the AUX channel. We could come up a complicated signaling scheme (have the MIPI-to-eDP bits return EPROBE_DEFER for a while or wait on some sort of completion), but it seems simple enough to just not even bother creating the bridge device until the AUX channel probes. That's what we'll do.
Signed-off-by: Douglas Anderson dianders@chromium.org ---
Changes in v7: - Remove use of now-dropped drm_dp_aux_register_ddc() call. - Beefed up commit message in context of the DP AUX bus. - Set the proper sub-device "dev" pointer in the AUX structure.
Changes in v6: - Use new drm_dp_aux_register_ddc() calls.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 80 +++++++++++++++++++++++---- 1 file changed, 69 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index bb0a0e1c6341..42a55d13864b 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -116,6 +116,7 @@ * struct ti_sn65dsi86 - Platform data for ti-sn65dsi86 driver. * @bridge_aux: AUX-bus sub device for MIPI-to-eDP bridge functionality. * @gpio_aux: AUX-bus sub device for GPIO controller functionality. + * @aux_aux: AUX-bus sub device for eDP AUX channel functionality. * * @dev: Pointer to the top level (i2c) device. * @regmap: Regmap for accessing i2c. @@ -148,6 +149,7 @@ struct ti_sn65dsi86 { struct auxiliary_device bridge_aux; struct auxiliary_device gpio_aux; + struct auxiliary_device aux_aux;
struct device *dev; struct regmap *regmap; @@ -1331,11 +1333,6 @@ static int ti_sn_bridge_probe(struct auxiliary_device *adev, if (ret) return ret;
- pdata->aux.name = "ti-sn65dsi86-aux"; - pdata->aux.dev = pdata->dev; - pdata->aux.transfer = ti_sn_aux_transfer; - drm_dp_aux_init(&pdata->aux); - pdata->bridge.funcs = &ti_sn_bridge_funcs; pdata->bridge.of_node = np;
@@ -1430,6 +1427,53 @@ static int ti_sn65dsi86_add_aux_device(struct ti_sn65dsi86 *pdata, return ret; }
+static int ti_sn_aux_probe(struct auxiliary_device *adev, + const struct auxiliary_device_id *id) +{ + struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent); + int ret; + + /* + * We couldn't do this pre-probe because it would confuse pinctrl. + * It would have tried to grab the same pins that the main device had. + * Set it now so that we can put the proper (sub) device in the aux + * structure and it will have the right node. + */ + adev->dev.of_node = pdata->dev->of_node; + + pdata->aux.name = "ti-sn65dsi86-aux"; + pdata->aux.dev = &adev->dev; + pdata->aux.transfer = ti_sn_aux_transfer; + drm_dp_aux_init(&pdata->aux); + + /* + * The eDP to MIPI bridge parts don't work until the AUX channel is + * setup so we don't add it in the main driver probe, we add it now. + */ + ret = ti_sn65dsi86_add_aux_device(pdata, &pdata->bridge_aux, "bridge"); + + /* + * Clear of_node on any errors. Really this only matters if the error + * is -EPROBE_DEFER to avoid (again) keep pinctrl from claiming when + * it tries the probe again, but it shouldn't hurt on any error. + */ + if (ret) + adev->dev.of_node = NULL; + + return ret; +} + +static const struct auxiliary_device_id ti_sn_aux_id_table[] = { + { .name = "ti_sn65dsi86.aux", }, + {}, +}; + +static struct auxiliary_driver ti_sn_aux_driver = { + .name = "aux", + .probe = ti_sn_aux_probe, + .id_table = ti_sn_aux_id_table, +}; + static int ti_sn65dsi86_probe(struct i2c_client *client, const struct i2c_device_id *id) { @@ -1488,10 +1532,11 @@ static int ti_sn65dsi86_probe(struct i2c_client *client, * motiviation here is to solve the chicken-and-egg problem of probe * ordering. The bridge wants the panel to be there when it probes. * The panel wants its HPD GPIO (provided by sn65dsi86 on some boards) - * when it probes. There will soon be other devices (DDC I2C bus, PWM) - * that have the same problem. Having sub-devices allows the some sub - * devices to finish probing even if others return -EPROBE_DEFER and - * gets us around the problems. + * when it probes. The panel and maybe backlight might want the DDC + * bus. Soon the PWM provided by the bridge chip will have the same + * problem. Having sub-devices allows the some sub devices to finish + * probing even if others return -EPROBE_DEFER and gets us around the + * problems. */
if (IS_ENABLED(CONFIG_OF_GPIO)) { @@ -1500,7 +1545,13 @@ static int ti_sn65dsi86_probe(struct i2c_client *client, return ret; }
- return ti_sn65dsi86_add_aux_device(pdata, &pdata->bridge_aux, "bridge"); + /* + * NOTE: At the end of the AUX channel probe we'll add the aux device + * for the bridge. This is because the bridge can't be used until the + * AUX channel is there and this is a very simple solution to the + * dependency problem. + */ + return ti_sn65dsi86_add_aux_device(pdata, &pdata->aux_aux, "aux"); }
static struct i2c_device_id ti_sn65dsi86_id[] = { @@ -1537,12 +1588,18 @@ static int __init ti_sn65dsi86_init(void) if (ret) goto err_main_was_registered;
- ret = auxiliary_driver_register(&ti_sn_bridge_driver); + ret = auxiliary_driver_register(&ti_sn_aux_driver); if (ret) goto err_gpio_was_registered;
+ ret = auxiliary_driver_register(&ti_sn_bridge_driver); + if (ret) + goto err_aux_was_registered; + return 0;
+err_aux_was_registered: + auxiliary_driver_unregister(&ti_sn_aux_driver); err_gpio_was_registered: ti_sn_gpio_unregister(); err_main_was_registered: @@ -1555,6 +1612,7 @@ module_init(ti_sn65dsi86_init); static void __exit ti_sn65dsi86_exit(void) { auxiliary_driver_unregister(&ti_sn_bridge_driver); + auxiliary_driver_unregister(&ti_sn_aux_driver); ti_sn_gpio_unregister(); i2c_del_driver(&ti_sn65dsi86_driver); }
We want to provide our panel with access to the DP AUX channel. The way to do this is to let our panel be a child of ours using the fancy new DP AUX bus support.
Signed-off-by: Douglas Anderson dianders@chromium.org ---
Changes in v7: - Patch to support for DP AUX bus on ti-sn65dsi86 new for v7.
drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 13 +++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index d25e900f07ef..294d0bdd4cbe 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -280,6 +280,7 @@ config DRM_TI_SN65DSI86 select DRM_PANEL select DRM_MIPI_DSI select AUXILIARY_BUS + select DRM_DP_AUX_BUS help Texas Instruments SN65DSI86 DSI to eDP Bridge driver
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index 42a55d13864b..a59497f7e504 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -23,6 +23,7 @@ #include <drm/drm_atomic.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> +#include <drm/drm_dp_aux_bus.h> #include <drm/drm_dp_helper.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_of.h> @@ -1446,19 +1447,27 @@ static int ti_sn_aux_probe(struct auxiliary_device *adev, pdata->aux.transfer = ti_sn_aux_transfer; drm_dp_aux_init(&pdata->aux);
+ ret = devm_of_dp_aux_populate_ep_devices(&pdata->aux); + if (ret) + goto err; + /* * The eDP to MIPI bridge parts don't work until the AUX channel is * setup so we don't add it in the main driver probe, we add it now. */ ret = ti_sn65dsi86_add_aux_device(pdata, &pdata->bridge_aux, "bridge");
+ if (ret) + goto err; + + return 0; +err: /* * Clear of_node on any errors. Really this only matters if the error * is -EPROBE_DEFER to avoid (again) keep pinctrl from claiming when * it tries the probe again, but it shouldn't hurt on any error. */ - if (ret) - adev->dev.of_node = NULL; + adev->dev.of_node = NULL;
return ret; }
On Mon, May 17, 2021 at 10:09 PM Douglas Anderson dianders@chromium.org wrote:
We want to provide our panel with access to the DP AUX channel. The way to do this is to let our panel be a child of ours using the fancy new DP AUX bus support.
Signed-off-by: Douglas Anderson dianders@chromium.org
That's neat. Acked-by: Linus Walleij linus.walleij@linaro.org
Yours, Linus Walleij
For 7 and 8:
Reviewed-by: Lyude Paul lyude@redhat.com
On Mon, 2021-05-17 at 13:09 -0700, Douglas Anderson wrote:
We want to provide our panel with access to the DP AUX channel. The way to do this is to let our panel be a child of ours using the fancy new DP AUX bus support.
Signed-off-by: Douglas Anderson dianders@chromium.org
Changes in v7:
- Patch to support for DP AUX bus on ti-sn65dsi86 new for v7.
drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 13 +++++++++++-- 2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index d25e900f07ef..294d0bdd4cbe 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -280,6 +280,7 @@ config DRM_TI_SN65DSI86 select DRM_PANEL select DRM_MIPI_DSI select AUXILIARY_BUS + select DRM_DP_AUX_BUS help Texas Instruments SN65DSI86 DSI to eDP Bridge driver diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index 42a55d13864b..a59497f7e504 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -23,6 +23,7 @@ #include <drm/drm_atomic.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> +#include <drm/drm_dp_aux_bus.h> #include <drm/drm_dp_helper.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_of.h> @@ -1446,19 +1447,27 @@ static int ti_sn_aux_probe(struct auxiliary_device *adev, pdata->aux.transfer = ti_sn_aux_transfer; drm_dp_aux_init(&pdata->aux); + ret = devm_of_dp_aux_populate_ep_devices(&pdata->aux); + if (ret) + goto err;
/* * The eDP to MIPI bridge parts don't work until the AUX channel is * setup so we don't add it in the main driver probe, we add it now. */ ret = ti_sn65dsi86_add_aux_device(pdata, &pdata->bridge_aux, "bridge"); + if (ret) + goto err;
+ return 0; +err: /* * Clear of_node on any errors. Really this only matters if the error * is -EPROBE_DEFER to avoid (again) keep pinctrl from claiming when * it tries the probe again, but it shouldn't hurt on any error. */ - if (ret) - adev->dev.of_node = NULL; + adev->dev.of_node = NULL; return ret; }
This is really just a revert of commit 58074b08c04a ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.
The old code failed to read the EDID properly in a very important case: before the bridge's pre_enable() was called. The way things need to work: 1. Read the EDID. 2. Based on the EDID, decide on video settings and pixel clock. 3. Enable the bridge w/ the desired settings.
The way things were working: 1. Try to read the EDID but fail; fall back to hardcoded values. 2. Based on hardcoded values, decide on video settings and pixel clock. 3. Enable the bridge w/ the desired settings. 4. Try again to read the EDID, it works now! 5. Realize that the hardcoded settings weren't quite right. 6. Disable / reenable the bridge w/ the right settings.
The reasons for the failures were twofold: a) Since we never ran the bridge chip's pre-enable then we never set the bit to ignore HPD. This meant the bridge chip didn't even _try_ to go out on the bus and communicate with the panel. b) Even if we fixed things to ignore HPD, the EDID still wouldn't read if the panel wasn't on.
Instead of reverting the code, we could fix it to set the HPD bit and also power on the panel. However, it also works nicely to just let the panel code read the EDID. Now that we've split the driver up we can expose the DDC AUX channel bus to the panel node. The panel can take charge of reading the EDID.
NOTE: in order for things to work, anyone that needs to read the EDID will need to instantiate their panel using the new DP AUX bus (AKA by listing their panel under the "aux-bus" node of the bridge chip in the device tree).
In the future if we want to use the bridge chip to provide a full external DP port (which won't have a panel) then we will have to conditinally add EDID reading back in.
Suggested-by: Andrzej Hajda a.hajda@samsung.com Signed-off-by: Douglas Anderson dianders@chromium.org Reviewed-by: Bjorn Andersson bjorn.andersson@linaro.org ---
Changes in v7: - Adjusted commit message to talk about DP AUX bus.
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 ---------------------- 1 file changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c b/drivers/gpu/drm/bridge/ti-sn65dsi86.c index a59497f7e504..c9311e6e3799 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c @@ -126,7 +126,6 @@ * @connector: Our connector. * @host_node: Remote DSI node. * @dsi: Our MIPI DSI source. - * @edid: Detected EDID of eDP panel. * @refclk: Our reference clock. * @panel: Our panel. * @enable_gpio: The GPIO we toggle to enable the bridge. @@ -157,7 +156,6 @@ struct ti_sn65dsi86 { struct drm_dp_aux aux; struct drm_bridge bridge; struct drm_connector connector; - struct edid *edid; struct device_node *host_node; struct mipi_dsi_device *dsi; struct clk *refclk; @@ -406,24 +404,6 @@ connector_to_ti_sn65dsi86(struct drm_connector *connector) static int ti_sn_bridge_connector_get_modes(struct drm_connector *connector) { struct ti_sn65dsi86 *pdata = connector_to_ti_sn65dsi86(connector); - struct edid *edid = pdata->edid; - int num, ret; - - if (!edid) { - pm_runtime_get_sync(pdata->dev); - edid = pdata->edid = drm_get_edid(connector, &pdata->aux.ddc); - pm_runtime_put_autosuspend(pdata->dev); - } - - if (edid && drm_edid_is_valid(edid)) { - ret = drm_connector_update_edid_property(connector, edid); - if (!ret) { - num = drm_add_edid_modes(connector, edid); - if (num) - return num; - } - } - return drm_panel_get_modes(pdata->panel, connector); }
@@ -1354,8 +1334,6 @@ static void ti_sn_bridge_remove(struct auxiliary_device *adev) mipi_dsi_device_unregister(pdata->dsi); }
- kfree(pdata->edid); - drm_bridge_remove(&pdata->bridge);
of_node_put(pdata->host_node);
Putting the panel under the bridge chip (under the aux-bus node) allows the panel driver to get access to the DP AUX bus, enabling all sorts of fabulous new features.
While we're at this, get rid of a level of hierarchy for the panel node. It doesn't need "ports / port" and can just have a "port" child.
For Linux, this patch has a hard requirement on the patches adding DP AUX bus support to the ti-sn65dsi86 bridge chip driver. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus").
Signed-off-by: Douglas Anderson dianders@chromium.org ---
Changes in v7: - Panel now under bridge chip instead of getting a link to ddc-i2c
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 30 ++++++++++---------- 1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi index 24d293ef56d7..c76afd857b54 100644 --- a/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi @@ -260,21 +260,6 @@ max98357a: audio-codec-0 { #sound-dai-cells = <0>; };
- panel: panel { - /* Compatible will be filled in per-board */ - power-supply = <&pp3300_dx_edp>; - backlight = <&backlight>; - hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; - - ports { - port { - panel_in_edp: endpoint { - remote-endpoint = <&sn65dsi86_out>; - }; - }; - }; - }; - pwmleds { compatible = "pwm-leds"; keyboard_backlight: keyboard-backlight { @@ -674,6 +659,21 @@ sn65dsi86_out: endpoint { }; }; }; + + aux-bus { + panel: panel { + /* Compatible will be filled in per-board */ + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&sn65dsi86_out>; + }; + }; + }; + }; }; };
On Mon, May 17, 2021 at 10:09 PM Douglas Anderson dianders@chromium.org wrote:
Putting the panel under the bridge chip (under the aux-bus node) allows the panel driver to get access to the DP AUX bus, enabling all sorts of fabulous new features.
While we're at this, get rid of a level of hierarchy for the panel node. It doesn't need "ports / port" and can just have a "port" child.
For Linux, this patch has a hard requirement on the patches adding DP AUX bus support to the ti-sn65dsi86 bridge chip driver. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus").
Signed-off-by: Douglas Anderson dianders@chromium.org
This is really looking good. Acked-by: Linus Walleij linus.walleij@linaro.org
Yours, Linus Walleij
JFYI I haven't had a chance yet but I'm hoping to look at this this week
On Mon, 2021-05-17 at 13:08 -0700, Douglas Anderson wrote:
The primary goal of this series is to try to properly fix EDID reading for eDP panels using the ti-sn65dsi86 bridge.
Previously we had a patch that added EDID reading but it turned out not to work at bootup. This caused some extra churn at bootup as we tried (and failed) to read the EDID several times and also ended up forcing us to use the hardcoded mode at boot. With this patch series I believe EDID reading is reliable at boot now and we never use the hardcoded mode.
High level note: in this series the EDID reading is driven by the panel driver, not by the bridge chip driver. I believe this makes a reasonable amount of sense since the panel driver already _could_ drive reading the EDID if provided with the DDC bus and in future planned work we'll want to give the panel driver the DDC bus (to make decisions based on EDID) and the AUX bus (to control the backlight). There are also planned patches from Laurent to make ti-sn65dsi86 able to drive full DP monitors. In that case the bridge chip will still be in charge of reading the EDID, but it's not hard to make this dynamic.
This series is the logical successor to the 3-part series containing the patch ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk") [1].
This patch was tested against drm-misc-next commit 60a6b73dd821 ("drm/ingenic: Fix pixclock rate for 24-bit serial panels") on a sc7180-trogdor-lazor device.
At v7 now, this patch series grew a bit from v6 because it introduces the DP AUX bus.
Between v2 and v3, high-level view of changes:
- stop doing the EDID caching in the core.
Between v3 and v4, high-level view of changes:
- EDID reading is actually driven by the panel driver now. See above.
- Lots of chicken-and-egg problems solved w/ sub-devices.
Between v4 and v5, high-level view of changes.
- Some of the early patches landed, so dropped from series.
- New pm_runtime_disable() fix (fixed a patch that already landed).
- Added Bjorn's tags to most patches
- Fixed problems when building as a module.
- Reordered debugfs patch and fixed error handling there.
- Dropped last patch. I'm not convinced it's safe w/out more work.
Between v5 and v6, high-level view of changes:
- Added the patch ("drm/dp: Allow an early call to register DDC i2c
bus")
- Many patches had been landed, so only a few "controversial" ones
left.
Between v6 and v7, high-level view of changes:
- New AUX DP bus!
[1] https://lore.kernel.org/r/20210304155144.3.I60a7fb23ce4589006bc95c64ab8d15c7...
Changes in v7:
- pm_runtime_dont_use_autosuspend() fix new for v7.
- List hpd properties bindings patch new for v7.
- ti-sn65dsi86: Add aux-bus child patch new for v7.
- Patch introducing the DP AUX bus is new for v7.
- Patch to allow panel-simple to be DP AUX EP new for v7.
- Patch using the DP AUX for DDC new for v7.
- Remove use of now-dropped drm_dp_aux_register_ddc() call.
- Beefed up commit message in context of the DP AUX bus.
- Set the proper sub-device "dev" pointer in the AUX structure.
- Patch to support for DP AUX bus on ti-sn65dsi86 new for v7.
- Adjusted commit message to talk about DP AUX bus.
- Panel now under bridge chip instead of getting a link to ddc-i2c
Changes in v6:
- Use new drm_dp_aux_register_ddc() calls.
Douglas Anderson (10): drm/panel: panel-simple: Add missing pm_runtime_dont_use_autosuspend() calls dt-bindings: display: simple: List hpd properties in panel-simple dt-bindings: drm/bridge: ti-sn65dsi86: Add aux-bus child drm: Introduce the DP AUX bus drm/panel: panel-simple: Allow panel-simple be a DP AUX endpoint device drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC arm64: dts: qcom: sc7180-trogdor: Move panel under the bridge chip
.../bindings/display/bridge/ti,sn65dsi86.yaml | 22 +- .../bindings/display/panel/panel-simple.yaml | 2 + arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 30 +- drivers/gpu/drm/Kconfig | 5 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 111 ++++-- drivers/gpu/drm/drm_dp_aux_bus.c | 322 ++++++++++++++++++ drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-simple.c | 66 +++- include/drm/drm_dp_aux_bus.h | 57 ++++ 11 files changed, 563 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/drm_dp_aux_bus.c create mode 100644 include/drm/drm_dp_aux_bus.h
For patches 5, and 6:
Reviewed-by: Lyude Paul lyude@redhat.com
This week got really busy so I wasn't able to look at the rest of them, but next week is going to be a lot less busy so I should be able to look at them then
On Mon, 2021-05-17 at 13:08 -0700, Douglas Anderson wrote:
The primary goal of this series is to try to properly fix EDID reading for eDP panels using the ti-sn65dsi86 bridge.
Previously we had a patch that added EDID reading but it turned out not to work at bootup. This caused some extra churn at bootup as we tried (and failed) to read the EDID several times and also ended up forcing us to use the hardcoded mode at boot. With this patch series I believe EDID reading is reliable at boot now and we never use the hardcoded mode.
High level note: in this series the EDID reading is driven by the panel driver, not by the bridge chip driver. I believe this makes a reasonable amount of sense since the panel driver already _could_ drive reading the EDID if provided with the DDC bus and in future planned work we'll want to give the panel driver the DDC bus (to make decisions based on EDID) and the AUX bus (to control the backlight). There are also planned patches from Laurent to make ti-sn65dsi86 able to drive full DP monitors. In that case the bridge chip will still be in charge of reading the EDID, but it's not hard to make this dynamic.
This series is the logical successor to the 3-part series containing the patch ("drm/bridge: ti-sn65dsi86: Properly get the EDID, but only if refclk") [1].
This patch was tested against drm-misc-next commit 60a6b73dd821 ("drm/ingenic: Fix pixclock rate for 24-bit serial panels") on a sc7180-trogdor-lazor device.
At v7 now, this patch series grew a bit from v6 because it introduces the DP AUX bus.
Between v2 and v3, high-level view of changes:
- stop doing the EDID caching in the core.
Between v3 and v4, high-level view of changes:
- EDID reading is actually driven by the panel driver now. See above.
- Lots of chicken-and-egg problems solved w/ sub-devices.
Between v4 and v5, high-level view of changes.
- Some of the early patches landed, so dropped from series.
- New pm_runtime_disable() fix (fixed a patch that already landed).
- Added Bjorn's tags to most patches
- Fixed problems when building as a module.
- Reordered debugfs patch and fixed error handling there.
- Dropped last patch. I'm not convinced it's safe w/out more work.
Between v5 and v6, high-level view of changes:
- Added the patch ("drm/dp: Allow an early call to register DDC i2c
bus")
- Many patches had been landed, so only a few "controversial" ones
left.
Between v6 and v7, high-level view of changes:
- New AUX DP bus!
[1] https://lore.kernel.org/r/20210304155144.3.I60a7fb23ce4589006bc95c64ab8d15c7...
Changes in v7:
- pm_runtime_dont_use_autosuspend() fix new for v7.
- List hpd properties bindings patch new for v7.
- ti-sn65dsi86: Add aux-bus child patch new for v7.
- Patch introducing the DP AUX bus is new for v7.
- Patch to allow panel-simple to be DP AUX EP new for v7.
- Patch using the DP AUX for DDC new for v7.
- Remove use of now-dropped drm_dp_aux_register_ddc() call.
- Beefed up commit message in context of the DP AUX bus.
- Set the proper sub-device "dev" pointer in the AUX structure.
- Patch to support for DP AUX bus on ti-sn65dsi86 new for v7.
- Adjusted commit message to talk about DP AUX bus.
- Panel now under bridge chip instead of getting a link to ddc-i2c
Changes in v6:
- Use new drm_dp_aux_register_ddc() calls.
Douglas Anderson (10): drm/panel: panel-simple: Add missing pm_runtime_dont_use_autosuspend() calls dt-bindings: display: simple: List hpd properties in panel-simple dt-bindings: drm/bridge: ti-sn65dsi86: Add aux-bus child drm: Introduce the DP AUX bus drm/panel: panel-simple: Allow panel-simple be a DP AUX endpoint device drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC arm64: dts: qcom: sc7180-trogdor: Move panel under the bridge chip
.../bindings/display/bridge/ti,sn65dsi86.yaml | 22 +- .../bindings/display/panel/panel-simple.yaml | 2 + arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 30 +- drivers/gpu/drm/Kconfig | 5 + drivers/gpu/drm/Makefile | 2 + drivers/gpu/drm/bridge/Kconfig | 1 + drivers/gpu/drm/bridge/ti-sn65dsi86.c | 111 ++++-- drivers/gpu/drm/drm_dp_aux_bus.c | 322 ++++++++++++++++++ drivers/gpu/drm/panel/Kconfig | 1 + drivers/gpu/drm/panel/panel-simple.c | 66 +++- include/drm/drm_dp_aux_bus.h | 57 ++++ 11 files changed, 563 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/drm_dp_aux_bus.c create mode 100644 include/drm/drm_dp_aux_bus.h
Hi,
On Fri, May 21, 2021 at 4:07 PM Lyude Paul lyude@redhat.com wrote:
For patches 5, and 6:
Reviewed-by: Lyude Paul lyude@redhat.com
This week got really busy so I wasn't able to look at the rest of them, but next week is going to be a lot less busy so I should be able to look at them then
Thanks for your review on the two patches and for letting me know your plans. I know that I still need to spin the bindings patches with Rob Herring's feedback, but I won't do that until I know you're done reviewing just to avoid spamming everyone an extra time. Assuming no emergency comes around and slams me, I should be able to react/respond fairly quickly this week M-Th, though I'm taking Friday off.
BTW: if anyone reading this happens to have 10 minutes, I'd sorta like to get patch #1 in this series landed sooner rather than later and it's a dead-simple fix. If I see a review of that one, I'll apply it to drm-misc before sending out the next version of the series. ;-)
-Doug
dri-devel@lists.freedesktop.org