Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
Hi,
On Thu, Mar 25, 2021 at 5:09 PM Rob Herring wrote:
>
> On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote:
> > The sc7180-trogdor-pompom board might be attached to any number of a
> > pile of eDP panels. At the moment I'm told that the list might include:
> > - KD KD116N21-30NV-A010
> > - KD KD116N09-30NH-A016
> > - Starry 2081116HHD028001-51D
> > - Sharp LQ116M1JW10
> >
> > It should be noted that while the EDID programmed in the first 3
> > panels indicates that they should run with exactly the same timing (to
> > keep things simple), the 4th panel not only needs different timing but
> > has a different resolution.
> >
> > As is true in general with eDP panels, we can figure out which panel
> > we have and all the info needed to drive its pixel clock by reading
> > the EDID. However, we can do this only after we've powered the panel
> > on. Powering on the panels requires following the timing diagram in
> > each panel's datasheet which specifies delays between certain
> > actions. This means that, while we can be quite dynamic about handling
> > things we can't just totally skip out on describing the panel like we
> > could do if it was connected to an external-facing DP port.
>
> Is this a 'standard' eDP connector? AFAICT, there does seem to be
> such a thing.
To answer this one: there's not any "standard" physical plug as far as
I can tell. There's a connector on the board side for the LCD that has
a whole hodgepodge of signals on it. Maybe USB for a camera. Some
power signals. Maybe a PWM for a backlight. Maybe some DMIC signals.
eDP signals which might be anywhere from 1 to 4 lanes. HPD (which is
really a "panel ready" signal for eDP). The size / style of connector
and the exact set of signals (and their ordering) is board specific.
You then get a board-specific cable that splits things out. Some might
go to a camera/MIC sub board. Some go to the panel and hook onto a
panel-specific connector which has pin count and orderings defined by
that panel. :-P
> I've said in the past I'd be okay with a edp-connector
> node. If that needs just the "HPD absent delay" property, I think that
> would be okay. It's just a never ending stream of new properties with
> each new panel that I don't want to see.
Thinking about this we'd need at least one other property right now
which is an enable delay. Specifically at least one panel I've
supported recently lied about HPD for a short period after bootup.
Specifically see commit 667d73d72f31 ("drm: panel: simple: Delay HPD
checking on boe_nv133fhm_n61 for 15 ms"). ...and, of course, the
existing power supply / enable signals that "simple-panel" already
has.
Also: if we weren't going to add the other delay properties in the
device tree, we'd have to add the code right away that used the EDID
to set other delays. That wouldn't be the end of the world, but it
would be code to write.
One last thought to add: I've looked at ~10 panels specs recently.
Though they are all a little different from each other, I will say
that almost every one of them seems to have the exact same timing
diagram in it just with different numbers filled in. To me that backs
up the idea that you can/should do the power sequence with a fairly
standard (parameterized) driver. I can't link the datasheets I have
but searching for "edp panel datasheet" finds me this random
datasheet:
https://www.data-modul.com/sites/default/files/products/NV156QUM-N72_specification_12039472.pdf
See "8.0 POWER SEQUENCE" in that document. All the panels have a
nearly identical diagram with different numbers filled in. You can
kinda tell it was copied from some other panel since some numbers
(like T4) aren't even defined.
-Doug
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
Hi, On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding wrote: > > The point remains that unless we describe exactly which panel we're > dealing with, we ultimately have no way of properly quirking anything if > we ever have to. Just to clarify here: with my initial proposal we actually could still quirk things if we had to. If the quirk needed to be applied before power on we'd just have to apply the quirk to the whole board (which we'd have to do anyway). After the panel was powered on then we could read the EDID and apply a quirk based on what the EDID tells us, right? > Also, once we allow this kind of wildcard we can > suddenly get into a situation where people might want to reuse this on > something that's not at all a google-pompom board because the same > particular power sequence happens to work on on some other board. That's a legit concern. Of course, people could already do that with existing panels right? One would also hope that if they reused this they also used the "more specific to least specific" rule, so someone could reuse (without any problems) with: compatible = "some-other-company,some-other-board-panel", "google,pompom-panel" That doesn't seem like it would be terrible. > Similarly I can imagine a situation where we could now have the same > panel supported by multiple different wildcard compatible strings. How > is that supposed to be any cleaner than what we have now? I'm tempted to call this (same panel supported by multiple different compatible strings) a feature, actually. Specifically: Even if the exact same hardware is shipped with more than one board, it may have a different EDID programmed into it. From what I've seen the timings used on a panel may need to be adjusted based on the SoC used (and what clock rates it can provide / features of the underlying display driver), EMI concerns, and power consumption concerns. Once a different EDID is programmed in it then it sorta becomes a "different" panel, right? I think sometimes (?) panel vendors assign a slightly different model number per board, but I'm not sure. -Doug
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
Hi, On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote: > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote: > > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > > > wrote: > > > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > > > wrote: > > > > > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > > > > > The sc7180-trogdor-pompom board might be attached to any number > > > > > > > of a > > > > > > > pile of eDP panels. At the moment I'm told that the list might > > > > > > > include: > > > > > > > - KD KD116N21-30NV-A010 > > > > > > > - KD KD116N09-30NH-A016 > > > > > > > - Starry 2081116HHD028001-51D > > > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > > > > > It should be noted that while the EDID programmed in the first 3 > > > > > > > panels indicates that they should run with exactly the same > > > > > > > timing (to > > > > > > > keep things simple), the 4th panel not only needs different > > > > > > > timing but > > > > > > > has a different resolution. > > > > > > > > > > > > > > As is true in general with eDP panels, we can figure out which > > > > > > > panel > > > > > > > we have and all the info needed to drive its pixel clock by > > > > > > > reading > > > > > > > the EDID. However, we can do this only after we've powered the > > > > > > > panel > > > > > > > on. Powering on the panels requires following the timing diagram > > > > > > > in > > > > > > > each panel's datasheet which specifies delays between certain > > > > > > > actions. This means that, while we can be quite dynamic about > > > > > > > handling > > > > > > > things we can't just totally skip out on describing the panel > > > > > > > like we > > > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > > > > > While the different panels have slightly different delays, it's > > > > > > > possible to come up with a set of unified delays that will work > > > > > > > on all > > > > > > > the panels. From reading the datasheets: > > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > > > - HPD absent delay: 200 ms > > > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 > > > > > > > ms) > > > > > > > * Starry 2081116HHD028001-51D > > > > > > > - HPD absent delay: 100 ms > > > > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > > > > - Unprepare delay: 500 ms > > > > > > > * Sharp LQ116M1JW10 > > > > > > > - HPD absent delay: 200 ms > > > > > > > - Unprepare delay: 500 ms > > > > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > > > > > > > Unified: > > > > > > > - HPD absent delay: 200 ms > > > > > > > - Unprepare delay: 500 ms > > > > > > > - Enable delay: 200 ms > > > > > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on is > > > > > > > the > > > > > > > "HPD absent delay" since once the panel asserts HPD we can read > > > > > > > the > > > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > > > > > Let's create a definition of "a panel that can be attached to > > > > > > > pompom" > > > > > > > as a panel that provides a valid EDID and can work with the > > > > > > > standard > > > > > > > pompom power sequencing. If more panels are later attached to > > > > > > > pompom > > > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > > > > > One might ask why we can't just use a generic string here and > > > > > > > provide > > > > > > > the timings directly in the device tree file. As I understand it, > > > > > > > trying to describe generic power sequencing in the device tree is > > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a > > > > > > > mistake > > > > > > > that shouldn't be repeated. Specifying a power sequence per board > > > > > > > (or > > > > > > > per board class) feels like a reasonable compromise. We're not > > > > > > > trying > > > > > > > to define fully generic power sequence bindings but we can also > > > > > > > take > > > > > > > advantage of the semi-probable properties of the attached device. > > > > > > > > > > > > > > NOTE: I believe that past instances of supporting this type of > > > > > > > thing > > > > > > > have used the "white lie" approach. One representative panel was > > > > > > > listed in the device tree. The power sequencings of this > > > > > > > representative panel were OK to use across all panels that might > > > > > > > be > > > > > > > attached and other differences were handled by EDID. This patch > > > > > > > attempts to set a new precedent and avoid the need for the white > > > > > > > lie. > > > > > > > > > > > > > > Signed-off-by: Douglas Anderson > > > > > > > --- > > > > > > > > > > > > Sounds reasonable
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri, Mar 26, 2021 at 5:33 PM Rob Clark wrote: > > On Fri, Mar 26, 2021 at 4:48 PM Rob Herring wrote: > > > > On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote: > > > > > > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote: > > > > > > > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote: > > > > > > > > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > > > > > > > > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > > > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson > > > > > > > > > wrote: > > > > > > > > > > The sc7180-trogdor-pompom board might be attached to any > > > > > > > > > > number of a > > > > > > > > > > pile of eDP panels. At the moment I'm told that the list > > > > > > > > > > might include: > > > > > > > > > > - KD KD116N21-30NV-A010 > > > > > > > > > > - KD KD116N09-30NH-A016 > > > > > > > > > > - Starry 2081116HHD028001-51D > > > > > > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > > > > > > > > > > > It should be noted that while the EDID programmed in the > > > > > > > > > > first 3 > > > > > > > > > > panels indicates that they should run with exactly the same > > > > > > > > > > timing (to > > > > > > > > > > keep things simple), the 4th panel not only needs different > > > > > > > > > > timing but > > > > > > > > > > has a different resolution. > > > > > > > > > > > > > > > > > > > > As is true in general with eDP panels, we can figure out > > > > > > > > > > which panel > > > > > > > > > > we have and all the info needed to drive its pixel clock by > > > > > > > > > > reading > > > > > > > > > > the EDID. However, we can do this only after we've powered > > > > > > > > > > the panel > > > > > > > > > > on. Powering on the panels requires following the timing > > > > > > > > > > diagram in > > > > > > > > > > each panel's datasheet which specifies delays between > > > > > > > > > > certain > > > > > > > > > > actions. This means that, while we can be quite dynamic > > > > > > > > > > about handling > > > > > > > > > > things we can't just totally skip out on describing the > > > > > > > > > > panel like we > > > > > > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > > > > > > > > > > > While the different panels have slightly different delays, > > > > > > > > > > it's > > > > > > > > > > possible to come up with a set of unified delays that will > > > > > > > > > > work on all > > > > > > > > > > the panels. From reading the datasheets: > > > > > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might > > > > > > > > > > be 500 ms) > > > > > > > > > > * Starry 2081116HHD028001-51D > > > > > > > > > > - HPD absent delay: 100 ms > > > > > > > > > > - Enable delay: (link training done till enable BL): 200 > > > > > > > > > > ms > > > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > > > * Sharp LQ116M1JW10 > > > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > > > - Prepare to enable delay (power on till backlight): 100 > > > > > > > > > > ms > > > > > > > > > > > > > > > > > > > > Unified: > > > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > > > - Enable delay: 200 ms > > > > > > > > > > > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity > > > > > > > > > > on is the > > > > > > > > > > "HPD absent delay" since once the panel asserts HPD we can > > > > > > > > > > read the > > > > > > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > > > > > > > > > > > Let's create a definition of "a panel that can be attached > > > > > > > > > > to pompom" > > > > > > > > > > as a panel that provides a valid EDID and can work with the > > > > > > > > > > standard > > > > > > > > > > pompom power sequencing. If more panels are later attached > > > > > > > > > > to pompom > > > > > > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > > > > > > > > > > > One might ask why we can't just use a generic string here > > > > > > > > > > and provide > > > > > > > > > > the timings directly in the device tree file. As I > > > > > > > > > > understand it, > > > > > > > > > > trying to describe generic power sequencing in the device > > > > > > > > > > tree is > > > > > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a > > > > > > > > > > mistake > > > > > > > > > > that shouldn't be repeated. Specifying a power sequence per > > > > > > > > > > board (or > > > > > > > > > > per board class) feels like a reasonable
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri, Mar 26, 2021 at 4:48 PM Rob Herring wrote: > > On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote: > > > > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote: > > > > > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote: > > > > > > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > > > > > > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > > > > > wrote: > > > > > > > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > > > > > wrote: > > > > > > > > > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson > > > > > > > > wrote: > > > > > > > > > The sc7180-trogdor-pompom board might be attached to any > > > > > > > > > number of a > > > > > > > > > pile of eDP panels. At the moment I'm told that the list > > > > > > > > > might include: > > > > > > > > > - KD KD116N21-30NV-A010 > > > > > > > > > - KD KD116N09-30NH-A016 > > > > > > > > > - Starry 2081116HHD028001-51D > > > > > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > > > > > > > > > It should be noted that while the EDID programmed in the > > > > > > > > > first 3 > > > > > > > > > panels indicates that they should run with exactly the same > > > > > > > > > timing (to > > > > > > > > > keep things simple), the 4th panel not only needs different > > > > > > > > > timing but > > > > > > > > > has a different resolution. > > > > > > > > > > > > > > > > > > As is true in general with eDP panels, we can figure out > > > > > > > > > which panel > > > > > > > > > we have and all the info needed to drive its pixel clock by > > > > > > > > > reading > > > > > > > > > the EDID. However, we can do this only after we've powered > > > > > > > > > the panel > > > > > > > > > on. Powering on the panels requires following the timing > > > > > > > > > diagram in > > > > > > > > > each panel's datasheet which specifies delays between certain > > > > > > > > > actions. This means that, while we can be quite dynamic about > > > > > > > > > handling > > > > > > > > > things we can't just totally skip out on describing the panel > > > > > > > > > like we > > > > > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > > > > > > > > > While the different panels have slightly different delays, > > > > > > > > > it's > > > > > > > > > possible to come up with a set of unified delays that will > > > > > > > > > work on all > > > > > > > > > the panels. From reading the datasheets: > > > > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be > > > > > > > > > 500 ms) > > > > > > > > > * Starry 2081116HHD028001-51D > > > > > > > > > - HPD absent delay: 100 ms > > > > > > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > > * Sharp LQ116M1JW10 > > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > > > > > > > > > > > Unified: > > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > > - Enable delay: 200 ms > > > > > > > > > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on > > > > > > > > > is the > > > > > > > > > "HPD absent delay" since once the panel asserts HPD we can > > > > > > > > > read the > > > > > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > > > > > > > > > Let's create a definition of "a panel that can be attached to > > > > > > > > > pompom" > > > > > > > > > as a panel that provides a valid EDID and can work with the > > > > > > > > > standard > > > > > > > > > pompom power sequencing. If more panels are later attached to > > > > > > > > > pompom > > > > > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > > > > > > > > > One might ask why we can't just use a generic string here and > > > > > > > > > provide > > > > > > > > > the timings directly in the device tree file. As I understand > > > > > > > > > it, > > > > > > > > > trying to describe generic power sequencing in the device > > > > > > > > > tree is > > > > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a > > > > > > > > > mistake > > > > > > > > > that shouldn't be repeated. Specifying a power sequence per > > > > > > > > > board (or > > > > > > > > > per board class) feels like a reasonable compromise. We're > > > > > > > > > not trying > > > > > > > > > to define fully generic power sequence bindings but we can > > > > > > > > > also take > > > > > > > > > advantage of the semi-probable properties of the attached > > > > > > > > > device. > > > > > > > > > > > > > > > > > > NOTE: I believe that past
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri, Mar 26, 2021 at 4:13 PM Rob Clark wrote: > > On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote: > > > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote: > > > > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > > > > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > > > > wrote: > > > > > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > > > > > > The sc7180-trogdor-pompom board might be attached to any number > > > > > > > > of a > > > > > > > > pile of eDP panels. At the moment I'm told that the list might > > > > > > > > include: > > > > > > > > - KD KD116N21-30NV-A010 > > > > > > > > - KD KD116N09-30NH-A016 > > > > > > > > - Starry 2081116HHD028001-51D > > > > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > > > > > > > It should be noted that while the EDID programmed in the first 3 > > > > > > > > panels indicates that they should run with exactly the same > > > > > > > > timing (to > > > > > > > > keep things simple), the 4th panel not only needs different > > > > > > > > timing but > > > > > > > > has a different resolution. > > > > > > > > > > > > > > > > As is true in general with eDP panels, we can figure out which > > > > > > > > panel > > > > > > > > we have and all the info needed to drive its pixel clock by > > > > > > > > reading > > > > > > > > the EDID. However, we can do this only after we've powered the > > > > > > > > panel > > > > > > > > on. Powering on the panels requires following the timing > > > > > > > > diagram in > > > > > > > > each panel's datasheet which specifies delays between certain > > > > > > > > actions. This means that, while we can be quite dynamic about > > > > > > > > handling > > > > > > > > things we can't just totally skip out on describing the panel > > > > > > > > like we > > > > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > > > > > > > While the different panels have slightly different delays, it's > > > > > > > > possible to come up with a set of unified delays that will work > > > > > > > > on all > > > > > > > > the panels. From reading the datasheets: > > > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be > > > > > > > > 500 ms) > > > > > > > > * Starry 2081116HHD028001-51D > > > > > > > > - HPD absent delay: 100 ms > > > > > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > * Sharp LQ116M1JW10 > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > > > > > > > > > Unified: > > > > > > > > - HPD absent delay: 200 ms > > > > > > > > - Unprepare delay: 500 ms > > > > > > > > - Enable delay: 200 ms > > > > > > > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on > > > > > > > > is the > > > > > > > > "HPD absent delay" since once the panel asserts HPD we can read > > > > > > > > the > > > > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > > > > > > > Let's create a definition of "a panel that can be attached to > > > > > > > > pompom" > > > > > > > > as a panel that provides a valid EDID and can work with the > > > > > > > > standard > > > > > > > > pompom power sequencing. If more panels are later attached to > > > > > > > > pompom > > > > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > > > > > > > One might ask why we can't just use a generic string here and > > > > > > > > provide > > > > > > > > the timings directly in the device tree file. As I understand > > > > > > > > it, > > > > > > > > trying to describe generic power sequencing in the device tree > > > > > > > > is > > > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a > > > > > > > > mistake > > > > > > > > that shouldn't be repeated. Specifying a power sequence per > > > > > > > > board (or > > > > > > > > per board class) feels like a reasonable compromise. We're not > > > > > > > > trying > > > > > > > > to define fully generic power sequence bindings but we can also > > > > > > > > take > > > > > > > > advantage of the semi-probable properties of the attached > > > > > > > > device. > > > > > > > > > > > > > > > > NOTE: I believe that past instances of supporting this type of > > > > > > > > thing > > > > > > > > have used the "white lie" approach. One representative panel was > > > > > > > > listed in the device tree. The power sequencings of this > > > > > > > > representative panel were OK to use across all panels that > > > > > > > > might be
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri, Mar 26, 2021 at 12:48 PM Rob Herring wrote: > > On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote: > > > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > > > wrote: > > > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > > > wrote: > > > > > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > > > > > The sc7180-trogdor-pompom board might be attached to any number > > > > > > > of a > > > > > > > pile of eDP panels. At the moment I'm told that the list might > > > > > > > include: > > > > > > > - KD KD116N21-30NV-A010 > > > > > > > - KD KD116N09-30NH-A016 > > > > > > > - Starry 2081116HHD028001-51D > > > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > > > > > It should be noted that while the EDID programmed in the first 3 > > > > > > > panels indicates that they should run with exactly the same > > > > > > > timing (to > > > > > > > keep things simple), the 4th panel not only needs different > > > > > > > timing but > > > > > > > has a different resolution. > > > > > > > > > > > > > > As is true in general with eDP panels, we can figure out which > > > > > > > panel > > > > > > > we have and all the info needed to drive its pixel clock by > > > > > > > reading > > > > > > > the EDID. However, we can do this only after we've powered the > > > > > > > panel > > > > > > > on. Powering on the panels requires following the timing diagram > > > > > > > in > > > > > > > each panel's datasheet which specifies delays between certain > > > > > > > actions. This means that, while we can be quite dynamic about > > > > > > > handling > > > > > > > things we can't just totally skip out on describing the panel > > > > > > > like we > > > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > > > > > While the different panels have slightly different delays, it's > > > > > > > possible to come up with a set of unified delays that will work > > > > > > > on all > > > > > > > the panels. From reading the datasheets: > > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > > > - HPD absent delay: 200 ms > > > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 > > > > > > > ms) > > > > > > > * Starry 2081116HHD028001-51D > > > > > > > - HPD absent delay: 100 ms > > > > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > > > > - Unprepare delay: 500 ms > > > > > > > * Sharp LQ116M1JW10 > > > > > > > - HPD absent delay: 200 ms > > > > > > > - Unprepare delay: 500 ms > > > > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > > > > > > > Unified: > > > > > > > - HPD absent delay: 200 ms > > > > > > > - Unprepare delay: 500 ms > > > > > > > - Enable delay: 200 ms > > > > > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on is > > > > > > > the > > > > > > > "HPD absent delay" since once the panel asserts HPD we can read > > > > > > > the > > > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > > > > > Let's create a definition of "a panel that can be attached to > > > > > > > pompom" > > > > > > > as a panel that provides a valid EDID and can work with the > > > > > > > standard > > > > > > > pompom power sequencing. If more panels are later attached to > > > > > > > pompom > > > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > > > > > One might ask why we can't just use a generic string here and > > > > > > > provide > > > > > > > the timings directly in the device tree file. As I understand it, > > > > > > > trying to describe generic power sequencing in the device tree is > > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a > > > > > > > mistake > > > > > > > that shouldn't be repeated. Specifying a power sequence per board > > > > > > > (or > > > > > > > per board class) feels like a reasonable compromise. We're not > > > > > > > trying > > > > > > > to define fully generic power sequence bindings but we can also > > > > > > > take > > > > > > > advantage of the semi-probable properties of the attached device. > > > > > > > > > > > > > > NOTE: I believe that past instances of supporting this type of > > > > > > > thing > > > > > > > have used the "white lie" approach. One representative panel was > > > > > > > listed in the device tree. The power sequencings of this > > > > > > > representative panel were OK to use across all panels that might > > > > > > > be > > > > > > > attached and other differences were handled by EDID. This patch > > > > > > > attempts to set a new precedent and avoid the need for the white > > > > > > > lie. > > > > > > > > > > > > > > Signed-off-by: Douglas Anderson > > > > > > > --- > > > > > > > > > > > > Sounds reasonable to me
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri, Mar 26, 2021 at 9:20 AM Rob Clark wrote: > > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > > wrote: > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > > wrote: > > > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > > > > The sc7180-trogdor-pompom board might be attached to any number of a > > > > > > pile of eDP panels. At the moment I'm told that the list might > > > > > > include: > > > > > > - KD KD116N21-30NV-A010 > > > > > > - KD KD116N09-30NH-A016 > > > > > > - Starry 2081116HHD028001-51D > > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > > > It should be noted that while the EDID programmed in the first 3 > > > > > > panels indicates that they should run with exactly the same timing > > > > > > (to > > > > > > keep things simple), the 4th panel not only needs different timing > > > > > > but > > > > > > has a different resolution. > > > > > > > > > > > > As is true in general with eDP panels, we can figure out which panel > > > > > > we have and all the info needed to drive its pixel clock by reading > > > > > > the EDID. However, we can do this only after we've powered the panel > > > > > > on. Powering on the panels requires following the timing diagram in > > > > > > each panel's datasheet which specifies delays between certain > > > > > > actions. This means that, while we can be quite dynamic about > > > > > > handling > > > > > > things we can't just totally skip out on describing the panel like > > > > > > we > > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > > > While the different panels have slightly different delays, it's > > > > > > possible to come up with a set of unified delays that will work on > > > > > > all > > > > > > the panels. From reading the datasheets: > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 > > > > > > ms) > > > > > > * Starry 2081116HHD028001-51D > > > > > > - HPD absent delay: 100 ms > > > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > * Sharp LQ116M1JW10 > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > > > > > Unified: > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > - Enable delay: 200 ms > > > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on is the > > > > > > "HPD absent delay" since once the panel asserts HPD we can read the > > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > > > Let's create a definition of "a panel that can be attached to > > > > > > pompom" > > > > > > as a panel that provides a valid EDID and can work with the standard > > > > > > pompom power sequencing. If more panels are later attached to pompom > > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > > > One might ask why we can't just use a generic string here and > > > > > > provide > > > > > > the timings directly in the device tree file. As I understand it, > > > > > > trying to describe generic power sequencing in the device tree is > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a mistake > > > > > > that shouldn't be repeated. Specifying a power sequence per board > > > > > > (or > > > > > > per board class) feels like a reasonable compromise. We're not > > > > > > trying > > > > > > to define fully generic power sequence bindings but we can also take > > > > > > advantage of the semi-probable properties of the attached device. > > > > > > > > > > > > NOTE: I believe that past instances of supporting this type of thing > > > > > > have used the "white lie" approach. One representative panel was > > > > > > listed in the device tree. The power sequencings of this > > > > > > representative panel were OK to use across all panels that might be > > > > > > attached and other differences were handled by EDID. This patch > > > > > > attempts to set a new precedent and avoid the need for the white > > > > > > lie. > > > > > > > > > > > > Signed-off-by: Douglas Anderson > > > > > > --- > > > > > > > > > > Sounds reasonable to me if DT maintainers can live with this abstract > > > > > hardware definition. It's clearer than the 'white lie' approach. > > > > > > > > Yeah, it is a weird grey area between "discoverable" and "not > > > > discoverable".. but I favor DT reflecting reality as much as > > > > possible/feasible, so I think this is definity cleaner than "white > > > > lies" > > > > > > This is practically no different than the "white lie". I suppose you
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri 26 Mar 10:24 CDT 2021, Rob Clark wrote: > On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > > wrote: > > > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > > wrote: > > > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > > > > The sc7180-trogdor-pompom board might be attached to any number of a > > > > > > pile of eDP panels. At the moment I'm told that the list might > > > > > > include: > > > > > > - KD KD116N21-30NV-A010 > > > > > > - KD KD116N09-30NH-A016 > > > > > > - Starry 2081116HHD028001-51D > > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > > > It should be noted that while the EDID programmed in the first 3 > > > > > > panels indicates that they should run with exactly the same timing > > > > > > (to > > > > > > keep things simple), the 4th panel not only needs different timing > > > > > > but > > > > > > has a different resolution. > > > > > > > > > > > > As is true in general with eDP panels, we can figure out which panel > > > > > > we have and all the info needed to drive its pixel clock by reading > > > > > > the EDID. However, we can do this only after we've powered the panel > > > > > > on. Powering on the panels requires following the timing diagram in > > > > > > each panel's datasheet which specifies delays between certain > > > > > > actions. This means that, while we can be quite dynamic about > > > > > > handling > > > > > > things we can't just totally skip out on describing the panel like > > > > > > we > > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > > > While the different panels have slightly different delays, it's > > > > > > possible to come up with a set of unified delays that will work on > > > > > > all > > > > > > the panels. From reading the datasheets: > > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 > > > > > > ms) > > > > > > * Starry 2081116HHD028001-51D > > > > > > - HPD absent delay: 100 ms > > > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > * Sharp LQ116M1JW10 > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > > > > > Unified: > > > > > > - HPD absent delay: 200 ms > > > > > > - Unprepare delay: 500 ms > > > > > > - Enable delay: 200 ms > > > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on is the > > > > > > "HPD absent delay" since once the panel asserts HPD we can read the > > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > > > Let's create a definition of "a panel that can be attached to > > > > > > pompom" > > > > > > as a panel that provides a valid EDID and can work with the standard > > > > > > pompom power sequencing. If more panels are later attached to pompom > > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > > > One might ask why we can't just use a generic string here and > > > > > > provide > > > > > > the timings directly in the device tree file. As I understand it, > > > > > > trying to describe generic power sequencing in the device tree is > > > > > > frowned upon and the one instance (SD/MMC) is regarded as a mistake > > > > > > that shouldn't be repeated. Specifying a power sequence per board > > > > > > (or > > > > > > per board class) feels like a reasonable compromise. We're not > > > > > > trying > > > > > > to define fully generic power sequence bindings but we can also take > > > > > > advantage of the semi-probable properties of the attached device. > > > > > > > > > > > > NOTE: I believe that past instances of supporting this type of thing > > > > > > have used the "white lie" approach. One representative panel was > > > > > > listed in the device tree. The power sequencings of this > > > > > > representative panel were OK to use across all panels that might be > > > > > > attached and other differences were handled by EDID. This patch > > > > > > attempts to set a new precedent and avoid the need for the white > > > > > > lie. > > > > > > > > > > > > Signed-off-by: Douglas Anderson > > > > > > --- > > > > > > > > > > Sounds reasonable to me if DT maintainers can live with this abstract > > > > > hardware definition. It's clearer than the 'white lie' approach. > > > > > > > > Yeah, it is a weird grey area between "discoverable" and "not > > > > discoverable".. but I favor DT reflecting reality as much as > > > > possible/feasible, so I think this is definity cleaner than "white > > > > lies" > > > > > > This is practically no different than the "white lie". I suppose you > >
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri, Mar 26, 2021 at 8:18 AM Rob Clark wrote: > > On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding > wrote: > > > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke > > > wrote: > > > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > > > The sc7180-trogdor-pompom board might be attached to any number of a > > > > > pile of eDP panels. At the moment I'm told that the list might > > > > > include: > > > > > - KD KD116N21-30NV-A010 > > > > > - KD KD116N09-30NH-A016 > > > > > - Starry 2081116HHD028001-51D > > > > > - Sharp LQ116M1JW10 > > > > > > > > > > It should be noted that while the EDID programmed in the first 3 > > > > > panels indicates that they should run with exactly the same timing (to > > > > > keep things simple), the 4th panel not only needs different timing but > > > > > has a different resolution. > > > > > > > > > > As is true in general with eDP panels, we can figure out which panel > > > > > we have and all the info needed to drive its pixel clock by reading > > > > > the EDID. However, we can do this only after we've powered the panel > > > > > on. Powering on the panels requires following the timing diagram in > > > > > each panel's datasheet which specifies delays between certain > > > > > actions. This means that, while we can be quite dynamic about handling > > > > > things we can't just totally skip out on describing the panel like we > > > > > could do if it was connected to an external-facing DP port. > > > > > > > > > > While the different panels have slightly different delays, it's > > > > > possible to come up with a set of unified delays that will work on all > > > > > the panels. From reading the datasheets: > > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > > - HPD absent delay: 200 ms > > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 ms) > > > > > * Starry 2081116HHD028001-51D > > > > > - HPD absent delay: 100 ms > > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > > - Unprepare delay: 500 ms > > > > > * Sharp LQ116M1JW10 > > > > > - HPD absent delay: 200 ms > > > > > - Unprepare delay: 500 ms > > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > > > Unified: > > > > > - HPD absent delay: 200 ms > > > > > - Unprepare delay: 500 ms > > > > > - Enable delay: 200 ms > > > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on is the > > > > > "HPD absent delay" since once the panel asserts HPD we can read the > > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > > > Let's create a definition of "a panel that can be attached to pompom" > > > > > as a panel that provides a valid EDID and can work with the standard > > > > > pompom power sequencing. If more panels are later attached to pompom > > > > > then it's fine as long as they work in a compatible way. > > > > > > > > > > One might ask why we can't just use a generic string here and provide > > > > > the timings directly in the device tree file. As I understand it, > > > > > trying to describe generic power sequencing in the device tree is > > > > > frowned upon and the one instance (SD/MMC) is regarded as a mistake > > > > > that shouldn't be repeated. Specifying a power sequence per board (or > > > > > per board class) feels like a reasonable compromise. We're not trying > > > > > to define fully generic power sequence bindings but we can also take > > > > > advantage of the semi-probable properties of the attached device. > > > > > > > > > > NOTE: I believe that past instances of supporting this type of thing > > > > > have used the "white lie" approach. One representative panel was > > > > > listed in the device tree. The power sequencings of this > > > > > representative panel were OK to use across all panels that might be > > > > > attached and other differences were handled by EDID. This patch > > > > > attempts to set a new precedent and avoid the need for the white lie. > > > > > > > > > > Signed-off-by: Douglas Anderson > > > > > --- > > > > > > > > Sounds reasonable to me if DT maintainers can live with this abstract > > > > hardware definition. It's clearer than the 'white lie' approach. > > > > > > Yeah, it is a weird grey area between "discoverable" and "not > > > discoverable".. but I favor DT reflecting reality as much as > > > possible/feasible, so I think this is definity cleaner than "white > > > lies" > > > > This is practically no different than the "white lie". I suppose you > > could perhaps call it "more honest", if you want. > > > > The point remains that unless we describe exactly which panel we're > > dealing with, we ultimately have no way of properly quirking anything if > > we ever have to. Also, once we allow this kind of wildcard we can > > suddenly get into a situation where people might want to reuse this on > > something that's
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Fri, Mar 26, 2021 at 5:38 AM Thierry Reding wrote: > > On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke wrote: > > > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > > The sc7180-trogdor-pompom board might be attached to any number of a > > > > pile of eDP panels. At the moment I'm told that the list might include: > > > > - KD KD116N21-30NV-A010 > > > > - KD KD116N09-30NH-A016 > > > > - Starry 2081116HHD028001-51D > > > > - Sharp LQ116M1JW10 > > > > > > > > It should be noted that while the EDID programmed in the first 3 > > > > panels indicates that they should run with exactly the same timing (to > > > > keep things simple), the 4th panel not only needs different timing but > > > > has a different resolution. > > > > > > > > As is true in general with eDP panels, we can figure out which panel > > > > we have and all the info needed to drive its pixel clock by reading > > > > the EDID. However, we can do this only after we've powered the panel > > > > on. Powering on the panels requires following the timing diagram in > > > > each panel's datasheet which specifies delays between certain > > > > actions. This means that, while we can be quite dynamic about handling > > > > things we can't just totally skip out on describing the panel like we > > > > could do if it was connected to an external-facing DP port. > > > > > > > > While the different panels have slightly different delays, it's > > > > possible to come up with a set of unified delays that will work on all > > > > the panels. From reading the datasheets: > > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > > - HPD absent delay: 200 ms > > > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 ms) > > > > * Starry 2081116HHD028001-51D > > > > - HPD absent delay: 100 ms > > > > - Enable delay: (link training done till enable BL): 200 ms > > > > - Unprepare delay: 500 ms > > > > * Sharp LQ116M1JW10 > > > > - HPD absent delay: 200 ms > > > > - Unprepare delay: 500 ms > > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > > > Unified: > > > > - HPD absent delay: 200 ms > > > > - Unprepare delay: 500 ms > > > > - Enable delay: 200 ms > > > > > > > > NOTE: in theory the only thing that we _really_ need unity on is the > > > > "HPD absent delay" since once the panel asserts HPD we can read the > > > > EDID and could make per-panel decisions if we wanted. > > > > > > > > Let's create a definition of "a panel that can be attached to pompom" > > > > as a panel that provides a valid EDID and can work with the standard > > > > pompom power sequencing. If more panels are later attached to pompom > > > > then it's fine as long as they work in a compatible way. > > > > > > > > One might ask why we can't just use a generic string here and provide > > > > the timings directly in the device tree file. As I understand it, > > > > trying to describe generic power sequencing in the device tree is > > > > frowned upon and the one instance (SD/MMC) is regarded as a mistake > > > > that shouldn't be repeated. Specifying a power sequence per board (or > > > > per board class) feels like a reasonable compromise. We're not trying > > > > to define fully generic power sequence bindings but we can also take > > > > advantage of the semi-probable properties of the attached device. > > > > > > > > NOTE: I believe that past instances of supporting this type of thing > > > > have used the "white lie" approach. One representative panel was > > > > listed in the device tree. The power sequencings of this > > > > representative panel were OK to use across all panels that might be > > > > attached and other differences were handled by EDID. This patch > > > > attempts to set a new precedent and avoid the need for the white lie. > > > > > > > > Signed-off-by: Douglas Anderson > > > > --- > > > > > > Sounds reasonable to me if DT maintainers can live with this abstract > > > hardware definition. It's clearer than the 'white lie' approach. > > > > Yeah, it is a weird grey area between "discoverable" and "not > > discoverable".. but I favor DT reflecting reality as much as > > possible/feasible, so I think this is definity cleaner than "white > > lies" > > This is practically no different than the "white lie". I suppose you > could perhaps call it "more honest", if you want. > > The point remains that unless we describe exactly which panel we're > dealing with, we ultimately have no way of properly quirking anything if > we ever have to. Also, once we allow this kind of wildcard we can > suddenly get into a situation where people might want to reuse this on > something that's not at all a google-pompom board because the same > particular power sequence happens to work on on some other board. > > Similarly I can imagine a situation where we could now have the same > panel supported by multiple different wildcard compatible
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Wed, Mar 17, 2021 at 06:53:04PM -0700, Rob Clark wrote: > On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke wrote: > > > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > > The sc7180-trogdor-pompom board might be attached to any number of a > > > pile of eDP panels. At the moment I'm told that the list might include: > > > - KD KD116N21-30NV-A010 > > > - KD KD116N09-30NH-A016 > > > - Starry 2081116HHD028001-51D > > > - Sharp LQ116M1JW10 > > > > > > It should be noted that while the EDID programmed in the first 3 > > > panels indicates that they should run with exactly the same timing (to > > > keep things simple), the 4th panel not only needs different timing but > > > has a different resolution. > > > > > > As is true in general with eDP panels, we can figure out which panel > > > we have and all the info needed to drive its pixel clock by reading > > > the EDID. However, we can do this only after we've powered the panel > > > on. Powering on the panels requires following the timing diagram in > > > each panel's datasheet which specifies delays between certain > > > actions. This means that, while we can be quite dynamic about handling > > > things we can't just totally skip out on describing the panel like we > > > could do if it was connected to an external-facing DP port. > > > > > > While the different panels have slightly different delays, it's > > > possible to come up with a set of unified delays that will work on all > > > the panels. From reading the datasheets: > > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > > - HPD absent delay: 200 ms > > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 ms) > > > * Starry 2081116HHD028001-51D > > > - HPD absent delay: 100 ms > > > - Enable delay: (link training done till enable BL): 200 ms > > > - Unprepare delay: 500 ms > > > * Sharp LQ116M1JW10 > > > - HPD absent delay: 200 ms > > > - Unprepare delay: 500 ms > > > - Prepare to enable delay (power on till backlight): 100 ms > > > > > > Unified: > > > - HPD absent delay: 200 ms > > > - Unprepare delay: 500 ms > > > - Enable delay: 200 ms > > > > > > NOTE: in theory the only thing that we _really_ need unity on is the > > > "HPD absent delay" since once the panel asserts HPD we can read the > > > EDID and could make per-panel decisions if we wanted. > > > > > > Let's create a definition of "a panel that can be attached to pompom" > > > as a panel that provides a valid EDID and can work with the standard > > > pompom power sequencing. If more panels are later attached to pompom > > > then it's fine as long as they work in a compatible way. > > > > > > One might ask why we can't just use a generic string here and provide > > > the timings directly in the device tree file. As I understand it, > > > trying to describe generic power sequencing in the device tree is > > > frowned upon and the one instance (SD/MMC) is regarded as a mistake > > > that shouldn't be repeated. Specifying a power sequence per board (or > > > per board class) feels like a reasonable compromise. We're not trying > > > to define fully generic power sequence bindings but we can also take > > > advantage of the semi-probable properties of the attached device. > > > > > > NOTE: I believe that past instances of supporting this type of thing > > > have used the "white lie" approach. One representative panel was > > > listed in the device tree. The power sequencings of this > > > representative panel were OK to use across all panels that might be > > > attached and other differences were handled by EDID. This patch > > > attempts to set a new precedent and avoid the need for the white lie. > > > > > > Signed-off-by: Douglas Anderson > > > --- > > > > Sounds reasonable to me if DT maintainers can live with this abstract > > hardware definition. It's clearer than the 'white lie' approach. > > Yeah, it is a weird grey area between "discoverable" and "not > discoverable".. but I favor DT reflecting reality as much as > possible/feasible, so I think this is definity cleaner than "white > lies" This is practically no different than the "white lie". I suppose you could perhaps call it "more honest", if you want. The point remains that unless we describe exactly which panel we're dealing with, we ultimately have no way of properly quirking anything if we ever have to. Also, once we allow this kind of wildcard we can suddenly get into a situation where people might want to reuse this on something that's not at all a google-pompom board because the same particular power sequence happens to work on on some other board. Similarly I can imagine a situation where we could now have the same panel supported by multiple different wildcard compatible strings. How is that supposed to be any cleaner than what we have now? And I still keep wondering why bootloaders can't be taught about these kinds of things. We have in the past discussed various solutions where the bootloader could detect
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > The sc7180-trogdor-pompom board might be attached to any number of a > pile of eDP panels. At the moment I'm told that the list might include: > - KD KD116N21-30NV-A010 > - KD KD116N09-30NH-A016 > - Starry 2081116HHD028001-51D > - Sharp LQ116M1JW10 > > It should be noted that while the EDID programmed in the first 3 > panels indicates that they should run with exactly the same timing (to > keep things simple), the 4th panel not only needs different timing but > has a different resolution. > > As is true in general with eDP panels, we can figure out which panel > we have and all the info needed to drive its pixel clock by reading > the EDID. However, we can do this only after we've powered the panel > on. Powering on the panels requires following the timing diagram in > each panel's datasheet which specifies delays between certain > actions. This means that, while we can be quite dynamic about handling > things we can't just totally skip out on describing the panel like we > could do if it was connected to an external-facing DP port. Is this a 'standard' eDP connector? AFAICT, there does seem to be such a thing. I've said in the past I'd be okay with a edp-connector node. If that needs just the "HPD absent delay" property, I think that would be okay. It's just a never ending stream of new properties with each new panel that I don't want to see. Rob
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Wed, Mar 17, 2021 at 4:27 PM Matthias Kaehlcke wrote: > > On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > > The sc7180-trogdor-pompom board might be attached to any number of a > > pile of eDP panels. At the moment I'm told that the list might include: > > - KD KD116N21-30NV-A010 > > - KD KD116N09-30NH-A016 > > - Starry 2081116HHD028001-51D > > - Sharp LQ116M1JW10 > > > > It should be noted that while the EDID programmed in the first 3 > > panels indicates that they should run with exactly the same timing (to > > keep things simple), the 4th panel not only needs different timing but > > has a different resolution. > > > > As is true in general with eDP panels, we can figure out which panel > > we have and all the info needed to drive its pixel clock by reading > > the EDID. However, we can do this only after we've powered the panel > > on. Powering on the panels requires following the timing diagram in > > each panel's datasheet which specifies delays between certain > > actions. This means that, while we can be quite dynamic about handling > > things we can't just totally skip out on describing the panel like we > > could do if it was connected to an external-facing DP port. > > > > While the different panels have slightly different delays, it's > > possible to come up with a set of unified delays that will work on all > > the panels. From reading the datasheets: > > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > > - HPD absent delay: 200 ms > > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 ms) > > * Starry 2081116HHD028001-51D > > - HPD absent delay: 100 ms > > - Enable delay: (link training done till enable BL): 200 ms > > - Unprepare delay: 500 ms > > * Sharp LQ116M1JW10 > > - HPD absent delay: 200 ms > > - Unprepare delay: 500 ms > > - Prepare to enable delay (power on till backlight): 100 ms > > > > Unified: > > - HPD absent delay: 200 ms > > - Unprepare delay: 500 ms > > - Enable delay: 200 ms > > > > NOTE: in theory the only thing that we _really_ need unity on is the > > "HPD absent delay" since once the panel asserts HPD we can read the > > EDID and could make per-panel decisions if we wanted. > > > > Let's create a definition of "a panel that can be attached to pompom" > > as a panel that provides a valid EDID and can work with the standard > > pompom power sequencing. If more panels are later attached to pompom > > then it's fine as long as they work in a compatible way. > > > > One might ask why we can't just use a generic string here and provide > > the timings directly in the device tree file. As I understand it, > > trying to describe generic power sequencing in the device tree is > > frowned upon and the one instance (SD/MMC) is regarded as a mistake > > that shouldn't be repeated. Specifying a power sequence per board (or > > per board class) feels like a reasonable compromise. We're not trying > > to define fully generic power sequence bindings but we can also take > > advantage of the semi-probable properties of the attached device. > > > > NOTE: I believe that past instances of supporting this type of thing > > have used the "white lie" approach. One representative panel was > > listed in the device tree. The power sequencings of this > > representative panel were OK to use across all panels that might be > > attached and other differences were handled by EDID. This patch > > attempts to set a new precedent and avoid the need for the white lie. > > > > Signed-off-by: Douglas Anderson > > --- > > Sounds reasonable to me if DT maintainers can live with this abstract > hardware definition. It's clearer than the 'white lie' approach. Yeah, it is a weird grey area between "discoverable" and "not discoverable".. but I favor DT reflecting reality as much as possible/feasible, so I think this is definity cleaner than "white lies" Reviewed-by: Rob Clark > It's then up to the vendor/manufacturer to ensure to only ship devices > with panels that have compatible timings. > > > .../devicetree/bindings/display/panel/panel-simple.yaml | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > index 62b0d54d87b7..9807dbc1cceb 100644 > > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > > @@ -140,6 +140,10 @@ properties: > >- giantplus,gpg48273qs5 > > # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel > >- giantplus,gpm940b0 > > +# A panel connected to a google,pompom board. Panel is guaranteed > > to > > +# confirm to google,pompom-panel power sequencing requirements and > > then > > s/confirm/conform/ ? > > > +# the specific panel will be probed via EDID. > > + - google,pompom-panel > > # HannStar Display Corp.
Re: [RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
On Tue, Mar 16, 2021 at 02:08:19PM -0700, Douglas Anderson wrote: > The sc7180-trogdor-pompom board might be attached to any number of a > pile of eDP panels. At the moment I'm told that the list might include: > - KD KD116N21-30NV-A010 > - KD KD116N09-30NH-A016 > - Starry 2081116HHD028001-51D > - Sharp LQ116M1JW10 > > It should be noted that while the EDID programmed in the first 3 > panels indicates that they should run with exactly the same timing (to > keep things simple), the 4th panel not only needs different timing but > has a different resolution. > > As is true in general with eDP panels, we can figure out which panel > we have and all the info needed to drive its pixel clock by reading > the EDID. However, we can do this only after we've powered the panel > on. Powering on the panels requires following the timing diagram in > each panel's datasheet which specifies delays between certain > actions. This means that, while we can be quite dynamic about handling > things we can't just totally skip out on describing the panel like we > could do if it was connected to an external-facing DP port. > > While the different panels have slightly different delays, it's > possible to come up with a set of unified delays that will work on all > the panels. From reading the datasheets: > * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 > - HPD absent delay: 200 ms > - Unprepare delay: 150 ms (datasheet is confusing, might be 500 ms) > * Starry 2081116HHD028001-51D > - HPD absent delay: 100 ms > - Enable delay: (link training done till enable BL): 200 ms > - Unprepare delay: 500 ms > * Sharp LQ116M1JW10 > - HPD absent delay: 200 ms > - Unprepare delay: 500 ms > - Prepare to enable delay (power on till backlight): 100 ms > > Unified: > - HPD absent delay: 200 ms > - Unprepare delay: 500 ms > - Enable delay: 200 ms > > NOTE: in theory the only thing that we _really_ need unity on is the > "HPD absent delay" since once the panel asserts HPD we can read the > EDID and could make per-panel decisions if we wanted. > > Let's create a definition of "a panel that can be attached to pompom" > as a panel that provides a valid EDID and can work with the standard > pompom power sequencing. If more panels are later attached to pompom > then it's fine as long as they work in a compatible way. > > One might ask why we can't just use a generic string here and provide > the timings directly in the device tree file. As I understand it, > trying to describe generic power sequencing in the device tree is > frowned upon and the one instance (SD/MMC) is regarded as a mistake > that shouldn't be repeated. Specifying a power sequence per board (or > per board class) feels like a reasonable compromise. We're not trying > to define fully generic power sequence bindings but we can also take > advantage of the semi-probable properties of the attached device. > > NOTE: I believe that past instances of supporting this type of thing > have used the "white lie" approach. One representative panel was > listed in the device tree. The power sequencings of this > representative panel were OK to use across all panels that might be > attached and other differences were handled by EDID. This patch > attempts to set a new precedent and avoid the need for the white lie. > > Signed-off-by: Douglas Anderson > --- Sounds reasonable to me if DT maintainers can live with this abstract hardware definition. It's clearer than the 'white lie' approach. It's then up to the vendor/manufacturer to ensure to only ship devices with panels that have compatible timings. > .../devicetree/bindings/display/panel/panel-simple.yaml | 4 > 1 file changed, 4 insertions(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > index 62b0d54d87b7..9807dbc1cceb 100644 > --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml > @@ -140,6 +140,10 @@ properties: >- giantplus,gpg48273qs5 > # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel >- giantplus,gpm940b0 > +# A panel connected to a google,pompom board. Panel is guaranteed to > +# confirm to google,pompom-panel power sequencing requirements and > then s/confirm/conform/ ? > +# the specific panel will be probed via EDID. > + - google,pompom-panel > # HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel >- hannstar,hsd070pww1 > # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel FWIW: Reviewed-by: Matthias Kaehlcke
