Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
Hi Douglas, On Mon, May 18, 2020 at 11:05:58AM -0700, Doug Anderson wrote: > Sam, > > On Mon, May 18, 2020 at 10:59 AM Sam Ravnborg wrote: > > > > Hi Douglas. > > > > > > Given the previous feedback from Linus W, Stephen, and Laurent I > > > > expect things are good enough to land now, but it'd be good to get > > > > confirmation (I removed some of the previous tags just to get > > > > confirmation). If we can get review tags early next week maybe it'll > > > > still be in time to land for 5.8? > > > > > > I think all the others have reviews now. Is there anything blocking > > > them from getting applied? > > Applied, including the small fix pointed out by Linus. > > Thanks! Ugh, I just realized what the problem was. I posted a v6 > with this fix but insanely somehow didn't CC you (!!!). It was here: > > https://lore.kernel.org/r/20200513215902.261547-1-diand...@chromium.org > > I'm super sorry about that and thanks for fixing the nit. That was > the only difference between v5 and v6. I just checked what you pushed > and it looks great, thank you. No worries as long as what hits drm-misc-next is OK, which it was in this case. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
Sam, On Mon, May 18, 2020 at 10:59 AM Sam Ravnborg wrote: > > Hi Douglas. > > > > Given the previous feedback from Linus W, Stephen, and Laurent I > > > expect things are good enough to land now, but it'd be good to get > > > confirmation (I removed some of the previous tags just to get > > > confirmation). If we can get review tags early next week maybe it'll > > > still be in time to land for 5.8? > > > > I think all the others have reviews now. Is there anything blocking > > them from getting applied? > Applied, including the small fix pointed out by Linus. Thanks! Ugh, I just realized what the problem was. I posted a v6 with this fix but insanely somehow didn't CC you (!!!). It was here: https://lore.kernel.org/r/20200513215902.261547-1-diand...@chromium.org I'm super sorry about that and thanks for fixing the nit. That was the only difference between v5 and v6. I just checked what you pushed and it looks great, thank you. -Doug ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
Hi Douglas. > > Given the previous feedback from Linus W, Stephen, and Laurent I > > expect things are good enough to land now, but it'd be good to get > > confirmation (I removed some of the previous tags just to get > > confirmation). If we can get review tags early next week maybe it'll > > still be in time to land for 5.8? > > I think all the others have reviews now. Is there anything blocking > them from getting applied? Applied, including the small fix pointed out by Linus. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
Sam,
On Sat, May 9, 2020 at 3:48 PM Doug Anderson wrote:
>
> Hi,
>
> On Sat, May 9, 2020 at 1:15 PM Sam Ravnborg wrote:
> >
> > Hi Douglas.
> >
> > On Thu, May 07, 2020 at 02:34:54PM -0700, Douglas Anderson wrote:
> > >
> > > As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86:
> > > Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is
> > > kinda useless, at least for embedded DisplayPort (eDP). However,
> > > despite the fact that the actual HPD pin on the bridge is mostly
> > > useless for eDP, the concept of HPD for eDP still makes sense. It
> > > allows us to optimize out a hardcoded delay that many panels need if
> > > HPD isn't hooked up. Panel timing diagrams show HPD as one of the
> > > events to measure timing from and we have to assume the worst case if
> > > we can't actually read HPD.
> > >
> > > One way to use HPD for eDP without using the mostly useless HPD pin on
> > > ti-sn65dsi86 is to route the panel's HPD somewhere else in the system,
> > > like to a GPIO. This works great because eDP panels aren't physically
> > > hotplugged. That means the debouncing logic that caused us problems
> > > wasn't really needed and a raw GPIO works great.
> > >
> > > As per the above, a smart board designer would realize the value of
> > > HPD and choose to route it to a GPIO somewhere on the board to avoid
> > > the silly sn65dsi86 debouncing. While said "smart designer" could
> > > theoretically route HPD anywhere on the board, a really smart designer
> > > would realize that there are several GPIOs on the bridge itself that
> > > are nearly useless for anything but this purpose and route HPD to one
> > > of those.
> > >
> > > This series of patches is intended to allow the scenario described
> > > above.
> > >
> > > This patch has been tested on a board that is not yet mainline. On
> > > the hardware I have:
> > > - Panel spec says HPD could take up to 200 ms to come up, so without
> > > HPD hooked up we need to delay 200 ms.
> > > - On my board the panel is powered by the same rail as the
> > > touchscreen. By chance of probe order the touchscreen comes up
> > > first. This means by the time we check HPD in ti_sn_bridge_enable()
> > > it's already up. Thus we can use the panel on 200 ms earlier.
> > > - If I measure HPD on this pane it comes up ~56 ms after the panel is
> > > powered. This means I can save 144 ms of delay.
> > >
> > > Side effects (though not main goals) of this series are:
> > > - ti-sn65dsi86 GPIOs are now exported in Linux.
> > > - ti-sn65dsi86 bindings are converted to yaml.
> > > - Common panel bindings now have "hpd-gpios" listed.
> > > - The simple-panel driver in Linux can delay in prepare based on
> > > "hpd-gpios"
> > > - ti-sn65dsi86 bindings (and current user) now specifies "no-hpd"
> > > if HPD isn't hooked up.
> > >
> > > Changes in v5:
> > > - Use of_xlate so that numbers in dts start at 1, not 0.
> > > - Squash
> > > https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/
> > >
> > > Changes in v4:
> > > - Don't include gpio.h
> > > - Use gpiochip_get_data() instead of container_of() to get data.
> > > - GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX
> > > - Use Linus W's favorite syntax to read a bit from a bitfield.
> > > - Define and use SN_GPIO_MUX_MASK.
> > > - Add a comment about why we use a bitmap for gchip_output.
> > > - Tacked on "or is otherwise unusable." to description.
> > >
> > > Changes in v3:
> > > - Becaue => Because
> > > - Add a kernel-doc to our pdata to clarify double-duty of gchip_output.
> > > - More comments about how powering off affects us (get_dir, dir_input).
> > > - Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return".
> > > - Use a bitmap rather than rolling my own.
> > > - Remind how gpio_get_optional() works in the commit message.
> > > - useful implement => useful to implement
> > >
> > > Changes in v2:
> > > - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
> > > - ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2
> > > - ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge
> > > GPIOs")
> > > - specification => specifier.
> > > - power up => power.
> > > - Added back missing suspend-gpios.
> > > - data-lanes and lane-polarities are are the right place now.
> > > - endpoints don't need to be patternProperties.
> > > - Specified more details for data-lanes and lane-polarities.
> > > - Added old example back in, fixing bugs in it.
> > > - Example i2c bus is just called "i2c", not "i2c1" now.
> > > - ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.
> > > - ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2.
> > >
> > > Douglas Anderson (6):
> > > drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
> > > dt-bindings: display: Add hpd-gpios to panel-common bindings
> > > drm/panel-simple: Support hpd-gpios for delaying prepare()
Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
Hi,
On Sat, May 9, 2020 at 1:15 PM Sam Ravnborg wrote:
>
> Hi Douglas.
>
> On Thu, May 07, 2020 at 02:34:54PM -0700, Douglas Anderson wrote:
> >
> > As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86:
> > Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is
> > kinda useless, at least for embedded DisplayPort (eDP). However,
> > despite the fact that the actual HPD pin on the bridge is mostly
> > useless for eDP, the concept of HPD for eDP still makes sense. It
> > allows us to optimize out a hardcoded delay that many panels need if
> > HPD isn't hooked up. Panel timing diagrams show HPD as one of the
> > events to measure timing from and we have to assume the worst case if
> > we can't actually read HPD.
> >
> > One way to use HPD for eDP without using the mostly useless HPD pin on
> > ti-sn65dsi86 is to route the panel's HPD somewhere else in the system,
> > like to a GPIO. This works great because eDP panels aren't physically
> > hotplugged. That means the debouncing logic that caused us problems
> > wasn't really needed and a raw GPIO works great.
> >
> > As per the above, a smart board designer would realize the value of
> > HPD and choose to route it to a GPIO somewhere on the board to avoid
> > the silly sn65dsi86 debouncing. While said "smart designer" could
> > theoretically route HPD anywhere on the board, a really smart designer
> > would realize that there are several GPIOs on the bridge itself that
> > are nearly useless for anything but this purpose and route HPD to one
> > of those.
> >
> > This series of patches is intended to allow the scenario described
> > above.
> >
> > This patch has been tested on a board that is not yet mainline. On
> > the hardware I have:
> > - Panel spec says HPD could take up to 200 ms to come up, so without
> > HPD hooked up we need to delay 200 ms.
> > - On my board the panel is powered by the same rail as the
> > touchscreen. By chance of probe order the touchscreen comes up
> > first. This means by the time we check HPD in ti_sn_bridge_enable()
> > it's already up. Thus we can use the panel on 200 ms earlier.
> > - If I measure HPD on this pane it comes up ~56 ms after the panel is
> > powered. This means I can save 144 ms of delay.
> >
> > Side effects (though not main goals) of this series are:
> > - ti-sn65dsi86 GPIOs are now exported in Linux.
> > - ti-sn65dsi86 bindings are converted to yaml.
> > - Common panel bindings now have "hpd-gpios" listed.
> > - The simple-panel driver in Linux can delay in prepare based on
> > "hpd-gpios"
> > - ti-sn65dsi86 bindings (and current user) now specifies "no-hpd"
> > if HPD isn't hooked up.
> >
> > Changes in v5:
> > - Use of_xlate so that numbers in dts start at 1, not 0.
> > - Squash
> > https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/
> >
> > Changes in v4:
> > - Don't include gpio.h
> > - Use gpiochip_get_data() instead of container_of() to get data.
> > - GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX
> > - Use Linus W's favorite syntax to read a bit from a bitfield.
> > - Define and use SN_GPIO_MUX_MASK.
> > - Add a comment about why we use a bitmap for gchip_output.
> > - Tacked on "or is otherwise unusable." to description.
> >
> > Changes in v3:
> > - Becaue => Because
> > - Add a kernel-doc to our pdata to clarify double-duty of gchip_output.
> > - More comments about how powering off affects us (get_dir, dir_input).
> > - Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return".
> > - Use a bitmap rather than rolling my own.
> > - Remind how gpio_get_optional() works in the commit message.
> > - useful implement => useful to implement
> >
> > Changes in v2:
> > - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
> > - ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2
> > - ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs")
> > - specification => specifier.
> > - power up => power.
> > - Added back missing suspend-gpios.
> > - data-lanes and lane-polarities are are the right place now.
> > - endpoints don't need to be patternProperties.
> > - Specified more details for data-lanes and lane-polarities.
> > - Added old example back in, fixing bugs in it.
> > - Example i2c bus is just called "i2c", not "i2c1" now.
> > - ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.
> > - ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2.
> >
> > Douglas Anderson (6):
> > drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
> > dt-bindings: display: Add hpd-gpios to panel-common bindings
> > drm/panel-simple: Support hpd-gpios for delaying prepare()
> > dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml
> > dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
> > arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza
>
> Applied:
> > dt-bindings: display: Add hpd-gpios to panel-common
Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
Hi Douglas.
On Thu, May 07, 2020 at 02:34:54PM -0700, Douglas Anderson wrote:
>
> As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86:
> Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is
> kinda useless, at least for embedded DisplayPort (eDP). However,
> despite the fact that the actual HPD pin on the bridge is mostly
> useless for eDP, the concept of HPD for eDP still makes sense. It
> allows us to optimize out a hardcoded delay that many panels need if
> HPD isn't hooked up. Panel timing diagrams show HPD as one of the
> events to measure timing from and we have to assume the worst case if
> we can't actually read HPD.
>
> One way to use HPD for eDP without using the mostly useless HPD pin on
> ti-sn65dsi86 is to route the panel's HPD somewhere else in the system,
> like to a GPIO. This works great because eDP panels aren't physically
> hotplugged. That means the debouncing logic that caused us problems
> wasn't really needed and a raw GPIO works great.
>
> As per the above, a smart board designer would realize the value of
> HPD and choose to route it to a GPIO somewhere on the board to avoid
> the silly sn65dsi86 debouncing. While said "smart designer" could
> theoretically route HPD anywhere on the board, a really smart designer
> would realize that there are several GPIOs on the bridge itself that
> are nearly useless for anything but this purpose and route HPD to one
> of those.
>
> This series of patches is intended to allow the scenario described
> above.
>
> This patch has been tested on a board that is not yet mainline. On
> the hardware I have:
> - Panel spec says HPD could take up to 200 ms to come up, so without
> HPD hooked up we need to delay 200 ms.
> - On my board the panel is powered by the same rail as the
> touchscreen. By chance of probe order the touchscreen comes up
> first. This means by the time we check HPD in ti_sn_bridge_enable()
> it's already up. Thus we can use the panel on 200 ms earlier.
> - If I measure HPD on this pane it comes up ~56 ms after the panel is
> powered. This means I can save 144 ms of delay.
>
> Side effects (though not main goals) of this series are:
> - ti-sn65dsi86 GPIOs are now exported in Linux.
> - ti-sn65dsi86 bindings are converted to yaml.
> - Common panel bindings now have "hpd-gpios" listed.
> - The simple-panel driver in Linux can delay in prepare based on
> "hpd-gpios"
> - ti-sn65dsi86 bindings (and current user) now specifies "no-hpd"
> if HPD isn't hooked up.
>
> Changes in v5:
> - Use of_xlate so that numbers in dts start at 1, not 0.
> - Squash
> https://lore.kernel.org/r/20200506140208.v2.2.I0a2bca02b09c1fcb6b09479b489736d600b3e57f@changeid/
>
> Changes in v4:
> - Don't include gpio.h
> - Use gpiochip_get_data() instead of container_of() to get data.
> - GPIOF_DIR_XXX => GPIO_LINE_DIRECTION_XXX
> - Use Linus W's favorite syntax to read a bit from a bitfield.
> - Define and use SN_GPIO_MUX_MASK.
> - Add a comment about why we use a bitmap for gchip_output.
> - Tacked on "or is otherwise unusable." to description.
>
> Changes in v3:
> - Becaue => Because
> - Add a kernel-doc to our pdata to clarify double-duty of gchip_output.
> - More comments about how powering off affects us (get_dir, dir_input).
> - Cleanup tail of ti_sn_setup_gpio_controller() to avoid one "return".
> - Use a bitmap rather than rolling my own.
> - Remind how gpio_get_optional() works in the commit message.
> - useful implement => useful to implement
>
> Changes in v2:
> - ("Export...GPIOs") is 1/2 of replacement for ("Allow...bridge GPIOs")
> - ("dt-bindings: display: Add hpd-gpios to panel-common...") new for v2
> - ("simple...hpd-gpios") is 1/2 of replacement for ("Allow...bridge GPIOs")
> - specification => specifier.
> - power up => power.
> - Added back missing suspend-gpios.
> - data-lanes and lane-polarities are are the right place now.
> - endpoints don't need to be patternProperties.
> - Specified more details for data-lanes and lane-polarities.
> - Added old example back in, fixing bugs in it.
> - Example i2c bus is just called "i2c", not "i2c1" now.
> - ("dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd") new for v2.
> - ("arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza") new for v2.
>
> Douglas Anderson (6):
> drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux
> dt-bindings: display: Add hpd-gpios to panel-common bindings
> drm/panel-simple: Support hpd-gpios for delaying prepare()
> dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml
> dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd
> arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza
Applied:
> dt-bindings: display: Add hpd-gpios to panel-common bindings
> drm/panel-simple: Support hpd-gpios for delaying prepare()
to drm-misc-next.
The others was missing reviews so we need to wait for feedback.
Sam
___
dri-devel mailing list
