linux-kernel - Re: [RFC] cpufreq: send notifications for intermediate (stable) frequencies

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]

Message-ID: <537512E0.7000102@wwwdotorg.org>
Date:	Thu, 15 May 2014 13:17:52 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Viresh Kumar <viresh.kumar@...aro.org>, rjw@...ysocki.net
CC:	linaro-kernel@...ts.linaro.org, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, arvind.chauhan@....com,
	swarren@...dia.com, nicolas.pitre@...aro.org,
	dianders@...omium.org, linux@....linux.org.uk
Subject: Re: [RFC] cpufreq: send notifications for intermediate (stable) frequencies

On 05/14/2014 11:56 PM, Viresh Kumar wrote:
> Douglas Anderson, recently pointed out an interesting problem due to which his
> udelay() was expiring earlier than it should:
> https://lkml.org/lkml/2014/5/13/766
> 
> While transitioning between frequencies few platforms may temporarily switch to
> a stable frequency, waiting for the main PLL to stabilize.
> 
> For example: When we transition between very low frequencies on exynos, like
> between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
> No CPUFREQ notification is sent for that. That means there's a period of time
> when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
> and 300MHz. And so udelay behaves badly.
> 
> To get this fixed in a generic way, lets introduce another callback safe_freq()
> for the cpufreq drivers.
> 
> safe_freq() should return a stable intermediate frequency a platform might want
> to switch to, before jumping to the frequency corresponding to 'index'. Core
> will send the 'PRE' notification for this 'stable' frequency and 'POST' for the
> 'target' frequency. Though if ->target_index() fails, it will handle POST for
> 'stable' frequency only.
> 
> Drivers must send 'POST' notification for 'stable' freq and 'PRE' for 'target'
> freq. If they can't switch to target frequency, they don't need to send any
> notification.

This seems rather complex. Can't either the driver or the cpufreq core
be responsible for all of the notifications? Otherwise, the logic gets
rather complex, and spread between the core and the driver.

Perhaps the core should make separate calls into the driver to switch to
the temporary frequency and the final frequency, so it can manage all
the notifications. Probably best to use a separate function pointer for
the temporary change so the driver can easily know what it's doing.
--
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/