| Message ID | 20210730142537.v2.1.I1116e79d34035338a45c1fc7cdd14a097909c8e0@changeid (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | eDP: Support probing eDP panels dynamically instead of hardcoding | expand |
On Fri, 30 Jul 2021 14:26:20 -0700, Douglas Anderson wrote: > eDP panels generally contain almost everything needed to control them > in their EDID. This comes from their DP heritage were a computer needs > to be able to properly control pretty much any DP display that's > plugged into it. > > The one big issue with eDP panels and the reason that we need a panel > driver for them is that the power sequencing can be different per > panel. > > While it is true that eDP panel sequencing can be arbitrarily complex, > in practice it turns out that many eDP panels are compatible with just > some slightly different delays. See the contents of the bindings file > introduced in this patch for some details. > > The fact that eDP panels are 99% probable and that the power > sequencing (especially power up) can be compatible between many panels > means that there's a constant desire to plug multiple different panels > into the same board. This could be for second sourcing purposes or to > support multiple SKUs (maybe a 11" and a 13", for instance). > > As discussed [1], it should be OK to support this by adding two > properties to the device tree to specify the delays needed for > powering up the panel the first time. We'll create a new "edp-panel" > bindings file and define the two delays that might need to be > specified. NOTE: in the vast majority of the cases (HPD is hooked up > and isn't glitchy or is debounced) even these delays aren't needed. > > [1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- > > Changes in v2: > - No longer allow fallback to panel-simple. > - Add "-ms" suffix to delays. > > .../bindings/display/panel/panel-edp.yaml | 188 ++++++++++++++++++ > 1 file changed, 188 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/panel-edp.example.dt.yaml: bridge@2d: 'aux-bus' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml \ndoc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/1511822 This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Hi, On Mon, Aug 2, 2021 at 6:39 AM Rob Herring <robh@kernel.org> wrote: > > On Fri, 30 Jul 2021 14:26:20 -0700, Douglas Anderson wrote: > > eDP panels generally contain almost everything needed to control them > > in their EDID. This comes from their DP heritage were a computer needs > > to be able to properly control pretty much any DP display that's > > plugged into it. > > > > The one big issue with eDP panels and the reason that we need a panel > > driver for them is that the power sequencing can be different per > > panel. > > > > While it is true that eDP panel sequencing can be arbitrarily complex, > > in practice it turns out that many eDP panels are compatible with just > > some slightly different delays. See the contents of the bindings file > > introduced in this patch for some details. > > > > The fact that eDP panels are 99% probable and that the power > > sequencing (especially power up) can be compatible between many panels > > means that there's a constant desire to plug multiple different panels > > into the same board. This could be for second sourcing purposes or to > > support multiple SKUs (maybe a 11" and a 13", for instance). > > > > As discussed [1], it should be OK to support this by adding two > > properties to the device tree to specify the delays needed for > > powering up the panel the first time. We'll create a new "edp-panel" > > bindings file and define the two delays that might need to be > > specified. NOTE: in the vast majority of the cases (HPD is hooked up > > and isn't glitchy or is debounced) even these delays aren't needed. > > > > [1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > --- > > > > Changes in v2: > > - No longer allow fallback to panel-simple. > > - Add "-ms" suffix to delays. > > > > .../bindings/display/panel/panel-edp.yaml | 188 ++++++++++++++++++ > > 1 file changed, 188 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml > > > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/panel-edp.example.dt.yaml: bridge@2d: 'aux-bus' does not match any of the regexes: 'pinctrl-[0-9]+' > From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > \ndoc reference errors (make refcheckdocs): > > See https://patchwork.ozlabs.org/patch/1511822 > > This check can fail if there are any dependencies. The base for a patch > series is generally the most recent rc1. I think it's a dependency problem. No hits here: git grep aux-bus v5.14-rc5 -- Documentation/devicetree/bindings/ ...but I get hits against "linuxnext". Rob: I'm hoping that this can still be in your queue for review even with the bot warning. Thanks! :-) -Doug
On Mon, Aug 9, 2021 at 4:20 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Mon, Aug 2, 2021 at 6:39 AM Rob Herring <robh@kernel.org> wrote: > > > > On Fri, 30 Jul 2021 14:26:20 -0700, Douglas Anderson wrote: > > > eDP panels generally contain almost everything needed to control them > > > in their EDID. This comes from their DP heritage were a computer needs > > > to be able to properly control pretty much any DP display that's > > > plugged into it. > > > > > > The one big issue with eDP panels and the reason that we need a panel > > > driver for them is that the power sequencing can be different per > > > panel. > > > > > > While it is true that eDP panel sequencing can be arbitrarily complex, > > > in practice it turns out that many eDP panels are compatible with just > > > some slightly different delays. See the contents of the bindings file > > > introduced in this patch for some details. > > > > > > The fact that eDP panels are 99% probable and that the power > > > sequencing (especially power up) can be compatible between many panels > > > means that there's a constant desire to plug multiple different panels > > > into the same board. This could be for second sourcing purposes or to > > > support multiple SKUs (maybe a 11" and a 13", for instance). > > > > > > As discussed [1], it should be OK to support this by adding two > > > properties to the device tree to specify the delays needed for > > > powering up the panel the first time. We'll create a new "edp-panel" > > > bindings file and define the two delays that might need to be > > > specified. NOTE: in the vast majority of the cases (HPD is hooked up > > > and isn't glitchy or is debounced) even these delays aren't needed. > > > > > > [1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com > > > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > --- > > > > > > Changes in v2: > > > - No longer allow fallback to panel-simple. > > > - Add "-ms" suffix to delays. > > > > > > .../bindings/display/panel/panel-edp.yaml | 188 ++++++++++++++++++ > > > 1 file changed, 188 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml > > > > > > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > > > yamllint warnings/errors: > > > > dtschema/dtc warnings/errors: > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/panel-edp.example.dt.yaml: bridge@2d: 'aux-bus' does not match any of the regexes: 'pinctrl-[0-9]+' > > From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > \ndoc reference errors (make refcheckdocs): > > > > See https://patchwork.ozlabs.org/patch/1511822 > > > > This check can fail if there are any dependencies. The base for a patch > > series is generally the most recent rc1. > > I think it's a dependency problem. No hits here: > > git grep aux-bus v5.14-rc5 -- Documentation/devicetree/bindings/ > > ...but I get hits against "linuxnext". Am I supposed to figure them out? A simple "'aux-bus' warning is fixed by commit XYZ in foo tree' in the patch would help. Then I won't send the failure email (I do review them, so it's not your free testing service :) ). If you list the dependency then I'm not going to spam folks with failures. If you don't then I will so no one applies things without dependencies (as often they are not queued). > Rob: I'm hoping that this can > still be in your queue for review even with the bot warning. Sometimes, but you don't have to guess. You can look at patchwork. Though there is a latency between sending failure emails and my changing PW state. In any case, it looks good to me. Reviewed-by: Rob Herring <robh@kernel.org> Rob
diff --git a/Documentation/devicetree/bindings/display/panel/panel-edp.yaml b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml new file mode 100644 index 000000000000..6a621376ff86 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-edp.yaml @@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-edp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Probable (via DP AUX / EDID) eDP Panels with simple poweron sequences + +maintainers: + - Douglas Anderson <dianders@chromium.org> + +description: | + This binding file can be used to indicate that an eDP panel is connected + to a Embedded DisplayPort AUX bus (see display/dp-aux-bus.yaml) without + actually specifying exactly what panel is connected. This is useful for + the case that more than one different panel could be connected to the + board, either for second-sourcing purposes or to support multiple SKUs + with different LCDs that hook up to a common board. + + As per above, a requirement for using this binding is that the panel is + represented under the DP AUX bus. This means that we can use any + information provided by the DP AUX bus (including the EDID) to identify + the panel. We can use this to identify display size, resolution, and + timings among other things. + + One piece of information about eDP panels that is typically _not_ + provided anywhere on the DP AUX bus is the power sequencing timings. + This is the reason why, historically, we've always had to explicitly + list eDP panels. We solve that here with two tricks. The "worst case" + power on timings for any panels expected to be connected to a board are + specified in these bindings. Once we've powered on, it's expected that + the operating system will lookup the panel in a table (based on EDID + information) to figure out other power sequencing timings. + + eDP panels in general can have somewhat arbitrary power sequencing + requirements. However, even though it's arbitrary in general, the + vast majority of panel datasheets have a power sequence diagram that + looks the exactly the same as every other panel. Each panel datasheet + cares about different timings in this diagram but the fact that the + diagram is so similar means we can come up with a single driver to + handle it. + + These diagrams all look roughly like this, sometimes labeled with + slightly different numbers / lines but all pretty much the same + sequence. This is because much of this diagram comes straight from + the eDP Standard. + + __________________________________________________ + Vdd ___/: :\____ / + _/ : : \_____/ + :<T1>:<T2>: :<--T10-->:<T11>:<T12>: + : +-----------------------+---------+---------+ + eDP -----------+ Black video | Src vid | Blk vid + + Display : +-----------------------+---------+---------+ + : _______________________:_________:_________: + HPD :<T3>| : : | + ___________| : : |_____________ + : : : : + Sink +-----------------------:---------:---------+ + AUX CH -----------+ AUX Ch operational : : +------------- + +-----------------------:---------:---------+ + : : : : + :<T4>: :<T7>: : : + Src main +------+------+--------------+---------+ + lnk data----------------+LnkTrn| Idle |Valid vid data| Idle/off+------------- + +------+------+--------------+---------+ + : <T5> :<-T6->:<-T8->: : + :__:<T9>: + LED_EN | | + _____________________________________| |____________________________ + : : + __________:__:_ + PWM | : : | + __________________________| : : |__________________________ + : : : : + _____________:__________:__:_:______ + Bklight ____/: : : : : :\____ + power _______/ :<---T13---->: : : :<T16>: \______________ + (Vbl) :<T17>:<---------T14--------->: :<-T15->:<T18>: + + The above looks fairly complex but, as per above, each panel only cares + about a subset of those timings. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: edp-panel + + hpd-reliable-delay-ms: + description: + A fixed amount of time that must be waited after powering on the + panel's power-supply before the HPD signal is a reliable way to know + when the AUX channel is ready. This is useful for panels that glitch + the HPD at the start of power-on. This value is not needed if HPD is + always reliable for all panels that might be connected. + + hpd-absent-delay-ms: + description: + The panel specifies that HPD will be asserted this many milliseconds + from power on (timing T3 in the diagram above). If we have no way to + measure HPD then a fixed delay of this many milliseconds can be used. + This can also be used as a timeout when waiting for HPD. Does not + include the hpd-reliable-delay, so if hpd-reliable-delay was 80 ms + and hpd-absent-delay was 200 ms then we'd do a fixed 80 ms delay and + then we know HPD would assert in the next 120 ms. This value is not + needed if HPD hooked up, either through a GPIO in the panel node or + hooked up directly to the eDP controller. + + backlight: true + enable-gpios: true + port: true + power-supply: true + no-hpd: true + hpd-gpios: true + +additionalProperties: false + +required: + - compatible + - power-supply + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi86"; + reg = <0x2d>; + + interrupt-parent = <&tlmm>; + interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; + + enable-gpios = <&tlmm 102 GPIO_ACTIVE_HIGH>; + + vpll-supply = <&src_pp1800_s4a>; + vccio-supply = <&src_pp1800_s4a>; + vcca-supply = <&src_pp1200_l2a>; + vcc-supply = <&src_pp1200_l2a>; + + clocks = <&rpmhcc RPMH_LN_BB_CLK2>; + clock-names = "refclk"; + + no-hpd; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + sn65dsi86_out: endpoint { + remote-endpoint = <&panel_in_edp>; + }; + }; + }; + + aux-bus { + panel { + compatible = "edp-panel"; + power-supply = <&pp3300_dx_edp>; + backlight = <&backlight>; + hpd-gpios = <&sn65dsi86_bridge 2 GPIO_ACTIVE_HIGH>; + hpd-reliable-delay-ms = <15>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&sn65dsi86_out>; + }; + }; + }; + }; + }; + };
eDP panels generally contain almost everything needed to control them in their EDID. This comes from their DP heritage were a computer needs to be able to properly control pretty much any DP display that's plugged into it. The one big issue with eDP panels and the reason that we need a panel driver for them is that the power sequencing can be different per panel. While it is true that eDP panel sequencing can be arbitrarily complex, in practice it turns out that many eDP panels are compatible with just some slightly different delays. See the contents of the bindings file introduced in this patch for some details. The fact that eDP panels are 99% probable and that the power sequencing (especially power up) can be compatible between many panels means that there's a constant desire to plug multiple different panels into the same board. This could be for second sourcing purposes or to support multiple SKUs (maybe a 11" and a 13", for instance). As discussed [1], it should be OK to support this by adding two properties to the device tree to specify the delays needed for powering up the panel the first time. We'll create a new "edp-panel" bindings file and define the two delays that might need to be specified. NOTE: in the vast majority of the cases (HPD is hooked up and isn't glitchy or is debounced) even these delays aren't needed. [1] https://lore.kernel.org/r/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com Signed-off-by: Douglas Anderson <dianders@chromium.org> --- Changes in v2: - No longer allow fallback to panel-simple. - Add "-ms" suffix to delays. .../bindings/display/panel/panel-edp.yaml | 188 ++++++++++++++++++ 1 file changed, 188 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml