linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Sowjanya Komatineni <skomatineni@nvidia.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: Tue, 23 Jul 2019 06:25:45 +0300	[thread overview]
Message-ID: <71c8cab1-bf72-c073-be30-4263c6b7c871@gmail.com> (raw)
In-Reply-To: <629826f9-c453-386a-9e88-bd64d23b8eab@nvidia.com>

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.

>>> 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]


  reply	other threads:[~2019-07-23  3:25 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 [this message]
2019-07-23  3:31                 ` Sowjanya Komatineni
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=71c8cab1-bf72-c073-be30-4263c6b7c871@gmail.com \
    --to=digetx@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --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=skomatineni@nvidia.com \
    --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).