from:"Gregory CLEMENT"

[PATCH V4 0/3] Add clock framework for armada 370/XP

2012-10-30 Thread Gregory CLEMENT

Hello Mike,

I hope this 4th version will meet your expectations. Beside the
corrections you have asked I also changed the way I get resources for
the clocks. Instead of referring to a node name, now I refer to a
compatible name which should be a better use of the device tree.

Rather than taking this series in your git tree, would it possible to
give your ack to the patches and let Jason Cooper take the patch set
in his git tree. We have other series for mvebu which depend on this
one (SMP, HWIOCC and SATA for now and more to come), and it will be
easier for us to have everything in the same place.

The purpose of this patch set is to add support for clock framework
for Armada 370 and Armada XP SoCs. All the support is done under the
directory drivers/clk/mvebu/ as the support for other mvebu SoCs was
in mind during the writing of the code.

Two kinds of clocks are added:

- The CPU clocks are only for Armada XP (which is multi-core)

- The core clocks are clocks which have their rate fixed during
  reset.

Many thanks to Thomas Petazzoni and Sebastian Hesselbarth for their
review and feedback. The device tree bindings were really improved
with the advices of Sebastian.

Changelog:
V3 - V4
- Rebased on top of 3.7-rc3
- Replaced the whitespace by tab in the Documentation files
- Fixed the comment style according to the CodingStyle documentation
- Fixed incorrect indentation
- Removed redundant header in clk-cpu.c
- Replaced improper whitespace by tabs in armada-xp.dtsi
- In the device tree, the resources for the clocks do not rely anymore
  on the node name mvebu-sar but now only depend on the compatible
  name. (Issue reported by Sebastian Hesselbarth)

V2 - V3:
- Rebased on top of v3.7-rc1
- Fixed a typo in device trees
- Fixed warning from checkpatch

V1 - V2:
- Improved the spelling and the wording of the documentation and the
  1st commit log
- Removed the end_of_list name which are unused here.
- Fix the cpu clock by using of_clk_src_onecell_get in the same way it
  was used for the core clocks

Regards,


Gregory CLEMENT (3):
  clk: mvebu: add armada-370-xp specific clocks
  clk: armada-370-xp: add support for clock framework
  clocksource: time-armada-370-xp converted to clk framework

 .../devicetree/bindings/clock/mvebu-core-clock.txt |   40 +++
 .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   21 ++
 arch/arm/boot/dts/armada-370-db.dts|4 -
 arch/arm/boot/dts/armada-370-xp.dtsi   |1 +
 arch/arm/boot/dts/armada-370.dtsi  |   12 +
 arch/arm/boot/dts/armada-xp.dtsi   |   48 +++
 arch/arm/mach-mvebu/Kconfig|5 +
 arch/arm/mach-mvebu/armada-370-xp.c|8 +-
 arch/arm/mach-mvebu/common.h   |1 +
 drivers/clk/Makefile   |1 +
 drivers/clk/mvebu/Makefile |2 +
 drivers/clk/mvebu/clk-core.c   |  318 
 drivers/clk/mvebu/clk-core.h   |   19 ++
 drivers/clk/mvebu/clk-cpu.c|  154 ++
 drivers/clk/mvebu/clk-cpu.h|   19 ++
 drivers/clk/mvebu/clk.c|   36 +++
 drivers/clocksource/time-armada-370-xp.c   |   11 +-
 17 files changed, 690 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
 create mode 100644 drivers/clk/mvebu/Makefile
 create mode 100644 drivers/clk/mvebu/clk-core.c
 create mode 100644 drivers/clk/mvebu/clk-core.h
 create mode 100644 drivers/clk/mvebu/clk-cpu.c
 create mode 100644 drivers/clk/mvebu/clk-cpu.h
 create mode 100644 drivers/clk/mvebu/clk.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 3/3] clocksource: time-armada-370-xp converted to clk framework

2012-10-30 Thread Gregory CLEMENT

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
cc: John Stultz johns...@us.ibm.com
---
 arch/arm/boot/dts/armada-370-db.dts  |4 
 arch/arm/boot/dts/armada-370-xp.dtsi |1 +
 drivers/clocksource/time-armada-370-xp.c |   11 ++-
 3 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index fffd5c2..4a31b03 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -34,9 +34,5 @@
clock-frequency = 2;
status = okay;
};
-   timer@d0020300 {
-   clock-frequency = 6;
-   status = okay;
-   };
};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 16cc82c..94b4b9e 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -62,6 +62,7 @@
   compatible = marvell,armada-370-xp-timer;
   reg = 0xd0020300 0x30;
   interrupts = 37, 38, 39, 40;
+  clocks = coreclk 2;
};
 
addr-decoding@d002 {
diff --git a/drivers/clocksource/time-armada-370-xp.c 
b/drivers/clocksource/time-armada-370-xp.c
index 4674f94..a4605fd 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -18,6 +18,7 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/kernel.h
+#include linux/clk.h
 #include linux/timer.h
 #include linux/clockchips.h
 #include linux/interrupt.h
@@ -167,7 +168,6 @@ void __init armada_370_xp_timer_init(void)
u32 u;
struct device_node *np;
unsigned int timer_clk;
-   int ret;
np = of_find_compatible_node(NULL, NULL, marvell,armada-370-xp-timer);
timer_base = of_iomap(np, 0);
WARN_ON(!timer_base);
@@ -179,13 +179,14 @@ void __init armada_370_xp_timer_init(void)
   timer_base + TIMER_CTRL_OFF);
timer_clk = 2500;
} else {
-   u32 clk = 0;
-   ret = of_property_read_u32(np, clock-frequency, clk);
-   WARN_ON(!clk || ret  0);
+   unsigned long rate = 0;
+   struct clk *clk = of_clk_get(np, 0);
+   WARN_ON(IS_ERR(clk));
+   rate =  clk_get_rate(clk);
u = readl(timer_base + TIMER_CTRL_OFF);
writel(u  ~(TIMER0_25MHZ | TIMER1_25MHZ),
   timer_base + TIMER_CTRL_OFF);
-   timer_clk = clk / TIMER_DIVIDER;
+   timer_clk = rate / TIMER_DIVIDER;
}
 
/* We use timer 0 as clocksource, and timer 1 for
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V4 2/3] clk: armada-370-xp: add support for clock framework

2012-10-30 Thread Gregory CLEMENT

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370.dtsi   |   12 +
 arch/arm/boot/dts/armada-xp.dtsi|   48 +++
 arch/arm/mach-mvebu/Kconfig |5 
 arch/arm/mach-mvebu/armada-370-xp.c |8 +-
 arch/arm/mach-mvebu/common.h|1 +
 5 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index 2069151..ac495b4 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -75,5 +75,17 @@
#interrupts-cells = 2;
interrupts = 91;
};
+   coreclk: mvebu-sar@d0018230 {
+   #clock-cells = 1;
+   reg = 0xd0018230 0x08;
+   compatible = marvell,armada-370-core-clockctrl;
+   clock-output-names =
+   tclk, /* 0 */
+   pclk, /* 1 */
+   nbclk,/* 2 */
+   hclk, /* 3 */
+   dramclk;  /* 4 */
+   };
+
};
 };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 71d6b5d..8fd924a 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,35 @@
0xd0021870 0x58;
};
 
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   cpu@0 {
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
+
+   cpu@1 {
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
+
+   cpu@2 {
+   compatible = marvell,sheeva-v7;
+   reg = 2;
+   clocks = cpuclk 2;
+   };
+
+   cpu@3 {
+   compatible = marvell,sheeva-v7;
+   reg = 3;
+   clocks = cpuclk 3;
+   };
+   };
+
soc {
serial@d0012200 {
compatible = ns16550;
@@ -47,6 +76,25 @@
marvell,timer-25Mhz;
};
 
+   coreclk: mvebu-sar@d0018230 {
+   #clock-cells = 1;
+   reg = 0xd0018230 0x08;
+   compatible = marvell,armada-xp-core-clockctrl;
+   clock-output-names =
+   tclk, /* 0 */
+   pclk, /* 1 */
+   nbclk,/* 2 */
+   hclk, /* 3 */
+   dramclk;  /* 4 */
+   };
+
+   cpuclk: clock-complex@d0018700 {
+   #clock-cells = 1;
+   compatible = marvell,armada-xp-cpu-clockctrl;
+   reg = 0xd0018700 0xA0;
+   clocks = coreclk 1;
+   };
+
system-controller@d0018200 {
compatible = 
marvell,armada-370-xp-system-controller;
reg = 0xd0018200 0x500;
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 416d46e..17d246b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -9,11 +9,16 @@ config ARCH_MVEBU
select PINCTRL
select PLAT_ORION
select SPARSE_IRQ
+   select CLKDEV_LOOKUP
+   select MVEBU_CLK_CPU
 
 if ARCH_MVEBU
 
 menu Marvell SOC with device tree
 
+config MVEBU_CLK_CPU
+  bool
+
 config MACH_ARMADA_370_XP
bool
select ARMADA_370_XP_TIMER
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..2af6ce5 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -37,8 +37,14 @@ void __init armada_370_xp_map_io(void)
iotable_init(armada_370_xp_io_desc, ARRAY_SIZE(armada_370_xp_io_desc));
 }
 
+void __init armada_370_xp_timer_and_clk_init(void)
+{
+   mvebu_clocks_init();
+   armada_370_xp_timer_init();
+}
+
 struct sys_timer armada_370_xp_timer = {
-   .init   = armada_370_xp_timer_init,
+   .init   = armada_370_xp_timer_and_clk_init,
 };
 
 static void __init armada_370_xp_dt_init(void)
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 02f89ea..281fab3 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -16,6 +16,7 @@
 #define __ARCH_MVEBU_COMMON_H
 
 void mvebu_restart(char mode, const char *cmd);
+void mvebu_clocks_init(void);
 
 void armada_370_xp_init_irq(void);
 void armada_370_xp_handle_irq(struct pt_regs *regs);
-- 
1.7.9.5

--
To unsubscribe from this list: send

[PATCH V4 1/3] clk: mvebu: add armada-370-xp specific clocks

2012-10-30 Thread Gregory CLEMENT

Add Armada 370/XP specific clocks: core clocks and CPU clocks.

The CPU clocks are only for Armada XP for the SMP mode.

The core clocks are clocks which have their rate set during reset. The
code was written with the other SoCs of the mvebu family in
mind. Adding them should be pretty straight forward. For a new
SoC, only 3 binding have to be added:
- one to provide the tclk frequency
- one to provde the pclk frequency
- and one to provide the ratio between the pclk and the children
  clocks

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 .../devicetree/bindings/clock/mvebu-core-clock.txt |   40 +++
 .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   21 ++
 drivers/clk/Makefile   |1 +
 drivers/clk/mvebu/Makefile |2 +
 drivers/clk/mvebu/clk-core.c   |  318 
 drivers/clk/mvebu/clk-core.h   |   19 ++
 drivers/clk/mvebu/clk-cpu.c|  154 ++
 drivers/clk/mvebu/clk-cpu.h|   19 ++
 drivers/clk/mvebu/clk.c|   36 +++
 9 files changed, 610 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
 create mode 100644 drivers/clk/mvebu/Makefile
 create mode 100644 drivers/clk/mvebu/clk-core.c
 create mode 100644 drivers/clk/mvebu/clk-core.h
 create mode 100644 drivers/clk/mvebu/clk-cpu.c
 create mode 100644 drivers/clk/mvebu/clk-cpu.h
 create mode 100644 drivers/clk/mvebu/clk.c

diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt 
b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
new file mode 100644
index 000..eb54c62
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for core clock of Marvell EBU platforms
+
+This is the binding for the core clock of the mvebu SoCs, the rate
+of this clocks are fixed during reset. Their value or ratio are taken
+from the Sample at Reset(SAR) register.
+
+Required properties:
+- compatible : shall be one of the following:
+   marvell,armada-370-core-clockctrl - core clock for Armada 370
+   marvell,armada-xp-core-clockctrl - core clock for Armada XP
+- reg : Address and length of the SAR register set
+- #clock-cells : should be set to 1.
+- clock-output-names: A list of clock output names that mvebu core
+  clocks provides.  The full list of all valid clock names, IDs and
+  description are below.
+   NameID  Description
+   tclk0   Peripheral clock
+   pclk1   CPU clock
+   nbclk   2   L2 clock
+   hclk3   DRAM control clock
+   dramclk 4   DDR clock
+
+coreclk: mvebu-sar@d0018230 {
+   #clock-cells = 1;
+   reg = 0xd0018230 0x08;
+   compatible = marvell,armada-370-core-clockctrl;
+   clock-output-names =
+   tclk, /* 0 */
+   pclk, /* 1 */
+   nbclk,/* 2 */
+   hclk, /* 3 */
+   dramclk;  /* 4 */
+};
+
+timer@d0020300 {
+   compatible = marvell,armada-370-xp-timer;
+   reg = 0xd0020300 0x30;
+   interrupts = 37, 38, 39, 40;
+   clocks = coreclk 0;
+};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt 
b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
new file mode 100644
index 000..1fb5a64
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -0,0 +1,21 @@
+Device Tree Clock bindings for cpu clock of Marvell EBU platforms
+
+Required properties:
+- compatible : shall be one of the following:
+   marvell,armada-xp-cpu-clockctrl - cpu clocks for Armada XP
+- reg : Address and length of the clock complex register set
+- #clock-cells : should be set to 1.
+- clocks : shall be the input parent clock phandle for the clock.
+
+cpuclk: clock-complex@d0018700 {
+   #clock-cells = 1;
+   compatible = marvell,armada-xp-cpu-clockctrl;
+   reg = 0xd0018700 0xA0;
+   clocks = coreclk 1;
+}
+
+cpu@0 {
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71a25b9..9c91d6c 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_PLAT_SPEAR)  += spear/
 obj-$(CONFIG_ARCH_U300)+= clk-u300.o
 obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
 obj-$(CONFIG_ARCH_PRIMA2)  += clk-prima2.o
+obj-$(CONFIG_ARCH_MVEBU)   += mvebu/
 ifeq ($(CONFIG_COMMON_CLK), y)
 obj-$(CONFIG_ARCH_MMP) += mmp/
 endif
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
new file mode 100644
index 000..de94a87
--- /dev/null
+++ b/drivers/clk/mvebu/Makefile
@@ -0,0 +1,2 @@
+obj-y += clk.o clk-core.o
+obj

Re: [PATCH V3 0/3] Add clock framework for armada 370/XP

2012-10-21 Thread Gregory CLEMENT

On 10/17/2012 05:39 PM, Jason Cooper wrote:
 Mike,
 
 On Mon, Oct 15, 2012 at 02:18:16PM +0200, Gregory CLEMENT wrote:
 Hello Mike,

 The v3.7-rc1 was released yesterday. So here it is the updated version
 of my patch set. The rebase was flawless. An I have just fixed a typo
 in the device tree and warnings from checkpatch. I built and test it
 for the Armada 370 and Armada XP evaluation board.

 The purpose of this patch set is to add support for clock framework
 for Armada 370 and Armada XP SoCs. All the support is done under the
 directory drivers/clk/mvebu/ as the support for other mvebu SoCs was
 in mind during the writing of the code.

 Two kinds of clocks are added:

 - The CPU clocks are only for Armada XP (which is multi-core)

 - The core clocks are clocks which have their rate fixed during
   reset.

 Many thanks to Thomas Petazzoni and Sebastian Hesselbarth for their
 review and feedback. The device tree bindings were really improved
 with the advices of Sebastian.

 Changelog:
 V2 - V3:
 - Rebased on top of v3.7-rc1
 - Fixed a typo in device trees
 - Fixed warning from checkpatch

 V1 - V2:

 - Improved the spelling and the wording of the documentation and the
   1st commit log
 - Removed the end_of_list name which are unused here.
 - Fix the cpu clock by using of_clk_src_onecell_get in the same way it
   was used for the core clocks

 Regards,


 Gregory CLEMENT (3):
   clk: mvebu: add armada-370-xp specific clocks
   clk: armada-370-xp: add support for clock framework
   clocksource: time-armada-370-xp converted to clk framework

  .../devicetree/bindings/clock/mvebu-core-clock.txt |   40 +++
  .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   21 ++
  arch/arm/boot/dts/armada-370-db.dts|4 -
  arch/arm/boot/dts/armada-370-xp.dtsi   |1 +
  arch/arm/boot/dts/armada-370.dtsi  |   12 +
  arch/arm/boot/dts/armada-xp.dtsi   |   48 +++
  arch/arm/mach-mvebu/Kconfig|5 +
  arch/arm/mach-mvebu/armada-370-xp.c|8 +-
  arch/arm/mach-mvebu/common.h   |1 +
  drivers/clk/Makefile   |1 +
  drivers/clk/mvebu/Makefile |2 +
  drivers/clk/mvebu/clk-core.c   |  312 
 
  drivers/clk/mvebu/clk-core.h   |   19 ++
  drivers/clk/mvebu/clk-cpu.c|  155 ++
  drivers/clk/mvebu/clk-cpu.h|   19 ++
  drivers/clk/mvebu/clk.c|   36 +++
  drivers/clocksource/time-armada-370-xp.c   |   11 +-
  17 files changed, 685 insertions(+), 10 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
  create mode 100644 
 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
  create mode 100644 drivers/clk/mvebu/Makefile
  create mode 100644 drivers/clk/mvebu/clk-core.c
  create mode 100644 drivers/clk/mvebu/clk-core.h
  create mode 100644 drivers/clk/mvebu/clk-cpu.c
  create mode 100644 drivers/clk/mvebu/clk-cpu.h
  create mode 100644 drivers/clk/mvebu/clk.c
 
 Would it be okay if we took this through the mvebu tree?  It looks like
 the only potential merge conflict we would have would be in
 drivers/clk/Makefile.  It would make dependency tracking easier.
 

It will also be easier for me if it was possible, because I have
patch series awaiting which will depend on the support of the
clock framework for mvebu.

 Otherwise is fine as well, just let me know which you prefer.
 
 Assuming, of course, everything looks good to you.
 
 thx,
 
 Jason.
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm: plat-orion: Add coherency attribute when setup mbus target

2012-10-24 Thread Gregory CLEMENT

Recent SoC such as Armada 370/XP came with the possibility to deal
with the I/O coherency by hardware. In this case the transaction
attribute of the window must be flagged as Shared transaction. Once
this flag is set, then the transactions will be forced to be sent
through the coherency block, in other case transaction is driven
directly to DRAM.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Reviewed-by: Yehuda Yitschak yehu...@marvell.com
---
 arch/arm/plat-orion/addr-map.c  |4 
 arch/arm/plat-orion/include/plat/addr-map.h |1 +
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/plat-orion/addr-map.c b/arch/arm/plat-orion/addr-map.c
index a7b8060..febe386 100644
--- a/arch/arm/plat-orion/addr-map.c
+++ b/arch/arm/plat-orion/addr-map.c
@@ -42,6 +42,8 @@ EXPORT_SYMBOL_GPL(mv_mbus_dram_info);
 #define WIN_REMAP_LO_OFF   0x0008
 #define WIN_REMAP_HI_OFF   0x000c
 
+#define ATTR_HW_COHERENCY  (0x1  4)
+
 /*
  * Default implementation
  */
@@ -163,6 +165,8 @@ void __init orion_setup_cpu_mbus_target(const struct 
orion_addr_map_cfg *cfg,
w = orion_mbus_dram_info.cs[cs++];
w-cs_index = i;
w-mbus_attr = 0xf  ~(1  i);
+   if (cfg-hw_io_coherency)
+   w-mbus_attr |= ATTR_HW_COHERENCY;
w-base = base  0x;
w-size = (size | 0x) + 1;
}
diff --git a/arch/arm/plat-orion/include/plat/addr-map.h 
b/arch/arm/plat-orion/include/plat/addr-map.h
index ec63e4a..b76c065 100644
--- a/arch/arm/plat-orion/include/plat/addr-map.h
+++ b/arch/arm/plat-orion/include/plat/addr-map.h
@@ -17,6 +17,7 @@ struct orion_addr_map_cfg {
const int num_wins; /* Total number of windows */
const int remappable_wins;
void __iomem *bridge_virt_base;
+   int hw_io_coherency;
 
/* If NULL, the default cpu_win_can_remap will be used, using
   the value in remappable_wins */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support

2012-10-24 Thread Gregory CLEMENT

Armada 370 and XP come with an unit called coherency fabric. This unit
allows to use the Armada XP as a nearly coherent architecture. The
coherency mechanism uses snoop filters to ensure the coherency between
caches, DRAM and devices. This mechanism needs a synchronization
barrier which guarantees that all memory write initiated by the
devices has reached their target and do not reside in intermediate
write buffers. That's why the architecture is not totally coherent and
we need to provide our own functions for some DMA operations.

Beside the use of the coherency fabric, the device units will have to
set the attribute flag to select the accurate coherency process for
the memory transaction. This is done each device driver programs the
DRAM address windows. The value of the attribute set by the driver is
retrieved through the orion_addr_map_cfg struct filled during the
early initialization of the platform.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Reviewed-by: Yehuda Yitschak yehu...@marvell.com
---
 arch/arm/boot/dts/armada-370-xp.dtsi |3 +-
 arch/arm/mach-mvebu/addr-map.c   |3 ++
 arch/arm/mach-mvebu/armada-370-xp.c  |1 +
 arch/arm/mach-mvebu/coherency.c  |   87 ++
 arch/arm/mach-mvebu/common.h |2 +
 5 files changed, 95 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 18ba60b..af22e53 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -38,7 +38,8 @@
 
coherency-fabric@d0020200 {
compatible = marvell,coherency-fabric;
-   reg = 0xd0020200 0xb0;
+   reg = 0xd0020200 0xb0,
+ 0xd0021010 0x1c;
};
 
soc {
diff --git a/arch/arm/mach-mvebu/addr-map.c b/arch/arm/mach-mvebu/addr-map.c
index fe454a4..595f6b7 100644
--- a/arch/arm/mach-mvebu/addr-map.c
+++ b/arch/arm/mach-mvebu/addr-map.c
@@ -108,6 +108,9 @@ static int __init armada_setup_cpu_mbus(void)
 
addr_map_cfg.bridge_virt_base = mbus_unit_addr_decoding_base;
 
+   if (of_find_compatible_node(NULL, NULL, marvell,coherency-fabric))
+   addr_map_cfg.hw_io_coherency = 1;
+
/*
 * Disable, clear and configure windows.
 */
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
b/arch/arm/mach-mvebu/armada-370-xp.c
index 41431a1..3517f7d 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -49,6 +49,7 @@ struct sys_timer armada_370_xp_timer = {
 
 static void __init armada_370_xp_dt_init(void)
 {
+   armada_370_xp_coherency_iocache_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
 }
 
diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
index 71e27ba..a596ca9 100644
--- a/arch/arm/mach-mvebu/coherency.c
+++ b/arch/arm/mach-mvebu/coherency.c
@@ -22,6 +22,10 @@
 #include linux/of_address.h
 #include linux/io.h
 #include linux/smp.h
+#include linux/dma-mapping.h
+#include linux/platform_device.h
+#include asm/smp_plat.h
+
 #include armada-370-xp.h
 
 /* Some functions in this file are called very early during SMP
@@ -31,16 +35,53 @@
  * value matching its virtual mapping
  */
 static void __iomem *coherency_base = ARMADA_370_XP_REGS_VIRT_BASE + 0x20200;
+static void __iomem *coherency_cpu_base;
+
+struct dma_map_ops armada_xp_dma_ops;
 
 /* Coherency fabric registers */
 #define COHERENCY_FABRIC_CTL_OFFSET   0x0
 #define COHERENCY_FABRIC_CFG_OFFSET   0x4
 
+#define IO_SYNC_BARRIER_CTL_OFFSET0x0
+
 static struct of_device_id of_coherency_table[] = {
{.compatible = marvell,coherency-fabric},
{ /* end of list */ },
 };
 
+static inline void armada_xp_sync_io_barrier(void)
+{
+   writel(0x1, coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET);
+   while (readl(coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET)  0x1);
+}
+
+dma_addr_t armada_xp_dma_map_page(struct device *dev, struct page *page,
+ unsigned long offset, size_t size,
+ enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+   if (dir != DMA_TO_DEVICE)
+   armada_xp_sync_io_barrier();
+   return pfn_to_dma(dev, page_to_pfn(page)) + offset;
+}
+
+
+void armada_xp_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
+ size_t size, enum dma_data_direction dir,
+ struct dma_attrs *attrs)
+{
+   if (dir != DMA_TO_DEVICE)
+   armada_xp_sync_io_barrier();
+}
+
+void armada_xp_dma_sync(struct device *dev, dma_addr_t dma_handle,
+   size_t size, enum dma_data_direction dir)
+{
+   if (dir != DMA_TO_DEVICE)
+   armada_xp_sync_io_barrier();
+}
+
 int armada_xp_get_cpu_count(void)
 {
int

[PATCH 0/2] Add hardware I/O coherency support for Armada 370/XP

2012-10-24 Thread Gregory CLEMENT

Hello,

The purpose of this patch set is to add hardware I/O Coherency support
for Armada 370 and Armada XP. Theses SoCs come with an unit called
coherency fabric. A beginning of the support for this unit have been
introduced with the SMP patch set. This series extend this support:
the coherency fabric unit allows to use the Armada XP and the Armada
370 as nearly coherent architectures.

The second patches enables this new feature and register our own set
of DMA ops, to benefit this hardware enhancement.

The first patch introduces a new flag for the address decoding
configuration in order to be able to set the memory windows as
shared memory.

This series depend on the SMP patch set posted on Monday
(http://thread.gmane.org/gmane.linux.ports.arm.kernel/194901).

Regards,

Gregory

Gregory CLEMENT (2):
  arm: plat-orion: Add coherency attribute when setup mbus target
  arm: mvebu: Add hardware I/O Coherency support

 arch/arm/boot/dts/armada-370-xp.dtsi|3 +-
 arch/arm/mach-mvebu/addr-map.c  |3 +
 arch/arm/mach-mvebu/armada-370-xp.c |1 +
 arch/arm/mach-mvebu/coherency.c |   87 +++
 arch/arm/mach-mvebu/common.h|2 +
 arch/arm/plat-orion/addr-map.c  |4 ++
 arch/arm/plat-orion/include/plat/addr-map.h |1 +
 7 files changed, 100 insertions(+), 1 deletion(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support

2012-10-24 Thread Gregory CLEMENT

On 10/24/2012 01:36 PM, Arnd Bergmann wrote:
 On Wednesday 24 October 2012, Gregory CLEMENT wrote:
 +void __init armada_370_xp_coherency_iocache_init(void)
 +{
 +   /* When the coherency fabric is available, the Armada XP and
 +* Aramada 370 are close to a coherent architecture, so we based
 +* our dma ops on the coherent one, and just changes the
 +* operations which need a arch io sync */
 +   if (of_find_compatible_node(NULL, NULL, marvell,coherency-fabric)) 
 {
 +   struct dma_map_ops *dma_ops = armada_xp_dma_ops;
 +   memcpy(dma_ops, arm_coherent_dma_ops, sizeof(*dma_ops));
 +   dma_ops-map_page = armada_xp_dma_map_page;
 +   dma_ops-unmap_page = armada_xp_dma_unmap_page;
 +   dma_ops-unmap_sg = arm_dma_ops.unmap_sg;
 +   dma_ops-sync_single_for_cpu = armada_xp_dma_sync;
 +   dma_ops-sync_single_for_device = armada_xp_dma_sync;
 +   dma_ops-sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu;
 +   dma_ops-sync_sg_for_device = arm_dma_ops.sync_sg_for_device;
 +   }
 +   bus_register_notifier(platform_bus_type, armada_xp_platform_nb);
 
 I think it would be cleaner to statically define the operations in a constant
 structure and point directly to the functions you need. If necessary, use
 multiple structures.

My problem was that these functions are not exposed, only arm_dma_op and
arm_coherent_dma_ops are exported.
Or do you think about something like this:

struct dma_map_ops *dma_ops = {
.alloc  = arm_dma_ops.arm_coherent_dma_alloc,
.free   = arm_dma_ops.arm_coherent_dma_free,
.mmap   = arm_dma_ops.arm_dma_mmap,
.get_sgtable= arm_dma_ops.arm_dma_get_sgtable,
.map_sg = arm_dma_ops.arm_dma_map_sg,
.set_dma_mask   = arm_dma_ops.arm_dma_set_mask,
.map_page   = armada_xp_dma_map_page,
.unmap_page = armada_xp_dma_unmap_page,
.unmap_sg   = arm_dma_ops.unmap_sg,
.sync_single_for_cpu= armada_xp_dma_sync,
.sync_single_for_device = armada_xp_dma_sync,
.sync_sg_for_cpu= arm_dma_ops.sync_sg_for_cpu,
.sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
};




 
   Arnd
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support

2012-10-24 Thread Gregory CLEMENT

On 10/24/2012 10:25 AM, Andrew Lunn wrote:
 On Wed, Oct 24, 2012 at 10:04:01AM +0200, Gregory CLEMENT wrote:
 Armada 370 and XP come with an unit called coherency fabric. This unit
 allows to use the Armada XP as a nearly coherent architecture. The
 coherency mechanism uses snoop filters to ensure the coherency between
 caches, DRAM and devices. This mechanism needs a synchronization
 barrier which guarantees that all memory write initiated by the
 devices has reached their target and do not reside in intermediate
 write buffers. That's why the architecture is not totally coherent and
 we need to provide our own functions for some DMA operations.

 Beside the use of the coherency fabric, the device units will have to
 set the attribute flag to select the accurate coherency process for
 the memory transaction. This is done each device driver programs the
 DRAM address windows. The value of the attribute set by the driver is
 retrieved through the orion_addr_map_cfg struct filled during the
 early initialization of the platform.

 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 Reviewed-by: Yehuda Yitschak yehu...@marvell.com
 ---
  arch/arm/boot/dts/armada-370-xp.dtsi |3 +-
  arch/arm/mach-mvebu/addr-map.c   |3 ++
  arch/arm/mach-mvebu/armada-370-xp.c  |1 +
  arch/arm/mach-mvebu/coherency.c  |   87 
 ++
  arch/arm/mach-mvebu/common.h |2 +
  5 files changed, 95 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
 b/arch/arm/boot/dts/armada-370-xp.dtsi
 index 18ba60b..af22e53 100644
 --- a/arch/arm/boot/dts/armada-370-xp.dtsi
 +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
 @@ -38,7 +38,8 @@
  
  coherency-fabric@d0020200 {
  compatible = marvell,coherency-fabric;
 -reg = 0xd0020200 0xb0;
 +reg = 0xd0020200 0xb0,
 +  0xd0021010 0x1c;
  };
 
 ...
 
  int __init armada_370_xp_coherency_init(void)
  {
  struct device_node *np;
 @@ -82,7 +159,17 @@ int __init armada_370_xp_coherency_init(void)
  if (np) {
  pr_info(Initializing Coherency fabric\n);
  coherency_base = of_iomap(np, 0);
 +coherency_cpu_base = of_iomap(np, 1);
 
 Is this already in the binding documentation?

No indeed, the documentation should be completed. I will do it
the V2

 
Thanks
   Andrew
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support

2012-10-24 Thread Gregory CLEMENT

On 10/24/2012 01:48 PM, Gregory CLEMENT wrote:
 On 10/24/2012 01:36 PM, Arnd Bergmann wrote:
 On Wednesday 24 October 2012, Gregory CLEMENT wrote:
 +void __init armada_370_xp_coherency_iocache_init(void)
 +{
 +   /* When the coherency fabric is available, the Armada XP and
 +* Aramada 370 are close to a coherent architecture, so we based
 +* our dma ops on the coherent one, and just changes the
 +* operations which need a arch io sync */
 +   if (of_find_compatible_node(NULL, NULL, 
 marvell,coherency-fabric)) {
 +   struct dma_map_ops *dma_ops = armada_xp_dma_ops;
 +   memcpy(dma_ops, arm_coherent_dma_ops, sizeof(*dma_ops));
 +   dma_ops-map_page = armada_xp_dma_map_page;
 +   dma_ops-unmap_page = armada_xp_dma_unmap_page;
 +   dma_ops-unmap_sg = arm_dma_ops.unmap_sg;
 +   dma_ops-sync_single_for_cpu = armada_xp_dma_sync;
 +   dma_ops-sync_single_for_device = armada_xp_dma_sync;
 +   dma_ops-sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu;
 +   dma_ops-sync_sg_for_device = 
 arm_dma_ops.sync_sg_for_device;
 +   }
 +   bus_register_notifier(platform_bus_type, armada_xp_platform_nb);

 I think it would be cleaner to statically define the operations in a constant
 structure and point directly to the functions you need. If necessary, use
 multiple structures.
 
 My problem was that these functions are not exposed, only arm_dma_op and
 arm_coherent_dma_ops are exported.
 Or do you think about something like this:
 
 struct dma_map_ops *dma_ops = {
   .alloc  = arm_dma_ops.arm_coherent_dma_alloc,
   .free   = arm_dma_ops.arm_coherent_dma_free,
   .mmap   = arm_dma_ops.arm_dma_mmap,
   .get_sgtable= arm_dma_ops.arm_dma_get_sgtable,
   .map_sg = arm_dma_ops.arm_dma_map_sg,
   .set_dma_mask   = arm_dma_ops.arm_dma_set_mask,
   .map_page   = armada_xp_dma_map_page,
   .unmap_page = armada_xp_dma_unmap_page,
   .unmap_sg   = arm_dma_ops.unmap_sg,
   .sync_single_for_cpu= armada_xp_dma_sync,
   .sync_single_for_device = armada_xp_dma_sync,
   .sync_sg_for_cpu= arm_dma_ops.sync_sg_for_cpu,
   .sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
 };

I was too fast to reply this struct is wrong, it should be as this one:

struct dma_map_ops *dma_ops = {
.alloc  = arm_coherent_dma_ops.arm_coherent_dma_alloc,
.free   = arm_coherent_dma_ops.arm_coherent_dma_free,
.mmap   = arm_coherent_dma_ops.arm_dma_mmap,
.get_sgtable= arm_coherent_dma_ops.arm_dma_get_sgtable,
.map_sg = arm_coherent_dma_ops.arm_dma_map_sg,
.set_dma_mask   = arm_coherent_dma_ops.arm_dma_set_mask,
.map_page   = armada_xp_dma_map_page,
.unmap_page = armada_xp_dma_unmap_page,
.unmap_sg   = arm_dma_ops.unmap_sg,
.sync_single_for_cpu= armada_xp_dma_sync,
.sync_single_for_device = armada_xp_dma_sync,
.sync_sg_for_cpu= arm_dma_ops.sync_sg_for_cpu,
.sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
};

Thanks,
Gregory
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] arm: mvebu: increase atomic coherent pool size for armada 370/XP

2012-10-24 Thread Gregory CLEMENT

For Armada 370/XP we have the same problem that for the commit
cb01b63, so we applied the same solution: The default 256 KiB
coherent pool may be too small for some of the Kirkwood devices, so
increase it to make sure that devices will be able to allocate their
buffers with GFP_ATOMIC flag

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com

Cc: Marek Szyprowski m.szyprow...@samsung.com
---
 arch/arm/mach-mvebu/armada-370-xp.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
b/arch/arm/mach-mvebu/armada-370-xp.c
index 2af6ce5..cbad821 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -17,6 +17,7 @@
 #include linux/of_platform.h
 #include linux/io.h
 #include linux/time-armada-370-xp.h
+#include linux/dma-mapping.h
 #include asm/mach/arch.h
 #include asm/mach/map.h
 #include asm/mach/time.h
@@ -43,6 +44,16 @@ void __init armada_370_xp_timer_and_clk_init(void)
armada_370_xp_timer_init();
 }
 
+void __init armada_370_xp_init_early(void)
+{
+   /*
+* Some Armada 370/XP devices allocate their coherent buffers
+* from atomic context. Increase size of atomic coherent pool
+* to make sure such the allocations won't fail.
+*/
+   init_dma_coherent_pool_size(SZ_1M);
+}
+
 struct sys_timer armada_370_xp_timer = {
.init   = armada_370_xp_timer_and_clk_init,
 };
@@ -61,6 +72,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] 
= {
 DT_MACHINE_START(ARMADA_XP_DT, Marvell Aramada 370/XP (Device Tree))
.init_machine   = armada_370_xp_dt_init,
.map_io = armada_370_xp_map_io,
+   .init_early = armada_370_xp_init_early,
.init_irq   = armada_370_xp_init_irq,
.handle_irq = armada_370_xp_handle_irq,
.timer  = armada_370_xp_timer,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update

2012-10-24 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Lior Amsalem al...@marvell.com
---
 arch/arm/boot/dts/armada-370-db.dts  |3 +++
 arch/arm/boot/dts/armada-370-xp.dtsi |   10 ++
 arch/arm/boot/dts/armada-xp-db.dts   |3 +++
 arch/arm/configs/mvebu_defconfig |7 +++
 4 files changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 4a31b03..2a2aa75 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -34,5 +34,8 @@
clock-frequency = 2;
status = okay;
};
+   sata@d00a {
+   status = okay;
+   };
};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 94b4b9e..3f08233 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -69,6 +69,16 @@
compatible = marvell,armada-addr-decoding-controller;
reg = 0xd002 0x258;
};
+
+   sata@d00a {
+compatible = marvell,orion-sata;
+reg = 0xd00a 0x2400;
+interrupts = 55;
+nr-ports = 2;
+   clocks = coreclk 0;//,  coreclk 0;
+status = disabled;
+   };
+
};
 };
 
diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index b1fc728..b0db9a3 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -46,5 +46,8 @@
clock-frequency = 25000;
status = okay;
};
+   sata@d00a {
+   status = okay;
+   };
};
 };
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 7bcf850..8ac5f3c 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -18,6 +18,13 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_VFP=y
 CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_SATA_MV=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_MD=y
+# CONFIG_MD_AUTODETECT is not set
+CONFIG_MD_RAID456=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] Adding SATA support for Armada 370/XP

