| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 22 Jul 2019 20:09:47 -0700
From: Sowjanya Komatineni <skomatineni@...dia.com>
To: Dmitry Osipenko <digetx@...il.com>, <thierry.reding@...il.com>,
<jonathanh@...dia.com>, <tglx@...utronix.de>,
<jason@...edaemon.net>, <marc.zyngier@....com>,
<linus.walleij@...aro.org>, <stefan@...er.ch>,
<mark.rutland@....com>
CC: <pdeschrijver@...dia.com>, <pgaikwad@...dia.com>,
<sboyd@...nel.org>, <linux-clk@...r.kernel.org>,
<linux-gpio@...r.kernel.org>, <jckuo@...dia.com>,
<josephl@...dia.com>, <talho@...dia.com>,
<linux-tegra@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<mperttunen@...dia.com>, <spatra@...dia.com>, <robh+dt@...nel.org>,
<devicetree@...r.kernel.org>
Subject: Re: [PATCH V6 16/21] soc/tegra: pmc: Add pmc wake support for
tegra210
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@...dia.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.
>> 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]
Powered by blists - more mailing lists