On Mon, Aug 9, 2021 at 4:20 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > Hi, > > On Mon, Aug 2, 2021 at 6:39 AM Rob Herring <robh@xxxxxxxxxx> 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@xxxxxxxxxxxxxx > > > > > > Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx> > > > --- > > > > > > 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@xxxxxxxxxx> Rob
