linux-kernel - Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 27 Aug 2014 15:41:43 -0400
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	Nishanth Menon <nm@...com>,
	Kevin Hilman <khilman@...prootsystems.com>
CC:	Paul Walmsley <paul@...an.com>, Tony Lindgren <tony@...mide.com>,
	Keerthy <j-keerthy@...com>, <daniel.lezcano@...aro.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Tero Kristo <t-kristo@...com>,
	Benoît Cousson <bcousson@...libre.com>,
	linux-omap <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support

On Wednesday 27 August 2014 03:35 PM, Nishanth Menon wrote:
> On Wed, Aug 27, 2014 at 2:13 PM, Kevin Hilman
> <khilman@...prootsystems.com> wrote:
>> + Daniel (cpuidle maintainer)
> [...]
>>> +static int omap_enter_idle_smp(struct cpuidle_device *dev,
>>> +                            struct cpuidle_driver *drv,
>>> +                            int index)
>>> +{
>>> +     struct idle_statedata *cx = state_ptr + index;
>>> +     unsigned long flag;
>>> +
>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>> +     cx->mpu_state_vote++;
>>> +     if (cx->mpu_state_vote == num_online_cpus()) {
>>> +             pwrdm_set_logic_retst(mpu_pd, cx->mpu_logic_state);
>>> +             omap_set_pwrdm_state(mpu_pd, cx->mpu_state);
>>> +     }
>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>> +
>>> +     omap4_enter_lowpower(dev->cpu, cx->cpu_state);
>>> +
>>> +     raw_spin_lock_irqsave(&mpu_lock, flag);
>>> +     if (cx->mpu_state_vote == num_online_cpus())
>>> +             omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
>>> +     cx->mpu_state_vote--;
>>> +     raw_spin_unlock_irqrestore(&mpu_lock, flag);
>>> +
>>> +     return index;
>>> +}
>>
>> Hmm, maybe OMAP5/DRA7 CPUidle driver should be a new one based on MCPM?
> 
> Trying to understand benefit of MCPM here - at least without a deeper
> understanding of mcpm infrastructure benefits (first look seemed a
> little heavy for OMAP5/DRA7 needs).
> 
> Neither DRA7/OMAP5 are multi-cluster, the SoCs are not targetted for
> "OFF" of CPU1/0, we have mercury hardware to help with context and
> sync issues.
> 
> Being able to reuse most of existing OMAP4 infrastructure code is
> useful as well to leave the existing omap4 framework as being lighter
> in complexity -esp in a cpuidle like hot path?
> 
> The spin_lock is only for the programming of MPU power domain in a
> consistent manner - I suppose might have been the trigger for
> proposing mcpm?
> 
Mostly not....

I think this is coming because last time Nicolas Pitre tried to convert
the OMAP CPUIdle into MCPM but because of various ordering requirements,
OMAP wasn't suitable and then the plan was dropped later.

Just to make clear, OMAP OMAP5/DRA7 as well the ordering requirement
remains the same for deeper states. Its just the mercury retention state
which we are able to enter without ordering requirements and hence
the voting scheme.

Hope this clarifies to you as well as Kevin just in case he missed the
part of the deeper C-states requirements.

Regards,
Santosh



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/