2012-10-24 Thread Gregory CLEMENT

Hello,

this small patch set adds the SATA support for Armada 370 and Armada XP.

The evaluation boards for Armada 370 and Armada XP come with 2 SATA
ports, and when both are enable the coherent pool for DMA mapping was
too short. It was exactly the same issue that was fixed for Kirkwood
two months ago. So I used the same fix in the first patch. Later when
Kirkwood will be part of mach-mvebu, then this fix will be shared
between the 2 SoCs families.

This patch set is based on 3.7-rc2 and depends one the framework clock
support (the last version was posted last week:
http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
called mvebu-SATA-for-3.8 is also available at
https://github.com/MISL-EBU-System-SW/mainline-public.git.

Regards,

Gregory

Gregory CLEMENT (1):
  arm: mvebu: increase atomic coherent pool size for armada 370/XP

Lior Amsalem (1):
  arm: mvebu: adding SATA support: dt binding and config update

 arch/arm/boot/dts/armada-370-db.dts  |3 +++
 arch/arm/boot/dts/armada-370-xp.dtsi |   10 ++
 arch/arm/boot/dts/armada-xp-db.dts   |3 +++
 arch/arm/configs/mvebu_defconfig |7 +++
 arch/arm/mach-mvebu/armada-370-xp.c  |   12 
 5 files changed, 35 insertions(+)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support

2012-10-24 Thread Gregory CLEMENT

On 10/24/2012 02:24 PM, Arnd Bergmann wrote:
 On Wednesday 24 October 2012, Gregory CLEMENT wrote:
 On 10/24/2012 01:48 PM, Gregory CLEMENT wrote:
 On 10/24/2012 01:36 PM, Arnd Bergmann wrote:

 I think it would be cleaner to statically define the operations in a 
 constant
 structure and point directly to the functions you need. If necessary, use
 multiple structures.

 My problem was that these functions are not exposed, only arm_dma_op and
 arm_coherent_dma_ops are exported.
 Or do you think about something like this:

 struct dma_map_ops *dma_ops = {
 .alloc  = 
 arm_coherent_dma_ops.arm_coherent_dma_alloc,
 .free   = arm_coherent_dma_ops.arm_coherent_dma_free,
 .mmap   = arm_coherent_dma_ops.arm_dma_mmap,
 .get_sgtable= arm_coherent_dma_ops.arm_dma_get_sgtable,
 .map_sg = arm_coherent_dma_ops.arm_dma_map_sg,
 .set_dma_mask   = arm_coherent_dma_ops.arm_dma_set_mask,
 .map_page   = armada_xp_dma_map_page,
 .unmap_page = armada_xp_dma_unmap_page,
 .unmap_sg   = arm_dma_ops.unmap_sg,
 .sync_single_for_cpu= armada_xp_dma_sync,
 .sync_single_for_device = armada_xp_dma_sync,
 .sync_sg_for_cpu= arm_dma_ops.sync_sg_for_cpu,
 .sync_sg_for_device = arm_dma_ops.sync_sg_for_device,
 };
 
 No, I was thinking of making the underlying functions globally visible
 and have extern declarations in a header file so you can access them
 directly.
 
 Generally speaking, when you run into a problem with common code, your
 first approach should be to fix the common code before you try to work
 around it.

OK I thought it was done on purpose. But if you consider it needs to be
fixed I will add patch for it in next version.

 
   Arnd
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update

2012-10-24 Thread Gregory CLEMENT

On 10/24/2012 04:01 PM, Thomas Petazzoni wrote:
 Hello,
 
 Shouldn't you split into one commit adding the SATA definition in
 the .dtsi + doing the defconfig change (the SoC level modifications),
 and then another commit for the .dts change? I don't really care
 personally, it's really up to Jason/Andrew on this.
 
 Another comment below, though.
 
 On Wed, 24 Oct 2012 15:49:21 +0200, Gregory CLEMENT wrote:
 
 diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
 b/arch/arm/boot/dts/armada-370-xp.dtsi
 index 94b4b9e..3f08233 100644
 --- a/arch/arm/boot/dts/armada-370-xp.dtsi
 +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
 @@ -69,6 +69,16 @@
  compatible = marvell,armada-addr-decoding-controller;
  reg = 0xd002 0x258;
  };
 +
 +sata@d00a {
 +compatible = marvell,orion-sata;
 +reg = 0xd00a 0x2400;
 +interrupts = 55;
 +nr-ports = 2;
 +clocks = coreclk 0;//,  coreclk 0;
 
 Alignment problem + remainings of tests or something like that.

True I missed this one.

Jason, Andrew, do you want I split this patch as suggested by Thomas or
are you fine with having one single patch?

I will wait your answer before sending the V2.

Thanks,

Gregory
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: Add hardware I/O Coherency support

2012-10-24 Thread Gregory CLEMENT

On 10/24/2012 02:27 PM, Thomas Petazzoni wrote:
[...]
I will fixed the spelling and complete the comments as suggested

[...]

 +struct dma_map_ops armada_xp_dma_ops;
 
 static

OK

 
 +static inline void armada_xp_sync_io_barrier(void)
 +{
 +writel(0x1, coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET);
 +while (readl(coherency_cpu_base + IO_SYNC_BARRIER_CTL_OFFSET)  0x1);
 +}
 +
 +dma_addr_t armada_xp_dma_map_page(struct device *dev, struct page *page,
 +  unsigned long offset, size_t size,
 +  enum dma_data_direction dir,
 +  struct dma_attrs *attrs)
 +{
 +if (dir != DMA_TO_DEVICE)
 +armada_xp_sync_io_barrier();
 +return pfn_to_dma(dev, page_to_pfn(page)) + offset;
 +}
 +
 +
 +void armada_xp_dma_unmap_page(struct device *dev, dma_addr_t dma_handle,
 +  size_t size, enum dma_data_direction dir,
 +  struct dma_attrs *attrs)
 +{
 +if (dir != DMA_TO_DEVICE)
 +armada_xp_sync_io_barrier();
 +}
 +
 +void armada_xp_dma_sync(struct device *dev, dma_addr_t dma_handle,
 +size_t size, enum dma_data_direction dir)
 +{
 +if (dir != DMA_TO_DEVICE)
 +armada_xp_sync_io_barrier();
 +}
 
 As others said, the prefix is wrong. Since the file is named coherency,
 maybe just coherency_ as the prefix? Not sure, though. Shouldn't the
 file be named coherency-armada-370-xp.c, as we have done for the irq
 controller file? In that case, the armada_370_xp prefix would make
 sense

I would prefer to just use coherency_ everywhere and keep the name of
the file as is. It made sense to suffix the irq file with
armada-370-xp because the other mvebu SoCs have their own irq
controller. Whereas, as far as I know the coherency unit is only
present in the Armada 370/XP.

 
  int armada_xp_get_cpu_count(void)
  {
  int reg, cnt;
 
 static?

Which function?
armada_xp_get_cpu_count and armada_370_xp_set_cpu_coherent are exported
and moreover are not part of this patch set but the SMP one.

 
 @@ -74,6 +115,42 @@ int armada_370_xp_set_cpu_coherent(unsigned int 
 hw_cpu_id, int smp_group_id)
  return 0;
  }
  
 +static int armada_xp_platform_notifier(struct notifier_block *nb,
 +   unsigned long event, void *__dev)
 +{
 +struct device *dev = __dev;
 +
 +if (event != BUS_NOTIFY_ADD_DEVICE)
 +return NOTIFY_DONE;
 +set_dma_ops(dev, armada_xp_dma_ops);
 +
 +return NOTIFY_OK;
 +}
 +
 +static struct notifier_block armada_xp_platform_nb = {
 +.notifier_call = armada_xp_platform_notifier,
 +};
 +
 +void __init armada_370_xp_coherency_iocache_init(void)
 +{
 +/* When the coherency fabric is available, the Armada XP and
 + * Aramada 370 are close to a coherent architecture, so we based
 + * our dma ops on the coherent one, and just changes the
 + * operations which need a arch io sync */
 +if (of_find_compatible_node(NULL, NULL, marvell,coherency-fabric)) {
 +struct dma_map_ops *dma_ops = armada_xp_dma_ops;
 +memcpy(dma_ops, arm_coherent_dma_ops, sizeof(*dma_ops));
 +dma_ops-map_page = armada_xp_dma_map_page;
 +dma_ops-unmap_page = armada_xp_dma_unmap_page;
 +dma_ops-unmap_sg = arm_dma_ops.unmap_sg;
 +dma_ops-sync_single_for_cpu = armada_xp_dma_sync;
 +dma_ops-sync_single_for_device = armada_xp_dma_sync;
 +dma_ops-sync_sg_for_cpu = arm_dma_ops.sync_sg_for_cpu;
 +dma_ops-sync_sg_for_device = arm_dma_ops.sync_sg_for_device;
 +}
 +bus_register_notifier(platform_bus_type, armada_xp_platform_nb);
 
 As Arnd said, I would prefer a lot to have the armada_xp_dma_ops
 structure be initialized statically, even though it means that if the
 arm_coherent_dma_ops structure is changed, we'll have to update here as
 well. But I think it's cleaner.
 
 Also, the bus notifier should be registered only if we have the
 coherency fabric, otherwise it is anyway going to be called, setting
 invalid DMA operations for all the platform devices.
 
 So:
 
 static dma_map_ops armada_370_xp_dma_ops = {
   ...
 };
 
 void __init armada_370_xp_coherency_iocache_init(void)
 {
   if (! of_find_compatible_node(NULL, NULL, marvell,coherency-fabric))
   return;
 
   bus_register_notifier(platform_bus_type, armada_370_xp_platform_nb);
 }

OK I agree

 
  int __init armada_370_xp_coherency_init(void)
  {
  struct device_node *np;
 @@ -82,7 +159,17 @@ int __init armada_370_xp_coherency_init(void)
  if (np) {
  pr_info(Initializing Coherency fabric\n);
  coherency_base = of_iomap(np, 0);
 +coherency_cpu_base = of_iomap(np, 1);
 +}
 +#ifndef CONFIG_SMP
 +if (coherency_base) {
 +/* In UP case, cpu coherency is enabled here, in SMP case cpu
 + * coherency is enabled for each CPU by
 +

Re: [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update

2012-10-24 Thread Gregory CLEMENT

On 10/24/2012 04:08 PM, Andrew Lunn wrote:
 On Wed, Oct 24, 2012 at 03:49:21PM +0200, Gregory CLEMENT wrote:
 From: Lior Amsalem al...@marvell.com

 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 Signed-off-by: Lior Amsalem al...@marvell.com
 ---
  arch/arm/boot/dts/armada-370-db.dts  |3 +++
  arch/arm/boot/dts/armada-370-xp.dtsi |   10 ++
  arch/arm/boot/dts/armada-xp-db.dts   |3 +++
  arch/arm/configs/mvebu_defconfig |7 +++
  4 files changed, 23 insertions(+)

 diff --git a/arch/arm/boot/dts/armada-370-db.dts 
 b/arch/arm/boot/dts/armada-370-db.dts
 index 4a31b03..2a2aa75 100644
 --- a/arch/arm/boot/dts/armada-370-db.dts
 +++ b/arch/arm/boot/dts/armada-370-db.dts
 @@ -34,5 +34,8 @@
  clock-frequency = 2;
  status = okay;
  };
 +sata@d00a {
 +status = okay;
 +};
  };
  };
 diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
 b/arch/arm/boot/dts/armada-370-xp.dtsi
 index 94b4b9e..3f08233 100644
 --- a/arch/arm/boot/dts/armada-370-xp.dtsi
 +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
 @@ -69,6 +69,16 @@
  compatible = marvell,armada-addr-decoding-controller;
  reg = 0xd002 0x258;
  };
 +
 +sata@d00a {
 +compatible = marvell,orion-sata;
 +reg = 0xd00a 0x2400;
 +interrupts = 55;
 +nr-ports = 2;
 +clocks = coreclk 0;//,  coreclk 0;
 +status = disabled;
 +};
 +
  };
  };
  
 diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
 b/arch/arm/boot/dts/armada-xp-db.dts
 index b1fc728..b0db9a3 100644
 --- a/arch/arm/boot/dts/armada-xp-db.dts
 +++ b/arch/arm/boot/dts/armada-xp-db.dts
 @@ -46,5 +46,8 @@
  clock-frequency = 25000;
  status = okay;
  };
 +sata@d00a {
 +status = okay;
 +};
  };
  };
 
 Hi Gregory
 
 Should there be some pinctrl setup somewhere, to ensure the pins used
 for SATA are really setup up for SATA?

Yes you're right we should not depend of the bootloader configuration.

 
 Also, for kirkwood, the number of SATA ports varies. So we don't
 define it in the base kirkwood.dtsi and leave each board to set it.
 Do we want to be consistent between kirkwood and 370/xp?

Yes sure. I will move it from dtsi to dts.

 
 Thanks
 Andrew
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update

2012-10-25 Thread Gregory CLEMENT

On 10/25/2012 03:21 PM, Thomas Petazzoni wrote:
 Jason,
 
 On Thu, 25 Oct 2012 09:18:18 -0400, Jason Cooper wrote:
 
 Jason, Andrew, do you want I split this patch as suggested by
 Thomas or are you fine with having one single patch?

 Yes, please make the defconfig changes a separate patch.  Also, please
 make sure only the minimum is enabled (eq RAID... isn't needed).
 
 I haven't looked in details at the driver, but is nr-ports = foo the
 right way of doing things? We may have platforms were port 0 is not
 used, but port 1 is used, and just a number of ports doesn't allow to
 express this.
 
 Shouldn't the DT property be
 
   ports = 0, 1
   ports = 1
   ports = 1, 3
 
 In order to allow to more precisely enabled SATA ports? Or maybe the
 SATA ports cannot be enabled/disabled on a per-port basis, in which
 case I'm obviously wrong here.

The actual implementation of mv_sata.c doesn't work like this. You can
only pass the number of ports supported not the list of the port you
want to support. I've checked in the device tree binding documentation
_and_ also in the code.


 
 Best regards,
 
 Thomas
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update

2012-10-25 Thread Gregory CLEMENT

On 10/25/2012 03:53 PM, Rob Herring wrote:
 On 10/25/2012 08:18 AM, Jason Cooper wrote:
 On Wed, Oct 24, 2012 at 04:05:45PM +0200, Gregory CLEMENT wrote:
 On 10/24/2012 04:01 PM, Thomas Petazzoni wrote:
 Hello,

 Shouldn't you split into one commit adding the SATA definition in
 the .dtsi + doing the defconfig change (the SoC level modifications),
 and then another commit for the .dts change? I don't really care
 personally, it's really up to Jason/Andrew on this.

 Another comment below, though.

 On Wed, 24 Oct 2012 15:49:21 +0200, Gregory CLEMENT wrote:

 diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
 b/arch/arm/boot/dts/armada-370-xp.dtsi
 index 94b4b9e..3f08233 100644
 --- a/arch/arm/boot/dts/armada-370-xp.dtsi
 +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
 @@ -69,6 +69,16 @@
   compatible = marvell,armada-addr-decoding-controller;
   reg = 0xd002 0x258;
   };
 +
 + sata@d00a {
 +compatible = marvell,orion-sata;
 +reg = 0xd00a 0x2400;
 +interrupts = 55;
 +nr-ports = 2;
 + clocks = coreclk 0;//,  coreclk 0;

 Alignment problem + remainings of tests or something like that.

 True I missed this one.

 Jason, Andrew, do you want I split this patch as suggested by Thomas or
 are you fine with having one single patch?

 Yes, please make the defconfig changes a separate patch.  Also, please
 make sure only the minimum is enabled (eq RAID... isn't needed).
 
 What about updating multi_v7_defconfig instead?

About the _instead_, when I proposed to removed mvebu_defconfig Thomas
argued that it was more convenient to build a mvebu-only kernel when
doing kernel development, and Andrew also pointed that this defconfig
should be useful for kisskb.

And about updated both mvebu_defconfig and multi_v7_defconfig, I'm
fine with it.

Gregory
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] arm: mvebu: adding SATA support: dt binding and config update

2012-10-25 Thread Gregory CLEMENT

On 10/25/2012 03:57 PM, Rob Herring wrote:
 On 10/25/2012 08:34 AM, Gregory CLEMENT wrote:
 On 10/25/2012 03:21 PM, Thomas Petazzoni wrote:
 Jason,

 On Thu, 25 Oct 2012 09:18:18 -0400, Jason Cooper wrote:

 Jason, Andrew, do you want I split this patch as suggested by
 Thomas or are you fine with having one single patch?

 Yes, please make the defconfig changes a separate patch.  Also, please
 make sure only the minimum is enabled (eq RAID... isn't needed).

 I haven't looked in details at the driver, but is nr-ports = foo the
 right way of doing things? We may have platforms were port 0 is not
 used, but port 1 is used, and just a number of ports doesn't allow to
 express this.

 Shouldn't the DT property be

   ports = 0, 1
   ports = 1
   ports = 1, 3

 In order to allow to more precisely enabled SATA ports? Or maybe the
 SATA ports cannot be enabled/disabled on a per-port basis, in which
 case I'm obviously wrong here.

 The actual implementation of mv_sata.c doesn't work like this. You can
 only pass the number of ports supported not the list of the port you
 want to support. I've checked in the device tree binding documentation
 _and_ also in the code.
 
 Is that a statement about the driver or the h/w? It does not matter what
 the driver does. If the h/w can support skipping a port, then the dts
 should allow that.

Indeed I didn't see anything in the datasheet which would prevent to use
only port 2. I agree to add this feature if needed, but currently there
is no Marvell based board whith this kind of configuration. Can we keep
this series as a simple series to enable SATA on Armada 370/XP, and
prepare an other series for this new feature?

 
 A bitmask would be most appropriate here (and matches how AHCI does the
 equivalent).

I didn't see any bitmask for AHCI, just an optional list of phandle on
combophy.

 
 Rob
 
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 0/4] Adding SATA support for Armada 370/XP

2012-10-26 Thread Gregory CLEMENT

Hello,

this patch set adds the SATA support for Armada 370 and Armada XP. Few
changes have been done since the first version by taking in account
the comments received for the first version.

The evaluation boards for Armada 370 and Armada XP come with 2 SATA
ports, and when both are enable the coherent pool for DMA mapping was
too short. It was exactly the same issue that was fixed for Kirkwood
two months ago. So I used the same fix in the first patch. Later when
Kirkwood will be part of mach-mvebu, then this fix will be shared
between the 2 SoCs families.

This patch set is based on 3.7-rc2 and depends one the framework clock
support (the last version was posted last week:
http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
called mvebu-SATA-for-3.8 is also available at
https://github.com/MISL-EBU-System-SW/mainline-public.git.

Changelog:

V1 - V2:
- Added the acked-by from Marek Szyprowski for the first patch.
- Moved the port number from dtsi to board file t o be coherent with
  Kirwkood boards.
- Cleaned armada-370-xp.dtsi from test strings.
- Split the second patch in 3 part one for dts, one for config update,
  and the last for dtsi.
- Updated the mvebu_defconfig file with only the necessary symbols.
- Updated also the multi_v7_defconfig file.

Regards,

Gregory

Gregory CLEMENT (4):
  arm: mvebu: increase atomic coherent pool size for armada 370/XP
  arm: mvebu: adding SATA support: dt binding for Armada 370/XP
  arm: mvebu: adding SATA support: configs update
  arm: mvebu: adding SATA support: dt binding for Armada 370/XP boards

 arch/arm/boot/dts/armada-370-db.dts  |4 
 arch/arm/boot/dts/armada-370-xp.dtsi |9 +
 arch/arm/boot/dts/armada-xp-db.dts   |4 
 arch/arm/configs/multi_v7_defconfig  |2 ++
 arch/arm/configs/mvebu_defconfig |3 +++
 arch/arm/mach-mvebu/armada-370-xp.c  |   12 
 6 files changed, 34 insertions(+)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP

2012-10-26 Thread Gregory CLEMENT

For Armada 370/XP we have the same problem that for the commit
cb01b63, so we applied the same solution: The default 256 KiB
coherent pool may be too small for some of the Kirkwood devices, so
increase it to make sure that devices will be able to allocate their
buffers with GFP_ATOMIC flag

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
 arch/arm/mach-mvebu/armada-370-xp.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
b/arch/arm/mach-mvebu/armada-370-xp.c
index 2af6ce5..cbad821 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -17,6 +17,7 @@
 #include linux/of_platform.h
 #include linux/io.h
 #include linux/time-armada-370-xp.h
+#include linux/dma-mapping.h
 #include asm/mach/arch.h
 #include asm/mach/map.h
 #include asm/mach/time.h
@@ -43,6 +44,16 @@ void __init armada_370_xp_timer_and_clk_init(void)
armada_370_xp_timer_init();
 }
 
+void __init armada_370_xp_init_early(void)
+{
+   /*
+* Some Armada 370/XP devices allocate their coherent buffers
+* from atomic context. Increase size of atomic coherent pool
+* to make sure such the allocations won't fail.
+*/
+   init_dma_coherent_pool_size(SZ_1M);
+}
+
 struct sys_timer armada_370_xp_timer = {
.init   = armada_370_xp_timer_and_clk_init,
 };
@@ -61,6 +72,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] 
= {
 DT_MACHINE_START(ARMADA_XP_DT, Marvell Aramada 370/XP (Device Tree))
.init_machine   = armada_370_xp_dt_init,
.map_io = armada_370_xp_map_io,
+   .init_early = armada_370_xp_init_early,
.init_irq   = armada_370_xp_init_irq,
.handle_irq = armada_370_xp_handle_irq,
.timer  = armada_370_xp_timer,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 3/4] arm: mvebu: adding SATA support: configs update

2012-10-26 Thread Gregory CLEMENT

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Lior Amsalem al...@marvell.com
---
 arch/arm/configs/multi_v7_defconfig |2 ++
 arch/arm/configs/mvebu_defconfig|3 +++
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 159f75f..dbea6f4 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -17,8 +17,10 @@ CONFIG_ARM_APPENDED_DTB=y
 CONFIG_VFP=y
 CONFIG_NEON=y
 CONFIG_NET=y
+CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_SATA_HIGHBANK=y
+CONFIG_SATA_MV=y
 CONFIG_NETDEVICES=y
 CONFIG_NET_CALXEDA_XGMAC=y
 CONFIG_SMSC911X=y
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 7bcf850..76a60b5 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -18,6 +18,9 @@ CONFIG_ZBOOT_ROM_BSS=0x0
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_VFP=y
 CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_SATA_MV=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 4/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP boards

2012-10-26 Thread Gregory CLEMENT

Add the SATA device tree bindings for
- Armada XP evaluation board (DB-78460-BP)
- Armada 370 evaluation board (DB-88F6710-BP-DDR3)

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Lior Amsalem al...@marvell.com
---
 arch/arm/boot/dts/armada-370-db.dts |4 
 arch/arm/boot/dts/armada-xp-db.dts  |4 
 2 files changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 4a31b03..060e5ba 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -34,5 +34,9 @@
clock-frequency = 2;
status = okay;
};
+   sata@d00a {
+nr-ports = 2;
+   status = okay;
+   };
};
 };
diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index b1fc728..375436b 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -46,5 +46,9 @@
clock-frequency = 25000;
status = okay;
};
+   sata@d00a {
+nr-ports = 2;
+   status = okay;
+   };
};
 };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP

2012-10-26 Thread Gregory CLEMENT

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Lior Amsalem al...@marvell.com
---
 arch/arm/boot/dts/armada-370-xp.dtsi |9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 94b4b9e..a911f7a 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -69,6 +69,15 @@
compatible = marvell,armada-addr-decoding-controller;
reg = 0xd002 0x258;
};
+
+   sata@d00a {
+compatible = marvell,orion-sata;
+reg = 0xd00a 0x2400;
+interrupts = 55;
+   clocks = coreclk 0;
+status = disabled;
+   };
+
};
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 0/4] Adding SATA support for Armada 370/XP

2012-10-26 Thread Gregory CLEMENT

