RE: [PATCH v2] powerpc: Update compilation flags with core specific options
The assembler option is redundant if the -mcpu= flag is set.
The patch fixes the kernel compilation problem for e5500/e6500
when using gcc option -mcpu=e5500/e6500.
Signed-off-by: Catalin Udma catalin.u...@freescale.com
---
changes for v2:
- update also KBUILD_AFLAGS with -mcpu and -msoft-float flags
arch/powerpc/Makefile | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
Is the assembler redundant for older toolchains?
- k
[CU] gcc defines the mapping from -mcpu to assembler options in file
gcc/config/rs6000/rs6000.h, like this:
%{mcpu=8540: -me500} \
%{mcpu=8548: -me500} \
%{mcpu=e300c2: -me300} \
%{mcpu=e300c3: -me300} \
%{mcpu=e500mc: -me500mc} \
%{mcpu=e500mc64: -me500mc64} \
%{mcpu=e5500: -me5500} \
%{mcpu=e6500: -me6500} \
I have checked this mapping from gcc 3.3 (where 8540 entry was added) to
3.4, 4.3, 4.4 and 4.8.1...The -Wa option is redundant for all these
older toolchains.
Catalin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
Hi, On 07/29/2013 10:58 AM, Vaidyanathan Srinivasan wrote: * Preeti U Murthy pre...@linux.vnet.ibm.com [2013-07-27 13:20:37]: Hi Ben, On 07/27/2013 12:00 PM, Benjamin Herrenschmidt wrote: On Fri, 2013-07-26 at 08:09 +0530, Preeti U Murthy wrote: *The lapic of a broadcast CPU is active always*. Say CPUX, wants the broadcast CPU to wake it up at timeX. Since we cannot program the lapic of a remote CPU, CPUX will need to send an IPI to the broadcast CPU, asking it to program its lapic to fire at timeX so as to wake up CPUX. *With multiple CPUs the overhead of sending IPI, could result in performance bottlenecks and may not scale well.* Hence the workaround is that the broadcast CPU on each of its timer interrupt checks if any of the next timer event of a CPU in deep idle state has expired, which can very well be found from dev-next_event of that CPU. For example the timeX that has been mentioned above has expired. If so the broadcast handler is called to send an IPI to the idling CPU to wake it up. *If the broadcast CPU, is in tickless idle, its timer interrupt could be many ticks away. It could miss waking up a CPU in deep idle*, if its wakeup is much before this timer interrupt of the broadcast CPU. But without tickless idle, atleast at each period we are assured of a timer interrupt. At which time broadcast handling is done as stated in the previous paragraph and we will not miss wakeup of CPUs in deep idle states. But that means a great loss of power saving on the broadcast CPU when the machine is basically completely idle. We might be able to come up with some thing better. (Note : I do no know the timer offload code if it exists already, I'm describing how things could happen out of the blue without any knowledge of pre-existing framework here) We can know when the broadcast CPU expects to wake up next. When a CPU goes to a deep sleep state, it can then - Indicate to the broadcast CPU when it intends to be woken up by queuing itself into an ordered queue (ordered by target wakeup time). (OPTIMISATION: Play with the locality of that: have one queue (and one broadcast CPU) per chip or per node instead of a global one to limit cache bouncing). - Check if that happens before the broadcast CPU intended wake time (we need statistics to see how often that happens), and in that case send an IPI to wake it up now. When the broadcast CPU goes to sleep, it limits its sleep time to the min of it's intended sleep time and the new sleeper time. (OPTIMISATION: Dynamically chose a broadcast CPU based on closest expiry ?) - We can probably limit spurrious wakeups a *LOT* by aligning that target time to a global jiffy boundary, meaning that several CPUs going to idle are likely to be choosing the same. Or maybe better, an adaptative alignment by essentially getting more coarse grained as we go further in the future - When the broadcast CPU goes to sleep, it can play the same game of alignment. I don't like the concept of a dedicated broadcast CPU however. I'd rather have a general queue (or per node) of sleepers needing a wakeup and more/less dynamically pick a waker to be the last man standing, but it does make things a bit more tricky with tickless scheduler (non-idle). Still, I wonder if we could just have some algorithm to actually pick wakers more dynamically based on who ever has the closest next wakeup planned, that sort of thing. A fixed broadcaster will create an imbalance in power/thermal within the chip in addition to needing to be moved around on hotplug etc... Thank you for having listed out the above suggestions. Below, I will bring out some ideas about how the concerns that you have raised can be addressed in the increasing order of priority. - To begin with, I think we can have the following model to have the responsibility of the broadcast CPU float around certain CPUs. i.e. Not have a dedicated broadcast CPU. I will refer to the broadcast CPU as the bc_cpu henceforth for convenience. 1. The first CPU that intends to enter deep sleep state will be the bc_cpu. 2. Every other CPU that intends to enter deep idle state will enter themselves into a mask, say the bc_mask, which is already being done today, after they check that a bc_cpu has been assigned. 3. The bc_cpu should not enter tickless idle, until step 5a holds true. 4. So on every timer interrupt, which is at-least every period, it checks the bc_mask to see if any CPUs need to be woken up. 5. The bc cpu should not enter tickless idle *until* it is de-nominated as the bc_cpu. The de-nomination occurs when: a. In one of its timer interrupts, it does broadcast handling to find out that there are no CPUs to be woken up. 6. So if 5a holds, then there is no bc_cpu anymore until a CPU decides to enter deep idle state again, in which case steps 1 to 5 repeat. - We could optimize this further, to allow the bc_cpu to enter tickless
[PATCH v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: Hongbo Zhang hongbo.zh...@freescale.com Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches. Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. V6-V7 changes: - only remove unnecessary CHIP-dma explanations in [1/3] V5-V6 changes: - minor updates of descriptions in binding document and Kconfig - remove [4/4], that should be another patch in future V4-V5 changes: - update description in the dt binding document, to make it more resonable - add new patch [4/4] to eliminate a compiling warning which already exists for a long time V3-V4 changes: - introduce new patch [1/3] to revise the legacy dma binding document - and then add new paragraph to describe new dt node binding in [2/3] - rebase to latest kernel v3.11-rc1 V2-V3 changes: - edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt - edit text string in Kconfig and the driver files, using elo series to mention all the current elo* V1-V2 changes: - removed the codes handling the register dgsr1, since it isn't used currently - renamed the DMA DT compatible to fsl,elo3-dma - renamed the new dts files to elo3-dma-n.dtsi Hongbo Zhang (3): DMA: Freescale: revise device tree binding document DMA: Freescale: Add new 8-channel DMA engine device tree nodes DMA: Freescale: update driver to support 8-channel DMA engine .../devicetree/bindings/powerpc/fsl/dma.txt| 114 +++- arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- drivers/dma/Kconfig|9 +- drivers/dma/fsldma.c |9 +- drivers/dma/fsldma.h |2 +- 8 files changed, 264 insertions(+), 40 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 1/3] DMA: Freescale: revise device tree binding document
From: Hongbo Zhang hongbo.zh...@freescale.com This patch updates the discription of each type of DMA controller and its channels, it is preparation for adding another new DMA controller binding, it also fixes some defects of indent for text alignment at the same time. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 48 1 file changed, 20 insertions(+), 28 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bc..6e9384b 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -1,33 +1,29 @@ -* Freescale 83xx DMA Controller +* Freescale DMA Controllers -Freescale PowerPC 83xx have on chip general purpose DMA controllers. +** Freescale Elo DMA Controller + This is a little-endian DMA controller, used in Freescale mpc83xx series + chips such as mpc8315, mpc8349, mpc8379 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma, where CHIP is the processor -(mpc8349, mpc8360, etc.) and the second is -fsl,elo-dma +- compatible: must include fsl,elo-dma - reg : registers mapping for DMA general status reg -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - cell-index: controller index. 0 for controller @ 0x8100 - interrupts: interrupt mapping for DMA IRQ - interrupt-parent : optional, if needed for interrupt mapping - - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma-channel, where CHIP is the processor -(mpc8349, mpc8350, etc.) and the second is -fsl,elo-dma-channel. However, see note below. +- compatible: must include fsl,elo-dma-channel + However, see note below. - reg : registers mapping for channel - cell-index: dma channel index starts at 0. Optional properties: - interrupts: interrupt mapping for DMA channel IRQ - (on 83xx this is expected to be identical to - the interrupts property of the parent node) + (on 83xx this is expected to be identical to + the interrupts property of the parent node) - interrupt-parent : optional, if needed for interrupt mapping Example: @@ -70,27 +66,23 @@ Example: }; }; -* Freescale 85xx/86xx DMA Controller - -Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers. +** Freescale EloPlus DMA Controller + This is DMA controller with extended addresses and chaining, mainly used in + Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as mpc8540, mpc8641 + p4080, bsc9131 etc. Required properties: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma, where CHIP is the processor -(mpc8540, mpc8540, etc.) and the second is -fsl,eloplus-dma +- compatible: must include fsl,eloplus-dma - reg : registers mapping for DMA general status reg - cell-index: controller index. 0 for controller @ 0x21000, 1 for controller @ 0xc000 -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- ranges: describes the mapping between the address space of the + DMA channels and the address space of the DMA controller - DMA channel nodes: -- compatible: compatible list, contains 2 entries, first is -fsl,CHIP-dma-channel, where CHIP is the processor -(mpc8540, mpc8560, etc.) and the second is -fsl,eloplus-dma-channel. However, see note below. +- compatible: must include fsl,eloplus-dma-channel + However, see note below. - cell-index: dma channel index starts at 0. - reg : registers mapping for channel - interrupts: interrupt mapping for DMA channel IRQ -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
From: Hongbo Zhang hongbo.zh...@freescale.com
Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds
the device tree nodes for them.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 66
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 232 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 6e9384b..2e66c3d 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -126,6 +126,72 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ This is EloPlus controller with 8 channels, used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : registers mapping for DMA general status reg
+- ranges: describes the mapping between the address space of the
+ DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+- compatible: must include fsl,eloplus-dma-channel
+- reg : registers mapping for channel
+- interrupts: interrupt mapping for DMA channel IRQ
+- interrupt-parent : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,elo3-dma;
+ reg = 0x100300 0x4 0x100600 0x4;
+ ranges = 0x0 0x100100 0x500;
+ dma-channel@0 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x0 0x80;
+ interrupts = 28 2 0 0;
+ };
+ dma-channel@80 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x80 0x80;
+ interrupts = 29 2 0 0;
+ };
+ dma-channel@100 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x100 0x80;
+ interrupts = 30 2 0 0;
+ };
+ dma-channel@180 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x180 0x80;
+ interrupts = 31 2 0 0;
+ };
+ dma-channel@300 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x300 0x80;
+ interrupts = 76 2 0 0;
+ };
+ dma-channel@380 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x380 0x80;
+ interrupts = 77 2 0 0;
+ };
+ dma-channel@400 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x400 0x80;
+ interrupts = 78 2 0 0;
+ };
+ dma-channel@480 {
+ compatible = fsl,eloplus-dma-channel;
+ reg = 0x480 0x80;
+ interrupts = 79 2 0 0;
+ };
+};
+
Note on DMA channel compatible properties: The compatible property must say
fsl,elo-dma-channel or fsl,eloplus-dma-channel to be used by the Elo DMA
driver (fsldma). Any DMA channel used by fsldma cannot be used by another
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..ea53ea1 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -223,13 +223,13 @@
reg = 0xe2000 0x1000;
};
-/include/ qoriq-dma-0.dtsi
+/include/ elo3-dma-0.dtsi
dma@100300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x580; /* DMA1LIODNR */
};
-/include/ qoriq-dma-1.dtsi
+/include/ elo3-dma-1.dtsi
dma@101300 {
fsl,iommu-parent = pamu0;
fsl,liodn-reg = guts 0x584; /* DMA2LIODNR */
diff --git a/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
new file mode 100644
index 000..69a3277
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
@@ -0,0 +1,81 @@
+/*
+ * QorIQ DMA device tree stub [ controller @ offset 0x10 ]
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of
[PATCH v7 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: Hongbo Zhang hongbo.zh...@freescale.com
This patch adds support to 8-channel DMA engine, thus the driver works for both
the new 8-channel and the legacy 4-channel DMA engines.
Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com
---
drivers/dma/Kconfig |9 +
drivers/dma/fsldma.c |9 ++---
drivers/dma/fsldma.h |2 +-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6825957..3979c65 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -89,14 +89,15 @@ config AT_HDMAC
Support the Atmel AHB DMA controller.
config FSL_DMA
- tristate Freescale Elo and Elo Plus DMA support
+ tristate Freescale Elo series DMA support
depends on FSL_SOC
select DMA_ENGINE
select ASYNC_TX_ENABLE_CHANNEL_SWITCH
---help---
- Enable support for the Freescale Elo and Elo Plus DMA controllers.
- The Elo is the DMA controller on some 82xx and 83xx parts, and the
- Elo Plus is the DMA controller on 85xx and 86xx parts.
+ Enable support for the Freescale Elo series DMA controllers.
+ The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
+ EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
+ some Txxx and Bxxx parts.
config MPC512X_DMA
tristate Freescale MPC512x built-in DMA engine support
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 49e8fbd..16a9a48 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
WARN_ON(fdev-feature != chan-feature);
chan-dev = fdev-dev;
- chan-id = ((res.start - 0x100) 0xfff) 7;
+ chan-id = (res.start 0xfff) 0x300 ?
+ ((res.start - 0x100) 0xfff) 7 :
+ ((res.start - 0x200) 0xfff) 7;
if (chan-id = FSL_DMA_MAX_CHANS_PER_DEVICE) {
dev_err(fdev-dev, too many channels for device\n);
err = -EINVAL;
@@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
}
static const struct of_device_id fsldma_of_ids[] = {
+ { .compatible = fsl,elo3-dma, },
{ .compatible = fsl,eloplus-dma, },
{ .compatible = fsl,elo-dma, },
{}
@@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
static __init int fsldma_init(void)
{
- pr_info(Freescale Elo / Elo Plus DMA driver\n);
+ pr_info(Freescale Elo series DMA driver\n);
return platform_driver_register(fsldma_of_driver);
}
@@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
subsys_initcall(fsldma_init);
module_exit(fsldma_exit);
-MODULE_DESCRIPTION(Freescale Elo / Elo Plus DMA driver);
+MODULE_DESCRIPTION(Freescale Elo series DMA driver);
MODULE_LICENSE(GPL);
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index f5c3879..1ffc244 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -112,7 +112,7 @@ struct fsldma_chan_regs {
};
struct fsldma_chan;
-#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
+#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
struct fsldma_device {
void __iomem *regs; /* DGSR register base */
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine
On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches. The dma relates changes look okay to me. I need someone to review and ACK the DT bindings. ~Vinod Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. V6-V7 changes: - only remove unnecessary CHIP-dma explanations in [1/3] V5-V6 changes: - minor updates of descriptions in binding document and Kconfig - remove [4/4], that should be another patch in future V4-V5 changes: - update description in the dt binding document, to make it more resonable - add new patch [4/4] to eliminate a compiling warning which already exists for a long time V3-V4 changes: - introduce new patch [1/3] to revise the legacy dma binding document - and then add new paragraph to describe new dt node binding in [2/3] - rebase to latest kernel v3.11-rc1 V2-V3 changes: - edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt - edit text string in Kconfig and the driver files, using elo series to mention all the current elo* V1-V2 changes: - removed the codes handling the register dgsr1, since it isn't used currently - renamed the DMA DT compatible to fsl,elo3-dma - renamed the new dts files to elo3-dma-n.dtsi Hongbo Zhang (3): DMA: Freescale: revise device tree binding document DMA: Freescale: Add new 8-channel DMA engine device tree nodes DMA: Freescale: update driver to support 8-channel DMA engine .../devicetree/bindings/powerpc/fsl/dma.txt| 114 +++- arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- drivers/dma/Kconfig|9 +- drivers/dma/fsldma.c |9 +- drivers/dma/fsldma.h |2 +- 8 files changed, 264 insertions(+), 40 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi -- 1.7.9.5 -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
It's convenient to have ethernet mac addresses use
ETH_ALEN to be able to grep for them a bit easier and
also to ensure that the addresses are __aligned(2).
Add #include linux/if_ether.h as necessary.
Signed-off-by: Joe Perches j...@perches.com
---
include/acpi/actbl2.h | 4 ++-
include/linux/dm9000.h | 4 ++-
include/linux/fs_enet_pd.h | 3 ++-
include/linux/ieee80211.h | 59
+
include/linux/mlx4/device.h | 11
include/linux/mlx4/qp.h | 5 ++--
include/linux/mv643xx_eth.h | 3 ++-
include/linux/sh_eth.h | 3 ++-
include/linux/smsc911x.h| 3 ++-
include/linux/uwb/spec.h| 5 ++--
include/media/tveeprom.h| 4 ++-
include/net/irda/irlan_common.h | 3 ++-
12 files changed, 61 insertions(+), 46 deletions(-)
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
index ffaac0e..3f0f11c 100644
--- a/include/acpi/actbl2.h
+++ b/include/acpi/actbl2.h
@@ -44,6 +44,8 @@
#ifndef __ACTBL2_H__
#define __ACTBL2_H__
+#include linux/if_ether.h
+
/***
*
* Additional ACPI Tables (2)
@@ -605,7 +607,7 @@ struct acpi_ibft_nic {
u8 secondary_dns[16];
u8 dhcp[16];
u16 vlan;
- u8 mac_address[6];
+ u8 mac_address[ETH_ALEN];
u16 pci_address;
u16 name_length;
u16 name_offset;
Please don't touch this file.
It comes from a code base outside of the kernel and should be kept in sync with
the upstream.
Thanks,
Rafael
diff --git a/include/linux/dm9000.h b/include/linux/dm9000.h
index 96e8769..841925f 100644
--- a/include/linux/dm9000.h
+++ b/include/linux/dm9000.h
@@ -14,6 +14,8 @@
#ifndef __DM9000_PLATFORM_DATA
#define __DM9000_PLATFORM_DATA __FILE__
+#include linux/if_ether.h
+
/* IO control flags */
#define DM9000_PLATF_8BITONLY(0x0001)
@@ -27,7 +29,7 @@
struct dm9000_plat_data {
unsigned intflags;
- unsigned char dev_addr[6];
+ unsigned char dev_addr[ETH_ALEN];
/* allow replacement IO routines */
diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 51b7934..343d82a 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -18,6 +18,7 @@
#include linux/string.h
#include linux/of_mdio.h
+#include linux/if_ether.h
#include asm/types.h
#define FS_ENET_NAME fs_enet
@@ -135,7 +136,7 @@ struct fs_platform_info {
const struct fs_mii_bus_info *bus_info;
int rx_ring, tx_ring; /* number of buffers on rx */
- __u8 macaddr[6];/* mac address */
+ __u8 macaddr[ETH_ALEN]; /* mac address */
int rx_copybreak; /* limit we copy small frames */
int use_napi; /* use NAPI*/
int napi_weight;/* NAPI weight */
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index b0dc87a..4e101af 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -16,6 +16,7 @@
#define LINUX_IEEE80211_H
#include linux/types.h
+#include linux/if_ether.h
#include asm/byteorder.h
/*
@@ -209,28 +210,28 @@ static inline u16 ieee80211_sn_sub(u16 sn1, u16 sn2)
struct ieee80211_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
- u8 addr4[6];
+ u8 addr4[ETH_ALEN];
} __packed __aligned(2);
struct ieee80211_hdr_3addr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
} __packed __aligned(2);
struct ieee80211_qos_hdr {
__le16 frame_control;
__le16 duration_id;
- u8 addr1[6];
- u8 addr2[6];
- u8 addr3[6];
+ u8 addr1[ETH_ALEN];
+ u8 addr2[ETH_ALEN];
+ u8 addr3[ETH_ALEN];
__le16 seq_ctrl;
__le16 qos_ctrl;
} __packed __aligned(2);
@@ -608,8 +609,8 @@ struct ieee80211s_hdr {
u8 flags;
u8 ttl;
__le32 seqnum;
- u8 eaddr1[6];
- u8 eaddr2[6];
+ u8 eaddr1[ETH_ALEN];
+ u8 eaddr2[ETH_ALEN];
} __packed __aligned(2);
/* Mesh flags */
@@ -758,7 +759,7 @@ struct ieee80211_rann_ie {
u8 rann_flags;
u8 rann_hopcount;
u8 rann_ttl;
- u8 rann_addr[6];
+ u8 rann_addr[ETH_ALEN];
__le32 rann_seq;
__le32 rann_interval;
__le32 rann_metric;
@@ -802,9 +803,9 @@ enum ieee80211_vht_opmode_bits {
struct ieee80211_mgmt {
__le16 frame_control;
__le16 duration;
- u8
Re: [PATCH 2/3] cpuidle/powernv: Enable idle powernv cpu to call into the cpuidle framework.
On 07/27/2013 10:59 AM, Daniel Lezcano wrote:
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch enables idle powernv cpu to hook on to the cpuidle
framework, if available, else call on to default idle platform
code.
Why do you need to do that ?
Hi Daniel,
Well, this is needed in case when one does not compile with CPU_IDLE
config option.
When CPUIDLE is not configured, idle cpus are needed to be running some
sort of default idle code or loop ( in the worst case) if cpuidle driver
is not registered or if one decides not to have that config enabled.
Regards,
Deepthi
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/setup.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 84438af..97d0951 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -25,6 +25,7 @@
#include linux/of.h
#include linux/interrupt.h
#include linux/bug.h
+#include linux/cpuidle.h
#include asm/machdep.h
#include asm/firmware.h
@@ -196,6 +197,15 @@ static int __init pnv_probe(void)
return 1;
}
+void powernv_idle(void)
+{
+/* Hook to cpuidle framework if available, else
+ * call on default platform idle code
+ */
+if (cpuidle_idle_call())
+power7_idle();
+}
+
define_machine(powernv) {
.name = PowerNV,
.probe = pnv_probe,
@@ -205,7 +215,7 @@ define_machine(powernv) {
.show_cpuinfo = pnv_show_cpuinfo,
.progress = pnv_progress,
.machine_shutdown = pnv_shutdown,
-.power_save = power7_idle,
+.power_save = powernv_idle,
.calibrate_decr = generic_calibrate_decr,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
Hi Daniel,
On 07/27/2013 10:57 AM, Daniel Lezcano wrote:
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch implements a back-end cpuidle driver for
powernv calling power7_nap and snooze idle states.
This can be extended by adding more idle states
in the future to the existing framework.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/Kconfig |9 +
arch/powerpc/platforms/powernv/Makefile |1
arch/powerpc/platforms/powernv/processor_idle.c | 239
+++
3 files changed, 249 insertions(+)
create mode 100644 arch/powerpc/platforms/powernv/processor_idle.c
diff --git a/arch/powerpc/platforms/powernv/Kconfig
b/arch/powerpc/platforms/powernv/Kconfig
index c24684c..ace2d22 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -20,3 +20,12 @@ config PPC_POWERNV_RTAS
default y
select PPC_ICS_RTAS
select PPC_RTAS
+
+config POWERNV_IDLE
+bool CPUIdle driver for powernv platform
+depends on CPU_IDLE
+depends on PPC_POWERNV
+default y
+help
+Select this option to enable processor idle state management
+through cpuidle subsystem.
diff --git a/arch/powerpc/platforms/powernv/Makefile
b/arch/powerpc/platforms/powernv/Makefile
index 7fe5951..c0e44eb 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -4,3 +4,4 @@ obj-y+= opal-rtc.o opal-nvram.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
obj-$(CONFIG_EEH) += eeh-ioda.o eeh-powernv.o
+obj-$(CONFIG_POWERNV_IDLE) += processor_idle.o
diff --git a/arch/powerpc/platforms/powernv/processor_idle.c
b/arch/powerpc/platforms/powernv/processor_idle.c
new file mode 100644
index 000..f43ad91a
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/processor_idle.c
@@ -0,0 +1,239 @@
+/*
+ * processor_idle - idle state cpuidle driver.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/moduleparam.h
+#include linux/cpuidle.h
+#include linux/cpu.h
+#include linux/notifier.h
+
+#include asm/machdep.h
+#include asm/runlatch.h
+
+struct cpuidle_driver powernv_idle_driver = {
+.name = powernv_idle,
+.owner =THIS_MODULE,
+};
+
+#define MAX_IDLE_STATE_COUNT2
+
+static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
+static struct cpuidle_device __percpu *powernv_cpuidle_devices;
+static struct cpuidle_state *cpuidle_state_table;
+
+static int snooze_loop(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+int cpu = dev-cpu;
+
+local_irq_enable();
+set_thread_flag(TIF_POLLING_NRFLAG);
+
+while ((!need_resched()) cpu_online(cpu)) {
+ppc64_runlatch_off();
+HMT_very_low();
+}
Why are you using the cpu_online test here ?
Snooze state is an idle state where cpu executes an infinite loop by
reducing the priority of the thread and the idle cpu can come out of it
only if need_resched is set or in case the cpu is offlined. In order to
continue executing this loop to remain in this idle state, we need the
check just to be safe.
+
+HMT_medium();
+clear_thread_flag(TIF_POLLING_NRFLAG);
+smp_mb();
+return index;
+}
+
+
+static int nap_loop(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ppc64_runlatch_off();
+power7_idle();
+return index;
+}
+
+/*
+ * States for dedicated partition case.
+ */
+static struct cpuidle_state powernv_states[MAX_IDLE_STATE_COUNT] = {
+{ /* Snooze */
+.name = snooze,
+.desc = snooze,
+.flags = CPUIDLE_FLAG_TIME_VALID,
+.exit_latency = 0,
+.target_residency = 0,
+.enter = snooze_loop },
+ { /* Nap */
+.name = Nap,
+.desc = Nap,
+.flags = CPUIDLE_FLAG_TIME_VALID,
+.exit_latency = 10,
+.target_residency = 100,
+.enter = nap_loop },
+};
+
+static int powernv_cpuidle_add_cpu_notifier(struct notifier_block *n,
+unsigned long action, void *hcpu)
+{
+int hotcpu = (unsigned long)hcpu;
+struct cpuidle_device *dev =
+per_cpu_ptr(powernv_cpuidle_devices, hotcpu);
+
+if (dev cpuidle_get_driver()) {
+switch (action) {
+case CPU_ONLINE:
+case CPU_ONLINE_FROZEN:
+cpuidle_pause_and_lock();
+cpuidle_enable_device(dev);
+cpuidle_resume_and_unlock();
+break;
+
+case CPU_DEAD:
+case CPU_DEAD_FROZEN:
+
Re: [PATCH 2/3] cpuidle/powernv: Enable idle powernv cpu to call into the cpuidle framework.
On 07/29/2013 04:27 PM, Deepthi Dharwar wrote:
On 07/27/2013 10:59 AM, Daniel Lezcano wrote:
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch enables idle powernv cpu to hook on to the cpuidle
framework, if available, else call on to default idle platform
code.
Why do you need to do that ?
Hi Daniel,
Well, this is needed in case when one does not compile with CPU_IDLE
config option.
When CPUIDLE is not configured, idle cpus are needed to be running some
sort of default idle code or loop ( in the worst case) if cpuidle driver
is not registered or if one decides not to have that config enabled.
Hi Deepthi,
ok may be there is some difference with the other platform but the
arch_cpu_idle function defined in the other archs do:
void arch_cpu_idle(void)
{
if (cpuidle_idle_call())
x86_idle();
else
local_irq_enable();
}
or
void arch_cpu_idle(void)
{
if (cpuidle_idle_call())
default_idle();
}
When the cpuidle driver is not compiled or not loaded, cpuidle_idle_call
fails, falling back to the default idle function.
The arch_cpu_idle function is called from the generic code in
kernel/cpu/idle.c.
Is there a particular reason to do it in a different way ?
Thanks
-- Daniel
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/setup.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 84438af..97d0951 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -25,6 +25,7 @@
#include linux/of.h
#include linux/interrupt.h
#include linux/bug.h
+#include linux/cpuidle.h
#include asm/machdep.h
#include asm/firmware.h
@@ -196,6 +197,15 @@ static int __init pnv_probe(void)
return 1;
}
+void powernv_idle(void)
+{
+ /* Hook to cpuidle framework if available, else
+* call on default platform idle code
+*/
+ if (cpuidle_idle_call())
+ power7_idle();
+}
+
define_machine(powernv) {
.name = PowerNV,
.probe = pnv_probe,
@@ -205,7 +215,7 @@ define_machine(powernv) {
.show_cpuinfo = pnv_show_cpuinfo,
.progress = pnv_progress,
.machine_shutdown = pnv_shutdown,
- .power_save = power7_idle,
+ .power_save = powernv_idle,
.calibrate_decr = generic_calibrate_decr,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
On 07/29/2013 04:39 PM, Deepthi Dharwar wrote:
Hi Daniel,
On 07/27/2013 10:57 AM, Daniel Lezcano wrote:
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch implements a back-end cpuidle driver for
powernv calling power7_nap and snooze idle states.
This can be extended by adding more idle states
in the future to the existing framework.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
[ ... ]
+static int snooze_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int cpu = dev-cpu;
+
+ local_irq_enable();
+ set_thread_flag(TIF_POLLING_NRFLAG);
+
+ while ((!need_resched()) cpu_online(cpu)) {
+ ppc64_runlatch_off();
+ HMT_very_low();
+ }
Why are you using the cpu_online test here ?
Snooze state is an idle state where cpu executes an infinite loop by
reducing the priority of the thread and the idle cpu can come out of it
only if need_resched is set or in case the cpu is offlined. In order to
continue executing this loop to remain in this idle state, we need the
check just to be safe.
Yes, but if the cpu is offline you are no longer executing this code, no ?
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 3/3] powerpc/85xx: Add C293PCIE board support
On 07/28/2013 09:20:11 PM, Liu Po-B43644 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Saturday, July 27, 2013 5:59 AM
To: Liu Po-B43644
Cc: linuxppc-...@ozlabs.org; ga...@kernel.crashing.org; Fleming
Andy-
AFLEMING; Hu Mingkai-B21284; Liu Po-B43644
Subject: Re: [PATCH v2 3/3] powerpc/85xx: Add C293PCIE board
support
On 07/25/2013 09:41:19 PM, Po Liu wrote:
+partition@190 {
+/* 7MB for User Area */
+reg = 0x0190 0x0070;
+label = NAND User area;
+};
+
+partition@200 {
+/* 96MB for Root File System */
+reg = 0x0200 0x0600;
+label = NAND Root File System;
+};
+
+partition@800 {
+/* 3968MB for Others */
+reg = 0x0800 0xF800;
+label = NAND Others;
+};
Again, what is the difference between user area and others?
I'm not
even sure why it needs to be separate from root file system, but
at
least the root filesystem should be larger given the size of the
overall
flash.
Do you mean just merge up four partition into one RFS? Or merge up
four partition into RFS and User area is better?
If you don't have a reason for separating them, then probably yes,
merge them all into one. If you do keep RFS and user area separate,
then user area should be the larger of the two, but the RFS should be
more than just 96 MiB.
+partition@58 {
+/* 10.5MB for Compressed RFS
Image */
+reg = 0x0058 0x00a8;
+label = SPI Flash Compressed
RFSImage;
+};
Space before Image. Why specifiy that it's compressed, versus
some
other filesystem type?
Remove all the compressed comments when express the RFS partition?
Yes.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
On Mon, 2013-07-29 at 13:59 +0200, Rafael J. Wysocki wrote:
On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
It's convenient to have ethernet mac addresses use
ETH_ALEN to be able to grep for them a bit easier and
also to ensure that the addresses are __aligned(2).
[]
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
[]
@@ -44,6 +44,8 @@
[]
+#include linux/if_ether.h
+
[]
@@ -605,7 +607,7 @@ struct acpi_ibft_nic {
[]
- u8 mac_address[6];
+ u8 mac_address[ETH_ALEN];
Please don't touch this file.
It comes from a code base outside of the kernel and should be kept in sync
with
the upstream.
Which files in include/acpi have this characteristic?
Perhaps an include/acpi/README is appropriate.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] include: Convert ethernet mac address declarations to use ETH_ALEN
On Monday, July 29, 2013 12:34:24 PM Joe Perches wrote:
On Mon, 2013-07-29 at 13:59 +0200, Rafael J. Wysocki wrote:
On Sunday, July 28, 2013 10:29:04 PM Joe Perches wrote:
It's convenient to have ethernet mac addresses use
ETH_ALEN to be able to grep for them a bit easier and
also to ensure that the addresses are __aligned(2).
[]
diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
[]
@@ -44,6 +44,8 @@
[]
+#include linux/if_ether.h
+
[]
@@ -605,7 +607,7 @@ struct acpi_ibft_nic {
[]
- u8 mac_address[6];
+ u8 mac_address[ETH_ALEN];
Please don't touch this file.
It comes from a code base outside of the kernel and should be kept in sync
with
the upstream.
Which files in include/acpi have this characteristic?
Generally, all whose names start with ac except for acpi_bus.h,
acpi_drivers.h and acpi_numa.h.
Perhaps an include/acpi/README is appropriate.
Yes, we can add one.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mmc:core: parse voltage from device-tree
On 07/28/2013 09:56:33 PM, Haijun Zhang wrote: Add function to support get voltage from device-tree. If there are voltage-range specified in device-tree node, this function will parse it and return the avail voltage mask. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- drivers/mmc/core/core.c | 48 include/linux/mmc/core.h | 1 + 2 files changed, 49 insertions(+) Move the code rather than copying it. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/3] DMA: Freescale: revise device tree binding document
On 07/29/2013 05:49:02 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com This patch updates the discription of each type of DMA controller and its channels, it is preparation for adding another new DMA controller binding, it also fixes some defects of indent for text alignment at the same time. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com ACK, but next time please do the whitespace fixes as a separate patch so that it's easier to see what's actually changing. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 07/29/2013 05:49:03 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds the device tree nodes for them. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 66 arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- 5 files changed, 232 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi ACK -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: visible memory seems wrong in kexec crash dump kernel
On 07/13/2013 01:30:50 AM, Chris Friesen wrote: On 07/12/2013 04:59 PM, Chris Friesen wrote: On 07/12/2013 03:08 PM, Chris Friesen wrote: I turned on the instrumentation in early_init_dt_scan_memory() and got the following when jumping to the capture kernel: memory scan node memory, reg size 16, data: 0 0 2 0, - 0 , 2 That 0x2 matches the fact that I'm seeing 8GB of memory available in the recovery kernel. If I boot the original kernel with crashkernel=224M@32M, should I expect that only 224MB is marked as linux,usable-memory in the recovery kernel? I started looking at the kexec side of things, and I noticed something a bit odd. In most places dealing with the device tree in kexec it accepts either memory or memory@ for the memory node name. In add_usable_mem_property() in arch/ppc64/fs2dt.c it seems to only accept memory@. Is this expected behaviour? It seems to be the same in current git versions of kexec-tools. On my system I see /proc/device-tree/memory. If I modify add_usable_mem_property() to also accept /memory then my recovery kernel boots up with physicalMemorySize = 0x1000 which is 256MB (which is still a bit odd since I specified 224MB for the crashkernel). However, it then hits the BUG() call at the end of mark_bootmem() in mm/bootmem.c. One final thing and I'll stop replying to myself. :) It looks like the problem is that some board-specific freescale code was calling lmb_reserve() with a base address in the 4GB range. It seems odd that lmb_reserve() didn't throw some kind of error when the recovery kernel was supposed to be limited to 224MB. Rather than try and fix the bug, I turned off the (unneeded) config options related to the above lmb_reserve() calls and was able to successfully access the information I needed via /dev/oldmem. The upshot is that there seems to be a number of things that could be improved: 1) kexec should accept /memory and not just /memory@ 2) lmb_reserve() should really respect the crashkernel memory limit 3) the freescale stuff really shouldn't assume it can map things wherever it feels like What board-specific freescale code are you referring to? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/2] powerpc: Add smp_generic_cpu_bootable
Cell and PSeries both implemented their own versions of a
cpu_bootable smp_op which do the same thing (well, the PSeries
one has support for more than 2 threads). Copy the PSeries one
to generic code, and rename it smp_generic_cpu_bootable.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
v2: Removed Change-Id
arch/powerpc/include/asm/smp.h |2 ++
arch/powerpc/kernel/smp.c | 23 +++
2 files changed, 25 insertions(+)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index ffbaabe..f2b5d41 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -182,6 +182,8 @@ extern int smt_enabled_at_boot;
extern int smp_mpic_probe(void);
extern void smp_mpic_setup_cpu(int cpu);
extern int smp_generic_kick_cpu(int nr);
+extern int smp_generic_cpu_bootable(unsigned int nr);
+
extern void smp_generic_give_timebase(void);
extern void smp_generic_take_timebase(void);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..3cd42aa 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -81,6 +81,29 @@ int smt_enabled_at_boot = 1;
static void (*crash_ipi_function_ptr)(struct pt_regs *) = NULL;
+/*
+ * Returns 1 if the specified cpu should be brought up during boot.
+ * Used to inhibit booting threads if they've been disabled or
+ * limited on the command line
+ */
+int smp_generic_cpu_bootable(unsigned int nr)
+{
+ /* Special case - we inhibit secondary thread startup
+* during boot if the user requests it.
+*/
+ if (system_state == SYSTEM_BOOTING cpu_has_feature(CPU_FTR_SMT)) {
+ if (!smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
+ return 0;
+ if (smt_enabled_at_boot
+cpu_thread_in_core(nr) = smt_enabled_at_boot)
+ return 0;
+ }
+
+ return 1;
+}
+EXPORT_SYMBOL(smp_generic_cpu_bootable);
+
+
#ifdef CONFIG_PPC64
int smp_generic_kick_cpu(int nr)
{
--
1.7.9.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc: Convert platforms to smp_generic_cpu_bootable
T4, Cell, powernv, and pseries had the same implementation, so switch
them to use a generic version. A2 apparently had a version, but
removed it at some point, so we remove the declaration, too.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
v2: Removed conflict and Change-Id foo
arch/powerpc/platforms/85xx/smp.c|1 +
arch/powerpc/platforms/cell/smp.c| 15 +--
arch/powerpc/platforms/powernv/smp.c | 18 +-
arch/powerpc/platforms/pseries/smp.c | 18 +-
arch/powerpc/platforms/wsp/wsp.h |1 -
5 files changed, 4 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c
b/arch/powerpc/platforms/85xx/smp.c
index 5ced4f5..ea9c626 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -255,6 +255,7 @@ out:
struct smp_ops_t smp_85xx_ops = {
.kick_cpu = smp_85xx_kick_cpu,
+ .cpu_bootable = smp_generic_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable= generic_cpu_disable,
.cpu_die= generic_cpu_die,
diff --git a/arch/powerpc/platforms/cell/smp.c
b/arch/powerpc/platforms/cell/smp.c
index f75f6fc..90745ea 100644
--- a/arch/powerpc/platforms/cell/smp.c
+++ b/arch/powerpc/platforms/cell/smp.c
@@ -136,25 +136,12 @@ static int smp_cell_kick_cpu(int nr)
return 0;
}
-static int smp_cell_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it. Odd-numbered
-* cpus are assumed to be secondary threads.
-*/
- if (system_state == SYSTEM_BOOTING
- cpu_has_feature(CPU_FTR_SMT)
- !smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
- return 0;
-
- return 1;
-}
static struct smp_ops_t bpa_iic_smp_ops = {
.message_pass = iic_message_pass,
.probe = smp_iic_probe,
.kick_cpu = smp_cell_kick_cpu,
.setup_cpu = smp_cell_setup_cpu,
- .cpu_bootable = smp_cell_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
};
/* This is called very early */
diff --git a/arch/powerpc/platforms/powernv/smp.c
b/arch/powerpc/platforms/powernv/smp.c
index 89e3857..908672b 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -46,22 +46,6 @@ static void pnv_smp_setup_cpu(int cpu)
xics_setup_cpu();
}
-static int pnv_smp_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it.
-*/
- if (system_state == SYSTEM_BOOTING cpu_has_feature(CPU_FTR_SMT)) {
- if (!smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
- return 0;
- if (smt_enabled_at_boot
-cpu_thread_in_core(nr) = smt_enabled_at_boot)
- return 0;
- }
-
- return 1;
-}
-
int pnv_smp_kick_cpu(int nr)
{
unsigned int pcpu = get_hard_smp_processor_id(nr);
@@ -195,7 +179,7 @@ static struct smp_ops_t pnv_smp_ops = {
.probe = xics_smp_probe,
.kick_cpu = pnv_smp_kick_cpu,
.setup_cpu = pnv_smp_setup_cpu,
- .cpu_bootable = pnv_smp_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
#ifdef CONFIG_HOTPLUG_CPU
.cpu_disable= pnv_smp_cpu_disable,
.cpu_die= generic_cpu_die,
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index 306643c..ca2d1f6 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -187,22 +187,6 @@ static int smp_pSeries_kick_cpu(int nr)
return 0;
}
-static int smp_pSeries_cpu_bootable(unsigned int nr)
-{
- /* Special case - we inhibit secondary thread startup
-* during boot if the user requests it.
-*/
- if (system_state == SYSTEM_BOOTING cpu_has_feature(CPU_FTR_SMT)) {
- if (!smt_enabled_at_boot cpu_thread_in_core(nr) != 0)
- return 0;
- if (smt_enabled_at_boot
-cpu_thread_in_core(nr) = smt_enabled_at_boot)
- return 0;
- }
-
- return 1;
-}
-
/* Only used on systems that support multiple IPI mechanisms */
static void pSeries_cause_ipi_mux(int cpu, unsigned long data)
{
@@ -237,7 +221,7 @@ static struct smp_ops_t pSeries_xics_smp_ops = {
.probe = pSeries_smp_probe,
.kick_cpu = smp_pSeries_kick_cpu,
.setup_cpu = smp_xics_setup_cpu,
- .cpu_bootable = smp_pSeries_cpu_bootable,
+ .cpu_bootable = smp_generic_cpu_bootable,
};
/* This is called very early */
diff --git a/arch/powerpc/platforms/wsp/wsp.h b/arch/powerpc/platforms/wsp/wsp.h
index 62ef21a..a563a8a 100644
--- a/arch/powerpc/platforms/wsp/wsp.h
+++
Re: P1021rdb-pc
On 07/25/2013 03:29:45 AM, BHARATHI KANDIMALLA wrote: Dear Sir, We are using P1021rdb-pc board with p1021 processor. 1. compilation and build process is taking so much of time. How should I reduce the time for linux build process? Remove things from the .config that you don't need. Be sure you're using a -j value that is large enough to keep all your CPUs busy. Use ccache. Get a faster build machine. :-) 2. In kernel configuration we are not able to select P1021rdb., When we configured the board for p1021RDB-PC , in default kenel config file all the below platforms are selected , We want only p1021rdb , what should we select here? CONFIG_PPC_CELL is not set CONFIG_FSL_SOC_BOOKE=y CONFIG_FSL_85XX_CACHE_SRAM=y CONFIG_MPC8540_ADS=y CONFIG_MPC8560_ADS=y CONFIG_MPC85xx_CDS=y CONFIG_MPC85xx_MDS=y CONFIG_MPC8536_DS=y CONFIG_MPC85xx_DS=y CONFIG_MPC85xx_RDB=y fsl,P1021RDB-PC is handled by mpc85xx_rdb.c (and thus CONFIG_MPC85xx_RDB). 3. We are using p1021 processor which has 36 bit support , but we have compiled uboot for 32 bit only.Is there any specfic use of 36 bit compilation, ? If your U-Boot is configured for 32 bits, there's no benefit to enabling CONFIG_PHYS_64BIT (unless you're remapping things yourself, such as moving the PCIe windows), and it can slow things down. 4. Now we are using SDK 1.3.2 for p1021 procesor .Is there any specific necessity that we should switch to sdk1.4 regarding linux drivers specially included for p1021 procesor? It's generally good to use more recent code for the various improvements and fixes it contains, but I don't know of a specific p1021-related requirement. Note that this list is for upstream Linux; for help with Freescale SDKs go to https://community.freescale.com/ Also note that p1021rdb-pc is supported in upstream Linux; you do not need to use the SDK at all unless there is something specific you need beyond basic board support. 5.UMCC driver is available in linux driver ? No. where should I get some help regarding UMCC ? community.freescale.com, supp...@freescale.com, or your sales/FAE contact. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Update compilation flags with core specific options
On 07/25/2013 06:54:14 AM, Catalin Udma wrote: If CONFIG_E500 is enabled, the compilation flags are updated specifying the target core -mcpu=e5500/e500mc/8540 Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500 The assembler option is redundant if the -mcpu= flag is set. The patch fixes the kernel compilation problem for e5500/e6500 when using gcc option -mcpu=e5500/e6500. Signed-off-by: Catalin Udma catalin.u...@freescale.com --- changes for v2: - update also KBUILD_AFLAGS with -mcpu and -msoft-float flags arch/powerpc/Makefile | 16 +++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 0624909..cb5cbe2 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -140,6 +140,21 @@ ifeq ($(CONFIG_6xx),y) KBUILD_CFLAGS += -mcpu=powerpc endif +ifeq ($(CONFIG_E500),y) +ifeq ($(CONFIG_64BIT),y) +KBUILD_CFLAGS += -mcpu=e5500 +KBUILD_AFLAGS += -mcpu=e5500 -msoft-float +else +ifeq ($(CONFIG_PPC_E500MC),y) +KBUILD_CFLAGS += -mcpu=e500mc +KBUILD_AFLAGS += -mcpu=e500mc -msoft-float +else +KBUILD_CFLAGS += -mcpu=8540 +KBUILD_AFLAGS += -mcpu=8540 -msoft-float +endif +endif +endif Instead of specifying -msoft-float here, shouldn't it go on the main KBUILD_AFLAGS in arch/powerpc/Makefile, right next to where it's added for KBUILD_CFLAGS? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [1/1] MPC831x: fix PCI express probing
On Mon, May 27, 2013 at 02:29:43PM +0200, Sergey Gerasimov wrote:
For MPC831x the bus probing function also needs the fixup to assign
addresses to the PCI devices as it was for MPC85xx and MPC86xx.
The fixup of the bridge vendor and device ID should be done early in
PCI probing. Else the bridge is not detected as FIXUP_HEADER is called
too late.
Signed-off-by: Sergey Gerasimov sergey.gerasi...@astrosoft-development.com
---
arch/powerpc/sysdev/fsl_pci.c | 68 +++
1 file changed, 30 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..94d1bd4 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -84,6 +84,34 @@ static int fsl_pcie_check_link(struct pci_controller *hose)
return 0;
}
+void fsl_pcibios_fixup_bus(struct pci_bus *bus)
+{
+ struct pci_controller *hose = (struct pci_controller *) bus-sysdata;
+ int i;
+
+
+ if ((bus-parent == hose-bus)
+ ((fsl_pcie_bus_fixup
+ pci_bus_find_capability(bus, 0, PCI_CAP_ID_EXP))
+ || (hose-indirect_type
+ PPC_INDIRECT_TYPE_NO_PCIE_LINK))) {
+ for (i = 0; i 4; ++i) {
+ struct resource *res = bus-resource[i];
+ struct resource *par = bus-parent-resource[i];
+ if (res) {
+ res-start = 0;
+ res-end = 0;
+ res-flags = 0;
+ }
+ if (res par) {
+ res-start = par-start;
+ res-end = par-end;
+ res-flags = par-flags;
+ }
+ }
+ }
+}
Why are you moving this function? This makes it hardaer to see the
changes you make -- and is likely the cause of unintended changes being
made due to a bad conflict resolution. In particular, you seem to be
reverting commit 13635dfdc6aa8d2890e02dc441decfcb4ae63e14
(powerpc/fsl/pci: Fix PCIe fixup regression).
Also please confirm that the problem still exists in after Fix PCIe
fixup regression.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Add device file bindings for MAPLE
On Mon, 2013-07-29 at 19:00 -0500, Scott Wood wrote: On 07/27/2013 08:03:42 AM, Shaveta Leekha wrote: Signed-off-by: Shaveta Leekha shav...@freescale.com --- .../devicetree/bindings/powerpc/fsl/maple.txt | 50 BTW, that's confusing, we have a platform called maple ... oh well... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: powerpc/85xx: Add P1023RDB board support
On Fri, Jun 14, 2013 at 04:26:20PM +0800, Chunhe Lan wrote:
P1023RDB Specification:
---
Memory subsystem:
512MB DDR3 (Fixed DDR on board)
64MB NOR flash
128MB NAND flash
Where is NAND in the device tree?
Ethernet:
eTSEC1: Connected to Atheros AR8035 GETH PHY
eTSEC2: Connected to Atheros AR8035 GETH PHY
Where are the PHYs in the device tree?
+ partition@3f0 {
+ label = firmware;
+ reg = 0x03f0 0x0008;
+ read-only;
+ };
+ partition@3f8 {
+ label = u-boot;
+ reg = 0x03f8 0x0008;
+ read-only;
+ };
What is firmware if not U-Boot? FMan firmware? Note that part of your
firmware partition contains the U-Boot environment.
diff --git a/arch/powerpc/configs/85xx/p1023rds_defconfig
b/arch/powerpc/configs/85xx/p1023rds_defconfig
index b80bcc6..092a746 100644
--- a/arch/powerpc/configs/85xx/p1023rds_defconfig
+++ b/arch/powerpc/configs/85xx/p1023rds_defconfig
@@ -22,6 +22,7 @@ CONFIG_MODVERSIONS=y
# CONFIG_BLK_DEV_BSG is not set
CONFIG_PARTITION_ADVANCED=y
CONFIG_MAC_PARTITION=y
+CONFIG_P1023_RDB=y
CONFIG_P1023_RDS=y
CONFIG_QUICC_ENGINE=y
CONFIG_QE_GPIO=y
@@ -67,6 +68,7 @@ CONFIG_PROC_DEVICETREE=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_LEGACY=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
@@ -102,6 +104,7 @@ CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_QE=m
CONFIG_NVRAM=y
CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
CONFIG_I2C_CPM=m
CONFIG_I2C_MPC=y
CONFIG_GPIO_MPC8XXX=y
@@ -121,6 +124,7 @@ CONFIG_USB_STORAGE=y
CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_CMOS=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
This isn't a p1023rds. Having one defconfig to support both boards is
good, but the defconfig should be renamed to p1023_defconfig.
diff --git a/arch/powerpc/platforms/85xx/Kconfig
b/arch/powerpc/platforms/85xx/Kconfig
index efdd37c..d0e8ff9 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -111,6 +111,12 @@ config P1022_RDK
This option enables support for the Freescale / iVeia P1022RDK
reference board.
+config P1023_RDB
+ bool Freescale P1023 RDB
+ select P1023_RDS
+ help
+ This option enables support for the P1023 RDB board
+
Why do you need a new kconfig option, if you're supporting both boards
with the same C file? Just update the name and description of the
existing kconfig symbol.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] mmc:core: parse voltage from device-tree
On 07/30/2013 06:07 AM, Scott Wood wrote: On 07/28/2013 09:56:33 PM, Haijun Zhang wrote: Add function to support get voltage from device-tree. If there are voltage-range specified in device-tree node, this function will parse it and return the avail voltage mask. Signed-off-by: Haijun Zhang haijun.zh...@freescale.com --- drivers/mmc/core/core.c | 48 include/linux/mmc/core.h | 1 + 2 files changed, 49 insertions(+) Move the code rather than copying it. -Scott Hi, Scott You mean? -- Thanks Regards Haijun ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 0/3] DMA: Freescale: Add support for 8-channel DMA engine
On 07/29/2013 06:59 PM, Vinod Koul wrote: On Mon, Jul 29, 2013 at 06:49:01PM +0800, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com Hi Vinod, Dan, Scott and Leo, please have a look at these V7 patches. The dma relates changes look okay to me. I need someone to review and ACK the DT bindings. Scott Wood has ACKed the [1/3] and [2/3]. Thank you Vinod. ~Vinod Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch set adds support this DMA engine. V6-V7 changes: - only remove unnecessary CHIP-dma explanations in [1/3] V5-V6 changes: - minor updates of descriptions in binding document and Kconfig - remove [4/4], that should be another patch in future V4-V5 changes: - update description in the dt binding document, to make it more resonable - add new patch [4/4] to eliminate a compiling warning which already exists for a long time V3-V4 changes: - introduce new patch [1/3] to revise the legacy dma binding document - and then add new paragraph to describe new dt node binding in [2/3] - rebase to latest kernel v3.11-rc1 V2-V3 changes: - edit Documentation/devicetree/bindings/powerpc/fsl/dma.txt - edit text string in Kconfig and the driver files, using elo series to mention all the current elo* V1-V2 changes: - removed the codes handling the register dgsr1, since it isn't used currently - renamed the DMA DT compatible to fsl,elo3-dma - renamed the new dts files to elo3-dma-n.dtsi Hongbo Zhang (3): DMA: Freescale: revise device tree binding document DMA: Freescale: Add new 8-channel DMA engine device tree nodes DMA: Freescale: update driver to support 8-channel DMA engine .../devicetree/bindings/powerpc/fsl/dma.txt| 114 +++- arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 ++ arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- drivers/dma/Kconfig|9 +- drivers/dma/fsldma.c |9 +- drivers/dma/fsldma.h |2 +- 8 files changed, 264 insertions(+), 40 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 2/3] DMA: Freescale: Add new 8-channel DMA engine device tree nodes
On 07/30/2013 06:10 AM, Scott Wood wrote: On 07/29/2013 05:49:03 AM, hongbo.zh...@freescale.com wrote: From: Hongbo Zhang hongbo.zh...@freescale.com Freescale QorIQ T4 and B4 introduce new 8-channel DMA engines, this patch adds the device tree nodes for them. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 66 arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 81 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 81 arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +- 5 files changed, 232 insertions(+), 4 deletions(-) create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi create mode 100644 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi ACK Thank you Scott for all the review comments. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4 v6] powerpc: export debug registers save function for KVM
Alexander Graf ag...@suse.de wrote:
On 04.07.2013, at 08:57, Bharat Bhushan wrote:
KVM need this function when switching from vcpu to user-space
thread. My subsequent patch will use this function.
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
Ben / Michael, please ack.
It's not really my area of expertise, but it applies and compiles for me
and it's relatively simple, so FWIW...
Acked-by: Michael Neuling mi...@neuling.org
Alex
---
v5-v6
- switch_booke_debug_regs() not guarded by the compiler switch
arch/powerpc/include/asm/switch_to.h |1 +
arch/powerpc/kernel/process.c|3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/switch_to.h
b/arch/powerpc/include/asm/switch_to.h
index 200d763..db68f1d 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -29,6 +29,7 @@ extern void giveup_vsx(struct task_struct *);
extern void enable_kernel_spe(void);
extern void giveup_spe(struct task_struct *);
extern void load_up_spe(struct task_struct *);
+extern void switch_booke_debug_regs(struct thread_struct *new_thread);
#ifndef CONFIG_SMP
extern void discard_lazy_cpu_state(void);
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 01ff496..da586aa 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -362,12 +362,13 @@ static void prime_debug_regs(struct thread_struct
*thread)
* debug registers, set the debug registers from the values
* stored in the new thread.
*/
-static void switch_booke_debug_regs(struct thread_struct *new_thread)
+void switch_booke_debug_regs(struct thread_struct *new_thread)
{
if ((current-thread.debug.dbcr0 DBCR0_IDM)
|| (new_thread-debug.dbcr0 DBCR0_IDM))
prime_debug_regs(new_thread);
}
+EXPORT_SYMBOL_GPL(switch_booke_debug_regs);
#else /* !CONFIG_PPC_ADV_DEBUG_REGS */
#ifndef CONFIG_HAVE_HW_BREAKPOINT
static void set_debug_reg_defaults(struct thread_struct *thread)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] arch: powerpc: kvm: add signed type cast for comparation
Hello Maintainers:
Please help check this patch whether OK or not, when you have time.
Thanks.
On 07/22/2013 02:32 PM, Chen Gang wrote:
'rmls' is 'unsigned long', lpcr_rmls() will return negative number when
failure occurs, so it need a type cast for comparing.
'lpid' is 'unsigned long', kvmppc_alloc_lpid() return negative number
when failure occurs, so it need a type cast for comparing.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kvm/book3s_hv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 2efa9dd..7629cd3 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1809,7 +1809,7 @@ static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu
*vcpu)
rma_size = PAGE_SHIFT;
rmls = lpcr_rmls(rma_size);
err = -EINVAL;
- if (rmls 0) {
+ if ((long)rmls 0) {
pr_err(KVM: Can't use RMA of 0x%lx bytes\n, rma_size);
goto out_srcu;
}
@@ -1874,7 +1874,7 @@ int kvmppc_core_init_vm(struct kvm *kvm)
/* Allocate the guest's logical partition ID */
lpid = kvmppc_alloc_lpid();
- if (lpid 0)
+ if ((long)lpid 0)
return -ENOMEM;
kvm-arch.lpid = lpid;
--
Chen Gang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, July 30, 2013 1:27 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; ga...@kernel.crashing.org; Zhao Chenhui-
B35336; Li Yang-R58472; Wang Dongsheng-B40534
Subject: Re: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel
features
On 07/10/2013 03:27:56 AM, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 6f3887d..0a8d0cb 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -138,6 +138,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_NOEXECUTE ASM_CONST(0x1000)
#define CPU_FTR_INDEXED_DCRASM_CONST(0x2000)
#define CPU_FTR_EMB_HV ASM_CONST(0x4000)
+#define CPU_FTR_CAN_WAIT ASM_CONST(0x8000)
Note that this is the last 32-bit CPU feature flag; it's time to start
thinking about other mechanisms. We should probably reserve feature
flags for things that need to use code patching due to being on a
performance critical path, and move other things into struct cpu_spec.
CPU_FTR_CAN_WAIT seems like a good candidate to be moved.
First of all, why should I do, I need to distinguish between the core, which
is to support the wait instruction. The CPU_FTR_CAN_WAIT looks easy.
How to fix this problem:
1/ I can drop this cpu feature, and move it into struct cpu_spec.
Add a pm_feature in struct cpu_spec? like,
struct cpu_spec {
...
unsigned long pm_features;
...
}
2/ Drop this cpu feature, using CPU_FTRS_E6500/CPU_FTRS_E5500.. to distinguish
wait or doze/nap.
Like,
CPU_FTRS_E500/CPU_FTRS_E500_2 support doze/nap.
CPU_FTRS_E500MC/CPU_FTRS_E5500/CPU_FTRS_E6500 support wait.
If using this method, inside the cpuidle driver needs to do a lot of judgment.
So I'm not sure this
is a very good solution.
Thanks.
- dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] cpuidle/powernv: Enable idle powernv cpu to call into the cpuidle framework.
On 07/29/2013 08:14 PM, Daniel Lezcano wrote:
On 07/29/2013 04:27 PM, Deepthi Dharwar wrote:
On 07/27/2013 10:59 AM, Daniel Lezcano wrote:
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch enables idle powernv cpu to hook on to the cpuidle
framework, if available, else call on to default idle platform
code.
Why do you need to do that ?
Hi Daniel,
Well, this is needed in case when one does not compile with CPU_IDLE
config option.
When CPUIDLE is not configured, idle cpus are needed to be running some
sort of default idle code or loop ( in the worst case) if cpuidle driver
is not registered or if one decides not to have that config enabled.
Hi Deepthi,
ok may be there is some difference with the other platform but the
arch_cpu_idle function defined in the other archs do:
void arch_cpu_idle(void)
{
if (cpuidle_idle_call())
x86_idle();
else
local_irq_enable();
}
or
void arch_cpu_idle(void)
{
if (cpuidle_idle_call())
default_idle();
}
When the cpuidle driver is not compiled or not loaded, cpuidle_idle_call
fails, falling back to the default idle function.
The arch_cpu_idle function is called from the generic code in
kernel/cpu/idle.c.
Is there a particular reason to do it in a different way ?
On powerpc, we have another parameter, ppc_md.powersave
knob. In arch_cpu_idle, we check for this knob. This is kernel command
line parameter too. If this is not set then default idle is executed.
ppc_md is generic powerpc structure, which points to idle routine that
needs to be executed.
In arch_cpu_idle code for powerpc:
arch_cpu_idle()
{
if (ppc_md.powersave())
ppc_md.powersave()
} else
/* default idle */
}
Not all flavors of powerpc arch support cpuidle.
So only those that support, powersave is set to cpuidle backend call.
And this check is necessary there.
Regards,
Deepthi
Thanks
-- Daniel
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/setup.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/setup.c
b/arch/powerpc/platforms/powernv/setup.c
index 84438af..97d0951 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -25,6 +25,7 @@
#include linux/of.h
#include linux/interrupt.h
#include linux/bug.h
+#include linux/cpuidle.h
#include asm/machdep.h
#include asm/firmware.h
@@ -196,6 +197,15 @@ static int __init pnv_probe(void)
return 1;
}
+void powernv_idle(void)
+{
+ /* Hook to cpuidle framework if available, else
+ * call on default platform idle code
+ */
+ if (cpuidle_idle_call())
+ power7_idle();
+}
+
define_machine(powernv) {
.name = PowerNV,
.probe = pnv_probe,
@@ -205,7 +215,7 @@ define_machine(powernv) {
.show_cpuinfo = pnv_show_cpuinfo,
.progress = pnv_progress,
.machine_shutdown = pnv_shutdown,
- .power_save = power7_idle,
+ .power_save = powernv_idle,
.calibrate_decr = generic_calibrate_decr,
#ifdef CONFIG_KEXEC
.kexec_cpu_down = pnv_kexec_cpu_down,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linux-pm] [PATCH 1/3] cpuidle/powernv: cpuidle backend driver for powernv
On 07/29/2013 08:23 PM, Daniel Lezcano wrote:
On 07/29/2013 04:39 PM, Deepthi Dharwar wrote:
Hi Daniel,
On 07/27/2013 10:57 AM, Daniel Lezcano wrote:
On 07/23/2013 11:01 AM, Deepthi Dharwar wrote:
This patch implements a back-end cpuidle driver for
powernv calling power7_nap and snooze idle states.
This can be extended by adding more idle states
in the future to the existing framework.
Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
[ ... ]
+static int snooze_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int cpu = dev-cpu;
+
+ local_irq_enable();
+ set_thread_flag(TIF_POLLING_NRFLAG);
+
+ while ((!need_resched()) cpu_online(cpu)) {
+ ppc64_runlatch_off();
+ HMT_very_low();
+ }
Why are you using the cpu_online test here ?
Snooze state is an idle state where cpu executes an infinite loop by
reducing the priority of the thread and the idle cpu can come out of it
only if need_resched is set or in case the cpu is offlined. In order to
continue executing this loop to remain in this idle state, we need the
check just to be safe.
Yes, but if the cpu is offline you are no longer executing this code, no ?
Yes, not needed.
Thanks !
Deepthi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [RFC 1/2] fsl/pm: combined the idle(PHPW) state
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, July 30, 2013 1:22 AM
To: Wang Dongsheng-B40534
Cc: b...@kernel.crashing.org; ga...@kernel.crashing.org; Zhao Chenhui-
B35336; Li Yang-R58472; Wang Dongsheng-B40534
Subject: Re: [RFC 1/2] fsl/pm: combined the idle(PHPW) state
On 07/10/2013 03:27:55 AM, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
move wait instructions from idle_e500.S to idle_book3e.S
idle_e500.S: rename e500_idle to e500_idle_ph.
What does _ph mean?
If this is a reference to the new PHnn/PWnn terminology used on e6500, I
don't see how that's relevant to this file, which isn't used on e6500.
Or if you do plan to use this on e6500, why?
ph10/ph15 means doze/nap on freescale e500 family processors. On the IBM
platform does not ph concept.
Yes, ph maybe that's not a good idea. We should keep e500_idle.
On e500 processor, there is doze/nap, but e500mc/e5500/e6500 is using wait.
I want to move wait from idle_e500.S into idle_book3e.S, but book3e means
64bit mode... Now 32bit using idle_e500, 64bit using idle_book3e, and the idle
method
does not distinguish according to the platform, only in accordance with the CPU
running mode(32bit/64bit) to distinguish.
So did you have any idea about this? Or another way as follows,
We do not touch idle_e500.S and idle_e6500.S, add fsl_cpuidle_wait() into
machdep.h
arch/powerpc/include/asm/machdep.h
/* Wait for Interrupt */
static inline void fsl_cpuidle_wait(void)
{
#ifdef CONFIG_PPC64
book3e_idle();
#else
e500_idle();
#endif
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] Add device file bindings for MAPLE
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, July 30, 2013 5:31 AM
To: Leekha Shaveta-B20052
Cc: devicetree-disc...@lists.ozlabs.org; linuxppc-dev@lists.ozlabs.org; Leekha
Shaveta-B20052
Subject: Re: [PATCH] Add device file bindings for MAPLE
On 07/27/2013 08:03:42 AM, Shaveta Leekha wrote:
Signed-off-by: Shaveta Leekha shav...@freescale.com
---
.../devicetree/bindings/powerpc/fsl/maple.txt | 50
1 files changed, 50 insertions(+), 0 deletions(-) create mode 100644
Documentation/devicetree/bindings/powerpc/fsl/maple.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
new file mode 100644
index 000..23b80a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/maple.txt
@@ -0,0 +1,50 @@
+* Freescale MAPLE Multi Accelerator Platform Engine Baseband 3
+ (MAPLE-B3)device nodes
+
+Supported chips:
+Example: B4860
+
+Required properties:
+
+- compatible:Should contain fsl,maple-b3 as the value
+ This identifies Multi Accelerator Platform Engine
+ Baseband 3 block.
+
+- reg: offset and length of the register set for the
device
+
+- interrupts
+ Usage: required
+ Value type: prop_encoded-array
+ Definition: Specifies the interrupts generated by this
device. The
+ value of the interrupts property consists of
one interrupt
+ specifier. The format of the specifier is
defined by the
+ binding document describing the node's
interrupt parent.
Please clean up whitespace so the text aligns.
[Leekha Shaveta-B20052] ok. Will remove whitespaces.
+
+ A single IRQ that handles error conditions is specified
by
+ this property. (Typically shared with port-write).
+
+Devices that have LIODNs need to specify links to the parent PAMU
controller
+(the actual PAMU controller that this device is connected to) and a
pointer to
+the LIODN register, if applicable.
+
+- fsl,iommu-parent
+ : phandle
+ This property should be present
+
+- status = disabled
+ In this example, status is set disabled,
+ As Maple device wouldn't be used by PPC Linux. This
representation is required
+ for doing the PAMU programming on the Linux side.
Is it proper for Linux to even set the LIODN on a device that is disabled?
Perhaps the compatible should be different, such as fsl,maple-b3-liodn to
indicate that that is the only portion of the device that is owned by this
partition.
+Example:
+ /* B4860 */
+
+ maple@80 {
+ #address-cells = 0;
+ #size-cells = 0;
+ status = disabled;
+ compatible = fsl,maple-b3;
+ reg = 0x800 0x1;
+ interrupts = 16 2 1 18;
+ fsl,iommu-parent = pamu1;
+ };
This error interrupt is documented as 13, not 18. b4860 (and maybe other b4?)
have an erratum that says that error interrupts are reversed, but this is
generally implemented in b4si-post.dtsi, not in block-specific include files.
Will no chip without the erratum ever have maple?
[Leekha Shaveta-B20052] You are right here. Will add the interrupts in b4si or
b4860si file, as other chips may have maple.
Regards,
Shaveta
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
