From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Cc: Petlozu Pravareshwar <petlozup@nvidia.com>,
jonathanh@nvidia.com, p.zabel@pengutronix.de,
ulf.hansson@linaro.org, kkartik@nvidia.com,
cai.huoqing@linux.dev, spatra@nvidia.com,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
Viswanath L <viswanathl@nvidia.com>
Subject: Re: [PATCH v2] soc/tegra: pmc: Support software wake-up for SPE
Date: Tue, 4 Apr 2023 13:15:29 +0200 [thread overview]
Message-ID: <ZCwG0SM9szT6toGG@orome> (raw)
In-Reply-To: <f70c6d62-a7fd-c153-932f-16886e46329b@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 3870 bytes --]
On Mon, Apr 03, 2023 at 07:06:12PM +0300, Dmitry Osipenko wrote:
> On 3/30/23 20:06, Petlozu Pravareshwar wrote:
> > The Sensor Processing Engine(SPE) can trigger a software wake-up of
> > the device. To support this wake-up for the SPE, set SR_CAPTURE_EN
> > bit in WAKE_AOWAKE_CNTRL register associated with the wake-up for
> > the SPE. This SR capturing logic is expected to be enabled for wakes
> > with short pulse signalling requirements.
> >
> > Signed-off-by: Viswanath L <viswanathl@nvidia.com>
> > Signed-off-by: Petlozu Pravareshwar <petlozup@nvidia.com>
> > ---
> > v1->v2:
> > * Rebase the change on latest code.
> > ---
> > drivers/soc/tegra/pmc.c | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
> > index cf4cfbf9f7c5..2a2342eff622 100644
> > --- a/drivers/soc/tegra/pmc.c
> > +++ b/drivers/soc/tegra/pmc.c
> > @@ -3,7 +3,7 @@
> > * drivers/soc/tegra/pmc.c
> > *
> > * Copyright (c) 2010 Google, Inc
> > - * Copyright (c) 2018-2022, NVIDIA CORPORATION. All rights reserved.
> > + * Copyright (c) 2018-2023, NVIDIA CORPORATION. All rights reserved.
> > *
> > * Author:
> > * Colin Cross <ccross@google.com>
> > @@ -177,6 +177,7 @@
> > /* Tegra186 and later */
> > #define WAKE_AOWAKE_CNTRL(x) (0x000 + ((x) << 2))
> > #define WAKE_AOWAKE_CNTRL_LEVEL (1 << 3)
> > +#define WAKE_AOWAKE_CNTRL_SR_CAPTURE_EN (1 << 1)
> > #define WAKE_AOWAKE_MASK_W(x) (0x180 + ((x) << 2))
> > #define WAKE_AOWAKE_MASK_R(x) (0x300 + ((x) << 2))
> > #define WAKE_AOWAKE_STATUS_W(x) (0x30c + ((x) << 2))
> > @@ -191,6 +192,8 @@
> > #define WAKE_AOWAKE_CTRL 0x4f4
> > #define WAKE_AOWAKE_CTRL_INTR_POLARITY BIT(0)
> >
> > +#define SW_WAKE_ID 83 /* wake83 */
> > +
> > /* for secure PMC */
> > #define TEGRA_SMC_PMC 0xc2fffe00
> > #define TEGRA_SMC_PMC_READ 0xaa
> > @@ -355,6 +358,7 @@ struct tegra_pmc_soc {
> > void (*setup_irq_polarity)(struct tegra_pmc *pmc,
> > struct device_node *np,
> > bool invert);
> > + void (*set_wake_filters)(struct tegra_pmc *pmc);
> > int (*irq_set_wake)(struct irq_data *data, unsigned int on);
> > int (*irq_set_type)(struct irq_data *data, unsigned int type);
> > int (*powergate_set)(struct tegra_pmc *pmc, unsigned int id,
> > @@ -2416,6 +2420,17 @@ static int tegra210_pmc_irq_set_type(struct irq_data *data, unsigned int type)
> > return 0;
> > }
> >
> > +static void tegra186_pmc_set_wake_filters(struct tegra_pmc *pmc)
> > +{
> > + u32 value;
> > +
> > + /* SW Wake (wake83) needs SR_CAPTURE filter to be enabled */
> > + value = readl(pmc->wake + WAKE_AOWAKE_CNTRL(SW_WAKE_ID));
> > + value |= WAKE_AOWAKE_CNTRL_SR_CAPTURE_EN;
> > + writel(value, pmc->wake + WAKE_AOWAKE_CNTRL(SW_WAKE_ID));
> > + dev_dbg(pmc->dev, "WAKE_AOWAKE_CNTRL_83 = 0x%x\n", value);
> > +}
>
> To me this needs to be moved to the SPE driver, which should get the PMC
> regmap handle and enable wake only when needed, similarly how it's done
> by USB Tegra drivers that also need to configure PMC. Otherwise this
> looks like a hack/workaround.
Wake is still only enabled when needed via the irq_set_wake() callback.
And this is slightly different in that it pretty has no side-effects. It
isn't a configuration option that needs to be switched every now and
then but rather just a bit in a register that happens to have the wrong
default value (or an inconvenient default value).
For USB there are actual side-effects and some of the settings only make
sense if a given USB port is actually used, etc. So doing the regmap
dance is actually worth it.
For SPE it just doesn't seem worth it to have all of these inter-
dependencies just for the sake of statically setting one bit once during
boot.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2023-04-04 11:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-30 17:06 [PATCH v2] soc/tegra: pmc: Support software wake-up for SPE Petlozu Pravareshwar
2023-04-03 12:36 ` Thierry Reding
2023-04-03 16:06 ` Dmitry Osipenko
2023-04-04 11:15 ` Thierry Reding [this message]
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=ZCwG0SM9szT6toGG@orome \
--to=thierry.reding@gmail.com \
--cc=cai.huoqing@linux.dev \
--cc=dmitry.osipenko@collabora.com \
--cc=jonathanh@nvidia.com \
--cc=kkartik@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=petlozup@nvidia.com \
--cc=spatra@nvidia.com \
--cc=ulf.hansson@linaro.org \
--cc=viswanathl@nvidia.com \
/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 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.