From: Thierry Reding <thierry.reding@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 8/9] drm/tegra: dpaux: Add missing runtime PM references
Date: Fri, 29 Nov 2019 11:44:12 +0100 [thread overview]
Message-ID: <20191129104412.GD2771912@ulmo> (raw)
In-Reply-To: <20191129092319.GD624164@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 4026 bytes --]
On Fri, Nov 29, 2019 at 10:23:19AM +0100, Daniel Vetter wrote:
> On Thu, Nov 28, 2019 at 04:37:40PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Ensure that a runtime PM reference is acquired each time the DPAUX
> > registers are accessed. Otherwise the code may end up running without
> > the controller being powered, out-of-reset or clocked in some corner
> > cases, resulting in a crash.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> On patches 4,5,7 in this series Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> On this one here I'm very confused.
>
> - Why do you drop the runtime pm between enable and disable? Is that just
> how the hw works, i.e. the pad config stays, just the registers go away?
Now you've made me doubt this. I don't think the pad configuration stays
across runtime suspend/resume, so you're right, this shouldn't work.
I'll need to go retest this one specifically.
I had added these runtime PM references to ensure the device was
properly configured at resume from suspend, but there ended up being an
additional issue with the I2C driver that relies on this, so perhaps
this may not be necessary in the end.
> - I'm not seeing any locking between the different users (dp aux and
> pinctrl). We might want to change drm_dp_aux->hw_mutex to a pointer to
> make this easier (but I'm not super fond of that pattern from i2c).
There should be no need to lock here. DP AUX transfers will only be used
between drm_dp_aux_enable() and drm_dp_aux_disable().
> - Your drm_dp_aux_enable/disable needs to be moved into the ->transfer
> callback, otherwise the various userspace interface (dp aux, but also
> i2c on top of that) won't work. Some pre/post_transfer functions like
> i2c has might be useful for stuff like this.
I suppose it would be possible for someone to attempt to use those
userspace interfaces outside of drm_dp_aux_enable()/drm_dp_aux_disable()
and then the locking would be required.
I'll look into that.
Thierry
>
> Cheers, Daniel
>
> > ---
> > drivers/gpu/drm/tegra/dpaux.c | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
> > index 622cdf1ad246..4b2b86aed1a5 100644
> > --- a/drivers/gpu/drm/tegra/dpaux.c
> > +++ b/drivers/gpu/drm/tegra/dpaux.c
> > @@ -434,8 +434,13 @@ static int tegra_dpaux_set_mux(struct pinctrl_dev *pinctrl,
> > unsigned int function, unsigned int group)
> > {
> > struct tegra_dpaux *dpaux = pinctrl_dev_get_drvdata(pinctrl);
> > + int err;
> > +
> > + pm_runtime_get_sync(dpaux->dev);
> > + err = tegra_dpaux_pad_config(dpaux, function);
> > + pm_runtime_put(dpaux->dev);
> >
> > - return tegra_dpaux_pad_config(dpaux, function);
> > + return err;
> > }
> >
> > static const struct pinmux_ops tegra_dpaux_pinmux_ops = {
> > @@ -809,15 +814,22 @@ enum drm_connector_status drm_dp_aux_detect(struct drm_dp_aux *aux)
> > int drm_dp_aux_enable(struct drm_dp_aux *aux)
> > {
> > struct tegra_dpaux *dpaux = to_dpaux(aux);
> > + int err;
> > +
> > + pm_runtime_get_sync(dpaux->dev);
> > + err = tegra_dpaux_pad_config(dpaux, DPAUX_PADCTL_FUNC_AUX);
> > + pm_runtime_put(dpaux->dev);
> >
> > - return tegra_dpaux_pad_config(dpaux, DPAUX_PADCTL_FUNC_AUX);
> > + return err;
> > }
> >
> > int drm_dp_aux_disable(struct drm_dp_aux *aux)
> > {
> > struct tegra_dpaux *dpaux = to_dpaux(aux);
> >
> > + pm_runtime_get_sync(dpaux->dev);
> > tegra_dpaux_pad_power_down(dpaux);
> > + pm_runtime_put(dpaux->dev);
> >
> > return 0;
> > }
> > --
> > 2.23.0
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-11-29 10:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-28 15:37 [PATCH 0/9] drm/tegra: Miscellaneous fixes Thierry Reding
2019-11-28 15:37 ` [PATCH 1/9] drm/tegra: hub: Remove bogus connection mutex check Thierry Reding
2019-11-29 9:06 ` Daniel Vetter
2019-11-29 10:12 ` Thierry Reding
2019-11-29 19:03 ` Daniel Vetter
2019-12-02 15:08 ` Thierry Reding
2019-11-28 15:37 ` [PATCH 2/9] drm/tegra: gem: Properly pin imported buffers Thierry Reding
2019-11-29 9:10 ` Daniel Vetter
2019-11-29 10:15 ` Thierry Reding
2019-11-29 19:09 ` Daniel Vetter
2019-11-28 15:37 ` [PATCH 3/9] drm/tegra: gem: Remove premature import restrictions Thierry Reding
2019-11-29 9:12 ` Daniel Vetter
2019-11-29 10:33 ` Thierry Reding
2019-11-29 20:06 ` Daniel Vetter
2019-11-28 15:37 ` [PATCH 4/9] drm/tegra: Use proper IOVA address for cursor image Thierry Reding
2019-11-28 15:37 ` [PATCH 5/9] drm/tegra: sor: Implement system suspend/resume Thierry Reding
2019-11-28 15:37 ` [PATCH 6/9] drm/tegra: vic: Export module device table Thierry Reding
2019-11-28 15:37 ` [PATCH 7/9] drm/tegra: Silence expected errors on IOMMU attach Thierry Reding
2019-11-28 15:37 ` [PATCH 8/9] drm/tegra: dpaux: Add missing runtime PM references Thierry Reding
2019-11-29 9:23 ` Daniel Vetter
2019-11-29 10:44 ` Thierry Reding [this message]
2019-11-29 20:20 ` Daniel Vetter
2019-12-02 14:58 ` Thierry Reding
2019-12-03 9:27 ` Daniel Vetter
2019-11-28 15:37 ` [PATCH 9/9] drm/tegra: sor: Make the +5V HDMI supply optional Thierry Reding
2019-11-29 9:24 ` Daniel Vetter
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=20191129104412.GD2771912@ulmo \
--to=thierry.reding@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-tegra@vger.kernel.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