From: Sowjanya Komatineni <skomatineni@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>, <thierry.reding@gmail.com>,
<jonathanh@nvidia.com>, <tglx@linutronix.de>,
<jason@lakedaemon.net>, <marc.zyngier@arm.com>,
<linus.walleij@linaro.org>, <stefan@agner.ch>,
<mark.rutland@arm.com>
Cc: <pdeschrijver@nvidia.com>, <pgaikwad@nvidia.com>,
<sboyd@kernel.org>, <linux-clk@vger.kernel.org>,
<linux-gpio@vger.kernel.org>, <jckuo@nvidia.com>,
<josephl@nvidia.com>, <talho@nvidia.com>,
<linux-tegra@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<mperttunen@nvidia.com>, <spatra@nvidia.com>,
<robh+dt@kernel.org>, <devicetree@vger.kernel.org>
Subject: Re: [PATCH V6 16/21] soc/tegra: pmc: Add pmc wake support for tegra210
Date: Mon, 22 Jul 2019 20:31:02 -0700 [thread overview]
Message-ID: <97096b6c-f2f5-b82a-b172-802f4a06d1af@nvidia.com> (raw)
In-Reply-To: <71c8cab1-bf72-c073-be30-4263c6b7c871@gmail.com>
On 7/22/19 8:25 PM, Dmitry Osipenko wrote:
> 23.07.2019 6:09, Sowjanya Komatineni пишет:
>> On 7/22/19 8:03 PM, Dmitry Osipenko wrote:
>>> 23.07.2019 4:52, Sowjanya Komatineni пишет:
>>>> On 7/22/19 6:41 PM, Dmitry Osipenko wrote:
>>>>> 23.07.2019 4:08, Dmitry Osipenko пишет:
>>>>>> 23.07.2019 3:58, Dmitry Osipenko пишет:
>>>>>>> 21.07.2019 22:40, Sowjanya Komatineni пишет:
>>>>>>>> This patch implements PMC wakeup sequence for Tegra210 and defines
>>>>>>>> common used RTC alarm wake event.
>>>>>>>>
>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
>>>>>>>> ---
>>>>>>>> drivers/soc/tegra/pmc.c | 111
>>>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>>> 1 file changed, 111 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
>>>>>>>> index 91c84d0e66ae..c556f38874e1 100644
>>>>>>>> --- a/drivers/soc/tegra/pmc.c
>>>>>>>> +++ b/drivers/soc/tegra/pmc.c
>>>>>>>> @@ -57,6 +57,12 @@
>>>>>>>> #define PMC_CNTRL_SYSCLK_OE BIT(11) /* system clock
>>>>>>>> enable */
>>>>>>>> #define PMC_CNTRL_SYSCLK_POLARITY BIT(10) /* sys clk
>>>>>>>> polarity */
>>>>>>>> #define PMC_CNTRL_MAIN_RST BIT(4)
>>>>>>>> +#define PMC_CNTRL_LATCH_WAKEUPS BIT(5)
>>>>>> Please follow the TRM's bits naming.
>>>>>>
>>>>>> PMC_CNTRL_LATCHWAKE_EN
>>>>>>
>>>>>>>> +#define PMC_WAKE_MASK 0x0c
>>>>>>>> +#define PMC_WAKE_LEVEL 0x10
>>>>>>>> +#define PMC_WAKE_STATUS 0x14
>>>>>>>> +#define PMC_SW_WAKE_STATUS 0x18
>>>>>>>> #define DPD_SAMPLE 0x020
>>>>>>>> #define DPD_SAMPLE_ENABLE BIT(0)
>>>>>>>> @@ -87,6 +93,11 @@
>>>>>>>> #define PMC_SCRATCH41 0x140
>>>>>>>> +#define PMC_WAKE2_MASK 0x160
>>>>>>>> +#define PMC_WAKE2_LEVEL 0x164
>>>>>>>> +#define PMC_WAKE2_STATUS 0x168
>>>>>>>> +#define PMC_SW_WAKE2_STATUS 0x16c
>>>>>>>> +
>>>>>>>> #define PMC_SENSOR_CTRL 0x1b0
>>>>>>>> #define PMC_SENSOR_CTRL_SCRATCH_WRITE BIT(2)
>>>>>>>> #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
>>>>>>>> @@ -1922,6 +1933,55 @@ static const struct irq_domain_ops
>>>>>>>> tegra_pmc_irq_domain_ops = {
>>>>>>>> .alloc = tegra_pmc_irq_alloc,
>>>>>>>> };
>>>>>>>> +static int tegra210_pmc_irq_set_wake(struct irq_data *data,
>>>>>>>> unsigned int on)
>>>>>>>> +{
>>>>>>>> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>>>>>>>> + unsigned int offset, bit;
>>>>>>>> + u32 value;
>>>>>>>> +
>>>>>>>> + if (data->hwirq == ULONG_MAX)
>>>>>>>> + return 0;
>>>>>>>> +
>>>>>>>> + offset = data->hwirq / 32;
>>>>>>>> + bit = data->hwirq % 32;
>>>>>>>> +
>>>>>>>> + /*
>>>>>>>> + * Latch wakeups to SW_WAKE_STATUS register to capture events
>>>>>>>> + * that would not make it into wakeup event register during
>>>>>>>> LP0 exit.
>>>>>>>> + */
>>>>>>>> + value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>>>>>> + value |= PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>> + udelay(120);
>>>>>>> Why it takes so much time to latch the values? Shouldn't some
>>>>>>> status-bit
>>>>>>> be polled for the completion of latching?
>>>>>>>
>>>>>>> Is this register-write really getting buffered in the PMC?
>>>>>>>
>>>>>>>> + value &= ~PMC_CNTRL_LATCH_WAKEUPS;
>>>>>>>> + tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>>> + udelay(120);
>>>>>>> 120 usecs to remove latching, really?
>>>>>>>
>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE_STATUS);
>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_SW_WAKE2_STATUS);
>>>>>>>> +
>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_WAKE_STATUS);
>>>>>>>> + tegra_pmc_writel(pmc, 0, PMC_WAKE2_STATUS);
>>>>>>>> +
>>>>>>>> + /* enable PMC wake */
>>>>>>>> + if (data->hwirq >= 32)
>>>>>>>> + offset = PMC_WAKE2_MASK;
>>>>>>>> + else
>>>>>>>> + offset = PMC_WAKE_MASK;
>>>>>>>> +
>>>>>>>> + value = tegra_pmc_readl(pmc, offset);
>>>>>>>> +
>>>>>>>> + if (on)
>>>>>>>> + value |= 1 << bit;
>>>>>>>> + else
>>>>>>>> + value &= ~(1 << bit);
>>>>>>>> +
>>>>>>>> + tegra_pmc_writel(pmc, value, offset);
>>>>>>> Why the latching is done *before* writing into the WAKE registers?
>>>>>>> What
>>>>>>> it is latching then?
>>>>>> I'm looking at the TRM doc and it says that latching should be done
>>>>>> *after* writing to the WAKE_MASK / LEVEL registers.
>>>>>>
>>>>>> Secondly it says that it's enough to do:
>>>>>>
>>>>>> value = tegra_pmc_readl(pmc, PMC_CNTRL);
>>>>>> value |= PMC_CNTRL_LATCH_WAKEUPS;
>>>>>> tegra_pmc_writel(pmc, value, PMC_CNTRL);
>>>>>>
>>>>>> in order to latch. There is no need for the delay and to remove the
>>>>>> "LATCHWAKE_EN" bit, it should be a oneshot action.
>>>>> Although, no. TRM says "stops latching on transition from 1
>>>>> to 0 (sequence - set to 1,set to 0)", so it's not a oneshot action.
>>>>>
>>>>> Have you tested this code at all? I'm wondering how it happens to work
>>>>> without a proper latching.
>>>> Yes, ofcourse its tested and this sequence to do transition is
>>>> recommendation from Tegra designer.
>>>> Will check if TRM doesn't have update properly or will re-confirm
>>>> internally on delay time...
>>>>
>>>> On any of the wake event PMC wakeup happens and WAKE_STATUS register
>>>> will have bits set for all events that triggered wake.
>>>> After wakeup PMC doesn't update SW_WAKE_STATUS register as per PMC
>>>> design.
>>>> SW latch register added in design helps to provide a way to capture
>>>> those events that happen right during wakeup time and didnt make it to
>>>> SW_WAKE_STATUS register.
>>>> So before next suspend entry, latching all prior wake events into SW
>>>> WAKE_STATUS and then clearing them.
>>> I'm now wondering whether the latching cold be turned ON permanently
>>> during of the PMC's probe, for simplicity.
>> latching should be done on suspend-resume cycle as wake events gets
>> generates on every suspend-resume cycle.
> You're saying that PMC "doesn't update SW_WAKE_STATUS" after wake-up,
> then I don't quite understand what's the point of disabling the latching
> at all.
When latch wake enable is set, events are latched and during 1 to 0
transition latching is disabled.
This is to avoid sw_wake_status and wake_status showing diff events.
Currently driver is not relying on SW_WAKE_STATUS but its good to latch
and clear so even at some point for some reason when SW_WAKE_STATUS is
used, this wlil not cause mismatch with wake_status.
>>>> LATCHWAKE_EN - When set, enables latching and stops latching on
>>>> transition from 1 to 0
>>>> There is recommendation of min 120uSec for this transition to stop
>>>> latching. Will double-check why 120uSec
>>> Yes, please check.
>>>
>>>>>>>> + return 0;
>>>>>>>> +}
>>>>>>>> +
>>>>>>>> static int tegra186_pmc_irq_set_wake(struct irq_data *data,
>>>>>>>> unsigned int on)
>>>>>>>> {
>>>>>>>> struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>>>>>>>> @@ -1954,6 +2014,49 @@ static int
>>>>>>>> tegra186_pmc_irq_set_wake(struct irq_data *data, unsigned int on)
>>>>>>>> return 0;
>>>>>>>> }
>>>>>>>> +static int tegra210_pmc_irq_set_type(struct irq_data *data,
>>>>>>>> unsigned int type)
>>>>>>>> +{
>>>>>>>> + struct tegra_pmc *pmc = irq_data_get_irq_chip_data(data);
>>>>>>>> + unsigned int offset, bit;
>>>>>>>> + u32 value;
>>>>>>>> +
>>>>>>>> + if (data->hwirq == ULONG_MAX)
>>>>>>>> + return 0;
>>>>>>>> +
>>>>>>>> + offset = data->hwirq / 32;
>>>>>>>> + bit = data->hwirq % 32;
>>>>>>>> +
>>>>>>>> + if (data->hwirq >= 32)
>>>>>>>> + offset = PMC_WAKE2_LEVEL;
>>>>>>>> + else
>>>>>>>> + offset = PMC_WAKE_LEVEL;
>>>>>>>> +
>>>>>>>> + value = tegra_pmc_readl(pmc, offset);
>>>>>>>> +
>>>>>>>> + switch (type) {
>>>>>>>> + case IRQ_TYPE_EDGE_RISING:
>>>>>>>> + case IRQ_TYPE_LEVEL_HIGH:
>>>>>>>> + value |= 1 << bit;
>>>>>>>> + break;
>>>>>>>> +
>>>>>>>> + case IRQ_TYPE_EDGE_FALLING:
>>>>>>>> + case IRQ_TYPE_LEVEL_LOW:
>>>>>>>> + value &= ~(1 << bit);
>>>>>>>> + break;
>>>>>>>> +
>>>>>>>> + case IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING:
>>>>>>>> + value ^= 1 << bit;
>>>>>>>> + break;
>>>>>>>> +
>>>>>>>> + default:
>>>>>>>> + return -EINVAL;
>>>>>>>> + }
>>>>>>>> +
>>>>>>>> + tegra_pmc_writel(pmc, value, offset);
>>>>>>> Shouldn't the WAKE_LEVEL be latched as well?
>>>> WAKE_LEVELs dont need any latch as they are the levels SW sets for wake
>>>> trigger and they are not status
>>> Okay.
>>>
>>> [snip]
next prev parent reply other threads:[~2019-07-23 3:31 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-21 19:40 [PATCH V6 00/21] SC7 entry and exit support for Tegra210 Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 01/21] irqchip: tegra: Do not disable COP IRQ during suspend Sowjanya Komatineni
2019-07-21 20:24 ` Marc Zyngier
2019-07-22 9:54 ` Dmitry Osipenko
2019-07-22 10:13 ` Marc Zyngier
2019-07-22 10:57 ` Dmitry Osipenko
2019-07-22 16:21 ` Sowjanya Komatineni
2019-07-22 18:38 ` Marc Zyngier
2019-07-22 23:35 ` Dmitry Osipenko
2019-07-24 23:09 ` Sowjanya Komatineni
2019-07-26 4:48 ` Dmitry Osipenko
2019-07-25 9:55 ` Peter De Schrijver
2019-07-25 10:05 ` Dmitry Osipenko
2019-07-25 10:33 ` Peter De Schrijver
2019-07-25 10:38 ` Peter De Schrijver
2019-07-25 10:59 ` Dmitry Osipenko
2019-08-02 13:05 ` Peter De Schrijver
2019-08-02 17:35 ` Dmitry Osipenko
2019-07-21 19:40 ` [PATCH V6 02/21] pinctrl: tegra: Add suspend and resume support Sowjanya Komatineni
2019-07-21 22:03 ` Dmitry Osipenko
2019-07-21 22:09 ` Dmitry Osipenko
2019-07-21 22:48 ` Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 03/21] pinctrl: tegra210: Add Tegra210 pinctrl pm ops Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 04/21] clk: tegra: Save and restore divider rate Sowjanya Komatineni
2019-07-21 22:14 ` Dmitry Osipenko
2019-07-21 19:40 ` [PATCH V6 05/21] clk: tegra: pllout: Save and restore pllout context Sowjanya Komatineni
2019-07-21 22:18 ` Dmitry Osipenko
2019-07-21 19:40 ` [PATCH V6 06/21] clk: tegra: pll: Save and restore pll context Sowjanya Komatineni
2019-07-21 21:44 ` Dmitry Osipenko
2019-07-21 22:47 ` Sowjanya Komatineni
2019-07-21 22:21 ` Dmitry Osipenko
2019-07-22 3:22 ` Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 07/21] clk: tegra: Support for OSC context save and restore Sowjanya Komatineni
2019-07-22 10:12 ` Dmitry Osipenko
2019-07-21 19:40 ` [PATCH V6 08/21] clk: tegra: clk-periph: Add save and restore support Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 09/21] clk: tegra: clk-super: Fix to enable PLLP branches to CPU Sowjanya Komatineni
2019-07-21 21:16 ` Dmitry Osipenko
2019-07-21 22:39 ` Sowjanya Komatineni
2019-07-22 3:17 ` Sowjanya Komatineni
2019-07-22 6:32 ` Dmitry Osipenko
2019-07-22 7:12 ` Sowjanya Komatineni
2019-07-22 7:17 ` Dmitry Osipenko
2019-07-22 7:24 ` Sowjanya Komatineni
2019-07-22 7:30 ` Dmitry Osipenko
2019-07-22 7:36 ` Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 10/21] clk: tegra: clk-super: Add save and restore support Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 11/21] clk: tegra: clk-dfll: Add suspend and resume support Sowjanya Komatineni
2019-07-21 21:32 ` Dmitry Osipenko
2019-07-21 22:42 ` Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 12/21] cpufreq: tegra124: " Sowjanya Komatineni
2019-07-21 21:04 ` Dmitry Osipenko
2019-07-21 19:40 ` [PATCH V6 13/21] clk: tegra210: Use fence_udelay during PLLU init Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 14/21] clk: tegra210: Add suspend and resume support Sowjanya Komatineni
2019-07-21 21:38 ` Dmitry Osipenko
2019-07-21 22:45 ` Sowjanya Komatineni
2019-07-22 6:10 ` Dmitry Osipenko
2019-07-22 6:52 ` Sowjanya Komatineni
2019-07-22 7:09 ` Dmitry Osipenko
2019-07-22 7:12 ` Dmitry Osipenko
2019-08-02 17:51 ` Stephen Boyd
2019-08-02 20:39 ` Sowjanya Komatineni
2019-08-07 21:22 ` Stephen Boyd
2019-07-21 19:40 ` [PATCH V6 15/21] soc/tegra: pmc: Allow to support more tegras wake Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 16/21] soc/tegra: pmc: Add pmc wake support for tegra210 Sowjanya Komatineni
2019-07-23 0:58 ` Dmitry Osipenko
2019-07-23 1:08 ` Dmitry Osipenko
2019-07-23 1:41 ` Dmitry Osipenko
2019-07-23 1:52 ` Dmitry Osipenko
2019-07-23 2:10 ` Dmitry Osipenko
[not found] ` <71a88a9c-a542-557a-0eaa-3c90112dee0e@nvidia.com>
2019-07-23 3:03 ` Dmitry Osipenko
2019-07-23 3:09 ` Sowjanya Komatineni
2019-07-23 3:25 ` Dmitry Osipenko
2019-07-23 3:31 ` Sowjanya Komatineni [this message]
2019-07-23 3:43 ` Dmitry Osipenko
2019-07-23 14:27 ` Dmitry Osipenko
2019-07-23 23:39 ` Sowjanya Komatineni
2019-07-24 9:31 ` Dmitry Osipenko
2019-07-21 19:40 ` [PATCH V6 17/21] arm64: tegra: Enable wake from deep sleep on RTC alarm Sowjanya Komatineni
2019-07-26 6:30 ` Dmitry Osipenko
2019-07-21 19:40 ` [PATCH V6 18/21] soc/tegra: pmc: Configure core power request polarity Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 19/21] soc/tegra: pmc: Configure deep sleep control settings Sowjanya Komatineni
2019-07-21 19:40 ` [PATCH V6 20/21] arm64: dts: tegra210-p2180: Jetson TX1 SC7 timings Sowjanya Komatineni
2019-07-21 19:41 ` [PATCH V6 21/21] arm64: dts: tegra210-p3450: Jetson nano " Sowjanya Komatineni
2019-07-21 22:25 ` Dmitry Osipenko
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=97096b6c-f2f5-b82a-b172-802f4a06d1af@nvidia.com \
--to=skomatineni@nvidia.com \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=jason@lakedaemon.net \
--cc=jckuo@nvidia.com \
--cc=jonathanh@nvidia.com \
--cc=josephl@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=mperttunen@nvidia.com \
--cc=pdeschrijver@nvidia.com \
--cc=pgaikwad@nvidia.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=spatra@nvidia.com \
--cc=stefan@agner.ch \
--cc=talho@nvidia.com \
--cc=tglx@linutronix.de \
--cc=thierry.reding@gmail.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 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).