All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Sam Ravnborg <sam@ravnborg.org>,
	LinusW <linus.walleij@linaro.org>,
	Stephen Boyd <swboyd@chromium.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Rob Herring <robh+dt@kernel.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Sandeep Panda <spanda@codeaurora.org>,
	Rob Clark <robdclark@chromium.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Jonas Karlman <jonas@kwiboo.se>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Andy Gross <agross@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
Date: Mon, 18 May 2020 07:50:29 -0700	[thread overview]
Message-ID: <CAD=FV=UNuwb+YYJKw9+HNMKUNfuNFxj+Gr+yB9tXANbXAvDgCg@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=VBU7JmTdvgWjyj_ytrFmz6Gkx2OjVr1FxLh9DBG_jN6w@mail.gmail.com>

Sam,

On Sat, May 9, 2020 at 3:48 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Sat, May 9, 2020 at 1:15 PM Sam Ravnborg <sam@ravnborg.org> 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 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.
>
> Thanks!
>
> 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?

Thanks!

-Doug

WARNING: multiple messages have this Message-ID
From: Doug Anderson <dianders@chromium.org>
To: Sam Ravnborg <sam@ravnborg.org>,
	LinusW <linus.walleij@linaro.org>,
	 Stephen Boyd <swboyd@chromium.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>,
	David Airlie <airlied@linux.ie>,
	Sandeep Panda <spanda@codeaurora.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Rob Clark <robdclark@chromium.org>,
	Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Andy Gross <agross@kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>, Jonas Karlman <jonas@kwiboo.se>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	Stephen Boyd <sboyd@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect
Date: Mon, 18 May 2020 07:50:29 -0700	[thread overview]
Message-ID: <CAD=FV=UNuwb+YYJKw9+HNMKUNfuNFxj+Gr+yB9tXANbXAvDgCg@mail.gmail.com> (raw)
In-Reply-To: <CAD=FV=VBU7JmTdvgWjyj_ytrFmz6Gkx2OjVr1FxLh9DBG_jN6w@mail.gmail.com>

Sam,

On Sat, May 9, 2020 at 3:48 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Sat, May 9, 2020 at 1:15 PM Sam Ravnborg <sam@ravnborg.org> 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 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.
>
> Thanks!
>
> 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?

Thanks!

-Doug
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-05-18 14:50 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 21:34 Douglas Anderson
2020-05-07 21:34 ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 1/6] drm/bridge: ti-sn65dsi86: Export bridge GPIOs to Linux Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-11 16:24   ` Stephen Boyd
2020-05-11 16:24     ` Stephen Boyd
2020-05-12  1:36   ` Bjorn Andersson
2020-05-12  1:36     ` Bjorn Andersson
2020-05-12 12:28   ` Linus Walleij
2020-05-12 12:28     ` Linus Walleij
2020-05-07 21:34 ` [PATCH v5 2/6] dt-bindings: display: Add hpd-gpios to panel-common bindings Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 3/6] drm/panel-simple: Support hpd-gpios for delaying prepare() Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-07 21:34 ` [PATCH v5 4/6] dt-bindings: drm/bridge: ti-sn65dsi86: Convert to yaml Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-11 16:25   ` Stephen Boyd
2020-05-11 16:25     ` Stephen Boyd
2020-05-07 21:34 ` [PATCH v5 5/6] dt-bindings: drm/bridge: ti-sn65dsi86: Document no-hpd Douglas Anderson
2020-05-07 21:34   ` Douglas Anderson
2020-05-07 21:35 ` [PATCH v5 6/6] arm64: dts: sdm845: Add "no-hpd" to sn65dsi86 on cheza Douglas Anderson
2020-05-07 21:35   ` Douglas Anderson
2020-05-12  1:21   ` Bjorn Andersson
2020-05-12  1:21     ` Bjorn Andersson
2020-05-09 20:15 ` [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect Sam Ravnborg
2020-05-09 20:15   ` Sam Ravnborg
2020-05-09 22:48   ` Doug Anderson
2020-05-09 22:48     ` Doug Anderson
2020-05-18 14:50     ` Doug Anderson [this message]
2020-05-18 14:50       ` Doug Anderson
2020-05-18 17:59       ` Sam Ravnborg
2020-05-18 17:59         ` Sam Ravnborg
2020-05-18 18:05         ` Doug Anderson
2020-05-18 18:05           ` Doug Anderson
2020-05-18 18:28           ` Sam Ravnborg
2020-05-18 18:28             ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD=FV=UNuwb+YYJKw9+HNMKUNfuNFxj+Gr+yB9tXANbXAvDgCg@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=agross@kernel.org \
    --cc=airlied@linux.ie \
    --cc=bgolaszewski@baylibre.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jeffrey.l.hugo@gmail.com \
    --cc=jernej.skrabec@siol.net \
    --cc=jonas@kwiboo.se \
    --cc=krzk@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robdclark@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sboyd@kernel.org \
    --cc=spanda@codeaurora.org \
    --cc=swboyd@chromium.org \
    --cc=thierry.reding@gmail.com \
    --subject='Re: [PATCH v5 0/6] drm: Prepare to use a GPIO on ti-sn65dsi86 for Hot Plug Detect' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.