From: Kieran Bingham <kieran.bingham@ideasonboard.com>
To: Doug Anderson <dianders@chromium.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>,
Neil Armstrong <narmstrong@baylibre.com>,
Jonas Karlman <jonas@kwiboo.se>,
dri-devel <dri-devel@lists.freedesktop.org>,
Stephen Boyd <swboyd@chromium.org>,
linux-renesas-soc@vger.kernel.org,
Andrzej Hajda <a.hajda@samsung.com>
Subject: Re: [RFC PATCH 11/11] drm/bridge: ti-sn65dsi86: Support hotplug detection
Date: Wed, 23 Feb 2022 17:43:09 +0000 [thread overview]
Message-ID: <164563818901.4066078.3221991328451321918@Monstersaurus> (raw)
In-Reply-To: <CAD=FV=W6npK+NhethhY8ghtt7gwDHYfpX00w07nHE82anqx5aA@mail.gmail.com>
Hi All,
I'm working to respin the remainder of these patches, now that I have
IRQ based HPD working on the SN65DSI86, and the (non-eDP) mode is used
for Renesas R-Car boards.
Quoting Doug Anderson (2021-06-24 00:51:12)
> Hi,
>
> On Wed, Jun 23, 2021 at 4:26 PM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> >
> > > > @@ -1365,7 +1384,8 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
> > > >
> > > > pdata->bridge.funcs = &ti_sn_bridge_funcs;
> > > > pdata->bridge.of_node = client->dev.of_node;
> > > > - pdata->bridge.ops = DRM_BRIDGE_OP_EDID;
> > > > + pdata->bridge.ops = (pdata->no_hpd ? 0 : DRM_BRIDGE_OP_DETECT)
> > >
> > > Checking for "no_hpd" here is not the right test IIUC. You want to
> > > check for eDP vs. DP (AKA whether a panel is downstream of you or a
> > > connector). Specifically if downstream of you is a panel then (I
> > > believe) HPD won't assert until you turn on the panel and you won't
> > > turn on the panel (which happens in pre_enable, right?) until HPD
> > > fires, so you've got a chicken-and-egg problem. If downstream of you
> > > is a connector, though, then by definition HPD has to just work
> > > without pre_enable running so then you're OK.
> >
> > Agreed. It's even more true now that your rework has landed, as in the
> > eDP case EDID is handled by the panel driver. I'll rework this.
> >
> > Should I also condition setting HPD_DISABLE to the presence of a panel
> > then ? I could drop of_property_read_bool() and set
> >
> > pdata->no_hpd = !!panel;
> >
> > > I guess then you'd need to figure out what to do if someone wants to
> > > use "HPD" on eDP. Do you need to put a polling loop in pre_enable
> > > then? Or you could just punt not support this case until someone needs
> > > it.
> >
> > I think I'll stop short of saving the world this time, yes :-) We'll see
> > what to do when this case arises.
>
> How about as a compromise you still call of_property_read_bool() but
> add some type of warning in the logs if someone didn't set "no-hpd"
> but they have a panel?
Would a mix of the two work well?
What about:
pdata->no_hpd = of_property_read_bool(np, "no-hpd");
if (panel && !pdata->no_hpd) {
DRM_ERROR("Panels will not function with HPD. Enforcing no-hpd\n");
pdata->no_hpd = true;
}
That leaves it still optional to DP connectors, but enforced on eDP?
> > > > + | DRM_BRIDGE_OP_EDID;
> > >
> > > IMO somewhere in here if HPD is being used like this you should throw
> > > in a call to pm_runtime_get_sync(). I guess in your solution the
> > > regulators (for the bridge, not the panel) and enable pin are just
> > > left on all the time,
> >
> > Correct, on my development board the SN65DSI86 is on all the time, I
> > can't control that.
> >
> > > but plausibly someone might want to build a
> > > system to use HPD and also have the enable pin and/or regulators
> > > controlled by this driver, right?
> >
> > True. DRM doesn't make this very easy, as, as far as I can tell, there's
> > no standard infrastructure for userspace to register an interest in HPD
> > that could be notified to bridges. I think it should be fixable, but
> > it's out of scope for this series :-) Should I still add a
> > pm_runtime_get_sync() at probe time, or leave this to be addressed by
> > someone who will need to implement power control ?
>
> IMO if you've detected you're running in DP mode you should add the
> pm_runtime_get_sync() in probe to keep it powered all the time and
> that seems the simplest. Technically I guess that's not really
> required since you're polling and you could power off between polls,
> but then you'd have to re-init a bunch of your state each time you
> polled too. If you ever transitioned to using an IRQ for HPD then
> you'd have to keep it always powered anyway.
Hrm ... that's precisely what I've done. It's not IRQ based HPD...
So would you like to see something like this during
ti_sn_bridge_probe()?
/* The device must remain powered up for HPD to be supported. */
if (!pdata->no_hpd)
pm_runtime_get_sync(pdata->dev);
--
Regards
Kieran
>
> -Doug
next prev parent reply other threads:[~2022-02-23 17:43 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 3:01 [RFC PATCH 00/11] drm/bridge: ti-sn65dsi86: Support DisplayPort mode Laurent Pinchart
2021-03-22 3:01 ` [RFC PATCH 01/11] dt-bindings: drm/bridge: ti-sn65dsi8: Make enable GPIO optional Laurent Pinchart
2021-03-22 10:29 ` Jagan Teki
2021-03-23 7:10 ` Stephen Boyd
2021-03-23 21:08 ` Doug Anderson
2021-03-27 16:42 ` Rob Herring
2021-03-22 3:01 ` [RFC PATCH 02/11] drm/bridge: ti-sn65dsi86: " Laurent Pinchart
2021-03-22 10:29 ` Jagan Teki
2021-03-23 7:10 ` Stephen Boyd
2021-03-23 21:08 ` Doug Anderson
2021-03-22 3:01 ` [RFC PATCH 03/11] drm/bridge: ti-sn65dsi86: Unregister AUX adapter in remove() Laurent Pinchart
2021-03-23 7:10 ` Stephen Boyd
2021-03-23 21:08 ` Doug Anderson
2021-03-23 21:41 ` Laurent Pinchart
2021-03-23 22:55 ` Doug Anderson
2021-03-23 23:02 ` Laurent Pinchart
2021-03-26 0:43 ` Doug Anderson
2021-03-26 1:01 ` Laurent Pinchart
2021-03-22 3:01 ` [RFC PATCH 04/11] drm/bridge: ti-sn65dsi86: Use bitmask to store valid rates Laurent Pinchart
2021-03-23 7:11 ` Stephen Boyd
2021-03-23 21:08 ` Doug Anderson
2021-03-23 21:45 ` Laurent Pinchart
2021-03-23 22:45 ` Doug Anderson
2021-03-24 8:47 ` Geert Uytterhoeven
2021-03-22 3:01 ` [RFC PATCH 05/11] drm/bridge: ti-sn65dsi86: Wrap panel with panel-bridge Laurent Pinchart
2021-03-22 10:19 ` Jagan Teki
2021-03-23 7:14 ` Stephen Boyd
2021-03-23 21:50 ` Laurent Pinchart
2021-03-24 22:44 ` Doug Anderson
2021-03-26 1:06 ` Laurent Pinchart
2021-03-22 3:01 ` [RFC PATCH 06/11] drm/bridge: ti-sn65dsi86: Group code in sections Laurent Pinchart
2021-03-23 7:14 ` Stephen Boyd
2021-03-24 22:44 ` Doug Anderson
2021-03-22 3:01 ` [RFC PATCH 07/11] drm/bridge: ti-sn65dsi86: Split connector creation to a function Laurent Pinchart
2021-03-23 7:15 ` Stephen Boyd
2021-03-24 22:44 ` Doug Anderson
2021-03-22 3:01 ` [RFC PATCH 08/11] drm/bridge: ti-sn65dsi86: Implement bridge connector operations Laurent Pinchart
2021-03-23 7:15 ` Stephen Boyd
2021-03-24 22:46 ` Doug Anderson
2021-03-26 1:40 ` Laurent Pinchart
2021-03-22 3:01 ` [RFC PATCH 09/11] drm/bridge: ti-sn65dsi86: Make connector creation optional Laurent Pinchart
2021-03-22 3:01 ` [RFC PATCH 10/11] drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode Laurent Pinchart
2021-03-24 22:47 ` Doug Anderson
2021-06-23 13:59 ` Laurent Pinchart
2022-02-23 18:04 ` Kieran Bingham
2022-02-23 18:20 ` Doug Anderson
2022-03-04 15:49 ` Laurent Pinchart
2021-03-22 3:01 ` [RFC PATCH 11/11] drm/bridge: ti-sn65dsi86: Support hotplug detection Laurent Pinchart
2021-03-23 7:21 ` Stephen Boyd
2021-03-24 22:47 ` Doug Anderson
2021-06-23 23:25 ` Laurent Pinchart
2021-06-23 23:51 ` Doug Anderson
2022-02-23 17:43 ` Kieran Bingham [this message]
2022-02-23 18:25 ` Doug Anderson
2022-03-04 15:45 ` Kieran Bingham
2022-03-04 16:30 ` Doug Anderson
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=164563818901.4066078.3221991328451321918@Monstersaurus \
--to=kieran.bingham@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=dianders@chromium.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=narmstrong@baylibre.com \
--cc=swboyd@chromium.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).