Message-ID: <20200509201511.GD30802@ravnborg.org>
Date:   Sat, 9 May 2020 22:15:11 +0200
From:   Sam Ravnborg <sam@...nborg.org>
To:     Douglas Anderson <dianders@...omium.org>
Cc:     linus.walleij@...aro.org, bgolaszewski@...libre.com,
        airlied@...ux.ie, daniel@...ll.ch, robh+dt@...nel.org,
        narmstrong@...libre.com, a.hajda@...sung.com,
        Laurent.pinchart@...asonboard.com, spanda@...eaurora.org,
        robdclark@...omium.org, devicetree@...r.kernel.org,
        jernej.skrabec@...l.net, jeffrey.l.hugo@...il.com,
        Stephen Boyd <sboyd@...nel.org>, linux-arm-msm@...r.kernel.org,
        jonas@...boo.se, dri-devel@...ts.freedesktop.org,
        swboyd@...omium.org, linux-gpio@...r.kernel.org,
        Andy Gross <agross@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        bjorn.andersson@...aro.org, linux-kernel@...r.kernel.org
Subject: 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

Powered by blists - more mailing lists