Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine

2013-11-11 Thread Hongbo Zhang

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

2013-11-11 Thread hongbo.zhang
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

2013-11-11 Thread hongbo.zhang
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

2013-11-11 Thread Yuantian.Tang
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

2013-11-11 Thread hongbo.zhang
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

2013-11-11 Thread hongbo.zhang
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

2013-11-11 Thread Claudiu Manoil

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

2013-11-11 Thread Mark Rutland
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

2013-11-11 Thread Aneesh Kumar K.V
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

2013-11-11 Thread Aneesh Kumar K.V
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

2013-11-11 Thread Aneesh Kumar K.V
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

2013-11-11 Thread Joseph S. Myers
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

2013-11-11 Thread Lijun Pan
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

2013-11-11 Thread Gerhard Sittig
[ 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

2013-11-11 Thread Gerhard Sittig
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

2013-11-11 Thread James Yang
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

2013-11-11 Thread shh.xie
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

2013-11-11 Thread shh.xie
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

2013-11-11 Thread shh.xie
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

2013-11-11 Thread shh.xie
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)

2013-11-11 Thread Adam Borowski
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

2013-11-11 Thread Scott Wood
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

2013-11-11 Thread Dan Williams
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

2013-11-11 Thread Benjamin Herrenschmidt
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

2013-11-11 Thread Yuantian Tang
  +++ 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

2013-11-11 Thread Vinod Koul
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.

2013-11-11 Thread Vinod Koul
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

2013-11-11 Thread Gavin Shan
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

2013-11-11 Thread Gavin Shan
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

2013-11-11 Thread Hongbo Zhang

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.

2013-11-11 Thread Li Xiubo
+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

2013-11-11 Thread pegasus
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