Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
On 11/08/2013 10:45 AM, Dan Williams wrote:
On Mon, Nov 4, 2013 at 6:31 PM, Hongbo Zhang hongbo.zh...@freescale.com wrote:
Hi Vinod Koul and Dan Williams,
Ping?
Not much to review from the dmaengine side, just one question below.
It would be helpful if you can send these to the new dmaengine
patchwork at dmaeng...@vger.kernel.org with the Acks you have already
collected.
Sorry didn't notice this new mailing list.
I will resend these patches to it again.
On 10/17/2013 01:56 PM, Hongbo Zhang wrote:
Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.
On 09/26/2013 05:33 PM, hongbo.zh...@freescale.com wrote:
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) {
Isn't it a bit fragile to have this based on the resource address?
Can't device tree tell you the channel id directly by an index into
the dma0: dma@100300 node?
Yes, both this way and putting a cell-index into device tree work.
This won't be fragile, because the resource address should always be
defined correctly, otherwise even if we can tell a channel id by
cell-index but with wrong resource address, nothing will work.
This piece of code only doesn't seem as neat as using cell-index, but
we prefer the style that let the device tree describes as true as what
hardware really has. This doesn't mean cell-index isn't acceptable, if
it is necessary and unavoidable, we can send another patch to add it,
but currently there is no need and we don't have to do this.
--
Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH resend 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 Acked-by: Mark Rutland mark.rutl...@arm.com --- .../devicetree/bindings/powerpc/fsl/dma.txt| 68 +--- 1 file changed, 31 insertions(+), 37 deletions(-) diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bc..0584168 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt @@ -1,33 +1,30 @@ -* 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 4-channel 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 -- reg : registers mapping for DMA general status reg -- ranges : Should be defined as specified in 1) to describe the - DMA controller channels. +- compatible: must include fsl,elo-dma +- reg : DMA General Status Register, i.e. DGSR which contains + status for all the 4 DMA 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 +- interrupts: interrupt specifier 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. -- reg : registers mapping for channel -- cell-index: dma channel index starts at 0. +- compatible: must include fsl,elo-dma-channel + However, see note below. +- reg : DMA channel specific registers +- 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) +- interrupts: interrupt specifier for DMA channel IRQ + (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,30 +67,27 @@ Example: }; }; -* Freescale 85xx/86xx DMA Controller - -Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers. +** Freescale EloPlus DMA Controller + This is a 4-channel 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 -- reg : registers mapping for DMA general status reg +- compatible: must include fsl,eloplus-dma +- reg : DMA General Status Register, i.e. DGSR which contains + status for all the 4 DMA channels - 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. --
[PATCH resend 0/3] DMA: Freescale: Add support for 8-channel DMA engine
From: Hongbo Zhang hongbo.zh...@freescale.com Hi Dan Williams and Vinod Koul, This time only resend all patches to the new dmaengine patchwork at dmaengine(at)vger.kernel.org as Dan Williams suggested. Patch 1/3 and 2/3 have been Acked-by: Mark Rutland mark.rutl...@arm.com after several iterations of review. 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| 138 ++-- arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +- arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82 arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82 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, 281 insertions(+), 49 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 v6] clk: corenet: Adds the clock binding
From: Tang Yuantian yuantian.t...@freescale.com
Adds the clock bindings for Freescale PowerPC CoreNet platforms
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
v6:
- splited the previous patch into 2 parts, one is for binding(this one),
the other is for DTS modification(will submit once this gets accepted)
- fixed typo
- refined #clock-cells and clock-output-names properties
- removed fixed-clock compatible string
v5:
- refine the binding document
- update the compatible string
v4:
- add binding document
- update compatible string
- update the reg property
v3:
- fix typo
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
.../devicetree/bindings/clock/corenet-clock.txt| 123 +
1 file changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt
b/Documentation/devicetree/bindings/clock/corenet-clock.txt
new file mode 100644
index 000..6a4e15d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -0,0 +1,123 @@
+* Clock Block on Freescale CoreNet Platforms
+
+Freescale CoreNet chips take primary clocking input from the external
+SYSCLK signal. The SYSCLK input (frequency) is multiplied using
+multiple phase locked loops (PLL) to create a variety of frequencies
+which can then be passed to a variety of internal logic, including
+cores and peripheral IP blocks.
+Please refer to the Reference Manual for details.
+
+1. Clock Block Binding
+
+Required properties:
+- compatible: Should include one or more of the following:
+ * fsl,chip-clockgen: for chip specific clock block, here chip
+ could be but not limited to one of the: p2041, p3041, p4080,
+ p5020, p5040, t4240, b4420, b4860
+ * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks
+ * fsl,qoriq-clockgen-2.0: for chassis 2.0 clocks
+ Notes that fsl,qoriq-clockgen-1.0 and fsl,qoriq-clockgen-2.0
+ cannot be included simultaneously.
+- reg: Offset and length of the clock register set
+
+Recommended properties:
+- ranges: Allows valid translation between child's address space and
+ parent's. Must be present if the device has sub-nodes.
+- #address-cells: Specifies the number of cells used to represent
+ physical base addresses. Must be present if the device has
+ sub-nodes and set to 1 if present
+- #size-cells: Specifies the number of cells used to represent
+ the size of an address. Must be present if the device has
+ sub-nodes and set to 1 if present
+
+2. Clock Provider/Consumer Binding
+
+Most of the bindings are from the common clock binding[1].
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : Should include one of the following:
+ * fsl,qoriq-core-pll-1.0 for core PLL clocks (v1.0)
+* fsl,qoriq-core-pll-2.0 for core PLL clocks (v2.0)
+* fsl,qoriq-core-mux-1.0 for core mux clocks (v1.0)
+* fsl,qoriq-core-mux-2.0 for core mux clocks (v2.0)
+ * fsl,qoriq-sysclk-1.0: for input system clock (v1.0)
+ * fsl,qoriq-sysclk-2.0: for input system clock (v2.0)
+- #clock-cells: From common clock binding; indicates the number of
+ output clock. 0 is for fsl,qoriq-sysclk-[1,2].0 and
+ fsl,qoriq-core-mux-[1,2].0; 1 for fsl,qoriq-core-pll-[1,2].0.
+ If #clock-cells has a value of 1, its clock consumer should specify
+ the desired clock by having the clock ID in its clocks phandle
+ cell. The following is a full list IDs:
+ * 0 - equal to the PLL frequency
+ * 1 - equal to the PLL frequency divided by 2
+ * 2 - equal to the PLL frequency divided by 4
+
+Recommended properties:
+- clocks: Should be the phandle of input parent clock
+- clock-names: From common clock binding, indicates the clock name
+- clock-output-names: From common clock binding, indicates the names of
+ output clocks
+- reg: Should be the offset and length of clock block base address.
+ The length should be 4.
+
+Example for clock block and clock provider:
+/ {
+ clockgen: global-utilities@e1000 {
+ compatible = fsl,p5020-clockgen, fsl,qoriq-clockgen-1.0;
+ ranges = 0x0 0xe1000 0x1000;
+ reg = 0xe1000 0x1000;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ sysclk: sysclk {
+ #clock-cells = 0;
+ compatible = fsl,qoriq-sysclk-1.0;
+ clock-output-names = sysclk;
+ }
+
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800 0x4;
+ compatible = fsl,qoriq-core-pll-1.0;
+
[PATCH resend 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
Acked-by: Mark Rutland mark.rutl...@arm.com
---
.../devicetree/bindings/powerpc/fsl/dma.txt| 70 +
arch/powerpc/boot/dts/fsl/b4si-post.dtsi |4 +-
arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi | 82
arch/powerpc/boot/dts/fsl/elo3-dma-1.dtsi | 82
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi|4 +-
5 files changed, 238 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 0584168..7fc1b01 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -128,6 +128,76 @@ Example:
};
};
+** Freescale Elo3 DMA Controller
+ DMA controller which has same function as EloPlus except that Elo3 has 8
+ channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+ series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible: must include fsl,elo3-dma
+- reg : contains two entries for DMA General Status Registers,
+ i.e. DGSR0 which includes status for channel 1~4, and
+ DGSR1 for channel 5~8
+- 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 : DMA channel specific registers
+- interrupts: interrupt specifier 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 4c617bf..4f6e482 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..3c210e0
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/elo3-dma-0.dtsi
@@ -0,0 +1,82 @@
+/*
+ * QorIQ Elo3 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
[PATCH resend 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 f238cfd..cd32586 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 b3f3e90..4e89812 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -1253,7 +1253,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;
@@ -1426,6 +1428,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, },
{}
@@ -1447,7 +1450,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);
}
@@ -1459,5 +1462,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] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
On 11/9/2013 1:17 AM, Lijun Pan wrote: diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig index d2e0fab..72fff6e 100644 --- a/arch/powerpc/configs/mpc85xx_defconfig +++ b/arch/powerpc/configs/mpc85xx_defconfig @@ -1,4 +1,5 @@ CONFIG_PPC_85xx=y +CONFIG_SMP=y mpc85xx_defconfig is targeting single CPU systems, like P1010, so why enable SMP here since there is a separate mpc85xx_smp_defconfig? regards, Claudiu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6] clk: corenet: Adds the clock binding
On Mon, Nov 11, 2013 at 09:41:46AM +, yuantian.t...@freescale.com wrote: From: Tang Yuantian yuantian.t...@freescale.com Adds the clock bindings for Freescale PowerPC CoreNet platforms Signed-off-by: Tang Yuantian yuantian.t...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- v6: - splited the previous patch into 2 parts, one is for binding(this one), the other is for DTS modification(will submit once this gets accepted) - fixed typo - refined #clock-cells and clock-output-names properties - removed fixed-clock compatible string v5: - refine the binding document - update the compatible string v4: - add binding document - update compatible string - update the reg property v3: - fix typo v2: - add t4240, b4420, b4860 support - remove pll/4 clock from p2041, p3041 and p5020 board .../devicetree/bindings/clock/corenet-clock.txt| 123 + 1 file changed, 123 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/corenet-clock.txt new file mode 100644 index 000..6a4e15d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt @@ -0,0 +1,123 @@ +* Clock Block on Freescale CoreNet Platforms + +Freescale CoreNet chips take primary clocking input from the external +SYSCLK signal. The SYSCLK input (frequency) is multiplied using +multiple phase locked loops (PLL) to create a variety of frequencies +which can then be passed to a variety of internal logic, including +cores and peripheral IP blocks. +Please refer to the Reference Manual for details. + +1. Clock Block Binding + +Required properties: +- compatible: Should include one or more of the following: When you say one or more, I assume you mean of the specific clock block strings, and then a chassis string? If so, it might be better to say smoething like: - compatible: Should contain a specific clock block compatible string and a single chassis clock compatible string. Clock block strings include: * fsl,p2041-clockgen * fsl,p3041-clockgen Chassis clock strings include: * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks * fsl,qoriq-clockgen-2.0: for chassis 2.0 clock + * fsl,chip-clockgen: for chip specific clock block, here chip + could be but not limited to one of the: p2041, p3041, p4080, + p5020, p5040, t4240, b4420, b4860 + * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks + * fsl,qoriq-clockgen-2.0: for chassis 2.0 clocks + Notes that fsl,qoriq-clockgen-1.0 and fsl,qoriq-clockgen-2.0 + cannot be included simultaneously. +- reg: Offset and length of the clock register set + +Recommended properties: +- ranges: Allows valid translation between child's address space and + parent's. Must be present if the device has sub-nodes. +- #address-cells: Specifies the number of cells used to represent + physical base addresses. Must be present if the device has + sub-nodes and set to 1 if present +- #size-cells: Specifies the number of cells used to represent + the size of an address. Must be present if the device has + sub-nodes and set to 1 if present Is there any particular reason these _must_ be 1? + +2. Clock Provider/Consumer Binding + +Most of the bindings are from the common clock binding[1]. + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : Should include one of the following: + * fsl,qoriq-core-pll-1.0 for core PLL clocks (v1.0) +* fsl,qoriq-core-pll-2.0 for core PLL clocks (v2.0) +* fsl,qoriq-core-mux-1.0 for core mux clocks (v1.0) +* fsl,qoriq-core-mux-2.0 for core mux clocks (v2.0) + * fsl,qoriq-sysclk-1.0: for input system clock (v1.0) + * fsl,qoriq-sysclk-2.0: for input system clock (v2.0) +- #clock-cells: From common clock binding; indicates the number of + output clock. 0 is for fsl,qoriq-sysclk-[1,2].0 and + fsl,qoriq-core-mux-[1,2].0; 1 for fsl,qoriq-core-pll-[1,2].0. Nit: #clock-cells defines the number of cells in a clock-specifier, not the number of output clocks. How about: - #clock-cells: The number of cells in a clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0 clocks, or 1 for fsl,qoriq-core-pll-[1,2].0 clocks. + If #clock-cells has a value of 1, its clock consumer should specify + the desired clock by having the clock ID in its clocks phandle + cell. The following is a full list IDs: The ID is in the clock-specifier, not the phandle. How about the following instead: For fsl,qoriq-core-pll-[1,2].0 clocks, the single clock-specifier cell may take the following values: + * 0 - equal to the PLL frequency + * 1 - equal to the PLL frequency divided by 2 + *
[PATCH] powerpc: book3s: kvm: Don't abuse host r2 in exit path
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
We don't use PACATOC for PR. Avoid updating HOST_R2 with PR
KVM mode when both HV and PR are enabled in the kernel. Without this we
get the below crash
(qemu)
Unable to handle kernel paging request for data at address 0x8310
Faulting instruction address: 0xc001d5a4
cpu 0x2: Vector: 300 (Data Access) at [c001dc53aef0]
pc: c001d5a4: .vtime_delta.isra.1+0x34/0x1d0
lr: c001d760: .vtime_account_system+0x20/0x60
sp: c001dc53b170
msr: 80009032
dar: 8310
dsisr: 4000
current = 0xc001d76c62d0
paca= 0xcfef1100 softe: 0irq_happened: 0x01
pid = 4472, comm = qemu-system-ppc
enter ? for help
[c001dc53b200] c001d760 .vtime_account_system+0x20/0x60
[c001dc53b290] c008d050 .kvmppc_handle_exit_pr+0x60/0xa50
[c001dc53b340] c008f51c kvm_start_lightweight+0xb4/0xc4
[c001dc53b510] c008cdf0 .kvmppc_vcpu_run_pr+0x150/0x2e0
[c001dc53b9e0] c008341c .kvmppc_vcpu_run+0x2c/0x40
[c001dc53ba50] c0080af4 .kvm_arch_vcpu_ioctl_run+0x54/0x1b0
[c001dc53bae0] c007b4c8 .kvm_vcpu_ioctl+0x478/0x730
[c001dc53bca0] c02140cc .do_vfs_ioctl+0x4ac/0x770
[c001dc53bd80] c02143e8 .SyS_ioctl+0x58/0xb0
[c001dc53be30] c0009e58 syscall_exit+0x0/0x98
--- Exception: c00 (System Call) at 1f960160
SP (1ecbe3c0) is in userspace
These changes were originally part of
http://mid.gmane.org/20130806042205.gr19...@iris.ozlabs.ibm.com
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_book3s_asm.h | 1 +
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 7 +++
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 0bd9348..69fe837 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -79,6 +79,7 @@ struct kvmppc_host_state {
ulong vmhandler;
ulong scratch0;
ulong scratch1;
+ ulong scratch2;
u8 in_guest;
u8 restore_hid5;
u8 napping;
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index 8e6ede6..841a4c8 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -583,6 +583,7 @@ int main(void)
HSTATE_FIELD(HSTATE_VMHANDLER, vmhandler);
HSTATE_FIELD(HSTATE_SCRATCH0, scratch0);
HSTATE_FIELD(HSTATE_SCRATCH1, scratch1);
+ HSTATE_FIELD(HSTATE_SCRATCH2, scratch2);
HSTATE_FIELD(HSTATE_IN_GUEST, in_guest);
HSTATE_FIELD(HSTATE_RESTORE_HID5, restore_hid5);
HSTATE_FIELD(HSTATE_NAPPING, napping);
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 339aa5e..16f7654 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -750,15 +750,14 @@ kvmppc_interrupt_hv:
* guest CR, R12 saved in shadow VCPU SCRATCH1/0
* guest R13 saved in SPRN_SCRATCH0
*/
- /* abuse host_r2 as third scratch area; we get r2 from PACATOC(r13) */
- std r9, HSTATE_HOST_R2(r13)
+ std r9, HSTATE_SCRATCH2(r13)
lbz r9, HSTATE_IN_GUEST(r13)
cmpwi r9, KVM_GUEST_MODE_HOST_HV
beq kvmppc_bad_host_intr
#ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
cmpwi r9, KVM_GUEST_MODE_GUEST
- ld r9, HSTATE_HOST_R2(r13)
+ ld r9, HSTATE_SCRATCH2(r13)
beq kvmppc_interrupt_pr
#endif
/* We're now back in the host but in guest MMU context */
@@ -778,7 +777,7 @@ kvmppc_interrupt_hv:
std r6, VCPU_GPR(R6)(r9)
std r7, VCPU_GPR(R7)(r9)
std r8, VCPU_GPR(R8)(r9)
- ld r0, HSTATE_HOST_R2(r13)
+ ld r0, HSTATE_SCRATCH2(r13)
std r0, VCPU_GPR(R9)(r9)
std r10, VCPU_GPR(R10)(r9)
std r11, VCPU_GPR(R11)(r9)
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Don't try to compute these values.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
NOTE: I am not sure why we were originally computing dsisr and dar. So may be
we need a variant of this patch. But with this and the additional patch
powerpc: book3s: PR: Enable Little Endian PR guest I am able to get a Little
Endian
PR guest to boot.
arch/powerpc/kvm/book3s_emulate.c | 64 ++-
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_emulate.c
b/arch/powerpc/kvm/book3s_emulate.c
index 99d40f8..62768f9 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -569,70 +569,10 @@ unprivileged:
u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
{
- u32 dsisr = 0;
-
- /*
-* This is what the spec says about DSISR bits (not mentioned = 0):
-*
-* 12:13[DS]Set to bits 30:31
-* 15:16[X] Set to bits 29:30
-* 17 [X] Set to bit 25
-* [D/DS] Set to bit 5
-* 18:21[X] Set to bits 21:24
-* [D/DS] Set to bits 1:4
-* 22:26Set to bits 6:10 (RT/RS/FRT/FRS)
-* 27:31Set to bits 11:15 (RA)
-*/
-
- switch (get_op(inst)) {
- /* D-form */
- case OP_LFS:
- case OP_LFD:
- case OP_STFD:
- case OP_STFS:
- dsisr |= (inst 12) 0x4000; /* bit 17 */
- dsisr |= (inst 17) 0x3c00; /* bits 18:21 */
- break;
- /* X-form */
- case 31:
- dsisr |= (inst 14) 0x18000; /* bits 15:16 */
- dsisr |= (inst 8) 0x04000; /* bit 17 */
- dsisr |= (inst 3) 0x03c00; /* bits 18:21 */
- break;
- default:
- printk(KERN_INFO KVM: Unaligned instruction 0x%x\n, inst);
- break;
- }
-
- dsisr |= (inst 16) 0x03ff; /* bits 22:31 */
-
- return dsisr;
+ return vcpu-arch.fault_dsisr;
}
ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
{
- ulong dar = 0;
- ulong ra = get_ra(inst);
- ulong rb = get_rb(inst);
-
- switch (get_op(inst)) {
- case OP_LFS:
- case OP_LFD:
- case OP_STFD:
- case OP_STFS:
- if (ra)
- dar = kvmppc_get_gpr(vcpu, ra);
- dar += (s32)((s16)inst);
- break;
- case 31:
- if (ra)
- dar = kvmppc_get_gpr(vcpu, ra);
- dar += kvmppc_get_gpr(vcpu, rb);
- break;
- default:
- printk(KERN_INFO KVM: Unaligned instruction 0x%x\n, inst);
- break;
- }
-
- return dar;
+ return vcpu-arch.fault_dar;
}
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: book3s: PR: Enable Little Endian PR guest
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch make sure we inherit the LE bit correctly in different case
so that we can run Little Endian distro in PR mode
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
This patch depends on the below two changes
1) [PATCH v5 0/6] KVM: PPC: Book3S: MMIO support for Little Endian guests
(kvm-ppc)
http://mid.gmane.org/1383672128-26795-1-git-send-email-...@fr.ibm.com
2) [PATCH] powerpc: book3s: kvm: Use the saved dsisr and dar values
http://mid.gmane.org/1384178577-23721-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com
arch/powerpc/kvm/book3s_64_mmu.c | 2 +-
arch/powerpc/kvm/book3s_pr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index 83da1f8..d339096 100644
--- a/arch/powerpc/kvm/book3s_64_mmu.c
+++ b/arch/powerpc/kvm/book3s_64_mmu.c
@@ -38,7 +38,7 @@
static void kvmppc_mmu_book3s_64_reset_msr(struct kvm_vcpu *vcpu)
{
- kvmppc_set_msr(vcpu, MSR_SF);
+ kvmppc_set_msr(vcpu, MSR_SF | (vcpu-arch.shared-msr MSR_LE));
}
static struct kvmppc_slb *kvmppc_mmu_book3s_64_find_slbe(
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index a7fe87a..cf9362c 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -226,7 +226,7 @@ static void kvmppc_recalc_shadow_msr(struct kvm_vcpu *vcpu)
ulong smsr = vcpu-arch.shared-msr;
/* Guest MSR values */
- smsr = MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE;
+ smsr = MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE | MSR_LE;
/* Process MSR values */
smsr |= MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_PR | MSR_EE;
/* External providers the guest reserved */
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Ping Re: [PATCH 0/6] powerpc/math-emu: e500 SPE float emulation fixes
Ping. I haven't seen any comments on any of these patches. -- Joseph S. Myers jos...@codesourcery.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y. Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig. Signed-off-by: Lijun Pan lijun@freescale.com --- arch/powerpc/configs/85xx/p1023_defconfig | 188 arch/powerpc/configs/mpc85xx_defconfig | 18 +++ arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++ 3 files changed, 35 insertions(+), 188 deletions(-) delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig diff --git a/arch/powerpc/configs/85xx/p1023_defconfig b/arch/powerpc/configs/85xx/p1023_defconfig deleted file mode 100644 index b06d37d..000 --- a/arch/powerpc/configs/85xx/p1023_defconfig +++ /dev/null @@ -1,188 +0,0 @@ -CONFIG_PPC_85xx=y -CONFIG_SMP=y -CONFIG_NR_CPUS=2 -CONFIG_SYSVIPC=y -CONFIG_POSIX_MQUEUE=y -CONFIG_BSD_PROCESS_ACCT=y -CONFIG_AUDIT=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y -CONFIG_RCU_FANOUT=32 -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=14 -CONFIG_BLK_DEV_INITRD=y -CONFIG_KALLSYMS_ALL=y -CONFIG_EMBEDDED=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -CONFIG_MODULE_FORCE_UNLOAD=y -CONFIG_MODVERSIONS=y -# CONFIG_BLK_DEV_BSG is not set -CONFIG_PARTITION_ADVANCED=y -CONFIG_MAC_PARTITION=y -CONFIG_PHYSICAL_START=0x -CONFIG_P1023_RDB=y -CONFIG_P1023_RDS=y -CONFIG_QUICC_ENGINE=y -CONFIG_QE_GPIO=y -CONFIG_CPM2=y -CONFIG_HIGHMEM=y -# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set -CONFIG_BINFMT_MISC=m -CONFIG_MATH_EMULATION=y -CONFIG_SWIOTLB=y -CONFIG_PCI=y -CONFIG_PCIEPORTBUS=y -# CONFIG_PCIEAER is not set -# CONFIG_PCIEASPM is not set -CONFIG_PCI_MSI=y -CONFIG_NET=y -CONFIG_PACKET=y -CONFIG_UNIX=y -CONFIG_XFRM_USER=y -CONFIG_NET_KEY=y -CONFIG_INET=y -CONFIG_IP_MULTICAST=y -CONFIG_IP_ADVANCED_ROUTER=y -CONFIG_IP_MULTIPLE_TABLES=y -CONFIG_IP_ROUTE_MULTIPATH=y -CONFIG_IP_ROUTE_VERBOSE=y -CONFIG_IP_PNP=y -CONFIG_IP_PNP_DHCP=y -CONFIG_IP_PNP_BOOTP=y -CONFIG_IP_PNP_RARP=y -CONFIG_NET_IPIP=y -CONFIG_IP_MROUTE=y -CONFIG_IP_PIMSM_V1=y -CONFIG_IP_PIMSM_V2=y -CONFIG_ARPD=y -CONFIG_INET_ESP=y -# CONFIG_INET_XFRM_MODE_BEET is not set -# CONFIG_INET_LRO is not set -CONFIG_IPV6=y -CONFIG_IP_SCTP=m -CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug -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 -CONFIG_MTD_PHYSMAP_OF=y -CONFIG_MTD_NAND=y -CONFIG_MTD_NAND_FSL_ELBC=y -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 -CONFIG_BLK_DEV_SR=y -CONFIG_CHR_DEV_SG=y -CONFIG_SCSI_MULTI_LUN=y -CONFIG_SCSI_LOGGING=y -CONFIG_ATA=y -CONFIG_SATA_FSL=y -CONFIG_SATA_SIL24=y -CONFIG_NETDEVICES=y -CONFIG_DUMMY=y -CONFIG_FS_ENET=y -CONFIG_FSL_PQ_MDIO=y -CONFIG_E1000E=y -CONFIG_PHYLIB=y -CONFIG_AT803X_PHY=y -CONFIG_MARVELL_PHY=y -CONFIG_DAVICOM_PHY=y -CONFIG_CICADA_PHY=y -CONFIG_VITESSE_PHY=y -CONFIG_FIXED_PHY=y -CONFIG_INPUT_FF_MEMLESS=m -# CONFIG_INPUT_MOUSEDEV is not set -# CONFIG_INPUT_KEYBOARD is not set -# CONFIG_INPUT_MOUSE is not set -CONFIG_SERIO_LIBPS2=y -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=2 -CONFIG_SERIAL_8250_RUNTIME_UARTS=2 -CONFIG_SERIAL_8250_EXTENDED=y -CONFIG_SERIAL_8250_MANY_PORTS=y -CONFIG_SERIAL_8250_SHARE_IRQ=y -CONFIG_SERIAL_8250_DETECT_IRQ=y -CONFIG_SERIAL_8250_RSA=y -CONFIG_HW_RANDOM=y -CONFIG_NVRAM=y -CONFIG_I2C=y -CONFIG_I2C_CHARDEV=y -CONFIG_I2C_CPM=m -CONFIG_I2C_MPC=y -CONFIG_GPIO_MPC8XXX=y -# CONFIG_HWMON is not set -CONFIG_VIDEO_OUTPUT_CONTROL=y -CONFIG_SOUND=y -CONFIG_SND=y -CONFIG_SND_MIXER_OSS=y -CONFIG_SND_PCM_OSS=y -# CONFIG_SND_SUPPORT_OLD_API is not set -CONFIG_USB=y -CONFIG_USB_DEVICEFS=y -CONFIG_USB_MON=y -CONFIG_USB_EHCI_HCD=y -CONFIG_USB_EHCI_FSL=y -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 -# CONFIG_NET_DMA is not set -CONFIG_STAGING=y -CONFIG_EXT2_FS=y -CONFIG_EXT3_FS=y -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -CONFIG_ISO9660_FS=m -CONFIG_JOLIET=y -CONFIG_ZISOFS=y -CONFIG_UDF_FS=m -CONFIG_MSDOS_FS=m -CONFIG_VFAT_FS=y -CONFIG_NTFS_FS=y -CONFIG_PROC_KCORE=y -CONFIG_TMPFS=y -CONFIG_ADFS_FS=m -CONFIG_AFFS_FS=m -CONFIG_HFS_FS=m -CONFIG_HFSPLUS_FS=m -CONFIG_BEFS_FS=m -CONFIG_BFS_FS=m -CONFIG_EFS_FS=m -CONFIG_CRAMFS=y -CONFIG_VXFS_FS=m -CONFIG_HPFS_FS=m -CONFIG_QNX4FS_FS=m -CONFIG_SYSV_FS=m -CONFIG_UFS_FS=m -CONFIG_NFS_FS=y -CONFIG_NFS_V4=y -CONFIG_ROOT_NFS=y -CONFIG_NFSD=y -CONFIG_CRC_T10DIF=y -CONFIG_FRAME_WARN=8092 -CONFIG_DEBUG_FS=y -CONFIG_DETECT_HUNG_TASK=y -# CONFIG_DEBUG_BUGVERBOSE is not set -CONFIG_DEBUG_INFO=y -CONFIG_STRICT_DEVMEM=y -CONFIG_CRYPTO_PCBC=m -CONFIG_CRYPTO_SHA256=y -CONFIG_CRYPTO_SHA512=y -CONFIG_CRYPTO_AES=y -# CONFIG_CRYPTO_ANSI_CPRNG is not set -CONFIG_CRYPTO_DEV_FSL_CAAM=y diff
Re: [PATCH RFC v5 1/5] dma: mpc512x: reorder mpc8308 specific instructions
[ dropping devicetree@vger from CC ] On Fri, Nov 01, 2013 at 11:04 +0100, Anatolij Gustschin wrote: On Fri, 1 Nov 2013 11:19:30 +0400 Alexander Popov a13xp0p0...@gmail.com wrote: Concentrate the specific code for MPC8308 in the 'if' branch and handle MPC512x in the 'else' branch. This modification only reorders instructions but doesn't change behaviour. Signed-off-by: Alexander Popov a13xp0p0...@gmail.com --- drivers/dma/mpc512x_dma.c | 42 +- 1 file changed, 25 insertions(+), 17 deletions(-) Acked-by: Anatolij Gustschin ag...@denx.de I feel that this patch has become stable and can be taken, regardless of the pending review of the other parts in the series. 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: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers
On Fri, Nov 01, 2013 at 11:19 +0400, Alexander Popov wrote: Introduce support for slave s/g transfer preparation and the associated device control callback in the MPC512x DMA controller driver, which adds support for data transfers between memory and peripheral I/O to the previously supported mem-to-mem transfers. Alexander, there is outstanding review feedback for a previous version of the series that you haven't addressed yet. Can you please either look into those issues, or state that it's OK to leave them and why this is so? It would be nice to get a response to the feedback that you are given. It may be appropriate not to obey to the feedback, but at least it should get considered. Have you noticed the recent introduction of the dmaengine@vger ML? Make sure to include it upon the next submission. 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: off...@denx.de ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BookE branch taken behavior vis-a-vis updating the NIP register
On Mon, 11 Nov 2013, pegasus wrote: And this is due to the pipelining feature that is inherent in all processors. No, it has nothing to do with pipelining at all. It is just the convention that IBM defined as to how the branch taken exception works in BookE Power ISA. The pipeline behavior is not visible from the architected state. But I still have a question about how one would then be able to signal to the userspace who might be interpreting this information differently? I mean if SRR0 contains, not the branch instruction address but the address of the branch target, how would any debugger be able to catch function calls? On Server and the BookE-mimicking-Server, PT_NIP would point to the start of the function you are calling. However, you do not get the callsite address unless you know you stopped after a function-calling branch-and-link executed, single step again and read the LR and subtract 4. If you don't know if the branch that caused the exception was actually a branch-and-link, you don't know if you are at the beginning of a function or not, unless you keep a table of the address of all possible functions and look up each PT_NIP to see if you are. But that wouldn't be 100% accurate either, since a non-linking branch could just redirect to the beginning of the function. In the other thread, Ben said they have the CFAR register, but from the way it is described in the ISA document, you will not always get the address of the callsite, e.g. if your target is in the same cache black, the CFAR might not change. So, I don't think it can work in a simple way. On BookE with my patch to NOT mimic server, you will stop before the branch executes, so PT_NIP points to the branch itself, so that there is your callsite information. If you want the function target, you decode the instruction to see if it is a branch-and-link, and then compute the target address or manually singlestep and grab the new PT_NIP. May be there is a trick involved here and hence gdb or for that matter the other debuggers are still in the market. Per the other thread, and my inquiry through my company's gdb experts and upstream on the gdb mailing list, gdb does NOT use hardware branch tracing, at least not using PTRACE_SINGLEBLOCK. I don't personally know of any debuggers that use it in the form that it exists in Linux. But then I would be immensely obliged if you could shed some light on how is this accomplished. Lets say I am waiting at the userspace in my own sigtrap, to watch out for branch instructions. Lets say I want to profile my code to get to know how many branch instructions it has generated. How could I ever do that using my own custom SIGTRAP handler? Lots of ways to skin this cat, but I don't think any of them are easy or simple. - Using valgrind is probably the easiest way to get this information on an unmodified executable. - You may want to recompile your program with call-arch profiling if you have source code. gcc -fprofile-arcs but read the docs. - Another method is to set up performance monitor counter to interrupt after a branch has executed, but callsite information may be lost as well and you still have the issue of discerning whether you just called a function or not. - You can use my patch for BookE, but it's just an RFC. Also, using PTRACE_SINGLEBLOCK is slow. You could also stop on every PTRACE_SINGLESTEP, but this is even slower. Coming on to PTRACE_SINGLESTEP, the sysroot that has been provided to us by our vendor does not include a PTRACE_SINGLEBLOCK in sys/ptrace.h: Although I can clearly see that PTRACE_SINGLEBLOCK is supported in the kernel. Hence I am not able to compile this simple program in userspace: Heres the error I get: testptrace.c: In function 'int main()': testptrace.c:47: error: invalid conversion from 'int' to '__ptrace_request' testptrace.c:47: error: initializing argument 1 of 'long int ptrace(__ptrace_request, ...)' make: *** [testptrace] Error 1 How should I go about using ptrace to test this? I don't know. You'll probably have to request support from your vendor or whoever provided you with those headers. If you are using a glibc based toolchain, your glibc is probably out-of-date. You can try adding PTRACE_SINGLEBLOCK into the enum definition just to get past the compiler syntax error, but I don't know if that will break things or not in your libc ptrace(). You may have to write your own function that calls the __ptrace syscall directly if the libc ptrace() does something to the request or the response. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/4] phylib: Add Clause 45 read/write functions
From: Andy Fleming
You need an extra parameter to read or write Clause 45 PHYs, so
we need a different API with the extra parameter.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
include/linux/phy.h | 33 +
1 file changed, 33 insertions(+)
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 64ab823..684925a 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -498,6 +498,21 @@ static inline int phy_read(struct phy_device *phydev, u32
regnum)
}
/**
+ * phy_read_mmd - Convenience function for reading a register
+ * from an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ *
+ * Same rules as for phy_read();
+ */
+static inline int phy_read_mmd(struct phy_device *phydev, int devad, u32
regnum)
+{
+ return mdiobus_read(phydev-bus, phydev-addr,
+ MII_ADDR_C45 | (devad 16) | (regnum 0x));
+}
+
+/**
* phy_write - Convenience function for writing a given PHY register
* @phydev: the phy_device struct
* @regnum: register number to write
@@ -533,6 +548,24 @@ static inline bool phy_is_internal(struct phy_device
*phydev)
return phydev-is_internal;
}
+/**
+ * phy_write_mmd - Convenience function for writing a register
+ * on an MMD on a given PHY.
+ * @phydev: The phy_device struct
+ * @devad: The MMD to read from
+ * @regnum: The register on the MMD to read
+ * @val: value to write to @regnum
+ *
+ * Same rules as for phy_write();
+ */
+static inline int phy_write_mmd(struct phy_device *phydev, int devad,
+ u32 regnum, u16 val)
+{
+ regnum = MII_ADDR_C45 | ((devad 0x1f) 16) | (regnum 0x);
+
+ return mdiobus_write(phydev-bus, phydev-addr, regnum, val);
+}
+
struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
bool is_c45, struct phy_c45_device_ids *c45_ids);
struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45);
--
1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/4] phylib: Add generic 10G driver
From: Andy Fleming
Very incomplete, but will allow for binding an ethernet controller
to it.
Also, Add XGMII interface type
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
drivers/net/phy/phy_device.c | 101 ++-
include/linux/phy.h | 1 +
2 files changed, 101 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 74630e9..30bf2d5 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -32,6 +32,7 @@
#include linux/module.h
#include linux/mii.h
#include linux/ethtool.h
+#include linux/mdio.h
#include linux/phy.h
#include asm/io.h
@@ -689,6 +690,13 @@ static int genphy_config_advert(struct phy_device *phydev)
return changed;
}
+int gen10g_config_advert(struct phy_device *dev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_config_advert);
+
+
/**
* genphy_setup_forced - configures/forces speed/duplex from @phydev
* @phydev: target phy_device struct
@@ -742,6 +750,12 @@ int genphy_restart_aneg(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_restart_aneg);
+int gen10g_restart_aneg(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_restart_aneg);
+
/**
* genphy_config_aneg - restart auto-negotiation or write BMCR
@@ -784,6 +798,13 @@ int genphy_config_aneg(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_config_aneg);
+int gen10g_config_aneg(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_config_aneg);
+
+
/**
* genphy_update_link - update link status in @phydev
* @phydev: target phy_device struct
@@ -913,6 +934,35 @@ int genphy_read_status(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_read_status);
+int gen10g_read_status(struct phy_device *phydev)
+{
+ int devad, reg;
+ u32 mmd_mask = phydev-c45_ids.devices_in_package;
+
+ phydev-link = 1;
+
+ /* For now just lie and say it's 10G all the time */
+ phydev-speed = 1;
+ phydev-duplex = DUPLEX_FULL;
+
+ for (devad = 0; mmd_mask; devad++, mmd_mask = mmd_mask 1) {
+ if (!(mmd_mask 1))
+ continue;
+
+ /* Read twice because link state is latched and a
+* read moves the current state into the register
+*/
+ phy_read_mmd(phydev, devad, MDIO_STAT1);
+ reg = phy_read_mmd(phydev, devad, MDIO_STAT1);
+ if (reg 0 || !(reg MDIO_STAT1_LSTATUS))
+ phydev-link = 0;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_read_status);
+
+
static int genphy_config_init(struct phy_device *phydev)
{
int val;
@@ -959,6 +1009,15 @@ static int genphy_config_init(struct phy_device *phydev)
return 0;
}
+
+static int gen10g_config_init(struct phy_device *phydev)
+{
+ /* Temporarily just say we support everything */
+ phydev-supported = phydev-advertising = SUPPORTED_1baseT_Full;
+
+ return 0;
+}
+
int genphy_suspend(struct phy_device *phydev)
{
int value;
@@ -974,6 +1033,13 @@ int genphy_suspend(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_suspend);
+int gen10g_suspend(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_suspend);
+
+
int genphy_resume(struct phy_device *phydev)
{
int value;
@@ -989,6 +1055,13 @@ int genphy_resume(struct phy_device *phydev)
}
EXPORT_SYMBOL(genphy_resume);
+int gen10g_resume(struct phy_device *phydev)
+{
+ return 0;
+}
+EXPORT_SYMBOL(gen10g_resume);
+
+
/**
* phy_probe - probe and init a PHY device
* @dev: device to probe and init
@@ -1129,6 +1202,20 @@ static struct phy_driver genphy_driver = {
.driver = {.owner= THIS_MODULE, },
};
+static struct phy_driver gen10g_driver = {
+ .phy_id = 0x,
+ .phy_id_mask= 0x,
+ .name = Generic 10G PHY,
+ .config_init= gen10g_config_init,
+ .features = 0,
+ .config_aneg= gen10g_config_aneg,
+ .read_status= gen10g_read_status,
+ .suspend= gen10g_suspend,
+ .resume = gen10g_resume,
+ .driver = {.owner = THIS_MODULE, },
+};
+
+
static int __init phy_init(void)
{
int rc;
@@ -1139,13 +1226,25 @@ static int __init phy_init(void)
rc = phy_driver_register(genphy_driver);
if (rc)
- mdio_bus_exit();
+ goto genphy_register_failed;
+
+ rc = phy_driver_register(gen10g_driver);
+ if (rc)
+ goto gen10g_register_failed;
+
+ return rc;
+
+gen10g_register_failed:
+ phy_driver_unregister(genphy_driver);
+genphy_register_failed:
+ mdio_bus_exit();
return rc;
}
static void __exit phy_exit(void)
{
+ phy_driver_unregister(gen10g_driver);
phy_driver_unregister(genphy_driver);
mdio_bus_exit();
}
[PATCH 3/4] phylib: Support attaching to gen10g_driver
From: Andy Fleming
phy_attach_direct() may now attach to a generic 10G driver. It can
also be used exactly as phy_connect_direct(), which will be useful
when using of_mdio, as phy_connect (and therefore of_phy_connect)
start the PHY state machine, which is currently irrelevant for 10G
PHYs.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
drivers/net/phy/phy_device.c | 23 +++
include/linux/phy.h | 2 ++
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 30bf2d5..f51ea2e 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -55,15 +55,13 @@ static void phy_device_release(struct device *dev)
}
static struct phy_driver genphy_driver;
+static struct phy_driver gen10g_driver;
extern int mdio_bus_init(void);
extern void mdio_bus_exit(void);
static LIST_HEAD(phy_fixup_list);
static DEFINE_MUTEX(phy_fixup_lock);
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
-u32 flags, phy_interface_t interface);
-
/*
* Creates a new phy_fixup and adds it to the list
* @bus_id: A string which matches phydev-dev.bus_id (or PHY_ANY_ID)
@@ -521,12 +519,12 @@ int phy_init_hw(struct phy_device *phydev)
*
* Description: Called by drivers to attach to a particular PHY
* device. The phy_device is found, and properly hooked up
- * to the phy_driver. If no driver is attached, then the
- * genphy_driver is used. The phy_device is given a ptr to
+ * to the phy_driver. If no driver is attached, then a
+ * generic driver is used. The phy_device is given a ptr to
* the attaching device, and given a callback for link status
* change. The phy_device is returned to the attaching driver.
*/
-static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
u32 flags, phy_interface_t interface)
{
struct device *d = phydev-dev;
@@ -535,12 +533,10 @@ static int phy_attach_direct(struct net_device *dev,
struct phy_device *phydev,
/* Assume that if there is no driver, that it doesn't
* exist, and we should use the genphy driver. */
if (NULL == d-driver) {
- if (phydev-is_c45) {
- pr_err(No driver for phy %x\n, phydev-phy_id);
- return -ENODEV;
- }
-
- d-driver = genphy_driver.driver;
+ if (phydev-is_c45)
+ d-driver = gen10g_driver.driver;
+ else
+ d-driver = genphy_driver.driver;
err = d-driver-probe(d);
if (err = 0)
@@ -573,6 +569,7 @@ static int phy_attach_direct(struct net_device *dev, struct
phy_device *phydev,
return err;
}
+EXPORT_SYMBOL(phy_attach_direct);
/**
* phy_attach - attach a network device to a particular PHY device
@@ -623,6 +620,8 @@ void phy_detach(struct phy_device *phydev)
* real driver could be loaded */
if (phydev-dev.driver == genphy_driver.driver)
device_release_driver(phydev-dev);
+ else if (phydev-dev.driver == gen10g_driver.driver)
+ device_release_driver(phydev-dev);
}
EXPORT_SYMBOL(phy_detach);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index f864004..f36a6f6 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -575,6 +575,8 @@ int phy_init_hw(struct phy_device *phydev);
struct phy_device * phy_attach(struct net_device *dev,
const char *bus_id, phy_interface_t interface);
struct phy_device *phy_find_first(struct mii_bus *bus);
+int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
+u32 flags, phy_interface_t interface);
int phy_connect_direct(struct net_device *dev, struct phy_device *phydev,
void (*handler)(struct net_device *),
phy_interface_t interface);
--
1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/4] phylib: Add of_phy_attach
From: Andy Fleming
10G PHYs don't currently support running the state machine, which
is implicitly setup via of_phy_connect(). Therefore, it is necessary
to implement an OF version of phy_attach(), which does everything
except start the state machine.
Signed-off-by: Andy Fleming
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
drivers/of/of_mdio.c| 22 --
include/linux/of_mdio.h | 8
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index d5a57a9..a748274 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -221,8 +221,7 @@ EXPORT_SYMBOL(of_phy_connect);
* not call this function from new drivers.
*/
struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
-void (*hndlr)(struct net_device *),
-phy_interface_t iface)
+ void (*hndlr)(struct net_device *), phy_interface_t iface)
{
struct device_node *net_np;
char bus_id[MII_BUS_ID_SIZE + 3];
@@ -247,3 +246,22 @@ struct phy_device *of_phy_connect_fixed_link(struct
net_device *dev,
return IS_ERR(phy) ? NULL : phy;
}
EXPORT_SYMBOL(of_phy_connect_fixed_link);
+
+/**
+ * of_phy_attach - Attach to a PHY without starting the state machine
+ * @dev: pointer to net_device claiming the phy
+ * @phy_np: Node pointer for the PHY
+ * @flags: flags to pass to the PHY
+ * @iface: PHY data interface type
+ */
+struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+ struct phy_device *phy = of_phy_find_device(phy_np);
+
+ if (!phy)
+ return NULL;
+
+ return phy_attach_direct(dev, phy, flags, iface) ? NULL : phy;
+}
+EXPORT_SYMBOL(of_phy_attach);
diff --git a/include/linux/of_mdio.h b/include/linux/of_mdio.h
index 8163107..dcda44d 100644
--- a/include/linux/of_mdio.h
+++ b/include/linux/of_mdio.h
@@ -19,6 +19,8 @@ extern struct phy_device *of_phy_connect(struct net_device
*dev,
struct device_node *phy_np,
void (*hndlr)(struct net_device *),
u32 flags, phy_interface_t iface);
+extern struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface);
extern struct phy_device *of_phy_connect_fixed_link(struct net_device *dev,
void (*hndlr)(struct net_device *),
phy_interface_t iface);
@@ -44,6 +46,12 @@ static inline struct phy_device *of_phy_connect(struct
net_device *dev,
return NULL;
}
+static inline struct phy_device *of_phy_attach(struct net_device *dev,
+ struct device_node *phy_np, u32 flags, phy_interface_t iface)
+{
+ return NULL;
+}
+
static inline struct phy_device *of_phy_connect_fixed_link(struct net_device
*dev,
void (*hndlr)(struct
net_device *),
phy_interface_t
iface)
--
1.8.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: typo in dts: interupt (four devices)
These lines were inoperative for four years, which puts some doubt into
their importance, and it's possible the fixed version will regress, but
at the very least they should be removed instead.
Signed-off-by: Adam Borowski kilob...@angband.pl
---
arch/powerpc/boot/dts/xcalibur1501.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/xcalibur1501.dts
b/arch/powerpc/boot/dts/xcalibur1501.dts
index cc00f4d..f151426 100644
--- a/arch/powerpc/boot/dts/xcalibur1501.dts
+++ b/arch/powerpc/boot/dts/xcalibur1501.dts
@@ -637,14 +637,14 @@
tlu@2f000 {
compatible = fsl,mpc8572-tlu, fsl_tlu;
reg = 0x2f000 0x1000;
- interupts = 61 2 ;
+ interrupts = 61 2 ;
interrupt-parent = mpic;
};
tlu@15000 {
compatible = fsl,mpc8572-tlu, fsl_tlu;
reg = 0x15000 0x1000;
- interupts = 75 2;
+ interrupts = 75 2;
interrupt-parent = mpic;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5301.dts
b/arch/powerpc/boot/dts/xpedite5301.dts
index 53c1c6a..d00fe16 100644
--- a/arch/powerpc/boot/dts/xpedite5301.dts
+++ b/arch/powerpc/boot/dts/xpedite5301.dts
@@ -547,14 +547,14 @@
tlu@2f000 {
compatible = fsl,mpc8572-tlu, fsl_tlu;
reg = 0x2f000 0x1000;
- interupts = 61 2 ;
+ interrupts = 61 2 ;
interrupt-parent = mpic;
};
tlu@15000 {
compatible = fsl,mpc8572-tlu, fsl_tlu;
reg = 0x15000 0x1000;
- interupts = 75 2;
+ interrupts = 75 2;
interrupt-parent = mpic;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5330.dts
b/arch/powerpc/boot/dts/xpedite5330.dts
index 2152259..e506554 100644
--- a/arch/powerpc/boot/dts/xpedite5330.dts
+++ b/arch/powerpc/boot/dts/xpedite5330.dts
@@ -583,14 +583,14 @@
tlu@2f000 {
compatible = fsl,mpc8572-tlu, fsl_tlu;
reg = 0x2f000 0x1000;
- interupts = 61 2 ;
+ interrupts = 61 2 ;
interrupt-parent = mpic;
};
tlu@15000 {
compatible = fsl,mpc8572-tlu, fsl_tlu;
reg = 0x15000 0x1000;
- interupts = 75 2;
+ interrupts = 75 2;
interrupt-parent = mpic;
};
};
diff --git a/arch/powerpc/boot/dts/xpedite5370.dts
b/arch/powerpc/boot/dts/xpedite5370.dts
index 11dbda1..9f1c608 100644
--- a/arch/powerpc/boot/dts/xpedite5370.dts
+++ b/arch/powerpc/boot/dts/xpedite5370.dts
@@ -545,14 +545,14 @@
tlu@2f000 {
compatible = fsl,mpc8572-tlu, fsl_tlu;
reg = 0x2f000 0x1000;
- interupts = 61 2 ;
+ interrupts = 61 2 ;
interrupt-parent = mpic;
};
tlu@15000 {
compatible = fsl,mpc8572-tlu, fsl_tlu;
reg = 0x15000 0x1000;
- interupts = 75 2;
+ interrupts = 75 2;
interrupt-parent = mpic;
};
};
--
1.8.5.rc0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: don't init the mpic ipi for the SoC which has doorbell support
On Sat, 2013-11-09 at 14:43 +0800, Kevin Hao wrote:
On Fri, Nov 08, 2013 at 03:16:12PM -0600, Scott Wood wrote:
OK... Why are you splitting out smp_85xx_basic_setup()?
In the current implementation of smp_85xx_setup_cpu(), we only invoke
the function mpic_setup_this_cpu() when the smp_85xx_ops.probe is set
to smp_mpic_probe(). So if we set smp_85xx_ops.probe to NULL when doorbell
is available, we must make sure that the mpic_setup_this_cpu() is also invoked
when there does have a mpic. The smp_85xx_basic_setup() is for the board which
has no mpic.
static void smp_85xx_setup_cpu(int cpu_nr)
{
if (smp_85xx_ops.probe == smp_mpic_probe)
mpic_setup_this_cpu();
if (cpu_has_feature(CPU_FTR_DBELL))
doorbell_setup_this_cpu();
}
Where do you
call it other than from smp_85xx_setup_cpu()?
We would set the .setup_cpu() to smp_85xx_basic_setup() if it is a
non-mpic board. The following is quoted form the patch:
np = of_find_node_by_type(NULL, open-pic);
if (np) {
smp_85xx_ops.probe = smp_mpic_probe;
+ smp_85xx_ops.setup_cpu = smp_85xx_setup_cpu;
smp_85xx_ops.message_pass = smp_mpic_message_pass;
- }
+ } else
+ smp_85xx_ops.setup_cpu = smp_85xx_basic_setup;
OK, somehow I missed the change to .setup_cpu before. :-P
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
On Mon, Nov 11, 2013 at 1:12 AM, Hongbo Zhang
hongbo.zh...@freescale.com wrote:
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) {
Isn't it a bit fragile to have this based on the resource address?
Can't device tree tell you the channel id directly by an index into
the dma0: dma@100300 node?
Yes, both this way and putting a cell-index into device tree work.
This won't be fragile, because the resource address should always be defined
correctly, otherwise even if we can tell a channel id by cell-index but
with wrong resource address, nothing will work.
This piece of code only doesn't seem as neat as using cell-index, but we
prefer the style that let the device tree describes as true as what hardware
really has. This doesn't mean cell-index isn't acceptable, if it is
necessary and unavoidable, we can send another patch to add it, but
currently there is no need and we don't have to do this.
I'm pointing it out because we just had a bug fix to another driver
motivated by the fact that resource addresses may move from one
implementation to another, whereas the cell index provided by device
tree is static. Just a note, no need to fix it now.
--
Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
Hi Linus ! Now that you've proven that even a typhoon can't get you, let's start throwing code at you again ! The bulk of this is LE updates. One should now be able to build an LE kernel and even run some things in it. I'm still sitting on a handful of patches to enable the new ABI that I *might* still send this merge window around, but due to the incertainty (they are pretty fresh) I want to keep them separate. Other notable changes are some infrastructure bits to better handle PCI pass-through under KVM, some bits and pieces added to the new PowerNV platform support such as access to the CPU SCOM bus via sysfs, and support for EEH error handling on PHB3 (Power8 PCIe). We also grew arch_get_random_long() for both pseries and powernv when running on P7+ and P8, exploiting the HW rng. And finally various embedded updates from freescale. Cheers, Ben. The following changes since commit 8b5ede69d24db939f52b47e2f6fe1e83e08b: powerpc/irq: Don't switch to irq stack from softirq stack (2013-10-07 14:19:39 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next for you to fetch changes up to 0c4888ef1d8a8b82c29075ce7e257ff795af15c7: powerpc: Fix fatal SLB miss when restoring PPR (2013-11-06 14:13:53 +1100) Alexey Kardashevskiy (3): hashtable: add hash_for_each_possible_rcu_notrace() powerpc: Prepare to support kernel handling of IOMMU map/unmap powerpc: add real mode support for dma operations on powernv Alistair Popple (5): powerpc: Little endian fixes for platforms/powernv/opal.c powerpc: Little endian fix for arch/powerpc/platforms/powernv/pci.c powerpc: Little endian fix for arch/powerpc/platforms/powernv/pci-p5ioc2.c powerpc: Little endian sparse clean up for arch/powerpc/platforms/powernv/pci-ioda.c powerpc: Fix 64K page size support for PPC44x Anatolij Gustschin (1): powerpc/52xx: fix build breakage for MPC5200 LPBFIFO module Anton Blanchard (30): powerpc: Fix endian issues in VMX copy loops powerpc: Book 3S MMU little endian support powerpc: Fix offset of FPRs in VSX registers in little endian builds powerpc: PTRACE_PEEKUSR/PTRACE_POKEUSER of FPR registers in little endian builds powerpc: Little endian builds double word swap VSX state during context save/restore powerpc: Add little endian support for word-at-a-time functions powerpc: Set MSR_LE bit on little endian builds powerpc: Reset MSR_LE on signal entry powerpc: Remove open coded byte swap macro in alignment handler powerpc: Remove hard coded FP offsets in alignment handler powerpc: Alignment handler shouldn't access VSX registers with TS_FPR powerpc: Add little endian support to alignment handler powerpc: Handle VSX alignment faults in little endian mode powerpc: Use generic checksum code in little endian powerpc: Use generic memcpy code in little endian powerpc: uname should return ppc64le/ppcle on little endian builds powerpc/powernv: More little endian issues in OPAL RTC driver powerpc/powernv: Fix some PCI sparse errors and one LE bug KVM: PPC: Disable KVM on little endian builds powerpc: Don't set HAVE_EFFICIENT_UNALIGNED_ACCESS on little endian builds powerpc: Work around little endian gcc bug powerpc: Fix little endian issue in OF PCI scan powerpc/pseries: Fix endian issues in pseries iommu code powerpc/pseries: Fix dedicated processor partition detection powerpc: Use -mcpu=power7 on ppc64 little endian builds powerpc: sync ppc64, ppc64e and pseries configs powerpc: Enable multipath modules on ppc64 and pseries powerpc: Enable virtio on ppc64 and pseries configs powerpc: Use 32 bit loads and stores when operating on condition register values powerpc: Add VMX optimised xor for RAID5 Bartlomiej Zolnierkiewicz (2): powerpc/legacy_serial: Fix incorrect placement of __initdata tag powerpc/8xx/tqm8xx: Fix incorrect placement of __initdata tag Benjamin Herrenschmidt (26): powerpc: Endian safe trampoline powerpc/powernv: Fix endian issues in OPAL RTC driver powerpc/powernv: Fix endian issues in OPAL ICS backend powerpc/powernv: Make OPAL NVRAM device tree accesses endian safe powerpc/powernv: Fix endian issues in powernv PCI code powerpc/powernv: Fix endian issues in OPAL console and udbg backend powerpc/powernv: Fix OPAL entry and exit in little endian mode powerpc/powernv: Don't register exception handlers in little endian mode powerpc/hvsi: Fix endian issues in HVSI driver tty/hvc_opal: powerpc: Make OPAL HVC device tree accesses endian safe powerpc: Enable /dev/port when isa_io_special is set powerpc/scom: Change scom_read() and scom_write() to return errors powerpc/scom:
RE: [PATCH v6] clk: corenet: Adds the clock binding
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -0,0 +1,123 @@
+* Clock Block on Freescale CoreNet Platforms
+
+Freescale CoreNet chips take primary clocking input from the external
+SYSCLK signal. The SYSCLK input (frequency) is multiplied using
+multiple phase locked loops (PLL) to create a variety of frequencies
+which can then be passed to a variety of internal logic, including
+cores and peripheral IP blocks.
+Please refer to the Reference Manual for details.
+
+1. Clock Block Binding
+
+Required properties:
+- compatible: Should include one or more of the following:
When you say one or more, I assume you mean of the specific clock block
strings, and then a chassis string?
If so, it might be better to say smoething like:
- compatible: Should contain a specific clock block compatible string
and a single chassis clock compatible string.
Clock block strings include:
* fsl,p2041-clockgen
* fsl,p3041-clockgen
Chassis clock strings include:
* fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks
* fsl,qoriq-clockgen-2.0: for chassis 2.0 clock
Sounds better.
+ * fsl,chip-clockgen: for chip specific clock block, here chip
+ could be but not limited to one of the: p2041, p3041, p4080,
+ p5020, p5040, t4240, b4420, b4860
+ * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks
+ * fsl,qoriq-clockgen-2.0: for chassis 2.0 clocks
+ Notes that fsl,qoriq-clockgen-1.0 and fsl,qoriq-clockgen-2.0
+ cannot be included simultaneously.
+- reg: Offset and length of the clock register set
+
+Recommended properties:
+- ranges: Allows valid translation between child's address space and
+ parent's. Must be present if the device has sub-nodes.
+- #address-cells: Specifies the number of cells used to represent
+ physical base addresses. Must be present if the device has
+ sub-nodes and set to 1 if present
+- #size-cells: Specifies the number of cells used to represent
+ the size of an address. Must be present if the device has
+ sub-nodes and set to 1 if present
Is there any particular reason these _must_ be 1?
They are one u32 variable long and no other options, so, they should be set to
1.
+
+2. Clock Provider/Consumer Binding
+
+Most of the bindings are from the common clock binding[1].
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : Should include one of the following:
+ * fsl,qoriq-core-pll-1.0 for core PLL clocks (v1.0)
+* fsl,qoriq-core-pll-2.0 for core PLL clocks (v2.0)
+* fsl,qoriq-core-mux-1.0 for core mux clocks (v1.0)
+* fsl,qoriq-core-mux-2.0 for core mux clocks (v2.0)
+ * fsl,qoriq-sysclk-1.0: for input system clock (v1.0)
+ * fsl,qoriq-sysclk-2.0: for input system clock (v2.0)
+- #clock-cells: From common clock binding; indicates the number of
+ output clock. 0 is for fsl,qoriq-sysclk-[1,2].0 and
+ fsl,qoriq-core-mux-[1,2].0; 1 for fsl,qoriq-core-pll-[1,2].0.
Nit: #clock-cells defines the number of cells in a clock-specifier, not
the number of output clocks. How about:
- #clock-cells: The number of cells in a clock-specifier. Should be 0
for fsl,qoriq-sysclk-[1,2].0 clocks, or 1 for
fsl,qoriq-core-pll-[1,2].0 clocks.
+ If #clock-cells has a value of 1, its clock consumer should specify
+ the desired clock by having the clock ID in its clocks phandle
+ cell. The following is a full list IDs:
The ID is in the clock-specifier, not the phandle. How about the
following instead:
For fsl,qoriq-core-pll-[1,2].0 clocks, the single clock-specifier cell
may take the following values:
OK, thanks.
+ * 0 - equal to the PLL frequency
+ * 1 - equal to the PLL frequency divided by 2
+ * 2 - equal to the PLL frequency divided by 4
+
+Recommended properties:
+- clocks: Should be the phandle of input parent clock
+- clock-names: From common clock binding, indicates the clock name
Is this not well defined and common across all of the clocks? The set of
inputs they have must be well known, and if it isn't then this property
isn't all that useful.
+- clock-output-names: From common clock binding, indicates the names
of
+ output clocks
Similarly, I'd expect that there might be well defined output names.
The clock-output-names and clock-names vary both from nodes to nodes and
from platforms to platforms. There is no general rules to define it.
I think the *-names properties should be added easily by following the example
below.
+- reg: Should be the offset and length of clock block base address.
+ The length should be 4.
+
+Example for clock block and clock provider:
+/ {
+ clockgen: global-utilities@e1000 {
+ compatible = fsl,p5020-clockgen, fsl,qoriq-clockgen-1.0;
+ ranges = 0x0 0xe1000 0x1000;
+ reg = 0xe1000 0x1000;
+
Re: [PATCH] powerpc: add explicit OF includes for ppc4xx
On Sun, Nov 10, 2013 at 11:35:43PM -0600, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com Commit b5b4bb3f6a11f9 (of: only include prom.h on sparc) removed implicit includes of of_*.h headers by powerpc's prom.h. Some PPC4xx components were missed in initial clean-up patch, so add the necessary includes to fix ppc4xx builds. Signed-off-by: Rob Herring rob.herr...@calxeda.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Tejun Heo t...@kernel.org Cc: Matt Mackall m...@selenic.com Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Cc: Vinod Koul vinod.k...@intel.com Cc: Dan Williams dan.j.willi...@intel.com Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-...@vger.kernel.org Cc: linux-cry...@vger.kernel.org --- I intend to send this patch to Linus with the rest of the DT clean-up series. Rob arch/powerpc/sysdev/ppc4xx_ocm.c | 1 + arch/powerpc/sysdev/xilinx_intc.c| 1 + drivers/ata/sata_dwc_460ex.c | 2 ++ drivers/char/hw_random/ppc4xx-rng.c | 1 + drivers/crypto/amcc/crypto4xx_core.c | 3 +++ drivers/dma/ppc4xx/adma.c| 2 ++ For this: Acked-by Vinod Koul vinod.k...@intel.com -- ~Vinod 6 files changed, 10 insertions(+) diff --git a/arch/powerpc/sysdev/ppc4xx_ocm.c b/arch/powerpc/sysdev/ppc4xx_ocm.c index 1b15f93..b7c4345 100644 --- a/arch/powerpc/sysdev/ppc4xx_ocm.c +++ b/arch/powerpc/sysdev/ppc4xx_ocm.c @@ -26,6 +26,7 @@ #include linux/kernel.h #include linux/dma-mapping.h #include linux/of.h +#include linux/of_address.h #include asm/rheap.h #include asm/ppc4xx_ocm.h #include linux/slab.h diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c index f4fdc94..83f943a 100644 --- a/arch/powerpc/sysdev/xilinx_intc.c +++ b/arch/powerpc/sysdev/xilinx_intc.c @@ -24,6 +24,7 @@ #include linux/irq.h #include linux/of.h #include linux/of_address.h +#include linux/of_irq.h #include asm/io.h #include asm/processor.h #include asm/i8259.h diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c index 2e39173..523524b 100644 --- a/drivers/ata/sata_dwc_460ex.c +++ b/drivers/ata/sata_dwc_460ex.c @@ -31,6 +31,8 @@ #include linux/module.h #include linux/init.h #include linux/device.h +#include linux/of_address.h +#include linux/of_irq.h #include linux/of_platform.h #include linux/platform_device.h #include linux/libata.h diff --git a/drivers/char/hw_random/ppc4xx-rng.c b/drivers/char/hw_random/ppc4xx-rng.c index 732c330..521f76b 100644 --- a/drivers/char/hw_random/ppc4xx-rng.c +++ b/drivers/char/hw_random/ppc4xx-rng.c @@ -13,6 +13,7 @@ #include linux/platform_device.h #include linux/hw_random.h #include linux/delay.h +#include linux/of_address.h #include linux/of_platform.h #include asm/io.h diff --git a/drivers/crypto/amcc/crypto4xx_core.c b/drivers/crypto/amcc/crypto4xx_core.c index f88e3d8..efaf630 100644 --- a/drivers/crypto/amcc/crypto4xx_core.c +++ b/drivers/crypto/amcc/crypto4xx_core.c @@ -27,6 +27,9 @@ #include linux/dma-mapping.h #include linux/platform_device.h #include linux/init.h +#include linux/module.h +#include linux/of_address.h +#include linux/of_irq.h #include linux/of_platform.h #include linux/slab.h #include asm/dcr.h diff --git a/drivers/dma/ppc4xx/adma.c b/drivers/dma/ppc4xx/adma.c index 370ff82..e24b5ef 100644 --- a/drivers/dma/ppc4xx/adma.c +++ b/drivers/dma/ppc4xx/adma.c @@ -42,6 +42,8 @@ #include linux/uaccess.h #include linux/proc_fs.h #include linux/of.h +#include linux/of_address.h +#include linux/of_irq.h #include linux/of_platform.h #include asm/dcr.h #include asm/dcr-regs.h -- 1.8.1.2 -- ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Mon, Oct 28, 2013 at 05:58:42AM +, Xiubo Li-B47053 wrote:
Hi Dan, Vinod,
+static int fsl_sai_probe(struct platform_device *pdev) {
[...]
+
+ sai-dma_params_rx.addr = res-start + SAI_RDR;
+ sai-dma_params_rx.maxburst = 6;
+ index = of_property_match_string(np, dma-names, rx);
+ ret = of_parse_phandle_with_args(np, dmas, #dma-cells, index,
+ dma_args);
+ if (ret)
+ return ret;
+ sai-dma_params_rx.slave_id = dma_args.args[1];
+
+ sai-dma_params_tx.addr = res-start + SAI_TDR;
+ sai-dma_params_tx.maxburst = 6;
+ index = of_property_match_string(np, dma-names, tx);
+ ret = of_parse_phandle_with_args(np, dmas, #dma-cells, index,
+ dma_args);
+ if (ret)
+ return ret;
+ sai-dma_params_tx.slave_id = dma_args.args[1];
The driver should not have to manually parse the dma devicetree
properties, this is something that should be handled by the dma engine
driver.
What do you think about the DMA slave_id ?
I have been noticed by one colleague that this should be parsed here, which
is from your opinions ?
Sure slave_id can be parsed here, but IMO it should be programmed via the
dma_slave_confog into the respective channel
--
~Vinod
+
+ ret = snd_soc_register_component(pdev-dev, fsl_component,
+ fsl_sai_dai, 1);
+ if (ret)
+ return ret;
+
+ ret = fsl_pcm_dma_init(pdev);
+ if (ret)
+ goto out;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridges
On PHB3, we will fail to fetch IODA tables without PCI_COMMAND_MASTER on PCI bridges. According to one experiment I had, the MSIx interrupts didn't raise from the adapter without the bit applied to all upstream PCI bridges including root port of the adapter. The patch forces to have that bit enabled accordingly. Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com --- arch/powerpc/kernel/eeh.c |9 + 1 file changed, 9 insertions(+) diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c index 1fb331d..180af13 100644 --- a/arch/powerpc/kernel/eeh.c +++ b/arch/powerpc/kernel/eeh.c @@ -687,6 +687,15 @@ void eeh_save_bars(struct eeh_dev *edev) for (i = 0; i 16; i++) eeh_ops-read_config(dn, i * 4, 4, edev-config_space[i]); + + /* +* For PCI bridges including root port, we need enable bus +* master explicitly. Otherwise, it can't fetch IODA table +* entries correctly. So we cache the bit in advance so that +* we can restore it after reset, either PHB range or PE range. +*/ + if (edev-mode EEH_DEV_BRIDGE) + edev-config_space[1] |= PCI_COMMAND_MASTER; } /** -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/eeh: More accurate log
We possibly has fenced PHB except frozen PE. So the output log
doesn't cover all cases and the patch fixes it.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/kernel/eeh_event.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_event.c b/arch/powerpc/kernel/eeh_event.c
index d27c5af..72d748b 100644
--- a/arch/powerpc/kernel/eeh_event.c
+++ b/arch/powerpc/kernel/eeh_event.c
@@ -74,8 +74,13 @@ static int eeh_event_handler(void * dummy)
pe = event-pe;
if (pe) {
eeh_pe_state_mark(pe, EEH_PE_RECOVERING);
- pr_info(EEH: Detected PCI bus error on PHB#%d-PE#%x\n,
-pe-phb-global_number, pe-addr);
+ if (pe-type EEH_PE_PHB)
+ pr_info(EEH: Detected error on PHB#%d\n,
+pe-phb-global_number);
+ else
+ pr_info(EEH: Detected PCI bus error on
+ PHB#%d-PE#%x\n,
+ pe-phb-global_number, pe-addr);
eeh_handle_event(pe);
eeh_pe_state_clear(pe, EEH_PE_RECOVERING);
} else {
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
On 11/12/2013 08:09 AM, Dan Williams wrote:
On Mon, Nov 11, 2013 at 1:12 AM, Hongbo Zhang
hongbo.zh...@freescale.com wrote:
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) {
Isn't it a bit fragile to have this based on the resource address?
Can't device tree tell you the channel id directly by an index into
the dma0: dma@100300 node?
Yes, both this way and putting a cell-index into device tree work.
This won't be fragile, because the resource address should always be defined
correctly, otherwise even if we can tell a channel id by cell-index but
with wrong resource address, nothing will work.
This piece of code only doesn't seem as neat as using cell-index, but we
prefer the style that let the device tree describes as true as what hardware
really has. This doesn't mean cell-index isn't acceptable, if it is
necessary and unavoidable, we can send another patch to add it, but
currently there is no need and we don't have to do this.
I'm pointing it out because we just had a bug fix to another driver
motivated by the fact that resource addresses may move from one
implementation to another, whereas the cell index provided by device
tree is static. Just a note, no need to fix it now.
Get it, and will remember it, thank you Dan.
--
Dan
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
+static int fsl_sai_probe(struct platform_device *pdev) {
[...]
+
+ sai-dma_params_rx.addr = res-start + SAI_RDR;
+ sai-dma_params_rx.maxburst = 6;
+ index = of_property_match_string(np, dma-names, rx);
+ ret = of_parse_phandle_with_args(np, dmas, #dma-cells,
index,
+ dma_args);
+ if (ret)
+ return ret;
+ sai-dma_params_rx.slave_id = dma_args.args[1];
+
+ sai-dma_params_tx.addr = res-start + SAI_TDR;
+ sai-dma_params_tx.maxburst = 6;
+ index = of_property_match_string(np, dma-names, tx);
+ ret = of_parse_phandle_with_args(np, dmas, #dma-cells,
index,
+ dma_args);
+ if (ret)
+ return ret;
+ sai-dma_params_tx.slave_id = dma_args.args[1];
The driver should not have to manually parse the dma devicetree
properties, this is something that should be handled by the dma
engine driver.
What do you think about the DMA slave_id ?
I have been noticed by one colleague that this should be parsed here,
which is from your opinions ?
Sure slave_id can be parsed here, but IMO it should be programmed via the
dma_slave_confog into the respective channel
Actually, these are parsed for cpu_dai-playback_dma_data and
cpu_dai-capture_dma_data dynamically, whose type is struct dma_slave_config.
And now I must parse them here, because the platform eDMA driver's newest
version will check and use the slave_ids to select and configure the eDMA
channels via dma_device-device_control().
--
Xiubo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BookE branch taken behavior vis-a-vis updating the NIP register
I re-read the link you posted earlier and this time it made more sense to me. The kind of questions which are coming into my mind were being discussed. So, off I went and downloaded the latest version of arch/powerpc/kernel/traps.c hoping to see those very changes in them. However it didn't match one on one with what was written in that thread. Ditto for the other files in your patch. Looks like your patch didn't make it to upstream but it looks exactly like what I need here. So allow me to discuss certain finer points of it, to make sure I understand what it does correctly. In that thread you say James Yang wrote BookE ISA's branch taken exception triggers before a branch that will be taken executes. This allows software to examine the branch and the conditions under which it will be taken. It also means software can tell where basic blocks end (at least the ones which are terminated by taken branches). * There are no architected registers that report the address of the branch instruction after it has executed. * My thoughts exactly! In the first patch's description, you say James Yang wrote This patch makes available the unmodified BookE branch taken debug exception through PTRACE_SINGLEBLOCK if the ptrace() addr parameter is set to 2. (The existing behavior of PTRACE_SINGLEBLOCK is retained for any other addr parameter value, e.g., 0.) * SIGTRAP will be signaled with the NIP pointing to the branch instruction before it has executed. The ptrace-calling program can then examine the program state. * / It should then request a PTRACE_SINGLESTEP in order to advance the program to the next instruction or a PTRACE_CONT to resume normal program execution. / The si_code now also reports TRAP_BRANCH. So requesting PTRACE_CONT has to happen inside the SIGTRAP signal handler right? So as to advance the branch instruction (and since we are talking BookE here, we are dead sure this branch will be taken). Now as for the second patch, as far as I can see, implements the same functionality. However it makes the change permanent and any tool which is used to the NIP pointing to the branch target will be broken. Anyways, for me either of them will work. But I think the first patch makes everyone happy by using the 'addr' field of ptrace. This also means I will have to make my (broken) ptrace working which, it seems is not as easy adding an enum field as you suggested. May be theres a check somewhere in the actual ptrace code which checks for illegal values and hence even after adding an enum, it is being reported as illegal in my case. However getting that to work is another story. Please confirm my understanding of your patches and since these patches have not made their way to the upstream kernel, will have to use them myself directly. By the way, I'm using 2.6.32.10 (you know..the long-term kernel) and I couldn't find any of your changes in them but then again I couldn't find it in the latest 3.12 version either. -- View this message in context: http://linuxppc.10917.n7.nabble.com/BookE-branch-taken-behavior-vis-a-vis-updating-the-NIP-register-tp77960p78036.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