On 10/26/2012 02:39 PM, Andrew Lunn wrote:
 On Fri, Oct 26, 2012 at 02:30:45PM +0200, Gregory CLEMENT wrote:
 Hello,

 this patch set adds the SATA support for Armada 370 and Armada XP. Few
 changes have been done since the first version by taking in account
 the comments received for the first version.

 The evaluation boards for Armada 370 and Armada XP come with 2 SATA
 ports, and when both are enable the coherent pool for DMA mapping was
 too short. It was exactly the same issue that was fixed for Kirkwood
 two months ago. So I used the same fix in the first patch. Later when
 Kirkwood will be part of mach-mvebu, then this fix will be shared
 between the 2 SoCs families.

 This patch set is based on 3.7-rc2 and depends one the framework clock
 support (the last version was posted last week:
 http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
 called mvebu-SATA-for-3.8 is also available at
 https://github.com/MISL-EBU-System-SW/mainline-public.git.
 
 Hi Gregory
 
 What about the openblocks-ax3?

Well I don't have this hardware, Thomas have. But with this question
I guess this board have (a) SATA port(s).

Moreover openblocks-ax3 is not (yet) in Jason branch so I can't make
a patch applying on a file which doesn't exist on my branch. It could
be a dependency but I try to reduce it as far as I can.

But as soon as this series will be applied, adding SATA support for
openblocks-ax3 should be pretty fast and just a matter of updating
the dts.

 
  Andrew
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP

2012-10-26 Thread Gregory CLEMENT

On 10/26/2012 03:34 PM, Andrew Lunn wrote:
 On Fri, Oct 26, 2012 at 09:31:54AM -0400, Jason Cooper wrote:
 On Fri, Oct 26, 2012 at 02:30:47PM +0200, Gregory CLEMENT wrote:
 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 Signed-off-by: Lior Amsalem al...@marvell.com
 ---
  arch/arm/boot/dts/armada-370-xp.dtsi |9 +
  1 file changed, 9 insertions(+)

 diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
 b/arch/arm/boot/dts/armada-370-xp.dtsi
 index 94b4b9e..a911f7a 100644
 --- a/arch/arm/boot/dts/armada-370-xp.dtsi
 +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
 @@ -69,6 +69,15 @@
 compatible = marvell,armada-addr-decoding-controller;
 reg = 0xd002 0x258;
 };
 +
 +   sata@d00a {
 +compatible = marvell,orion-sata;
 +reg = 0xd00a 0x2400;
 +interrupts = 55;
 +   clocks = coreclk 0;

 nit. whitespace?
 
 [Don't shoot the messenger]
 
 How about extending checkpatch to check for this? I guess its just
 spaces which should be tabs.

No it is the opposite in fact! On this line it's tabs: 3 tabs of 8
whitespace, so the line start at 24. But as there is a '+', the first
tab is only 7, so it is still start at 24. Whereas for the other lines
it's 24 white spaces, so with the '+' it starts at 25. That's why I
didn't notice it, and if you apply the patch all is fine.

Now, about white spaces vs tab, I don't know what is the rule for .dts
file.


Gregory
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP

2012-10-26 Thread Gregory CLEMENT

On 10/26/2012 05:02 PM, Jason Cooper wrote:
 On Fri, Oct 26, 2012 at 04:57:59PM +0200, Thomas Petazzoni wrote:

 On Fri, 26 Oct 2012 15:52:25 +0200, Andrew Lunn wrote:
 Now, about white spaces vs tab, I don't know what is the rule
 for .dts file.

 I personally use tabs, but i don't see anything in the
 Documentation/CodingStyle.

 Maybe ask on the device tree mailing list?

 Yes, it would be good to know and document what is the rule for .dts
 files, and possibly extend checkpatch to cover those special rules
 for .dts files.
 
 until that is resolved, can we make this patch conform to what is in the
 file currently?  Once the dt folks clarify, we can run through all the
 dts's and submit one cleanup series.
 
 If there are no other comments on this series, I'm fine taking it as is
 and doing the fixup on my end.  No need to do a version bump just for
 this.

OK then you will just have to replace my tabs by whitespace.

Thanks,

Gregory
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm: mvebu: support for the Globalscale Mirabox MBX0001 board

2012-10-27 Thread Gregory CLEMENT

This platform, available from Globalscale has an Armada 370. For now,
only the serial port is supported. Support for network, USB and other
peripherals will be added as drivers for them become available for
Armada 370 in mainline.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/Makefile  |3 ++-
 arch/arm/boot/dts/mbx001.dts|   37 +++
 arch/arm/mach-mvebu/armada-370-xp.c |1 +
 3 files changed, 40 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/mbx001.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..ee09963 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -44,7 +44,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
 dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
msm8960-cdp.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
-   armada-xp-db.dtb
+   armada-xp-db.dtb \
+   mbx0001.dtb
 dtb-$(CONFIG_ARCH_MXC) += imx51-babbage.dtb \
imx53-ard.dtb \
imx53-evk.dtb \
diff --git a/arch/arm/boot/dts/mbx001.dts b/arch/arm/boot/dts/mbx001.dts
new file mode 100644
index 000..88a5a11
--- /dev/null
+++ b/arch/arm/boot/dts/mbx001.dts
@@ -0,0 +1,37 @@
+/*
+ * Device Tree file for Globalscale Mirabox MBX0001
+ *
+ * Gregory CLEMENT gregory.clem...@free-electrons.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+/include/ armada-370.dtsi
+
+/ {
+   model = Mirabox MBX0001;
+   compatible = globalscale,mbx0001, marvell,armada370, 
marvell,armada-370-xp;
+
+   chosen {
+   bootargs = console=ttyS0,115200 earlyprintk;
+   };
+
+   memory {
+   device_type = memory;
+   reg = 0x 0x2000; /* 512 MB */
+   };
+
+   soc {
+   serial@d0012000 {
+   clock-frequency = 2;
+   status = okay;
+   };
+   timer@d0020300 {
+   clock-frequency = 6;
+   status = okay;
+   };
+   };
+};
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..e5269b4 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -49,6 +49,7 @@ static void __init armada_370_xp_dt_init(void)
 static const char * const armada_370_xp_dt_board_dt_compat[] = {
marvell,a370-db,
marvell,axp-db,
+   globalscale,mbx0001,
NULL,
 };
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 0/3] Add clock framework for armada 370/XP

2012-10-15 Thread Gregory CLEMENT

Hello Mike,

The v3.7-rc1 was released yesterday. So here it is the updated version
of my patch set. The rebase was flawless. An I have just fixed a typo
in the device tree and warnings from checkpatch. I built and test it
for the Armada 370 and Armada XP evaluation board.

The purpose of this patch set is to add support for clock framework
for Armada 370 and Armada XP SoCs. All the support is done under the
directory drivers/clk/mvebu/ as the support for other mvebu SoCs was
in mind during the writing of the code.

Two kinds of clocks are added:

- The CPU clocks are only for Armada XP (which is multi-core)

- The core clocks are clocks which have their rate fixed during
  reset.

Many thanks to Thomas Petazzoni and Sebastian Hesselbarth for their
review and feedback. The device tree bindings were really improved
with the advices of Sebastian.

Changelog:
V2 - V3:
- Rebased on top of v3.7-rc1
- Fixed a typo in device trees
- Fixed warning from checkpatch

V1 - V2:

- Improved the spelling and the wording of the documentation and the
  1st commit log
- Removed the end_of_list name which are unused here.
- Fix the cpu clock by using of_clk_src_onecell_get in the same way it
  was used for the core clocks

Regards,


Gregory CLEMENT (3):
  clk: mvebu: add armada-370-xp specific clocks
  clk: armada-370-xp: add support for clock framework
  clocksource: time-armada-370-xp converted to clk framework

 .../devicetree/bindings/clock/mvebu-core-clock.txt |   40 +++
 .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   21 ++
 arch/arm/boot/dts/armada-370-db.dts|4 -
 arch/arm/boot/dts/armada-370-xp.dtsi   |1 +
 arch/arm/boot/dts/armada-370.dtsi  |   12 +
 arch/arm/boot/dts/armada-xp.dtsi   |   48 +++
 arch/arm/mach-mvebu/Kconfig|5 +
 arch/arm/mach-mvebu/armada-370-xp.c|8 +-
 arch/arm/mach-mvebu/common.h   |1 +
 drivers/clk/Makefile   |1 +
 drivers/clk/mvebu/Makefile |2 +
 drivers/clk/mvebu/clk-core.c   |  312 
 drivers/clk/mvebu/clk-core.h   |   19 ++
 drivers/clk/mvebu/clk-cpu.c|  155 ++
 drivers/clk/mvebu/clk-cpu.h|   19 ++
 drivers/clk/mvebu/clk.c|   36 +++
 drivers/clocksource/time-armada-370-xp.c   |   11 +-
 17 files changed, 685 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
 create mode 100644 drivers/clk/mvebu/Makefile
 create mode 100644 drivers/clk/mvebu/clk-core.c
 create mode 100644 drivers/clk/mvebu/clk-core.h
 create mode 100644 drivers/clk/mvebu/clk-cpu.c
 create mode 100644 drivers/clk/mvebu/clk-cpu.h
 create mode 100644 drivers/clk/mvebu/clk.c

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 3/3] clocksource: time-armada-370-xp converted to clk framework

2012-10-15 Thread Gregory CLEMENT

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts  |4 
 arch/arm/boot/dts/armada-370-xp.dtsi |1 +
 drivers/clocksource/time-armada-370-xp.c |   11 ++-
 3 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index fffd5c2..4a31b03 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -34,9 +34,5 @@
clock-frequency = 2;
status = okay;
};
-   timer@d0020300 {
-   clock-frequency = 6;
-   status = okay;
-   };
};
 };
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 16cc82c..94b4b9e 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -62,6 +62,7 @@
   compatible = marvell,armada-370-xp-timer;
   reg = 0xd0020300 0x30;
   interrupts = 37, 38, 39, 40;
+  clocks = coreclk 2;
};
 
addr-decoding@d002 {
diff --git a/drivers/clocksource/time-armada-370-xp.c 
b/drivers/clocksource/time-armada-370-xp.c
index 4674f94..a4605fd 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -18,6 +18,7 @@
 #include linux/init.h
 #include linux/platform_device.h
 #include linux/kernel.h
+#include linux/clk.h
 #include linux/timer.h
 #include linux/clockchips.h
 #include linux/interrupt.h
@@ -167,7 +168,6 @@ void __init armada_370_xp_timer_init(void)
u32 u;
struct device_node *np;
unsigned int timer_clk;
-   int ret;
np = of_find_compatible_node(NULL, NULL, marvell,armada-370-xp-timer);
timer_base = of_iomap(np, 0);
WARN_ON(!timer_base);
@@ -179,13 +179,14 @@ void __init armada_370_xp_timer_init(void)
   timer_base + TIMER_CTRL_OFF);
timer_clk = 2500;
} else {
-   u32 clk = 0;
-   ret = of_property_read_u32(np, clock-frequency, clk);
-   WARN_ON(!clk || ret  0);
+   unsigned long rate = 0;
+   struct clk *clk = of_clk_get(np, 0);
+   WARN_ON(IS_ERR(clk));
+   rate =  clk_get_rate(clk);
u = readl(timer_base + TIMER_CTRL_OFF);
writel(u  ~(TIMER0_25MHZ | TIMER1_25MHZ),
   timer_base + TIMER_CTRL_OFF);
-   timer_clk = clk / TIMER_DIVIDER;
+   timer_clk = rate / TIMER_DIVIDER;
}
 
/* We use timer 0 as clocksource, and timer 1 for
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 2/3] clk: armada-370-xp: add support for clock framework

2012-10-15 Thread Gregory CLEMENT

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370.dtsi   |   12 +
 arch/arm/boot/dts/armada-xp.dtsi|   48 +++
 arch/arm/mach-mvebu/Kconfig |5 
 arch/arm/mach-mvebu/armada-370-xp.c |8 +-
 arch/arm/mach-mvebu/common.h|1 +
 5 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index 2069151..ac495b4 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -75,5 +75,17 @@
#interrupts-cells = 2;
interrupts = 91;
};
+   coreclk: mvebu-sar@d0018230 {
+   #clock-cells = 1;
+   reg = 0xd0018230 0x08;
+   compatible = marvell,armada-370-core-clockctrl;
+   clock-output-names =
+   tclk, /* 0 */
+   pclk, /* 1 */
+   nbclk,/* 2 */
+   hclk, /* 3 */
+   dramclk;  /* 4 */
+   };
+
};
 };
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 71d6b5d..a564b52 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,35 @@
0xd0021870 0x58;
};
 
+   cpus {
+   #address-cells = 1;
+   #size-cells = 0;
+
+   cpu@0 {
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
+
+   cpu@1 {
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
+
+   cpu@2 {
+   compatible = marvell,sheeva-v7;
+   reg = 2;
+   clocks = cpuclk 2;
+   };
+
+   cpu@3 {
+   compatible = marvell,sheeva-v7;
+   reg = 3;
+   clocks = cpuclk 3;
+   };
+   };
+
soc {
serial@d0012200 {
compatible = ns16550;
@@ -47,6 +76,25 @@
marvell,timer-25Mhz;
};
 
+   coreclk: mvebu-sar@d0018230 {
+   #clock-cells = 1;
+   reg = 0xd0018230 0x08;
+   compatible = marvell,armada-xp-core-clockctrl;
+   clock-output-names =
+   tclk, /* 0 */
+   pclk, /* 1 */
+   nbclk,/* 2 */
+   hclk, /* 3 */
+   dramclk;  /* 4 */
+   };
+
+   cpuclk: clock-complex@d0018700 {
+   #clock-cells = 1;
+   compatible = marvell,armada-xp-cpu-clockctrl;
+   reg = 0xd0018700 0xA0;
+   clocks = coreclk 1;
+   };
+
system-controller@d0018200 {
compatible = 
marvell,armada-370-xp-system-controller;
reg = 0xd0018200 0x500;
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 416d46e..17d246b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -9,11 +9,16 @@ config ARCH_MVEBU
select PINCTRL
select PLAT_ORION
select SPARSE_IRQ
+   select CLKDEV_LOOKUP
+   select MVEBU_CLK_CPU
 
 if ARCH_MVEBU
 
 menu Marvell SOC with device tree
 
+config MVEBU_CLK_CPU
+  bool
+
 config MACH_ARMADA_370_XP
bool
select ARMADA_370_XP_TIMER
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c 
b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..2af6ce5 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -37,8 +37,14 @@ void __init armada_370_xp_map_io(void)
iotable_init(armada_370_xp_io_desc, ARRAY_SIZE(armada_370_xp_io_desc));
 }
 
+void __init armada_370_xp_timer_and_clk_init(void)
+{
+   mvebu_clocks_init();
+   armada_370_xp_timer_init();
+}
+
 struct sys_timer armada_370_xp_timer = {
-   .init   = armada_370_xp_timer_init,
+   .init   = armada_370_xp_timer_and_clk_init,
 };
 
 static void __init armada_370_xp_dt_init(void)
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 02f89ea..281fab3 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -16,6 +16,7 @@
 #define __ARCH_MVEBU_COMMON_H
 
 void mvebu_restart(char mode, const char *cmd);
+void mvebu_clocks_init(void);
 
 void armada_370_xp_init_irq(void);
 void armada_370_xp_handle_irq(struct pt_regs *regs);
-- 
1.7.9.5

--
To unsubscribe from this list: send

[PATCH V3 1/3] clk: mvebu: add armada-370-xp specific clocks

2012-10-15 Thread Gregory CLEMENT

Add Armada 370/XP specific clocks: core clocks and CPU clocks.

The CPU clocks are only for Armada XP for the SMP mode.

The core clocks are clocks which have their rate set during reset. The
code was written with the other SoCs of the mvebu family in
mind. Adding them should be pretty straight forward. For a new
SoC, only 3 binding have to be added:
- one to provide the tclk frequency
- one to provde the pclk frequency
- and one to provide the ratio between the pclk and the children
  clocks

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 .../devicetree/bindings/clock/mvebu-core-clock.txt |   40 +++
 .../devicetree/bindings/clock/mvebu-cpu-clock.txt  |   21 ++
 drivers/clk/Makefile   |1 +
 drivers/clk/mvebu/Makefile |2 +
 drivers/clk/mvebu/clk-core.c   |  312 
 drivers/clk/mvebu/clk-core.h   |   19 ++
 drivers/clk/mvebu/clk-cpu.c|  155 ++
 drivers/clk/mvebu/clk-cpu.h|   19 ++
 drivers/clk/mvebu/clk.c|   36 +++
 9 files changed, 605 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
 create mode 100644 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
 create mode 100644 drivers/clk/mvebu/Makefile
 create mode 100644 drivers/clk/mvebu/clk-core.c
 create mode 100644 drivers/clk/mvebu/clk-core.h
 create mode 100644 drivers/clk/mvebu/clk-cpu.c
 create mode 100644 drivers/clk/mvebu/clk-cpu.h
 create mode 100644 drivers/clk/mvebu/clk.c

diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt 
b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
new file mode 100644
index 000..d2e0965
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for core clock of Marvell EBU platforms
+
+This is the binding for the core clock of the mvebu SoCs, the rate
+of this clocks are fixed during reset. Their value or ratio are taken
+from the Sample at Reset(SAR) register.
+
+Required properties:
+- compatible : shall be one of the following:
+   marvell,armada-370-core-clockctrl - core clock for Armada 370
+   marvell,armada-xp-core-clockctrl - core clock for Armada XP
+- reg : Address and length of the SAR register set
+- #clock-cells : should be set to 1.
+- clock-output-names: A list of clock output names that mvebu core
+  clocks provides.  The full list of all valid clock names, IDs and
+  description are below.
+   NameID  Description
+   tclk0   Peripheral clock
+   pclk1   CPU clock
+   nbclk   2   L2 clock
+   hclk3   DRAM control clock
+   dramclk 4   DDR clock
+
+coreclk: mvebu-sar@d0018230 {
+   #clock-cells = 1;
+   reg = 0xd0018230 0x08;
+   compatible = marvell,armada-370-core-clockctrl;
+   clock-output-names =
+   tclk, /* 0 */
+   pclk, /* 1 */
+   nbclk,/* 2 */
+   hclk, /* 3 */
+   dramclk,  /* 4 */
+};
+
+timer@d0020300 {
+  compatible = marvell,armada-370-xp-timer;
+  reg = 0xd0020300 0x30;
+  interrupts = 37, 38, 39, 40;
+  clocks = coreclk 0;
+};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt 
b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
new file mode 100644
index 000..c524618
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -0,0 +1,21 @@
+Device Tree Clock bindings for cpu clock of Marvell EBU platforms
+
+Required properties:
+- compatible : shall be one of the following:
+   marvell,armada-xp-cpu-clockctrl - cpu clocks for Armada XP
+- reg : Address and length of the clock complex register set
+- #clock-cells : should be set to 1.
+- clocks : shall be the input parent clock phandle for the clock.
+
+cpuclk: clock-complex@d0018700 {
+   #clock-cells = 1;
+   compatible = marvell,armada-xp-cpu-clockctrl;
+   reg = 0xd0018700 0xA0;
+   clocks = coreclk 1;
+}
+
+cpu@0 {
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71a25b9..9c91d6c 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_PLAT_SPEAR)  += spear/
 obj-$(CONFIG_ARCH_U300)+= clk-u300.o
 obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
 obj-$(CONFIG_ARCH_PRIMA2)  += clk-prima2.o
+obj-$(CONFIG_ARCH_MVEBU)   += mvebu/
 ifeq ($(CONFIG_COMMON_CLK), y)
 obj-$(CONFIG_ARCH_MMP) += mmp/
 endif
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
new file mode 100644
index 000..de94a87
--- /dev/null
+++ b/drivers/clk/mvebu/Makefile
@@ -0,0 +1,2

Re: [PATCH v4 0/5] LPAE remaining device tree file

2013-04-15 Thread Gregory CLEMENT

On 04/15/2013 05:47 PM, Jason Cooper wrote:
 On Fri, Apr 12, 2013 at 04:29:05PM +0200, Gregory CLEMENT wrote:
 Hi Jason,

 I have just rebased the commits that you haven't applied yet. They are
 rebased on mvebu/dt. I check that all the dtb can be built.

 Thanks,

 Gregory CLEMENT (3):
   ARM: dts: mvebu: Convert all the mvebu files to use the range
 property
   ARM: dts: mvebu: introduce internal-regs node
   ARM: dts: mvebu: Convert mvebu device tree files to 64 bits

 Thomas Petazzoni (2):
   ARM: dts: mvebu: fix cpus section indentation
   ARM: dts: mvebu: move all peripherals inside soc

  arch/arm/boot/dts/armada-370-db.dts  |  134 +++---
  arch/arm/boot/dts/armada-370-mirabox.dts |  176 
  arch/arm/boot/dts/armada-370-rd.dts  |   96 ++---
  arch/arm/boot/dts/armada-370-xp.dtsi |  336 +++
  arch/arm/boot/dts/armada-370.dtsi|  330 +++
  arch/arm/boot/dts/armada-xp-db.dts   |  202 -
  arch/arm/boot/dts/armada-xp-gp.dts   |  222 +-
  arch/arm/boot/dts/armada-xp-mv78230.dtsi |  284 ++---
  arch/arm/boot/dts/armada-xp-mv78260.dtsi |  342 +++
  arch/arm/boot/dts/armada-xp-mv78460.dtsi |  484 
 +++---
  arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  262 ++--
  arch/arm/boot/dts/armada-xp.dtsi |  202 -
  12 files changed, 1549 insertions(+), 1521 deletions(-)
 
 whole series applied to mvebu/dt
 
 thx,
 

Great, Thanks!
 Jason.
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RFC] Fix bug if earlyprintk is called twice

2013-04-18 Thread Gregory CLEMENT

Hello,

If on the kernel command line the parameter earlyprintk is written
twice, then setup_early_printk is called twice. This can happen for
example with the option CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is
selected, and the earlyprintk is passed from the ATAG_CMDLINE and
from the dtb.

This lead to an infinite loop on the message Booting Linux on
physical CPU 0 displayed from smp_setup_processor_id() in
arch/arm/kernel/setup.c. This behavior as been reproduced on ARMv7
architecture (Armada XP and Armada 370), and on a ARMv5 one
(AT91SAMG35 thanks to Richard Genoud), with and with CONFIG_SMP
selected.

After some investigation I found that the problem happened when the
early_console is register for the second time in file kernel/printk.c
on line 2310 when the function console_lock() is called, and in this
function I managed to have traces until the call to down(console_sem)
one line 1922. Keep in mind that I had this information using printk
so maybe it was not the best way to debug the console!

I didn't had other platform that ARM one for testing this behavior, so
I don't know if this bug is specific to ARM. If you think it is
something specific to ARM then I propose the patch in the following
email.

Any feedback on this issue would be welcome

Thanks,

Gregory CLEMENT (1):
  ARM: don't allow to register the early_console twice

 arch/arm/kernel/early_printk.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH RFC] ARM: don't allow to register the early_console twice

2013-04-18 Thread Gregory CLEMENT

If on the kernel command line the parameter earlyprintk is written
twice, then setup_early_printk is called twice. This can happen for
example with the option CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is
selected, and the earlyprintk is passed from the ATAG_CMDLINE and
from the dtb.

This lead to an infinite loop on the message Booting Linux on
physical CPU 0 displayed from smp_setup_processor_id() in
arch/arm/kernel/setup.c. This behavior as been reproduced on ARMv7
architecture (Armada XP and Armada 370), and on a ARMv5 one
(AT91SAMG35 thanks to Richard Genoud), with and with CONFIG_SMP
selected.

This patch simply doesn't allow to call twice register_console() with
the early_console.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/kernel/early_printk.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/early_printk.c b/arch/arm/kernel/early_printk.c
index 85aa2b2..435577a 100644
--- a/arch/arm/kernel/early_printk.c
+++ b/arch/arm/kernel/early_printk.c
@@ -50,7 +50,11 @@ asmlinkage void early_printk(const char *fmt, ...)
 
 static int __init setup_early_printk(char *buf)
 {
-   register_console(early_console);
+   static int done;
+   if (!done) {
+   register_console(early_console);
+   done = 1;
+   }
return 0;
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 6/9] arm: dts: mvebu: Convert all the mvebu files to use the range property

2013-04-05 Thread Gregory CLEMENT

This conversion will allow to keep 32 bits addresses for the internal
registers whereas the memory of the system will be 64 bits.
Later it will also ease the move of the mvebu-mbus driver to the
device tree support.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts  |   16 ++---
 arch/arm/boot/dts/armada-370-mirabox.dts |   14 ++--
 arch/arm/boot/dts/armada-370-rd.dts  |   14 ++--
 arch/arm/boot/dts/armada-370-xp.dtsi |   83 +++---
 arch/arm/boot/dts/armada-370.dtsi|   49 ++---
 arch/arm/boot/dts/armada-xp-db.dts   |   28 
 arch/arm/boot/dts/armada-xp-gp.dts   |   20 +++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   10 +--
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   18 ++---
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   18 ++---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |   22 +++---
 arch/arm/boot/dts/armada-xp.dtsi |   65 -
 12 files changed, 180 insertions(+), 177 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..183901c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,11 +30,11 @@
};
 
