* Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Geert Uytterhoeven @ 2014-04-18 8:04 UTC (permalink / raw)
To: Leif Lindholm
Cc: Mark Rutland, devicetree@vger.kernel.org, patches,
linux-kernel@vger.kernel.org, Grant Likely,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1397756521-29387-4-git-send-email-leif.lindholm@linaro.org>
Hi Leif,
On Thu, Apr 17, 2014 at 7:42 PM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> In order to deal with an firmware bug on a specific ppc32 platform
> (longtrail), early_init_dt_scan_memory() looks for a node called
> memory@0 on all platforms. Restrict this quirk to ppc32 kernels only.
This breaks backwards compatibilty with old DTSes (at least on ARM/MIPS,
where you added the missing property in patches 1 and 2 of the series)?
For the Longtrail, I don't care much anymore, as mine died in 2004.
AFAIK, there have never been many users anyway.
> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/of/fdt.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index fa16a91..7368472 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -887,14 +887,19 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
>
> /* We are scanning "memory" nodes only */
> if (type == NULL) {
> +#ifdef CONFIG_PPC32
> /*
> * The longtrail doesn't have a device_type on the
> * /memory node, so look for the node called /memory@0.
> */
> if (depth != 1 || strcmp(uname, "memory@0") != 0)
> return 0;
> - } else if (strcmp(type, "memory") != 0)
> +#else
> + return 0;
> +#endif
> + } else if (strcmp(type, "memory") != 0) {
> return 0;
> + }
>
> reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
> if (reg == NULL)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
From: Brian Norris @ 2014-04-18 6:30 UTC (permalink / raw)
To: Thierry Reding
Cc: Marek Vasut, linux-mips, Russell King, Stephen Warren, linux-sh,
Steven Miao, Linux Kernel, Ralf Baechle, adi-buildroot-devel,
linux-tegra, linux-mtd, linux-arm-kernel, Sascha Hauer,
Olof Johansson, Paul Mackerras, linuxppc-dev, Shawn Guo
In-Reply-To: <20140417105302.GA32603@ulmo>
Hi,
On Thu, Apr 17, 2014 at 12:53:03PM +0200, Thierry Reding wrote:
> On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote:
> > We are introducing a new SPI-NOR library/framework for MTD, to support various
> > types of SPI-NOR flash controllers which require (or benefit from) intimate
> > knowledge of the flash interface, rather than just the relatively dumb SPI
> > interface. This library borrows much of the m25p80 driver for its abstraction
> > and moves this code into a spi-nor module.
>
> If this is a common library, then the more common approach to solve this
> would be to have each driver that uses it to select MTD_SPI_NOR rather
> than depend on it. That way you can drop this whole series to update the
> default configurations.
But does MTD_SPI_NOR (and drivers/mtd/spi-nor/) qualify as a "library"
or as a "subsystem"? I thought the latter were typically expected to be
user-selectable options, not automatically-"select"ed.
I would say that, except for its age, MTD_SPI_NOR is very similar in to
MTD_NAND (driver/mtd/nand/), which I'd consider a kind of subsystem, and
which users must select before they are asked about drivers which fall
under its category.
Perhaps my usage of the word "library" in the description was a mistake,
as I don't exactly consider it like a library in the sense of many other
"select"ed libraries.
Brian
^ permalink raw reply
* Re: [PATCH v3 4/8] DMA: Freescale: add fsl_dma_free_descriptor() to reduce code duplication
From: Hongbo Zhang @ 2014-04-18 4:09 UTC (permalink / raw)
To: Andy Shevchenko
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <1397482830.11914.126.camel@smile.fi.intel.com>
On 04/14/2014 09:40 PM, Andy Shevchenko wrote:
> On Fri, 2014-04-11 at 16:14 +0800, Hongbo Zhang wrote:
>> On 04/10/2014 07:29 PM, Andy Shevchenko wrote:
>>> On Thu, 2014-04-10 at 15:10 +0800, hongbo.zhang@freescale.com wrote:
> []
>
>>>> @@ -819,8 +826,7 @@ static void fsldma_cleanup_descriptor(struct fsldma_chan *chan,
>>>> dma_run_dependencies(txd);
>>>>
>>>> dma_descriptor_unmap(txd);
>>>> - chan_dbg(chan, "LD %p free\n", desc);
>>>> - dma_pool_free(chan->desc_pool, desc, txd->phys);
>>>> + fsl_dma_free_descriptor(chan, desc);
>>> Here is no list_del() call since it's been called in dma_do_tasklet().
>>> What will be the result of double list_del() against the same node?
>> Not clear with your point.
>> This patch is only introducing a common fsl_dma_free_descriptor() to
>> reduce code duplication. And later in the patch 6/8 the
>> fsldma_cleanup_descriptor() is replaced by fsldma_cleanup_descriptorS().
> In the last case you could have a broken kernel which will fails on
> double list_del(). I think it's better to leave this one untouched and
> you may remove it later.
>
> Or move this patch after you have removed that lines.
>
Good catch, thank you Andy.
Yes I prefer to leave this untouched and handle it later.
^ permalink raw reply
* Re: [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
From: Rob Herring @ 2014-04-18 0:43 UTC (permalink / raw)
To: Leif Lindholm
Cc: Mark Rutland, devicetree@vger.kernel.org, linuxppc-dev,
linux-kernel@vger.kernel.org, Linaro Patches
In-Reply-To: <1397756521-29387-1-git-send-email-leif.lindholm@linaro.org>
On Thu, Apr 17, 2014 at 12:41 PM, Leif Lindholm
<leif.lindholm@linaro.org> wrote:
> drivers/of/fdt.c contains a workaround for a missing memory type
> entry on longtrail firmware. Make that quirk PPC32 only, and while
> at it - fix up the .dts files in the tree currently working only
> because of that quirk.
But why do you need this?
>
> Cc: devicetree@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> Cc: Mark Rutland <mark.rutland@arm.com>
>
> Leif Lindholm (3):
> arm: dts: add device_type="memory" for ste-ccu8540
> mips: dts: add device_type="memory" where missing
> of: Handle memory@0 node on PPC32 only
>
> arch/arm/boot/dts/ste-ccu8540.dts | 1 +
> arch/mips/lantiq/dts/easy50712.dts | 1 +
> arch/mips/ralink/dts/mt7620a_eval.dts | 1 +
> arch/mips/ralink/dts/rt2880_eval.dts | 1 +
> arch/mips/ralink/dts/rt3052_eval.dts | 1 +
> arch/mips/ralink/dts/rt3883_eval.dts | 1 +
I'm not worried about these MIPS dts files because they are all
built-in, but you are breaking compatibility with old dtbs for this
ARM board.
Rob
> drivers/of/fdt.c | 7 ++++++-
> 7 files changed, 12 insertions(+), 1 deletion(-)
>
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Leif Lindholm @ 2014-04-17 17:42 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, patches, Leif Lindholm, Grant Likely,
linuxppc-dev
In-Reply-To: <1397756521-29387-1-git-send-email-leif.lindholm@linaro.org>
In order to deal with an firmware bug on a specific ppc32 platform
(longtrail), early_init_dt_scan_memory() looks for a node called
memory@0 on all platforms. Restrict this quirk to ppc32 kernels only.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/of/fdt.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index fa16a91..7368472 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -887,14 +887,19 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
/* We are scanning "memory" nodes only */
if (type == NULL) {
+#ifdef CONFIG_PPC32
/*
* The longtrail doesn't have a device_type on the
* /memory node, so look for the node called /memory@0.
*/
if (depth != 1 || strcmp(uname, "memory@0") != 0)
return 0;
- } else if (strcmp(type, "memory") != 0)
+#else
+ return 0;
+#endif
+ } else if (strcmp(type, "memory") != 0) {
return 0;
+ }
reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
if (reg == NULL)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/3] of: dts: enable memory@0 quirk for PPC32 only
From: Leif Lindholm @ 2014-04-17 17:41 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, linuxppc-dev, Leif Lindholm, patches
drivers/of/fdt.c contains a workaround for a missing memory type
entry on longtrail firmware. Make that quirk PPC32 only, and while
at it - fix up the .dts files in the tree currently working only
because of that quirk.
Cc: devicetree@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>
Leif Lindholm (3):
arm: dts: add device_type="memory" for ste-ccu8540
mips: dts: add device_type="memory" where missing
of: Handle memory@0 node on PPC32 only
arch/arm/boot/dts/ste-ccu8540.dts | 1 +
arch/mips/lantiq/dts/easy50712.dts | 1 +
arch/mips/ralink/dts/mt7620a_eval.dts | 1 +
arch/mips/ralink/dts/rt2880_eval.dts | 1 +
arch/mips/ralink/dts/rt3052_eval.dts | 1 +
arch/mips/ralink/dts/rt3883_eval.dts | 1 +
drivers/of/fdt.c | 7 ++++++-
7 files changed, 12 insertions(+), 1 deletion(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
From: Marek Vasut @ 2014-04-17 11:07 UTC (permalink / raw)
To: Brian Norris
Cc: linux-mips, Russell King, Stephen Warren, linux-sh, Steven Miao,
Linux Kernel, Ralf Baechle, adi-buildroot-devel, linux-tegra,
Thierry Reding, linux-mtd, linux-arm-kernel, Sascha Hauer,
Olof Johansson, Paul Mackerras, linuxppc-dev, Shawn Guo
In-Reply-To: <1397719309-2022-1-git-send-email-computersforpeace@gmail.com>
On Thursday, April 17, 2014 at 09:21:44 AM, Brian Norris wrote:
> Hi all,
>
> We are introducing a new SPI-NOR library/framework for MTD, to support
> various types of SPI-NOR flash controllers which require (or benefit from)
> intimate knowledge of the flash interface, rather than just the relatively
> dumb SPI interface. This library borrows much of the m25p80 driver for its
> abstraction and moves this code into a spi-nor module.
>
> This means CONFIG_M25P80 now has a dependency on CONFIG_MTD_SPI_NOR, which
> should be added to the defconfigs. I'm not sure what is the best process
> for doing this. Should each $ARCH maintainer just take their respective
> patch, even if the MTD_SPI_NOR Kconfig symbol is not defined for them yet?
> Or should maintainers plan on merging the relevant SPI-NOR code into their
> trees during the development cycle? Or some third option?
Shouldn't the M25P80 driver just "select" the SPI NOR framework? Then you won't
need the adjustment to defconfigs at all I think.
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
From: Thierry Reding @ 2014-04-17 10:53 UTC (permalink / raw)
To: Brian Norris
Cc: Marek Vasut, linux-mips, Russell King, Stephen Warren, linux-sh,
Steven Miao, Linux Kernel, Ralf Baechle, adi-buildroot-devel,
linux-tegra, linux-mtd, linux-arm-kernel, Sascha Hauer,
Olof Johansson, Paul Mackerras, linuxppc-dev, Shawn Guo
In-Reply-To: <1397719309-2022-1-git-send-email-computersforpeace@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 702 bytes --]
On Thu, Apr 17, 2014 at 12:21:44AM -0700, Brian Norris wrote:
> Hi all,
>
> We are introducing a new SPI-NOR library/framework for MTD, to support various
> types of SPI-NOR flash controllers which require (or benefit from) intimate
> knowledge of the flash interface, rather than just the relatively dumb SPI
> interface. This library borrows much of the m25p80 driver for its abstraction
> and moves this code into a spi-nor module.
If this is a common library, then the more common approach to solve this
would be to have each driver that uses it to select MTD_SPI_NOR rather
than depend on it. That way you can drop this whole series to update the
default configurations.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 3/3] cpufreq: ppc: Fix handling of non-existent clocks
From: Geert Uytterhoeven @ 2014-04-17 9:53 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, cpufreq, linux-pm
In-Reply-To: <1397728407-13909-1-git-send-email-geert+renesas@glider.be>
If the clock doesn't exist, clk_get_rate() returns -EINVAL, which becomes
a large number (freq is u32), failing the "freq < min_cpufreq" test.
Explicitly test for "(u32)-EINVAL" to fix this.
Update the comment, and fix a grammer issue while we're at it.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/cpufreq/ppc-corenet-cpufreq.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c b/drivers/cpufreq/ppc-corenet-cpufreq.c
index 53881d78a931..7027eab814ce 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
@@ -179,10 +179,11 @@ static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy)
clk = of_clk_get(data->parent, i);
freq = clk_get_rate(clk);
/*
- * the clock is valid if its frequency is not masked
- * and large than minimum allowed frequency.
+ * the clock is valid if it exists, its frequency is not
+ * masked, and larger than minimum allowed frequency.
*/
- if (freq < min_cpufreq || (mask & (1 << i)))
+ if (freq == (u32)-EINVAL || freq < min_cpufreq ||
+ (mask & (1 << i)))
table[i].frequency = CPUFREQ_ENTRY_INVALID;
else
table[i].frequency = freq / 1000;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] cpufreq: ppc: Fix integer overflow in expression
From: Geert Uytterhoeven @ 2014-04-17 9:53 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, cpufreq, linux-pm
In-Reply-To: <1397728407-13909-1-git-send-email-geert+renesas@glider.be>
On 32-bit, "12 * NSEC_PER_SEC" doesn't fit in "unsigned long"
(NSEC_PER_SEC is a "long" constant), causing an integer overflow:
drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
drivers/cpufreq/ppc-corenet-cpufreq.c:211:9: warning: integer overflow in expression [-Woverflow]
Force the intermediate to be 64-bit by adding an "ULL" suffix to the
constant multiplier to fix this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/cpufreq/ppc-corenet-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c b/drivers/cpufreq/ppc-corenet-cpufreq.c
index e78f9c806de4..53881d78a931 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
@@ -208,7 +208,7 @@ static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy)
per_cpu(cpu_data, i) = data;
policy->cpuinfo.transition_latency =
- (12 * NSEC_PER_SEC) / fsl_get_sys_freq();
+ (12ULL * NSEC_PER_SEC) / fsl_get_sys_freq();
of_node_put(np);
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] cpufreq: ppc: Add missing #include <asm/smp.h>
From: Geert Uytterhoeven @ 2014-04-17 9:53 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Geert Uytterhoeven, linuxppc-dev, linux-kernel, cpufreq, linux-pm
If CONFIG_SMP=n, <linux/smp.h> does not include <asm/smp.h>, causing:
drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
drivers/cpufreq/ppc-corenet-cpufreq.c:173:3: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/cpufreq/ppc-corenet-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c b/drivers/cpufreq/ppc-corenet-cpufreq.c
index b7e677be1df0..e78f9c806de4 100644
--- a/drivers/cpufreq/ppc-corenet-cpufreq.c
+++ b/drivers/cpufreq/ppc-corenet-cpufreq.c
@@ -22,6 +22,8 @@
#include <linux/smp.h>
#include <sysdev/fsl_soc.h>
+#include <asm/smp.h>
+
/**
* struct cpu_data - per CPU data struct
* @parent: the parent node of cpu clock
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] powerpc: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
From: Brian Norris @ 2014-04-17 7:21 UTC (permalink / raw)
To: Linux Kernel
Cc: Marek Vasut, linux-mtd, Paul Mackerras, Brian Norris,
linuxppc-dev
In-Reply-To: <1397719309-2022-1-git-send-email-computersforpeace@gmail.com>
These defconfigs contain the CONFIG_M25P80 symbol, which is now
dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to the
relevant defconfigs.
At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
This change is based on l2-mtd.git/spinor, which is based on 3.15-rc1:
git://git.infradead.org/l2-mtd.git +spinor
arch/powerpc/configs/corenet32_smp_defconfig | 2 +-
arch/powerpc/configs/corenet64_smp_defconfig | 2 +-
arch/powerpc/configs/mpc85xx_defconfig | 2 +-
arch/powerpc/configs/mpc85xx_smp_defconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index bbd794deb6eb..fceaa893d37c 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -69,7 +69,6 @@ CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_CFI=y
CONFIG_MTD_CFI_AMDSTD=y
@@ -78,6 +77,7 @@ CONFIG_MTD_M25P80=y
CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_FSL_ELBC=y
CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_SPI_NOR=y
CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 5c7fa19ae4ef..9c8d58a50df2 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -61,7 +61,6 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
@@ -82,6 +81,7 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_FSL_ELBC=y
CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index 19f0fbe5ba4b..33d9c8aef4eb 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -83,7 +83,6 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
@@ -104,6 +103,7 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_FSL_ELBC=y
CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 062312e1fe1a..25174f9a6615 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -86,7 +86,6 @@ CONFIG_DEVTMPFS_MOUNT=y
CONFIG_MTD=y
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_FTL=y
@@ -107,6 +106,7 @@ CONFIG_MTD_NAND=y
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_FSL_ELBC=y
CONFIG_MTD_NAND_FSL_IFC=y
+CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
--
1.8.3.2
^ permalink raw reply related
* [PATCH 0/5] defconfigs: add MTD_SPI_NOR (dependency for M25P80)
From: Brian Norris @ 2014-04-17 7:21 UTC (permalink / raw)
To: Linux Kernel
Cc: Marek Vasut, linux-mips, Russell King, Stephen Warren, linux-sh,
Steven Miao, adi-buildroot-devel, Ralf Baechle, linux-tegra,
Thierry Reding, linux-mtd, linux-arm-kernel, Sascha Hauer,
Olof Johansson, Paul Mackerras, Brian Norris, linuxppc-dev,
Shawn Guo
Hi all,
We are introducing a new SPI-NOR library/framework for MTD, to support various
types of SPI-NOR flash controllers which require (or benefit from) intimate
knowledge of the flash interface, rather than just the relatively dumb SPI
interface. This library borrows much of the m25p80 driver for its abstraction
and moves this code into a spi-nor module.
This means CONFIG_M25P80 now has a dependency on CONFIG_MTD_SPI_NOR, which
should be added to the defconfigs. I'm not sure what is the best process for
doing this. Should each $ARCH maintainer just take their respective patch, even
if the MTD_SPI_NOR Kconfig symbol is not defined for them yet? Or should
maintainers plan on merging the relevant SPI-NOR code into their trees during
the development cycle? Or some third option?
Anyway, the patches are here. Please keep general comments to the cover letter,
so all parties can see.
This series is based on the development repo for MTD, in the 'spinor' branch:
git://git.infradead.org/l2-mtd.git +spinor
This series is available in the same repo at:
git://git.infradead.org/l2-mtd.git +defconfigs
I tried locally merging this into linux-next and saw a trivial conflict in
arch/arm/configs/shmobile_defconfig. I can resubmit based on an appropriate
tree, if requested.
Thanks,
Brian
P.S. I was going to purely automatically generate this diff as follows, but
it generated a lot of defconfig noise:
#!/bin/sh
for i in arm blackfin mips powerpc sh
do
for j in `git grep -l M25P80 arch/$i/configs`
do
echo $j
cp $j .config
echo CONFIG_MTD_SPI_NOR=y >> .config
make ARCH=$i savedefconfig
mv defconfig $j
done
done
So I did a mixed approach, where I filtered most of the noise out of the diff.
Brian Norris (5):
ARM: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
blackfin: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
mips: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
powerpc: defconfigs: add MTD_SPI_NOR (new dependency for M25P80)
sh: defconfig: add MTD_SPI_NOR (new dependency for M25P80)
arch/arm/configs/bockw_defconfig | 2 +-
arch/arm/configs/dove_defconfig | 2 +-
arch/arm/configs/imx_v6_v7_defconfig | 1 +
arch/arm/configs/keystone_defconfig | 1 +
arch/arm/configs/kirkwood_defconfig | 1 +
arch/arm/configs/koelsch_defconfig | 1 +
arch/arm/configs/lager_defconfig | 1 +
arch/arm/configs/lpc32xx_defconfig | 2 +-
arch/arm/configs/multi_v5_defconfig | 1 +
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/configs/mvebu_v5_defconfig | 1 +
arch/arm/configs/mvebu_v7_defconfig | 1 +
arch/arm/configs/mxs_defconfig | 1 +
arch/arm/configs/sama5_defconfig | 2 +-
arch/arm/configs/shmobile_defconfig | 1 +
arch/arm/configs/tegra_defconfig | 1 +
arch/blackfin/configs/BF526-EZBRD_defconfig | 2 +-
arch/blackfin/configs/BF527-EZKIT-V2_defconfig | 2 +-
arch/blackfin/configs/BF527-EZKIT_defconfig | 2 +-
arch/blackfin/configs/BF548-EZKIT_defconfig | 2 +-
arch/blackfin/configs/BF609-EZKIT_defconfig | 2 +-
arch/blackfin/configs/BlackStamp_defconfig | 3 +--
arch/blackfin/configs/H8606_defconfig | 3 +--
arch/mips/configs/ath79_defconfig | 3 +--
arch/mips/configs/db1xxx_defconfig | 1 +
arch/mips/configs/rt305x_defconfig | 2 +-
arch/powerpc/configs/corenet32_smp_defconfig | 2 +-
arch/powerpc/configs/corenet64_smp_defconfig | 2 +-
arch/powerpc/configs/mpc85xx_defconfig | 2 +-
arch/powerpc/configs/mpc85xx_smp_defconfig | 2 +-
arch/sh/configs/sh7757lcr_defconfig | 2 +-
31 files changed, 31 insertions(+), 21 deletions(-)
--
1.8.3.2
^ permalink raw reply
* Powerpc: e1000e cannot work normally after system resume from sleep(standby)
From: Dongsheng.Wang @ 2014-04-17 7:00 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org, linux-pci@vger.kernel.org,
netdev@vger.kernel.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org
Hi all,
Now I'm developing Freescale PCIe power management feature. The following i=
s my PCIe
suspend/resume code.
when I test system wake up from sleep(STANDBY), I got below calltrace. Look=
s like e1000e
cannot transfer data, maybe watchdog has some issue. Or maybe some of the o=
ther causes.
I think this is not root cause. Because If changed mdelay(10) to 20ms. E100=
0 will work normal.
Maybe e1000e need more time to recover? Or ?
Here are my test results:
E1000e plug in PCIe slot 1, we need to delay 10ms.
E1000e plug in PCIe slot 2, we need to delay 20ms.
E1000e plug in PCIe slot 3, we need to delay 60ms.
Anyone have any idea about this?
*Suspend flow*:=20
if (fsl_pcie_check_link(hose))
return;
/* Send PME_Turn_Off Message Request */
setbits32(&pci->pex_pmcr, PEX_PMCR_PTOMR);
/* Wait trun off done */
/* RC will get this detect quickly */
for (i =3D 0; i < 50; i++) {
dr =3D in_be32(&pci->pex_pme_mes_dr);
if (dr & ENL23_DETECT_BIT) {
out_be32(&pci->pex_pme_mes_dr, dr);
break;
}
udelay(1000);
}
/*
* "PCI Bus Power Management Interface Specification" define
* Minimum System Software Guaranteed Delays
*
* D0, D1 or D2 --> D3, need delay 10ms.
* But we need to delay more time when EP plug in p1022 slot2.
*/
mdelay(10);
*Resume flow*:
if (fsl_pcie_check_link(hose))
return;
/* Send Exit L2 State Message */
setbits32(&pci->pex_pmcr, PEX_PMCR_EXL2S);
/* Wait exit done */
/* RC will get this detect quickly */
for (i =3D 0; i < 50; i++) {
dr =3D in_be32(&pci->pex_pme_mes_dr);
if (dr & EXL23_DETECT_BIT) {
out_be32(&pci->pex_pme_mes_dr, dr);
break;
}
udelay(1000);
}
/*
* "PCI Bus Power Management Interface Specification" define
* Minimum System Software Guaranteed Delays
*
* D3 hot --> D0, need delay 10ms.
* But we need to delay more time when EP plug in p1022 slot2.
*/
mdelay(10);
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
CALL TRACE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
[root@p1022 /root]# udhcpc -i eth0
udhcpc (v1.11.2) started
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Sending discover...
e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sending discover...
Sending discover...
NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out
------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:264
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.0-173871-g9964256-dirty #42
task: ee0534e0 ti: ee070000 task.ti: ee070000
NIP: c036267c LR: c036267c CTR: c028b834
REGS: ee071d00 TRAP: 0700 Not tainted (3.14.0-173871-g9964256-dirty)
MSR: 00029000 <CE,EE,ME> CR: 42000022 XER: 20000000
GPR00: c036267c ee071db0 ee0534e0 0000003a c16393b0 c16398e8 01079000 c05c0=
3a8
GPR08: 00000001 00000001 01079000 00000132 00000132 00000000 00000004 c05ed=
040
GPR16: 00000001 00000100 00000004 fffef539 00000000 c05c10c0 00000038 fffff=
fff
GPR24: 00000000 00000001 ee070000 00000004 c05e0000 c05f0000 ee3c0000 00000=
000
NIP [c036267c] dev_watchdog+0x2c8/0x2d8
LR [c036267c] dev_watchdog+0x2c8/0x2d8
Call Trace:
[ee071db0] [c036267c] dev_watchdog+0x2c8/0x2d8 (unreliable)
[ee071de0] [c004778c] call_timer_fn.isra.24+0x28/0x84
[ee071e00] [c00479b8] run_timer_softirq+0x1d0/0x248
[ee071e40] [c004090c] __do_softirq+0x104/0x20c
[ee071ea0] [c0040cd8] irq_exit+0xa4/0xc8
[ee071eb0] [c0009ef4] timer_interrupt+0xb8/0xdc
[ee071ed0] [c000f57c] ret_from_except+0x0/0x18
--- Exception: 901 at arch_cpu_idle+0x24/0x5c
LR =3D arch_cpu_idle+0x24/0x5c
[ee071f90] [c0089534] rcu_idle_enter+0xa4/0xd0 (unreliable)
[ee071fa0] [c0076010] cpu_startup_entry+0x120/0x17c
[ee071fd0] [c0010bbc] start_secondary+0x214/0x224
[ee071ff0] [c0002154] __secondary_start+0x7c/0xc8
Instruction dump:
4e800421 80fe0224 4bffff4c 7fc3f378 4bfe5401 7fc4f378 7c651b78 3c60c055
7fe6fb78 3863e0f4 4cc63182 480e9a05 <0fe00000> 39200001 993c6f38 4bffffb4
---[ end trace 2d4f2cedfa86e32f ]---
e1000e 0002:05:00.0: Net device Info
e1000e: Device Name state trans_start last_rx
e1000e: eth0 0000000000000003 00000000FFFEF040 0000000000000000
e1000e 0002:05:00.0: Register Dump
e1000e: Register Name Value
e1000e: CTRL 58100248
e1000e: STATUS 00080783
e1000e: CTRL_EXT 18580000
e1000e: ICR 00000000
e1000e: RCTL 04008002
e1000e: RDLEN 00001000
e1000e: RDH 0000001d
e1000e: RDT 000000f0
e1000e: RDTR 00000020
e1000e: RXDCTL[0-1] 01040420 01040420
e1000e: ERT 00000000
e1000e: RDBAL 2d390000
e1000e: RDBAH 00000000
e1000e: RDFH 0000020a
e1000e: RDFT 0000020a
e1000e: RDFHS 0000020a
e1000e: RDFTS 0000020a
e1000e: RDFPC 00000000
e1000e: TCTL 3103f0fa
e1000e: TDBAL 2e158000
e1000e: TDBAH 00000000
e1000e: TDLEN 00001000
e1000e: TDH 00000001
e1000e: TDT 00000001
e1000e: TIDV 00000008
e1000e: TXDCTL[0-1] 0141011f 0141011f
e1000e: TADV 00000020
e1000e: TARC[0-1] 04000403 00000403
e1000e: TDFH 00001000
e1000e: TDFT 00001012
e1000e: TDFHS 00001000
e1000e: TDFTS 00001000
e1000e: TDFPC 00000000
e1000e 0002:05:00.0: Tx Ring Summary
e1000e: Queue [NTU] [NTC] [bi(ntc)->dma ] leng ntw timestamp
e1000e: 0 1 0 000000002C809802 005A 0 00000000FFFEF044
e1000e 0002:05:00.0: Rx Ring Summary
e1000e: Queue [NTU] [NTC]
e1000e: 0 FF 0
e1000e 0002:05:00.0 eth0: Reset adapter unexpectedly
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix ".__node_distance" undefined
From: Mike Qiu @ 2014-04-17 3:10 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, jlarrew, paulus, srivatsa.bhat, alistair, nfont, akpm, rcj,
linuxppc-dev
In-Reply-To: <1397570417-1714-1-git-send-email-qiudayu@linux.vnet.ibm.com>
Any update about this patch ?
Thanks
Mike
On 04/15/2014 10:00 PM, Mike Qiu wrote:
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> ...
> Building modules, stage 2.
> WARNING: 1 bad relocations
> c0000000013d6a30 R_PPC64_ADDR64 uprobes_fetch_type_table
> WRAP arch/powerpc/boot/zImage.pseries
> WRAP arch/powerpc/boot/zImage.epapr
> MODPOST 1849 modules
> ERROR: ".__node_distance" [drivers/block/nvme.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> make: *** Waiting for unfinished jobs....
>
> The reason is symbol "__node_distance" not been exported in powerpc.
>
> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 4ebbb9e..3b181b2 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -232,6 +232,7 @@ int __node_distance(int a, int b)
>
> return distance;
> }
> +EXPORT_SYMBOL(__node_distance);
>
> static void initialize_distance_lookup_table(int nid,
> const __be32 *associativity)
^ permalink raw reply
* Re: [PATCH RFC v11 5/6] dma: mpc512x: add device tree binding document
From: Gerhard Sittig @ 2014-04-16 20:44 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree, Lars-Peter Clausen, Anatolij Gustschin, Arnd Bergmann,
Vinod Koul, dmaengine, Dan Williams, Andy Shevchenko,
linuxppc-dev
In-Reply-To: <1397559250-17680-6-git-send-email-a13xp0p0v88@gmail.com>
On Tue, 2014-04-15 at 14:54 +0400, Alexander Popov wrote:
>
> Introduce a device tree binding document for the MPC512x DMA controller
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
I'm not certain whether the attribution is right. Is the S-o-b
appropriate when the patch is not "from" me? As I've stated
before, it's OK if you pick up and extend what I provide, but
please don't pretend that I wrote what you did, and don't pretend
that I ACKed or passed along your submission when I didn't.
This binding certainly needs further improvement to become a good
one. As I've communicated in the past, I was rather ignorant
"back then" when I wrote v1 and v2 of the RFC. We have learned
something in the meantime. Though I admit having gone silent
after several review iterations. Assumed you would pick up
information that showed up several times on public lists.
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> @@ -0,0 +1,51 @@
> +* Freescale MPC512x and MPC8308 DMA Controller
> +
> +The DMA controller in the Freescale MPC512x and MPC8308 SoCs can move
> +blocks of memory contents between memory and peripherals or
> +from memory to memory.
> +
> +Refer to the "Generic DMA Controller and DMA request bindings" in
> +the dma/dma.txt file for a more detailed description of binding.
> +
> +* DMA controller
> +
> +Required properties:
> +- compatible: Should be one of
> + "fsl,mpc5121-dma"
> + "fsl,mpc8308-dma", "fsl,mpc5121-dma"
is this a duplicate? looks funny, needs a fix
or is it a requirement that for MPC8308 you need to provide both
compatible strings? that would be wrong, as MPC8308 certainly is
not an MPC5121
a quick search reveals: the drivers/dma/mpc512x_dma.c Linux
driver implementation is wrong, it should match on both strings;
expecting the MPC8308 to disguise as an MPC5121 when it's not is
inappropriate (and only went unnoticed because of missing
bindings, I guess)
> +- reg: Address and size of the DMA controller's register set
> +- interrupts: Interrupt for the DMA controller. Generic interrupt client node
> + is described in interrupt-controller/interrupts.txt
'interrupts' only works in combinations with 'interrupt-parent',
that actual .dts files don't have the latter in the nodes is an
implementation detail but not a binding's requirement
and an alternative method of specifying interrupts was introduced
recently, a reference to the common binding without naming one
specific property name could be most appropriate
> +
> +Optional properties:
> +- #dma-cells: The length of the DMA specifier, must be <1> since
> + the DMA controller uses a fixed assignment of request lines
> + per channel. Refer to dma/dma.txt for the detailed description
> + of this property
I'm afraid that a generic/common document does not and cannot
describe the specific semantics of this provider's cells
this binding should explicitly mention that the number of cells
needs to be one, and that this one cell is the DMA channel (which
translates to "peripheral request line"), because these
assigments are fixed in hardware
> +
> +Example:
> +
> + dma0: dma@14000 {
> + compatible = "fsl,mpc5121-dma";
> + reg = <0x14000 0x1800>;
> + interrupts = <65 0x8>;
> + #dma-cells = <1>;
> + };
> +
> +* DMA client
the DMA provider's binding probably need not discuss client
specs, a reference to the common binding should suffice if it's
appropriate at all
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization for platform
From: Scott Wood @ 2014-04-16 19:36 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org, haokexin@gmail.com,
Kushwaha Prabhakar-B32579, Jin Zhengxiong-R64188
In-Reply-To: <77e2c53b2f154faba68c8b7ac760accc@BN1PR03MB188.namprd03.prod.outlook.com>
On Tue, 2014-04-15 at 21:58 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 16, 2014 3:39 AM
> > To: Wang Dongsheng-B40534
> > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha Prabhakar-B32579;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization
> > for platform
> >
> > On Tue, 2014-04-15 at 13:53 +0800, Dongsheng Wang wrote:
> > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > >
> > > Corenet_generic is a generic platform initialization. Those based on
> > > the corenet_generic board maybe need a particular initialize to
> > > enable/set some IP-Blocks. So add "Fix Generic Initialization" to solve
> > > this kind of special cases.
> >
> > I still don't understand what you mean by "fix". What are you fixing,
> > or what is fixed?
> >
> > There is no need for adding an infrastructure layer here. Just add a
> > new piece of code for t104x diu, and have it be called by an appropriate
> > initfunc.
> >
>
> "fix" is means to handle some boards those based on corenet_generic config file,
> But those boards may need some special handle. Perhaps these used to handle
> special feature codes not have an appropriate initfunc we cannot *just find*
> an appropriate place,
I'm not asking you to "just find" anything. I'm asking you to add an
initfunc in a standalone file.
> if more and more boards need to do this, at that time maybe *initfunc*
> looks very complicated.
They would each have their own initfunc. There is no reason to tie this
in with anything else.
> > > --- a/arch/powerpc/platforms/85xx/Kconfig
> > > +++ b/arch/powerpc/platforms/85xx/Kconfig
> > > @@ -269,6 +269,17 @@ config CORENET_GENERIC
> > > The following boards are supported for both 32bit and 64bit kernel:
> > > P5020 DS and P5040 DS
> > >
> > > +config FIX_GENERIC_PLATFORM_INIT
> > > + bool "Fix Generic Initialization"
> > > + depends on CORENET_GENERIC
> >
> > Why does this depend on CORENET_GENERIC?
> >
>
> Because CORENET_GENERIC is a multiboards file, This is designed to handle this situation.
This DIU code is going to be just as applicable to a custom T104x board
which may or may not use CORENET_GENERIC.
> > > + default y
> >
> > No.
> >
>
> Why not? This will not increase any redundant operations if there is not any boards need fix.
> You can see my fix.c code.
default y should not be used for hardware specific code.
-Scott
^ permalink raw reply
* Re: [PATCH 1/1] powerpc: Increase COMMAND_LINE_SIZE to 2048 from 512.
From: Joseph Salisbury @ 2014-04-16 18:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, linux-kernel, stable, anton
In-Reply-To: <1397555363.14218.6.camel@pasglop>
On 04/15/2014 05:49 AM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-04-14 at 14:58 -0400, Joseph Salisbury wrote:
>> After further review, it appears ppc does not actually use the define
>> in
>> the ppc headers but uses the common generic
>> default(include/uapi/asm-generic/setup.h). COMMAND_LINE_SIZE should
>> probably become a kernel config option. Do folks agree that is the
>> correct thing to do? If so, I can re-work the patch.
> No objection on my side.
>
> Make sure you remove any unused arch define while at it.
>
> Cheers,
> Ben.
>
>
Hi Ben,
I can think of two ways to add the new config option. One would be to
have a large entry in ~/arch/Kconfig, with a default COMMAND_LINE_SIZE
line for each architecture. The other way would be to have the default
value for COMMAND_LINE_SIZE in the architecture sub-directory Kconfig
file: ~/arch/powerpc/Kconfig for example.
Do you have a preference for either way?
Thanks,
Joe
^ permalink raw reply
* Re: [PATCH v4] powerpc: kvm: make _PAGE_NUMA take effect
From: Alexander Graf @ 2014-04-16 12:27 UTC (permalink / raw)
To: Liu Ping Fan, linuxppc-dev, kvm-ppc; +Cc: Paul Mackerras, Aneesh Kumar K.V, kvm
In-Reply-To: <1397550820-29993-1-git-send-email-pingfank@linux.vnet.ibm.com>
On 15.04.14 10:33, Liu Ping Fan wrote:
> Numa fault is a method which help to achieve auto numa balancing.
> When such a page fault takes place, the page fault handler will check
> whether the page is placed correctly. If not, migration should be
> involved to cut down the distance between the cpu and pages.
>
> A pte with _PAGE_NUMA help to implement numa fault. It means not to
> allow the MMU to access the page directly. So a page fault is triggered
> and numa fault handler gets the opportunity to run checker.
>
> As for the access of MMU, we need special handling for the powernv's guest.
> When we mark a pte with _PAGE_NUMA, we already call mmu_notifier to
> invalidate it in guest's htab, but when we tried to re-insert them,
> we firstly try to map it in real-mode. Only after this fails, we fallback
> to virt mode, and most of important, we run numa fault handler in virt
> mode. This patch guards the way of real-mode to ensure that if a pte is
> marked with _PAGE_NUMA, it will NOT be mapped in real mode, instead, it will
> be mapped in virt mode and have the opportunity to be checked with placement.
>
> Signed-off-by: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Thanks, applied to for-3.15.
Alex
^ permalink raw reply
* Re: [v3] mtd: m25p80: Modify the name of mtd_info
From: Brian Norris @ 2014-04-16 6:53 UTC (permalink / raw)
To: Hou Zhiqiang
Cc: Scott Wood, linuxppc-dev@ozlabs.org, Mingkai.Hu@freescale.com,
linux-mtd@lists.infradead.org, David Woodhouse
In-Reply-To: <1395478518-22308-1-git-send-email-B48286@freescale.com>
On Sat, Mar 22, 2014 at 1:55 AM, Hou Zhiqiang <B48286@freescale.com> wrote:
> v3:
> Fix a bug, matching unsigned long long with "%llx".
> v2:
> 1. Fix some code style issue.
> 2. Cast physical address to unsigned long long.
I missed v2 and v3 and commented on v1 instead, sorry. Same comments
apply here though.
Also, can you please include PATCH in the subject? (e.g., [PATCH v3])
See Documentation/SubmittingPatches, item 11.
Thanks,
Brian
^ permalink raw reply
* Re: [PATCH] mtd: m25p80: Modify the name of mtd_info
From: Brian Norris @ 2014-04-16 6:48 UTC (permalink / raw)
To: Hou Zhiqiang; +Cc: scottwood, linuxppc-dev, mingkai.hu, linux-mtd, dwmw2
In-Reply-To: <1395400578-5637-1-git-send-email-B48286@freescale.com>
On Fri, Mar 21, 2014 at 07:16:18PM +0800, Hou Zhiqiang wrote:
> To specify spi flash layouts by "mtdparts=..." in cmdline, we must
> give mtd_info a fixed name,because the cmdlinepart's parser will
> match the name of mtd_info given in cmdline.
> Now, if use DT, the mtd_info's name will be spi->dev->name. It
> consists of spi_master->bus_num, and the spi_master->bus_num maybe
> dynamically fetched. So, in this case, replace the component bus_num
> with thei physical address of spi master.
>
> Signed-off-by: Hou Zhiqiang <B48286@freescale.com>
> ---
> drivers/mtd/devices/m25p80.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 7eda71d..64450a2 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -30,6 +30,7 @@
> #include <linux/mtd/cfi.h>
> #include <linux/mtd/mtd.h>
> #include <linux/mtd/partitions.h>
> +#include <linux/of_address.h>
> #include <linux/of_platform.h>
>
> #include <linux/spi/spi.h>
> @@ -934,9 +935,11 @@ static int m25p_probe(struct spi_device *spi)
> struct flash_platform_data *data;
> struct m25p *flash;
> struct flash_info *info;
> - unsigned i;
> + unsigned i, ret;
> struct mtd_part_parser_data ppdata;
> struct device_node *np = spi->dev.of_node;
> + struct resource res;
> + struct device_node *mnp = spi->master->dev.of_node;
>
> /* Platform data helps sort out which chip type we have, as
> * well as how this board partitions it. If we don't have
> @@ -1009,8 +1012,17 @@ static int m25p_probe(struct spi_device *spi)
>
> if (data && data->name)
> flash->mtd.name = data->name;
> - else
> - flash->mtd.name = dev_name(&spi->dev);
> + else{
> + ret = of_address_to_resource(mnp, 0, &res);
You're making a lot assumptions about the SPI master/device
relationship -- that the master has a device-node; that the first
resource of the master is its physical address (this is not guaranteed
by DT semantics). Please do not do this.
> + if (ret) {
> + dev_err(&spi->dev, "failed to get spi master resource\n");
> + return ret;
This is wrong. It breaks all !CONFIG_OF cases which didn't specify a
name via platform data.
> + }
> + flash->mtd.name = kasprintf(GFP_KERNEL, "spi%x.%d",
> + (unsigned)res.start, spi->chip_select);
> + if (!flash->mtd.name)
> + return -ENOMEM;
> + }
>
> flash->mtd.type = MTD_NORFLASH;
> flash->mtd.writesize = 1;
Brian
^ permalink raw reply
* RE: [PATCH 2/2] fsl/mpic_timer: make mpic_timer to support deep sleep feature
From: Dongsheng.Wang @ 2014-04-16 6:06 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, chenhui.zhao@freescale.com,
Jason.Jin@freescale.com
In-Reply-To: <1397595963.20280.279.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxNiwgMjAxNCA1OjA2IEFNDQo+IFRvOiBXYW5n
IERvbmdzaGVuZy1CNDA1MzQNCj4gQ2M6IEppbiBaaGVuZ3hpb25nLVI2NDE4ODsgTGkgWWFuZy1M
ZW8tUjU4NDcyOyBaaGFvIENoZW5odWktQjM1MzM2OyBsaW51eHBwYy0NCj4gZGV2QGxpc3RzLm96
bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzJdIGZzbC9tcGljX3RpbWVyOiBtYWtl
IG1waWNfdGltZXIgdG8gc3VwcG9ydCBkZWVwIHNsZWVwDQo+IGZlYXR1cmUNCj4gDQo+IE9uIE1v
biwgMjAxNC0wNC0xNCBhdCAyMjoyMyAtMDUwMCwgV2FuZyBEb25nc2hlbmctQjQwNTM0IHdyb3Rl
Og0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogV29v
ZCBTY290dC1CMDc0MjENCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE1LCAyMDE0IDc6MzYg
QU0NCj4gPiA+IFRvOiBXYW5nIERvbmdzaGVuZy1CNDA1MzQNCj4gPiA+IENjOiBKaW4gWmhlbmd4
aW9uZy1SNjQxODg7IExpIFlhbmctTGVvLVI1ODQ3MjsgWmhhbyBDaGVuaHVpLUIzNTMzNjsNCj4g
bGludXhwcGMtDQo+ID4gPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6
IFtQQVRDSCAyLzJdIGZzbC9tcGljX3RpbWVyOiBtYWtlIG1waWNfdGltZXIgdG8gc3VwcG9ydCBk
ZWVwDQo+IHNsZWVwDQo+ID4gPiBmZWF0dXJlDQo+ID4gPg0KPiA+ID4gT24gTW9uLCAyMDE0LTA0
LTE0IGF0IDEwOjI0ICswODAwLCBEb25nc2hlbmcgV2FuZyB3cm90ZToNCj4gPiA+ID4gRnJvbTog
V2FuZyBEb25nc2hlbmcgPGRvbmdzaGVuZy53YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+DQo+
ID4gPiA+IEF0IFQxMDR4IHBsYXRmcm9tIHRoZSB0aW1lciBjbG9jayB3aWxsIGJlIGNoYW5nZWQg
d2hlbiBzeXN0ZW0gZ29pbmcgdG8NCj4gPiA+ID4gZGVlcCBzbGVlcC4NCj4gPiA+DQo+ID4gPiBD
b3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgaXMgY2hhbmdpbmcgYW5kIHdoeT8NCj4gPiA+DQo+
ID4NCj4gPiBPa2F5Lg0KPiA+DQo+ID4gPiA+ICsjaW5jbHVkZSA8YXNtL21wYzg1eHguaD4NCj4g
PiA+ID4gICNpbmNsdWRlIDxhc20vbXBpY190aW1lci5oPg0KPiA+ID4NCj4gPiA+IFNvIG11Y2gg
Zm9yLCAiVGhlIGRyaXZlciBjdXJyZW50bHkgaXMgb25seSB0ZXN0ZWQgb24gZnNsIGNoaXAsIGJ1
dCBpdCBjYW4NCj4gPiA+IHBvdGVudGlhbGx5IHN1cHBvcnQgb3RoZXIgZ2xvYmFsIHRpbWVycyBj
b21wbHlpbmcgdG8gT3BlblBJQyBzdGFuZGFyZC4iDQo+ID4gPg0KPiA+ID4gPiAgI2RlZmluZSBG
U0xfR0xPQkFMX1RJTUVSCQkweDENCj4gPiA+ID4gQEAgLTcxLDggKzc0LDEwIEBAIHN0cnVjdCB0
aW1lcl9ncm91cF9wcml2IHsNCj4gPiA+ID4gIAlzdHJ1Y3QgdGltZXJfcmVncyBfX2lvbWVtCSpy
ZWdzOw0KPiA+ID4gPiAgCXN0cnVjdCBtcGljX3RpbWVyCQl0aW1lcltUSU1FUlNfUEVSX0dST1VQ
XTsNCj4gPiA+ID4gIAlzdHJ1Y3QgbGlzdF9oZWFkCQlub2RlOw0KPiA+ID4gPiArCXVuc2lnbmVk
IGxvbmcJCQlpZGxlOw0KPiA+ID4gPiAgCXVuc2lnbmVkIGludAkJCXRpbWVyZnJlcTsNCj4gPiA+
ID4gLQl1bnNpZ25lZCBpbnQJCQlpZGxlOw0KPiA+ID4NCj4gPiA+IFdoeT8NCj4gPiA+DQo+ID4N
Cj4gPiBVbS4uLiBJdCBzaG91bGRuJ3QgYmUgaGFwcGVuZWQuLi5pIHdpbGwgcmVtb3ZlIHRoaXMu
DQo+ID4NCj4gPiA+ID4gKwl1bnNpZ25lZCBpbnQJCQlzdXNwZW5kZWRfdGltZXJmcmVxOw0KPiA+
ID4gPiArCXVuc2lnbmVkIGludAkJCXJlc3VtZV90aW1lcmZyZXE7DQo+ID4gPiA+ICAJdW5zaWdu
ZWQgaW50CQkJZmxhZ3M7DQo+ID4gPiA+ICAJc3BpbmxvY2tfdAkJCWxvY2s7DQo+ID4gPiA+ICAJ
dm9pZCBfX2lvbWVtCQkJKmdyb3VwX3RjcjsNCj4gPiA+ID4gQEAgLTg4LDYgKzkzLDcgQEAgc3Rh
dGljIHN0cnVjdCBjYXNjYWRlX3ByaXYgY2FzY2FkZV90aW1lcltdID0geyAgfTsNCj4gPiA+ID4N
Cj4gPiA+ID4gIHN0YXRpYyBMSVNUX0hFQUQodGltZXJfZ3JvdXBfbGlzdCk7DQo+ID4gPiA+ICtz
dGF0aWMgaW50IHN3aXRjaF9mcmVxX2ZsYWc7DQo+ID4gPg0KPiA+ID4gTmVlZHMgZG9jdW1lbnRh
dGlvbiwgYW5kIGJhc2VkIG9uICJfZmxhZyIgaXQgc2hvdWxkIHByb2JhYmx5IGJlIGEgYm9vbC4N
Cj4gPiA+DQo+ID4NCj4gPiBPa2F5Lg0KPiA+DQo+ID4gPiA+ICBzdGF0aWMgdm9pZCBjb252ZXJ0
X3RpY2tzX3RvX3RpbWUoc3RydWN0IHRpbWVyX2dyb3VwX3ByaXYgKnByaXYsDQo+ID4gPiA+ICAJ
CWNvbnN0IHU2NCB0aWNrcywgc3RydWN0IHRpbWV2YWwgKnRpbWUpIEBAIC00MjMsNiArNDI5LDMz
IEBADQo+IHN0cnVjdA0KPiA+ID4gPiBtcGljX3RpbWVyICptcGljX3JlcXVlc3RfdGltZXIoaXJx
X2hhbmRsZXJfdCBmbiwgdm9pZCAqZGV2LCAgfQ0KPiA+ID4gPiBFWFBPUlRfU1lNQk9MKG1waWNf
cmVxdWVzdF90aW1lcik7DQo+ID4gPiA+DQo+ID4gPiA+ICtzdGF0aWMgdm9pZCB0aW1lcl9ncm91
cF9nZXRfc3VzcGVuZGVkX2ZyZXEoc3RydWN0IHRpbWVyX2dyb3VwX3ByaXYNCj4gPiA+ID4gKypw
cml2KSB7DQo+ID4gPiA+ICsJc3RydWN0IGRldmljZV9ub2RlICpucDsNCj4gPiA+ID4gKw0KPiA+
ID4gPiArCW5wID0gb2ZfZmluZF9jb21wYXRpYmxlX25vZGUoTlVMTCwgTlVMTCwgImZzbCxxb3Jp
cS1jbG9ja2dlbi0yLjAiKTsNCj4gPiA+ID4gKwlpZiAoIW5wKSB7DQo+ID4gPiA+ICsJCXByX2Vy
cigibXBpYyB0aW1lcjogTWlzc2luZyBjbG9ja2dlbiBkZXZpY2Ugbm9kZS5cbiIpOw0KPiA+ID4N
Cj4gPiA+IFdoeSBpcyBpdCBhbiBlcnJvciB0byBub3QgaGF2ZSBhIDIuMCBRb3JJUSBjbG9ja2dl
bj8NCj4gPiA+DQo+ID4NCj4gPiBUaGlzIHdpbGwgYWZmZWN0IHRoZSBhY2N1cmFjeSBvZiB0aGUg
dGltZXIuIEJ1dCBub3QgbWVhbnMgdGhlIHRpbWVyIGNhbm5vdA0KPiB3b3JrLg0KPiA+IE1heWJl
IHlvdSBhcmUgcmlnaHQsIHRoaXMgcHJfZXJyIHNob3VsZCBiZSBhIHByX3dhcm4uDQo+IA0KPiBX
aGF0IEkgbWVhbiBpcywgd2hhdCBpZiB0aGUgbXBpYyB0aW1lciBkcml2ZXIgaXMgdXNlZCB3aXRo
IGRlZXAgc2xlZXAgb24NCj4gYSBkaWZmZXJlbnQgY2hpcCBzdWNoIGFzIG1wYzg1MzY/DQo+IA0K
DQpPbmx5IFQxMDR4IGhhcyB0aGlzIGZlYXR1cmUsIG90aGVyIHBsYXRmb3JtIHdpbGwgbm90IGJl
IGVmZmVjdC4NCkkgd2lsbCByZW1vdmUgdGhpcyBwcl9lcnIuDQoNCj4gPiA+ID4gKwkJcmV0dXJu
Ow0KPiA+ID4gPiArCX0NCj4gPiA+ID4gKw0KPiA+ID4gPiArCW9mX3Byb3BlcnR5X3JlYWRfdTMy
KG5wLCAiY2xvY2stZnJlcXVlbmN5IiwgJnByaXYtDQo+ID5zdXNwZW5kZWRfdGltZXJmcmVxKTsN
Cj4gPiA+ID4gKwlvZl9ub2RlX3B1dChucCk7DQo+ID4gPg0KPiA+ID4gU2hvdWxkbid0IHRoaXMg
Z28gdGhyb3VnaCB0aGUgY2xvY2sgQVBJPw0KPiA+ID4NCj4gPg0KPiA+IFNvcnJ5LCBJJ20gbm90
IGNsZWFyIGFib3V0IGNsb2NrIEFQSSwgeW91IG1lYW4gZnNsX2dldF9zeXNfZnJlcSgpPyBPciA/
DQo+IA0KPiBObywgSSBtZWFuIGRyaXZlcnMvY2xrLw0KPiANCj4gVGhvdWdoIEkgc3VwcG9zZSBt
YW51YWxseSByZWFkaW5nIGNsb2NrLWZyZXF1ZW5jeSBpcyBPSywgYXMgdGhlDQo+IGNsb2NrLWZy
ZXF1ZW5jeSBvbiB0aGUgY2xvY2tnZW4gbm9kZSBwcmVkYXRlZCB0aGUgaW50cm9kdWN0aW9uIG9m
IGNsb2NrDQo+IGJpbmRpbmdzIHRvIHRoZSBkZXZpY2UgdHJlZS4NCj4gDQo+IERvbid0IHVzZSBm
c2xfZ2V0X3N5c19mcmVxKCkuDQo+IA0KDQpObywgd2UgY2Fubm90IHVzZSBkcml2ZXJzL2Nsay8u
IEJlY2F1c2UgY2xrLXBwYy1jb3JlbmV0LmMgb25seSBzdXBwb3J0IGNvcmVuZXQgcGxhdGZvcm0u
DQoNCj4gPiA+ID4gK3N0YXRpYyBpbnQgbmVlZF90b19zd2l0Y2hfZnJlcSh2b2lkKQ0KPiA+ID4g
PiArew0KPiA+ID4gPiArCXUzMiBzdnI7DQo+ID4gPiA+ICsNCj4gPiA+ID4gKwlzdnIgPSBtZnNw
cihTUFJOX1NWUik7DQo+ID4gPiA+ICsJaWYgKFNWUl9TT0NfVkVSKHN2cikgPT0gU1ZSX1QxMDQw
IHx8DQo+ID4gPiA+ICsJCQlTVlJfU09DX1ZFUihzdnIpID09IFNWUl9UMTA0MikNCj4gPiA+ID4g
KwkJcmV0dXJuIDE7DQo+ID4gPg0KPiA+ID4gRXhwbGFpbiB3aHkgdGhpcyBpcyBzcGVjaWZpYyB0
byBUMTA0eC4NCj4gPiA+DQo+ID4NCj4gPiBNcGljIHRpbWVyIGZyZXEgd2lsbCBiZSBjaGFuZ2Ug
d2hlbiBzeXN0ZW0gZ29pbmcgdG8gZGVlcCBzbGVlcC4gU28gd2UgbmVlZCB0bw0KPiByZWNhbGN1
bGF0ZSB0aGUgdGltZS4NCj4gDQo+IERvIGFueSBvdGhlciBjaGlwcyB3aXRoIGRlZXAgc2xlZXAg
aGF2ZSB0aGlzIHByb2JsZW0/DQo+IA0KDQpPbmx5IGhhcyBvbiBUMTA0eCByaWdodCBub3cuDQoN
ClJlZ2FyZHMsDQotRG9uZ3NoZW5nDQoNCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* Re: [PATCH v2] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
From: Michael wang @ 2014-04-16 3:14 UTC (permalink / raw)
To: linuxppc-dev, LKML, benh, paulus, nfont, sfr, Andrew Morton, rcj,
jlarrew, srivatsa.bhat, alistair
In-Reply-To: <53436AC8.5020705@linux.vnet.ibm.com>
On 04/08/2014 11:19 AM, Michael wang wrote:
> Since v1:
> Edited the comment according to Srivatsa's suggestion.
>
> During the testing, we encounter below WARN followed by Oops:
Is there any more comments on this issue? Should we apply this fix?
Regards,
Michael Wang
>
> WARNING: at kernel/sched/core.c:6218
> ...
> NIP [c000000000101660] .build_sched_domains+0x11d0/0x1200
> LR [c000000000101358] .build_sched_domains+0xec8/0x1200
> PACATMSCRATCH [800000000000f032]
> Call Trace:
> [c00000001b103850] [c000000000101358] .build_sched_domains+0xec8/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
> Oops: Kernel access of bad area, sig: 11 [#1]
> ...
> NIP [c00000000045c000] .__bitmap_weight+0x60/0xf0
> LR [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> PACATMSCRATCH [8000000000029032]
> Call Trace:
> [c00000001b1037a0] [c000000000288ff4] .kmem_cache_alloc_node_trace+0x184/0x3a0
> [c00000001b103850] [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
>
> This was caused by that 'sd->groups == NULL' after building groups, which
> was caused by the empty 'sd->span'.
>
> The cpu's domain contained nothing because the cpu was assigned to a wrong
> node, due to the following unfortunate sequence of events:
>
> 1. The hypervisor sent a topology update to the guest OS, to notify changes
> to the cpu-node mapping. However, the update was actually redundant - i.e.,
> the "new" mapping was exactly the same as the old one.
>
> 2. Due to this, the 'updated_cpus' mask turned out to be empty after exiting
> the 'for-loop' in arch_update_cpu_topology().
>
> 3. So we ended up calling stop-machine() with an empty cpumask list, which made
> stop-machine internally elect cpumask_first(cpu_online_mask), i.e., CPU0 as
> the cpu to run the payload (the update_cpu_topology() function).
>
> 4. This causes update_cpu_topology() to be run by CPU0. And since 'updates'
> is kzalloc()'ed inside arch_update_cpu_topology(), update_cpu_topology()
> finds update->cpu as well as update->new_nid to be 0. In other words, we
> end up assigning CPU0 (and eventually its siblings) to node 0, incorrectly.
>
> Along with the following wrong updating, it causes the sched-domain rebuild
> code to break and crash the system.
>
> Fix this by skipping the topology update in cases where we find that
> the topology has not actually changed in reality (ie., spurious updates).
>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> CC: Stephen Rothwell <sfr@canb.auug.org.au>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Robert Jennings <rcj@linux.vnet.ibm.com>
> CC: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
> CC: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> CC: Alistair Popple <alistair@popple.id.au>
> Suggested-by: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/numa.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 30a42e2..4ebbb9e 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1591,6 +1591,20 @@ int arch_update_cpu_topology(void)
> cpu = cpu_last_thread_sibling(cpu);
> }
>
> + /*
> + * In cases where we have nothing to update (because the updates list
> + * is too short or because the new topology is same as the old one),
> + * skip invoking update_cpu_topology() via stop-machine(). This is
> + * necessary (and not just a fast-path optimization) since stop-machine
> + * can end up electing a random CPU to run update_cpu_topology(), and
> + * thus trick us into setting up incorrect cpu-node mappings (since
> + * 'updates' is kzalloc()'ed).
> + *
> + * And for the similar reason, we will skip all the following updating.
> + */
> + if (!cpumask_weight(&updated_cpus))
> + goto out;
> +
> stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
>
> /*
> @@ -1612,6 +1626,7 @@ int arch_update_cpu_topology(void)
> changed = 1;
> }
>
> +out:
> kfree(updates);
> return changed;
> }
>
^ permalink raw reply
* RE: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization for platform
From: Dongsheng.Wang @ 2014-04-16 2:58 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, haokexin@gmail.com,
prabhakar@freescale.com, Jason.Jin@freescale.com
In-Reply-To: <1397590755.20280.250.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBBcHJpbCAxNiwgMjAxNCAzOjM5IEFNDQo+IFRvOiBXYW5n
IERvbmdzaGVuZy1CNDA1MzQNCj4gQ2M6IEppbiBaaGVuZ3hpb25nLVI2NDE4ODsgaGFva2V4aW5A
Z21haWwuY29tOyBLdXNod2FoYSBQcmFiaGFrYXItQjMyNTc5Ow0KPiBsaW51eHBwYy1kZXZAbGlz
dHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIIHYyIDEvMl0gZnNsL2NvcmVuZXRf
Z2VuZXJpYzogYWRkIGEgcGFydGljdWxhciBpbml0aWFsaXphdGlvbg0KPiBmb3IgcGxhdGZvcm0N
Cj4gDQo+IE9uIFR1ZSwgMjAxNC0wNC0xNSBhdCAxMzo1MyArMDgwMCwgRG9uZ3NoZW5nIFdhbmcg
d3JvdGU6DQo+ID4gRnJvbTogV2FuZyBEb25nc2hlbmcgPGRvbmdzaGVuZy53YW5nQGZyZWVzY2Fs
ZS5jb20+DQo+ID4NCj4gPiBDb3JlbmV0X2dlbmVyaWMgaXMgYSBnZW5lcmljIHBsYXRmb3JtIGlu
aXRpYWxpemF0aW9uLiBUaG9zZSBiYXNlZCBvbg0KPiA+IHRoZSBjb3JlbmV0X2dlbmVyaWMgYm9h
cmQgbWF5YmUgbmVlZCBhIHBhcnRpY3VsYXIgaW5pdGlhbGl6ZSB0bw0KPiA+IGVuYWJsZS9zZXQg
c29tZSBJUC1CbG9ja3MuIFNvIGFkZCAiRml4IEdlbmVyaWMgSW5pdGlhbGl6YXRpb24iIHRvIHNv
bHZlDQo+ID4gdGhpcyBraW5kIG9mIHNwZWNpYWwgY2FzZXMuDQo+IA0KPiBJIHN0aWxsIGRvbid0
IHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbiBieSAiZml4Ii4gIFdoYXQgYXJlIHlvdSBmaXhpbmcs
DQo+IG9yIHdoYXQgaXMgZml4ZWQ/DQo+IA0KPiBUaGVyZSBpcyBubyBuZWVkIGZvciBhZGRpbmcg
YW4gaW5mcmFzdHJ1Y3R1cmUgbGF5ZXIgaGVyZS4gIEp1c3QgYWRkIGENCj4gbmV3IHBpZWNlIG9m
IGNvZGUgZm9yIHQxMDR4IGRpdSwgYW5kIGhhdmUgaXQgYmUgY2FsbGVkIGJ5IGFuIGFwcHJvcHJp
YXRlDQo+IGluaXRmdW5jLg0KPiANCg0KImZpeCIgaXMgbWVhbnMgdG8gaGFuZGxlIHNvbWUgYm9h
cmRzIHRob3NlIGJhc2VkIG9uIGNvcmVuZXRfZ2VuZXJpYyBjb25maWcgZmlsZSwNCkJ1dCB0aG9z
ZSBib2FyZHMgbWF5IG5lZWQgc29tZSBzcGVjaWFsIGhhbmRsZS4gUGVyaGFwcyB0aGVzZSB1c2Vk
IHRvIGhhbmRsZQ0Kc3BlY2lhbCBmZWF0dXJlIGNvZGVzIG5vdCBoYXZlIGFuIGFwcHJvcHJpYXRl
IGluaXRmdW5jIHdlIGNhbm5vdCAqanVzdCBmaW5kKg0KYW4gYXBwcm9wcmlhdGUgcGxhY2UsIGlm
IG1vcmUgYW5kIG1vcmUgYm9hcmRzIG5lZWQgdG8gZG8gdGhpcywgYXQgdGhhdCB0aW1lDQptYXli
ZSAqaW5pdGZ1bmMqIGxvb2tzIHZlcnkgY29tcGxpY2F0ZWQuIFNvIHdlIG5lZWQgdGhpcyAiZml4
IiBsYXllciB0byBkZWFsIHRoZW0uDQpXZSBuZWVkIGEgcGxhbiB0byBmaXggdGhvc2UgYm9hcmRz
LCBub3QganVzdCBmaW5kIGFuIGluaXRmdW5jLiBJIHRoaW5rcyAiZml4Ig0KaXMgdGhlIGJlc3Qg
aW5pdGZ1bmMgdG8gaGFuZGxlIHRob3NlIHNwZWNpYWwgdGhpbmdzLg0KDQpJZiAiZml4IiBpcyBu
b3QgY2xlYXIsIGRpZCB5b3UgaGF2ZSBhIGdvb2QgaWRlYXI/IDopDQoNCj4gPiBTaWduZWQtb2Zm
LWJ5OiBXYW5nIERvbmdzaGVuZyA8ZG9uZ3NoZW5nLndhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPiAt
LS0NCj4gPiAqdjIqDQo+ID4gIDEvIFNwbGl0IERJVSBjb2RlLg0KPiA+ICAyLyBtYWtlIGZpeC5j
IGFzIGEgaW5kZXBlbmRlbnQgZHJpdmVyLg0KPiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMv
cGxhdGZvcm1zLzg1eHgvS2NvbmZpZw0KPiBiL2FyY2gvcG93ZXJwYy9wbGF0Zm9ybXMvODV4eC9L
Y29uZmlnDQo+ID4gaW5kZXggYzE3YWFlOC4uZmNlMjM0MSAxMDA2NDQNCj4gPiAtLS0gYS9hcmNo
L3Bvd2VycGMvcGxhdGZvcm1zLzg1eHgvS2NvbmZpZw0KPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9w
bGF0Zm9ybXMvODV4eC9LY29uZmlnDQo+ID4gQEAgLTI2OSw2ICsyNjksMTcgQEAgY29uZmlnIENP
UkVORVRfR0VORVJJQw0KPiA+ICAJICBUaGUgZm9sbG93aW5nIGJvYXJkcyBhcmUgc3VwcG9ydGVk
IGZvciBib3RoIDMyYml0IGFuZCA2NGJpdCBrZXJuZWw6DQo+ID4gIAkgICAgUDUwMjAgRFMgYW5k
IFA1MDQwIERTDQo+ID4NCj4gPiArY29uZmlnIEZJWF9HRU5FUklDX1BMQVRGT1JNX0lOSVQNCj4g
PiArCWJvb2wgIkZpeCBHZW5lcmljIEluaXRpYWxpemF0aW9uIg0KPiA+ICsJZGVwZW5kcyBvbiBD
T1JFTkVUX0dFTkVSSUMNCj4gDQo+IFdoeSBkb2VzIHRoaXMgZGVwZW5kIG9uIENPUkVORVRfR0VO
RVJJQz8NCj4gDQoNCkJlY2F1c2UgQ09SRU5FVF9HRU5FUklDIGlzIGEgbXVsdGlib2FyZHMgZmls
ZSwgVGhpcyBpcyBkZXNpZ25lZCB0byBoYW5kbGUgdGhpcyBzaXR1YXRpb24uDQoNCj4gPiArCWRl
ZmF1bHQgeQ0KPiANCj4gTm8uDQo+IA0KDQpXaHkgbm90PyBUaGlzIHdpbGwgbm90IGluY3JlYXNl
IGFueSByZWR1bmRhbnQgb3BlcmF0aW9ucyBpZiB0aGVyZSBpcyBub3QgYW55IGJvYXJkcyBuZWVk
IGZpeC4NCllvdSBjYW4gc2VlIG15IGZpeC5jIGNvZGUuDQoNClJlZ2FyZHMsDQotRG9uZ3NoZW5n
DQoNCj4gLVNjb3R0DQo+IA0KDQo=
^ permalink raw reply
* [PATCH v2 2/8] cpufreq: Use cpufreq_for_each_* macros for frequency table iteration
From: Stratos Karafotis @ 2014-04-15 22:25 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar
Cc: Kukjin Kim, linux-pm, LKML, cpufreq@vger.kernel.org,
linux-samsung-soc, Sudeep Holla, Olof Johansson, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
The cpufreq core now supports the cpufreq_for_each_entry and
cpufreq_for_each_valid_entry macros helpers for iteration over the
cpufreq_frequency_table, so use them.
It should have no functional changes.
Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr>
---
drivers/cpufreq/acpi-cpufreq.c | 9 +++---
drivers/cpufreq/arm_big_little.c | 16 +++++------
drivers/cpufreq/cpufreq_stats.c | 24 ++++++----------
drivers/cpufreq/dbx500-cpufreq.c | 8 ++----
drivers/cpufreq/elanfreq.c | 9 +++---
drivers/cpufreq/exynos-cpufreq.c | 11 ++++---
drivers/cpufreq/exynos5440-cpufreq.c | 30 +++++++++----------
drivers/cpufreq/freq_table.c | 56 ++++++++++++++++--------------------
drivers/cpufreq/longhaul.c | 13 ++++-----
drivers/cpufreq/pasemi-cpufreq.c | 10 +++----
drivers/cpufreq/powernow-k6.c | 14 ++++-----
drivers/cpufreq/ppc_cbe_cpufreq.c | 9 +++---
drivers/cpufreq/s3c2416-cpufreq.c | 40 +++++++++++---------------
drivers/cpufreq/s3c64xx-cpufreq.c | 15 ++++------
14 files changed, 117 insertions(+), 147 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 000e4e0..b0c18ed 100644
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -213,7 +213,7 @@ static unsigned extract_io(u32 value, struct acpi_cpufreq_data *data)
static unsigned extract_msr(u32 msr, struct acpi_cpufreq_data *data)
{
- int i;
+ struct cpufreq_frequency_table *pos;
struct acpi_processor_performance *perf;
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)
@@ -223,10 +223,9 @@ static unsigned extract_msr(u32 msr, struct acpi_cpufreq_data *data)
perf = data->acpi_data;
- for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
- if (msr == perf->states[data->freq_table[i].driver_data].status)
- return data->freq_table[i].frequency;
- }
+ cpufreq_for_each_entry(pos, data->freq_table)
+ if (msr == perf->states[pos->driver_data].status)
+ return pos->frequency;
return data->freq_table[0].frequency;
}
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index bad2ed3..1f4d4e3 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -226,22 +226,22 @@ static inline u32 get_table_count(struct cpufreq_frequency_table *table)
/* get the minimum frequency in the cpufreq_frequency_table */
static inline u32 get_table_min(struct cpufreq_frequency_table *table)
{
- int i;
+ struct cpufreq_frequency_table *pos;
uint32_t min_freq = ~0;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
- if (table[i].frequency < min_freq)
- min_freq = table[i].frequency;
+ cpufreq_for_each_entry(pos, table)
+ if (pos->frequency < min_freq)
+ min_freq = pos->frequency;
return min_freq;
}
/* get the maximum frequency in the cpufreq_frequency_table */
static inline u32 get_table_max(struct cpufreq_frequency_table *table)
{
- int i;
+ struct cpufreq_frequency_table *pos;
uint32_t max_freq = 0;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++)
- if (table[i].frequency > max_freq)
- max_freq = table[i].frequency;
+ cpufreq_for_each_entry(pos, table)
+ if (pos->frequency > max_freq)
+ max_freq = pos->frequency;
return max_freq;
}
diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c
index ecaaebf..0cd9b4d 100644
--- a/drivers/cpufreq/cpufreq_stats.c
+++ b/drivers/cpufreq/cpufreq_stats.c
@@ -182,11 +182,11 @@ static void cpufreq_stats_free_table(unsigned int cpu)
static int __cpufreq_stats_create_table(struct cpufreq_policy *policy)
{
- unsigned int i, j, count = 0, ret = 0;
+ unsigned int i, count = 0, ret = 0;
struct cpufreq_stats *stat;
unsigned int alloc_size;
unsigned int cpu = policy->cpu;
- struct cpufreq_frequency_table *table;
+ struct cpufreq_frequency_table *pos, *table;
table = cpufreq_frequency_get_table(cpu);
if (unlikely(!table))
@@ -205,12 +205,8 @@ static int __cpufreq_stats_create_table(struct cpufreq_policy *policy)
stat->cpu = cpu;
per_cpu(cpufreq_stats_table, cpu) = stat;
- for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
- unsigned int freq = table[i].frequency;
- if (freq == CPUFREQ_ENTRY_INVALID)
- continue;
+ cpufreq_for_each_valid_entry(pos, table)
count++;
- }
alloc_size = count * sizeof(int) + count * sizeof(u64);
@@ -228,15 +224,11 @@ static int __cpufreq_stats_create_table(struct cpufreq_policy *policy)
#ifdef CONFIG_CPU_FREQ_STAT_DETAILS
stat->trans_table = stat->freq_table + count;
#endif
- j = 0;
- for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
- unsigned int freq = table[i].frequency;
- if (freq == CPUFREQ_ENTRY_INVALID)
- continue;
- if (freq_table_get_index(stat, freq) == -1)
- stat->freq_table[j++] = freq;
- }
- stat->state_num = j;
+ i = 0;
+ cpufreq_for_each_valid_entry(pos, table)
+ if (freq_table_get_index(stat, pos->frequency) == -1)
+ stat->freq_table[i++] = pos->frequency;
+ stat->state_num = i;
spin_lock(&cpufreq_stats_lock);
stat->last_time = get_jiffies_64();
stat->last_index = freq_table_get_index(stat, policy->cur);
diff --git a/drivers/cpufreq/dbx500-cpufreq.c b/drivers/cpufreq/dbx500-cpufreq.c
index 412a78b..4bebc1b 100644
--- a/drivers/cpufreq/dbx500-cpufreq.c
+++ b/drivers/cpufreq/dbx500-cpufreq.c
@@ -45,7 +45,7 @@ static struct cpufreq_driver dbx500_cpufreq_driver = {
static int dbx500_cpufreq_probe(struct platform_device *pdev)
{
- int i = 0;
+ struct cpufreq_frequency_table *pos;
freq_table = dev_get_platdata(&pdev->dev);
if (!freq_table) {
@@ -60,10 +60,8 @@ static int dbx500_cpufreq_probe(struct platform_device *pdev)
}
pr_info("dbx500-cpufreq: Available frequencies:\n");
- while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
- pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
- i++;
- }
+ cpufreq_for_each_entry(pos, freq_table)
+ pr_info(" %d Mhz\n", pos->frequency / 1000);
return cpufreq_register_driver(&dbx500_cpufreq_driver);
}
diff --git a/drivers/cpufreq/elanfreq.c b/drivers/cpufreq/elanfreq.c
index 7f5d2a6..1c06e78 100644
--- a/drivers/cpufreq/elanfreq.c
+++ b/drivers/cpufreq/elanfreq.c
@@ -147,7 +147,7 @@ static int elanfreq_target(struct cpufreq_policy *policy,
static int elanfreq_cpu_init(struct cpufreq_policy *policy)
{
struct cpuinfo_x86 *c = &cpu_data(0);
- unsigned int i;
+ struct cpufreq_frequency_table *pos;
/* capability check */
if ((c->x86_vendor != X86_VENDOR_AMD) ||
@@ -159,10 +159,9 @@ static int elanfreq_cpu_init(struct cpufreq_policy *policy)
max_freq = elanfreq_get_cpu_frequency(0);
/* table init */
- for (i = 0; (elanfreq_table[i].frequency != CPUFREQ_TABLE_END); i++) {
- if (elanfreq_table[i].frequency > max_freq)
- elanfreq_table[i].frequency = CPUFREQ_ENTRY_INVALID;
- }
+ cpufreq_for_each_entry(pos, elanfreq_table)
+ if (pos->frequency > max_freq)
+ pos->frequency = CPUFREQ_ENTRY_INVALID;
/* cpuinfo and default policy values */
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index f99cfe2..9c13255 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -29,17 +29,16 @@ static unsigned int locking_frequency;
static int exynos_cpufreq_get_index(unsigned int freq)
{
struct cpufreq_frequency_table *freq_table = exynos_info->freq_table;
- int index;
+ struct cpufreq_frequency_table *pos;
- for (index = 0;
- freq_table[index].frequency != CPUFREQ_TABLE_END; index++)
- if (freq_table[index].frequency == freq)
+ cpufreq_for_each_entry(pos, freq_table)
+ if (pos->frequency == freq)
break;
- if (freq_table[index].frequency == CPUFREQ_TABLE_END)
+ if (pos->frequency == CPUFREQ_TABLE_END)
return -EINVAL;
- return index;
+ return pos - freq_table;
}
static int exynos_cpufreq_scale(unsigned int target_freq)
diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c
index a6b8214..f33f25b 100644
--- a/drivers/cpufreq/exynos5440-cpufreq.c
+++ b/drivers/cpufreq/exynos5440-cpufreq.c
@@ -114,25 +114,23 @@ static struct cpufreq_freqs freqs;
static int init_div_table(void)
{
- struct cpufreq_frequency_table *freq_tbl = dvfs_info->freq_table;
+ struct cpufreq_frequency_table *pos, *freq_tbl = dvfs_info->freq_table;
unsigned int tmp, clk_div, ema_div, freq, volt_id;
- int i = 0;
struct dev_pm_opp *opp;
rcu_read_lock();
- for (i = 0; freq_tbl[i].frequency != CPUFREQ_TABLE_END; i++) {
-
+ cpufreq_for_each_entry(pos, freq_tbl) {
opp = dev_pm_opp_find_freq_exact(dvfs_info->dev,
- freq_tbl[i].frequency * 1000, true);
+ pos->frequency * 1000, true);
if (IS_ERR(opp)) {
rcu_read_unlock();
dev_err(dvfs_info->dev,
"failed to find valid OPP for %u KHZ\n",
- freq_tbl[i].frequency);
+ pos->frequency);
return PTR_ERR(opp);
}
- freq = freq_tbl[i].frequency / 1000; /* In MHZ */
+ freq = pos->frequency / 1000; /* In MHZ */
clk_div = ((freq / CPU_DIV_FREQ_MAX) & P0_7_CPUCLKDEV_MASK)
<< P0_7_CPUCLKDEV_SHIFT;
clk_div |= ((freq / CPU_ATB_FREQ_MAX) & P0_7_ATBCLKDEV_MASK)
@@ -157,7 +155,8 @@ static int init_div_table(void)
tmp = (clk_div | ema_div | (volt_id << P0_7_VDD_SHIFT)
| ((freq / FREQ_UNIT) << P0_7_FREQ_SHIFT));
- __raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 * i);
+ __raw_writel(tmp, dvfs_info->base + XMU_PMU_P0_7 + 4 *
+ (pos - freq_tbl));
}
rcu_read_unlock();
@@ -166,8 +165,9 @@ static int init_div_table(void)
static void exynos_enable_dvfs(unsigned int cur_frequency)
{
- unsigned int tmp, i, cpu;
+ unsigned int tmp, cpu;
struct cpufreq_frequency_table *freq_table = dvfs_info->freq_table;
+ struct cpufreq_frequency_table *pos;
/* Disable DVFS */
__raw_writel(0, dvfs_info->base + XMU_DVFS_CTRL);
@@ -182,15 +182,15 @@ static void exynos_enable_dvfs(unsigned int cur_frequency)
__raw_writel(tmp, dvfs_info->base + XMU_PMUIRQEN);
/* Set initial performance index */
- for (i = 0; freq_table[i].frequency != CPUFREQ_TABLE_END; i++)
- if (freq_table[i].frequency == cur_frequency)
+ cpufreq_for_each_entry(pos, freq_table)
+ if (pos->frequency == cur_frequency)
break;
- if (freq_table[i].frequency == CPUFREQ_TABLE_END) {
+ if (pos->frequency == CPUFREQ_TABLE_END) {
dev_crit(dvfs_info->dev, "Boot up frequency not supported\n");
/* Assign the highest frequency */
- i = 0;
- cur_frequency = freq_table[i].frequency;
+ pos = freq_table;
+ cur_frequency = pos->frequency;
}
dev_info(dvfs_info->dev, "Setting dvfs initial frequency = %uKHZ",
@@ -199,7 +199,7 @@ static void exynos_enable_dvfs(unsigned int cur_frequency)
for (cpu = 0; cpu < CONFIG_NR_CPUS; cpu++) {
tmp = __raw_readl(dvfs_info->base + XMU_C0_3_PSTATE + cpu * 4);
tmp &= ~(P_VALUE_MASK << C0_3_PSTATE_NEW_SHIFT);
- tmp |= (i << C0_3_PSTATE_NEW_SHIFT);
+ tmp |= ((pos - freq_table) << C0_3_PSTATE_NEW_SHIFT);
__raw_writel(tmp, dvfs_info->base + XMU_C0_3_PSTATE + cpu * 4);
}
diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
index 08e7bbc..cf004a5 100644
--- a/drivers/cpufreq/freq_table.c
+++ b/drivers/cpufreq/freq_table.c
@@ -21,22 +21,19 @@
int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy,
struct cpufreq_frequency_table *table)
{
+ struct cpufreq_frequency_table *pos;
unsigned int min_freq = ~0;
unsigned int max_freq = 0;
- unsigned int i;
+ unsigned int freq;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
- unsigned int freq = table[i].frequency;
- if (freq == CPUFREQ_ENTRY_INVALID) {
- pr_debug("table entry %u is invalid, skipping\n", i);
+ cpufreq_for_each_valid_entry(pos, table) {
+ freq = pos->frequency;
- continue;
- }
if (!cpufreq_boost_enabled()
- && (table[i].flags & CPUFREQ_BOOST_FREQ))
+ && (pos->flags & CPUFREQ_BOOST_FREQ))
continue;
- pr_debug("table entry %u: %u kHz\n", i, freq);
+ pr_debug("table entry %lu: %u kHz\n", pos - table, freq);
if (freq < min_freq)
min_freq = freq;
if (freq > max_freq)
@@ -57,7 +54,8 @@ EXPORT_SYMBOL_GPL(cpufreq_frequency_table_cpuinfo);
int cpufreq_frequency_table_verify(struct cpufreq_policy *policy,
struct cpufreq_frequency_table *table)
{
- unsigned int next_larger = ~0, freq, i = 0;
+ struct cpufreq_frequency_table *pos;
+ unsigned int freq, next_larger = ~0;
bool found = false;
pr_debug("request for verification of policy (%u - %u kHz) for cpu %u\n",
@@ -65,9 +63,9 @@ int cpufreq_frequency_table_verify(struct cpufreq_policy *policy,
cpufreq_verify_within_cpu_limits(policy);
- for (; freq = table[i].frequency, freq != CPUFREQ_TABLE_END; i++) {
- if (freq == CPUFREQ_ENTRY_INVALID)
- continue;
+ cpufreq_for_each_valid_entry(pos, table) {
+ freq = pos->frequency;
+
if ((freq >= policy->min) && (freq <= policy->max)) {
found = true;
break;
@@ -118,7 +116,8 @@ int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
.driver_data = ~0,
.frequency = 0,
};
- unsigned int i;
+ struct cpufreq_frequency_table *pos;
+ unsigned int freq, i = 0;
pr_debug("request for target %u kHz (relation: %u) for cpu %u\n",
target_freq, relation, policy->cpu);
@@ -132,10 +131,10 @@ int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
break;
}
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
- unsigned int freq = table[i].frequency;
- if (freq == CPUFREQ_ENTRY_INVALID)
- continue;
+ cpufreq_for_each_valid_entry(pos, table) {
+ freq = pos->frequency;
+
+ i = pos - table;
if ((freq < policy->min) || (freq > policy->max))
continue;
switch (relation) {
@@ -184,8 +183,7 @@ EXPORT_SYMBOL_GPL(cpufreq_frequency_table_target);
int cpufreq_frequency_table_get_index(struct cpufreq_policy *policy,
unsigned int freq)
{
- struct cpufreq_frequency_table *table;
- int i;
+ struct cpufreq_frequency_table *pos, *table;
table = cpufreq_frequency_get_table(policy->cpu);
if (unlikely(!table)) {
@@ -193,10 +191,9 @@ int cpufreq_frequency_table_get_index(struct cpufreq_policy *policy,
return -ENOENT;
}
- for (i = 0; table[i].frequency != CPUFREQ_TABLE_END; i++) {
- if (table[i].frequency == freq)
- return i;
- }
+ cpufreq_for_each_valid_entry(pos, table)
+ if (pos->frequency == freq)
+ return pos - table;
return -EINVAL;
}
@@ -208,16 +205,13 @@ EXPORT_SYMBOL_GPL(cpufreq_frequency_table_get_index);
static ssize_t show_available_freqs(struct cpufreq_policy *policy, char *buf,
bool show_boost)
{
- unsigned int i = 0;
ssize_t count = 0;
- struct cpufreq_frequency_table *table = policy->freq_table;
+ struct cpufreq_frequency_table *pos, *table = policy->freq_table;
if (!table)
return -ENODEV;
- for (i = 0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
- if (table[i].frequency == CPUFREQ_ENTRY_INVALID)
- continue;
+ cpufreq_for_each_valid_entry(pos, table) {
/*
* show_boost = true and driver_data = BOOST freq
* display BOOST freqs
@@ -229,10 +223,10 @@ static ssize_t show_available_freqs(struct cpufreq_policy *policy, char *buf,
* show_boost = false and driver_data != BOOST freq
* display NON BOOST freqs
*/
- if (show_boost ^ (table[i].flags & CPUFREQ_BOOST_FREQ))
+ if (show_boost ^ (pos->flags & CPUFREQ_BOOST_FREQ))
continue;
- count += sprintf(&buf[count], "%d ", table[i].frequency);
+ count += sprintf(&buf[count], "%d ", pos->frequency);
}
count += sprintf(&buf[count], "\n");
diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index d00e5d1..5e12646 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -528,6 +528,7 @@ static int longhaul_get_ranges(void)
static void longhaul_setup_voltagescaling(void)
{
+ struct cpufreq_frequency_table *freq_pos;
union msr_longhaul longhaul;
struct mV_pos minvid, maxvid, vid;
unsigned int j, speed, pos, kHz_step, numvscales;
@@ -606,18 +607,16 @@ static void longhaul_setup_voltagescaling(void)
/* Calculate kHz for one voltage step */
kHz_step = (highest_speed - min_vid_speed) / numvscales;
- j = 0;
- while (longhaul_table[j].frequency != CPUFREQ_TABLE_END) {
- speed = longhaul_table[j].frequency;
+ cpufreq_for_each_entry(freq_pos, longhaul_table) {
+ speed = freq_pos->frequency;
if (speed > min_vid_speed)
pos = (speed - min_vid_speed) / kHz_step + minvid.pos;
else
pos = minvid.pos;
- longhaul_table[j].driver_data |= mV_vrm_table[pos] << 8;
+ freq_pos->driver_data |= mV_vrm_table[pos] << 8;
vid = vrm_mV_table[mV_vrm_table[pos]];
- printk(KERN_INFO PFX "f: %d kHz, index: %d, vid: %d mV\n",
- speed, j, vid.mV);
- j++;
+ printk(KERN_INFO PFX "f: %u kHz, index: %u, vid: %d mV\n",
+ speed, freq_pos - longhaul_table, vid.mV);
}
can_scale_voltage = 1;
diff --git a/drivers/cpufreq/pasemi-cpufreq.c b/drivers/cpufreq/pasemi-cpufreq.c
index 84c84b5..9a64492 100644
--- a/drivers/cpufreq/pasemi-cpufreq.c
+++ b/drivers/cpufreq/pasemi-cpufreq.c
@@ -136,9 +136,10 @@ void restore_astate(int cpu)
static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
+ struct cpufreq_frequency_table *pos;
const u32 *max_freqp;
u32 max_freq;
- int i, cur_astate;
+ int cur_astate;
struct resource res;
struct device_node *cpu, *dn;
int err = -ENODEV;
@@ -197,10 +198,9 @@ static int pas_cpufreq_cpu_init(struct cpufreq_policy *policy)
pr_debug("initializing frequency table\n");
/* initialize frequency table */
- for (i=0; pas_freqs[i].frequency!=CPUFREQ_TABLE_END; i++) {
- pas_freqs[i].frequency =
- get_astate_freq(pas_freqs[i].driver_data) * 100000;
- pr_debug("%d: %d\n", i, pas_freqs[i].frequency);
+ cpufreq_for_each_entry(pos, pas_freqs) {
+ pos->frequency = get_astate_freq(pos->driver_data) * 100000;
+ pr_debug("%lu: %d\n", pos - pas_freqs, pos->frequency);
}
cur_astate = get_cur_astate(policy->cpu);
diff --git a/drivers/cpufreq/powernow-k6.c b/drivers/cpufreq/powernow-k6.c
index 49f120e..a133236 100644
--- a/drivers/cpufreq/powernow-k6.c
+++ b/drivers/cpufreq/powernow-k6.c
@@ -159,6 +159,7 @@ static int powernow_k6_target(struct cpufreq_policy *policy,
static int powernow_k6_cpu_init(struct cpufreq_policy *policy)
{
+ struct cpufreq_frequency_table *pos;
unsigned int i, f;
unsigned khz;
@@ -176,12 +177,11 @@ static int powernow_k6_cpu_init(struct cpufreq_policy *policy)
}
}
if (param_max_multiplier) {
- for (i = 0; (clock_ratio[i].frequency != CPUFREQ_TABLE_END); i++) {
- if (clock_ratio[i].driver_data == param_max_multiplier) {
+ cpufreq_for_each_entry(pos, clock_ratio)
+ if (pos->driver_data == param_max_multiplier) {
max_multiplier = param_max_multiplier;
goto have_max_multiplier;
}
- }
printk(KERN_ERR "powernow-k6: invalid max_multiplier parameter, valid parameters 20, 30, 35, 40, 45, 50, 55, 60\n");
return -EINVAL;
}
@@ -209,12 +209,12 @@ have_busfreq:
param_busfreq = busfreq * 10;
/* table init */
- for (i = 0; (clock_ratio[i].frequency != CPUFREQ_TABLE_END); i++) {
- f = clock_ratio[i].driver_data;
+ cpufreq_for_each_entry(pos, clock_ratio) {
+ f = pos->driver_data;
if (f > max_multiplier)
- clock_ratio[i].frequency = CPUFREQ_ENTRY_INVALID;
+ pos->frequency = CPUFREQ_ENTRY_INVALID;
else
- clock_ratio[i].frequency = busfreq * f;
+ pos->frequency = busfreq * f;
}
/* cpuinfo and default policy values */
diff --git a/drivers/cpufreq/ppc_cbe_cpufreq.c b/drivers/cpufreq/ppc_cbe_cpufreq.c
index 5be8a48..b550d5c 100644
--- a/drivers/cpufreq/ppc_cbe_cpufreq.c
+++ b/drivers/cpufreq/ppc_cbe_cpufreq.c
@@ -67,9 +67,10 @@ static int set_pmode(unsigned int cpu, unsigned int slow_mode)
static int cbe_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
+ struct cpufreq_frequency_table *pos;
const u32 *max_freqp;
u32 max_freq;
- int i, cur_pmode;
+ int cur_pmode;
struct device_node *cpu;
cpu = of_get_cpu_node(policy->cpu, NULL);
@@ -102,9 +103,9 @@ static int cbe_cpufreq_cpu_init(struct cpufreq_policy *policy)
pr_debug("initializing frequency table\n");
/* initialize frequency table */
- for (i=0; cbe_freqs[i].frequency!=CPUFREQ_TABLE_END; i++) {
- cbe_freqs[i].frequency = max_freq / cbe_freqs[i].driver_data;
- pr_debug("%d: %d\n", i, cbe_freqs[i].frequency);
+ cpufreq_for_each_entry(pos, cbe_freqs) {
+ pos->frequency = max_freq / pos->driver_data;
+ pr_debug("%lu: %d\n", pos - cbe_freqs, pos->frequency);
}
/* if DEBUG is enabled set_pmode() measures the latency
diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
index 4626f90..2fd53ea 100644
--- a/drivers/cpufreq/s3c2416-cpufreq.c
+++ b/drivers/cpufreq/s3c2416-cpufreq.c
@@ -266,7 +266,7 @@ out:
static void __init s3c2416_cpufreq_cfg_regulator(struct s3c2416_data *s3c_freq)
{
int count, v, i, found;
- struct cpufreq_frequency_table *freq;
+ struct cpufreq_frequency_table *pos;
struct s3c2416_dvfs *dvfs;
count = regulator_count_voltages(s3c_freq->vddarm);
@@ -275,12 +275,11 @@ static void __init s3c2416_cpufreq_cfg_regulator(struct s3c2416_data *s3c_freq)
return;
}
- freq = s3c_freq->freq_table;
- while (count > 0 && freq->frequency != CPUFREQ_TABLE_END) {
- if (freq->frequency == CPUFREQ_ENTRY_INVALID)
- continue;
+ if (!count)
+ goto out;
- dvfs = &s3c2416_dvfs_table[freq->driver_data];
+ cpufreq_for_each_valid_entry(pos, s3c_freq->freq_table) {
+ dvfs = &s3c2416_dvfs_table[pos->driver_data];
found = 0;
/* Check only the min-voltage, more is always ok on S3C2416 */
@@ -292,13 +291,12 @@ static void __init s3c2416_cpufreq_cfg_regulator(struct s3c2416_data *s3c_freq)
if (!found) {
pr_debug("cpufreq: %dkHz unsupported by regulator\n",
- freq->frequency);
- freq->frequency = CPUFREQ_ENTRY_INVALID;
+ pos->frequency);
+ pos->frequency = CPUFREQ_ENTRY_INVALID;
}
-
- freq++;
}
+out:
/* Guessed */
s3c_freq->regulator_latency = 1 * 1000 * 1000;
}
@@ -338,7 +336,7 @@ static struct notifier_block s3c2416_cpufreq_reboot_notifier = {
static int __init s3c2416_cpufreq_driver_init(struct cpufreq_policy *policy)
{
struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
- struct cpufreq_frequency_table *freq;
+ struct cpufreq_frequency_table *pos;
struct clk *msysclk;
unsigned long rate;
int ret;
@@ -427,31 +425,27 @@ static int __init s3c2416_cpufreq_driver_init(struct cpufreq_policy *policy)
s3c_freq->regulator_latency = 0;
#endif
- freq = s3c_freq->freq_table;
- while (freq->frequency != CPUFREQ_TABLE_END) {
+ cpufreq_for_each_entry(pos, s3c_freq->freq_table) {
/* special handling for dvs mode */
- if (freq->driver_data == 0) {
+ if (pos->driver_data == 0) {
if (!s3c_freq->hclk) {
pr_debug("cpufreq: %dkHz unsupported as it would need unavailable dvs mode\n",
- freq->frequency);
- freq->frequency = CPUFREQ_ENTRY_INVALID;
+ pos->frequency);
+ pos->frequency = CPUFREQ_ENTRY_INVALID;
} else {
- freq++;
continue;
}
}
/* Check for frequencies we can generate */
rate = clk_round_rate(s3c_freq->armdiv,
- freq->frequency * 1000);
+ pos->frequency * 1000);
rate /= 1000;
- if (rate != freq->frequency) {
+ if (rate != pos->frequency) {
pr_debug("cpufreq: %dkHz unsupported by clock (clk_round_rate return %lu)\n",
- freq->frequency, rate);
- freq->frequency = CPUFREQ_ENTRY_INVALID;
+ pos->frequency, rate);
+ pos->frequency = CPUFREQ_ENTRY_INVALID;
}
-
- freq++;
}
/* Datasheet says PLL stabalisation time must be at least 300us,
diff --git a/drivers/cpufreq/s3c64xx-cpufreq.c b/drivers/cpufreq/s3c64xx-cpufreq.c
index ff7d3ec..176e84c 100644
--- a/drivers/cpufreq/s3c64xx-cpufreq.c
+++ b/drivers/cpufreq/s3c64xx-cpufreq.c
@@ -118,11 +118,10 @@ static void __init s3c64xx_cpufreq_config_regulator(void)
pr_err("Unable to check supported voltages\n");
}
- freq = s3c64xx_freq_table;
- while (count > 0 && freq->frequency != CPUFREQ_TABLE_END) {
- if (freq->frequency == CPUFREQ_ENTRY_INVALID)
- continue;
+ if (!count)
+ goto out;
+ cpufreq_for_each_valid_entry(freq, s3c64xx_freq_table) {
dvfs = &s3c64xx_dvfs_table[freq->driver_data];
found = 0;
@@ -137,10 +136,9 @@ static void __init s3c64xx_cpufreq_config_regulator(void)
freq->frequency);
freq->frequency = CPUFREQ_ENTRY_INVALID;
}
-
- freq++;
}
+out:
/* Guess based on having to do an I2C/SPI write; in future we
* will be able to query the regulator performance here. */
regulator_latency = 1 * 1000 * 1000;
@@ -179,8 +177,7 @@ static int s3c64xx_cpufreq_driver_init(struct cpufreq_policy *policy)
}
#endif
- freq = s3c64xx_freq_table;
- while (freq->frequency != CPUFREQ_TABLE_END) {
+ cpufreq_for_each_entry(freq, s3c64xx_freq_table) {
unsigned long r;
/* Check for frequencies we can generate */
@@ -196,8 +193,6 @@ static int s3c64xx_cpufreq_driver_init(struct cpufreq_policy *policy)
* frequency is the maximum we can support. */
if (!vddarm && freq->frequency > clk_get_rate(policy->clk) / 1000)
freq->frequency = CPUFREQ_ENTRY_INVALID;
-
- freq++;
}
/* Datasheet says PLL stabalisation time (if we were to use
--
1.9.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox