Re: [PATCH] powerpc: Check flat device tree version at boot
On Thu, 2014-08-28 at 09:27 -0500, Rob Herring wrote: > On Thu, Aug 28, 2014 at 3:40 AM, Michael Ellerman wrote: > > In commit e6a6928c3ea1 "of/fdt: Convert FDT functions to use libfdt", > > the kernel stopped supporting old flat device tree formats. The minimum > > supported version is now 0x10. > > Ugg. Is that something which needs to be supported? Supporting it at > this point would mean adding support to libfdt. Well it would have been nice to keep supporting v2, dropping it broke kexec-tools for example. But it's done now, so we'll just deal with the fallout. If you can CC linuxppc-dev in future on patches that fundamentally change the device tree parsing that would be appreciated :) cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec
On 28 August 2014 19:36, Shilpasri G Bhat
wrote:
> This patch ensures the cpus to kexec/reboot at nominal frequency.
> Nominal frequency is the highest cpu frequency on PowerPC at
> which the cores can run without getting throttled.
>
> If the host kernel had set the cpus to a low pstate and then it
> kexecs/reboots to a cpufreq disabled kernel it would cause the target
> kernel to perform poorly. It will also increase the boot up time of
> the target kernel. So set the cpus to high pstate, in this case to
> nominal frequency before rebooting to avoid such scenarios.
>
> The reboot notifier will set the cpus to nominal frequncy.
>
> Changes v1->v2:
> Invoke .target() driver callback to set the cpus to nominal frequency
> in reboot notifier, instead of calling cpufreq_suspend() as suggested
> by Viresh Kumar.
> Modified the commit message.
This changelog will get commited, is this what you want?
> Signed-off-by: Shilpasri G Bhat
> Reviewed-by: Preeti U Murthy
> ---
> drivers/cpufreq/powernv-cpufreq.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index 379c083..ba27c49 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -35,6 +36,7 @@
> #define POWERNV_MAX_PSTATES256
>
> static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
> +static bool rebooting;
>
> /*
> * Note: The set of pstates consists of contiguous integers, the
> @@ -284,6 +286,15 @@ static void set_pstate(void *freq_data)
> }
>
> /*
> + * get_nominal_index: Returns the index corresponding to the nominal
> + * pstate in the cpufreq table
> + */
> +static inline unsigned int get_nominal_index(void)
> +{
> + return powernv_pstate_info.max - powernv_pstate_info.nominal;
> +}
> +
> +/*
> * powernv_cpufreq_target_index: Sets the frequency corresponding to
> * the cpufreq table entry indexed by new_index on the cpus in the
> * mask policy->cpus
> @@ -293,6 +304,9 @@ static int powernv_cpufreq_target_index(struct
> cpufreq_policy *policy,
> {
> struct powernv_smp_call_data freq_data;
>
> + if (unlikely(rebooting) && new_index != get_nominal_index())
> + return -EBUSY;
Have you placed the unlikely only around 'rebooting' intentionally or
should it cover whole if statement?
> +
> freq_data.pstate_id = powernv_freqs[new_index].driver_data;
>
> /*
> @@ -317,6 +331,25 @@ static int powernv_cpufreq_cpu_init(struct
> cpufreq_policy *policy)
> return cpufreq_table_validate_and_show(policy, powernv_freqs);
> }
>
> +static int powernv_cpufreq_reboot_notifier(struct notifier_block *nb,
> + unsigned long action, void *unused)
> +{
> + int cpu;
> + struct cpufreq_policy cpu_policy;
> +
> + rebooting = true;
> + for_each_online_cpu(cpu) {
> + cpufreq_get_policy(&cpu_policy, cpu);
> + powernv_cpufreq_target_index(&cpu_policy,
> get_nominal_index());
> + }
> +
> + return NOTIFY_DONE;
> +}
> +
> +static struct notifier_block powernv_cpufreq_reboot_nb = {
> + .notifier_call = powernv_cpufreq_reboot_notifier,
> +};
> +
> static struct cpufreq_driver powernv_cpufreq_driver = {
> .name = "powernv-cpufreq",
> .flags = CPUFREQ_CONST_LOOPS,
> @@ -342,12 +375,14 @@ static int __init powernv_cpufreq_init(void)
> return rc;
> }
>
> + register_reboot_notifier(&powernv_cpufreq_reboot_nb);
> return cpufreq_register_driver(&powernv_cpufreq_driver);
> }
> module_init(powernv_cpufreq_init);
>
> static void __exit powernv_cpufreq_exit(void)
> {
> + unregister_reboot_notifier(&powernv_cpufreq_reboot_nb);
> cpufreq_unregister_driver(&powernv_cpufreq_driver);
> }
> module_exit(powernv_cpufreq_exit);
Looks fine otherwise.
Acked-by: Viresh Kumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux 3.16: all my drivers on SPI bus report WARNING: at drivers/base/dd.c:286
On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe wrote: > I've been able to identify the origin of the issue. It happens since the > below commit. > Do you know what should be done to fix that ? > > Christophe > Actually, more things are wrong with what the driver is doing. If inside spi_add_device() the call to device_add() fails, then that code bails out without any call to spi_cleanup() and the same memory will leak (Is this intended?). Basically, fsl_spi_setup allocates memory using devm_kzalloc, while device_add expects that any memory allocated via this way is only done in the device's probe function. The simple fix would be to do a normal allocation (revert the patch) and add a free to the cleanup() function. Unfortunately that doesn't fix the memleak I mentioned above. So, some outside-the-box thinking brings me to conclude that another way to fix this problem is to allocate the devm_kzalloc not on the device's resource list but on the controller's resources (it's controller state after all...). Regards, Stijn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] drivers: char: hw_random: printk replacement
as pr_* macros are more preffered over printk, so printk replaced with
corresponding pr_* macros
Signed-off-by: Sudip Mukherjee
---
The replacement was done by a bash script to avoid copy paste error. The script
is as follows :
OLD="printk(KERN_ERR \?"
OLD1="printk(KERN_NOTICE \?"
OLD2="printk(KERN_WARNING \?"
OLD3="printk(KERN_INFO \?"
NEW="pr_err("
NEW1="pr_notice("
NEW2="pr_warn("
NEW3="pr_info("
TFILE="/tmp/out.tmp.$$"
for f in *.c
do
sed -e "s/$OLD/$NEW/g" -e "s/$OLD1/$NEW1/g" -e "s/$OLD2/$NEW2/g" -e
"s/$OLD3/$NEW3/g" "$f" > $TFILE && mv $TFILE "$f"
done
Frankly speaking this script has missed one instance of printk(warning) in
intel-rng.c file , and this one was edited manually.
drivers/char/hw_random/amd-rng.c | 4 ++--
drivers/char/hw_random/geode-rng.c | 4 ++--
drivers/char/hw_random/intel-rng.c | 12 ++--
drivers/char/hw_random/pasemi-rng.c | 2 +-
drivers/char/hw_random/pseries-rng.c | 2 +-
drivers/char/hw_random/via-rng.c | 8
6 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index c6af038..48f6a83 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -142,10 +142,10 @@ found:
amd_rng.priv = (unsigned long)pmbase;
amd_pdev = pdev;
- printk(KERN_INFO "AMD768 RNG detected\n");
+ pr_info("AMD768 RNG detected\n");
err = hwrng_register(&amd_rng);
if (err) {
- printk(KERN_ERR PFX "RNG registering failed (%d)\n",
+ pr_err(PFX "RNG registering failed (%d)\n",
err);
release_region(pmbase + 0xF0, 8);
goto out;
diff --git a/drivers/char/hw_random/geode-rng.c
b/drivers/char/hw_random/geode-rng.c
index 4c4d4e1..0d0579f 100644
--- a/drivers/char/hw_random/geode-rng.c
+++ b/drivers/char/hw_random/geode-rng.c
@@ -109,10 +109,10 @@ found:
goto out;
geode_rng.priv = (unsigned long)mem;
- printk(KERN_INFO "AMD Geode RNG detected\n");
+ pr_info("AMD Geode RNG detected\n");
err = hwrng_register(&geode_rng);
if (err) {
- printk(KERN_ERR PFX "RNG registering failed (%d)\n",
+ pr_err(PFX "RNG registering failed (%d)\n",
err);
goto err_unmap;
}
diff --git a/drivers/char/hw_random/intel-rng.c
b/drivers/char/hw_random/intel-rng.c
index 86fe45c..3122376 100644
--- a/drivers/char/hw_random/intel-rng.c
+++ b/drivers/char/hw_random/intel-rng.c
@@ -199,7 +199,7 @@ static int intel_rng_init(struct hwrng *rng)
if ((hw_status & INTEL_RNG_ENABLED) == 0)
hw_status = hwstatus_set(mem, hw_status | INTEL_RNG_ENABLED);
if ((hw_status & INTEL_RNG_ENABLED) == 0) {
- printk(KERN_ERR PFX "cannot enable RNG, aborting\n");
+ pr_err(PFX "cannot enable RNG, aborting\n");
goto out;
}
err = 0;
@@ -216,7 +216,7 @@ static void intel_rng_cleanup(struct hwrng *rng)
if (hw_status & INTEL_RNG_ENABLED)
hwstatus_set(mem, hw_status & ~INTEL_RNG_ENABLED);
else
- printk(KERN_WARNING PFX "unusual: RNG already disabled\n");
+ pr_warn(PFX "unusual: RNG already disabled\n");
}
@@ -274,7 +274,7 @@ static int __init intel_rng_hw_init(void *_intel_rng_hw)
if (mfc != INTEL_FWH_MANUFACTURER_CODE ||
(dvc != INTEL_FWH_DEVICE_CODE_8M &&
dvc != INTEL_FWH_DEVICE_CODE_4M)) {
- printk(KERN_NOTICE PFX "FWH not detected\n");
+ pr_notice(PFX "FWH not detected\n");
return -ENODEV;
}
@@ -314,7 +314,7 @@ PFX "RNG, try using the 'no_fwh_detect' option.\n";
if (no_fwh_detect)
return -ENODEV;
- printk(warning);
+ pr_warn(warning);
return -EBUSY;
}
@@ -392,10 +392,10 @@ fwh_done:
goto out;
}
- printk(KERN_INFO "Intel 82802 RNG detected\n");
+ pr_info("Intel 82802 RNG detected\n");
err = hwrng_register(&intel_rng);
if (err) {
- printk(KERN_ERR PFX "RNG registering failed (%d)\n",
+ pr_err(PFX "RNG registering failed (%d)\n",
err);
iounmap(mem);
}
diff --git a/drivers/char/hw_random/pasemi-rng.c
b/drivers/char/hw_random/pasemi-rng.c
index c66279b..c0347d1 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -113,7 +113,7 @@ static int rng_probe(struct platform_device *ofdev)
pasemi_rng.priv = (unsigned long)rng_regs;
- printk(KERN_INFO "Registering PA Semi RNG\n");
+ pr_info("Registering PA Semi RNG\n");
err = hwrng_register(&pasemi_rng);
diff --git a/drivers/char/hw_random/pseries-rng.c
b/drivers/char/hw_random/pseries-rng.c
in
Re: Linux 3.16: all my drivers on SPI bus report WARNING: at drivers/base/dd.c:286
On Thu, Aug 28, 2014 at 5:53 PM, leroy christophe wrote: > > I've been able to identify the origin of the issue. It happens since the > below commit. > Do you know what should be done to fix that ? > > Christophe > > Actually, more things are wrong with what the driver is doing. If inside spi_add_device() the call to device_add() fails, then that code bails out without any call to spi_cleanup() and the same memory will leak (Is this intended?). Basically, fsl_spi_setup allocates memory using devm_kzalloc, while device_add expects that any memory allocated via this way is only done in the device's probe function. The simple fix would be to do a normal allocation (revert the patch) and add a free to the cleanup() function. Unfortunately that doesn't fix the memleak I mentioned above. So, some outside-the-box thinking brings me to conclude that another way to fix this problem is to allocate the devm_kzalloc not on the device's resource list but on the controller's resources (it's controller state after all...). Regards, Stijn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support
On Thu, 2014-08-28 at 05:05 -0500, Lu Jingchang-B35083 wrote: > >-Original Message- > >From: Wood Scott-B07421 > >Sent: Thursday, August 28, 2014 7:34 AM > >To: Lu Jingchang-B35083 > >Cc: mturque...@linaro.org; linuxppc-dev@lists.ozlabs.org; linux- > >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms > >CLK_OF_DECLARE support > > > >On Tue, 2014-08-26 at 21:19 -0500, Lu Jingchang-B35083 wrote: > >> >-Original Message- > >> >From: Wood Scott-B07421 > >> >Sent: Wednesday, August 27, 2014 6:51 AM > >> >To: Lu Jingchang-B35083 > >> >Cc: mturque...@linaro.org; linuxppc-dev@lists.ozlabs.org; linux- > >> >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > >> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based > >> >platforms CLK_OF_DECLARE support > >> > > >> >On Fri, 2014-08-22 at 17:34 +0800, Jingchang Lu wrote: > >> >> +CLK_OF_DECLARE(ppc_core_pll_v1, "fsl,qoriq-core-pll-1.0", > >> >core_pll_init); > >> >> +CLK_OF_DECLARE(ppc_core_pll_v2, "fsl,qoriq-core-pll-2.0", > >> >core_pll_init); > >> >> +CLK_OF_DECLARE(ppc_core_mux_v1, "fsl,qoriq-core-mux-1.0", > >> >core_mux_init); > >> >> +CLK_OF_DECLARE(ppc_core_mux_v2, "fsl,qoriq-core-mux-2.0", > >> >core_mux_init); > >> > > >> >What does this do that the existing platform driver and match table > >> >don't? Why is it needed for ARM when PPC didn't need it? > >> > > >> >-Scott > >> > > >> Common clk init on ARM platform is initialized earlier via > >> of_clk_init() instead of driver probe method, the of_clk_init will > >> walk a __clk_of_table to init each clk provider in the table, the > >> CLK_OF_DECLARE() macro puts a supported clk in the __clk_of_table for it > >initializing on starup, and the clk system has added some common clk such > >as "fixed-clk" > >> to this table already. > >> So here I add our specific clk init declaration to consist this > >> framework, and the driver probe function will not be needed on ARM. > > > >OK... Is there any reason why the new method won't work on PPC? > > > PPC has little dependence on the clock tree but frequency, it will work well > if adopted I think. I'm just saying it seems redundant to have both. Even on ARM, won't this result in the clock getting registered twice (albeit with one of those times being too late)? Regardless of what dependence PPC has on the clock tree, what stops this method of enumeration from working on PPC? Is there anything required other than inserting a call to of_clk_init(NULL) in the arch init code? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux 3.16: all my drivers on SPI bus report WARNING: at drivers/base/dd.c:286
I've been able to identify the origin of the issue. It happens since the below
commit.
Do you know what should be done to fix that ?
Christophe
From 7a40054361162d2f78f332aa868fed137beb7901 Mon Sep 17 00:00:00 2001
From: Axel Lin
Date: Sun, 30 Mar 2014 16:42:57 +0800
Subject: spi: fsl-spi: Fix memory leak
mpc8xxx_spi_probe() has set master->cleanup = mpc8xxx_spi_cleanup,
however current code overrides the setting in fsl_spi_probe() and set
master->cleanup = fsl_spi_cleanup.
Thus the memory allocated for cs is not freed anywhere.
Convert to use devm_kzalloc to fix the memory leak.
Signed-off-by: Axel Lin
Signed-off-by: Mark Brown
diff --git a/drivers/spi/spi-fsl-spi.c b/drivers/spi/spi-fsl-spi.c
index b3e7775..98ccd23 100644
--- a/drivers/spi/spi-fsl-spi.c
+++ b/drivers/spi/spi-fsl-spi.c
@@ -431,7 +431,7 @@ static int fsl_spi_setup(struct spi_device *spi)
return -EINVAL;
if (!cs) {
- cs = kzalloc(sizeof *cs, GFP_KERNEL);
+ cs = devm_kzalloc(&spi->dev, sizeof(*cs), GFP_KERNEL);
if (!cs)
return -ENOMEM;
spi->controller_state = cs;
--
cgit v0.10.1
Le 19/08/2014 11:21, leroy christophe a écrit :
Since Linux 3.16, for all drivers tied to SPI bus, I get the following
warning on a PowerPC 8xx.
It doesn't happen with Linux 3.15
What can be the reason / what should I look at ?
[3.086957] device: 'spi32766.1': device_add
[3.087179] bus: 'spi': add device spi32766.1
[3.087653] bus: 'spi': driver_probe_device: matched device
spi32766.1 with driver lm70
[3.087743] bus: 'spi': really_probe: probing driver lm70 with
device spi32766.1
[3.088014] [ cut here ]
[3.092348] WARNING: at drivers/base/dd.c:286
[3.096637] Modules linked in:
[3.099697] CPU: 0 PID: 25 Comm: kworker/u2:1 Tainted: G W
3.16.1-s3k-drv-999-svn5771_knld-999 #158
[3.109610] Workqueue: deferwq deferred_probe_work_func
[3.114736] task: c787f020 ti: c790c000 task.ti: c790c000
[3.120062] NIP: c01df158 LR: c01df144 CTR:
[3.124983] REGS: c790db30 TRAP: 0700 Tainted: GW
(3.16.1-s3k-drv-999-svn5771_knld-999)
[3.134162] MSR: 00029032 CR: 22002082 XER: 2000
[3.140703]
[3.140703] GPR00: 0001 c790dbe0 c787f020 0044 0054
0308 c056da0e 20737069
[3.140703] GPR08: 33323736 000ebfe0 0308 000ebfdf 22002082
c046c5a0 c046c608
[3.140703] GPR16: c046c614 c046c620 c046c62c c046c638 c046c648
c046c654 c046c68c c046c6c4
[3.140703] GPR24: 0003 c0401aa0 c0596638
c059662c c054e7a8 c7996800
[3.170102] NIP [c01df158] driver_probe_device+0xf8/0x334
[3.175431] LR [c01df144] driver_probe_device+0xe4/0x334
[3.180633] Call Trace:
[3.183093] [c790dbe0] [c01df144] driver_probe_device+0xe4/0x334
(unreliable)
[3.190147] [c790dc10] [c01dd15c] bus_for_each_drv+0x7c/0xc0
[3.195741] [c790dc40] [c01df5fc] device_attach+0xcc/0xf8
[3.201076] [c790dc60] [c01dd6d4] bus_probe_device+0xb4/0xc4
[3.20] [c790dc80] [c01db9f8] device_add+0x270/0x564
[3.211923] [c790dcc0] [c0219e84] spi_add_device+0xc0/0x190
[3.217427] [c790dce0] [c021a79c] spi_register_master+0x720/0x834
[3.223455] [c790dd40] [c021cb48] of_fsl_spi_probe+0x55c/0x614
[3.229234] [c790dda0] [c01e0d2c] platform_drv_probe+0x30/0x74
[3.234987] [c790ddb0] [c01df18c] driver_probe_device+0x12c/0x334
[3.241008] [c790dde0] [c01dd15c] bus_for_each_drv+0x7c/0xc0
[3.246602] [c790de10] [c01df5fc] device_attach+0xcc/0xf8
[3.251937] [c790de30] [c01dd6d4] bus_probe_device+0xb4/0xc4
[3.257536] [c790de50] [c01de9d8] deferred_probe_work_func+0x98/0xe0
[3.263816] [c790de70] [c00305b8] process_one_work+0x18c/0x440
[3.269577] [c790dea0] [c0030a00] worker_thread+0x194/0x67c
[3.275105] [c790def0] [c0039198] kthread+0xd0/0xe4
[3.279911] [c790df40] [c000c6d0] ret_from_kernel_thread+0x5c/0x64
[3.285970] Instruction dump:
[3.288900] 80de 419e01d0 3b7b0038 3c60c046 7f65db78 38635264
48211b99 813f00a0
[3.296559] 381f00a0 7d290278 3169 7c0b4910 <0f00> 93df0044
7fe3fb78 4bfffd4d
[3.304401] ---[ end trace c75d3461bf9e2961 ]---
[3.309598] device: 'hwmon1': device_add
[3.310246] driver: 'lm70': driver_bound: bound to device 'spi32766.1'
[3.310342] bus: 'spi': really_probe: bound device spi32766.1 to
driver lm70
Christophe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Check flat device tree version at boot
On Thu, Aug 28, 2014 at 3:40 AM, Michael Ellerman wrote:
> In commit e6a6928c3ea1 "of/fdt: Convert FDT functions to use libfdt",
> the kernel stopped supporting old flat device tree formats. The minimum
> supported version is now 0x10.
Ugg. Is that something which needs to be supported? Supporting it at
this point would mean adding support to libfdt.
Rob
> There was a checking function added, early_init_dt_verify(), but it's
> not called on powerpc.
>
> The result is, if you boot with an old flat device tree, the kernel will
> fail to parse it correctly, think you have no memory etc. and hilarity
> ensues.
>
> We can't really fix it, but we can at least catch the fact that the
> device tree is in an unsupported format and panic(). We can't call
> BUG(), it's too early.
>
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/kernel/prom.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 4e139f8a69ef..bb777b255b1c 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -641,6 +641,10 @@ void __init early_init_devtree(void *params)
>
> DBG(" -> early_init_devtree(%p)\n", params);
>
> + /* Too early to BUG_ON(), do it by hand */
> + if (!early_init_dt_verify(params))
> + panic("BUG: Failed verifying flat device tree, bad version?");
> +
> /* Setup flat device-tree pointer */
> initial_boot_params = params;
>
> --
> 1.9.1
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec
This patch ensures the cpus to kexec/reboot at nominal frequency.
Nominal frequency is the highest cpu frequency on PowerPC at
which the cores can run without getting throttled.
If the host kernel had set the cpus to a low pstate and then it
kexecs/reboots to a cpufreq disabled kernel it would cause the target
kernel to perform poorly. It will also increase the boot up time of
the target kernel. So set the cpus to high pstate, in this case to
nominal frequency before rebooting to avoid such scenarios.
The reboot notifier will set the cpus to nominal frequncy.
Changes v1->v2:
Invoke .target() driver callback to set the cpus to nominal frequency
in reboot notifier, instead of calling cpufreq_suspend() as suggested
by Viresh Kumar.
Modified the commit message.
Signed-off-by: Shilpasri G Bhat
Reviewed-by: Preeti U Murthy
---
drivers/cpufreq/powernv-cpufreq.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index 379c083..ba27c49 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -35,6 +36,7 @@
#define POWERNV_MAX_PSTATES256
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
+static bool rebooting;
/*
* Note: The set of pstates consists of contiguous integers, the
@@ -284,6 +286,15 @@ static void set_pstate(void *freq_data)
}
/*
+ * get_nominal_index: Returns the index corresponding to the nominal
+ * pstate in the cpufreq table
+ */
+static inline unsigned int get_nominal_index(void)
+{
+ return powernv_pstate_info.max - powernv_pstate_info.nominal;
+}
+
+/*
* powernv_cpufreq_target_index: Sets the frequency corresponding to
* the cpufreq table entry indexed by new_index on the cpus in the
* mask policy->cpus
@@ -293,6 +304,9 @@ static int powernv_cpufreq_target_index(struct
cpufreq_policy *policy,
{
struct powernv_smp_call_data freq_data;
+ if (unlikely(rebooting) && new_index != get_nominal_index())
+ return -EBUSY;
+
freq_data.pstate_id = powernv_freqs[new_index].driver_data;
/*
@@ -317,6 +331,25 @@ static int powernv_cpufreq_cpu_init(struct cpufreq_policy
*policy)
return cpufreq_table_validate_and_show(policy, powernv_freqs);
}
+static int powernv_cpufreq_reboot_notifier(struct notifier_block *nb,
+ unsigned long action, void *unused)
+{
+ int cpu;
+ struct cpufreq_policy cpu_policy;
+
+ rebooting = true;
+ for_each_online_cpu(cpu) {
+ cpufreq_get_policy(&cpu_policy, cpu);
+ powernv_cpufreq_target_index(&cpu_policy, get_nominal_index());
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block powernv_cpufreq_reboot_nb = {
+ .notifier_call = powernv_cpufreq_reboot_notifier,
+};
+
static struct cpufreq_driver powernv_cpufreq_driver = {
.name = "powernv-cpufreq",
.flags = CPUFREQ_CONST_LOOPS,
@@ -342,12 +375,14 @@ static int __init powernv_cpufreq_init(void)
return rc;
}
+ register_reboot_notifier(&powernv_cpufreq_reboot_nb);
return cpufreq_register_driver(&powernv_cpufreq_driver);
}
module_init(powernv_cpufreq_init);
static void __exit powernv_cpufreq_exit(void)
{
+ unregister_reboot_notifier(&powernv_cpufreq_reboot_nb);
cpufreq_unregister_driver(&powernv_cpufreq_driver);
}
module_exit(powernv_cpufreq_exit);
--
1.9.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support
>-Original Message- >From: Wood Scott-B07421 >Sent: Thursday, August 28, 2014 7:34 AM >To: Lu Jingchang-B35083 >Cc: mturque...@linaro.org; linuxppc-dev@lists.ozlabs.org; linux- >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms >CLK_OF_DECLARE support > >On Tue, 2014-08-26 at 21:19 -0500, Lu Jingchang-B35083 wrote: >> >-Original Message- >> >From: Wood Scott-B07421 >> >Sent: Wednesday, August 27, 2014 6:51 AM >> >To: Lu Jingchang-B35083 >> >Cc: mturque...@linaro.org; linuxppc-dev@lists.ozlabs.org; linux- >> >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org >> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based >> >platforms CLK_OF_DECLARE support >> > >> >On Fri, 2014-08-22 at 17:34 +0800, Jingchang Lu wrote: >> >> +CLK_OF_DECLARE(ppc_core_pll_v1, "fsl,qoriq-core-pll-1.0", >> >core_pll_init); >> >> +CLK_OF_DECLARE(ppc_core_pll_v2, "fsl,qoriq-core-pll-2.0", >> >core_pll_init); >> >> +CLK_OF_DECLARE(ppc_core_mux_v1, "fsl,qoriq-core-mux-1.0", >> >core_mux_init); >> >> +CLK_OF_DECLARE(ppc_core_mux_v2, "fsl,qoriq-core-mux-2.0", >> >core_mux_init); >> > >> >What does this do that the existing platform driver and match table >> >don't? Why is it needed for ARM when PPC didn't need it? >> > >> >-Scott >> > >> Common clk init on ARM platform is initialized earlier via >> of_clk_init() instead of driver probe method, the of_clk_init will >> walk a __clk_of_table to init each clk provider in the table, the >> CLK_OF_DECLARE() macro puts a supported clk in the __clk_of_table for it >initializing on starup, and the clk system has added some common clk such >as "fixed-clk" >> to this table already. >> So here I add our specific clk init declaration to consist this >> framework, and the driver probe function will not be needed on ARM. > >OK... Is there any reason why the new method won't work on PPC? > PPC has little dependence on the clock tree but frequency, it will work well if adopted I think. Best Regards, Jingchang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Check flat device tree version at boot
In commit e6a6928c3ea1 "of/fdt: Convert FDT functions to use libfdt",
the kernel stopped supporting old flat device tree formats. The minimum
supported version is now 0x10.
There was a checking function added, early_init_dt_verify(), but it's
not called on powerpc.
The result is, if you boot with an old flat device tree, the kernel will
fail to parse it correctly, think you have no memory etc. and hilarity
ensues.
We can't really fix it, but we can at least catch the fact that the
device tree is in an unsupported format and panic(). We can't call
BUG(), it's too early.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/prom.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 4e139f8a69ef..bb777b255b1c 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -641,6 +641,10 @@ void __init early_init_devtree(void *params)
DBG(" -> early_init_devtree(%p)\n", params);
+ /* Too early to BUG_ON(), do it by hand */
+ if (!early_init_dt_verify(params))
+ panic("BUG: Failed verifying flat device tree, bad version?");
+
/* Setup flat device-tree pointer */
initial_boot_params = params;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