soc {
-   serial@d0012000 {
+   serial@12000 {
clock-frequency = 2;
status = okay;
};
-   sata@d00a {
+   sata@a {
nr-ports = 2;
status = okay;
};
@@ -49,18 +49,18 @@
};
};
 
-   ethernet@d007 {
+   ethernet@7 {
status = okay;
phy = phy0;
phy-mode = rgmii-id;
};
-   ethernet@d0074000 {
+   ethernet@74000 {
status = okay;
phy = phy1;
phy-mode = rgmii-id;
};
 
-   mvsdio@d00d4000 {
+   mvsdio@d4000 {
pinctrl-0 = sdio_pins1;
pinctrl-names = default;
/*
@@ -75,15 +75,15 @@
/* No CD or WP GPIOs */
};
 
-   usb@d005 {
+   usb@5 {
status = okay;
};
 
-   usb@d0051000 {
+   usb@51000 {
status = okay;
};
 
-   spi0: spi@d0010600 {
+   spi0: spi@10600 {
status = okay;
 
spi-flash@0 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts 
b/arch/arm/boot/dts/armada-370-mirabox.dts
index dd0c57d..2773eee 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,11 +25,11 @@
};
 
soc {
-   serial@d0012000 {
+   serial@12000 {
clock-frequency = 2;
status = okay;
};
-   timer@d0020300 {
+   timer@20300 {
clock-frequency = 6;
status = okay;
};
@@ -42,18 +42,18 @@
reg = 1;
};
};
-   ethernet@d007 {
+   ethernet@7 {
status = okay;
phy = phy0;
phy-mode = rgmii-id;
};
-   ethernet@d0074000 {
+   ethernet@74000 {
status = okay;
phy = phy1;
phy-mode = rgmii-id;
};
 
-   mvsdio@d00d4000 {
+   mvsdio@d4000 {
pinctrl-0 = sdio_pins2;
pinctrl-names = default;
status = okay;
@@ -63,11 +63,11 @@
 */
};
 
-   usb@d005 {
+   usb@5 {
status = okay;
};
 
-   usb@d0051000 {
+   usb@51000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/armada-370-rd.dts 
b/arch/arm/boot/dts/armada-370-rd.dts
index 070bba4..be209020 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,11 +28,11 @@
};
 
soc {
-   serial@d0012000 {
+   serial@12000 {
clock-frequency = 2;
status = okay;
};
-   sata@d00a

[PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node

2013-04-05 Thread Gregory CLEMENT

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts  |  108 +-
 arch/arm/boot/dts/armada-370-mirabox.dts |   78 
 arch/arm/boot/dts/armada-370-rd.dts  |2 +
 arch/arm/boot/dts/armada-370-xp.dtsi |  228 +++---
 arch/arm/boot/dts/armada-370.dtsi|  211 ++--
 arch/arm/boot/dts/armada-xp-db.dts   |  154 +++
 arch/arm/boot/dts/armada-xp-gp.dts   |  124 ++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   56 +++---
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   80 
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   80 
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  196 ++-
 arch/arm/boot/dts/armada-xp.dtsi |  182 +
 12 files changed, 759 insertions(+), 740 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 183901c..6c30a9f 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,68 +30,70 @@
};
 
soc {
-   serial@12000 {
-   clock-frequency = 2;
-   status = okay;
-   };
-   sata@a {
-   nr-ports = 2;
-   status = okay;
-   };
-
-   mdio {
-   phy0: ethernet-phy@0 {
-   reg = 0;
+   internal-regs {
+   serial@12000 {
+   clock-frequency = 2;
+   status = okay;
+   };
+   sata@a {
+   nr-ports = 2;
+   status = okay;
};
 
-   phy1: ethernet-phy@1 {
-   reg = 1;
+   mdio {
+   phy0: ethernet-phy@0 {
+   reg = 0;
+   };
+
+   phy1: ethernet-phy@1 {
+   reg = 1;
+   };
};
-   };
 
-   ethernet@7 {
-   status = okay;
-   phy = phy0;
-   phy-mode = rgmii-id;
-   };
-   ethernet@74000 {
-   status = okay;
-   phy = phy1;
-   phy-mode = rgmii-id;
-   };
+   ethernet@7 {
+   status = okay;
+   phy = phy0;
+   phy-mode = rgmii-id;
+   };
+   ethernet@74000 {
+   status = okay;
+   phy = phy1;
+   phy-mode = rgmii-id;
+   };
 
-   mvsdio@d4000 {
-   pinctrl-0 = sdio_pins1;
-   pinctrl-names = default;
-   /*
-* This device is disabled by default, because
-* using the SD card connector requires
-* changing the default CON40 connector
-* DB-88F6710_MPP_2xRGMII_DEVICE_Jumper to a
-* different connector
-* DB-88F6710_MPP_RGMII_SD_Jumper.
-*/
-   status = disabled;
-   /* No CD or WP GPIOs */
-   };
+   mvsdio@d4000 {
+   pinctrl-0 = sdio_pins1;
+   pinctrl-names = default;
+   /*
+* This device is disabled by default, because
+* using the SD card connector requires
+* changing the default CON40 connector
+* DB-88F6710_MPP_2xRGMII_DEVICE_Jumper to a
+* different connector
+* DB-88F6710_MPP_RGMII_SD_Jumper.
+*/
+   status = disabled;
+   /* No CD or WP GPIOs */
+   };
 
-   usb@5 {
-   status = okay;
-   };
+   usb@5 {
+   status = okay;
+   };
 
-   usb@51000 {
-   status = okay;
-   };
+   usb@51000 {
+   status = okay

[PATCH v2 8/9] arm: dts: mvebu: fix cpus section indentation

2013-04-05 Thread Gregory CLEMENT

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   28 
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   28 
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   54 +++---
 3 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f0d38fb..392f118 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -25,22 +25,22 @@
};
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
+   #address-cells = 1;
+   #size-cells = 0;
 
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
 
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 2621bda..8fb7fea 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -26,22 +26,22 @@
};
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
+   #address-cells = 1;
+   #size-cells = 0;
 
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
 
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index ccb95ff..fa665cb 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -27,36 +27,36 @@
 
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
+   #address-cells = 1;
+   #size-cells = 0;
 
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
 
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
 
-   cpu@2 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 2;
-   clocks = cpuclk 2;
-   };
+   cpu@2 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 2;
+   clocks = cpuclk 2;
+   };
 
-   cpu@3 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 3;
-   clocks = cpuclk 3;
-   };
+   cpu@3 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 3;
+   clocks = cpuclk 3;
+   };
};
 
soc {
@@ -114,4 +114,4 @@
};
};
};
- };
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the

[PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs

2013-04-05 Thread Gregory CLEMENT

Hello,

The Armada XP SoCs have LPAE support. This is the second version patch
set whixh allow to run kernel on this SoCs with LPAE support.

The biggest changes are the conversion of the device tree file to 64
bits in order to be able to use more than 4GB of memory (without this
the LPAE is pointless).

The main change since the first version is the usage of the range
property as suggested by Rob Herring. As this massive change on the
dts file will have an impact on the mvebu-mbus driver binding, I also
added some patches from Thomas Petazzoni. The purpose is to avoid a
new big change in the devices tree files when Thomas will improve the
mvebu-mbus driver to rely on the device tree.

The other point is about DMA usage. LPAE allows to use 40bits address
only between CPU and DRAM. All the DMA transfer are restricted to the
low 32 bits address space. The first version try to use DMABOUNCE to
allows DMA transfer from any place in memory. There were a consensus
on the fact that was a something to avoid. The alternative was
swiotlb, however it will require a large rewrite of
arch/arm/mach-mvebu/coherency.c (our dma_map_ops was defined here),
and we are close the opening of the merge window. So I chose, in a
first phase, to use ZONE_DMA to limit the use of the DMA on the 32
bits address space. Later our dma_map_ops would be improve with
swiotlb.

This new patch set have been tested on a Armada XP GP board with 8GB
of DRAM with LPAE selected. It have been tested on Armada XP DB board
with 3GB of DRAM with and without LPAE. And also on the Armada 370 DB
board (without LPAE) to check that no regression appeared.

This patch set is based on 3.9-rc5 and is still 3.10 material. The git
branch called lpae-v2 is available at:

https://github.com/MISL-EBU-System-SW/mainline-public.git.

Thanks,

Changelog:
v1 - v2:

* The patch to convert the mvebu device tree files to 64 bits was
  split in 3 parts:

- arm: dts: move all peripherals inside soc from Thomas

- then arm: dts: Convert all the mvebu files to use the range
property which will allow to keep 32 bits addresses for the
internal registers whereas the memory of the system will be 64
bits

- and finally arm: dts: Convert mvebu device tree files to 64
  bits which was the move to 64 bits itself.

* A new patch was added arm: dts: introduce internal-regs node based
  on the work of Thomas for the mvebu-mbus driver. It introduce a
  'internal-regs' subnode, under which all devices are moved. This is
  not really needed for now, but will be for the mvebu-mbus
  driver. This generates a lot of code movement since it's indenting
  by one more tab all the devices. So it was a good opportunity to fix
  all the bad indentation.

* New patch from Thomas fix cpus section indentation to finalize the
  fixing of the bad indentation

* For DMA transfer, DMA_ZONE was selected instead of DMABOUNCE: all
  the DMA transfer are restricted to the low 32 bits address space.


Gregory CLEMENT (4):
  arm: mvebu: Limit the DMA zone when LPAE is selected
  arm: dts: mvebu: Convert all the mvebu files to use the range
property
  arm: dts: mvebu: introduce internal-regs node
  arm: dts: mvebu: Convert mvebu device tree files to 64 bits

Lior Amsalem (3):
  arm: mvebu: Align the internal registers virtual base to support LPAE
  arm: mvebu: Enable pj4b on LPAE compilations
  arm: dts: Add a 64 bits version of the skeleton device tree

Thomas Petazzoni (2):
  arm: dts: mvebu: move all peripherals inside soc
  arm: dts: mvebu: fix cpus section indentation

 arch/arm/boot/dts/armada-370-db.dts  |  110 +-
 arch/arm/boot/dts/armada-370-mirabox.dts |   80 +++
 arch/arm/boot/dts/armada-370-rd.dts  |   18 +-
 arch/arm/boot/dts/armada-370-xp.dtsi |  253 +++---
 arch/arm/boot/dts/armada-370.dtsi|  211 +-
 arch/arm/boot/dts/armada-xp-db.dts   |  156 ++---
 arch/arm/boot/dts/armada-xp-gp.dts   |  138 ++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   84 +++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |  110 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |  136 ++--
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  198 -
 arch/arm/boot/dts/armada-xp.dtsi |  191 
 arch/arm/boot/dts/skeleton64.dtsi|   13 ++
 arch/arm/include/debug/mvebu.S   |2 +-
 arch/arm/mach-mvebu/Kconfig  |1 +
 arch/arm/mach-mvebu/armada-370-xp.h  |2 +-
 arch/arm/mm/proc-v7.S|3 +-
 17 files changed, 873 insertions(+), 833 deletions(-)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http

[PATCH v2 9/9] arm: dts: mvebu: Convert mvebu device tree files to 64 bits

2013-04-05 Thread Gregory CLEMENT

In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.

Armada XP and Armada 370 share a dtsi file which have also be
converted to 64 bits. This lead to convert all the device tree files
to 64 bits even the one used for Armada 370 (which don't support LPAE)

This was heavily based on the work of Lior Amsalem.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts  |2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts |2 +-
 arch/arm/boot/dts/armada-370-rd.dts  |2 +-
 arch/arm/boot/dts/armada-370-xp.dtsi |4 ++--
 arch/arm/boot/dts/armada-xp-db.dts   |2 +-
 arch/arm/boot/dts/armada-xp-gp.dts   |   14 --
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 +-
 7 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 6c30a9f..c996c06 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -26,7 +26,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x4000; /* 1 GB */
+   reg = 0 0x 0 0x4000; /* 1 GB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts 
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 5a06e87..29b6b64 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -21,7 +21,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x2000; /* 512 MB */
+   reg = 0 0x 0 0x2000; /* 512 MB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts 
b/arch/arm/boot/dts/armada-370-rd.dts
index 437dcd2..09e75fc 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -24,7 +24,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x2000; /* 512 MB */
+   reg = 0 0x 0 0x2000; /* 512 MB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 8b9adc6..6a3b418 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -16,7 +16,7 @@
  * 370 and Armada XP SoC.
  */
 
-/include/ skeleton.dtsi
+/include/ skeleton64.dtsi
 
 / {
model = Marvell Armada 370 and XP SoC;
@@ -33,7 +33,7 @@
#size-cells = 1;
compatible = simple-bus;
interrupt-parent = mpic;
-   ranges = 0 0xd000 0x10;
+   ranges = 0 0 0xd000 0x10;
 
internal-regs {
compatible = simple-bus;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index fbd0f04..a2dd24e 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -26,7 +26,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x8000; /* 2 GB */
+   reg = 0 0x 0 0x8000; /* 2 GB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts 
b/arch/arm/boot/dts/armada-xp-gp.dts
index b0298d7..b022906 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -26,14 +26,16 @@
 
memory {
device_type = memory;
-
/*
-* 4 GB of plug-in RAM modules by default but only 3GB
-* are visible, the amount of memory available can be
-* changed by the bootloader according the size of the
-* module actually plugged
+ * 8 GB of plug-in RAM modules by default.The amount
+ * of memory available can be changed by the
+ * bootloader according the size of the module
+ * actually plugged. Only 7GB are usable because
+ * addresses from 0xC000 to 0x are used by
+ * the internal registers of the SoC.
 */
-   reg = 0x 0xC000;
+   reg = 0x 0x 0x 0xC000,
+ 0x0001 0x 0x0001 0x;
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts 
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index e2eaf4f..1f274e7 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -23,7 +23,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0xC000; /* 3 GB */
+   reg = 0 0x 0 0xC000; /* 3 GB */
};
 
soc {
-- 
1.7.9.5

--
To unsubscribe from this list

[PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is selected

2013-04-05 Thread Gregory CLEMENT

When LPAE is activated on Armada XP, all registers and IOs are still
32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
That means that all the DMA transfer are restricted to the low 32 bits
address space. This is limitation is achieved by selecting ZONE_DMA.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/mach-mvebu/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..db1bbc8 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -13,6 +13,7 @@ config ARCH_MVEBU
select MVEBU_CLK_CORE
select MVEBU_CLK_CPU
select MVEBU_CLK_GATING
+   select ZONE_DMA if ARM_LPAE
 
 if ARCH_MVEBU
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/9] arm: mvebu: Enable pj4b on LPAE compilations

2013-04-05 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

pj4b cpus are LPAE capable so enable them on LPAE compilations

Signed-off-by: Lior Amsalem al...@marvell.com
Tested-by: Franklin f...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/mm/proc-v7.S |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3a3c015..159c747 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -402,6 +402,8 @@ __v7_ca9mp_proc_info:
__v7_proc __v7_ca9mp_setup
.size   __v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
 
+#endif /* CONFIG_ARM_LPAE */
+
/*
 * Marvell PJ4B processor.
 */
@@ -411,7 +413,6 @@ __v7_pj4b_proc_info:
.long   0xfff0
__v7_proc __v7_pj4b_setup
.size   __v7_pj4b_proc_info, . - __v7_pj4b_proc_info
-#endif /* CONFIG_ARM_LPAE */
 
/*
 * ARM Ltd. Cortex A7 processor.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/9] arm: mvebu: Align the internal registers virtual base to support LPAE

2013-04-05 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

In order to be able to support he LPAE, the internal registers virtual
base must be aligned to 2MB.

Signed-off-by: Lior Amsalem al...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/include/debug/mvebu.S  |2 +-
 arch/arm/mach-mvebu/armada-370-xp.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 865c6d0..df191af 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -12,7 +12,7 @@
 */
 
 #define ARMADA_370_XP_REGS_PHYS_BASE   0xd000
-#define ARMADA_370_XP_REGS_VIRT_BASE   0xfeb0
+#define ARMADA_370_XP_REGS_VIRT_BASE   0xfec0
 
.macro  addruart, rp, rv, tmp
ldr \rp, =ARMADA_370_XP_REGS_PHYS_BASE
diff --git a/arch/arm/mach-mvebu/armada-370-xp.h 
b/arch/arm/mach-mvebu/armada-370-xp.h
index c6a7d74..c49c08e 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.h
+++ b/arch/arm/mach-mvebu/armada-370-xp.h
@@ -16,7 +16,7 @@
 #define __MACH_ARMADA_370_XP_H
 
 #define ARMADA_370_XP_REGS_PHYS_BASE   0xd000
-#define ARMADA_370_XP_REGS_VIRT_BASE   IOMEM(0xfeb0)
+#define ARMADA_370_XP_REGS_VIRT_BASE   IOMEM(0xfec0)
 #define ARMADA_370_XP_REGS_SIZESZ_1M
 
 #ifdef CONFIG_SMP
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 5/9] arm: dts: mvebu: move all peripherals inside soc

2013-04-05 Thread Gregory CLEMENT

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-xp.dtsi |   26 +-
 arch/arm/boot/dts/armada-370.dtsi|   23 ---
 arch/arm/boot/dts/armada-xp.dtsi |   32 
 3 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 5b70820..bd26c48 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,19 +28,6 @@
};
};
 
-   mpic: interrupt-controller@d002 {
- compatible = marvell,mpic;
- #interrupt-cells = 1;
- #size-cells = 1;
- interrupt-controller;
-   };
-
-   coherency-fabric@d0020200 {
-   compatible = marvell,coherency-fabric;
-   reg = 0xd0020200 0xb0,
- 0xd0021810 0x1c;
-   };
-
soc {
#address-cells = 1;
#size-cells = 1;
@@ -48,6 +35,19 @@
interrupt-parent = mpic;
ranges;
 
+   mpic: interrupt-controller@d002 {
+   compatible = marvell,mpic;
+   #interrupt-cells = 1;
+   #size-cells = 1;
+   interrupt-controller;
+   };
+
+   coherency-fabric@d0020200 {
+   compatible = marvell,coherency-fabric;
+   reg = 0xd0020200 0xb0,
+ 0xd0021810 0x1c;
+   };
+
serial@d0012000 {
compatible = snps,dw-apb-uart;
reg = 0xd0012000 0x100;
diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index 8188d13..03808aa 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -20,12 +20,6 @@
 / {
model = Marvell Armada 370 family SoC;
compatible = marvell,armada370, marvell,armada-370-xp;
-   L2: l2-cache {
-   compatible = marvell,aurora-outer-cache;
-   reg = 0xd0008000 0x1000;
-   cache-id-part = 0x100;
-   wt-override;
-   };
 
aliases {
gpio0 = gpio0;
@@ -33,17 +27,24 @@
gpio2 = gpio2;
};
 
-   mpic: interrupt-controller@d002 {
- reg = 0xd0020a00 0x1d0,
-   0xd0021870 0x58;
-   };
-
soc {
+   mpic: interrupt-controller@d002 {
+   reg = 0xd0020a00 0x1d0,
+ 0xd0021870 0x58;
+   };
+
system-controller@d0018200 {
compatible = 
marvell,armada-370-xp-system-controller;
reg = 0xd0018200 0x100;
};
 
+   L2: l2-cache {
+   compatible = marvell,aurora-outer-cache;
+   reg = 0xd0008000 0x1000;
+   cache-id-part = 0x100;
+   wt-override;
+   };
+
pinctrl {
compatible = marvell,mv88f6710-pinctrl;
reg = 0xd0018000 0x38;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index ca00d83..e644cc5 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,25 +22,25 @@
model = Marvell Armada XP family SoC;
compatible = marvell,armadaxp, marvell,armada-370-xp;
 
-   L2: l2-cache {
-   compatible = marvell,aurora-system-cache;
-   reg = 0xd0008000 0x1000;
-   cache-id-part = 0x100;
-   wt-override;
-   };
+   soc {
+   L2: l2-cache {
+   compatible = marvell,aurora-system-cache;
+   reg = 0xd0008000 0x1000;
+   cache-id-part = 0x100;
+   wt-override;
+   };
 
-   mpic: interrupt-controller@d002 {
- reg = 0xd0020a00 0x2d0,
-   0xd0021070 0x58;
-   };
+   mpic: interrupt-controller@d002 {
+ reg = 0xd0020a00 0x2d0,
+   0xd0021070 0x58;
+   };
 
-   armada-370-xp-pmsu@d0022000 {
-   compatible = marvell,armada-370-xp-pmsu;
-   reg = 0xd0022100 0x430,
- 0xd0020800 0x20;
-   };
+   armada-370-xp-pmsu@d0022000 {
+   compatible = marvell,armada-370-xp-pmsu;
+   reg = 0xd0022100 0x430,
+ 0xd0020800 0x20;
+   };
 
-   soc {
serial@d0012200 {
compatible =

[PATCH v2 4/9] arm: dts: Add a 64 bits version of the skeleton device tree

2013-04-05 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

In order to be able to use more than 4GB address-cells and size-cells
have to be set to 2

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Lior Amsalem al...@marvell.com
---
 arch/arm/boot/dts/skeleton64.dtsi |   13 +
 1 file changed, 13 insertions(+)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

diff --git a/arch/arm/boot/dts/skeleton64.dtsi 
b/arch/arm/boot/dts/skeleton64.dtsi
new file mode 100644
index 000..1599415
--- /dev/null
+++ b/arch/arm/boot/dts/skeleton64.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree in the 64 bits version; the bare minimum
+ * needed to boot; just include and add a compatible value.  The
+ * bootloader will typically populate the memory node.
+ */
+
+/ {
+   #address-cells = 2;
+   #size-cells = 2;
+   chosen { };
+   aliases { };
+   memory { device_type = memory; reg = 0 0; };
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/9] arm: dts: mvebu: introduce internal-regs node

2013-04-05 Thread Gregory CLEMENT

On 04/05/2013 10:43 PM, Arnd Bergmann wrote:
 On Friday 05 April 2013, Gregory CLEMENT wrote:
 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 
 The patch looks good but the description is a bit short.
 

It cannot be more brief! :)

I explained the purpose of this patch in the cover letter and forgot to
add this explanation here.

I will expand it for next version.

Thanks.
   Arnd
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/9] arm: mvebu: Limit the DMA zone when LPAE is selected

2013-04-05 Thread Gregory CLEMENT

On 04/05/2013 10:41 PM, Arnd Bergmann wrote:
 On Friday 05 April 2013, Gregory CLEMENT wrote:
 When LPAE is activated on Armada XP, all registers and IOs are still
 32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
 That means that all the DMA transfer are restricted to the low 32 bits
 address space. This is limitation is achieved by selecting ZONE_DMA.

 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 
 
 Shouldn't that be ZONE_DMA32?
 

Well common code for ARM don't manage the ZONE_DMA32. Whereas with
ZONE_DMA, setup_dma_zone() in arch/arm/mm/init.c does exactly what
I want: setting arm_dma_limit to 0x.

ZONE_DMA32 is used on arm64 however.

   Arnd
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/9] rm: mvebu: Enable LPAE support for Armada XP SoCs

2013-04-05 Thread Gregory CLEMENT

On 04/05/2013 10:46 PM, Arnd Bergmann wrote:
 On Friday 05 April 2013, Gregory CLEMENT wrote:
 The Armada XP SoCs have LPAE support. This is the second version patch
 set whixh allow to run kernel on this SoCs with LPAE support.

 The biggest changes are the conversion of the device tree file to 64
 bits in order to be able to use more than 4GB of memory (without this
 the LPAE is pointless).

 
 The series looks good overall, I've commented on trivial details.

So there is still hope to have this patch set in 3.10 :)

 
 Also, please use ARM: mvebu: ... in the subject rather than the lower-case
 version.

OK I will, but I saw a lot of 'arm' written in lower-case int the subject of 
emails
on the LAKML.
 
   Arnd
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/9] arm: mvebu: Align the internal registers virtual base to support LPAE

2013-04-05 Thread Gregory CLEMENT

On 04/05/2013 10:50 PM, Arnd Bergmann wrote:
 On Friday 05 April 2013, Gregory CLEMENT wrote:
 From: Lior Amsalem al...@marvell.com

 In order to be able to support he LPAE, the internal registers virtual
 base must be aligned to 2MB.

 Signed-off-by: Lior Amsalem al...@marvell.com
 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 
 This is a surprising limitation. Can you extend the above text to go into more
 detail where that alignment requirement comes from?
 

The explanation I had was that in LPAE section size is 2MB, in earlyprintk we 
map
the internal registers and it must be section aligned.

   Arnd
 
 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 5/9] ARM: dts: Add a 64 bits version of the skeleton device tree

2013-04-08 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

In order to be able to use more than 4GB address-cells and size-cells
have to be set to 2

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Lior Amsalem al...@marvell.com
---
 arch/arm/boot/dts/skeleton64.dtsi |   13 +
 1 file changed, 13 insertions(+)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

diff --git a/arch/arm/boot/dts/skeleton64.dtsi 
b/arch/arm/boot/dts/skeleton64.dtsi
new file mode 100644
index 000..1599415
--- /dev/null
+++ b/arch/arm/boot/dts/skeleton64.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree in the 64 bits version; the bare minimum
+ * needed to boot; just include and add a compatible value.  The
+ * bootloader will typically populate the memory node.
+ */
+
+/ {
+   #address-cells = 2;
+   #size-cells = 2;
+   chosen { };
+   aliases { };
+   memory { device_type = memory; reg = 0 0; };
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 8/9] ARM: dts: mvebu: introduce internal-regs node

2013-04-08 Thread Gregory CLEMENT

Introduce a 'internal-regs' subnode, under which all devices are
moved. This is not really needed for now, but will be for the
mvebu-mbus driver. This generates a lot of code movement since it's
indenting by one more tab all the devices.  So it was a good
opportunity to fix all the bad indentation.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts  |  108 +-
 arch/arm/boot/dts/armada-370-mirabox.dts |   78 
 arch/arm/boot/dts/armada-370-rd.dts  |2 +
 arch/arm/boot/dts/armada-370-xp.dtsi |  228 +++---
 arch/arm/boot/dts/armada-370.dtsi|  219 +++--
 arch/arm/boot/dts/armada-xp-db.dts   |  154 +++
 arch/arm/boot/dts/armada-xp-gp.dts   |  124 ++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   56 +++---
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   80 
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   80 
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  196 ++-
 arch/arm/boot/dts/armada-xp.dtsi |  182 +
 12 files changed, 763 insertions(+), 744 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 183901c..6c30a9f 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,68 +30,70 @@
};
 
soc {
-   serial@12000 {
-   clock-frequency = 2;
-   status = okay;
-   };
-   sata@a {
-   nr-ports = 2;
-   status = okay;
-   };
-
-   mdio {
-   phy0: ethernet-phy@0 {
-   reg = 0;
+   internal-regs {
+   serial@12000 {
+   clock-frequency = 2;
+   status = okay;
+   };
+   sata@a {
+   nr-ports = 2;
+   status = okay;
};
 
-   phy1: ethernet-phy@1 {
-   reg = 1;
+   mdio {
+   phy0: ethernet-phy@0 {
+   reg = 0;
+   };
+
+   phy1: ethernet-phy@1 {
+   reg = 1;
+   };
};
-   };
 
-   ethernet@7 {
-   status = okay;
-   phy = phy0;
-   phy-mode = rgmii-id;
-   };
-   ethernet@74000 {
-   status = okay;
-   phy = phy1;
-   phy-mode = rgmii-id;
-   };
+   ethernet@7 {
+   status = okay;
+   phy = phy0;
+   phy-mode = rgmii-id;
+   };
+   ethernet@74000 {
+   status = okay;
+   phy = phy1;
+   phy-mode = rgmii-id;
+   };
 
-   mvsdio@d4000 {
-   pinctrl-0 = sdio_pins1;
-   pinctrl-names = default;
-   /*
-* This device is disabled by default, because
-* using the SD card connector requires
-* changing the default CON40 connector
-* DB-88F6710_MPP_2xRGMII_DEVICE_Jumper to a
-* different connector
-* DB-88F6710_MPP_RGMII_SD_Jumper.
-*/
-   status = disabled;
-   /* No CD or WP GPIOs */
-   };
+   mvsdio@d4000 {
+   pinctrl-0 = sdio_pins1;
+   pinctrl-names = default;
+   /*
+* This device is disabled by default, because
+* using the SD card connector requires
+* changing the default CON40 connector
+* DB-88F6710_MPP_2xRGMII_DEVICE_Jumper to a
+* different connector
+* DB-88F6710_MPP_RGMII_SD_Jumper.
+*/
+   status = disabled;
+   /* No CD or WP GPIOs */
+   };
 
-   usb@5 {
-   status = okay

[PATCH v3 9/9] ARM: dts: mvebu: Convert mvebu device tree files to 64 bits

2013-04-08 Thread Gregory CLEMENT

In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.

Only Armada XP is LPAE capable, but as it shares a common dtsi file
with Armada 370, then the common file include the skeleton64. Thanks
to the use of the overload capability of the device tree format,
armada-370 include the 32 bit skeleton and all the armada 370 based
dts can remain the same.

This was heavily based on the work of Lior Amsalem.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-xp.dtsi |4 ++--
 arch/arm/boot/dts/armada-370.dtsi|2 ++
 arch/arm/boot/dts/armada-xp-db.dts   |2 +-
 arch/arm/boot/dts/armada-xp-gp.dts   |   14 --
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 +-
 5 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 8b9adc6..6a3b418 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -16,7 +16,7 @@
  * 370 and Armada XP SoC.
  */
 
-/include/ skeleton.dtsi
+/include/ skeleton64.dtsi
 
 / {
model = Marvell Armada 370 and XP SoC;
@@ -33,7 +33,7 @@
#size-cells = 1;
compatible = simple-bus;
interrupt-parent = mpic;
-   ranges = 0 0xd000 0x10;
+   ranges = 0 0 0xd000 0x10;
 
internal-regs {
compatible = simple-bus;
diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index 9ae6053..7fc18e7 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -16,6 +16,7 @@
  */
 
 /include/ armada-370-xp.dtsi
+/include/ skeleton.dtsi
 
 / {
model = Marvell Armada 370 family SoC;
@@ -28,6 +29,7 @@
};
 
soc {
+   ranges = 0 0xd000 0x10;
internal-regs {
system-controller@18200 {
compatible = 
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index fbd0f04..a2dd24e 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -26,7 +26,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x8000; /* 2 GB */
+   reg = 0 0x 0 0x8000; /* 2 GB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts 
b/arch/arm/boot/dts/armada-xp-gp.dts
index b0298d7..b022906 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -26,14 +26,16 @@
 
memory {
device_type = memory;
-
/*
-* 4 GB of plug-in RAM modules by default but only 3GB
-* are visible, the amount of memory available can be
-* changed by the bootloader according the size of the
-* module actually plugged
+ * 8 GB of plug-in RAM modules by default.The amount
+ * of memory available can be changed by the
+ * bootloader according the size of the module
+ * actually plugged. Only 7GB are usable because
+ * addresses from 0xC000 to 0x are used by
+ * the internal registers of the SoC.
 */
-   reg = 0x 0xC000;
+   reg = 0x 0x 0x 0xC000,
+ 0x0001 0x 0x0001 0x;
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts 
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index e2eaf4f..1f274e7 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -23,7 +23,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0xC000; /* 3 GB */
+   reg = 0 0x 0 0xC000; /* 3 GB */
};
 
soc {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/9] ARM: mvebu: Limit the DMA zone when LPAE is selected

2013-04-08 Thread Gregory CLEMENT

When LPAE is activated on Armada XP, all registers and IOs are still
32bit, the 40bit extension is on the CPU to DRAM path (windows) only.
That means that all the DMA transfer are restricted to the low 32 bits
address space. This is limitation is achieved by selecting ZONE_DMA.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/mach-mvebu/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..db1bbc8 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -13,6 +13,7 @@ config ARCH_MVEBU
select MVEBU_CLK_CORE
select MVEBU_CLK_CPU
select MVEBU_CLK_GATING
+   select ZONE_DMA if ARM_LPAE
 
 if ARCH_MVEBU
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 4/9] ARM: mvebu: Enable pj4b on LPAE compilations

2013-04-08 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

pj4b cpus are LPAE capable so enable them on LPAE compilations

Signed-off-by: Lior Amsalem al...@marvell.com
Tested-by: Franklin f...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/mm/proc-v7.S |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index f584d3f..d75dc67 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -402,6 +402,8 @@ __v7_ca9mp_proc_info:
__v7_proc __v7_ca9mp_setup
.size   __v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
 
+#endif /* CONFIG_ARM_LPAE */
+
/*
 * Marvell PJ4B processor.
 */
@@ -411,7 +413,6 @@ __v7_pj4b_proc_info:
.long   0xfff0
__v7_proc __v7_pj4b_setup
.size   __v7_pj4b_proc_info, . - __v7_pj4b_proc_info
-#endif /* CONFIG_ARM_LPAE */
 
/*
 * ARM Ltd. Cortex A7 processor.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 7/9] ARM: dts: mvebu: Convert all the mvebu files to use the range property

2013-04-08 Thread Gregory CLEMENT

This conversion will allow to keep 32 bits addresses for the internal
registers whereas the memory of the system will be 64 bits.
Later it will also ease the move of the mvebu-mbus driver to the
device tree support.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts  |   16 ++---
 arch/arm/boot/dts/armada-370-mirabox.dts |   14 ++--
 arch/arm/boot/dts/armada-370-rd.dts  |   14 ++--
 arch/arm/boot/dts/armada-370-xp.dtsi |   83 +++---
 arch/arm/boot/dts/armada-370.dtsi|   49 ++---
 arch/arm/boot/dts/armada-xp-db.dts   |   28 
 arch/arm/boot/dts/armada-xp-gp.dts   |   20 +++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   10 +--
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   18 ++---
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   18 ++---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |   22 +++---
 arch/arm/boot/dts/armada-xp.dtsi |   65 -
 12 files changed, 180 insertions(+), 177 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..183901c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,11 +30,11 @@
};
 
soc {
-   serial@d0012000 {
+   serial@12000 {
clock-frequency = 2;
status = okay;
};
-   sata@d00a {
+   sata@a {
nr-ports = 2;
status = okay;
};
@@ -49,18 +49,18 @@
};
};
 
-   ethernet@d007 {
+   ethernet@7 {
status = okay;
phy = phy0;
phy-mode = rgmii-id;
};
-   ethernet@d0074000 {
+   ethernet@74000 {
status = okay;
phy = phy1;
phy-mode = rgmii-id;
};
 
-   mvsdio@d00d4000 {
+   mvsdio@d4000 {
pinctrl-0 = sdio_pins1;
pinctrl-names = default;
/*
@@ -75,15 +75,15 @@
/* No CD or WP GPIOs */
};
 
-   usb@d005 {
+   usb@5 {
status = okay;
};
 
-   usb@d0051000 {
+   usb@51000 {
status = okay;
};
 
-   spi0: spi@d0010600 {
+   spi0: spi@10600 {
status = okay;
 
spi-flash@0 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts 
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 3234875..77dfec7 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,11 +25,11 @@
};
 
soc {
-   serial@d0012000 {
+   serial@12000 {
clock-frequency = 2;
status = okay;
};
-   timer@d0020300 {
+   timer@20300 {
clock-frequency = 6;
status = okay;
};
@@ -42,18 +42,18 @@
reg = 1;
};
};
-   ethernet@d007 {
+   ethernet@7 {
status = okay;
phy = phy0;
phy-mode = rgmii-id;
};
-   ethernet@d0074000 {
+   ethernet@74000 {
status = okay;
phy = phy1;
phy-mode = rgmii-id;
};
 
-   mvsdio@d00d4000 {
+   mvsdio@d4000 {
pinctrl-0 = sdio_pins3;
pinctrl-names = default;
status = okay;
@@ -63,11 +63,11 @@
 */
};
 
-   usb@d005 {
+   usb@5 {
status = okay;
};
 
-   usb@d0051000 {
+   usb@51000 {
status = okay;
};
};
diff --git a/arch/arm/boot/dts/armada-370-rd.dts 
b/arch/arm/boot/dts/armada-370-rd.dts
index 070bba4..be209020 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,11 +28,11 @@
};
 
soc {
-   serial@d0012000 {
+   serial@12000 {
clock-frequency = 2;
status = okay;
};
-   sata@d00a

[PATCH v3 6/9] ARM: dts: mvebu: move all peripherals inside soc

2013-04-08 Thread Gregory CLEMENT

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

reorganize the .dts and .dtsi files so that all devices are under the
soc { } node (currently some devices such as the interrupt controller,
the L2 cache and a few others are outside).

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-xp.dtsi |   26 +-
 arch/arm/boot/dts/armada-370.dtsi|   23 ---
 arch/arm/boot/dts/armada-xp.dtsi |   32 
 3 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 5b70820..bd26c48 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,19 +28,6 @@
};
};
 
-   mpic: interrupt-controller@d002 {
- compatible = marvell,mpic;
- #interrupt-cells = 1;
- #size-cells = 1;
- interrupt-controller;
-   };
-
-   coherency-fabric@d0020200 {
-   compatible = marvell,coherency-fabric;
-   reg = 0xd0020200 0xb0,
- 0xd0021810 0x1c;
-   };
-
soc {
#address-cells = 1;
#size-cells = 1;
@@ -48,6 +35,19 @@
interrupt-parent = mpic;
ranges;
 
+   mpic: interrupt-controller@d002 {
+   compatible = marvell,mpic;
+   #interrupt-cells = 1;
+   #size-cells = 1;
+   interrupt-controller;
+   };
+
+   coherency-fabric@d0020200 {
+   compatible = marvell,coherency-fabric;
+   reg = 0xd0020200 0xb0,
+ 0xd0021810 0x1c;
+   };
+
serial@d0012000 {
compatible = snps,dw-apb-uart;
reg = 0xd0012000 0x100;
diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index a195deb..9bc092b 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -20,12 +20,6 @@
 / {
model = Marvell Armada 370 family SoC;
compatible = marvell,armada370, marvell,armada-370-xp;
-   L2: l2-cache {
-   compatible = marvell,aurora-outer-cache;
-   reg = 0xd0008000 0x1000;
-   cache-id-part = 0x100;
-   wt-override;
-   };
 
aliases {
gpio0 = gpio0;
@@ -33,17 +27,24 @@
gpio2 = gpio2;
};
 
-   mpic: interrupt-controller@d002 {
- reg = 0xd0020a00 0x1d0,
-   0xd0021870 0x58;
-   };
-
soc {
+   mpic: interrupt-controller@d002 {
+   reg = 0xd0020a00 0x1d0,
+ 0xd0021870 0x58;
+   };
+
system-controller@d0018200 {
compatible = 
marvell,armada-370-xp-system-controller;
reg = 0xd0018200 0x100;
};
 
+   L2: l2-cache {
+   compatible = marvell,aurora-outer-cache;
+   reg = 0xd0008000 0x1000;
+   cache-id-part = 0x100;
+   wt-override;
+   };
+
pinctrl {
compatible = marvell,mv88f6710-pinctrl;
reg = 0xd0018000 0x38;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index ca00d83..e644cc5 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,25 +22,25 @@
model = Marvell Armada XP family SoC;
compatible = marvell,armadaxp, marvell,armada-370-xp;
 
-   L2: l2-cache {
-   compatible = marvell,aurora-system-cache;
-   reg = 0xd0008000 0x1000;
-   cache-id-part = 0x100;
-   wt-override;
-   };
+   soc {
+   L2: l2-cache {
+   compatible = marvell,aurora-system-cache;
+   reg = 0xd0008000 0x1000;
+   cache-id-part = 0x100;
+   wt-override;
+   };
 
-   mpic: interrupt-controller@d002 {
- reg = 0xd0020a00 0x2d0,
-   0xd0021070 0x58;
-   };
+   mpic: interrupt-controller@d002 {
+ reg = 0xd0020a00 0x2d0,
+   0xd0021070 0x58;
+   };
 
-   armada-370-xp-pmsu@d0022000 {
-   compatible = marvell,armada-370-xp-pmsu;
-   reg = 0xd0022100 0x430,
- 0xd0020800 0x20;
-   };
+   armada-370-xp-pmsu@d0022000 {
+   compatible = marvell,armada-370-xp-pmsu;
+   reg

[PATCH v3 0/9] ARM: mvebu: Enable LPAE support for Armada XP SoCs

2013-04-08 Thread Gregory CLEMENT

Hello,

The Armada XP SoCs have LPAE support. This is the third patch set
which allows to run kernel on this SoCs with LPAE support.

The biggest changes are the conversion of the device tree file to 64
bits in order to be able to use more than 4GB of memory (without this
the LPAE is pointless).

They are two kinds of change:
- most of the change are on the commit log, according to Arnd
comments.

- the other change was made on the patch ARM: dts: mvebu: Convert
  mvebu device tree files to 64 bits. I managed to not have to use
  the 64 bits format for the Armada 370 device tree files.

This patch set won't be the last one, as to ease the merge work of
Jason, I will rebase this series onto his dts branch once he will have
pull the pending commits. Beside this rebase nothing will be changed,
that why I would like to start to get the acked-by from Rob Herring
and Arnd Bergmann for this series(both of them made comments so they
must have an opinion on this last version). I am also submitting the
patch ARM: mvebu: Enable pj4b on LPAE compilations to Russell King's
patch system as I didn't receive any complaint about it, and it is a
pretty trivial patch.

This new patch set have been tested on a Armada XP GP board with 8GB
of DRAM with LPAE selected. It have been tested on Armada XP DB board
with 3GB of DRAM with and without LPAE. And also on the Armada 370 DB
board (without LPAE) to check that no regression appeared.

This patch set is based on 3.9-rc6 and is still 3.10 material. The git
branch called lpae-v3 is available at:

https://github.com/MISL-EBU-System-SW/mainline-public.git.

Thanks,

Changelog:
v2 - v3:

* Pass all the arm architecture word in uppercase in the commit titles.

* Add a commit message to ARM: dts: mvebu: move all peripherals
  inside soc and move it at first patch of the series.

* Add a commit message to  ARM: dts: mvebu: move all peripherals
  inside soc

* Add a commit message to ARM: dts: mvebu: introduce internal-regs
   node

* Add more explanation to ARM: mvebu: Align the internal registers
  virtual base to support LPAE

* In patch ARM: dts: mvebu: Convert all the mvebu files to use the
  range property thanks to the use of the overload capability of the
  device tree format, armada-370 now includes the 32 bit skeleton and
  all the armada 370 based dts can remain the same.

v1 - v2:

* The patch to convert the mvebu device tree files to 64 bits was
  split in 3 parts:

- arm: dts: move all peripherals inside soc from Thomas

- then arm: dts: Convert all the mvebu files to use the range
property which will allow to keep 32 bits addresses for the
internal registers whereas the memory of the system will be 64
bits

- and finally arm: dts: Convert mvebu device tree files to 64
  bits which was the move to 64 bits itself.

* A new patch was added arm: dts: introduce internal-regs node based
  on the work of Thomas for the mvebu-mbus driver. It introduce a
  'internal-regs' subnode, under which all devices are moved. This is
  not really needed for now, but will be for the mvebu-mbus
  driver. This generates a lot of code movement since it's indenting
  by one more tab all the devices. So it was a good opportunity to fix
  all the bad indentation.

* New patch from Thomas fix cpus section indentation to finalize the
  fixing of the bad indentation

* For DMA transfer, DMA_ZONE was selected instead of DMABOUNCE: all
  the DMA transfer are restricted to the low 32 bits address space.

Gregory CLEMENT (4):
  ARM: mvebu: Limit the DMA zone when LPAE is selected
  ARM: dts: mvebu: Convert all the mvebu files to use the range
property
  ARM: dts: mvebu: introduce internal-regs node
  ARM: dts: mvebu: Convert mvebu device tree files to 64 bits

Lior Amsalem (3):
  ARM: mvebu: Align the internal registers virtual base to support LPAE
  ARM: mvebu: Enable pj4b on LPAE compilations
  ARM: dts: Add a 64 bits version of the skeleton device tree

Thomas Petazzoni (2):
  ARM: dts: mvebu: fix cpus section indentation
  ARM: dts: mvebu: move all peripherals inside soc

 arch/arm/boot/dts/armada-370-db.dts  |  108 -
 arch/arm/boot/dts/armada-370-mirabox.dts |   78 +++
 arch/arm/boot/dts/armada-370-rd.dts  |   16 +-
 arch/arm/boot/dts/armada-370-xp.dtsi |  253 +++---
 arch/arm/boot/dts/armada-370.dtsi|  223 +--
 arch/arm/boot/dts/armada-xp-db.dts   |  156 ++---
 arch/arm/boot/dts/armada-xp-gp.dts   |  138 ++--
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   84 +++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |  110 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |  136 ++--
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  198 -
 arch/arm/boot/dts/armada-xp.dtsi |  191 
 arch/arm/boot/dts/skeleton64.dtsi|   13

[PATCH v3 3/9] ARM: mvebu: Align the internal registers virtual base to support LPAE

2013-04-08 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

In order to be able to support the LPAE, the internal registers
virtual base must be aligned to 2MB. In LPAE section size is 2MB, in
earlyprintk we map the internal registers and it must be section
aligned.

Signed-off-by: Lior Amsalem al...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/include/debug/mvebu.S  |2 +-
 arch/arm/mach-mvebu/armada-370-xp.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 865c6d0..df191af 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -12,7 +12,7 @@
 */
 
 #define ARMADA_370_XP_REGS_PHYS_BASE   0xd000
-#define ARMADA_370_XP_REGS_VIRT_BASE   0xfeb0
+#define ARMADA_370_XP_REGS_VIRT_BASE   0xfec0
 
.macro  addruart, rp, rv, tmp
ldr \rp, =ARMADA_370_XP_REGS_PHYS_BASE
diff --git a/arch/arm/mach-mvebu/armada-370-xp.h 
b/arch/arm/mach-mvebu/armada-370-xp.h
index c6a7d74..c49c08e 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.h
+++ b/arch/arm/mach-mvebu/armada-370-xp.h
@@ -16,7 +16,7 @@
 #define __MACH_ARMADA_370_XP_H
 
 #define ARMADA_370_XP_REGS_PHYS_BASE   0xd000
-#define ARMADA_370_XP_REGS_VIRT_BASE   IOMEM(0xfeb0)
+#define ARMADA_370_XP_REGS_VIRT_BASE   IOMEM(0xfec0)
 #define ARMADA_370_XP_REGS_SIZESZ_1M
 
 #ifdef CONFIG_SMP
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 1/9] ARM: dts: mvebu: fix cpus section indentation

2013-04-08 Thread Gregory CLEMENT

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

Align the cpu node indentation with the rest of the file

[gc]: added a commit description
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   28 
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   28 
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   54 +++---
 3 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index f56c405..50180eb 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -25,22 +25,22 @@
};
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
+   #address-cells = 1;
+   #size-cells = 0;
 
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
 
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index f8f2b78..3c433d5 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -26,22 +26,22 @@
};
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
+   #address-cells = 1;
+   #size-cells = 0;
 
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
 
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 936c25d..4c38e942 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -27,36 +27,36 @@
 
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
+   #address-cells = 1;
+   #size-cells = 0;
 
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
 
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
 
-   cpu@2 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 2;
-   clocks = cpuclk 2;
-   };
+   cpu@2 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 2;
+   clocks = cpuclk 2;
+   };
 
-   cpu@3 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 3;
-   clocks = cpuclk 3;
-   };
+   cpu@3 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 3;
+   clocks = cpuclk 3;
+   };
};
 
soc {
@@ -112,4 +112,4 @@

Re: [PATCH] clk: Add device tree binding to clk-fixed-factor

2013-04-10 Thread Gregory CLEMENT

Hi Christian,

On 04/10/2013 05:40 PM, Christian Ruppert wrote:
 This patch adds a device tree binding for the simple fixed factor clock
 divider/multiplier of the common clock tree binding.

This patch remind me of something :
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html

Do you have a use case for it, this time?

My version have been hold off waiting for an user for it.
Will you need it for a driver?

Regards,

 
 Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
 ---
  .../bindings/clock/fixed-factor-clkdiv.txt |   24 +++
  drivers/clk/clk-fixed-factor.c |   32 
 
  include/linux/clk-provider.h   |1 +
  3 files changed, 57 insertions(+), 0 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 
 diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt 
 b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 new file mode 100644
 index 000..352bac4
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 @@ -0,0 +1,24 @@
 +Device Tree Clock bindings for plat-tb10x
 +
 +This binding uses the common clock binding[1].
 +
 +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible : shall be fixed-factor-clkdiv
 +- #clock-cells: from common clock binding; shall be set to 0
 +- clocks: shall be the input parent clock phandle for the clock.
 +- clock-mult: defines the multiplication factor of the output clock frequency
 +  wrt. the input clock frequency.
 +- clock-div: defines the division factor of the output clock frequency wrt.
 +  the input clock frequency.
 +
 +Example:
 +cpu_clk: clkdiv_cpu {/* CPU clock derived from pll0. 1/2 of pll 
 frequency */
 + compatible = fixed-factor-clkdiv;
 + #clock-cells = 0;
 + clocks = pll0;
 + clock-mult = 1;
 + clock-div = 2;
 + clock-output-names = cpu_clk;
 +};
 diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
 index 1ef271e..85e45f1 100644
 --- a/drivers/clk/clk-fixed-factor.c
 +++ b/drivers/clk/clk-fixed-factor.c
 @@ -11,6 +11,7 @@
  #include linux/clk-provider.h
  #include linux/slab.h
  #include linux/err.h
 +#include linux/of.h
  
  /*
   * DOC: basic fixed multiplier and divider clock that cannot gate
 @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device *dev, 
 const char *name,
  
   return clk;
  }
 +
 +#ifdef CONFIG_OF
 +/**
 + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock divider
 + */
 +void of_fixed_factor_clkdiv_setup(struct device_node *node)
 +{
 + struct clk *clk;
 + const char *clk_name = node-name;
 + const char *parent_name;
 + u32 mult, div;
 +
 + if (of_property_read_u32(node, clock-mult, mult))
 + return;
 +
 + if (of_property_read_u32(node, clock-div, div))
 + return;
 +
 + parent_name = of_clk_get_parent_name(node, 0);
 +
 + of_property_read_string(node, clock-output-names, clk_name);
 +
 + clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
 + mult, div);
 + if (!IS_ERR(clk))
 + of_clk_add_provider(node, of_clk_src_simple_get, clk);
 +}
 +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
 +CLK_OF_DECLARE(fixed_clkdiv, fixed-factor-clkdiv,
 + of_fixed_factor_clkdiv_setup);
 +#endif
 diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
 index 7f197d7..d4937cf 100644
 --- a/include/linux/clk-provider.h
 +++ b/include/linux/clk-provider.h
 @@ -184,6 +184,7 @@ struct clk *clk_register_fixed_rate(struct device *dev, 
 const char *name,
   unsigned long fixed_rate);
  
  void of_fixed_clk_setup(struct device_node *np);
 +void of_fixed_factor_clkdiv_setup(struct device_node *node);
  
  /**
   * struct clk_gate - gating clock
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: Add device tree binding to clk-fixed-factor

2013-04-11 Thread Gregory CLEMENT

On 04/11/2013 11:19 AM, Christian Ruppert wrote:
 Hi Gregory,
 
 Since there doesn't seem to be anyone opposing this feature I just
 checked your patch and after adding the CLK_OF_DECLARE macro in the end
 it works well for us. Tell me if you would like to rebase and resubmit
 your patch or if I should follow up on our own.

I can rebase and resubmit my patch, it's pretty straightforward.
The problem was the lack of user in the kernel. And by user I mean
a driver using these functions. Usually a new function enter in the
kernel only if there are users for it inside the kernel so if you plan
to submit a driver using this piece of code, then I see no reason
to not get it.

 
 Greetings,
   Christian
 
 On Wed, Apr 10, 2013 at 06:27:47PM +0200, christian ruppert wrote:
 Hi Gregory,

 We use derived clocks with fixed ratios for our TB10x platform. I
 originally had this in the platform code but Vineet (the platform
 maintainer) rightly pointed out that the common clock framework would
 be the correct place for it.
 Is there any reason not to support this functionality? After all, the
 generic fixed rate clock also has a device tree binding and I'd guess
 we're not the only ones statically deriving one clock from another in
 our SOCs.

 Greetings,
   Christian

 On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
 Hi Christian,

 On 04/10/2013 05:40 PM, Christian Ruppert wrote:
 This patch adds a device tree binding for the simple fixed factor clock
 divider/multiplier of the common clock tree binding.

 This patch remind me of something :
 http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html

 Do you have a use case for it, this time?

 My version have been hold off waiting for an user for it.
 Will you need it for a driver?

 Regards,


 Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
 ---
  .../bindings/clock/fixed-factor-clkdiv.txt |   24 +++
  drivers/clk/clk-fixed-factor.c |   32 
 
  include/linux/clk-provider.h   |1 +
  3 files changed, 57 insertions(+), 0 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt

 diff --git 
 a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt 
 b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 new file mode 100644
 index 000..352bac4
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 @@ -0,0 +1,24 @@
 +Device Tree Clock bindings for plat-tb10x
 +
 +This binding uses the common clock binding[1].
 +
 +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible : shall be fixed-factor-clkdiv
 +- #clock-cells: from common clock binding; shall be set to 0
 +- clocks: shall be the input parent clock phandle for the clock.
 +- clock-mult: defines the multiplication factor of the output clock 
 frequency
 +  wrt. the input clock frequency.
 +- clock-div: defines the division factor of the output clock frequency 
 wrt.
 +  the input clock frequency.
 +
 +Example:
 +cpu_clk: clkdiv_cpu { /* CPU clock derived from pll0. 1/2 of pll 
 frequency */
 +  compatible = fixed-factor-clkdiv;
 +  #clock-cells = 0;
 +  clocks = pll0;
 +  clock-mult = 1;
 +  clock-div = 2;
 +  clock-output-names = cpu_clk;
 +};
 diff --git a/drivers/clk/clk-fixed-factor.c 
 b/drivers/clk/clk-fixed-factor.c
 index 1ef271e..85e45f1 100644
 --- a/drivers/clk/clk-fixed-factor.c
 +++ b/drivers/clk/clk-fixed-factor.c
 @@ -11,6 +11,7 @@
  #include linux/clk-provider.h
  #include linux/slab.h
  #include linux/err.h
 +#include linux/of.h
  
  /*
   * DOC: basic fixed multiplier and divider clock that cannot gate
 @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device 
 *dev, const char *name,
  
return clk;
  }
 +
 +#ifdef CONFIG_OF
 +/**
 + * of_fixed_factor_clkdiv_setup() - Set up simple fixed factor clock 
 divider
 + */
 +void of_fixed_factor_clkdiv_setup(struct device_node *node)
 +{
 +  struct clk *clk;
 +  const char *clk_name = node-name;
 +  const char *parent_name;
 +  u32 mult, div;
 +
 +  if (of_property_read_u32(node, clock-mult, mult))
 +  return;
 +
 +  if (of_property_read_u32(node, clock-div, div))
 +  return;
 +
 +  parent_name = of_clk_get_parent_name(node, 0);
 +
 +  of_property_read_string(node, clock-output-names, clk_name);
 +
 +  clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
 +  mult, div);
 +  if (!IS_ERR(clk))
 +  of_clk_add_provider(node, of_clk_src_simple_get, clk);
 +}
 +EXPORT_SYMBOL_GPL(of_fixed_factor_clkdiv_setup);
 +CLK_OF_DECLARE(fixed_clkdiv, fixed-factor-clkdiv,
 +  of_fixed_factor_clkdiv_setup);
 +#endif
 diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
 index 7f197d7..d4937cf 100644
 --- a/include/linux/clk-provider.h
 +++ b/include/linux/clk-provider.h

Re: [PATCH v3 4/9] ARM: mvebu: Enable pj4b on LPAE compilations

2013-04-11 Thread Gregory CLEMENT

Hi Jason,

On 04/11/2013 08:08 PM, Jason Cooper wrote:
 On Tue, Apr 09, 2013 at 12:52:12AM +0200, Gregory CLEMENT wrote:
 From: Lior Amsalem al...@marvell.com

 pj4b cpus are LPAE capable so enable them on LPAE compilations

 Signed-off-by: Lior Amsalem al...@marvell.com
 Tested-by: Franklin f...@marvell.com
 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 ---
  arch/arm/mm/proc-v7.S |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 Applied to mvebu/soc
 
 thx,
 
 Jason.
 

First thanks for pulling all these patches.

However, this one should go through Russell's git tree.  Or at least
you need his acked-by. I have already submit this patch on Russell
patch system. Unfortunately Russell told that he will be away for
around one week.

This patch is needed to have LPAE support, but all the other patches
don't depend on it. That means that if you applied all the other
patches it won't break anything even if at the end this patch is not
merged. But I really hope that Russell will be able to apply this
patch to his git tree.

Thanks

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 5/9] ARM: dts: Add a 64 bits version of the skeleton device tree

2013-04-11 Thread Gregory CLEMENT

Hi Jason,

On 04/11/2013 08:12 PM, Jason Cooper wrote:
 On Tue, Apr 09, 2013 at 12:52:13AM +0200, Gregory CLEMENT wrote:
 From: Lior Amsalem al...@marvell.com

 In order to be able to use more than 4GB address-cells and size-cells
 have to be set to 2

 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 Signed-off-by: Lior Amsalem al...@marvell.com
 ---
  arch/arm/boot/dts/skeleton64.dtsi |   13 +
  1 file changed, 13 insertions(+)
  create mode 100644 arch/arm/boot/dts/skeleton64.dtsi
 
 Applied to mvebu/dt
 
 Gregory,
 
 Once I can pull in Thomas' pci work, you'll just need to rebase patches
 1, and 6 - 9 against mvebu/dt.
 

Yes sure! When did you plan to pull the dts part of Thomas' pci work?
Is there still anything left to prevent to pull this part?

Thanks,
-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: Add device tree binding to clk-fixed-factor

2013-04-12 Thread Gregory CLEMENT

On 04/12/2013 08:54 AM, Christian Ruppert wrote:
 On Thu, Apr 11, 2013 at 06:26:07PM +0200, Gregory CLEMENT wrote:
 On 04/11/2013 11:19 AM, Christian Ruppert wrote:
 Hi Gregory,

 Since there doesn't seem to be anyone opposing this feature I just
 checked your patch and after adding the CLK_OF_DECLARE macro in the end
 it works well for us. Tell me if you would like to rebase and resubmit
 your patch or if I should follow up on our own.

 I can rebase and resubmit my patch, it's pretty straightforward.
 The problem was the lack of user in the kernel. And by user I mean
 a driver using these functions. Usually a new function enter in the
 kernel only if there are users for it inside the kernel so if you plan
 to submit a driver using this piece of code, then I see no reason
 to not get it.
 
 If you add the line
 
 CLK_OF_DECLARE(fixed_factor_clk, fixed-factor-clkdiv, 
 
 in the end of drivers/clk/clk-fixed-factor.c, the new function will be
 automatically used by of_clk_init(NULL) which itself is used in numerous
 platform ports, in particular arch/arc/plat-tb10x. plat-tb10x is currently
 being integrated in the ARC architecture tree. The device tree file
 requiring this patch is already in linux-next (see
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi).
 

great it is good to know there are user for this function.

 We didn't know if you wanted to resubmit your patch or if I should
 pursue mine at the time, and today it uses the naming scheme from mine.
 It would be nice if you could either adapt your patch to that naming
 scheme.

I am going to resubmit my patch this morning and adapt it to your naming
scheme.

Regards,


 
 Greetings,
   Christian
 
 Greetings,
   Christian

 On Wed, Apr 10, 2013 at 06:27:47PM +0200, christian ruppert wrote:
 Hi Gregory,

 We use derived clocks with fixed ratios for our TB10x platform. I
 originally had this in the platform code but Vineet (the platform
 maintainer) rightly pointed out that the common clock framework would
 be the correct place for it.
 Is there any reason not to support this functionality? After all, the
 generic fixed rate clock also has a device tree binding and I'd guess
 we're not the only ones statically deriving one clock from another in
 our SOCs.

 Greetings,
   Christian

 On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
 Hi Christian,

 On 04/10/2013 05:40 PM, Christian Ruppert wrote:
 This patch adds a device tree binding for the simple fixed factor clock
 divider/multiplier of the common clock tree binding.

 This patch remind me of something :
 http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html

 Do you have a use case for it, this time?

 My version have been hold off waiting for an user for it.
 Will you need it for a driver?

 Regards,


 Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
 ---
  .../bindings/clock/fixed-factor-clkdiv.txt |   24 
 +++
  drivers/clk/clk-fixed-factor.c |   32 
 
  include/linux/clk-provider.h   |1 +
  3 files changed, 57 insertions(+), 0 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt

 diff --git 
 a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt 
 b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 new file mode 100644
 index 000..352bac4
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 @@ -0,0 +1,24 @@
 +Device Tree Clock bindings for plat-tb10x
 +
 +This binding uses the common clock binding[1].
 +
 +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible : shall be fixed-factor-clkdiv
 +- #clock-cells: from common clock binding; shall be set to 0
 +- clocks: shall be the input parent clock phandle for the clock.
 +- clock-mult: defines the multiplication factor of the output clock 
 frequency
 +  wrt. the input clock frequency.
 +- clock-div: defines the division factor of the output clock frequency 
 wrt.
 +  the input clock frequency.
 +
 +Example:
 +cpu_clk: clkdiv_cpu {   /* CPU clock derived from pll0. 1/2 of pll 
 frequency */
 +compatible = fixed-factor-clkdiv;
 +#clock-cells = 0;
 +clocks = pll0;
 +clock-mult = 1;
 +clock-div = 2;
 +clock-output-names = cpu_clk;
 +};
 diff --git a/drivers/clk/clk-fixed-factor.c 
 b/drivers/clk/clk-fixed-factor.c
 index 1ef271e..85e45f1 100644
 --- a/drivers/clk/clk-fixed-factor.c
 +++ b/drivers/clk/clk-fixed-factor.c
 @@ -11,6 +11,7 @@
  #include linux/clk-provider.h
  #include linux/slab.h
  #include linux/err.h
 +#include linux/of.h
  
  /*
   * DOC: basic fixed multiplier and divider clock that cannot gate
 @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device 
 *dev, const char *name,
  
  return clk;
  }
 +
 +#ifdef

Re: [PATCH] clk: Add device tree binding to clk-fixed-factor

2013-04-12 Thread Gregory CLEMENT

On 04/12/2013 08:54 AM, Christian Ruppert wrote:
 On Thu, Apr 11, 2013 at 06:26:07PM +0200, Gregory CLEMENT wrote:
 On 04/11/2013 11:19 AM, Christian Ruppert wrote:
 Hi Gregory,

 Since there doesn't seem to be anyone opposing this feature I just
 checked your patch and after adding the CLK_OF_DECLARE macro in the end
 it works well for us. Tell me if you would like to rebase and resubmit
 your patch or if I should follow up on our own.

 I can rebase and resubmit my patch, it's pretty straightforward.
 The problem was the lack of user in the kernel. And by user I mean
 a driver using these functions. Usually a new function enter in the
 kernel only if there are users for it inside the kernel so if you plan
 to submit a driver using this piece of code, then I see no reason
 to not get it.
 
 If you add the line
 
 CLK_OF_DECLARE(fixed_factor_clk, fixed-factor-clkdiv, 

Why did you add the div suffix?

There is nothing in the function which prevent to have mul greater than
div and hence having a multiplicative factor.

I think that this suffix is misleading.

 
 in the end of drivers/clk/clk-fixed-factor.c, the new function will be
 automatically used by of_clk_init(NULL) which itself is used in numerous
 platform ports, in particular arch/arc/plat-tb10x. plat-tb10x is currently
 being integrated in the ARC architecture tree. The device tree file
 requiring this patch is already in linux-next (see
 https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi).
 
 We didn't know if you wanted to resubmit your patch or if I should
 pursue mine at the time, and today it uses the naming scheme from mine.
 It would be nice if you could either adapt your patch to that naming
 scheme.
 
 Greetings,
   Christian
 
 Greetings,
   Christian

 On Wed, Apr 10, 2013 at 06:27:47PM +0200, christian ruppert wrote:
 Hi Gregory,

 We use derived clocks with fixed ratios for our TB10x platform. I
 originally had this in the platform code but Vineet (the platform
 maintainer) rightly pointed out that the common clock framework would
 be the correct place for it.
 Is there any reason not to support this functionality? After all, the
 generic fixed rate clock also has a device tree binding and I'd guess
 we're not the only ones statically deriving one clock from another in
 our SOCs.

 Greetings,
   Christian

 On Wed, Apr 10, 2013 at 05:56:25PM +0200, Gregory CLEMENT wrote:
 Hi Christian,

 On 04/10/2013 05:40 PM, Christian Ruppert wrote:
 This patch adds a device tree binding for the simple fixed factor clock
 divider/multiplier of the common clock tree binding.

 This patch remind me of something :
 http://lists.infradead.org/pipermail/linux-arm-kernel/2012-August/116405.html

 Do you have a use case for it, this time?

 My version have been hold off waiting for an user for it.
 Will you need it for a driver?

 Regards,


 Signed-off-by: Christian Ruppert christian.rupp...@abilis.com
 ---
  .../bindings/clock/fixed-factor-clkdiv.txt |   24 
 +++
  drivers/clk/clk-fixed-factor.c |   32 
 
  include/linux/clk-provider.h   |1 +
  3 files changed, 57 insertions(+), 0 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt

 diff --git 
 a/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt 
 b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 new file mode 100644
 index 000..352bac4
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clkdiv.txt
 @@ -0,0 +1,24 @@
 +Device Tree Clock bindings for plat-tb10x
 +
 +This binding uses the common clock binding[1].
 +
 +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible : shall be fixed-factor-clkdiv
 +- #clock-cells: from common clock binding; shall be set to 0
 +- clocks: shall be the input parent clock phandle for the clock.
 +- clock-mult: defines the multiplication factor of the output clock 
 frequency
 +  wrt. the input clock frequency.
 +- clock-div: defines the division factor of the output clock frequency 
 wrt.
 +  the input clock frequency.
 +
 +Example:
 +cpu_clk: clkdiv_cpu {   /* CPU clock derived from pll0. 1/2 of pll 
 frequency */
 +compatible = fixed-factor-clkdiv;
 +#clock-cells = 0;
 +clocks = pll0;
 +clock-mult = 1;
 +clock-div = 2;
 +clock-output-names = cpu_clk;
 +};
 diff --git a/drivers/clk/clk-fixed-factor.c 
 b/drivers/clk/clk-fixed-factor.c
 index 1ef271e..85e45f1 100644
 --- a/drivers/clk/clk-fixed-factor.c
 +++ b/drivers/clk/clk-fixed-factor.c
 @@ -11,6 +11,7 @@
  #include linux/clk-provider.h
  #include linux/slab.h
  #include linux/err.h
 +#include linux/of.h
  
  /*
   * DOC: basic fixed multiplier and divider clock that cannot gate
 @@ -96,3 +97,34 @@ struct clk *clk_register_fixed_factor(struct device 
 *dev, const char *name

Re: [PATCH] clk: Add device tree binding to clk-fixed-factor

2013-04-12 Thread Gregory CLEMENT

On 04/12/2013 11:12 AM, Christian Ruppert wrote:
 On Fri, Apr 12, 2013 at 11:04:51AM +0200, Gregory CLEMENT wrote:
 On 04/12/2013 08:54 AM, Christian Ruppert wrote:
 On Thu, Apr 11, 2013 at 06:26:07PM +0200, Gregory CLEMENT wrote:
 On 04/11/2013 11:19 AM, Christian Ruppert wrote:
 Hi Gregory,

 Since there doesn't seem to be anyone opposing this feature I just
 checked your patch and after adding the CLK_OF_DECLARE macro in the end
 it works well for us. Tell me if you would like to rebase and resubmit
 your patch or if I should follow up on our own.

 I can rebase and resubmit my patch, it's pretty straightforward.
 The problem was the lack of user in the kernel. And by user I mean
 a driver using these functions. Usually a new function enter in the
 kernel only if there are users for it inside the kernel so if you plan
 to submit a driver using this piece of code, then I see no reason
 to not get it.

 If you add the line

 CLK_OF_DECLARE(fixed_factor_clk, fixed-factor-clkdiv, 

 Why did you add the div suffix?

 There is nothing in the function which prevent to have mul greater than
 div and hence having a multiplicative factor.

 I think that this suffix is misleading.
 
 You are right, let's remove it.

Great, I am going to send the patch in a couple of minutes.
That means that you will have to ammend your file
arch/arc/boot/dts/abilis_tb10x.dtsi

and for the clock named cpu_clk and ahb_clk you will have to rename
fixed-factor-clkdiv to fixed-factor-clock

Thanks,

 
 [...]
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] clk: add device tree fixed-factor-clock binding support

2013-04-12 Thread Gregory CLEMENT

Add support for DT fixed-factor-clock binding to the common fixed
factor clock support.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 .../bindings/clock/fixed-factor-clock.txt  |   24 +
 drivers/clk/clk-fixed-factor.c |   36 
 include/linux/clk-provider.h   |2 ++
 3 files changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt 
b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
new file mode 100644
index 000..7ed236f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -0,0 +1,24 @@
+Binding for simple fixed factor rate clock sources.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be fixed-factor-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- div: fixed divider.
+- mult: fixed multiplier.
+- clocks: parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+   clock {
+   compatible = fixed-factor-clock;
+   clocks = parentclk;
+   #clock-cells = 0;
+   div = 2;
+   mult = 1;
+   };
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 1ef271e..9ff7d51 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -11,6 +11,7 @@
 #include linux/clk-provider.h
 #include linux/slab.h
 #include linux/err.h
+#include linux/of.h
 
 /*
  * DOC: basic fixed multiplier and divider clock that cannot gate
@@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, 
const char *name,
 
return clk;
 }
+#ifdef CONFIG_OF
+/**
+ * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
+ */
+void __init of_fixed_factor_clk_setup(struct device_node *node)
+{
+   struct clk *clk;
+   const char *clk_name = node-name;
+   const char *parent_name;
+   u32 div, mult;
+
+   if (of_property_read_u32(node, clock-div, div)) {
+   pr_err(%s Fixed factor clock %s must have a clock-div 
property\n,
+   __func__, node-name);
+   return;
+   }
+
+   if (of_property_read_u32(node, clock-mult, mult)) {
+   pr_err(%s Fixed factor clock %s must have a clokc-mult 
property\n,
+   __func__, node-name);
+   return;
+   }
+
+   of_property_read_string(node, clock-output-names, clk_name);
+   parent_name = of_clk_get_parent_name(node, 0);
+
+   clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+   mult, div);
+   if (!IS_ERR(clk))
+   of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
+CLK_OF_DECLARE(fixed_factor_clk, fixed-factor-clock,
+   of_fixed_factor_clk_setup);
+#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f197d7..7ea501b 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, 
const char *name,
const char *parent_name, unsigned long flags,
unsigned int mult, unsigned int div);
 
+void of_fixed_factor_clk_setup(struct device_node *node);
+
 /**
  * clk_register - allocate a new clock, register it and return an opaque cookie
  * @dev: device that is registering this clock
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] clk: add device tree fixed-factor-clock binding support

2013-04-12 Thread Gregory CLEMENT

Hi,

[I resend it because I forgot to add the mainling lists!]

Since august this patch finally find a user:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi.
So I resusrected this patch with small changed suggested by Christian
Ruppert.

- Adding CLK_OF_DECLARE
- Using IS_ERR to test the clk value

Thanks,

Gregory CLEMENT (1):
  clk: add device tree fixed-factor-clock binding support

 .../bindings/clock/fixed-factor-clock.txt  |   24 +
 drivers/clk/clk-fixed-factor.c |   36 
 include/linux/clk-provider.h   |2 ++
 3 files changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] clk: add device tree fixed-factor-clock binding support

2013-04-12 Thread Gregory CLEMENT

On 04/12/2013 12:30 PM, Christian Ruppert wrote:
 Hi Gregory,
 
 Just tested the patch and it works perfectly. Did you forget to update
 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt, however?

Oh yes you're right. I will send a v3 with this modification.
Can I also add your tested-by flag?

Thanks,


 
 Greetings,
   Christian
 
 On Fri, Apr 12, 2013 at 11:58:28AM +0200, Gregory CLEMENT wrote:
 Add support for DT fixed-factor-clock binding to the common fixed
 factor clock support.

 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 ---
  .../bindings/clock/fixed-factor-clock.txt  |   24 +
  drivers/clk/clk-fixed-factor.c |   36 
 
  include/linux/clk-provider.h   |2 ++
  3 files changed, 62 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

 diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt 
 b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
 new file mode 100644
 index 000..7ed236f
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
 @@ -0,0 +1,24 @@
 +Binding for simple fixed factor rate clock sources.
 +
 +This binding uses the common clock binding[1].
 +
 +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 +
 +Required properties:
 +- compatible : shall be fixed-factor-clock.
 +- #clock-cells : from common clock binding; shall be set to 0.
 +- div: fixed divider.
 +- mult: fixed multiplier.
 +- clocks: parent clock.
 +
 +Optional properties:
 +- clock-output-names : From common clock binding.
 +
 +Example:
 +clock {
 +compatible = fixed-factor-clock;
 +clocks = parentclk;
 +#clock-cells = 0;
 +div = 2;
 +mult = 1;
 +};
 diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
 index 1ef271e..9ff7d51 100644
 --- a/drivers/clk/clk-fixed-factor.c
 +++ b/drivers/clk/clk-fixed-factor.c
 @@ -11,6 +11,7 @@
  #include linux/clk-provider.h
  #include linux/slab.h
  #include linux/err.h
 +#include linux/of.h
  
  /*
   * DOC: basic fixed multiplier and divider clock that cannot gate
 @@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, 
 const char *name,
  
  return clk;
  }
 +#ifdef CONFIG_OF
 +/**
 + * of_fixed_factor_clk_setup() - Setup function for simple fixed factor 
 clock
 + */
 +void __init of_fixed_factor_clk_setup(struct device_node *node)
 +{
 +struct clk *clk;
 +const char *clk_name = node-name;
 +const char *parent_name;
 +u32 div, mult;
 +
 +if (of_property_read_u32(node, clock-div, div)) {
 +pr_err(%s Fixed factor clock %s must have a clock-div 
 property\n,
 +__func__, node-name);
 +return;
 +}
 +
 +if (of_property_read_u32(node, clock-mult, mult)) {
 +pr_err(%s Fixed factor clock %s must have a clokc-mult 
 property\n,
 +__func__, node-name);
 +return;
 +}
 +
 +of_property_read_string(node, clock-output-names, clk_name);
 +parent_name = of_clk_get_parent_name(node, 0);
 +
 +clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
 +mult, div);
 +if (!IS_ERR(clk))
 +of_clk_add_provider(node, of_clk_src_simple_get, clk);
 +}
 +EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
 +CLK_OF_DECLARE(fixed_factor_clk, fixed-factor-clock,
 +of_fixed_factor_clk_setup);
 +#endif
 diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
 index 7f197d7..7ea501b 100644
 --- a/include/linux/clk-provider.h
 +++ b/include/linux/clk-provider.h
 @@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device 
 *dev, const char *name,
  const char *parent_name, unsigned long flags,
  unsigned int mult, unsigned int div);
  
 +void of_fixed_factor_clk_setup(struct device_node *node);
 +
  /**
   * clk_register - allocate a new clock, register it and return an opaque 
 cookie
   * @dev: device that is registering this clock
 -- 
 1.7.9.5

 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] clk: add device tree fixed-factor-clock binding support

2013-04-12 Thread Gregory CLEMENT

Add support for DT fixed-factor-clock binding to the common fixed
factor clock support.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Tested-by: Christian Ruppert christian.rupp...@abilis.com
---
 .../bindings/clock/fixed-factor-clock.txt  |   24 +
 drivers/clk/clk-fixed-factor.c |   36 
 include/linux/clk-provider.h   |2 ++
 3 files changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt 
b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
new file mode 100644
index 000..5757f9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -0,0 +1,24 @@
+Binding for simple fixed factor rate clock sources.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be fixed-factor-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- clock-div: fixed divider.
+- clock-mult: fixed multiplier.
+- clocks: parent clock.
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+   clock {
+   compatible = fixed-factor-clock;
+   clocks = parentclk;
+   #clock-cells = 0;
+   div = 2;
+   mult = 1;
+   };
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 1ef271e..9ff7d51 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -11,6 +11,7 @@
 #include linux/clk-provider.h
 #include linux/slab.h
 #include linux/err.h
+#include linux/of.h
 
 /*
  * DOC: basic fixed multiplier and divider clock that cannot gate
@@ -96,3 +97,38 @@ struct clk *clk_register_fixed_factor(struct device *dev, 
const char *name,
 
return clk;
 }
+#ifdef CONFIG_OF
+/**
+ * of_fixed_factor_clk_setup() - Setup function for simple fixed factor clock
+ */
+void __init of_fixed_factor_clk_setup(struct device_node *node)
+{
+   struct clk *clk;
+   const char *clk_name = node-name;
+   const char *parent_name;
+   u32 div, mult;
+
+   if (of_property_read_u32(node, clock-div, div)) {
+   pr_err(%s Fixed factor clock %s must have a clock-div 
property\n,
+   __func__, node-name);
+   return;
+   }
+
+   if (of_property_read_u32(node, clock-mult, mult)) {
+   pr_err(%s Fixed factor clock %s must have a clokc-mult 
property\n,
+   __func__, node-name);
+   return;
+   }
+
+   of_property_read_string(node, clock-output-names, clk_name);
+   parent_name = of_clk_get_parent_name(node, 0);
+
+   clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+   mult, div);
+   if (!IS_ERR(clk))
+   of_clk_add_provider(node, of_clk_src_simple_get, clk);
+}
+EXPORT_SYMBOL_GPL(of_fixed_factor_clk_setup);
+CLK_OF_DECLARE(fixed_factor_clk, fixed-factor-clock,
+   of_fixed_factor_clk_setup);
+#endif
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7f197d7..7ea501b 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -325,6 +325,8 @@ struct clk *clk_register_fixed_factor(struct device *dev, 
const char *name,
const char *parent_name, unsigned long flags,
unsigned int mult, unsigned int div);
 
+void of_fixed_factor_clk_setup(struct device_node *node);
+
 /**
  * clk_register - allocate a new clock, register it and return an opaque cookie
  * @dev: device that is registering this clock
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] clk: add device tree fixed-factor-clock binding support

2013-04-12 Thread Gregory CLEMENT

Hi,

Since august this patch finally find a user:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arc/boot/dts/abilis_*.dtsi.
So I resusrected this patch with small changed suggested by Christian
Ruppert.

Mike,
if you still agree with this patch, you can apply it.
It was based on 3.9-rc6 but it can also be applied on clk-next
without any conflict.

Changelog:
v2 - v3

- Updating the binding documentation bu using clock-div and clock-mul
  instead of div and mul
- Adding the tested-by tag from by Christian Ruppert

v1 - v2
- Adding CLK_OF_DECLARE
- Using IS_ERR to test the clk value

Thanks,

Gregory CLEMENT (1):
  clk: add device tree fixed-factor-clock binding support

 .../bindings/clock/fixed-factor-clock.txt  |   24 +
 drivers/clk/clk-fixed-factor.c |   36 
 include/linux/clk-provider.h   |2 ++
 3 files changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/fixed-factor-clock.txt

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 2/5] ARM: dts: mvebu: move all peripherals inside soc

2013-04-12 Thread Gregory CLEMENT

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

reorganize the .dts and .dtsi files so that all devices are under the
soc { } node (currently some devices such as the interrupt controller,
the L2 cache and a few others are outside).

Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-xp.dtsi |   26 +-
 arch/arm/boot/dts/armada-370.dtsi|   23 ---
 arch/arm/boot/dts/armada-xp.dtsi |   32 
 3 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 9693f79..972448c 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -28,19 +28,6 @@
};
};
 
-   mpic: interrupt-controller@d002 {
- compatible = marvell,mpic;
- #interrupt-cells = 1;
- #size-cells = 1;
- interrupt-controller;
-   };
-
-   coherency-fabric@d0020200 {
-   compatible = marvell,coherency-fabric;
-   reg = 0xd0020200 0xb0,
- 0xd0021810 0x1c;
-   };
-
soc {
#address-cells = 1;
#size-cells = 1;
@@ -48,6 +35,19 @@
interrupt-parent = mpic;
ranges;
 
+   mpic: interrupt-controller@d002 {
+   compatible = marvell,mpic;
+   #interrupt-cells = 1;
+   #size-cells = 1;
+   interrupt-controller;
+   };
+
+   coherency-fabric@d0020200 {
+   compatible = marvell,coherency-fabric;
+   reg = 0xd0020200 0xb0,
+ 0xd0021810 0x1c;
+   };
+
serial@d0012000 {
compatible = snps,dw-apb-uart;
reg = 0xd0012000 0x100;
diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index 18f6eb4..209caeb 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -20,12 +20,6 @@
 / {
model = Marvell Armada 370 family SoC;
compatible = marvell,armada370, marvell,armada-370-xp;
-   L2: l2-cache {
-   compatible = marvell,aurora-outer-cache;
-   reg = 0xd0008000 0x1000;
-   cache-id-part = 0x100;
-   wt-override;
-   };
 
aliases {
gpio0 = gpio0;
@@ -33,17 +27,24 @@
gpio2 = gpio2;
};
 
-   mpic: interrupt-controller@d002 {
- reg = 0xd0020a00 0x1d0,
-   0xd0021870 0x58;
-   };
-
soc {
+   mpic: interrupt-controller@d002 {
+   reg = 0xd0020a00 0x1d0,
+ 0xd0021870 0x58;
+   };
+
system-controller@d0018200 {
compatible = 
marvell,armada-370-xp-system-controller;
reg = 0xd0018200 0x100;
};
 
+   L2: l2-cache {
+   compatible = marvell,aurora-outer-cache;
+   reg = 0xd0008000 0x1000;
+   cache-id-part = 0x100;
+   wt-override;
+   };
+
pinctrl {
compatible = marvell,mv88f6710-pinctrl;
reg = 0xd0018000 0x38;
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 29dfeb6..ef3d413 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -22,25 +22,25 @@
model = Marvell Armada XP family SoC;
compatible = marvell,armadaxp, marvell,armada-370-xp;
 
-   L2: l2-cache {
-   compatible = marvell,aurora-system-cache;
-   reg = 0xd0008000 0x1000;
-   cache-id-part = 0x100;
-   wt-override;
-   };
+   soc {
+   L2: l2-cache {
+   compatible = marvell,aurora-system-cache;
+   reg = 0xd0008000 0x1000;
+   cache-id-part = 0x100;
+   wt-override;
+   };
 
-   mpic: interrupt-controller@d002 {
- reg = 0xd0020a00 0x2d0,
-   0xd0021070 0x58;
-   };
+   mpic: interrupt-controller@d002 {
+ reg = 0xd0020a00 0x2d0,
+   0xd0021070 0x58;
+   };
 
-   armada-370-xp-pmsu@d0022000 {
-   compatible = marvell,armada-370-xp-pmsu;
-   reg = 0xd0022100 0x430,
- 0xd0020800 0x20;
-   };
+   armada-370-xp-pmsu@d0022000 {
+   compatible = marvell,armada-370-xp-pmsu;
+   reg

[PATCH v4 0/5] LPAE remaining device tree file

2013-04-12 Thread Gregory CLEMENT

Hi Jason,

I have just rebased the commits that you haven't applied yet. They are
rebased on mvebu/dt. I check that all the dtb can be built.

Thanks,

Gregory CLEMENT (3):
  ARM: dts: mvebu: Convert all the mvebu files to use the range
property
  ARM: dts: mvebu: introduce internal-regs node
  ARM: dts: mvebu: Convert mvebu device tree files to 64 bits

Thomas Petazzoni (2):
  ARM: dts: mvebu: fix cpus section indentation
  ARM: dts: mvebu: move all peripherals inside soc

 arch/arm/boot/dts/armada-370-db.dts  |  134 +++---
 arch/arm/boot/dts/armada-370-mirabox.dts |  176 
 arch/arm/boot/dts/armada-370-rd.dts  |   96 ++---
 arch/arm/boot/dts/armada-370-xp.dtsi |  336 +++
 arch/arm/boot/dts/armada-370.dtsi|  330 +++
 arch/arm/boot/dts/armada-xp-db.dts   |  202 -
 arch/arm/boot/dts/armada-xp-gp.dts   |  222 +-
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |  284 ++---
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |  342 +++
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |  484 +++---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |  262 ++--
 arch/arm/boot/dts/armada-xp.dtsi |  202 -
 12 files changed, 1549 insertions(+), 1521 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/5] ARM: dts: mvebu: fix cpus section indentation

2013-04-12 Thread Gregory CLEMENT

From: Thomas Petazzoni thomas.petazz...@free-electrons.com

Align the cpu node indentation with the rest of the file

[gc]: added a commit description
Signed-off-by: Thomas Petazzoni thomas.petazz...@free-electrons.com
---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   32 +-
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   32 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   54 +++---
 3 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index c2c7845..e072a53 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -25,22 +25,22 @@
};
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
-
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
-
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   #address-cells = 1;
+   #size-cells = 0;
+
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
+
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 885bf22..6dae1bc 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -26,22 +26,22 @@
};
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
-
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
-
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   #address-cells = 1;
+   #size-cells = 0;
+
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
+
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi 
b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index 23a5ac4..b9da5b8 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -27,36 +27,36 @@
 
 
cpus {
-   #address-cells = 1;
-   #size-cells = 0;
+   #address-cells = 1;
+   #size-cells = 0;
 
-   cpu@0 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 0;
-   clocks = cpuclk 0;
-   };
+   cpu@0 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 0;
+   clocks = cpuclk 0;
+   };
 
-   cpu@1 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 1;
-   clocks = cpuclk 1;
-   };
+   cpu@1 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 1;
+   clocks = cpuclk 1;
+   };
 
-   cpu@2 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 2;
-   clocks = cpuclk 2;
-   };
+   cpu@2 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 2;
+   clocks = cpuclk 2;
+   };
 
-   cpu@3 {
-   device_type = cpu;
-   compatible = marvell,sheeva-v7;
-   reg = 3;
-   clocks = cpuclk 3;
-   };
+   cpu@3 {
+   device_type = cpu;
+   compatible = marvell,sheeva-v7;
+   reg = 3;
+   clocks = cpuclk 3;
+   };
};
 
soc {
@@ -300,4 +300,4 @@

[PATCH v4 5/5] ARM: dts: mvebu: Convert mvebu device tree files to 64 bits

2013-04-12 Thread Gregory CLEMENT

In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.

Only Armada XP is LPAE capable, but as it shares a common dtsi file
with Armada 370, then the common file include the skeleton64. Thanks
to the use of the overload capability of the device tree format,
armada-370 include the 32 bit skeleton and all the armada 370 based
dts can remain the same.

This was heavily based on the work of Lior Amsalem.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-xp.dtsi |4 ++--
 arch/arm/boot/dts/armada-370.dtsi|2 ++
 arch/arm/boot/dts/armada-xp-db.dts   |2 +-
 arch/arm/boot/dts/armada-xp-gp.dts   |   14 --
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 +-
 5 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index bf8f911..272bbc6 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -16,7 +16,7 @@
  * 370 and Armada XP SoC.
  */
 
-/include/ skeleton.dtsi
+/include/ skeleton64.dtsi
 
 / {
model = Marvell Armada 370 and XP SoC;
@@ -33,7 +33,7 @@
#size-cells = 1;
compatible = simple-bus;
interrupt-parent = mpic;
-   ranges = 0 0xd000 0x10;
+   ranges = 0 0 0xd000 0x10;
 
internal-regs {
compatible = simple-bus;
diff --git a/arch/arm/boot/dts/armada-370.dtsi 
b/arch/arm/boot/dts/armada-370.dtsi
index 6ef95dd..b2c1b5a 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -16,6 +16,7 @@
  */
 
 /include/ armada-370-xp.dtsi
+/include/ skeleton.dtsi
 
 / {
model = Marvell Armada 370 family SoC;
@@ -28,6 +29,7 @@
};
 
soc {
+   ranges = 0 0xd000 0x10;
internal-regs {
system-controller@18200 {
compatible = 
marvell,armada-370-xp-system-controller;
diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index 6c8b032..d6cc8bf 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -26,7 +26,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x8000; /* 2 GB */
+   reg = 0 0x 0 0x8000; /* 2 GB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts 
b/arch/arm/boot/dts/armada-xp-gp.dts
index d9972c9..26ad06f 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -26,14 +26,16 @@
 
memory {
device_type = memory;
-
/*
-* 4 GB of plug-in RAM modules by default but only 3GB
-* are visible, the amount of memory available can be
-* changed by the bootloader according the size of the
-* module actually plugged
+ * 8 GB of plug-in RAM modules by default.The amount
+ * of memory available can be changed by the
+ * bootloader according the size of the module
+ * actually plugged. Only 7GB are usable because
+ * addresses from 0xC000 to 0x are used by
+ * the internal registers of the SoC.
 */
-   reg = 0x 0xC000;
+   reg = 0x 0x 0x 0xC000,
+ 0x0001 0x 0x0001 0x;
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts 
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index 15a66a8..f14d36c 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -23,7 +23,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0xC000; /* 3 GB */
+   reg = 0 0x 0 0xC000; /* 3 GB */
};
 
soc {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 3/5] ARM: dts: mvebu: Convert all the mvebu files to use the range property

2013-04-12 Thread Gregory CLEMENT

This conversion will allow to keep 32 bits addresses for the internal
registers whereas the memory of the system will be 64 bits.
Later it will also ease the move of the mvebu-mbus driver to the
device tree support.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts  |   16 ++--
 arch/arm/boot/dts/armada-370-mirabox.dts |   16 ++--
 arch/arm/boot/dts/armada-370-rd.dts  |   14 +--
 arch/arm/boot/dts/armada-370-xp.dtsi |   99 +++---
 arch/arm/boot/dts/armada-370.dtsi|   65 +++---
 arch/arm/boot/dts/armada-xp-db.dts   |   28 +++---
 arch/arm/boot/dts/armada-xp-gp.dts   |   22 ++---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |   30 +++
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   44 +-
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   58 ++---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |   24 +++---
 arch/arm/boot/dts/armada-xp.dtsi |   71 
 12 files changed, 245 insertions(+), 242 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 6403acd..e766f8b 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -30,11 +30,11 @@
};
 
soc {
-   serial@d0012000 {
+   serial@12000 {
clock-frequency = 2;
status = okay;
};
-   sata@d00a {
+   sata@a {
nr-ports = 2;
status = okay;
};
@@ -49,18 +49,18 @@
};
};
 
-   ethernet@d007 {
+   ethernet@7 {
status = okay;
phy = phy0;
phy-mode = rgmii-id;
};
-   ethernet@d0074000 {
+   ethernet@74000 {
status = okay;
phy = phy1;
phy-mode = rgmii-id;
};
 
-   mvsdio@d00d4000 {
+   mvsdio@d4000 {
pinctrl-0 = sdio_pins1;
pinctrl-names = default;
/*
@@ -75,15 +75,15 @@
/* No CD or WP GPIOs */
};
 
-   usb@d005 {
+   usb@5 {
status = okay;
};
 
-   usb@d0051000 {
+   usb@51000 {
status = okay;
};
 
-   spi0: spi@d0010600 {
+   spi0: spi@10600 {
status = okay;
 
spi-flash@0 {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts 
b/arch/arm/boot/dts/armada-370-mirabox.dts
index 58ee793..6530ae3 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -25,11 +25,11 @@
};
 
soc {
-   serial@d0012000 {
+   serial@12000 {
clock-frequency = 2;
status = okay;
};
-   timer@d0020300 {
+   timer@20300 {
clock-frequency = 6;
status = okay;
};
@@ -79,18 +79,18 @@
reg = 1;
};
};
-   ethernet@d007 {
+   ethernet@7 {
status = okay;
phy = phy0;
phy-mode = rgmii-id;
};
-   ethernet@d0074000 {
+   ethernet@74000 {
status = okay;
phy = phy1;
phy-mode = rgmii-id;
};
 
-   mvsdio@d00d4000 {
+   mvsdio@d4000 {
pinctrl-0 = sdio_pins3;
pinctrl-names = default;
status = okay;
@@ -100,15 +100,15 @@
 */
};
 
-   usb@d005 {
+   usb@5 {
status = okay;
};
 
-   usb@d0051000 {
+   usb@51000 {
status = okay;
};
 
-   i2c@d0011000 {
+   i2c@11000 {
status = okay;
clock-frequency = 10;
pca9505: pca9505@25 {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts 
b/arch/arm/boot/dts/armada-370-rd.dts
index 516dec3..83d5c04 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -28,11 +28,11 @@
};
 
soc

Re: [BUG][mvebu] mvneta: cannot request irq 25 on openblocks-ax3

2013-03-19 Thread Gregory CLEMENT

On 03/19/2013 03:19 PM, Masami Hiramatsu wrote:
 Hi Ezequiel,
 
 (2013/03/19 22:39), Ezequiel Garcia wrote:
 Hi Masami,

 On Tue, Mar 19, 2013 at 10:12:37PM +0900, Masami Hiramatsu wrote:

 Here I've hit a bug on the recent kernel. As far as I know, this bug
 exists on 3.9-rc1 too.

 When I tried the latest mvebu for-next tree
 (git://git.infradead.org/users/jcooper/linux.git mvebu/for-next),
 I got below warning at bootup time and mvneta didn't work (link was never 
 up).
 I ensured that ifconfig ethX up always caused that.

 Does anyone succeed to boot openblocks-ax3 recently or hit same
 trouble?

 This is a known bug. Gregory Clement already has a fix and he
 will submit it soon. In case you need this fixed ASAP, I'm attaching
 you a patch with a fix.
 
 Thanks! I'll try that.
 
 Please note the attached patch is not ready for mainline inclusion,
 as I said Gregory will submit a cleaner version soon.
 
 Yeah, I look forward to it :)

Hi Masami,

You can try this patch if you want.
I don't have the hardware today so I didn't test it.
If you (and also Florian and Ezequiel) can test it and if it fixed
the bug, then I will be able send a proper email for it,

Thanks,
-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

From a82800cbd4f2ff34a4a03c8caa688149b8770ab7 Mon Sep 17 00:00:00 2001
From: Gregory CLEMENT gregory.clem...@free-electrons.com
Date: Tue, 19 Mar 2013 15:11:48 +0100
Subject: [PATCH] net: mvneta: convert to local interrupt

Since commit 3a6f08a37 arm: mvebu: Add support for local interrupt,
the mvneta interrupt is now managed as a local interrupt. That means
that the driver have to use the request_percpu_irq() function instead
of request_irq().

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 drivers/net/ethernet/marvell/mvneta.c |   26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index cd345b8..ad64a50 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -256,6 +256,8 @@ struct mvneta_port {
 	unsigned int link;
 	unsigned int duplex;
 	unsigned int speed;
+
+	struct mvneta_port __percpu **percpu_pp;
 };
 
 /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -1799,7 +1801,7 @@ static void mvneta_set_rx_mode(struct net_device *dev)
 /* Interrupt handling - the callback for request_irq() */
 static irqreturn_t mvneta_isr(int irq, void *dev_id)
 {
-	struct mvneta_port *pp = (struct mvneta_port *)dev_id;
+	struct mvneta_port *pp = *(struct mvneta_port **)dev_id;
 
 	/* Mask all interrupts */
 	mvreg_write(pp, MVNETA_INTR_NEW_MASK, 0);
@@ -2371,8 +2373,19 @@ static void mvneta_mdio_remove(struct mvneta_port *pp)
 static int mvneta_open(struct net_device *dev)
 {
 	struct mvneta_port *pp = netdev_priv(dev);
+
 	int ret;
 
+	/* As the mvneta interrupts are locals, we need to create a
+	 * percpu variable
+	 */
+	pp-percpu_pp = alloc_percpu(struct mvneta_port *);
+	if (!pp) {
+		ret = -ENOMEM;
+		goto err_percpu_alloc;
+	}
+	*__this_cpu_ptr(pp-percpu_pp) = pp;
+
 	mvneta_mac_addr_set(pp, dev-dev_addr, rxq_def);
 
 	pp-pkt_size = MVNETA_RX_PKT_SIZE(pp-dev-mtu);
@@ -2385,13 +2398,15 @@ static int mvneta_open(struct net_device *dev)
 	if (ret)
 		goto err_cleanup_rxqs;
 
+
 	/* Connect to port interrupt line */
-	ret = request_irq(pp-dev-irq, mvneta_isr, 0,
-			  MVNETA_DRIVER_NAME, pp);
+	ret = request_percpu_irq(pp-dev-irq, mvneta_isr,
+MVNETA_DRIVER_NAME, pp-percpu_pp);
 	if (ret) {
 		netdev_err(pp-dev, cannot request irq %d\n, pp-dev-irq);
 		goto err_cleanup_txqs;
 	}
+	enable_percpu_irq(pp-dev-irq, 0);
 
 	/* In default link is down */
 	netif_carrier_off(pp-dev);
@@ -2407,11 +2422,13 @@ static int mvneta_open(struct net_device *dev)
 	return 0;
 
 err_free_irq:
+	free_percpu(pp-percpu_pp);
 	free_irq(pp-dev-irq, pp);
 err_cleanup_txqs:
 	mvneta_cleanup_txqs(pp);
 err_cleanup_rxqs:
 	mvneta_cleanup_rxqs(pp);
+err_percpu_alloc:
 	return ret;
 }
 
@@ -2422,7 +2439,8 @@ static int mvneta_stop(struct net_device *dev)
 
 	mvneta_stop_dev(pp);
 	mvneta_mdio_remove(pp);
-	free_irq(dev-irq, pp);
+	free_percpu(pp-percpu_pp);
+	free_percpu_irq(dev-irq, pp);
 	mvneta_cleanup_rxqs(pp);
 	mvneta_cleanup_txqs(pp);
 	del_timer(pp-tx_done_timer);
-- 
1.7.9.5

Re: [BUG][mvebu] mvneta: cannot request irq 25 on openblocks-ax3

2013-03-20 Thread Gregory CLEMENT

On 03/19/2013 08:48 PM, Florian Fainelli wrote:
 On Tuesday 19 March 2013 17:43:49 Gregory CLEMENT wrote:

 Hi Masami,

 You can try this patch if you want.
 I don't have the hardware today so I didn't test it.
 If you (and also Florian and Ezequiel) can test it and if it fixed
 the bug, then I will be able send a proper email for it,
 
 I just tested your patch on RD-A370-A1 and DB-MV784MP-GP and it works fine, 
 thanks! Feel free to add my Tested-by: Florian Fainelli flor...@openwrt.org 
 to your next submission.
 
 Thanks!
 
Thanks for having tested it, but with this patch there is still an issue when
we try to release the network interface. In this case the the interrupt line
is not properly freed.
Unfortunately the state of the percpu_irq API prevents the driver to use it.

Indeed the interrupts have to be freed when the .stop() function is
called. As the free_percpu_irq() function don't disable the interrupt
line, we have to do it on each CPU before calling this. The function
disable_percpu_irq() only disable the percpu on the current CPU and
there is no function which allows to disable a percpu irq on a given
CPU. Waiting for the extension of the percpu_irq API, this fix allows
to use again the mvneta driver.

I have just wrote and tested a new patch to fix this issue by just go back
on the old way we managed the irq for the mvenat as global irq and not
as local ones.

I am going to send the fix on the LAKML in a few minutes.

Thanks,

Gregory
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 08/10] clocksource: time-armada-370-xp: Fix sparse warning

2013-03-20 Thread Gregory CLEMENT

On 03/13/2013 07:17 PM, Stephen Boyd wrote:
 drivers/clocksource/time-armada-370-xp.c:217:13: warning: symbol
 'armada_370_xp_timer_init' was not declared. Should it be static?
 
 Also remove the __init marking in the prototype as it's
 unnecessary and drop the init.h file.
 
 Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
 Signed-off-by: Stephen Boyd sb...@codeaurora.org
 ---
  drivers/clocksource/time-armada-370-xp.c | 3 ++-
  include/linux/time-armada-370-xp.h   | 4 +---
  2 files changed, 3 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/clocksource/time-armada-370-xp.c 
 b/drivers/clocksource/time-armada-370-xp.c
 index 47a6730..efe4aef 100644
 --- a/drivers/clocksource/time-armada-370-xp.c
 +++ b/drivers/clocksource/time-armada-370-xp.c
 @@ -27,10 +27,11 @@
  #include linux/of_address.h
  #include linux/irq.h
  #include linux/module.h
 +#include linux/percpu.h
 +#include linux/time-armada-370-xp.h
  
  #include asm/sched_clock.h
  #include asm/localtimer.h
 -#include linux/percpu.h
  /*
   * Timer block registers.
   */
 diff --git a/include/linux/time-armada-370-xp.h 
 b/include/linux/time-armada-370-xp.h
 index dfdfdc0..6fb0856 100644
 --- a/include/linux/time-armada-370-xp.h
 +++ b/include/linux/time-armada-370-xp.h
 @@ -11,8 +11,6 @@
  #ifndef __TIME_ARMADA_370_XPPRCMU_H
  #define __TIME_ARMADA_370_XPPRCMU_H
  
 -#include linux/init.h
 -
 -void __init armada_370_xp_timer_init(void);
 +void armada_370_xp_timer_init(void);
  
  #endif
 
Acked-by: Gregory CLEMENT gregory.clem...@free-electrons.com

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 09/10] clocksource: time-armada-370-xp: Divorce from local timer API

2013-03-20 Thread Gregory CLEMENT

 instruction: 0 [#2] SMP ARM
Modules linked in:
CPU: 0Tainted: G  D   (3.9.0-rc3-next-20130319-00010-g728b448 #153)
PC is at 0xe92d45f0
LR is at armada_370_xp_timer_interrupt+0x3c/0x4c
pc : [e92d45f0]lr : [c023c2bc]psr: 61d3
sp : c0635cc0  ip :   fp : c063c3f0
r10: 03ff  r9 :   r8 : 0010
r7 : c22b3c40  r6 : ef007c00  r5 : c0640fcc  r4 : c0053e30
r3 : e92d45f0  r2 : fffe  r1 : c22b3c40  r0 : c0053e30
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 406a  DAC: 0015
Process swapper/0 (pid: 0, stack limit = 0xc0634238)
Stack: (0xc0635cc0 to 0xc0636000)
5cc0: ef004c80 c0063224 0010 0010 c0635f18 c0660ac0 c0635d20 c005fcb8
5ce0: c0632b90 c000ed94 c0316d54 6153 0001 c00085a8 c0316ca4 c0316d54
5d00: 6153  c0635d54 c03a53b0  c0660b70 61d3 c000db60
5d20: c0660fc0  c0642f80    000b c06400e0
5d40: c03a53b0  c0660b70 61d3  c0635d68 c0316ca4 c0316d54
5d60: 6153  61d3 c0635d94 c06608c0 c0634000 000b c06400e0
5d80: c03a53b0  c063f180 c0011624 c03a5310 21d3 c0642f80 0001
5da0: c0634238 000b 00100100 c0635e70 e92d45f0 7ed5a5f7 0001 0500
5dc0: c000dbcc c0634000 c063c3f0 c00082a0 0006 c22b0768 0004 
5de0: 00030001 e92d45f0  0001 c22b076c  c065fa1c c065f9c0
5e00: 00100100 0002 c065f9c0  c063cca0  0002 c065f9c0
5e20: c0661ca4 c06618e6 0041 0002 000a 0002  
5e40:     c06602cc  c00146d4 e92d45f4
5e60: 61d3 c0634050 0001 c000dbcc c0053e30 c22b3c40 fffe e92d45f0
5e80: c0053e30 c0640fcc ef007c00 c22b3c40 0010  03ff c063c3f0
5ea0:  c0635eb8 c023c2bc e92d45f0 61d3  ef004c80 c0063224
5ec0: 0010 0010  c0660ac0 c0635f18 c005fcb8 c0632b90 c000ed94
5ee0: c0313c60 6153 0001 c00085a8 c0313c54 c0313c60 6153 
5f00: c0635f4c  562f5842 c06360c0  c000db60 001a 8ad0
5f20: 8ad0 c06360c0   c04379c0 c22ad780  562f5842
5f40: c06360c0  6153 c0635f60 c0313c54 c0313c60 6153 
5f60: 0021  0003 0004 006e c065fcc0 c067924c c063ceb8
5f80: c063cc84 c006d8c0 0005 c065fcc0 c067924c c0421764 c22ad780 c063c42c
5fa0: 562f5842 c063cca8 c06605c0 c04379c0 c22ad780  562f5842 
5fc0:  c0417754   c04172dc   c04379c0
5fe0: 10c53c7d c063c414 c04379bc c063febc 406a 8074  
[c023c2bc] (armada_370_xp_timer_interrupt+0x3c/0x4c) from [c0063224] 
(handle_percpu_devid_irq+0x64/0x80)
[c0063224] (handle_percpu_devid_irq+0x64/0x80) from [c005fcb8] 
(generic_handle_irq+0x20/0x30)
[c005fcb8] (generic_handle_irq+0x20/0x30) from [c000ed94] 
(handle_IRQ+0x38/0x90)
[c000ed94] (handle_IRQ+0x38/0x90) from [c00085a8] 
(armada_370_xp_handle_irq+0xa4/0xb0)
[c00085a8] (armada_370_xp_handle_irq+0xa4/0xb0) from [c000db60] 
(__irq_svc+0x40/0x50)
Exception stack(0xc0635d20 to 0xc0635d68)
5d20: c0660fc0  c0642f80    000b c06400e0
5d40: c03a53b0  c0660b70 61d3  c0635d68 c0316ca4 c0316d54
5d60: 6153 
[c000db60] (__irq_svc+0x40/0x50) from [c0316d54] (panic+0x144/0x1b0)
[c0316d54] (panic+0x144/0x1b0) from [c0011624] (die+0x278/0x2a8)
[c0011624] (die+0x278/0x2a8) from [c00082a0] (do_undefinstr+0x9c/0x1c4)
[c00082a0] (do_undefinstr+0x9c/0x1c4) from [c000dbcc] 
(__und_svc_finish+0x0/0x14)
Exception stack(0xc0635e70 to 0xc0635eb8)
5e60: c0053e30 c22b3c40 fffe e92d45f0
5e80: c0053e30 c0640fcc ef007c00 c22b3c40 0010  03ff c063c3f0
5ea0:  c0635eb8 c023c2bc e92d45f0 61d3 
[c000dbcc] (__und_svc_finish+0x0/0x14) from [e92d45f0] (0xe92d45f0)
Code: 1fe7deb7 cd5772dd fff5692e ed55f79e (7ed5a5f7)
---[ end trace 1b75b31a2719ed1d ]---


I am trying to figure out what happened.


 
 Cc: Gregory CLEMENT gregory.clem...@free-electrons.com
 Signed-off-by: Stephen Boyd sb...@codeaurora.org
 ---
  drivers/clocksource/time-armada-370-xp.c | 85 
 ++--
  1 file changed, 38 insertions(+), 47 deletions(-)
 
 diff --git a/drivers/clocksource/time-armada-370-xp.c 
 b/drivers/clocksource/time-armada-370-xp.c
 index efe4aef..ee2e50c5 100644
 --- a/drivers/clocksource/time-armada-370-xp.c
 +++ b/drivers/clocksource/time-armada-370-xp.c
 @@ -19,6 +19,7 @@
  #include linux/platform_device.h
  #include linux/kernel.h
  #include linux/clk.h
 +#include linux/cpu.h
  #include linux/timer.h
  #include linux/clockchips.h
  #include linux/interrupt.h
 @@ -31,7 +32,6 @@
  #include linux/time-armada-370-xp.h
  
  #include asm/sched_clock.h
 -#include asm/localtimer.h
  /*
   * Timer block registers.
   */
 @@ -70,7 +70,7 @@ static bool timer25Mhz

Re: [PATCHv3 09/10] clocksource: time-armada-370-xp: Divorce from local timer API

2013-03-20 Thread Gregory CLEMENT

On 03/20/2013 06:09 PM, Gregory CLEMENT wrote:
 On 03/13/2013 07:17 PM, Stephen Boyd wrote:
 Separate the armada 370xp local timers from the local timer API.
 This will allow us to remove ARM local timer support in the near
 future and makes this driver multi-architecture friendly.
 
 At first view the code looks good, but when I applied your patch set on
 linux-next, build it and run it on a Armada XP based board (AX3 with 2 cores),
 it crashed:
 
 Booting Linux on physical CPU 0x0
 Linux version 3.9.0-rc3-next-20130319-00010-g728b448 
 (gclement@FE-greg-laptop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) 
 #153 SMP Wed Mar 20 17:58:57 CET 2013
 CPU: ARMv7 Processor [562f5842] revision 2 (ARMv7), cr=10c53c7d
 CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
 Machine: Marvell Armada 370/XP (Device Tree), model: PlatHome OpenBlocks 
 AX3-4 board
 bootconsole [earlycon0] enabled
 Memory policy: ECC disabled, Data cache writealloc
 PERCPU: Embedded 7 pages/cpu @c22b s7104 r8192 d13376 u32768
 Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 784912
 Kernel command line: console=ttyS0,115200 earlyprintk
 PID hash table entries: 4096 (order: 2, 16384 bytes)
 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
 Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
 __ex_table already sorted, skipping sort
 Memory: 3072MB = 3072MB total
 Memory: 3113520k/3113520k available, 32208k reserved, 2367488K highmem
 Virtual kernel memory layout:
 vector  : 0x - 0x1000   (   4 kB)
 fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
 vmalloc : 0xf000 - 0xff00   ( 240 MB)
 lowmem  : 0xc000 - 0xef80   ( 760 MB)
 pkmap   : 0xbfe0 - 0xc000   (   2 MB)
 modules : 0xbf00 - 0xbfe0   (  14 MB)
   .text : 0xc0008000 - 0xc041647c   (4154 kB)
   .init : 0xc0417000 - 0xc0633bc0   (2163 kB)
   .data : 0xc0634000 - 0xc06605c0   ( 178 kB)
.bss : 0xc06605c0 - 0xc0686a2c   ( 154 kB)
 Hierarchical RCU implementation.
 RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=2.
 NR_IRQS:16 nr_irqs:16 16
 Aurora cache controller enabled
 l2x0: 16 ways, CACHE_ID 0x0100, AUX_CTRL 0x1a696b12, Cache size: 1048576 B
 sched_clock: 32 bits at 25MHz, resolution 40ns, wraps every 171798ms
 Console: colour dummy device 80x30
 Calibrating delay loop...
 Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
 Modules linked in:
 CPU: 0Not tainted  (3.9.0-rc3-next-20130319-00010-g728b448 #153)
 PC is at 0xe92d45f0
 LR is at armada_370_xp_timer_interrupt+0x3c/0x4c
 pc : [e92d45f0]lr : [c023c2bc]psr: 61d3
 sp : c0635eb8  ip :   fp : c063c3f0
 r10: 03ff  r9 :   r8 : 0010
 r7 : c22b3c40  r6 : ef007c00  r5 : c0640fcc  r4 : c0053e30
 r3 : e92d45f0  r2 : fffe  r1 : c22b3c40  r0 : c0053e30
 Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
 Control: 10c53c7d  Table: 406a  DAC: 0015
 Process swapper/0 (pid: 0, stack limit = 0xc0634238)
 Stack: (0xc0635eb8 to 0xc0636000)
 5ea0:   ef004c80 c0063224
 5ec0: 0010 0010  c0660ac0 c0635f18 c005fcb8 c0632b90 c000ed94
 5ee0: c0313c60 6153 0001 c00085a8 c0313c54 c0313c60 6153 
 5f00: c0635f4c  562f5842 c06360c0  c000db60 001a 8ad0
 5f20: 8ad0 c06360c0   c04379c0 c22ad780  562f5842
 5f40: c06360c0  6153 c0635f60 c0313c54 c0313c60 6153 
 5f60: 0021  0003 0004 006e c065fcc0 c067924c c063ceb8
 5f80: c063cc84 c006d8c0 0005 c065fcc0 c067924c c0421764 c22ad780 c063c42c
 5fa0: 562f5842 c063cca8 c06605c0 c04379c0 c22ad780  562f5842 
 5fc0:  c0417754   c04172dc   c04379c0
 5fe0: 10c53c7d c063c414 c04379bc c063febc 406a 8074  
 [c023c2bc] (armada_370_xp_timer_interrupt+0x3c/0x4c) from [c0063224] 
 (handle_percpu_devid_irq+0x64/0x80)
 [c0063224] (handle_percpu_devid_irq+0x64/0x80) from [c005fcb8] 
 (generic_handle_irq+0x20/0x30)
 [c005fcb8] (generic_handle_irq+0x20/0x30) from [c000ed94] 
 (handle_IRQ+0x38/0x90)
 [c000ed94] (handle_IRQ+0x38/0x90) from [c00085a8] 
 (armada_370_xp_handle_irq+0xa4/0xb0)
 [c00085a8] (armada_370_xp_handle_irq+0xa4/0xb0) from [c000db60] 
 (__irq_svc+0x40/0x50)
 Exception stack(0xc0635f18 to 0xc0635f60)
 5f00:   001a 8ad0
 5f20: 8ad0 c06360c0   c04379c0 c22ad780  562f5842
 5f40: c06360c0  6153 c0635f60 c0313c54 c0313c60 6153 
 [c000db60] (__irq_svc+0x40/0x50) from [c0313c60] 
 (calibrate_delay+0x378/0x528)
 [c0313c60] (calibrate_delay+0x378/0x528) from [c0417754] 
 (start_kernel+0x250/0x2dc)
 [c0417754] (start_kernel+0x250/0x2dc) from [8074] (0x8074)
 Code: 1fe7deb7 cd5772dd fff5692e ed55f79e

Re: [PATCHv3 09/10] clocksource: time-armada-370-xp: Divorce from local timer API

2013-03-20 Thread Gregory CLEMENT

On 03/20/2013 06:20 PM, Stephen Boyd wrote:
 On 03/20/13 10:09, Gregory CLEMENT wrote:
 On 03/13/2013 07:17 PM, Stephen Boyd wrote:
 Separate the armada 370xp local timers from the local timer API.
 This will allow us to remove ARM local timer support in the near
 future and makes this driver multi-architecture friendly.
 At first view the code looks good, but when I applied your patch set on
 linux-next, build it and run it on a Armada XP based board (AX3 with 2 
 cores),
 it crashed:
 [...]
 Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
 Modules linked in:
 CPU: 0Not tainted  (3.9.0-rc3-next-20130319-00010-g728b448 #153)
 PC is at 0xe92d45f0
 LR is at armada_370_xp_timer_interrupt+0x3c/0x4c
 pc : [e92d45f0]lr : [c023c2bc]psr: 61d3
 sp : c0635eb8  ip :   fp : c063c3f0
 r10: 03ff  r9 :   r8 : 0010
 r7 : c22b3c40  r6 : ef007c00  r5 : c0640fcc  r4 : c0053e30
 r3 : e92d45f0  r2 : fffe  r1 : c22b3c40  r0 : c0053e30
 Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
 Control: 10c53c7d  Table: 406a  DAC: 0015
 Process swapper/0 (pid: 0, stack limit = 0xc0634238)
 Stack: (0xc0635eb8 to 0xc0636000)
 5ea0:   ef004c80 c0063224
 5ec0: 0010 0010  c0660ac0 c0635f18 c005fcb8 c0632b90 c000ed94
 5ee0: c0313c60 6153 0001 c00085a8 c0313c54 c0313c60 6153 
 5f00: c0635f4c  562f5842 c06360c0  c000db60 001a 8ad0
 5f20: 8ad0 c06360c0   c04379c0 c22ad780  562f5842
 5f40: c06360c0  6153 c0635f60 c0313c54 c0313c60 6153 
 5f60: 0021  0003 0004 006e c065fcc0 c067924c c063ceb8
 5f80: c063cc84 c006d8c0 0005 c065fcc0 c067924c c0421764 c22ad780 c063c42c
 5fa0: 562f5842 c063cca8 c06605c0 c04379c0 c22ad780  562f5842 
 5fc0:  c0417754   c04172dc   c04379c0
 5fe0: 10c53c7d c063c414 c04379bc c063febc 406a 8074  
 [c023c2bc] (armada_370_xp_timer_interrupt+0x3c/0x4c) from [c0063224] 
 (handle_percpu_devid_irq+0x64/0x80)
 [c0063224] (handle_percpu_devid_irq+0x64/0x80) from [c005fcb8] 
 (generic_handle_irq+0x20/0x30)
 [c005fcb8] (generic_handle_irq+0x20/0x30) from [c000ed94] 
 (handle_IRQ+0x38/0x90)
 [c000ed94] (handle_IRQ+0x38/0x90) from [c00085a8] 
 (armada_370_xp_handle_irq+0xa4/0xb0)
 [c00085a8] (armada_370_xp_handle_irq+0xa4/0xb0) from [c000db60] 
 (__irq_svc+0x40/0x50)
 Exception stack(0xc0635f18 to 0xc0635f60)
 5f00:   001a 8ad0
 5f20: 8ad0 c06360c0   c04379c0 c22ad780  562f5842
 5f40: c06360c0  6153 c0635f60 c0313c54 c0313c60 6153 
 [c000db60] (__irq_svc+0x40/0x50) from [c0313c60] 
 (calibrate_delay+0x378/0x528)
 [c0313c60] (calibrate_delay+0x378/0x528) from [c0417754] 
 (start_kernel+0x250/0x2dc)
 [c0417754] (start_kernel+0x250/0x2dc) from [8074] (0x8074)
 Code: 1fe7deb7 cd5772dd fff5692e ed55f79e (7ed5a5f7)



 I am trying to figure out what happened.
 
 Argh. Stupid casting again. Can you try this?

Our emails  must have crossed, your fix is also fine :)


 
 ---8
 
 diff --git a/drivers/clocksource/time-armada-370-xp.c 
 b/drivers/clocksource/time-armada-370-xp.c
 index ee2e50c5..a9bf37a 100644
 --- a/drivers/clocksource/time-armada-370-xp.c
 +++ b/drivers/clocksource/time-armada-370-xp.c
 @@ -150,7 +150,7 @@ static irqreturn_t armada_370_xp_timer_interrupt(int irq, 
 void *dev_id)
 /*
  * ACK timer interrupt and call event handler.
  */
 -   struct clock_event_device *evt = *(struct clock_event_device 
 **)dev_id;
 +   struct clock_event_device *evt = dev_id;
  
 writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
 evt-event_handler(evt);
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv3 09/10] clocksource: time-armada-370-xp: Divorce from local timer API

2013-03-20 Thread Gregory CLEMENT

On 03/20/2013 06:26 PM, Gregory CLEMENT wrote:
 On 03/20/2013 06:20 PM, Stephen Boyd wrote:
 On 03/20/13 10:09, Gregory CLEMENT wrote:
 On 03/13/2013 07:17 PM, Stephen Boyd wrote:
 Separate the armada 370xp local timers from the local timer API.
 This will allow us to remove ARM local timer support in the near
 future and makes this driver multi-architecture friendly.
 At first view the code looks good, but when I applied your patch set on
 linux-next, build it and run it on a Armada XP based board (AX3 with 2 
 cores),
 it crashed:
 [...]
 Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
 Modules linked in:
 CPU: 0Not tainted  (3.9.0-rc3-next-20130319-00010-g728b448 #153)
 PC is at 0xe92d45f0
 LR is at armada_370_xp_timer_interrupt+0x3c/0x4c
 pc : [e92d45f0]lr : [c023c2bc]psr: 61d3
 sp : c0635eb8  ip :   fp : c063c3f0
 r10: 03ff  r9 :   r8 : 0010
 r7 : c22b3c40  r6 : ef007c00  r5 : c0640fcc  r4 : c0053e30
 r3 : e92d45f0  r2 : fffe  r1 : c22b3c40  r0 : c0053e30
 Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
 Control: 10c53c7d  Table: 406a  DAC: 0015
 Process swapper/0 (pid: 0, stack limit = 0xc0634238)
 Stack: (0xc0635eb8 to 0xc0636000)
 5ea0:   ef004c80 
 c0063224
 5ec0: 0010 0010  c0660ac0 c0635f18 c005fcb8 c0632b90 
 c000ed94
 5ee0: c0313c60 6153 0001 c00085a8 c0313c54 c0313c60 6153 
 
 5f00: c0635f4c  562f5842 c06360c0  c000db60 001a 
 8ad0
 5f20: 8ad0 c06360c0   c04379c0 c22ad780  
 562f5842
 5f40: c06360c0  6153 c0635f60 c0313c54 c0313c60 6153 
 
 5f60: 0021  0003 0004 006e c065fcc0 c067924c 
 c063ceb8
 5f80: c063cc84 c006d8c0 0005 c065fcc0 c067924c c0421764 c22ad780 
 c063c42c
 5fa0: 562f5842 c063cca8 c06605c0 c04379c0 c22ad780  562f5842 
 
 5fc0:  c0417754   c04172dc   
 c04379c0
 5fe0: 10c53c7d c063c414 c04379bc c063febc 406a 8074  
 
 [c023c2bc] (armada_370_xp_timer_interrupt+0x3c/0x4c) from [c0063224] 
 (handle_percpu_devid_irq+0x64/0x80)
 [c0063224] (handle_percpu_devid_irq+0x64/0x80) from [c005fcb8] 
 (generic_handle_irq+0x20/0x30)
 [c005fcb8] (generic_handle_irq+0x20/0x30) from [c000ed94] 
 (handle_IRQ+0x38/0x90)
 [c000ed94] (handle_IRQ+0x38/0x90) from [c00085a8] 
 (armada_370_xp_handle_irq+0xa4/0xb0)
 [c00085a8] (armada_370_xp_handle_irq+0xa4/0xb0) from [c000db60] 
 (__irq_svc+0x40/0x50)
 Exception stack(0xc0635f18 to 0xc0635f60)
 5f00:   001a 
 8ad0
 5f20: 8ad0 c06360c0   c04379c0 c22ad780  
 562f5842
 5f40: c06360c0  6153 c0635f60 c0313c54 c0313c60 6153 
 
 [c000db60] (__irq_svc+0x40/0x50) from [c0313c60] 
 (calibrate_delay+0x378/0x528)
 [c0313c60] (calibrate_delay+0x378/0x528) from [c0417754] 
 (start_kernel+0x250/0x2dc)
 [c0417754] (start_kernel+0x250/0x2dc) from [8074] (0x8074)
 Code: 1fe7deb7 cd5772dd fff5692e ed55f79e (7ed5a5f7)



 I am trying to figure out what happened.

 Argh. Stupid casting again. Can you try this?
 
 Our emails  must have crossed, your fix is also fine :)
 

I have also tested the patch set on a Armada 370 based board (Armada 370 DB),
and it works well.
So with this last chunk you can add my:
Acked-by: Gregory CLEMENT gregory.clem...@free-electrons.com
and also my
tested-by: Gregory CLEMENT gregory.clem...@free-electrons.com


 

 ---8

 diff --git a/drivers/clocksource/time-armada-370-xp.c 
 b/drivers/clocksource/time-armada-370-xp.c
 index ee2e50c5..a9bf37a 100644
 --- a/drivers/clocksource/time-armada-370-xp.c
 +++ b/drivers/clocksource/time-armada-370-xp.c
 @@ -150,7 +150,7 @@ static irqreturn_t armada_370_xp_timer_interrupt(int 
 irq, void *dev_id)
 /*
  * ACK timer interrupt and call event handler.
  */
 -   struct clock_event_device *evt = *(struct clock_event_device 
 **)dev_id;
 +   struct clock_event_device *evt = dev_id;
  
 writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
 evt-event_handler(evt);

 
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] arm: mvebu: Select DMA_BOUNCE when LPAE is selected in Kconfig

2013-03-21 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

For mvebu IOs are 32 bits and we have 40 bits memory due to LPAE so
make sure we give 32 bits addresses to the IOs.

Signed-off-by: Lior Amsalem al...@marvell.com
Tested-by: Franklin f...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/mach-mvebu/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 440b13e..617da94 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -13,6 +13,7 @@ config ARCH_MVEBU
select MVEBU_CLK_CORE
select MVEBU_CLK_CPU
select MVEBU_CLK_GATING
+   select DMABOUNCE if ARM_LPAE
 
 if ARCH_MVEBU
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits

2013-03-21 Thread Gregory CLEMENT

In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.

Armada XP and Armada 370 share a dtsi file which have also be
converted to 64 bits. This lead to convert all the device tree files
to 64 bits even the one used for Armada 370 (which don't support
LPAE)

This was heavily based on the work of Lior Amsalem.

Signed-off-by: Lior Amsalem al...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/boot/dts/armada-370-db.dts  |2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts |2 +-
 arch/arm/boot/dts/armada-370-rd.dts  |2 +-
 arch/arm/boot/dts/armada-370-xp.dtsi |   45 +++---
 arch/arm/boot/dts/armada-370.dtsi|   28 +++---
 arch/arm/boot/dts/armada-xp-db.dts   |2 +-
 arch/arm/boot/dts/armada-xp-gp.dts   |   14 ---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |6 +--
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   10 ++---
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   10 ++---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 +-
 arch/arm/boot/dts/armada-xp.dtsi |   34 
 12 files changed, 80 insertions(+), 77 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index e34b280..0bde82c 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -26,7 +26,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x4000; /* 1 GB */
+   reg = 0 0x 0 0x4000; /* 1 GB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts 
b/arch/arm/boot/dts/armada-370-mirabox.dts
index dd0c57d..fd08cd6 100644
--- a/arch/arm/boot/dts/armada-370-mirabox.dts
+++ b/arch/arm/boot/dts/armada-370-mirabox.dts
@@ -21,7 +21,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x2000; /* 512 MB */
+   reg = 0 0x 0 0x2000; /* 512 MB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-370-rd.dts 
b/arch/arm/boot/dts/armada-370-rd.dts
index 070bba4..e51948d 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -24,7 +24,7 @@
 
memory {
device_type = memory;
-   reg = 0x 0x2000; /* 512 MB */
+   reg = 0 0x 0 0x2000; /* 512 MB */
};
 
soc {
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 5b70820..562f24c 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -15,8 +15,7 @@
  * This file contains the definitions that are common to the Armada
  * 370 and Armada XP SoC.
  */
-
-/include/ skeleton.dtsi
+/include/ skeleton64.dtsi
 
 / {
model = Marvell Armada 370 and XP SoC;
@@ -37,20 +36,20 @@
 
coherency-fabric@d0020200 {
compatible = marvell,coherency-fabric;
-   reg = 0xd0020200 0xb0,
- 0xd0021810 0x1c;
+   reg = 0 0xd0020200 0 0xb0,
+ 0 0xd0021810 0 0x1c;
};
 
soc {
-   #address-cells = 1;
-   #size-cells = 1;
+   #address-cells = 2;
+   #size-cells = 2;
compatible = simple-bus;
interrupt-parent = mpic;
ranges;
 
serial@d0012000 {
compatible = snps,dw-apb-uart;
-   reg = 0xd0012000 0x100;
+   reg = 0 0xd0012000 0 0x100;
reg-shift = 2;
interrupts = 41;
reg-io-width = 1;
@@ -58,7 +57,7 @@
};
serial@d0012100 {
compatible = snps,dw-apb-uart;
-   reg = 0xd0012100 0x100;
+   reg = 0 0xd0012100 0 0x100;
reg-shift = 2;
interrupts = 42;
reg-io-width = 1;
@@ -67,20 +66,20 @@
 
timer@d0020300 {
   compatible = marvell,armada-370-xp-timer;
-  reg = 0xd0020300 0x30,
-  0xd0021040 0x30;
+  reg = 0 0xd0020300 0 0x30,
+  0 0xd0021040 0 0x30;
   interrupts = 37, 38, 39, 40, 5, 6;
   clocks = coreclk 2;
};
 
addr-decoding@d002 {
compatible = marvell,armada-addr-decoding-controller;
-   reg = 0xd002 0x258

[PATCH 0/5] arm: mvebu: Enable LPAE support for Armada XP SoCs

2013-03-21 Thread Gregory CLEMENT

Hello,

The Armada XP SoCs have LPAE support. This patch set allow to run
kernel on this SoCs with LPAE support.

The biggest changes are the conversion of the device tree file to 64
bits in order to be able to use more than 4GB of memory (without this
the LPAE is pointless).

This patch set have been tested on a Armada XP GP board with 8GB of
DRAM with LPAE selected. It have been tested on Armada XP DB board
with 3GB of DRAM with and without LPAE. And also on the Armada 370 DB
board (without LPAE) to check that no regression appeared.

This patch set is based on 3.9-rc3 and is 3.10 material. The
git branch called lpae is available at:
https://github.com/MISL-EBU-System-SW/mainline-public.git.

Thanks,

Gregory CLEMENT (1):
  arm: dts: Convert mvebu device tree files to 64 bits

Lior Amsalem (4):
  arm: mvebu: Aligne the internal registers virtual base to support
LPAE
  arm: mvebu: Select DMA_BOUNCE when LPAE is selected in Kconfig
  arm: mvebu: Enable pj4b on LPAE compilations
  arm: dts: Add a 64 bits version of the skeleton device tree

 arch/arm/boot/dts/armada-370-db.dts  |2 +-
 arch/arm/boot/dts/armada-370-mirabox.dts |2 +-
 arch/arm/boot/dts/armada-370-rd.dts  |2 +-
 arch/arm/boot/dts/armada-370-xp.dtsi |   45 +++---
 arch/arm/boot/dts/armada-370.dtsi|   28 +++---
 arch/arm/boot/dts/armada-xp-db.dts   |2 +-
 arch/arm/boot/dts/armada-xp-gp.dts   |   14 ---
 arch/arm/boot/dts/armada-xp-mv78230.dtsi |6 +--
 arch/arm/boot/dts/armada-xp-mv78260.dtsi |   10 ++---
 arch/arm/boot/dts/armada-xp-mv78460.dtsi |   10 ++---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts |2 +-
 arch/arm/boot/dts/armada-xp.dtsi |   34 
 arch/arm/boot/dts/skeleton64.dtsi|   13 +++
 arch/arm/include/debug/mvebu.S   |2 +-
 arch/arm/mach-mvebu/Kconfig  |1 +
 arch/arm/mach-mvebu/armada-370-xp.h  |2 +-
 arch/arm/mm/proc-v7.S|3 +-
 17 files changed, 98 insertions(+), 80 deletions(-)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] arm: mvebu: Aligne the internal registers virtual base to support LPAE

2013-03-21 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

In order to be able to support he LPAE, the internal registers virtual
base must be aligned to 2MB.

Signed-off-by: Lior Amsalem al...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/include/debug/mvebu.S  |2 +-
 arch/arm/mach-mvebu/armada-370-xp.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
index 865c6d0..df191af 100644
--- a/arch/arm/include/debug/mvebu.S
+++ b/arch/arm/include/debug/mvebu.S
@@ -12,7 +12,7 @@
 */
 
 #define ARMADA_370_XP_REGS_PHYS_BASE   0xd000
-#define ARMADA_370_XP_REGS_VIRT_BASE   0xfeb0
+#define ARMADA_370_XP_REGS_VIRT_BASE   0xfec0
 
.macro  addruart, rp, rv, tmp
ldr \rp, =ARMADA_370_XP_REGS_PHYS_BASE
diff --git a/arch/arm/mach-mvebu/armada-370-xp.h 
b/arch/arm/mach-mvebu/armada-370-xp.h
index c6a7d74..c49c08e 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.h
+++ b/arch/arm/mach-mvebu/armada-370-xp.h
@@ -16,7 +16,7 @@
 #define __MACH_ARMADA_370_XP_H
 
 #define ARMADA_370_XP_REGS_PHYS_BASE   0xd000
-#define ARMADA_370_XP_REGS_VIRT_BASE   IOMEM(0xfeb0)
+#define ARMADA_370_XP_REGS_VIRT_BASE   IOMEM(0xfec0)
 #define ARMADA_370_XP_REGS_SIZESZ_1M
 
 #ifdef CONFIG_SMP
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] arm: dts: Add a 64 bits version of the skeleton device tree

2013-03-21 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

In order to be able to use more than 4GB address-cells and size-cells
have to be set to 2

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Lior Amsalem al...@marvell.com
---
 arch/arm/boot/dts/skeleton64.dtsi |   13 +
 1 file changed, 13 insertions(+)
 create mode 100644 arch/arm/boot/dts/skeleton64.dtsi

diff --git a/arch/arm/boot/dts/skeleton64.dtsi 
b/arch/arm/boot/dts/skeleton64.dtsi
new file mode 100644
index 000..1599415
--- /dev/null
+++ b/arch/arm/boot/dts/skeleton64.dtsi
@@ -0,0 +1,13 @@
+/*
+ * Skeleton device tree in the 64 bits version; the bare minimum
+ * needed to boot; just include and add a compatible value.  The
+ * bootloader will typically populate the memory node.
+ */
+
+/ {
+   #address-cells = 2;
+   #size-cells = 2;
+   chosen { };
+   aliases { };
+   memory { device_type = memory; reg = 0 0; };
+};
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] arm: mvebu: Enable pj4b on LPAE compilations

2013-03-21 Thread Gregory CLEMENT

From: Lior Amsalem al...@marvell.com

pj4b cpus are LPAE capable so enable them on LPAE compilations

Signed-off-by: Lior Amsalem al...@marvell.com
Tested-by: Franklin f...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 arch/arm/mm/proc-v7.S |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 3a3c015..159c747 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -402,6 +402,8 @@ __v7_ca9mp_proc_info:
__v7_proc __v7_ca9mp_setup
.size   __v7_ca9mp_proc_info, . - __v7_ca9mp_proc_info
 
+#endif /* CONFIG_ARM_LPAE */
+
/*
 * Marvell PJ4B processor.
 */
@@ -411,7 +413,6 @@ __v7_pj4b_proc_info:
.long   0xfff0
__v7_proc __v7_pj4b_setup
.size   __v7_pj4b_proc_info, . - __v7_pj4b_proc_info
-#endif /* CONFIG_ARM_LPAE */
 
/*
 * ARM Ltd. Cortex A7 processor.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Serial port initialization broken on Armada 370/XP due to serial: 8250_dw: Don't use UPF_FIXED_TYPE

2013-02-27 Thread Gregory CLEMENT

Hello,

when I tried to use the linux-next git tree (next-20130226), I
encountered a problem during boot: the serial port was no more
initialized on my Armada XP (ARM SoC) base board . I get:

[...]
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
sata_mv d00a.sata: slots 32 ports 2
[...]
turn off boot console earlycon0


And then nothing.

So after git bisect I ended to the commit  serial: 8250_dw: Don't use
UPF_FIXED_TYPE. Then by adding again the UPF_FIXED_TYPE flag (ie
reverting this commit) I got the usual boot log:

[...]
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
d0012000.serial: ttyS0 at MMIO 0xd0012000 (irq = 17) is a 8250
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
d0012100.serial: ttyS1 at MMIO 0xd0012100 (irq = 18) is a 8250
d0012200.serial: ttyS2 at MMIO 0xd0012200 (irq = 29) is a 8250
d0012300.serial: ttyS3 at MMIO 0xd0012300 (irq = 30) is a 8250
sata_mv d00a.sata: slots 32 ports 2
[...]
Freeing init memory: 2160K
Starting logging: OK
Initializing random number generator... done.
Starting network...

Welcome to Buildroot
buildroot login:



I understand that the purpose of this commit was to let the driver
find by itself the port type, but I didn't find yet how it managed to
do it and then why it failed in our case.

I will continue to investigate but any pointers are welcome.

Thanks,

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial port initialization broken on Armada 370/XP due to serial: 8250_dw: Don't use UPF_FIXED_TYPE

2013-02-27 Thread Gregory CLEMENT

On 02/27/2013 03:40 PM, Gregory CLEMENT wrote:
 Hello,
 

[ I have added linux-serial mailing list as I should added them
initially ]

 when I tried to use the linux-next git tree (next-20130226), I
 encountered a problem during boot: the serial port was no more
 initialized on my Armada XP (ARM SoC) base board . I get:
 
 [...]
 Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
 sata_mv d00a.sata: slots 32 ports 2
 [...]
 turn off boot console earlycon0
 
 
 And then nothing.
 
 So after git bisect I ended to the commit  serial: 8250_dw: Don't use
 UPF_FIXED_TYPE. Then by adding again the UPF_FIXED_TYPE flag (ie
 reverting this commit) I got the usual boot log:
 
 [...]
 Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
 d0012000.serial: ttyS0 at MMIO 0xd0012000 (irq = 17) is a 8250
 console [ttyS0] enabled, bootconsole disabled
 console [ttyS0] enabled, bootconsole disabled
 d0012100.serial: ttyS1 at MMIO 0xd0012100 (irq = 18) is a 8250
 d0012200.serial: ttyS2 at MMIO 0xd0012200 (irq = 29) is a 8250
 d0012300.serial: ttyS3 at MMIO 0xd0012300 (irq = 30) is a 8250
 sata_mv d00a.sata: slots 32 ports 2
 [...]
 Freeing init memory: 2160K
 Starting logging: OK
 Initializing random number generator... done.
 Starting network...
 
 Welcome to Buildroot
 buildroot login:
 
 
 
 I understand that the purpose of this commit was to let the driver
 find by itself the port type, but I didn't find yet how it managed to
 do it and then why it failed in our case.
 
 I will continue to investigate but any pointers are welcome.
 

I found the root of the problem in drivers/tty/serial/8250/8250.c

in the autoconfig() function, when the IIR register is acceded, it is
done using serial_in(), this function return an int but is used as it
have returned a char. There is a lot of implicit cast to a char when
the returned value is put in a char variable, this seems to not be a
problem most of the time. The problematic line is the following:

scratch = serial_in(up, UART_IIR)  6;

the shift is done here before any cast or mask, and unfortunately my
hardware send 0xC1C1C1C1, that lead to get a '7' in the scratch
variable instead of a '3'.

Would you agree with this kind of patch to fix the issue?

diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index e2ac25a..0b284c6 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -1119,7 +1119,7 @@ static void autoconfig(struct uart_8250_port *up, 
unsigned int probeflags)
serial_out(up, UART_LCR, 0);

serial_out(up, UART_FCR, UART_FCR_ENABLE_FIFO);
-   scratch = serial_in(up, UART_IIR)  6;
+   scratch = (serial_in(up, UART_IIR)  0xFF)  6;

switch (scratch) {
case 0:




-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Serial port initialization broken on Armada 370/XP due to serial: 8250_dw: Don't use UPF_FIXED_TYPE

2013-02-28 Thread Gregory CLEMENT

Hi Heikki,

On 02/28/2013 10:26 AM, Heikki Krogerus wrote:
 Hi Gregory.
 
 On Wed, Feb 27, 2013 at 05:08:04PM +0100, Gregory CLEMENT wrote:
 I found the root of the problem in drivers/tty/serial/8250/8250.c

 in the autoconfig() function, when the IIR register is acceded, it is
 done using serial_in(), this function return an int but is used as it
 have returned a char. There is a lot of implicit cast to a char when
 the returned value is put in a char variable, this seems to not be a
 problem most of the time. The problematic line is the following:

 scratch = serial_in(up, UART_IIR)  6;

 the shift is done here before any cast or mask, and unfortunately my
 hardware send 0xC1C1C1C1, that lead to get a '7' in the scratch
 variable instead of a '3'.
 
 OK, this is interesting. Why does it return that? dw_apb_uart_db.pdf I
 have says that bits 31:8 read as zero?

The UART paragraphs on the Armada 370/XP datasheet also says the same
thing.  Actually for all the register the bits 31:8 should be 0.I
suspect an hardware issue (or let's call it an optimization), as the
upper bits are not supposed to be used.

 
 Would you agree with this kind of patch to fix the issue?

 diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
 index e2ac25a..0b284c6 100644
 --- a/drivers/tty/serial/8250/8250.c
 +++ b/drivers/tty/serial/8250/8250.c
 @@ -1119,7 +1119,7 @@ static void autoconfig(struct uart_8250_port *up, 
 unsigned int probeflags)
 serial_out(up, UART_LCR, 0);

 serial_out(up, UART_FCR, UART_FCR_ENABLE_FIFO);
 -   scratch = serial_in(up, UART_IIR)  6;
 +   scratch = (serial_in(up, UART_IIR)  0xFF)  6;

 switch (scratch) {
 case 0:
 
 Instead, can you test if it's enough for you to set the reg-io-width
 to 1 instead of 4:

Yes indeed it worked and it seems to be the correct description of my
hardware. So I will fix the dtsi file.

However isn't buggy to use a function as it returned a char whereas
it returns an int?

Regards,

 
 diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
 b/arch/arm/boot/dts/armada-370-xp.dtsi
 index 4c0abe8..3a87a0e 100644
 --- a/arch/arm/boot/dts/armada-370-xp.dtsi
 +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
 @@ -54,7 +54,7 @@
 reg = 0xd0012000 0x100;
 reg-shift = 2;
 interrupts = 41;
 -   reg-io-width = 4;
 +   reg-io-width = 1;
 status = disabled;
 };
 serial@d0012100 {
 @@ -62,7 +62,7 @@
 reg = 0xd0012100 0x100;
 reg-shift = 2;
 interrupts = 42;
 -   reg-io-width = 4;
 +   reg-io-width = 1;
 status = disabled;
 };
  
 Thanks,
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG][arm-soc] kernel panic in boot on Openblocks with the latest kernel

2013-03-01 Thread Gregory CLEMENT

On 03/01/2013 09:00 AM, Heikki Krogerus wrote:
 Hi Jason,
 
 On Thu, Feb 28, 2013 at 09:29:30AM -0500, Jason Cooper wrote:
 If you have a moment, could you put this into a formal patch and send to
 lakml?  If I could Gregory and Masami's Tested-by's on that, I'll queue
 it up for -rc1/2.
 
 OK, I'll prepare the patch. I thought that Gregory was going to create
 a patch for this.

If you want I still can take care of it.

 
 Br,
 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/3] gpio: pca953x: add support for pca9505

2013-01-25 Thread Gregory CLEMENT

On 01/25/2013 09:16 AM, Linus Walleij wrote:
 On Tue, Jan 22, 2013 at 10:10 PM, Gregory CLEMENT
 gregory.clem...@free-electrons.com wrote:
 
 Now that pca953x driver can handle GPIO expanders with more than 32
 bits this patch adds the support for the pca9505 which cam with 40
 GPIOs.

 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 
 Patch applied, thanks.
 
 But guys, this driver contains some horrific stuff, look at this:
 
 static int pxa_gpio_nums(void)
 {
 int count = 0;
 
 #ifdef CONFIG_ARCH_PXA
 if (cpu_is_pxa25x()) {
 #ifdef CONFIG_CPU_PXA26x
 count = 89;
 gpio_type = PXA26X_GPIO;
 #elif defined(CONFIG_PXA25x)
 count = 84;
 gpio_type = PXA26X_GPIO;
 #endif /* CONFIG_CPU_PXA26x */
 } else if (cpu_is_pxa27x()) {
 count = 120;
 gpio_type = PXA27X_GPIO;
 } else if (cpu_is_pxa93x()) {
 count = 191;
 gpio_type = PXA93X_GPIO;
 } else if (cpu_is_pxa3xx()) {
 count = 127;
 gpio_type = PXA3XX_GPIO;
 }
 #endif /* CONFIG_ARCH_PXA */
 
 #ifdef CONFIG_ARCH_MMP
 if (cpu_is_pxa168() || cpu_is_pxa910()) {
 count = 127;
 gpio_type = MMP_GPIO;
 } else if (cpu_is_mmp2()) {
 count = 191;
 gpio_type = MMP_GPIO;
 }
 #endif /* CONFIG_ARCH_MMP */
 return count;
 }
 
 This is totally killing all attempts at a single kernel for multiple
 machines in this family. The above should not be #ifdef's but instead
 use either platform data or the compatible property to figure out which
 one to use.
 
 It's fine to introduce new compatible= strings or device names to
 distinguish between these.
 
 As an example, in pinctrl-nomadik.c we have this:
 
 static const struct of_device_id nmk_pinctrl_match[] = {
 {
 .compatible = stericsson,nmk_pinctrl,
 .data = (void *)PINCTRL_NMK_DB8500,
 },
 {},
 };
 
 static const struct platform_device_id nmk_pinctrl_id[] = {
 { pinctrl-stn8815, PINCTRL_NMK_STN8815 },
 { pinctrl-db8500, PINCTRL_NMK_DB8500 },
 { pinctrl-db8540, PINCTRL_NMK_DB8540 },
 { }
 };
 
 static struct platform_driver nmk_pinctrl_driver = {
 .driver = {
 .owner = THIS_MODULE,
 .name = pinctrl-nomadik,
 .of_match_table = nmk_pinctrl_match,
 },
 .probe = nmk_pinctrl_probe,
 .id_table = nmk_pinctrl_id,
 };
 
 
 The first match is for DT boot the latter for using the platform
 device name directly.
 
 Then in the probefunction we do:
 
 static int nmk_pinctrl_probe(struct platform_device *pdev)
 {
 const struct platform_device_id *platid = 
 platform_get_device_id(pdev);
 (...)
 if (platid)
 version = platid-driver_data;
 else if (np) {
 const struct of_device_id *match;
 
 match = of_match_device(nmk_pinctrl_match, pdev-dev);
 if (!match)
 return -ENODEV;
 version = (unsigned int) match-data;
 }
 (...)
 if (version == PINCTRL_NMK_STN8815)
 nmk_pinctrl_stn8815_init(npct-soc);
 if (version == PINCTRL_NMK_DB8500)
 nmk_pinctrl_db8500_init(npct-soc);
 if (version == PINCTRL_NMK_DB8540)
 nmk_pinctrl_db8540_init(npct-soc);
 }
 
 Surely a scheme like this must be possible to use to distinguish between
 the different versions at runtime rather than using these #ifdefs?
 

Well, at the beginning I thought adding support for pca9505 was just a matter
of a couple of lines to add. Then I realized that I need to handle the 40 bits
case, and I ended up refactoring all access to the registers. So now I am on it,
it seems I am volunteer to continue to improve this driver.

However I won't be able to test it, the only PXA based platform I have is a
Zaurus SL-C3100 which embeds a PXA270 if I remember well, but I doubt it come
with gpio expander on i2c.

Gregory
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] Improvement for pca953x drivers

2013-01-25 Thread Gregory CLEMENT

Hi Linus,

those two patches are the begining of the improvement work we have
spoken about earlier. I started with the two patches you sent.

I've just made a small fix to make it build on the 2nd patch so I keep
your autorship and signed-off.

For the second one, it didn't build too, but I made a more substantial
change on it by moving the setting of the irq to the map function. So
for this one, I took the authorship and remove your signed-off to not
make you responsible of my possible bug! :)

I've compiled and run it, but as I don't have support for the pca905
interrupt on my board, I can't say it didn't break anything. Maybe
this time again Maxime will be willing to test it.

For the remaining improvement related to the PWA and MMP #ifdef, I
hope to be able to work on it this week-end.

Regards

Gregory CLEMENT (1):
  gpio: pca953x: use simple irqdomain

Linus Walleij (1):
  gpio: pca953x: use managed resources

 drivers/gpio/gpio-pca953x.c |   97 ---
 1 file changed, 36 insertions(+), 61 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] gpio: pca953x: use managed resources

2013-01-25 Thread Gregory CLEMENT

From: Linus Walleij linus.wall...@linaro.org

Using the devm_* managed resources the pca driver can be simplified
and cut down on boilerplate code.

[gcl: fixed a inccorect reference to a removed label, goto fail_out
became return ret]

Signed-off-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 drivers/gpio/gpio-pca953x.c |   32 
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 1dc9906..2405946 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -560,7 +560,7 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
}
ret = pca953x_read_regs(chip, offset, chip-irq_stat);
if (ret)
-   goto out_failed;
+   return ret;
 
/*
 * There is no way to know which GPIO line generated the
@@ -579,7 +579,8 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
if (!chip-domain)
return -ENODEV;
 
-   ret = request_threaded_irq(client-irq,
+   ret = devm_request_threaded_irq(client-dev,
+   client-irq,
   NULL,
   pca953x_irq_handler,
   IRQF_TRIGGER_LOW | IRQF_ONESHOT,
@@ -596,12 +597,6 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
return 0;
 }
 
-static void pca953x_irq_teardown(struct pca953x_chip *chip)
-{
-   if (chip-irq_base != -1) {
-   free_irq(chip-client-irq, chip);
-   }
-}
 #else /* CONFIG_GPIO_PCA953X_IRQ */
 static int pca953x_irq_setup(struct pca953x_chip *chip,
 const struct i2c_device_id *id,
@@ -614,10 +609,6 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
 
return 0;
 }
-
-static void pca953x_irq_teardown(struct pca953x_chip *chip)
-{
-}
 #endif
 
 /*
@@ -736,7 +727,8 @@ static int pca953x_probe(struct i2c_client *client,
int ret;
u32 invert = 0;
 
-   chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
+   chip = devm_kzalloc(client-dev,
+   sizeof(struct pca953x_chip), GFP_KERNEL);
if (chip == NULL)
return -ENOMEM;
 
@@ -771,15 +763,15 @@ static int pca953x_probe(struct i2c_client *client,
else
ret = device_pca957x_init(chip, invert);
if (ret)
-   goto out_failed;
+   return ret;
 
ret = pca953x_irq_setup(chip, id, irq_base);
if (ret)
-   goto out_failed;
+   return ret;
 
ret = gpiochip_add(chip-gpio_chip);
if (ret)
-   goto out_failed_irq;
+   return ret;
 
if (pdata  pdata-setup) {
ret = pdata-setup(client, chip-gpio_chip.base,
@@ -790,12 +782,6 @@ static int pca953x_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, chip);
return 0;
-
-out_failed_irq:
-   pca953x_irq_teardown(chip);
-out_failed:
-   kfree(chip);
-   return ret;
 }
 
 static int pca953x_remove(struct i2c_client *client)
@@ -821,8 +807,6 @@ static int pca953x_remove(struct i2c_client *client)
return ret;
}
 
-   pca953x_irq_teardown(chip);
-   kfree(chip);
return 0;
 }
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] gpio: pca953x: use simple irqdomain

2013-01-25 Thread Gregory CLEMENT

This switches the legacy irqdomain to the simple one, which will
auto-allocate descriptors, and also make sure that we use
irq_create_mapping() in the to_irq function. Also use the map function
of irq_domain_ops to setup the irq configuration on demand and no more
statically during the initialization of the driver.

Based on a initial patch from Linus Walleij linus.wall...@linaro.org

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 drivers/gpio/gpio-pca953x.c |   65 +++
 1 file changed, 28 insertions(+), 37 deletions(-)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 3a68aed..1dc9906 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -89,7 +89,6 @@ struct pca953x_chip {
u8 irq_stat[MAX_BANK];
u8 irq_trig_raise[MAX_BANK];
u8 irq_trig_fall[MAX_BANK];
-   int  irq_base;
struct irq_domain *domain;
 #endif
 
@@ -372,7 +371,7 @@ static int pca953x_gpio_to_irq(struct gpio_chip *gc, 
unsigned off)
struct pca953x_chip *chip;
 
chip = container_of(gc, struct pca953x_chip, gpio_chip);
-   return chip-irq_base + off;
+   return irq_create_mapping(chip-domain, off);
 }
 
 static void pca953x_irq_mask(struct irq_data *d)
@@ -520,6 +519,27 @@ static irqreturn_t pca953x_irq_handler(int irq, void 
*devid)
return IRQ_HANDLED;
 }
 
+static int pca953x_gpio_irq_map(struct irq_domain *d, unsigned int irq,
+  irq_hw_number_t hwirq)
+{
+   irq_clear_status_flags(irq, IRQ_NOREQUEST);
+   irq_set_chip_data(irq, d-host_data);
+   irq_set_chip(irq, pca953x_irq_chip);
+   irq_set_nested_thread(irq, true);
+#ifdef CONFIG_ARM
+   set_irq_flags(irq, IRQF_VALID);
+#else
+   irq_set_noprobe(irq);
+#endif
+
+   return 0;
+}
+
+static const struct irq_domain_ops pca953x_irq_simple_ops = {
+   .map = pca953x_gpio_irq_map,
+   .xlate = irq_domain_xlate_twocell,
+};
+
 static int pca953x_irq_setup(struct pca953x_chip *chip,
 const struct i2c_device_id *id,
 int irq_base)
@@ -529,7 +549,6 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
 
if (irq_base != -1
 (id-driver_data  PCA_INT)) {
-   int lvl;
 
switch (chip-chip_type) {
case PCA953X_TYPE:
@@ -552,34 +571,13 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
chip-irq_stat[i] = chip-reg_direction[i];
mutex_init(chip-irq_lock);
 
-   chip-irq_base = irq_alloc_descs(-1, irq_base, 
chip-gpio_chip.ngpio, -1);
-   if (chip-irq_base  0)
-   goto out_failed;
-
-   chip-domain = irq_domain_add_legacy(client-dev.of_node,
+   chip-domain = irq_domain_add_simple(client-dev.of_node,
chip-gpio_chip.ngpio,
-   chip-irq_base,
-   0,
-   irq_domain_simple_ops,
+   irq_base,
+   pca953x_irq_simple_ops,
NULL);
-   if (!chip-domain) {
-   ret = -ENODEV;
-   goto out_irqdesc_free;
-   }
-
-   for (lvl = 0; lvl  chip-gpio_chip.ngpio; lvl++) {
-   int irq = lvl + chip-irq_base;
-
-   irq_clear_status_flags(irq, IRQ_NOREQUEST);
-   irq_set_chip_data(irq, chip);
-   irq_set_chip(irq, pca953x_irq_chip);
-   irq_set_nested_thread(irq, true);
-#ifdef CONFIG_ARM
-   set_irq_flags(irq, IRQF_VALID);
-#else
-   irq_set_noprobe(irq);
-#endif
-   }
+   if (!chip-domain)
+   return -ENODEV;
 
ret = request_threaded_irq(client-irq,
   NULL,
@@ -589,25 +587,18 @@ static int pca953x_irq_setup(struct pca953x_chip *chip,
if (ret) {
dev_err(client-dev, failed to request irq %d\n,
client-irq);
-   goto out_irqdesc_free;
+   return ret;
}
 
chip-gpio_chip.to_irq = pca953x_gpio_to_irq;
}
 
return 0;
-
-out_irqdesc_free:
-   irq_free_descs(chip-irq_base, chip-gpio_chip.ngpio);
-out_failed:
-   chip-irq_base = -1;
-   return ret;
 }
 
 static void pca953x_irq_teardown(struct pca953x_chip *chip)
 {
if (chip-irq_base != -1) {
-   irq_free_descs(chip-irq_base, chip-gpio_chip.ngpio);
free_irq(chip-client-irq, chip

[PATCH v2 2/5] clocksource: time-armada-370-xp: add local timer support

2013-01-25 Thread Gregory CLEMENT

On the SOCs Armada 370 and Armada XP, each CPU comes with two private
timers. This patch use the timer 0 of each CPU as local timer for the
clockevent if CONFIG_LOCAL_TIMER is selected. In the other case, use
only the private Timer 0 of CPU 0.

Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
 drivers/clocksource/time-armada-370-xp.c |  150 ++
 1 file changed, 112 insertions(+), 38 deletions(-)

diff --git a/drivers/clocksource/time-armada-370-xp.c 
b/drivers/clocksource/time-armada-370-xp.c
index a4605fd..47a6730 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -27,8 +27,10 @@
 #include linux/of_address.h
 #include linux/irq.h
 #include linux/module.h
-#include asm/sched_clock.h
 
+#include asm/sched_clock.h
+#include asm/localtimer.h
+#include linux/percpu.h
 /*
  * Timer block registers.
  */
@@ -49,6 +51,7 @@
 #define TIMER1_RELOAD_OFF  0x0018
 #define TIMER1_VAL_OFF 0x001c
 
+#define LCL_TIMER_EVENTS_STATUS0x0028
 /* Global timers are connected to the coherency fabric clock, and the
below divider reduces their incrementing frequency. */
 #define TIMER_DIVIDER_SHIFT 5
@@ -57,14 +60,17 @@
 /*
  * SoC-specific data.
  */
-static void __iomem *timer_base;
-static int timer_irq;
+static void __iomem *timer_base, *local_base;
+static unsigned int timer_clk;
+static bool timer25Mhz = true;
 
 /*
  * Number of timer ticks per jiffy.
  */
 static u32 ticks_per_jiffy;
 
+static struct clock_event_device __percpu **percpu_armada_370_xp_evt;
+
 static u32 notrace armada_370_xp_read_sched_clock(void)
 {
return ~readl(timer_base + TIMER0_VAL_OFF);
@@ -78,24 +84,23 @@ armada_370_xp_clkevt_next_event(unsigned long delta,
struct clock_event_device *dev)
 {
u32 u;
-
/*
 * Clear clockevent timer interrupt.
 */
-   writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
+   writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
 
/*
 * Setup new clockevent timer value.
 */
-   writel(delta, timer_base + TIMER1_VAL_OFF);
+   writel(delta, local_base + TIMER0_VAL_OFF);
 
/*
 * Enable the timer.
 */
-   u = readl(timer_base + TIMER_CTRL_OFF);
-   u = ((u  ~TIMER1_RELOAD_EN) | TIMER1_EN |
-TIMER1_DIV(TIMER_DIVIDER_SHIFT));
-   writel(u, timer_base + TIMER_CTRL_OFF);
+   u = readl(local_base + TIMER_CTRL_OFF);
+   u = ((u  ~TIMER0_RELOAD_EN) | TIMER0_EN |
+TIMER0_DIV(TIMER_DIVIDER_SHIFT));
+   writel(u, local_base + TIMER_CTRL_OFF);
 
return 0;
 }
@@ -107,37 +112,38 @@ armada_370_xp_clkevt_mode(enum clock_event_mode mode,
u32 u;
 
if (mode == CLOCK_EVT_MODE_PERIODIC) {
+
/*
 * Setup timer to fire at 1/HZ intervals.
 */
-   writel(ticks_per_jiffy - 1, timer_base + TIMER1_RELOAD_OFF);
-   writel(ticks_per_jiffy - 1, timer_base + TIMER1_VAL_OFF);
+   writel(ticks_per_jiffy - 1, local_base + TIMER0_RELOAD_OFF);
+   writel(ticks_per_jiffy - 1, local_base + TIMER0_VAL_OFF);
 
/*
 * Enable timer.
 */
-   u = readl(timer_base + TIMER_CTRL_OFF);
 
-   writel((u | TIMER1_EN | TIMER1_RELOAD_EN |
-   TIMER1_DIV(TIMER_DIVIDER_SHIFT)),
-  timer_base + TIMER_CTRL_OFF);
+   u = readl(local_base + TIMER_CTRL_OFF);
+
+   writel((u | TIMER0_EN | TIMER0_RELOAD_EN |
+   TIMER0_DIV(TIMER_DIVIDER_SHIFT)),
+   local_base + TIMER_CTRL_OFF);
} else {
/*
 * Disable timer.
 */
-   u = readl(timer_base + TIMER_CTRL_OFF);
-   writel(u  ~TIMER1_EN, timer_base + TIMER_CTRL_OFF);
+   u = readl(local_base + TIMER_CTRL_OFF);
+   writel(u  ~TIMER0_EN, local_base + TIMER_CTRL_OFF);
 
/*
 * ACK pending timer interrupt.
 */
-   writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS);
-
+   writel(TIMER0_CLR_MASK, local_base + LCL_TIMER_EVENTS_STATUS);
}
 }
 
 static struct clock_event_device armada_370_xp_clkevt = {
-   .name   = armada_370_xp_tick,
+   .name   = armada_370_xp_per_cpu_tick,
.features   = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
.shift  = 32,
.rating = 300,
@@ -150,32 +156,78 @@ static irqreturn_t armada_370_xp_timer_interrupt(int irq, 
void *dev_id)
/*
 * ACK timer interrupt and call event handler.
 */
+   struct clock_event_device *evt = *(struct clock_event_device **)dev_id;
 
-   writel(TIMER1_CLR_MASK, timer_base + TIMER_EVENTS_STATUS

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 3300 matches

Mail list logo