On 10 October 2012 19:37, Viresh Kumar <viresh.kumar(a)linaro.org> wrote:
> On 10 October 2012 19:14, Sudeep KarkadaNagesha
> <Sudeep.KarkadaNagesha(a)arm.com> wrote:
>> Here is my understanding on this patch. This change is closely related
>> to ACPI cpufreq driver(used mostly on Intel cores). This change was
>> introduced to keep track of the related cpus as returned by ACPI
>> firmware along with affected cpus as imposed by SW. I don't understand
>> the exact difference in Intel cores.
>> I believe it's just for tracking and not used much in the driver.
>
> Then i believe we shouldn't fill the related_cpus field for ARM cores. As anyway
> the show_related_cpus will pick affected cpus in that case.
Ahh, I was searching for something in my Archives and found this old
unanswered mail. As I have understood the difference between between
these two variables (affected and related cpus) now until this happened:
951fc5f4 (in v3.9). I thought it would be good to bury the actual answers
somewhere in Archives so that somebody looking for the answer can find
it easily.
What it was:
Affected CPUs: List of CPUs which share clock domain and s/w was responsible
to managing these.
Related CPUs: List of CPUs which share clock domain and only h/w was
responsible for managing these.
What do we mean by software and hardware managed stuff?
It was specific for acpi-cpufreq driver and nobody else :)
The firmware below kernel layer for hardware using this driver wanted to
manage cpus (sharing clock domain) by itself. i.e. It wanted the actual freq
request to go to it, it will then pick the highest freq requested for a clock
domain and set it for all cpus under policy->cpus. But kernel wouldn't know
these details at all. CPUFreq core would think that these cores don't
actually share clock line and so are independent.
Then there were some user space applications (like DVFS controllers),
which wanted to know the exact hardware coordination details rather than
what is present with cpufreq core. And so related_cpus was created for
them with this commit: e8628dd06d66f2e3965ec9742029b401d63434f1
related_cpus wasn't used in making kernel decisions at all and was only
for the applications who want to know exact hardware details.
As it didn't make sense to keep acpi-cpufreq specific stuff in CPUFreq core,
it was eventually moved into acpi-cpufreq driver with the name:
freqdomain_cpus in 3.11. related_cpus was kept in kernel but its meaning
is now changed.
affected_cpus: List of Online CPUs that require software coordination
of frequency.
related_cpus: List of Online + Offline CPUs that need software
coordination of frequency.
--
viresh
There has long been a syntax problem in iop3xx_i2c_wait_event() which
has been somehow hidden by the macros in <linux/wait.h>. After some
recent cleanup/rework of the wait_event_* helpers, the bug has come
out from hiding and now results in build failure:
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c: In function 'iop3xx_i2c_wait_event':
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:143: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:157: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:213: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:291: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:551: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:565: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:764: error: expected ')' before ';' token
/work/kernel/next/drivers/i2c/busses/i2c-iop3xx.c:176:778: error: expected ')' b
Fix by removing stray ';'
Signed-off-by: Kevin Hilman <khilman(a)linaro.org>
---
Discovered in new build failure of iop32xx_defconfig with next-20130628
drivers/i2c/busses/i2c-iop3xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-iop3xx.c b/drivers/i2c/busses/i2c-iop3xx.c
index bc99333..dd24aa0 100644
--- a/drivers/i2c/busses/i2c-iop3xx.c
+++ b/drivers/i2c/busses/i2c-iop3xx.c
@@ -176,7 +176,7 @@ iop3xx_i2c_wait_event(struct i2c_algo_iop3xx_data *iop3xx_adap,
interrupted = wait_event_interruptible_timeout (
iop3xx_adap->waitq,
(done = compare( sr = iop3xx_i2c_get_srstat(iop3xx_adap) ,flags )),
- 1 * HZ;
+ 1 * HZ
);
if ((rc = iop3xx_i2c_error(sr)) < 0) {
*status = sr;
--
1.8.3
From: Naresh Bhat <naresh.bhat(a)linaro.org>
CC drivers/acpi/fan.o
drivers/acpi/fan.c: In function ‘fan_get_cur_state’:
drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized]
---
drivers/acpi/fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index f815da8..f61f7fd 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -84,7 +84,7 @@ static int fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long
{
struct acpi_device *device = cdev->devdata;
int result;
- int acpi_state;
+ int acpi_state = 0;
if (!device)
return -EINVAL;
--
1.7.9.5
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.
In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.
This isn't obeyed by many of the drivers and core wasn't forcing it.
This patchset first fixes all the driver to follow it strictly and then adds
some protection against this. Now, we keep track of the last transaction and see
if something went wrong.
Last patch is intentionally kept towards the end, so that git bisect still works
well for all the faulty drivers.
This is pushed here and a pull request for 3.11 would be sent after few days.
git://git.linaro.org/people/vireshk/linux.git cpufreq-fix-notification
Viresh Kumar (13):
cpufreq: acpi: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: arm-big-little: call CPUFREQ_POSTCHANGE notfier in error
cases
cpufreq: davinci: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: dbx500: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: e_powersave: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: exynos: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: imx6q: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: omap: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: pcc: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: powernow-k8: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: s3c64xx: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: tegra: call CPUFREQ_POSTCHANGE notfier in error cases
cpufreq: make sure frequency transitions are serialized
drivers/cpufreq/acpi-cpufreq.c | 6 ++++--
drivers/cpufreq/arm_big_little.c | 4 +---
drivers/cpufreq/cpufreq.c | 9 +++++++++
drivers/cpufreq/davinci-cpufreq.c | 3 +++
drivers/cpufreq/dbx500-cpufreq.c | 4 ++--
drivers/cpufreq/e_powersaver.c | 3 +++
drivers/cpufreq/exynos-cpufreq.c | 10 ++++++++--
drivers/cpufreq/imx6q-cpufreq.c | 17 +++++++++++------
drivers/cpufreq/omap-cpufreq.c | 6 +++---
drivers/cpufreq/pcc-cpufreq.c | 2 ++
drivers/cpufreq/powernow-k8.c | 6 +++---
drivers/cpufreq/s3c64xx-cpufreq.c | 8 ++++++--
drivers/cpufreq/tegra-cpufreq.c | 4 ++--
13 files changed, 57 insertions(+), 25 deletions(-)
--
1.7.12.rc2.18.g61b472e
From: Naresh Bhat <naresh.bhat(a)linaro.org>
CC drivers/acpi/fan.o
drivers/acpi/fan.c: In function ‘fan_get_cur_state’:
drivers/acpi/fan.c:96:9: warning: ‘acpi_state’ may be used uninitialized in this function [-Wuninitialized]
---
drivers/acpi/fan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index f815da8..f61f7fd 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -84,7 +84,7 @@ static int fan_get_cur_state(struct thermal_cooling_device *cdev, unsigned long
{
struct acpi_device *device = cdev->devdata;
int result;
- int acpi_state;
+ int acpi_state = 0;
if (!device)
return -EINVAL;
--
1.7.9.5