[Patch 2/5] dt: unittest: typo in error string

2015-03-13 Thread Frank Rowand
From: Frank Rowand 

Fix bug pointed out by checkpatch.

Splitting string incorrectly removed a space between two words.

Signed-off-by: Frank Rowand 
---
 drivers/of/unittest.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: b/drivers/of/unittest.c
===
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -212,8 +212,9 @@ static void __init of_selftest_check_tre
child_count = of_selftest_check_node_linkage(of_root);
 
selftest(child_count > 0, "Device node data structure is corrupted\n");
-   selftest(child_count == allnode_count, "allnodes list size (%i) doesn't 
match"
-"sibling lists size (%i)\n", allnode_count, child_count);
+   selftest(child_count == allnode_count,
+"allnodes list size (%i) doesn't match sibling lists size 
(%i)\n",
+allnode_count, child_count);
pr_debug("allnodes list size (%i); sibling lists size (%i)\n", 
allnode_count, child_count);
 }
 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Patch 1/5] dt: unittest: early return from test skips tests

2015-03-13 Thread Frank Rowand
From: Frank Rowand 

Fix bugs pointed out by checkpatch.

Mis-coding of two if statements caused early return from function.

Number of tests completed increased from 102 to 107.
Number of tests failed increased from 0 to 2.

Signed-off-by: Frank Rowand 
---
 drivers/of/unittest.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

Index: b/drivers/of/unittest.c
===
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -762,12 +762,14 @@ static void __init of_selftest_platform_
irq = platform_get_irq(pdev, 0);
selftest(irq < 0 && irq != -EPROBE_DEFER, "device parsing error failed 
- %d\n", irq);
 
-   if (selftest(np = of_find_node_by_path("/testcase-data/platform-tests"),
-"No testcase data in device tree\n"));
+   np = of_find_node_by_path("/testcase-data/platform-tests");
+   selftest(np, "No testcase data in device tree\n");
+   if (!np)
return;
 
-   if (selftest(!(rc = device_register(&test_bus)),
-"testbus registration failed; rc=%i\n", rc));
+   rc = device_register(&test_bus);
+   selftest(!rc, "testbus registration failed; rc=%i\n", rc);
+   if (rc)
return;
 
for_each_child_of_node(np, child) {
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Patch 0/5] dt: unittest: fix breakage and warnings

2015-03-13 Thread Frank Rowand
Running checkpatch on early versions of my patchset to fix the devicetree
make dependency issues exposed a large number of warnings, including some that
are actual bugs.  http://lkml.iu.edu/hypermail/linux/kernel/1503.1/03335.html

These patches fix those bugs, and another bug exposed by fixing those bugs.
As a result, the number of tests completed increased from 102 to 107.

Since I was already poking around, I fixed a few classes of checkpatch warnings.

There are still plenty of warnings, but the noise is greatly reduced and future
checkpatch warnings that are problems should stand out more clearly.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

2015-03-13 Thread Alexandru M Stan
This block should not be enabled by default or else if the kconfig is set,
it will try to load/probe even if there's no phy connected.

Signed-off-by: Alexandru M Stan 
---
 arch/arm/boot/dts/rk3288.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index d771f68..eccc78d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -411,6 +411,7 @@
"mac_clk_rx", "mac_clk_tx",
"clk_mac_ref", "clk_mac_refout",
"aclk_mac", "pclk_mac";
+   status = "disabled";
};
 
usb_host0_ehci: usb@ff50 {
-- 
2.2.0.rc0.207.ga3a616c

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


[PATCH 0/1] ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

2015-03-13 Thread Alexandru M Stan
The way it is right now, each board using rk3288.dtsi has to disable
it or else (given CONFIG_DWMAC_RK is set) it will try loading the driver
and looking for phy's even though none are connected.

The status should be "disabled".

PS: I'm ok with "the big relicensing"
(http://www.spinics.net/lists/arm-kernel/msg403629.html) to GPLv2/X11.


Alexandru M Stan (1):
  ARM: dts: rockchip: disable gmac by default in rk3288.dtsi

 arch/arm/boot/dts/rk3288.dtsi | 1 +
 1 file changed, 1 insertion(+)

-- 
2.2.0.rc0.207.ga3a616c

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


Re: [RFC 14/18] dt: bindings: Add bindings for omap3isp

2015-03-13 Thread Laurent Pinchart
Hi Sebastian,

Thank you for the review.

On Friday 13 March 2015 10:34:53 Sebastian Reichel wrote:
> On Fri, Mar 13, 2015 at 01:03:21AM +0200, Sakari Ailus wrote:
> > [...]
> > 
> > > > +Required properties
> > > > +===
> > > > +
> > > > +compatible : "ti,omap3-isp"
> > > 
> > > I would rephrase that using the usual wording as "compatible: Must
> > > contain
> > > "ti,omap3-isp".
> > 
> > [...]
> > 
> > > > +ti,phy-type: 0 -- 3430; 1 -- 3630
> > > 
> > > Would it make sense to add #define's for this ?
> > 
> > I'll use OMAP3ISP_PHY_TYPE_COMPLEX_IO and OMAP3ISP_PHY_TYPE_CSIPHY as
> > discussed.
> > 
> > > It could also make sense to document/name them "Complex I/O" and
> > > "CSIPHY" to avoid referring to the SoC that implements them, as the ISP
> > > is also found in SoCs other than 3430 and 3630.
> > > 
> > > Could the PHY type be derived from the ES revision that we query at
> > > runtime ?
> >
> > I think this would work on 3430 and 3630 but I'm not certain about others.
> > 
> > > We should also take into account the fact that the DM3730 has officially
> > > no CSIPHY, but still seems to implement them in practice.
> > 
> > The DT sources are for 36xx, but I'd guess it works on 37xx as well,
> > doesn't it?
> 
> In other drivers this kind of information is often extracted from the
> compatible string. For example:
> 
> { .compatible = "ti,omap34xx-isp", .data = OMAP3ISP_PHY_TYPE_COMPLEX_IO, },
> { .compatible = "ti,omap36xx-isp", .data = OMAP3ISP_PHY_TYPE_CSIPHY, },
> ...

That's an option too, which I've discussed with Sakari before. The reason why 
we have decided to go for a separate property is that the PHY type seems to be 
more an SoC integration property than an ISP model property. I'm open to 
reconsidering that though.

Another option that has been discussed was to infer the PHY type from the ISP 
revision number queried at runtime. That would be fine for the 3430, 3630 and 
3730, but it remains unclear at this point whether this scheme would work with 
other SoCs. It should also be noted that some OMAP3-based SoCs that 
incorporate the ISP officially don't include the CSI PHYs, but seem to have 
them in practice.

> > [...]
> > 
> > > > +Example
> > > > +===
> > > > +
> > > > +   omap3_isp: omap3_isp@480bc000 {
> > > 
> > > DT node names traditionally use - as a separator. Furthermore the
> > > phandle isn't needed. This should thus probably be
> > > 
> > >   omap3-isp@480bc000 {
> > 
> > Fixed.
> 
> According to ePAPR this should be a generic name (page 19); For
> example the i2c node name should be "i2c@address" instead of
> "omap3-i2c@address". There is no recommended generic term for an
> image signal processor, "isp" looks ok to me and seems to be
> already used in NVIDIA Tegra's device tree files. So maybe:
> 
> isp@480bc000 {

"isp" sounds good to me.

-- 
Regards,

Laurent Pinchart

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


Re: [PATCH v2 2/2] v4l: mt9v032: Add OF support

2015-03-13 Thread Laurent Pinchart
Hi Prabhakar,

On Friday 13 March 2015 05:43:42 Lad, Prabhakar wrote:
> On Fri, Mar 13, 2015 at 12:03 AM, Laurent Pinchart wrote:
> > Parse DT properties into a platform data structure when a DT node is
> > available.
> > 
> > Signed-off-by: Laurent Pinchart 
> > 
> > ---
> 
> [snip]
> 
> > +static struct mt9v032_platform_data *
> > +mt9v032_get_pdata(struct i2c_client *client)
> > +{
> > +   struct mt9v032_platform_data *pdata;
> > +   struct v4l2_of_endpoint endpoint;
> > +   struct device_node *np;
> > +   struct property *prop;
> > +
> > +   if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> > +   return client->dev.platform_data;
> > +
> > +   np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
> > +   if (!np)
> > +   return NULL;
> > +
> > +   if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
> > +   goto done;
> > +
> 
> with the above two statements it seems its based on older version of kernel.

You're absolutely right, I've sent the wrong version of the patch, sorry about 
that.

I'll fix the v4l2_of_get_next_endpoint() call in v3. Is there anything wrong 
with v4l2_of_parse_endpoint() though ?

-- 
Regards,

Laurent Pinchart

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


[PATCH V2 1/5] MIPS: Create a common

2015-03-13 Thread Andrew Bresticker
From: Kevin Cernekee 

11 platforms require at least one of these workarounds to be enabled; 22
platforms do not.  In the latter case we can fall back to a generic version.

Note that this also deletes an orphaned reference to RM9000_CDEX_SMP_WAR.

Suggested-by: Arnd Bergmann 
Signed-off-by: Kevin Cernekee 
Signed-off-by: Andrew Bresticker 
---
No changes from v1.
Changes from Kevin's v6:
 - Left cavium-octeon's war.h in-tact
---
 arch/mips/include/asm/mach-ar7/war.h   | 24 
 arch/mips/include/asm/mach-ath25/war.h | 25 -
 arch/mips/include/asm/mach-ath79/war.h | 24 
 arch/mips/include/asm/mach-au1x00/war.h| 24 
 arch/mips/include/asm/mach-bcm3384/war.h   | 24 
 arch/mips/include/asm/mach-bcm47xx/war.h   | 24 
 arch/mips/include/asm/mach-bcm63xx/war.h   | 24 
 arch/mips/include/asm/mach-cobalt/war.h| 24 
 arch/mips/include/asm/mach-dec/war.h   | 24 
 arch/mips/include/asm/mach-emma2rh/war.h   | 24 
 arch/mips/include/asm/mach-generic/war.h   | 24 
 arch/mips/include/asm/mach-jazz/war.h  | 24 
 arch/mips/include/asm/mach-jz4740/war.h| 24 
 arch/mips/include/asm/mach-lantiq/war.h| 23 ---
 arch/mips/include/asm/mach-lasat/war.h | 24 
 arch/mips/include/asm/mach-loongson/war.h  | 24 
 arch/mips/include/asm/mach-loongson1/war.h | 24 
 arch/mips/include/asm/mach-netlogic/war.h  | 25 -
 arch/mips/include/asm/mach-paravirt/war.h  | 25 -
 arch/mips/include/asm/mach-pnx833x/war.h   | 24 
 arch/mips/include/asm/mach-ralink/war.h| 24 
 arch/mips/include/asm/mach-tx39xx/war.h| 24 
 arch/mips/include/asm/mach-vr41xx/war.h| 24 
 23 files changed, 24 insertions(+), 530 deletions(-)
 delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
 delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
 delete mode 100644 arch/mips/include/asm/mach-dec/war.h
 delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
 create mode 100644 arch/mips/include/asm/mach-generic/war.h
 delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
 delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
 delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
 delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
 delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
 delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h
 delete mode 100644 arch/mips/include/asm/mach-pnx833x/war.h
 delete mode 100644 arch/mips/include/asm/mach-ralink/war.h
 delete mode 100644 arch/mips/include/asm/mach-tx39xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-vr41xx/war.h

diff --git a/arch/mips/include/asm/mach-ar7/war.h 
b/arch/mips/include/asm/mach-ar7/war.h
deleted file mode 100644
index 99071e5..000
--- a/arch/mips/include/asm/mach-ar7/war.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 2002, 2004, 2007 by Ralf Baechle 
- */
-#ifndef __ASM_MIPS_MACH_AR7_WAR_H
-#define __ASM_MIPS_MACH_AR7_WAR_H
-
-#define R4600_V1_INDEX_ICACHEOP_WAR0
-#define R4600_V1_HIT_CACHEOP_WAR   0
-#define R4600_V2_HIT_CACHEOP_WAR   0
-#define R5432_CP0_INTERRUPT_WAR0
-#define BCM1250_M3_WAR 0
-#define SIBYTE_1956_WAR0
-#define MIPS4K_ICACHE_REFILL_WAR   0
-#define MIPS_CACHE_SYNC_WAR0
-#define TX49XX_ICACHE_INDEX_INV_WAR0
-#define ICACHE_REFILLS_WORKAROUND_WAR  0
-#define R1_LLSC_WAR0
-#define MIPS34K_MISSED_ITLB_WAR0
-
-#endif /* __ASM_MIPS_MACH_AR7_WAR_H */
diff --git a/arch/mips/include/asm/mach-ath25/war.h 
b/arch/mips/include/asm/mach-ath25/war.h
deleted file mode 100644
index e3a5250..000
--- a/arch/mips/include/asm/mach-ath25/war.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License.  See 

[PATCH V2 4/5] MIPS: Add support for the IMG Pistachio SoC

2015-03-13 Thread Andrew Bresticker
Add initial support for boards based on the Imagination Pistachio SoC.
Pistachio is based on a dual-core MIPS interAptiv CPU and will boot
using device-tree.

Signed-off-by: James Hartley 
Signed-off-by: Andrew Bresticker 
---
Changes from v1:
 - switched to MIPS UHI hand-off protocol
---
 arch/mips/Kbuild.platforms  |   1 +
 arch/mips/Kconfig   |  27 ++
 arch/mips/include/asm/mach-pistachio/gpio.h |  21 +
 arch/mips/include/asm/mach-pistachio/irq.h  |  18 
 arch/mips/pistachio/Makefile|   1 +
 arch/mips/pistachio/Platform|   8 ++
 arch/mips/pistachio/init.c  | 131 
 arch/mips/pistachio/irq.c   |  28 ++
 arch/mips/pistachio/time.c  |  52 +++
 9 files changed, 287 insertions(+)
 create mode 100644 arch/mips/include/asm/mach-pistachio/gpio.h
 create mode 100644 arch/mips/include/asm/mach-pistachio/irq.h
 create mode 100644 arch/mips/pistachio/Makefile
 create mode 100644 arch/mips/pistachio/Platform
 create mode 100644 arch/mips/pistachio/init.c
 create mode 100644 arch/mips/pistachio/irq.c
 create mode 100644 arch/mips/pistachio/time.c

diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index e5fc463..2298baa 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -23,6 +23,7 @@ platforms += netlogic
 platforms += paravirt
 platforms += pmcs-msp71xx
 platforms += pnx833x
+platforms += pistachio
 platforms += ralink
 platforms += rb532
 platforms += sgi-ip22
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c7a1690..343b238 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -352,6 +352,33 @@ config MACH_LOONGSON1
  the ICT (Institute of Computing Technology) and the Chinese Academy
  of Sciences.
 
+config MACH_PISTACHIO
+   bool "IMG Pistachio SoC based boards"
+   select ARCH_REQUIRE_GPIOLIB
+   select BOOT_ELF32
+   select BOOT_RAW
+   select CEVT_R4K
+   select CLKSRC_MIPS_GIC
+   select COMMON_CLK
+   select CSRC_R4K
+   select DMA_MAYBE_COHERENT
+   select IRQ_CPU
+   select LIBFDT
+   select MFD_SYSCON
+   select MIPS_CPU_SCACHE
+   select MIPS_GIC
+   select PINCTRL
+   select REGULATOR
+   select SYS_HAS_CPU_MIPS32_R2
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_SUPPORTS_LITTLE_ENDIAN
+   select SYS_SUPPORTS_MIPS_CPS
+   select SYS_SUPPORTS_MULTITHREADING
+   select SYS_SUPPORTS_ZBOOT
+   select USE_OF
+   help
+ This enables support for the IMG Pistachio SoC platform.
+
 config MIPS_MALTA
bool "MIPS Malta board"
select ARCH_MAY_HAVE_PC_FDC
diff --git a/arch/mips/include/asm/mach-pistachio/gpio.h 
b/arch/mips/include/asm/mach-pistachio/gpio.h
new file mode 100644
index 000..6c1649c
--- /dev/null
+++ b/arch/mips/include/asm/mach-pistachio/gpio.h
@@ -0,0 +1,21 @@
+/*
+ * Pistachio IRQ setup
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MACH_PISTACHIO_GPIO_H
+#define __ASM_MACH_PISTACHIO_GPIO_H
+
+#include 
+
+#define gpio_get_value __gpio_get_value
+#define gpio_set_value __gpio_set_value
+#define gpio_cansleep  __gpio_cansleep
+#define gpio_to_irq__gpio_to_irq
+
+#endif /* __ASM_MACH_PISTACHIO_GPIO_H */
diff --git a/arch/mips/include/asm/mach-pistachio/irq.h 
b/arch/mips/include/asm/mach-pistachio/irq.h
new file mode 100644
index 000..b94a09a
--- /dev/null
+++ b/arch/mips/include/asm/mach-pistachio/irq.h
@@ -0,0 +1,18 @@
+/*
+ * Pistachio IRQ setup
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef __ASM_MACH_PISTACHIO_IRQ_H
+#define __ASM_MACH_PISTACHIO_IRQ_H
+
+#define NR_IRQS 256
+
+#include_next 
+
+#endif /* __ASM_MACH_PISTACHIO_IRQ_H */
diff --git a/arch/mips/pistachio/Makefile b/arch/mips/pistachio/Makefile
new file mode 100644
index 000..32189c6
--- /dev/null
+++ b/arch/mips/pistachio/Makefile
@@ -0,0 +1 @@
+obj-y  += init.o irq.o time.o
diff --git a/arch/mips/pistachio/Platform b/arch/mips/pistachio/Platform
new file mode 100644
index 000..d80cd61
--- /dev/null
+++ b/arch/mips/pistachio/Platform
@@ -0,0 +1,8 @@
+#
+# IMG Pistachio SoC
+#
+platform-$(CONFIG_MACH_PISTACHIO)  += pistachio/
+cflags-$(CONFIG_MACH_PISTACHIO)+=  
\
+   -I$(srctree)/arch/mips/include/asm/mach-pistachio
+load-$(CONFIG_MACH_PISTACHIO)  += 0x8040
+zload-$(CONFIG_MACH_PISTACHIO) += 0x8100
diff --git a/arch/m

[PATCH V2 2/5] MIPS: Allow platforms to specify the decompressor load address

2015-03-13 Thread Andrew Bresticker
Platforms which use raw zboot images may need to link the image at
a fixed address if there is no other way to communicate the load
address to the bootloader.  Allow the per-platform Kbuild files
to specify an optional zboot image load address (zload-y) and fall
back to calc_vmlinuz_load_addr if unset.

Signed-off-by: Andrew Bresticker 
Cc: Lars-Peter Clausen 
---
No changes from v1.
---
 arch/mips/boot/compressed/Makefile | 6 --
 arch/mips/jz4740/Platform  | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/mips/boot/compressed/Makefile 
b/arch/mips/boot/compressed/Makefile
index 61af6b6..82d0b13 100644
--- a/arch/mips/boot/compressed/Makefile
+++ b/arch/mips/boot/compressed/Makefile
@@ -12,6 +12,8 @@
 # Author: Wu Zhangjin 
 #
 
+include $(srctree)/arch/mips/Kbuild.platforms
+
 # set the default size of the mallocing area for decompressing
 BOOT_HEAP_SIZE := 0x40
 
@@ -66,8 +68,8 @@ $(obj)/piggy.o: $(obj)/dummy.o $(obj)/vmlinux.bin.z FORCE
 # Calculate the load address of the compressed kernel image
 hostprogs-y := calc_vmlinuz_load_addr
 
-ifeq ($(CONFIG_MACH_JZ4740),y)
-VMLINUZ_LOAD_ADDRESS := 0x8060
+ifneq ($(zload-y),)
+VMLINUZ_LOAD_ADDRESS := $(zload-y)
 else
 VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \
$(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS))
diff --git a/arch/mips/jz4740/Platform b/arch/mips/jz4740/Platform
index ba91be9..c41d300 100644
--- a/arch/mips/jz4740/Platform
+++ b/arch/mips/jz4740/Platform
@@ -1,3 +1,4 @@
 platform-$(CONFIG_MACH_JZ4740) += jz4740/
 cflags-$(CONFIG_MACH_JZ4740)   += 
-I$(srctree)/arch/mips/include/asm/mach-jz4740
 load-$(CONFIG_MACH_JZ4740) += 0x8001
+zload-$(CONFIG_MACH_JZ4740)+= 0x8060
-- 
2.2.0.rc0.207.ga3a616c

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


[PATCH V2 0/5] MIPS: Initial IMG Pistachio SoC support

2015-03-13 Thread Andrew Bresticker
This series adds basic support for the Imagination Technologies Pistachio
SoC.  Pistachio will boot using device-tree only.  v4.0-rc1 already includes
support for several of the peripherals on Pistachio, including MMC, SPI,
I2C, DMA, watchdog timer, PWM, and IR.  Clock and pinctrl support for
Pistachio is coming soon, as well as an initial device-tree and support
for USB and ethernet.

Patches 1 and 2 are cleanups in preparation for adding Pistachio support,
with patch 1 having been posted by Kevin late last year [1].  Patch 3
documents Pistachio's required device-tree properties/nodes and its boot
protocol.  Patch 4 adds support for Pistachio itself and finally patch 5
adds a defconfig for Pistachio.

Boot tested on an IMG Pistachio BuB ("bring-up board") and build tested
for all other affected platforms.  Based on v4.0-rc3.  A tree with these
changes is available at [2].

Changes from v1:
 - Switched to MIPS UHI hand-off protocol

Cc: Ezequiel Garcia 
Cc: James Hartley 
Cc: James Hogan 

[1] http://patchwork.linux-mips.org/patch/8837/
[2] https://github.com/abrestic/linux/tree/pistachio-platform-v2

Andrew Bresticker (3):
  MIPS: Allow platforms to specify the decompressor load address
  MIPS: Document Pistachio boot protocol and device-tree bindings
  MIPS: Add support for the IMG Pistachio SoC

Govindraj Raja (1):
  MIPS: pistachio: Add an initial defconfig

Kevin Cernekee (1):
  MIPS: Create a common 

 .../devicetree/bindings/mips/img/pistachio.txt |  42 +++
 arch/mips/Kbuild.platforms |   1 +
 arch/mips/Kconfig  |  27 ++
 arch/mips/boot/compressed/Makefile |   6 +-
 arch/mips/configs/pistachio_defconfig  | 336 +
 arch/mips/include/asm/mach-ar7/war.h   |  24 --
 arch/mips/include/asm/mach-ath25/war.h |  25 --
 arch/mips/include/asm/mach-ath79/war.h |  24 --
 arch/mips/include/asm/mach-au1x00/war.h|  24 --
 arch/mips/include/asm/mach-bcm3384/war.h   |  24 --
 arch/mips/include/asm/mach-bcm47xx/war.h   |  24 --
 arch/mips/include/asm/mach-bcm63xx/war.h   |  24 --
 arch/mips/include/asm/mach-cobalt/war.h|  24 --
 arch/mips/include/asm/mach-dec/war.h   |  24 --
 arch/mips/include/asm/mach-emma2rh/war.h   |  24 --
 arch/mips/include/asm/mach-generic/war.h   |  24 ++
 arch/mips/include/asm/mach-jazz/war.h  |  24 --
 arch/mips/include/asm/mach-jz4740/war.h|  24 --
 arch/mips/include/asm/mach-lantiq/war.h|  23 --
 arch/mips/include/asm/mach-lasat/war.h |  24 --
 arch/mips/include/asm/mach-loongson/war.h  |  24 --
 arch/mips/include/asm/mach-loongson1/war.h |  24 --
 arch/mips/include/asm/mach-netlogic/war.h  |  25 --
 arch/mips/include/asm/mach-paravirt/war.h  |  25 --
 arch/mips/include/asm/mach-pistachio/gpio.h|  21 ++
 arch/mips/include/asm/mach-pistachio/irq.h |  18 ++
 arch/mips/include/asm/mach-pnx833x/war.h   |  24 --
 arch/mips/include/asm/mach-ralink/war.h|  24 --
 arch/mips/include/asm/mach-tx39xx/war.h|  24 --
 arch/mips/include/asm/mach-vr41xx/war.h|  24 --
 arch/mips/jz4740/Platform  |   1 +
 arch/mips/pistachio/Makefile   |   1 +
 arch/mips/pistachio/Platform   |   8 +
 arch/mips/pistachio/init.c | 131 
 arch/mips/pistachio/irq.c  |  28 ++
 arch/mips/pistachio/time.c |  52 
 36 files changed, 694 insertions(+), 532 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mips/img/pistachio.txt
 create mode 100644 arch/mips/configs/pistachio_defconfig
 delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
 delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
 delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
 delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
 delete mode 100644 arch/mips/include/asm/mach-dec/war.h
 delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
 create mode 100644 arch/mips/include/asm/mach-generic/war.h
 delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
 delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
 delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
 delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
 delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
 delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
 delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h
 create mode 10

[PATCH V2 3/5] MIPS: Document Pistachio boot protocol and device-tree bindings

2015-03-13 Thread Andrew Bresticker
The Pistachio SoC boots only with device-tree.  Document the required
properties and nodes as well as the boot protocol between the bootlaoder
and the kernel.

Signed-off-by: Andrew Bresticker 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
---
Changes from v1:
 - switched to MIPS UHI hand-off protocol
---
 .../devicetree/bindings/mips/img/pistachio.txt | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/img/pistachio.txt

diff --git a/Documentation/devicetree/bindings/mips/img/pistachio.txt 
b/Documentation/devicetree/bindings/mips/img/pistachio.txt
new file mode 100644
index 000..a736d88
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/img/pistachio.txt
@@ -0,0 +1,42 @@
+Imagination Pistachio SoC
+=
+
+Required properties:
+
+ - compatible: Must include "img,pistachio".
+
+CPU nodes:
+--
+A "cpus" node is required.  Required properties:
+ - #address-cells: Must be 1.
+ - #size-cells: Must be 0.
+A CPU sub-node is also required for at least CPU 0.  Since the topology may
+be probed via CPS, it is not necessary to specify secondary CPUs.  Required
+propertis:
+ - device_type: Must be "cpu".
+ - compatible: Must be "mti,interaptiv".
+ - reg: CPU number.
+ - clocks: Must include the CPU clock.  See ../../clock/clock-bindings.txt for
+   details on clock bindings.
+Example:
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: cpu@0 {
+   device_type = "cpu";
+   compatible = "mti,interaptiv";
+   reg = <0>;
+   clocks = <&clk_core CLK_MIPS>;
+   };
+   };
+
+
+Boot protocol:
+--
+In accordance with the MIPS UHI specification[1], the bootloader must pass the
+following arguments to the kernel:
+ - $a0: -2.
+ - $a1: KSEG0 address of the flattened device-tree blob.
+
+[1] http://prplfoundation.org/wiki/MIPS_documentation
-- 
2.2.0.rc0.207.ga3a616c

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


[PATCH V2 5/5] MIPS: pistachio: Add an initial defconfig

2015-03-13 Thread Andrew Bresticker
From: Govindraj Raja 

Add a defconfig for Pistachio which enables drivers for all the
currently supported peripherals on the SoC.

Signed-off-by: Govindraj Raja 
Signed-off-by: Andrew Bresticker 
---
No changes from v1.
---
 arch/mips/configs/pistachio_defconfig | 336 ++
 1 file changed, 336 insertions(+)
 create mode 100644 arch/mips/configs/pistachio_defconfig

diff --git a/arch/mips/configs/pistachio_defconfig 
b/arch/mips/configs/pistachio_defconfig
new file mode 100644
index 000..f22e92e
--- /dev/null
+++ b/arch/mips/configs/pistachio_defconfig
@@ -0,0 +1,336 @@
+CONFIG_MACH_PISTACHIO=y
+CONFIG_MIPS_MT_SMP=y
+CONFIG_MIPS_CPS=y
+# CONFIG_COMPACTION is not set
+CONFIG_DEFAULT_MMAP_MIN_ADDR=32768
+CONFIG_ZSMALLOC=y
+CONFIG_NR_CPUS=4
+CONFIG_PREEMPT_VOLUNTARY=y
+# CONFIG_LOCALVERSION_AUTO is not set
+CONFIG_DEFAULT_HOSTNAME="localhost"
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_IKCONFIG=m
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=18
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_CFS_BANDWIDTH=y
+CONFIG_NAMESPACES=y
+CONFIG_USER_NS=y
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+CONFIG_EMBEDDED=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_PROFILING=y
+CONFIG_CC_STACKPROTECTOR_STRONG=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_PM_DEBUG=y
+CONFIG_PM_ADVANCED_DEBUG=y
+CONFIG_CPU_IDLE=y
+# CONFIG_MIPS_CPS_CPUIDLE is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_NET_KEY=m
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+CONFIG_SYN_COOKIES=y
+CONFIG_INET_AH=m
+CONFIG_INET_ESP=m
+CONFIG_INET_IPCOMP=m
+CONFIG_INET_XFRM_MODE_TRANSPORT=m
+CONFIG_INET_XFRM_MODE_TUNNEL=m
+CONFIG_INET_XFRM_MODE_BEET=m
+# CONFIG_INET_DIAG is not set
+CONFIG_TCP_CONG_ADVANCED=y
+# CONFIG_TCP_CONG_BIC is not set
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+CONFIG_TCP_CONG_LP=m
+CONFIG_TCP_MD5SIG=y
+CONFIG_IPV6=y
+CONFIG_INET6_AH=m
+CONFIG_INET6_ESP=m
+CONFIG_INET6_XFRM_MODE_TRANSPORT=m
+CONFIG_INET6_XFRM_MODE_TUNNEL=m
+CONFIG_INET6_XFRM_MODE_BEET=m
+CONFIG_IPV6_SIT=m
+CONFIG_NETWORK_SECMARK=y
+CONFIG_NETFILTER=y
+# CONFIG_BRIDGE_NETFILTER is not set
+CONFIG_NF_CONNTRACK=y
+CONFIG_NF_CT_NETLINK=y
+CONFIG_NETFILTER_XT_MARK=m
+CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
+CONFIG_NETFILTER_XT_TARGET_DSCP=y
+CONFIG_NETFILTER_XT_TARGET_NFLOG=y
+CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
+CONFIG_NETFILTER_XT_TARGET_SECMARK=y
+CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
+CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
+CONFIG_NETFILTER_XT_MATCH_DSCP=y
+CONFIG_NETFILTER_XT_MATCH_POLICY=y
+CONFIG_NETFILTER_XT_MATCH_STATE=y
+CONFIG_NF_CONNTRACK_IPV4=y
+CONFIG_NF_NAT_IPV4=m
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_IP_NF_FILTER=y
+CONFIG_IP_NF_TARGET_REJECT=y
+CONFIG_IP_NF_MANGLE=y
+CONFIG_NF_CONNTRACK_IPV6=m
+CONFIG_NF_NAT_IPV6=m
+CONFIG_IP6_NF_IPTABLES=m
+CONFIG_IP6_NF_MATCH_IPV6HEADER=m
+CONFIG_IP6_NF_FILTER=m
+CONFIG_IP6_NF_TARGET_REJECT=m
+CONFIG_IP6_NF_MANGLE=m
+CONFIG_BRIDGE=m
+CONFIG_VLAN_8021Q=m
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_HTB=m
+CONFIG_NET_SCH_CODEL=m
+CONFIG_NET_SCH_FQ_CODEL=m
+CONFIG_NET_CLS_U32=m
+CONFIG_CLS_U32_MARK=y
+CONFIG_BT=m
+CONFIG_BT_RFCOMM=m
+CONFIG_BT_HCIBTUSB=m
+CONFIG_BT_HCIBFUSB=m
+CONFIG_BT_HCIVHCI=m
+CONFIG_CFG80211=m
+CONFIG_NL80211_TESTMODE=y
+CONFIG_CFG80211_DEBUGFS=y
+CONFIG_CFG80211_WEXT=y
+CONFIG_MAC80211=m
+CONFIG_MAC80211_LEDS=y
+CONFIG_MAC80211_DEBUGFS=y
+CONFIG_MAC80211_DEBUG_MENU=y
+CONFIG_MAC80211_VERBOSE_DEBUG=y
+CONFIG_RFKILL=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+CONFIG_DEBUG_DEVRES=y
+CONFIG_CONNECTOR=y
+CONFIG_MTD=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_M25P80=y
+CONFIG_MTD_SPI_NOR=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_BLOCK=y
+CONFIG_ZRAM=m
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_BLK_DEV_SR=m
+CONFIG_SCSI_SPI_ATTRS=y
+CONFIG_MD=y
+CONFIG_BLK_DEV_DM=y
+CONFIG_DM_CRYPT=y
+CONFIG_DM_VERITY=y
+CONFIG_NETDEVICES=y
+CONFIG_TUN=m
+CONFIG_VETH=m
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_MICROCHIP is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+CONFIG_STMMAC_ETH=y
+# CONFIG_NET_VENDOR_VIA is not set
+CONFIG_PPP=m
+CONFIG_PPP_ASYNC=m
+CONFIG_USB_PEGASUS=m
+CONFIG_USB_RTL8150=m
+CONFIG_USB_RTL8152=m
+CONFIG_USB_NET_DM9601=m
+CONFIG_USB_NET_SMSC75XX=m
+CONFIG_USB_NET_SMSC95XX=m
+CONFIG_USB_NET_MCS7830=m
+# CONFIG_USB_NET_CDC_SUBSET is not set
+# CONFIG_USB_NET_ZAURUS is not set
+CONFIG_LIBERTAS_THINFIRM=m
+CONFIG_USB_NET_RNDIS_WLAN=m
+CONFIG_MAC80211_HWSIM=m
+CONFIG_HOSTAP=m
+CONFIG_HOSTAP_FIRMWARE=y

Re: [Patch v4 2/2] dmaengine: Add ADM driver

2015-03-13 Thread Andy Gross
On Fri, Mar 13, 2015 at 02:27:45PM +0530, Vinod Koul wrote:
> On Wed, Feb 11, 2015 at 11:46:05PM -0600, Andy Gross wrote:
> > +++ b/drivers/dma/qcom_adm.c
> > @@ -0,0 +1,901 @@
> > +/*
> > + * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> shouldn't this be 15 :)

yeah, need to update.

> 
>  +/* ADM registers - calculated from channel number and security domain */
> > +#define HI_CH_CMD_PTR(chan, ee)(4*chan + 0x20800*ee)
> > +#define HI_CH_RSLT(chan, ee)   (0x40 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE0(chan, ee)   (0x80 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE1(chan, ee)   (0xc0 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE2(chan, ee)   (0x100 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE3(chan, ee)   (0x140 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE4(chan, ee)   (0x180 + 4*chan + 0x20800*ee)
> > +#define HI_CH_FLUSH_STATE5(chan, ee)   (0x1c0 + 4*chan + 0x20800*ee)
> > +#define HI_CH_STATUS_SD(chan, ee)  (0x200 + 4*chan + 0x20800*ee)
> > +#define HI_CH_CONF(chan)   (0x240 + 4*chan)
> > +#define HI_CH_RSLT_CONF(chan, ee)  (0x300 + 4*chan + 0x20800*ee)
> > +#define HI_SEC_DOMAIN_IRQ_STATUS(ee)   (0x380 + 0x20800*ee)
> > +#define HI_CI_CONF(ci) (0x390 + 4*ci)
> > +#define HI_CRCI_CONF0  0x3d0
> > +#define HI_CRCI_CONF1  0x3d4
> > +#define HI_GP_CTL  0x3d8
> > +#define HI_CRCI_CTL(crci, ee)  (0x400 + 0x4*crci + 0x20800*ee)
> two things, one the names are quite generic and may cause conflicts so pls
> fix that. Second the values, what is the deal with 4*chan, should that be a
> define as well. Also rather than copy pasting a macros would be better for
> this expansion

Yeah there are sets of registers that have both channel and execution
environment offsets.  It is messy.  I'll try to make it more sane.

> 
> > +
> > +/* channel status */
> > +#define CH_STATUS_VALIDBIT(1)
> > +
> > +/* channel result */
> > +#define CH_RSLT_VALID  BIT(31)
> > +#define CH_RSLT_ERRBIT(3)
> > +#define CH_RSLT_FLUSH  BIT(2)
> > +#define CH_RSLT_TPDBIT(1)
> > +
> > +/* channel conf */
> > +#define CH_CONF_MPU_DISABLEBIT(11)
> > +#define CH_CONF_PERM_MPU_CONF  BIT(9)
> > +#define CH_CONF_FLUSH_RSLT_EN  BIT(8)
> > +#define CH_CONF_FORCE_RSLT_EN  BIT(7)
> > +#define CH_CONF_IRQ_EN BIT(6)
> > +
> > +/* channel result conf */
> > +#define CH_RSLT_CONF_FLUSH_EN  BIT(1)
> > +#define CH_RSLT_CONF_IRQ_ENBIT(0)
> > +
> > +/* CRCI CTL */
> > +#define CRCI_CTL_MUX_SEL   BIT(18)
> > +#define CRCI_CTL_RST   BIT(17)
> > +
> > +/* CI configuration */
> > +#define CI_RANGE_END(x)(x << 24)
> > +#define CI_RANGE_START(x)  (x << 16)
> > +#define CI_BURST_4_WORDS   0x4
> > +#define CI_BURST_8_WORDS   0x8
> shouldn't you be consistent is usage of BIT()

good catch

> > +
> > +/* GP CTL */
> > +#define GP_CTL_LP_EN   BIT(12)
> > +#define GP_CTL_LP_CNT(x)   (x << 8)
> > +
> > +/* Command pointer list entry */
> > +#define CPLE_LPBIT(31)
> > +#define CPLE_CMD_PTR_LIST  BIT(29)
> > +
> > +/* Command list entry */
> > +#define CMD_LC BIT(31)
> > +#define CMD_DST_CRCI(n)(((n) & 0xf) << 7)
> > +#define CMD_SRC_CRCI(n)(((n) & 0xf) << 3)
> > +
> > +#define CMD_TYPE_SINGLE0x0
> > +#define CMD_TYPE_BOX   0x3a
> naming issues...

ok. will try to come up with something better

> > +static int adm_alloc_chan(struct dma_chan *chan)
> > +{
> > +   return 0;
> > +}
> This is no longer mandatory, so can be dropped

will remove

> 
> > +static int adm_get_blksize(unsigned int burst)
> > +{
> > +   int ret;
> > +
> > +   switch (burst) {
> > +   case 16:
> > +   ret = 0;
> > +   break;
> > +   case 32:
> > +   ret = 1;
> > +   break;
> > +   case 64:
> > +   ret = 2;
> > +   break;
> > +   case 128:
> > +   ret = 3;
> > +   break;
> > +   case 192:
> > +   ret = 4;
> > +   break;
> > +   case 256:
> > +   ret = 5;
> > +   break;
> ffs(burst>>4) ?

that should work nicely.  thanks.

> > +static struct dma_async_tx_descriptor *adm_prep_slave_sg(struct dma_chan 
> > *chan,
> > +   struct scatterlist *sgl, unsigned int sg_len,
> > +   enum dma_transfer_direction direction, unsigned long flags,
> > +   void *context)
> > +{
> > +   struct adm_chan *achan = to_adm_chan(chan);
> > +   struct adm_device *adev = achan->adev;
> > +   struct adm_async_desc *async_desc;
> > +   struct scatterlist *sg;
> > +   u32 i;
> > +   u32 single_count = 0, box_count = 0, desc_offset = 0, crci = 0;
> > +   struct adm_desc_hw_box *box_desc;
> > +   struct adm_desc_hw_single *single_desc;
> > +   void *desc;
> > +   u32 *cple, *last_cmd;
> > +   u32 burst;
> > +   int blk_size = 0;
> > +
> 

Re: [PATCH 0/6] ARM: cpuidle: Unify the ARM64/ARM DT approach

2015-03-13 Thread Daniel Lezcano

On 03/13/2015 09:51 PM, Rob Herring wrote:

On Thu, Mar 12, 2015 at 9:25 AM, Daniel Lezcano
 wrote:


Catalin, Rob,

do you agree with this patchset ?


There's very little to do with DT, but looks fine to me.


Shall I consider as a acked-by for the entire patchset or only the DT part ?

Thanks for taking the time to look at the patches.

  -- Daniel

--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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


Re: [PATCH 0/6] ARM: cpuidle: Unify the ARM64/ARM DT approach

2015-03-13 Thread Daniel Lezcano

On 03/13/2015 07:29 PM, Catalin Marinas wrote:

On Thu, Mar 12, 2015 at 03:25:34PM +0100, Daniel Lezcano wrote:

do you agree with this patchset ?


In principle yes, apart from some function naming and I'm waiting for
Lorenzo's ack as well. Do you plan to upstream this directly via your
tree? If yes, I'll look in more detail and give some acks.


If you don't care, I would like to upstream via my tree because there is 
a couple of operations (like sharing a branch) I would like to monitor 
to let people build their driver on top of it: renesas and qcom.


Qcom's cpuidle driver is already implemented and waits for this patchset 
to be upstream (the patchset has been around long enough). And I believe 
the Renesas driver will be reworked to use it also.


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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


Re: [PATCH 3/6] ARM64: cpuidle: Replace cpu_suspend by the common ARM/ARM64 function

2015-03-13 Thread Daniel Lezcano

On 03/13/2015 07:21 PM, Catalin Marinas wrote:

On Tue, Mar 03, 2015 at 01:29:34PM +0100, Daniel Lezcano wrote:

Call the common ARM/ARM64 'arm_cpuidle_suspend' instead of cpu_suspend function
which is specific to ARM64.

Signed-off-by: Daniel Lezcano 
---
  drivers/cpuidle/cpuidle-arm64.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpuidle/cpuidle-arm64.c b/drivers/cpuidle/cpuidle-arm64.c
index 39a2c62..0cea244 100644
--- a/drivers/cpuidle/cpuidle-arm64.c
+++ b/drivers/cpuidle/cpuidle-arm64.c
@@ -49,7 +49,7 @@ static int arm64_enter_idle_state(struct cpuidle_device *dev,
 * call the CPU ops suspend protocol with idle index as a
 * parameter.
 */
-   ret = cpu_suspend(idx);
+   arm_cpuidle_suspend(idx);


Nitpick: why don't we just rename the arm one cpuidle_suspend()?


I don't have a strong opinion on that. Actually, the cpuidle_ prefix is 
used by the arch agnostic code in drivers/cpuidle/cpuidle.c.


If Rafael agrees on changing it to this function name, I am ok also.


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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


Re: [PATCH 0/6] ARM: cpuidle: Unify the ARM64/ARM DT approach

2015-03-13 Thread Rob Herring
On Thu, Mar 12, 2015 at 9:25 AM, Daniel Lezcano
 wrote:
>
> Catalin, Rob,
>
> do you agree with this patchset ?

There's very little to do with DT, but looks fine to me.

Rob

>
> Thanks
>   -- Daniel
>
>
> On 03/03/2015 01:29 PM, Daniel Lezcano wrote:
>>
>> There is a big number of cpuidle drivers for the ARM architecture.
>>
>> These drivers have been cleaned up and grouped into the drivers/cpuidle
>> directory to keep track of the changes more easily and ensure the code
>> is following the same scheme across the drivers.
>>
>> That had the benefit of simplifying the code and factor out a lot of
>> common
>> parts. Beside that, as the drivers belong to the 'drivers' directory, we
>> had
>> to split the arch specific bits and the generic code in order to keep
>> everything self contained. The platform driver paradigm was used for this
>> purpose.
>>
>> Unfortunately, this approach is now no longer accepted and a different
>> solution
>> must be provided to reach the same goal: one example is the Qualcomm
>> cpuidle
>> driver upstreaming attempt [1].
>>
>> In the meantime, ARM64 developed a generic cpuidle driver based on DT
>> definition.
>>
>> The DT definition provides an 'enable-method' to specify one of the cpu
>> operations (PSCI, ...).
>>
>> This patchset unify this driver with ARM32, using the same DT definition.
>>
>> Thanks with this patchset we can use the 'enable-method' to specify a cpu
>> operations, hence get rid of the platform driver approach and go further
>> in the
>> cpuidle driver flexibility via the DT.
>>
>> Daniel Lezcano (6):
>>ARM: cpuidle: Remove duplicate header inclusion
>>ARM: cpuidle: Add a cpuidle ops structure to be used for DT
>>ARM64: cpuidle: Replace cpu_suspend by the common ARM/ARM64 function
>>ARM64: cpuidle: Rename cpu_init_idle to a common function name
>>ARM64: cpuidle: Remove arm64 reference
>>ARM: cpuidle: Enable the ARM64 driver for both ARM32/ARM64
>>
>>   arch/arm/include/asm/cpuidle.h | 12 +++
>>   arch/arm/include/asm/cpuidle_ops.h |  3 +
>>   arch/arm/kernel/cpuidle.c  | 87
>> +-
>>   arch/arm/mach-davinci/cpuidle.c|  1 -
>>   arch/arm/mach-imx/cpuidle-imx6q.c  |  1 -
>>   arch/arm/mach-imx/cpuidle-imx6sl.c |  1 -
>>   arch/arm/mach-imx/cpuidle-imx6sx.c |  1 -
>>   arch/arm/mach-omap2/cpuidle44xx.c  |  1 -
>>   arch/arm/mach-tegra/cpuidle-tegra20.c  |  1 -
>>   arch/arm/mach-tegra/cpuidle-tegra30.c  |  1 -
>>   arch/arm64/include/asm/cpuidle.h   |  9 ++-
>>   arch/arm64/kernel/cpuidle.c|  2 +-
>>   drivers/cpuidle/Kconfig|  7 +-
>>   drivers/cpuidle/Kconfig.arm| 10 +++
>>   drivers/cpuidle/Kconfig.arm64  | 13 
>>   drivers/cpuidle/Makefile   |  5 +-
>>   drivers/cpuidle/{cpuidle-arm64.c => cpuidle-arm.c} | 38 +-
>>   drivers/cpuidle/cpuidle-at91.c |  1 -
>>   drivers/cpuidle/cpuidle-exynos.c   |  1 -
>>   drivers/cpuidle/cpuidle-kirkwood.c |  1 -
>>   drivers/cpuidle/cpuidle-ux500.c|  1 -
>>   drivers/cpuidle/cpuidle-zynq.c |  1 -
>>   22 files changed, 139 insertions(+), 59 deletions(-)
>>   create mode 100644 arch/arm/include/asm/cpuidle_ops.h
>>   delete mode 100644 drivers/cpuidle/Kconfig.arm64
>>   rename drivers/cpuidle/{cpuidle-arm64.c => cpuidle-arm.c} (72%)
>>
>
>
> --
>   Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:   Facebook |
>  Twitter |
>  Blog
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Add device tree support to adp1653 flash driver

2015-03-13 Thread Pavel Machek
Nokia N900 is switching to device tree, make sure we can use flash
there, too.

Signed-off-by: Pavel Machek 

diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c
index 873fe19..0341009 100644
--- a/drivers/media/i2c/adp1653.c
+++ b/drivers/media/i2c/adp1653.c
@@ -8,6 +8,7 @@
  * Contributors:
  * Sakari Ailus 
  * Tuukka Toivonen 
+ * Pavel Machek 
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -34,6 +35,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -306,9 +309,17 @@ adp1653_init_device(struct adp1653_flash *flash)
 static int
 __adp1653_set_power(struct adp1653_flash *flash, int on)
 {
-   int ret;
+   int ret = 0;
+
+   if (flash->platform_data->power) {
+   ret = flash->platform_data->power(&flash->subdev, on);
+   } else {
+   gpio_set_value(flash->platform_data->power_gpio, on);
+   if (on)
+   /* Some delay is apparently required. */
+   udelay(20);
+   }
 
-   ret = flash->platform_data->power(&flash->subdev, on);
if (ret < 0)
return ret;
 
@@ -316,8 +327,13 @@ __adp1653_set_power(struct adp1653_flash *flash, int on)
return 0;
 
ret = adp1653_init_device(flash);
-   if (ret < 0)
+   if (ret >= 0)
+   return ret;
+
+   if (flash->platform_data->power)
flash->platform_data->power(&flash->subdev, 0);
+   else
+   gpio_set_value(flash->platform_data->power_gpio, 0);
 
return ret;
 }
@@ -407,21 +423,77 @@ static int adp1653_resume(struct device *dev)
 
 #endif /* CONFIG_PM */
 
+static int adp1653_of_init(struct i2c_client *client,
+  struct adp1653_flash *flash,
+  struct device_node *node)
+{
+   u32 val;
+   struct adp1653_platform_data *pd;
+   enum of_gpio_flags flags;
+   int gpio;
+   struct device_node *child;
+
+   if (!node)
+   return -EINVAL;
+
+   pd = devm_kzalloc(&client->dev, sizeof(*pd), GFP_KERNEL);
+   if (!pd)
+   return -ENOMEM;
+   flash->platform_data = pd;
+
+   child = of_get_child_by_name(node, "flash");
+   if (!child)
+   return -EINVAL;
+   if (of_property_read_u32(child, "flash-timeout-microsec", &val))
+   return -EINVAL;
+
+   pd->max_flash_timeout = val;
+   if (of_property_read_u32(child, "flash-max-microamp", &val))
+   return -EINVAL;
+   pd->max_flash_intensity = val/1000;
+
+   if (of_property_read_u32(child, "max-microamp", &val))
+   return -EINVAL;
+   pd->max_torch_intensity = val/1000;
+
+   child = of_get_child_by_name(node, "indicator");
+   if (!child)
+   return -EINVAL;
+   if (of_property_read_u32(child, "max-microamp", &val))
+   return -EINVAL;
+   pd->max_indicator_intensity = val;
+
+   if (!of_find_property(node, "gpios", NULL)) {
+   dev_err(&client->dev, "No gpio node\n");
+   return -EINVAL;
+   }
+
+   pd->power_gpio = of_get_gpio_flags(node, 0, &flags);
+   if (pd->power_gpio < 0) {
+   dev_err(&client->dev, "Error getting GPIO\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+
 static int adp1653_probe(struct i2c_client *client,
 const struct i2c_device_id *devid)
 {
struct adp1653_flash *flash;
int ret;
 
-   /* we couldn't work without platform data */
-   if (client->dev.platform_data == NULL)
-   return -ENODEV;
-
flash = devm_kzalloc(&client->dev, sizeof(*flash), GFP_KERNEL);
if (flash == NULL)
return -ENOMEM;
 
flash->platform_data = client->dev.platform_data;
+   if (!flash->platform_data) {
+   ret = adp1653_of_init(client, flash, client->dev.of_node);
+   if (ret)
+   return ret;
+   }
 
mutex_init(&flash->power_lock);
 
@@ -438,10 +510,10 @@ static int adp1653_probe(struct i2c_client *client,
goto free_and_quit;
 
flash->subdev.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
-
return 0;
 
 free_and_quit:
+   dev_err(&client->dev, "adp1653: failed to register device\n");
v4l2_ctrl_handler_free(&flash->ctrls);
return ret;
 }
@@ -464,7 +536,7 @@ static const struct i2c_device_id adp1653_id_table[] = {
 };
 MODULE_DEVICE_TABLE(i2c, adp1653_id_table);
 
-static struct dev_pm_ops adp1653_pm_ops = {
+static const struct dev_pm_ops adp1653_pm_ops = {
.suspend= adp1653_suspend,
.resume = adp1653_resume,
 };
diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt 
b/Documentation/devicetree/bindings/media/i2c/adp1653.txt
new file mo

[PATCH v2 1/2] ARM: dts: omap3: Remove all references to ti,codec property

2015-03-13 Thread Marek Belisko
ti,codec property is not used (parsed) in omap-twl4030 driver. The 
ti,twl4030-audio
which ti,codec points by phandle is mfd driver and device for ASoC codec is 
created
w/o DT compatible string. Removing all references in DT files.

Signed-off-by: Marek Belisko 
---
 arch/arm/boot/dts/omap3-beagle-xm.dts   | 1 -
 arch/arm/boot/dts/omap3-beagle.dts  | 1 -
 arch/arm/boot/dts/omap3-cm-t3x30.dtsi   | 1 -
 arch/arm/boot/dts/omap3-devkit8000.dts  | 1 -
 arch/arm/boot/dts/omap3-gta04.dtsi  | 1 -
 arch/arm/boot/dts/omap3-igep.dtsi   | 1 -
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi | 1 -
 arch/arm/boot/dts/omap3-overo-base.dtsi | 1 -
 arch/arm/boot/dts/omap3-tao3530.dtsi| 1 -
 9 files changed, 9 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 25f7b0a..da1464b 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -60,7 +60,6 @@
ti,model = "omap3beagle";
 
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
};
 
gpio_keys {
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index c792391..4d30eaf 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -71,7 +71,6 @@
ti,model = "omap3beagle";
 
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
};
 
gpio_keys {
diff --git a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi 
b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
index d9e92b6..046cd77 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x30.dtsi
@@ -16,7 +16,6 @@
ti,model = "cm-t35";
 
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
};
 };
 
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts 
b/arch/arm/boot/dts/omap3-devkit8000.dts
index 169037e..134d3f2 100644
--- a/arch/arm/boot/dts/omap3-devkit8000.dts
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -48,7 +48,6 @@
ti,model = "devkit8000";
 
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
ti,audio-routing =
"Ext Spk", "PREDRIVEL",
"Ext Spk", "PREDRIVER",
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index fb3a696..b9f6881 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -46,7 +46,6 @@
ti,model = "gta04";
 
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
};
 
spi_lcd {
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi 
b/arch/arm/boot/dts/omap3-igep.dtsi
index 8a63ad2..d5e5cd4 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -22,7 +22,6 @@
compatible = "ti,omap-twl4030";
ti,model = "igep2";
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
};
 
vdd33: regulator-vdd33 {
diff --git a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi 
b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
index e81fb65..e631333 100644
--- a/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
+++ b/arch/arm/boot/dts/omap3-lilly-a83x.dtsi
@@ -38,7 +38,6 @@
ti,model = "lilly-a83x";
 
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
};
 
reg_vcc3: vcc3 {
diff --git a/arch/arm/boot/dts/omap3-overo-base.dtsi 
b/arch/arm/boot/dts/omap3-overo-base.dtsi
index d36bf02..18e1649 100644
--- a/arch/arm/boot/dts/omap3-overo-base.dtsi
+++ b/arch/arm/boot/dts/omap3-overo-base.dtsi
@@ -27,7 +27,6 @@
ti,model = "overo";
 
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
};
 
/* HS USB Port 2 Power */
diff --git a/arch/arm/boot/dts/omap3-tao3530.dtsi 
b/arch/arm/boot/dts/omap3-tao3530.dtsi
index e89820a..b3b24a5 100644
--- a/arch/arm/boot/dts/omap3-tao3530.dtsi
+++ b/arch/arm/boot/dts/omap3-tao3530.dtsi
@@ -45,7 +45,6 @@
 
/* McBSP2 is used for onboard sound, same as on beagle */
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
};
 
/* Regulator to enable/switch the vcc of the Wifi module */
-- 
1.9.1

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


[PATCH v2 2/2] Documentation: omap-twl4030: Move ti,codec property to optional

2015-03-13 Thread Marek Belisko
ti,codec property is not used in omap-twl4030 driver in linux kernel but
we keep it as optional property, so that the existing dtbs do not
become noncompliant after the change on other OS.

Signed-off-by: Marek Belisko 
---
 Documentation/devicetree/bindings/sound/omap-twl4030.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt 
b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
index 1ab6bc8..f6a715e 100644
--- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
+++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
@@ -4,9 +4,9 @@ Required properties:
 - compatible: "ti,omap-twl4030"
 - ti,model: Name of the sound card (for example "omap3beagle")
 - ti,mcbsp: phandle for the McBSP node
-- ti,codec: phandle for the twl4030 audio node
 
 Optional properties:
+- ti,codec: phandle for the twl4030 audio node
 - ti,mcbsp-voice: phandle for the McBSP node connected to the voice port of twl
 - ti, jack-det-gpio: Jack detect GPIO
 - ti,audio-routing: List of connections between audio components.
@@ -59,5 +59,4 @@ sound {
ti,model = "omap3beagle";
 
ti,mcbsp = <&mcbsp2>;
-   ti,codec = <&twl_audio>;
 };
-- 
1.9.1

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


[PATCH v2 0/2] ARM: devicetree: Remove unused ti,codec property

2015-03-13 Thread Marek Belisko
ti,codec in not parsed in omap-twl4030 sound driver. It's not necessary
to specify this property in DT because ti,twl4030-audio which ti,codec
was pointing to by phandle is mfd driver and device for ASoC ic created w/o
any DT property (codec name is hardcoded in ASoC driver).

Please see reply [1] from Peter Ujfalusi.

Changes from v1:
- keep ti,codec property in Documentation as optional that the
existing dtbs do not become noncompliant after the change

[1]: http://comments.gmane.org/gmane.linux.ports.arm.omap/124273

Marek Belisko (2):
  ARM: dts: omap3: Remove all references to ti,codec property
  Documentation: omap-twl4030: Move ti,codec property to optional

 Documentation/devicetree/bindings/sound/omap-twl4030.txt | 3 +--
 arch/arm/boot/dts/omap3-beagle-xm.dts| 1 -
 arch/arm/boot/dts/omap3-beagle.dts   | 1 -
 arch/arm/boot/dts/omap3-cm-t3x30.dtsi| 1 -
 arch/arm/boot/dts/omap3-devkit8000.dts   | 1 -
 arch/arm/boot/dts/omap3-gta04.dtsi   | 1 -
 arch/arm/boot/dts/omap3-igep.dtsi| 1 -
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi  | 1 -
 arch/arm/boot/dts/omap3-overo-base.dtsi  | 1 -
 arch/arm/boot/dts/omap3-tao3530.dtsi | 1 -
 10 files changed, 1 insertion(+), 11 deletions(-)

-- 
1.9.1

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


Re: [PATCH 6/6] dts: msm8974: Add dma channels for blsp2_i2c1 node

2015-03-13 Thread Andy Gross
On Fri, Mar 13, 2015 at 11:19:52PM +0530, Sricharan R wrote:
> Signed-off-by: Sricharan R 
> ---

Reviewed-by: Andy Gross 

>  arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 3f648ae..1ec7ec5 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -246,6 +246,8 @@
>   clock-names = "core", "iface";
>   #address-cells = <1>;
>   #size-cells = <0>;
> + dmas = <&blsp2_dma 20>, <&blsp2_dma 21>;
> + dma-names = "bam-tx", "bam-rx";

more of a nit, but the bam- is unnecessary.  it's just rx/tx.
>   };
>  
>   blsp2_dma: dma@f9944000 {
> -- 
> 1.8.2.1
> 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[Patch] dt: OF_UNITTEST make dependency broken

2015-03-13 Thread Frank Rowand
From: Frank Rowand 

If CONFIG_OF_UNITTEST=y then a kernel image make will always cause .version to
be incremented, even if there are not source changes.  This is caused by
a lack of dependency tracking and checking for
drivers/of/unittest-data/testcases.dtb.o.


Signed-off-by: Frank Rowand 

---


 drivers/of/Makefile |5 +++--
 drivers/of/unittest-data/.gitignore |2 ++
 drivers/of/unittest-data/Makefile   |7 +++
 3 files changed, 12 insertions(+), 2 deletions(-)

Index: b/drivers/of/Makefile
===
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -6,8 +6,7 @@ obj-$(CONFIG_OF_PROMTREE) += pdt.o
 obj-$(CONFIG_OF_ADDRESS)  += address.o
 obj-$(CONFIG_OF_IRQ)+= irq.o
 obj-$(CONFIG_OF_NET)   += of_net.o
-obj-$(CONFIG_OF_UNITTEST) += of_unittest.o
-of_unittest-objs := unittest.o unittest-data/testcases.dtb.o
+obj-$(CONFIG_OF_UNITTEST) += unittest.o
 obj-$(CONFIG_OF_MDIO)  += of_mdio.o
 obj-$(CONFIG_OF_PCI)   += of_pci.o
 obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
@@ -16,5 +15,7 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_rese
 obj-$(CONFIG_OF_RESOLVE)  += resolver.o
 obj-$(CONFIG_OF_OVERLAY) += overlay.o
 
+obj-$(CONFIG_OF_UNITTEST) += unittest-data/
+
 CFLAGS_fdt.o = -I$(src)/../../scripts/dtc/libfdt
 CFLAGS_fdt_address.o = -I$(src)/../../scripts/dtc/libfdt
Index: b/drivers/of/unittest-data/Makefile
===
--- /dev/null
+++ b/drivers/of/unittest-data/Makefile
@@ -0,0 +1,7 @@
+obj-y += testcases.dtb.o
+
+targets += testcases.dtb testcases.dtb.S
+
+.SECONDARY: \
+   $(obj)/testcases.dtb.S \
+   $(obj)/testcases.dtb
Index: b/drivers/of/unittest-data/.gitignore
===
--- /dev/null
+++ b/drivers/of/unittest-data/.gitignore
@@ -0,0 +1,2 @@
+testcases.dtb
+testcases.dtb.S
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch v3 1/3] dt: OF_UNITTEST make dependency broken, framework fixes

2015-03-13 Thread Frank Rowand
On 3/13/2015 6:13 AM, Rob Herring wrote:
> On Thu, Mar 12, 2015 at 8:15 AM, Frank Rowand  wrote:
>> From: Frank Rowand 
>>
>> This 3 patch series is not bisectable.  If CONFIG_OF_UNITTEST=y then the 
>> kernel
>> will not build with just patch 1 or just patches 1 and 2 applied.
> 
> If you did 2 patches with the move first, wouldn't that make it
> bisectable. However, I'd rather avoid the move.

Yes, I did not like the move either.  Fortunately you gave me the cluebat I 
needed
to avoid the move.

> 
>> If CONFIG_OF_UNITTEST=y then a kernel image make will always cause .version 
>> to
>> be incremented, even if there are not source changes.  This is caused by
>> a lack of dependency tracking and checking for
>> drivers/of/unittest-data/testcases.dtb.o.  Fixing the problem was made more
>> complicated by the fact that testcases.dtb.o was linked into 
>> ../of_unittest.o.
> 
> Couldn't we change that to be 2 modules.

Thanks, that was just the hint I needed to realize that of_unittest.o was
just an artifact of the problem I was trying to solve.  I will send a new
patch that removes the of_unittest.o cruft and does not need to move unittest.c

> 
>> Patch 1 modifies makefiles to move of_unittest.c into unittest-data/ and
>> creates missing dependency tracking for testcases.dtb.o.
>>
>> Patch 2 will move of_unittest.c into unittest-data/
>>
>> Patch 3 will fix an of_unittest.c include path to account for the move.
> 
> This should all be in an intro email, not patch #1.

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


Re: [PATCH v6 0/6] wlcore: add device-tree support

2015-03-13 Thread Sébastien Szymanski
Hello,

On 03/12/2015 01:09 PM, Eliad Peller wrote:
> 
> NOTE: all the platform patches were compile-tested
> only. I'm looking for some wl12xx card (that i should
> have somewhere) to test the wl12xx changes (wrt. clocks),
> but haven't found it yet.
> 

I have tested this series on a APF6 board, i.MX6 based board with a
Jorjin WG7311-0A Wifi/BT module which is based on the wl1271l.

It works. I was able to power up the wlan0 interface and ping google.

Best regards,

-- 
Sébastien Szymanski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/6] ARM: cpuidle: Unify the ARM64/ARM DT approach

2015-03-13 Thread Catalin Marinas
On Thu, Mar 12, 2015 at 03:25:34PM +0100, Daniel Lezcano wrote:
> do you agree with this patchset ?

In principle yes, apart from some function naming and I'm waiting for
Lorenzo's ack as well. Do you plan to upstream this directly via your
tree? If yes, I'll look in more detail and give some acks.

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


Re: [PATCH 4/6] ARM64: cpuidle: Rename cpu_init_idle to a common function name

2015-03-13 Thread Catalin Marinas
On Tue, Mar 03, 2015 at 01:29:35PM +0100, Daniel Lezcano wrote:
> diff --git a/drivers/cpuidle/cpuidle-arm64.c b/drivers/cpuidle/cpuidle-arm64.c
> index 0cea244..6ef291c7 100644
> --- a/drivers/cpuidle/cpuidle-arm64.c
> +++ b/drivers/cpuidle/cpuidle-arm64.c
> @@ -110,7 +110,7 @@ static int __init arm64_idle_init(void)
>* idle states suspend back-end specific data
>*/
>   for_each_possible_cpu(cpu) {
> - ret = cpu_init_idle(cpu);
> + ret = arm_cpuidle_init(cpu);

Same nitpick here about dropping the arm_ prefix (though here we already
have a cpuidle_init).

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


Re: [PATCH 3/6] ARM64: cpuidle: Replace cpu_suspend by the common ARM/ARM64 function

2015-03-13 Thread Catalin Marinas
On Tue, Mar 03, 2015 at 01:29:34PM +0100, Daniel Lezcano wrote:
> Call the common ARM/ARM64 'arm_cpuidle_suspend' instead of cpu_suspend 
> function
> which is specific to ARM64.
> 
> Signed-off-by: Daniel Lezcano 
> ---
>  drivers/cpuidle/cpuidle-arm64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpuidle/cpuidle-arm64.c b/drivers/cpuidle/cpuidle-arm64.c
> index 39a2c62..0cea244 100644
> --- a/drivers/cpuidle/cpuidle-arm64.c
> +++ b/drivers/cpuidle/cpuidle-arm64.c
> @@ -49,7 +49,7 @@ static int arm64_enter_idle_state(struct cpuidle_device 
> *dev,
>* call the CPU ops suspend protocol with idle index as a
>* parameter.
>*/
> - ret = cpu_suspend(idx);
> + arm_cpuidle_suspend(idx);

Nitpick: why don't we just rename the arm one cpuidle_suspend()?

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


Re: [PATCH 1/6] ARM: cpuidle: Remove duplicate header inclusion

2015-03-13 Thread Lorenzo Pieralisi
On Tue, Mar 03, 2015 at 12:29:32PM +, Daniel Lezcano wrote:
> The cpu_do_idle() function is always used by the cpuidle drivers.
> 
> That led to have each driver including cpuidle.h and proc-fns.h, they are
> always paired. That makes a lot of duplicate headers inclusion. Instead of
> including both in each .c file, move the proc-fns.h header inclusion in the
> cpuidle.h header file directly, so we can save some line of code.
> 
> Signed-off-by: Daniel Lezcano 

Acked-by: Lorenzo Pieralisi 

> ---
>  arch/arm/include/asm/cpuidle.h| 2 ++
>  arch/arm/kernel/cpuidle.c | 2 +-
>  arch/arm/mach-davinci/cpuidle.c   | 1 -
>  arch/arm/mach-imx/cpuidle-imx6q.c | 1 -
>  arch/arm/mach-imx/cpuidle-imx6sl.c| 1 -
>  arch/arm/mach-imx/cpuidle-imx6sx.c| 1 -
>  arch/arm/mach-omap2/cpuidle44xx.c | 1 -
>  arch/arm/mach-tegra/cpuidle-tegra20.c | 1 -
>  arch/arm/mach-tegra/cpuidle-tegra30.c | 1 -
>  drivers/cpuidle/cpuidle-at91.c| 1 -
>  drivers/cpuidle/cpuidle-exynos.c  | 1 -
>  drivers/cpuidle/cpuidle-kirkwood.c| 1 -
>  drivers/cpuidle/cpuidle-ux500.c   | 1 -
>  drivers/cpuidle/cpuidle-zynq.c| 1 -
>  14 files changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/include/asm/cpuidle.h b/arch/arm/include/asm/cpuidle.h
> index af319ac..348dc81 100644
> --- a/arch/arm/include/asm/cpuidle.h
> +++ b/arch/arm/include/asm/cpuidle.h
> @@ -1,6 +1,8 @@
>  #ifndef __ASM_ARM_CPUIDLE_H
>  #define __ASM_ARM_CPUIDLE_H
>  
> +#include 
> +
>  #ifdef CONFIG_CPU_IDLE
>  extern int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
>   struct cpuidle_driver *drv, int index);
> diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c
> index 89545f6..45969f8 100644
> --- a/arch/arm/kernel/cpuidle.c
> +++ b/arch/arm/kernel/cpuidle.c
> @@ -10,7 +10,7 @@
>   */
>  
>  #include 
> -#include 
> +#include 
>  
>  int arm_cpuidle_simple_enter(struct cpuidle_device *dev,
>   struct cpuidle_driver *drv, int index)
> diff --git a/arch/arm/mach-davinci/cpuidle.c b/arch/arm/mach-davinci/cpuidle.c
> index e365c1b..306ebc5 100644
> --- a/arch/arm/mach-davinci/cpuidle.c
> +++ b/arch/arm/mach-davinci/cpuidle.c
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> diff --git a/arch/arm/mach-imx/cpuidle-imx6q.c 
> b/arch/arm/mach-imx/cpuidle-imx6q.c
> index d76d086..8e21ccc 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6q.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6q.c
> @@ -9,7 +9,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "common.h"
>  #include "cpuidle.h"
> diff --git a/arch/arm/mach-imx/cpuidle-imx6sl.c 
> b/arch/arm/mach-imx/cpuidle-imx6sl.c
> index 7d92e65..5742a9f 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6sl.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6sl.c
> @@ -9,7 +9,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include "common.h"
>  #include "cpuidle.h"
> diff --git a/arch/arm/mach-imx/cpuidle-imx6sx.c 
> b/arch/arm/mach-imx/cpuidle-imx6sx.c
> index 5a36722..2c9f1a8 100644
> --- a/arch/arm/mach-imx/cpuidle-imx6sx.c
> +++ b/arch/arm/mach-imx/cpuidle-imx6sx.c
> @@ -10,7 +10,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include "common.h"
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
> b/arch/arm/mach-omap2/cpuidle44xx.c
> index 01e398a..7622dbb 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -17,7 +17,6 @@
>  #include 
>  
>  #include 
> -#include 
>  
>  #include "common.h"
>  #include "pm.h"
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra20.c 
> b/arch/arm/mach-tegra/cpuidle-tegra20.c
> index 4f25a7c..e22b0d9 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra20.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra20.c
> @@ -27,7 +27,6 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/arch/arm/mach-tegra/cpuidle-tegra30.c 
> b/arch/arm/mach-tegra/cpuidle-tegra30.c
> index f8815ed..a2400ab4 100644
> --- a/arch/arm/mach-tegra/cpuidle-tegra30.c
> +++ b/arch/arm/mach-tegra/cpuidle-tegra30.c
> @@ -27,7 +27,6 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/cpuidle/cpuidle-at91.c b/drivers/cpuidle/cpuidle-at91.c
> index aae7bfc..f2446c7 100644
> --- a/drivers/cpuidle/cpuidle-at91.c
> +++ b/drivers/cpuidle/cpuidle-at91.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #define AT91_MAX_STATES  2
> diff --git a/drivers/cpuidle/cpuidle-exynos.c 
> b/drivers/cpuidle/cpuidle-exynos.c
> index 26f5f29..0c06ea2 100644
> --- a/drivers/cpuidle/cpuidle-exynos.c
> +++ b/drivers/cpuidle/cpuidle-exynos.c
> @@ -19,7 +19,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/cpuidle/cpuidle-kirkwood.c 
> b/drivers/cpuidle/cpuidle-kirkwood.c
> index cea0a6c..d23d8f4 100644
> --- a/drivers/cpuidle/cpuidle-kirkwood.c

[PATCH 1/6] i2c: qup: Change qup_wait_writeready function to use for all timeouts

2015-03-13 Thread Sricharan R
qup_wait_writeready waits only on a output fifo empty event.
Change the same function to accept the event and data length
to wait as parameters. This way the same function can be used for
timeouts in otherplaces as well.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 4dad23b..49c6cba 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -221,26 +221,42 @@ static int qup_i2c_change_state(struct qup_i2c_dev *qup, 
u32 state)
return 0;
 }
 
-static int qup_i2c_wait_writeready(struct qup_i2c_dev *qup)
+/**
+ * qup_i2c_wait_ready - wait for a give number of bytes in tx/rx path
+ * @qup: The qup_i2c_dev device
+ * @op: The bit/event to wait on
+ * @val: value of the bit to wait on, 0 or 1
+ * @len: The length the bytes to be transferred
+ */
+static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int op, bool val,
+ int len)
 {
unsigned long timeout;
u32 opflags;
u32 status;
+   u32 shift = __ffs(op);
 
-   timeout = jiffies + HZ;
+   len *= qup->one_byte_t;
+   /* timeout after a wait of twice the max time */
+   timeout = jiffies + len * 4;
 
for (;;) {
opflags = readl(qup->base + QUP_OPERATIONAL);
status = readl(qup->base + QUP_I2C_STATUS);
 
-   if (!(opflags & QUP_OUT_NOT_EMPTY) &&
-   !(status & I2C_STATUS_BUS_ACTIVE))
-   return 0;
+   if (((opflags & op) >> shift) == val) {
+   if (op == QUP_OUT_NOT_EMPTY) {
+   if (!(status & I2C_STATUS_BUS_ACTIVE))
+   return 0;
+   } else {
+   return 0;
+   }
+   }
 
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
 
-   usleep_range(qup->one_byte_t, qup->one_byte_t * 2);
+   usleep_range(len, len * 2);
}
 }
 
@@ -347,7 +363,7 @@ static int qup_i2c_write_one(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
} while (qup->pos < msg->len);
 
/* Wait for the outstanding data in the fifo to drain */
-   ret = qup_i2c_wait_writeready(qup);
+   ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, 0, 1);
 
 err:
disable_irq(qup->irq);
-- 
1.8.2.1

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


[PATCH 3/6] i2c: qup: Add bam dma capabilities

2015-03-13 Thread Sricharan R
QUP cores can be attached to a BAM module, which acts as
a dma engine for the QUP core. When DMA with BAM is enabled,
the BAM consumer pipe transmitted data is written to the output FIFO
and the BAM producer pipe received data is read from the input FIFO.

With BAM capabilities, qup-i2c core can transfer more than 256 bytes,
without a 'stop' which is not possible otherwise.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 365 ++-
 1 file changed, 359 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index e4e223f..11ea6af 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -25,6 +25,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /* QUP Registers */
 #define QUP_CONFIG 0x000
@@ -34,6 +39,7 @@
 #define QUP_OPERATIONAL0x018
 #define QUP_ERROR_FLAGS0x01c
 #define QUP_ERROR_FLAGS_EN 0x020
+#define QUP_OPERATIONAL_MASK   0x028
 #define QUP_HW_VERSION 0x030
 #define QUP_MX_OUTPUT_CNT  0x100
 #define QUP_OUT_FIFO_BASE  0x110
@@ -44,6 +50,7 @@
 #define QUP_I2C_CLK_CTL0x400
 #define QUP_I2C_STATUS 0x404
 #define QUP_I2C_MASTER_GEN 0x408
+#define QUP_I2C_MASTER_CONFIG  0x408
 
 /* QUP States and reset values */
 #define QUP_RESET_STATE0
@@ -53,6 +60,7 @@
 
 #define QUP_STATE_VALIDBIT(2)
 #define QUP_I2C_MAST_GEN   BIT(4)
+#define QUP_I2C_FLUSH  BIT(6)
 
 #define QUP_OPERATIONAL_RESET  0x000ff0
 #define QUP_I2C_STATUS_RESET   0xfc
@@ -78,7 +86,10 @@
 
 /* Packing/Unpacking words in FIFOs, and IO modes */
 #define QUP_OUTPUT_BLK_MODE(1 << 10)
+#define QUP_OUTPUT_BAM_MODE(3 << 10)
 #define QUP_INPUT_BLK_MODE (1 << 12)
+#define QUP_INPUT_BAM_MODE (3 << 12)
+#define QUP_BAM_MODE   (QUP_OUTPUT_BAM_MODE | QUP_INPUT_BAM_MODE)
 #define QUP_UNPACK_EN  BIT(14)
 #define QUP_PACK_ENBIT(15)
 
@@ -105,6 +116,10 @@
 #define QUP_TAG_V2_DATARD  0x85
 #define QUP_TAG_V2_DATARD_STOP 0x87
 
+/* QUP BAM v2 tags */
+#define QUP_BAM_INPUT_EOT  0x93
+#define QUP_BAM_FLUSH_STOP 0x96
+
 /* frequency definitions for high speed and max speed */
 #define I2C_QUP_CLK_FAST_FREQ  100
 #define I2C_QUP_CLK_MAX_FREQ   340
@@ -116,12 +131,21 @@
 #define QUP_STATUS_ERROR_FLAGS 0x7c
 
 #define QUP_READ_LIMIT 256
+#define MX_TX_RX_LEN   SZ_64K
+#define MX_BLOCKS  (MX_TX_RX_LEN / QUP_READ_LIMIT)
+
+#define TOUT_MAX   300 /* Max timeout for 32k tx/tx */
 
 struct qup_i2c_config {
int tag_ver;
int max_freq;
 };
 
+struct tag {
+   u8 *start;
+   dma_addr_t addr;
+};
+
 struct qup_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -157,9 +181,35 @@ struct qup_i2c_dev {
/* QUP core errors */
u32 qup_err;
 
+   /* dma parameters */
+   boolis_dma;
+   struct  dma_pool *dpool;
+   struct  tag start_tag;
+   struct  tag scratch_tag;
+   struct  tag footer_tag;
+   struct  dma_chan *dma_tx;
+   struct  dma_chan *dma_rx;
+   struct  scatterlist *sg_tx;
+   struct  scatterlist *sg_rx;
+   dma_addr_t  sg_tx_phys;
+   dma_addr_t  sg_rx_phys;
+
struct completion   xfer;
 };
 
+struct i2c_bam_xfer {
+   struct qup_i2c_dev *qup;
+   u32 start_len;
+
+   u32 rx_nents;
+   u32 tx_nents;
+
+   struct dma_async_tx_descriptor *tx_desc;
+   dma_cookie_t tx_cookie;
+   struct dma_async_tx_descriptor *rx_desc;
+   dma_cookie_t rx_cookie;
+};
+
 static irqreturn_t qup_i2c_interrupt(int irq, void *dev)
 {
struct qup_i2c_dev *qup = dev;
@@ -233,6 +283,14 @@ static int qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 
req_state)
return qup_i2c_poll_state_mask(qup, req_state, QUP_STATE_MASK);
 }
 
+static void qup_i2c_flush(struct qup_i2c_dev *qup)
+{
+   u32 val = readl(qup->base + QUP_STATE);
+
+   val |= QUP_I2C_FLUSH;
+   writel(val, qup->base + QUP_STATE);
+}
+
 static int qup_i2c_poll_state_valid(struct qup_i2c_dev *qup)
 {
return qup_i2c_poll_state_mask(qup, 0, 0);
@@ -719,12 +777,244 @@ err:
return ret;
 }
 
+static void bam_i2c_callback(void *data)
+{
+   struct qup_i2c_dev *qup = data;
+
+   complete(&qup->xfer);
+}
+
+static int get_start_tag(u8 *tag, struct i2c_msg *msg, int first, int last,
+   int blen)
+{
+   u8 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
+   u8 op;
+   int len = 0;
+
+   /* always

[PATCH 5/6] dts: msm8974: Add blsp2_bam dma node

2015-03-13 Thread Sricharan R
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index e265ec1..3f648ae 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -247,5 +247,15 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+   blsp2_dma: dma@f9944000 {
+   compatible = "qcom,bam-v1.4.0";
+   reg = <0xf9944000 0x19000>;
+   interrupts = <0 239 0>;
+   clocks = <&gcc GCC_BLSP2_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   };
};
 };
-- 
1.8.2.1

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


[PATCH 4/6] i2c: qup: Transfer every i2c_msg in i2c_msgs without stop

2015-03-13 Thread Sricharan R
The definition of i2c_msg says that

"If this is the last message in a group, it is followed by a STOP.
  Otherwise it is followed by the next @i2c_msg transaction segment,
  beginning with a (repeated) START"

So the expectation is that there is no 'STOP' bit inbetween individual
i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
to inform that there should not be a 'STOP' at the end of transaction.
The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
in to one transaction and transfer them. Adding the support for the same.

This is required for some clients like touchscreen which keeps
incrementing counts across individual transfers and 'STOP' bit inbetween
resets the counter, which is not required.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 192 ++-
 1 file changed, 115 insertions(+), 77 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 11ea6af..90a2b5e 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -846,75 +846,91 @@ void qup_sg_set_buf(struct scatterlist *sg, void *buf, 
struct tag *tg,
sg_dma_address(sg) = tg->addr + ((u8 *) buf - tg->start);
 }
 
-static int bam_do_xfer(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int bam_do_xfer(struct qup_i2c_dev *qup, struct i2c_msg *msg, int num)
 {
struct dma_async_tx_descriptor *txd, *rxd = NULL;
int ret = 0;
dma_cookie_t cookie_rx, cookie_tx;
-   u32 rx_nents = 0, tx_nents = 0, len = 0;
-   /* QUP I2C read/write limit for single command is 256bytes max*/
-   int blocks = (msg->len + QUP_READ_LIMIT) / QUP_READ_LIMIT;
-   int rem = msg->len % QUP_READ_LIMIT;
-   int tlen, i = 0, tx_len = 0;
-
-   if (msg->flags & I2C_M_RD) {
-   tx_nents = 1;
-   rx_nents = (blocks << 1) + 1;
-   sg_init_table(qup->sg_rx, rx_nents);
-
-   while (i < blocks) {
-   /* transfer length set to '0' implies 256 bytes */
-   tlen = (i == (blocks - 1)) ? rem : 0;
-   len += get_start_tag(&qup->start_tag.start[len],
- msg, !i, (i == (blocks-1)),
- tlen);
-
-   qup_sg_set_buf(&qup->sg_rx[i << 1],
-  &qup->scratch_tag.start[0],
-  &qup->scratch_tag,
-  2, qup, 0, 0);
-
-   qup_sg_set_buf(&qup->sg_rx[(i << 1) + 1],
-  &msg->buf[QUP_READ_LIMIT * i],
-  NULL, tlen, qup, 1,
-  DMA_FROM_DEVICE);
-
-   i++;
-   }
-
-   sg_init_one(qup->sg_tx, &qup->start_tag.start[0], len);
-   qup_sg_set_buf(qup->sg_tx, &qup->start_tag.start[0],
-  &qup->start_tag, len, qup, 0, 0);
-   qup_sg_set_buf(&qup->sg_rx[i << 1],
-  &qup->scratch_tag.start[1],
-  &qup->scratch_tag, 2,
-  qup, 0, 0);
-   } else {
-   qup->footer_tag.start[0] = QUP_BAM_FLUSH_STOP;
-   qup->footer_tag.start[1] = QUP_BAM_FLUSH_STOP;
-
-   tx_nents = (blocks << 1) + 1;
-   sg_init_table(qup->sg_tx, tx_nents);
-
-   while (i < blocks) {
-   tlen = (i == (blocks - 1)) ? rem : 0;
-   len = get_start_tag(&qup->start_tag.start[tx_len],
-   msg, !i, (i == (blocks-1)), tlen);
-
-   qup_sg_set_buf(&qup->sg_tx[i << 1],
-  &qup->start_tag.start[tx_len],
-  &qup->start_tag,
-  len, qup, 0, 0);
-
-   tx_len += len;
-   qup_sg_set_buf(&qup->sg_tx[(i << 1) + 1],
-  &msg->buf[QUP_READ_LIMIT * i], NULL,
-  tlen, qup, 1, DMA_TO_DEVICE);
-   i++;
+   u32 rx_nents = 0, tx_nents = 0, len, blocks, rem, last;
+   u32 cur_rx_nents, cur_tx_nents;
+   u32 tlen, i, tx_len, tx_buf = 0, rx_buf = 0, off = 0;
+
+   while (num) {
+   blocks = (msg->len + QUP_READ_LIMIT) / QUP_READ_LIMIT;
+   rem = msg->len % QUP_READ_LIMIT;
+   i = 0, tx_len = 0, len = 0;
+
+   if (msg->flags & I2C_M_RD) {
+   cur_tx_nents = 1;
+   cur_rx_nents = (blocks << 1) + 1;
+   rx_nents += cur_rx_nents;
+   tx_nents += cur_tx_nents;
+
+   while (i < blocks) {
+ 

[PATCH 2/6] i2c: qup: Add V2 tags support

2015-03-13 Thread Sricharan R
From: Andy Gross 

QUP from version 2.1.1 onwards, supports a new format of
i2c command tags. Tag codes instructs the controller to
perform a operation like read/write. This new tagging version
supports bam dma and transfers of more than 256 bytes without 'stop'
in between. Adding the support for the same.

For each block a data_write/read tag and data_len tag is added to
the output fifo. For the final block of data write_stop/read_stop
tag is used.

Signed-off-by: Andy Gross 
Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 342 ++-
 1 file changed, 305 insertions(+), 37 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 49c6cba..e4e223f 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* QUP Registers */
 #define QUP_CONFIG 0x000
@@ -42,6 +43,7 @@
 #define QUP_IN_FIFO_BASE   0x218
 #define QUP_I2C_CLK_CTL0x400
 #define QUP_I2C_STATUS 0x404
+#define QUP_I2C_MASTER_GEN 0x408
 
 /* QUP States and reset values */
 #define QUP_RESET_STATE0
@@ -69,6 +71,8 @@
 #define QUP_CLOCK_AUTO_GATEBIT(13)
 #define I2C_MINI_CORE  (2 << 8)
 #define I2C_N_VAL  15
+#define I2C_N_VAL_V2   7
+
 /* Most significant word offset in FIFO port */
 #define QUP_MSW_SHIFT  (I2C_N_VAL + 1)
 
@@ -80,17 +84,31 @@
 
 #define QUP_REPACK_EN  (QUP_UNPACK_EN | QUP_PACK_EN)
 
+#define QUP_V2_TAGS_EN 1
+
 #define QUP_OUTPUT_BLOCK_SIZE(x)(((x) >> 0) & 0x03)
 #define QUP_OUTPUT_FIFO_SIZE(x)(((x) >> 2) & 0x07)
 #define QUP_INPUT_BLOCK_SIZE(x)(((x) >> 5) & 0x03)
 #define QUP_INPUT_FIFO_SIZE(x) (((x) >> 7) & 0x07)
 
-/* QUP tags */
+/* QUP V1 tags */
 #define QUP_TAG_START  (1 << 8)
 #define QUP_TAG_DATA   (2 << 8)
 #define QUP_TAG_STOP   (3 << 8)
 #define QUP_TAG_REC(4 << 8)
 
+/* QUP v2 tags */
+#define QUP_TAG_V2_HS  0xff
+#define QUP_TAG_V2_START   0x81
+#define QUP_TAG_V2_DATAWR  0x82
+#define QUP_TAG_V2_DATAWR_STOP 0x83
+#define QUP_TAG_V2_DATARD  0x85
+#define QUP_TAG_V2_DATARD_STOP 0x87
+
+/* frequency definitions for high speed and max speed */
+#define I2C_QUP_CLK_FAST_FREQ  100
+#define I2C_QUP_CLK_MAX_FREQ   340
+
 /* Status, Error flags */
 #define I2C_STATUS_WR_BUFFER_FULL  BIT(0)
 #define I2C_STATUS_BUS_ACTIVE  BIT(8)
@@ -99,6 +117,11 @@
 
 #define QUP_READ_LIMIT 256
 
+struct qup_i2c_config {
+   int tag_ver;
+   int max_freq;
+};
+
 struct qup_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -112,9 +135,20 @@ struct qup_i2c_dev {
int in_fifo_sz;
int out_blk_sz;
int in_blk_sz;
-
+   int blocks;
+   u8  *block_tag_len;
+   int *block_data_len;
+   int block_pos;
unsigned long   one_byte_t;
 
+   int is_hs;
+   booluse_v2_tags;
+
+   int tx_tag_len;
+   int rx_tag_len;
+   u8  *tags;
+   int tags_pos;
+
struct i2c_msg  *msg;
/* Current posion in user message buffer */
int pos;
@@ -262,8 +296,13 @@ static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int 
op, bool val,
 
 static void qup_i2c_set_write_mode(struct qup_i2c_dev *qup, struct i2c_msg 
*msg)
 {
-   /* Number of entries to shift out, including the start */
-   int total = msg->len + 1;
+   /* Total Number of entries to shift out, including the tags */
+   int total;
+
+   if (qup->use_v2_tags)
+   total = msg->len + qup->tx_tag_len;
+   else
+   total = msg->len + 1; /* plus start tag */
 
if (total < qup->out_fifo_sz) {
/* FIFO mode */
@@ -277,7 +316,7 @@ static void qup_i2c_set_write_mode(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
}
 }
 
-static void qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static void qup_i2c_issue_write_v1(struct qup_i2c_dev *qup, struct i2c_msg 
*msg)
 {
u32 addr = msg->addr << 1;
u32 qup_tag;
@@ -318,6 +357,136 @@ static void qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
}
 }
 
+static void qup_i2c_create_tag_v2(struct qup_i2c_dev *qup,
+ struct i2c_msg *msg)
+{
+   u16 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
+   int len = 0, prev_len = 0;
+   int blocks = 0;
+   int rem;
+   int block_len = 0;
+   int data_len;
+
+  

[PATCH 6/6] dts: msm8974: Add dma channels for blsp2_i2c1 node

2015-03-13 Thread Sricharan R
Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 3f648ae..1ec7ec5 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -246,6 +246,8 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <&blsp2_dma 20>, <&blsp2_dma 21>;
+   dma-names = "bam-tx", "bam-rx";
};
 
blsp2_dma: dma@f9944000 {
-- 
1.8.2.1

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


[PATCH 0/6] i2c: qup: Add support for v2 tags and bam dma

2015-03-13 Thread Sricharan R
QUP from version 2.1.1 onwards, supports a new format of
i2c command tags. Tag codes instructs the controller to
perform a operation like read/write. This new tagging version
supports and is required for adding bam dma capabilities.
v2 tags supports transfer of more than 256 bytes in a single
i2c transaction. Also adding bam dma support facilitates
transferring each i2c_msg in i2c_msgs without a 'stop' bit
in between which is required for some of the clients.

This series depends on the below bam dma bug fix
 https://lkml.org/lkml/2015/2/20/47

Tested this series on apq8074 dragon board eeprom client
on i2c bus1

Andy Gross (1):
  i2c: qup: Add V2 tags support

Sricharan R (5):
  i2c: qup: Change qup_wait_writeready function to use for all timeouts
  i2c: qup: Add bam dma capabilities
  i2c: qup: Transfer every i2c_msg in i2c_msgs without stop
  dts: msm8974: Add blsp2_bam dma node
  dts: msm8974: Add dma channels for blsp2_i2c1 node

 arch/arm/boot/dts/qcom-msm8974.dtsi |  12 +
 drivers/i2c/busses/i2c-qup.c| 783 +---
 2 files changed, 741 insertions(+), 54 deletions(-)

-- 
1.8.2.1

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


Re: [PATCH v3 02/12] irqchip: nvic: support hierarchy irq domain

2015-03-13 Thread Maxime Coquelin
2015-03-13 0:36 GMT+01:00 Stefan Agner :
> Add support for hierarchy irq domain. Use to support the interrupt
> router found in Vybrid SoC, which is between the NVIC and the
> peripherals.
>
> Signed-off-by: Stefan Agner 
> ---
>  drivers/irqchip/irq-nvic.c | 28 +++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-nvic.c b/drivers/irqchip/irq-nvic.c
> index 4ff0805..5fac910 100644
> --- a/drivers/irqchip/irq-nvic.c
> +++ b/drivers/irqchip/irq-nvic.c
> @@ -49,6 +49,31 @@ nvic_handle_irq(irq_hw_number_t hwirq, struct pt_regs 
> *regs)
> handle_IRQ(irq, regs);
>  }
>
> +static int nvic_irq_domain_alloc(struct irq_domain *domain, unsigned int 
> virq,
> +   unsigned int nr_irqs, void *arg)
> +{
> +   int i, ret;
> +   irq_hw_number_t hwirq;
> +   unsigned int type = IRQ_TYPE_NONE;
> +   struct of_phandle_args *irq_data = arg;
> +
> +   ret = irq_domain_xlate_onecell(domain, irq_data->np, irq_data->args,
> +  irq_data->args_count, &hwirq, &type);
> +   if (ret)
> +   return ret;
> +
> +   for (i = 0; i < nr_irqs; i++)
> +   irq_map_generic_chip(domain, virq + i, hwirq + i);
> +
> +   return 0;
> +}
> +
> +static const struct irq_domain_ops nvic_irq_domain_ops = {
> +   .xlate = irq_domain_xlate_onecell,
> +   .alloc = nvic_irq_domain_alloc,

.alloc is only available with CONFIG_IRQ_DOMAIN_HIERARCHY=y, and it is
not selected by in the config ARM_NVIC entry.
It breaks the build with my STM32 series.

Once selected, the build is fine, and the board boots successfully.


Best regards,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 0/6] ARM: cpuidle: Unify the ARM64/ARM DT approach

2015-03-13 Thread Daniel Lezcano

On 03/13/2015 06:03 PM, Kevin Hilman wrote:

Daniel Lezcano  writes:


There is a big number of cpuidle drivers for the ARM architecture.

These drivers have been cleaned up and grouped into the drivers/cpuidle
directory to keep track of the changes more easily and ensure the code
is following the same scheme across the drivers.

That had the benefit of simplifying the code and factor out a lot of common
parts. Beside that, as the drivers belong to the 'drivers' directory, we had
to split the arch specific bits and the generic code in order to keep
everything self contained. The platform driver paradigm was used for this
purpose.

Unfortunately, this approach is now no longer accepted and a different solution
must be provided to reach the same goal: one example is the Qualcomm cpuidle
driver upstreaming attempt [1].

In the meantime, ARM64 developed a generic cpuidle driver based on DT 
definition.

The DT definition provides an 'enable-method' to specify one of the cpu
operations (PSCI, ...).

This patchset unify this driver with ARM32, using the same DT definition.

Thanks with this patchset we can use the 'enable-method' to specify a cpu
operations, hence get rid of the platform driver approach and go further in the
cpuidle driver flexibility via the DT.


I really like that these two are unified now.

Acked-by: Kevin Hilman 


Thanks for reviewing the patchset.

  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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


Re: [PATCH 0/6] ARM: cpuidle: Unify the ARM64/ARM DT approach

2015-03-13 Thread Kevin Hilman
Daniel Lezcano  writes:

> There is a big number of cpuidle drivers for the ARM architecture.
>
> These drivers have been cleaned up and grouped into the drivers/cpuidle
> directory to keep track of the changes more easily and ensure the code
> is following the same scheme across the drivers.
>
> That had the benefit of simplifying the code and factor out a lot of common
> parts. Beside that, as the drivers belong to the 'drivers' directory, we had
> to split the arch specific bits and the generic code in order to keep
> everything self contained. The platform driver paradigm was used for this
> purpose.
>
> Unfortunately, this approach is now no longer accepted and a different 
> solution
> must be provided to reach the same goal: one example is the Qualcomm cpuidle
> driver upstreaming attempt [1].
>
> In the meantime, ARM64 developed a generic cpuidle driver based on DT 
> definition.
>
> The DT definition provides an 'enable-method' to specify one of the cpu
> operations (PSCI, ...).
>
> This patchset unify this driver with ARM32, using the same DT definition.
>
> Thanks with this patchset we can use the 'enable-method' to specify a cpu
> operations, hence get rid of the platform driver approach and go further in 
> the
> cpuidle driver flexibility via the DT.

I really like that these two are unified now.

Acked-by: Kevin Hilman 

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


Re: [RFC 18/18] omap3isp: Deprecate platform data support

2015-03-13 Thread Tony Lindgren
* Sebastian Reichel  [150313 02:41]:
> Hi,
> 
> [+CC Tony]
> 
> On Sat, Mar 07, 2015 at 11:41:15PM +0200, Sakari Ailus wrote:
> > Print a warning when the driver is used with platform data. Existing
> > platform data user should move to DT now.
> 
> I guess this should become a more visible warning on OMAP SoC level,
> since platform data based boot will be deprecated completly.

Yeah. We should need platform data in addition to device tree data in
only very few cases. Basically only when there's some arch specific
callback function that needs to be passed to the driver.

Regards,

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


Re: [PATCH v4 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

2015-03-13 Thread Kumar Gala

On Mar 13, 2015, at 11:25 AM, Mark Rutland  wrote:

> On Fri, Mar 13, 2015 at 03:50:42PM +, Kumar Gala wrote:
>> 
>> On Mar 13, 2015, at 5:52 AM, Mark Rutland  wrote:
>> 
 +/ {
 +  chosen {
 +  stdout-path = &blsp1_uart2;
 +  };
>>> 
>>> It would be good if we had the configuration too (see
>>> Documentation/devicetree/bindings/chosen.txt), as that avoids any
>>> reliance on kernel defaults.
>>> 
>>> You can refer to an alias, so this could be:
>>> 
>>> aliases {
>>> serial0 = &blsp1_uart2;
>>> };
>>> 
>>> chosen {
>>> stdout-path = "serial0:115200n8";
>>> };
>>> 
>>> ...assuming that 115200n8 is correct for your UART, of course.
>>> 
>>> 
>>> […]
>> 
>> Where is the code that actually handles this parsing?  I’m not see it
>> in early_init_dt_scan_chosen_serial and I don’t believe
>> fdt_path_offset does anything special with ‘:'
> 
> Take a look at commit 7914a7c5651a5161 ("of: support passing console options 
> with
> stdout-path").
> 
> Early on of_alias_scan will find the options and in of_console_check
> we'll call add_preferred_console as appropriate. That'll be called in
> uart_add_one_port.

Ok, but earlycon dt code doesn’t utilize this, as its setup is before we 
unflatten the dt.

So it breaks earlycon parsing right now, I’ll look at fixing that.

- k

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


[PATCH 09/10] ARM: dt: dove: add video decoder power domain description

2015-03-13 Thread Russell King
Add the description of the video decoder power domain to the PMU DT
entry.

Signed-off-by: Russell King 
---
 arch/arm/boot/dts/dove.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 7e80407bdcf8..3dcf5322bf0e 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -387,6 +387,13 @@
interrupt-controller;
#interrupt-cells = <1>;
#reset-cells = <1>;
+
+   vpu_domain: vpu-domain {
+   #power-domain-cells = <0>;
+   marvell,pmu_pwr_mask = <0x0008>;
+   marvell,pmu_iso_mask = <0x0001>;
+   resets = <&pmu 16>;
+   };
};
 
thermal: thermal-diode@d001c {
-- 
1.8.3.1

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


[PATCH 10/10] ARM: dt: dove: add GPU power domain description

2015-03-13 Thread Russell King
Add the description of the GPU power domain to the PMU DT entry.

Signed-off-by: Russell King 
---
 arch/arm/boot/dts/dove.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 3dcf5322bf0e..d273552ada8a 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -394,6 +394,13 @@
marvell,pmu_iso_mask = <0x0001>;
resets = <&pmu 16>;
};
+
+   gpu_domain: gpu-domain {
+   #power-domain-cells = <0>;
+   marvell,pmu_pwr_mask = <0x0004>;
+   marvell,pmu_iso_mask = <0x0002>;
+   resets = <&pmu 18>;
+   };
};
 
thermal: thermal-diode@d001c {
-- 
1.8.3.1

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


[PATCH 08/10] ARM: dt: dove: wire up RTC interrupt

2015-03-13 Thread Russell King
Now that we have a PMU driver, we can wire up the RTC interrupt in the
DT description for Dove.

Signed-off-by: Russell King 
---
 arch/arm/boot/dts/dove.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 43d4ebf414be..7e80407bdcf8 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -624,6 +624,8 @@
rtc: real-time-clock@d8500 {
compatible = "marvell,orion-rtc";
reg = <0xd8500 0x20>;
+   interrupt-parent = <&pmu>;
+   interrupts = <5>;
};
 
gconf: global-config@e802c {
-- 
1.8.3.1

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


[PATCH 07/10] ARM: dt: dove: add Dove PMU DT entry to dove.dtsi

2015-03-13 Thread Russell King
Add the PMU description to the Dove DT file.  The PMU provides multiple
features, including an interrupt, reset, power and isolation controller.

Signed-off-by: Russell King 
---
 arch/arm/boot/dts/dove.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index a5441d5482a6..43d4ebf414be 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -380,6 +380,15 @@
status = "disabled";
};
 
+   pmu: power-management@d {
+   compatible = "marvell,dove-pmu";
+   reg = <0xd 0x8000>, <0xd8000 0x8000>;
+   interrupts = <33>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #reset-cells = <1>;
+   };
+
thermal: thermal-diode@d001c {
compatible = "marvell,dove-thermal";
reg = <0xd001c 0x0c>, <0xd005c 0x08>;
-- 
1.8.3.1

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


[PATCH 05/10] dt-bindings: add Marvell PMU documentation

2015-03-13 Thread Russell King
Add the required DT binding documentation for the Marvell PMU driver.

Signed-off-by: Russell King 
---
 Documentation/devicetree/bindings/soc/dove/pmu.txt | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/dove/pmu.txt

diff --git a/Documentation/devicetree/bindings/soc/dove/pmu.txt 
b/Documentation/devicetree/bindings/soc/dove/pmu.txt
new file mode 100644
index ..25d988e7ec35
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/dove/pmu.txt
@@ -0,0 +1,49 @@
+Device Tree bindings for Marvell PMU
+
+Required properties:
+ - compatible: value should be "marvell,dove-pmu".
+ - reg: two base addresses and sizes of the PM controller and PMU.
+ - interrupts: single interrupt number for the PMU interrupt
+ - interrupt-controller: must be specified as the PMU itself is an
+interrupt controller.
+ - #interrupt-cells: must be 1.
+ - #reset-cells: must be 1.
+
+Optional properties:
+ - None
+
+Power domain descriptions are listed as child nodes of the power management
+node.  Each domain has the following properties:
+
+Required properties:
+ - #power-domain-cells: must be 0.
+
+Optional properties:
+ - marvell,pmu_pwr_mask: specifies the mask value for PMU power register
+ - marvell,pmu_iso_mask: specifies the mask value for PMU isolation register
+ - resets: points to the reset manager (PMU node) and reset index.
+
+Example:
+
+   pmu: power-management@d {
+   compatible = "marvell,dove-pmu";
+   reg = <0xd 0x8000>, <0xd8000 0x8000>;
+   interrupts = <33>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   #reset-cells = <1>;
+
+   vpu_domain: vpu-domain {
+   #power-domain-cells = <0>;
+   marvell,pmu_pwr_mask = <0x0008>;
+   marvell,pmu_iso_mask = <0x0001>;
+   resets = <&pmu 16>;
+   };
+
+   gpu_domain: gpu-domain {
+   #power-domain-cells = <0>;
+   marvell,pmu_pwr_mask = <0x0004>;
+   marvell,pmu_iso_mask = <0x0002>;
+   resets = <&pmu 18>;
+   };
+   };
-- 
1.8.3.1

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


Re: [PATCH v4 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

2015-03-13 Thread Mark Rutland
On Fri, Mar 13, 2015 at 03:50:42PM +, Kumar Gala wrote:
> 
> On Mar 13, 2015, at 5:52 AM, Mark Rutland  wrote:
> 
> >> +/ {
> >> +  chosen {
> >> +  stdout-path = &blsp1_uart2;
> >> +  };
> > 
> > It would be good if we had the configuration too (see
> > Documentation/devicetree/bindings/chosen.txt), as that avoids any
> > reliance on kernel defaults.
> > 
> > You can refer to an alias, so this could be:
> > 
> > aliases {
> > serial0 = &blsp1_uart2;
> > };
> > 
> > chosen {
> > stdout-path = "serial0:115200n8";
> > };
> > 
> > ...assuming that 115200n8 is correct for your UART, of course.
> > 
> > 
> > […]
> 
> Where is the code that actually handles this parsing?  I’m not see it
> in early_init_dt_scan_chosen_serial and I don’t believe
> fdt_path_offset does anything special with ‘:'

Take a look at commit 7914a7c5651a5161 ("of: support passing console options 
with
stdout-path").

Early on of_alias_scan will find the options and in of_console_check
we'll call add_preferred_console as appropriate. That'll be called in
uart_add_one_port.

> I’ll kill off usage of skeleton.dtsi

Cheers.

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


[FOR DISCUSSION 0/10] Dove PMU support

2015-03-13 Thread Russell King - ARM Linux
This is the third re-posting of the patch set which I posted almost 11
months ago to support the Dove PMU, with a few additional changes.
This set is based upon 3.19.

In this set are:

* one patch which Rafael originally acked, but there was indecision
  last time around how to handle them due to potential conflicts with
  work that Ulf was doing.  This patches have been updated to apply
  cleanly to 3.19.  This patch should be applied anyway.

* factor out code which gets a validated generic PM domain, which we
  will make use of in later patches. (new)

* improve the validation of the generic PM domain pointer passed into
  pm_genpd_remove_device(). (updated)

* synchronise the state of the generic PM domain after a device is
  probed.  Other solutions may be possible, but require a larger
  patch series to resolve. (updated for patch 2)

* DT binding documentation for the Dove PMU driver, updated with
  comments from Rob.

* the addition of the core Dove PMU driver, which consists of a reset,
  IRQ controller, and power domains.  The reset and power domain code
  has to be closely related due to the power up/down requirements of
  the GPU/VPU subsystems needing to be performed atomically.  (This
  requirement prevents it using the MFD/syscon infrastructure, because
  we would need to hold spinlocks while calling several different
  sub-drivers.)  This currently needs to be available early on in the
  init sequence, so an explicit initialisation call is added to
  mach-mvebu to achieve this. (updated)

* addition of the RTC interrupt, so we can now receive and act on
  alarms generated by the Dove RTC.

* addition of the DT descriptions for the GPU and VPU power domains.
  These patches do not themselves add the DT descriptions for these
  units, so these patches serve as illustrations how these should be
  described.

 Documentation/devicetree/bindings/soc/dove/pmu.txt |  49 +++
 arch/arm/boot/dts/dove.dtsi|  25 ++
 arch/arm/mach-mvebu/Kconfig|   1 +
 arch/arm/mach-mvebu/dove.c |   2 +
 drivers/amba/bus.c |   4 +-
 drivers/base/platform.c|   2 +
 drivers/base/power/common.c|  15 +
 drivers/base/power/domain.c|  64 +++-
 drivers/i2c/i2c-core.c |   2 +
 drivers/soc/Makefile   |   1 +
 drivers/soc/dove/Makefile  |   1 +
 drivers/soc/dove/pmu.c | 406 +
 drivers/spi/spi.c  |   2 +
 include/linux/pm.h |   1 +
 include/linux/pm_domain.h  |   4 +
 include/linux/soc/dove/pmu.h   |   6 +
 16 files changed, 564 insertions(+), 21 deletions(-)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v6 4/4] ARM: dts: enable PCIe support for Cygnus

2015-03-13 Thread Florian Fainelli
On 11/03/15 11:06, Ray Jui wrote:
> Add PCIe device nodes in bcm-cygnus.dtsi but keep them disabled there.
> Only enable them for bcm958300k where PCIe interfaces are populated
> 
> Signed-off-by: Ray Jui 
> Reviewed-by: Scott Branden 

Applied to devicetree/next with Arnd's acked-by, thanks!
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH v5 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

2015-03-13 Thread Kumar Gala
Add initial device tree support for Qualcomm MSM8916 SoC and MTP8916
evaluation board.  At the current time we only boot up a single processor.

Signed-off-by: Kumar Gala 
---
v5:
* killed use of skeleton, moved to addr/size cells both being 2
* Added serial alias in prep of being able to spec uart params
  in chosen node

v4:
* Added chosen node so we dont need to spec everything for earlycon
* fixed up timer node to armv8, dropped clock-frequency

v3:
* Removed qcom,msm-id and qcom,board-id
* Added top level compat for "qcom,msm8916-mtp-smb1360"

v2:
* Updated to dropping CONFIG_ARCH_QCOM_MSM8916
* Updated to use qcom-ids.h

 arch/arm64/boot/dts/Makefile  |   1 +
 arch/arm64/boot/dts/qcom/Makefile |   5 +
 arch/arm64/boot/dts/qcom/msm8916-mtp.dts  |  21 
 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi |  32 +
 arch/arm64/boot/dts/qcom/msm8916.dtsi | 195 ++
 5 files changed, 254 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/Makefile
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8916.dtsi

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index e0350ca..8517f15 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -5,5 +5,6 @@ dts-dirs += cavium
 dts-dirs += exynos
 dts-dirs += freescale
 dts-dirs += mediatek
+dts-dirs += qcom
 
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/qcom/Makefile 
b/arch/arm64/boot/dts/qcom/Makefile
new file mode 100644
index 000..360ec4c
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_QCOM)+= msm8916-mtp.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dts 
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
new file mode 100644
index 000..784ad92
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dts
@@ -0,0 +1,21 @@
+/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License version 2 and
+* only version 2 as published by the Free Software Foundation.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*/
+
+/dts-v1/;
+
+#include "msm8916-mtp.dtsi"
+
+/ {
+   model = "Qualcomm Technologies, Inc. MSM 8916 MTP";
+   compatible = "qcom,msm8916-mtp", "qcom,msm8916-mtp-smb1360",
+   "qcom,msm8916", "qcom,mtp";
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
new file mode 100644
index 000..8dbb77f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-mtp.dtsi
@@ -0,0 +1,32 @@
+/* Copyright (c) 2014-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "msm8916.dtsi"
+
+/ {
+   aliases {
+   serial0 = &blsp1_uart2;
+   };
+
+   chosen {
+   stdout-path = "serial0";
+   };
+
+   soc {
+   serial@78b {
+   status = "okay";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <&blsp1_uart2_default>;
+   pinctrl-1 = <&blsp1_uart2_sleep>;
+   };
+   };
+};
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi 
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
new file mode 100644
index 000..45ceca6
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -0,0 +1,195 @@
+/* Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Qualcomm Technologies, Inc. MSM8916";
+   compatible = "qcom,msm8916";
+
+   interrupt

[GIT PULL] DeviceTree fixes for 4.0-rc

2015-03-13 Thread Rob Herring
Hi Linus,

Please pull DT fixes for 4.0. Details below.

Rob

The following changes since commit 9eccca0843205f87c00404b663188b88eb248051:

  Linux 4.0-rc3 (2015-03-08 16:09:09 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
tags/devicetree-fixes-for-4.0

for you to fetch changes up to a697c2efba03ac7bfdbffbba7f0f1aa294f7dee0:

  of/platform: Fix sparc:allmodconfig build (2015-03-13 09:45:24 -0500)


DeviceTree fixes for 4.0-rc:

- Fix for stdout-path option parsing with added unittest

- Fix for stdout-path interaction with earlycon

- Several DT unittest fixes

- Fix Sparc allmodconfig build error on
  of_platform_register_reconfig_notifier

- Several DT overlay kconfig and build warning fixes

- Several DT binding documentation updates


Arnd Bergmann (1):
  of: unittest: fix I2C dependency

Chunyan Zhang (1):
  Documentation: DT: Renamed of-serial.txt to 8250.txt

Fabio Estevam (1):
  of/overlay: Remove unused variable

Guenter Roeck (1):
  of/platform: Fix sparc:allmodconfig build

Leif Lindholm (1):
  of: fix handling of '/' in options for of_find_node_by_path()

Mark Brown (1):
  of/overlay: Directly include idr.h

Matt Porter (1):
  dt: submitting-patches: clarify that DT maintainers are to be
cced on bindings

Matwey V. Kornilov (2):
  of: Add prompt for OF_OVERLAY config
  of: Drop superfluous dependance for OF_OVERLAY

Michal Simek (1):
  of: Add vendor prefix for Arasan

Niklas Cassel (1):
  serial: add device tree binding documentation for ETRAX FS UART

Peter Hurley (2):
  of: Fix premature bootconsole disable with 'stdout-path'
  of: unittest: Add options string testcase variants

Rob Herring (1):
  Merge tag 'v4.0-rc3' into HEAD

Wang Long (2):
  of/unittest: remove the duplicate of_changeset_init
  of/unittest: Fix the wrong expected value in of_selftest_property_string

 .../bindings/serial/{of-serial.txt => 8250.txt}|  0
 .../bindings/serial/axis,etraxfs-uart.txt  | 19 +++
 .../devicetree/bindings/submitting-patches.txt |  3 +++
 .../devicetree/bindings/vendor-prefixes.txt|  2 ++
 drivers/of/Kconfig |  3 +--
 drivers/of/base.c  | 27 ++---
 drivers/of/overlay.c   |  3 ++-
 drivers/of/unittest.c  | 28 +++---
 include/linux/of_platform.h|  2 +-
 9 files changed, 65 insertions(+), 22 deletions(-)
 rename Documentation/devicetree/bindings/serial/{of-serial.txt =>
8250.txt} (100%)
 create mode 100644
Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables

2015-03-13 Thread Brian Norris
On Tue, Feb 24, 2015 at 09:41:10AM +, Lee Jones wrote:
> On Mon, 23 Feb 2015, Brian Norris wrote:
> > On Tue, Feb 10, 2015 at 03:46:34PM +0800, Lee Jones wrote:
> > > On Thu, 05 Feb 2015, Brian Norris wrote:

[snip other discussion]

> > Now, unless you were able to provide an additional enlightening
> > viewpoint, then the following paragraph likely all holds true:
> > 
> > > > Also, I realized that all this boot device / syscfg gymnastics is just
> > > > for one simple fact; your driver is trying to hide the fact that your
> > > > system can't reliably handle 4-byte addressing for the boot device. Even
> > > > if you try your best at toggling 4-byte addressing before/after each
> > > > read/write/erase, you still are vulnerable to power cuts during the
> > > > operation. This is a bad design, and we have consistently agreed that we
> > > > aren't going to work around that in Linux.
> > > > 
> > > > Better solutions: hook up a reset line to your flash; improve your boot
> > > > ROM / bootloader to handle 4-byte addressing for large flash.
> 
> Okay, I'm re-read the code and have a new understanding about the
> boot-from-spi 'gymnastics'. 

Great! See, much of that could be done by reading your own code (yeah,
yeah, not "yours"; but still) and honestly dealing with my questions,
rather than giving up and deferring to me or your MIA authorities. I'm
happy to return to technical points and avoid the other unpleasantness.

> There is a separate controller on the platform which acts as a boot
> device and makes the NOR chip appear as though it is memory mapped.
> This expects the NOR Controller to be in its default state [24-bit
> addressing] on boot.  The issue arises if a warm-reset occurs and the
> device is still in 32-bit addressing mode.

OK, this is all familiar. This is common to many other systems.

> To minimise the risk, the
> controller attempts to stay in 24-bit addressing mode for as long as
> possible.

This is the part where we differ, I suppose. The "as long as possible"
statement is still not sufficient; I believe this still leaves holes
that simply cannot be fixed in Linux.

> You mentioned power-cuts.  I do not believe this to be an issue, as
> when the power is completely removed the controller will reset back
> into default state.  Only warm-resets are an issue.

You're right: power cuts shouldn't be a problem. But what about other
unexpected warm resets? (Watchdogs?) Do you have any solution for them?

> > > > What's the possibility of dropping all this 4-byte address toggling
> > > > shenanigans? This will be a blocker to merging with spi-nor.c.
> 
> We wouldn't be able to remove this code without significantly
> weakening resilience to warm-reset mishaps, and changing the hardware
> design for devices which have already been released is obviously out
> of the question.

Then maybe we can't solve this. That doesn't mean that upstream will
support you, though.

Problems like this are why "release early, release often" makes sense.
If your employer didn't take the "fire the engineers and dump software
support to the community" approach, but rather honestly engaged on
driver support earlier, then perhaps your employer could have fixed the
SoCs/boot ROMs/board designs earlier, rather than later, and you
wouldn't be stuck trying to wedge in upstream workarounds for bad
designs in the wild.

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


Re: [PATCH v4 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

2015-03-13 Thread Kumar Gala

On Mar 13, 2015, at 5:52 AM, Mark Rutland  wrote:

>> +/ {
>> +chosen {
>> +stdout-path = &blsp1_uart2;
>> +};
> 
> It would be good if we had the configuration too (see
> Documentation/devicetree/bindings/chosen.txt), as that avoids any
> reliance on kernel defaults.
> 
> You can refer to an alias, so this could be:
> 
> aliases {
>   serial0 = &blsp1_uart2;
> };
> 
> chosen {
>   stdout-path = "serial0:115200n8";
> };
> 
> ...assuming that 115200n8 is correct for your UART, of course.
> 
> 
> […]

Where is the code that actually handles this parsing?  I’m not see it in 
early_init_dt_scan_chosen_serial and I don’t believe fdt_path_offset does 
anything special with ‘:'

> 
>> +#include "skeleton.dtsi"
> 
> I'd like to get rid of skeleton.dtsi; it causes more problems than it
> solves (the address/size cells mismatch is confusing and hidden, people
> forget to fill in memory nodes appropriately, etc).
> 
> Please remove this include and place appropriate #address-cells and 
> #size-cells here.
> 
> I'd strongly recommend going with /#size-cells = <2>; it' will save on a
> lot of pain if you need to add PCIe or something with large ranges
> later. If things all fall in 4GB within the SoC then have
> /soc/#size=cells = <1> and an appropriate /soc/ranges property.
> 
> I note this DT doesn't have any memory nodes. Is that an accident or
> does the loader fill that in?

it was coming out of skeleton.dtsi

> 
> If the latter, have an empty node with a comment to that effect.

I’ll kill off usage of skeleton.dtsi

- k
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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


Re: [PATCH v2 1/4] usb: renesas_usbhs: fix spinlock suspected in a gadget complete function

2015-03-13 Thread Felipe Balbi
Hi,

On Fri, Mar 13, 2015 at 01:14:01AM +, yoshihiro shimoda wrote:
> > > > diff --git a/drivers/usb/renesas_usbhs/mod_gadget.c 
> > > > b/drivers/usb/renesas_usbhs/mod_gadget.c
> > > > index e0384af77e56..e9d75d85be59 100644
> > > > --- a/drivers/usb/renesas_usbhs/mod_gadget.c
> > > > +++ b/drivers/usb/renesas_usbhs/mod_gadget.c
> > > > @@ -119,7 +119,7 @@ struct usbhsg_recip_handle {
> > > >  /*
> > > >   * queue push/pop
> > > >   */
> > > > -static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > > +static void __usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > >  struct usbhsg_request *ureq,
> > > >  int status)
> > > >  {
> > > > @@ -133,6 +133,15 @@ static void usbhsg_queue_pop(struct usbhsg_uep 
> > > > *uep,
> > > > usb_gadget_giveback_request(&uep->ep, &ureq->req);
> > > >  }
> > > >
> > > > +static void usbhsg_queue_pop(struct usbhsg_uep *uep,
> > > > +struct usbhsg_request *ureq,
> > > > +int status)
> > > > +{
> > > > +   usbhs_lock(priv, flags);
> > > > +   __usbhsg_queue_pop(uep, ureq, status);
> > > > +   usbhs_unlock(priv, flags);
> > > > +}
> > > > +
> > > >  static void usbhsg_queue_done(struct usbhs_priv *priv, struct 
> > > > usbhs_pkt *pkt)
> > > >  {
> > > > struct usbhs_pipe *pipe = pkt->pipe;
> > > >
> > > >
> > > > then, for cases where lock is already held you call __usbhsg_queue_pop()
> > > > and for all other cases, call usbhsg_queue_pop().
> > >
> > > Thank you for the suggestion. However, we cannot use this
> > > usbhsg_queue_pop() because a gadget driver might call usb_ep_queue()
> > > in the "complete" function and this driver calls usbhs_lock() in the
> > > usb_ep_queue().
> > 
> > right, in that case just call __usbhs_queue_pop() directly.
> 
> Yes. So, my understanding is that this driver always calls __usbhs_queue_pop()
> because this driver cannot know that a gadget driver calls usb_ep_queue() or 
> not
> in the "complete" function.

but you don't need to know that. All you have to do is spin_unlock()
before calling usb_gadget_giveback_request(), look at
drivers/usb/dwc3/gadget.c::dwc3_gadget_giveback()

> > > Perhaps my explanation was bad, but this issue was caused by the
> > > following conditions:
> > >  - I use the renesas_usbhs driver as udc.
> > >  - I use an old usb-dmac driver that the callback runs on a kthread.
> > >  - I use the ncm driver. In this environment, the ncm driver might
> > >   cause a spinlock suspected.
> > >
> > > As an old solution, I fixed the renesas_usbhs driver by this patch.
> > > However, if I use a new usb-dmac driver that the callback runs on a
> > > tasklet, I don't need this patch. (This is a new solution.)
> > 
> > then differentiate based on some revision register or something like
> > that ?
> 
> Sorry for the lack information. I am submitting this usb-dmac driver that
> the callback runs on a tasklet now. This means that the driver is not
> merged yet. So, I think that we don't need to differentiate.

But as soon as your driver gets merged, you will need to differentiate,
right ?

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCH] of/overlay: Remove unused variable

2015-03-13 Thread Rob Herring
On Tue, Mar 3, 2015 at 7:04 AM, Fabio Estevam
 wrote:
> Commit 3e7f7626fd49a ("of/overlay: Do not generate duplicate nodes") removed
> the only use of the 'grandchild' variable, which leads to the following build
> warning:
>
> drivers/of/overlay.c: In function 'of_overlay_apply_single_device_node':
> drivers/of/overlay.c:89:31: warning: unused variable 'grandchild' 
> [-Wunused-variable]
>   struct device_node *tchild, *grandchild;
>^
>
> Remove this unused variable.
>
> Signed-off-by: Fabio Estevam 

Applied for 4.0. Thanks.

Rob

> ---
>  drivers/of/overlay.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
> index 4066648..dee9270 100644
> --- a/drivers/of/overlay.c
> +++ b/drivers/of/overlay.c
> @@ -86,7 +86,7 @@ static int of_overlay_apply_single_device_node(struct 
> of_overlay *ov,
> struct device_node *target, struct device_node *child)
>  {
> const char *cname;
> -   struct device_node *tchild, *grandchild;
> +   struct device_node *tchild;
> int ret = 0;
>
> cname = kbasename(child->full_name);
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v6 5/6] ARM: dts: add wl12xx/wl18xx bindings

2015-03-13 Thread Tony Lindgren
* Eliad Peller  [150312 05:09]:
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
>  
> -static void __init omap3_evm_legacy_init(void)
> -{
> - legacy_init_wl12xx(3840, 0, 149);
> -}

FYI, at least this part conflicts with the fixes in the arm-soc
tree for the v4.0-rc series as omap3 evm also needs the copy clock
quirk.

> @@ -419,20 +351,9 @@ static struct pdata_init pdata_quirks[] __initdata = {
>   { "nokia,omap3-n950", hsmmc2_internal_input_clk, },
>   { "isee,omap3-igep0020-rev-f", omap3_igep0020_rev_f_legacy_init, },
>   { "isee,omap3-igep0030-rev-g", omap3_igep0030_rev_g_legacy_init, },
> - { "ti,omap3-evm-37xx", omap3_evm_legacy_init, },

So this function cannot be yet removed.

With that fixed, I was able to iw dev wlan0 scan with series on
omap3 evm :)

Regards,

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


Re: [PATCH] of: Fix premature bootconsole disable with 'stdout-path'

2015-03-13 Thread Rob Herring
On Sun, Mar 1, 2015 at 11:21 AM, Peter Hurley  wrote:
> Support for devicetree serial consoles via 'stdout-path' causes
> bootconsoles to be disabled when the vt dummy console loads, since
> there is no preferred console (the preferred console is not added
> until the device is probed).
>
> Ensure there is at least a preferred console, even if never matched.
>
> Requires: "console: Fix console name size mismatch"
> Cc: Andrew Morton 
> Signed-off-by: Peter Hurley 

Applied for 4.0. Thanks.

Rob

> ---
>  drivers/of/base.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 36536b6..83dc8a6 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1885,8 +1885,10 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 
> align))
> name = of_get_property(of_chosen, 
> "linux,stdout-path", NULL);
> if (IS_ENABLED(CONFIG_PPC) && !name)
> name = of_get_property(of_aliases, "stdout", NULL);
> -   if (name)
> +   if (name) {
> of_stdout = of_find_node_opts_by_path(name, 
> &of_stdout_options);
> +   add_preferred_console("stdout-path", 0, NULL);
> +   }
> }
>
> if (!of_aliases)
> --
> 2.3.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] of/selftest: remove the duplicate of_changeset_init

2015-03-13 Thread Rob Herring
On Mon, Mar 2, 2015 at 12:49 AM, Wang Long  wrote:
> Remove the duplicate of_changeset_init. In of_selftest_changeset
> testcase, the "struct of_changeset chgset" is initialized twice,
> but only once is enough. so, drop the first initializtion code.
>
> Signed-off-by: Wang Long 

Applied for 4.0. Thanks.

Rob

> ---
>  drivers/of/unittest.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 0cf9a23..199fb23 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -478,7 +478,6 @@ static void __init of_selftest_changeset(void)
> struct device_node *n1, *n2, *n21, *nremove, *parent, *np;
> struct of_changeset chgset;
>
> -   of_changeset_init(&chgset);
> n1 = __of_node_dup(NULL, "/testcase-data/changeset/n1");
> selftest(n1, "testcase setup failure\n");
> n2 = __of_node_dup(NULL, "/testcase-data/changeset/n2");
> --
> 1.8.3.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] of/unittest: Fix the wrong expected value in of_selftest_property_string

2015-03-13 Thread Rob Herring
On Mon, Mar 2, 2015 at 9:50 PM, Wang Long  wrote:
> This patch fix the wrong expected value of of_property_match_string
> in of_selftest_property_string.
>
> Signed-off-by: Wang Long 

Applied for 4.0. Thanks.

Rob

> ---
>  drivers/of/unittest.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 199fb23..00ddce7 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -378,9 +378,9 @@ static void __init of_selftest_property_string(void)
> rc = of_property_match_string(np, "phandle-list-names", "first");
> selftest(rc == 0, "first expected:0 got:%i\n", rc);
> rc = of_property_match_string(np, "phandle-list-names", "second");
> -   selftest(rc == 1, "second expected:0 got:%i\n", rc);
> +   selftest(rc == 1, "second expected:1 got:%i\n", rc);
> rc = of_property_match_string(np, "phandle-list-names", "third");
> -   selftest(rc == 2, "third expected:0 got:%i\n", rc);
> +   selftest(rc == 2, "third expected:2 got:%i\n", rc);
> rc = of_property_match_string(np, "phandle-list-names", "fourth");
> selftest(rc == -ENODATA, "unmatched string; rc=%i\n", rc);
> rc = of_property_match_string(np, "missing-property", "blah");
> --
> 1.8.3.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/2] of: Add prompt for OF_OVERLAY config

2015-03-13 Thread Rob Herring
On Mon, Feb 16, 2015 at 12:27 AM, Matwey V. Kornilov  wrote:
> Add prompt for OF_OVERLAY config option to make in visible in 
> menuconfig/xconfig
> to make user be able to set or unset this option.
>
> Signed-off-by: Matwey V. Kornilov 

Applied for 4.0. Thanks.

Rob

> ---
> Changes from v1:
>  - Explanation commit message has been added to 1/2
>  - Add 2/2 (drop depends on OF) as suggested by 
>
>  drivers/of/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index b5e0c87..fdca685 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -85,7 +85,7 @@ config OF_RESOLVE
> bool
>
>  config OF_OVERLAY
> -   bool
> +   bool "Device Tree overlays"
> depends on OF
> select OF_DYNAMIC
> select OF_RESOLVE
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 2/2] of: Drop superfluous dependance for OF_OVERLAY

2015-03-13 Thread Rob Herring
On Mon, Feb 16, 2015 at 12:27 AM, Matwey V. Kornilov  wrote:
> The whole menu already depends on OF, so there is no need to additionaly 
> specify it.
>
> Suggested-by: Paul Bolle 
> Signed-off-by: Matwey V. Kornilov 

Applied for 4.0. Thanks.

Rob

> ---
>  drivers/of/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index fdca685..4831137 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -86,7 +86,6 @@ config OF_RESOLVE
>
>  config OF_OVERLAY
> bool "Device Tree overlays"
> -   depends on OF
> select OF_DYNAMIC
> select OF_RESOLVE
>
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] of: Kconfig: Let OF_UNITTEST depend on "I2C=y" and "I2C_MUX=y"

2015-03-13 Thread Rob Herring
On Wed, Mar 4, 2015 at 1:49 PM, Arnd Bergmann  wrote:
> On Wednesday 04 March 2015 16:04:23 Geert Uytterhoeven wrote:
>> > -   depends on OF_IRQ && OF_EARLY_FLATTREE
>> > +   depends on OF_IRQ && OF_EARLY_FLATTREE && I2C=y && I2C_MUX=y
>>
>> ... I think it would be better to replace "#if IS_ENABLED(CONFIG_XXX)" by
>> "#ifdef CONFIG_XXX" in drivers/of/unittest.c instead.
>>
>
> Agreed. I came across the same bug and came to the same conclusion as you.
>
> How about this:
>
> 8<
> Subject: of: unittest: fix I2C dependency
>
> The unittest fails to link if I2C or I2C_MUX is a loadable module:
>
>   drivers/built-in.o: In function `selftest_i2c_mux_remove':
>   unittest.c:(.text+0xb0ce4): undefined reference to `i2c_del_mux_adapter'
>
> This changes the newly added IS_ENABLED() checks to use IS_BUILTIN()
> instead, which evaluates to false if the other driver is a module.
>
> Reported-by: Chen Gang 
> Signed-off-by: Arnd Bergmann 
> Fixes: d5e75500ca401 ("of: unitest: Add I2C overlay unit tests.")

Applied for 4.0. Thanks.

Rob

>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 0cf9a236d438..8daa49206c36 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -979,7 +979,7 @@ static int of_path_platform_device_exists(const char 
> *path)
> return pdev != NULL;
>  }
>
> -#if IS_ENABLED(CONFIG_I2C)
> +#if IS_BUILTIN(CONFIG_I2C)
>
>  /* get the i2c client device instantiated at the path */
>  static struct i2c_client *of_path_to_i2c_client(const char *path)
> @@ -1445,7 +1445,7 @@ static void of_selftest_overlay_11(void)
> return;
>  }
>
> -#if IS_ENABLED(CONFIG_I2C) && IS_ENABLED(CONFIG_OF_OVERLAY)
> +#if IS_BUILTIN(CONFIG_I2C) && IS_ENABLED(CONFIG_OF_OVERLAY)
>
>  struct selftest_i2c_bus_data {
> struct platform_device  *pdev;
> @@ -1584,7 +1584,7 @@ static struct i2c_driver selftest_i2c_dev_driver = {
> .id_table = selftest_i2c_dev_id,
>  };
>
> -#if IS_ENABLED(CONFIG_I2C_MUX)
> +#if IS_BUILTIN(CONFIG_I2C_MUX)
>
>  struct selftest_i2c_mux_data {
> int nchans;
> @@ -1695,7 +1695,7 @@ static int of_selftest_overlay_i2c_init(void)
> "could not register selftest i2c bus driver\n"))
> return ret;
>
> -#if IS_ENABLED(CONFIG_I2C_MUX)
> +#if IS_BUILTIN(CONFIG_I2C_MUX)
> ret = i2c_add_driver(&selftest_i2c_mux_driver);
> if (selftest(ret == 0,
> "could not register selftest i2c mux driver\n"))
> @@ -1707,7 +1707,7 @@ static int of_selftest_overlay_i2c_init(void)
>
>  static void of_selftest_overlay_i2c_cleanup(void)
>  {
> -#if IS_ENABLED(CONFIG_I2C_MUX)
> +#if IS_BUILTIN(CONFIG_I2C_MUX)
> i2c_del_driver(&selftest_i2c_mux_driver);
>  #endif
> platform_driver_unregister(&selftest_i2c_bus_driver);
> @@ -1814,7 +1814,7 @@ static void __init of_selftest_overlay(void)
> of_selftest_overlay_10();
> of_selftest_overlay_11();
>
> -#if IS_ENABLED(CONFIG_I2C)
> +#if IS_BUILTIN(CONFIG_I2C)
> if (selftest(of_selftest_overlay_i2c_init() == 0, "i2c init 
> failed\n"))
> goto out;
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] of: Add vendor prefix for Arasan

2015-03-13 Thread Rob Herring
On Thu, Feb 12, 2015 at 2:38 AM, Michal Simek  wrote:
> PATA(pata_arasan_cf.c) and SDHCI(sdhci-of-arasan.c) drivers
> are already using this prefix.
>
> Signed-off-by: Michal Simek 

Applied for 4.0. Thanks.

Rob

> ---
>
> https://arasan.com/contact/
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index b1df0ad1306c..7da04260a680 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -18,6 +18,7 @@ amlogic   Amlogic, Inc.
>  amsAMS AG
>  amstaosAMS-Taos Inc.
>  apmApplied Micro Circuits Corporation (APM)
> +arasan Arasan Chip Systems
>  armARM Ltd.
>  armadeus   ARMadeus Systems SARL
>  atmel  Atmel Corporation
> --
> 1.8.2.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH RESEND 2/2] serial: add device tree binding documentation for ETRAX FS UART

2015-03-13 Thread Rob Herring
On Wed, Feb 18, 2015 at 4:29 PM, Niklas Cassel  wrote:
> Signed-off-by: Niklas Cassel 
> ---
> [PATCH 1/2] of this patch series has already reached its way into mainline.
> It would be nice if someone picked up [PATCH 2/2] (this commit) before the 
> merge window closes.
>
>  .../devicetree/bindings/serial/axis,etraxfs-uart.txt  | 19 
> +++
>  Documentation/devicetree/bindings/vendor-prefixes.txt |  1 +
>  2 files changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt

Applied for 4.0. Thanks.

Rob

>
> diff --git a/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt 
> b/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt
> new file mode 100644
> index 000..ebcbb62
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt
> @@ -0,0 +1,19 @@
> +ETRAX FS UART
> +
> +Required properties:
> +- compatible : "axis,etraxfs-uart"
> +- reg: offset and length of the register set for the device.
> +- interrupts: device interrupt
> +
> +Optional properties:
> +- {dtr,dsr,ri,cd}-gpios: specify a GPIO for DTR/DSR/RI/CD
> +  line respectively.
> +
> +Example:
> +
> +serial@b0026 {
> +   compatible = "axis,etraxfs-uart";
> +   reg = <0xb0026000 0x1000>;
> +   interrupts = <68>;
> +   status = "disabled";
> +};
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index d6bad12..f8d088e 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -27,6 +27,7 @@ atmel Atmel Corporation
>  auoAU Optronics Corporation
>  avago  Avago Technologies
>  avic   Shanghai AVIC Optoelectronics Co., Ltd.
> +axis   Axis Communications AB
>  bosch  Bosch Sensortec GmbH
>  brcm   Broadcom Corporation
>  buffaloBuffalo, Inc.
> --
> 2.2.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 2/3] of: add optional options parameter to of_find_node_by_path()

2015-03-13 Thread Rob Herring
On Fri, Mar 6, 2015 at 12:59 PM, Peter Hurley  wrote:
> On 03/06/2015 01:11 PM, Peter Hurley wrote:
>> On 03/06/2015 11:52 AM, Leif Lindholm wrote:
>
> [...]
>
>>> Could you give the below a spin, and if it works for you, send me the
>>> above tests as a full patch so that I can post both as a series?
>>
>> Will do as soon as I finish testing.
>
> All passed with your patch; patch for testcases below.

Applied both for 4.0. Thanks.

Rob

>
> Regards,
> Peter Hurley
>
> --- >% ---
> From: Peter Hurley 
> Subject: [PATCH] of: unittest: Add options string testcase variants
>
> Add testcase variants with '/' in the options string to test for
> scan beyond end path name terminated by ':'.
>
> Signed-off-by: Peter Hurley 
> ---
>  drivers/of/unittest.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 0cf9a23..b2d7547 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -92,6 +92,11 @@ static void __init of_selftest_find_node_by_name(void)
>  "option path test failed\n");
> of_node_put(np);
>
> +   np = of_find_node_opts_by_path("/testcase-data:test/option", 
> &options);
> +   selftest(np && !strcmp("test/option", options),
> +"option path test, subcase #1 failed\n");
> +   of_node_put(np);
> +
> np = of_find_node_opts_by_path("/testcase-data:testoption", NULL);
> selftest(np, "NULL option path test failed\n");
> of_node_put(np);
> @@ -102,6 +107,12 @@ static void __init of_selftest_find_node_by_name(void)
>  "option alias path test failed\n");
> of_node_put(np);
>
> +   np = of_find_node_opts_by_path("testcase-alias:test/alias/option",
> +  &options);
> +   selftest(np && !strcmp("test/alias/option", options),
> +"option alias path test, subcase #1 failed\n");
> +   of_node_put(np);
> +
> np = of_find_node_opts_by_path("testcase-alias:testaliasoption", 
> NULL);
> selftest(np, "NULL option alias path test failed\n");
> of_node_put(np);
> --
> 2.3.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] dt: submitting-patches: clarify that DT maintainers are to be cced on bindings

2015-03-13 Thread Rob Herring
On Thu, Mar 5, 2015 at 9:53 AM, Matt Porter  wrote:
> The exact steps provided for submitting binding patches can be read
> as requiring the bindings to be sent only to the devicetree@vger.kernel.org
> list. Since the DT maintainers would like to be Cced on any binding
> submissions, make this requirement explicit in step 2.
>
> Signed-off-by: Matt Porter 

Applied for 4.0. Thanks.

Rob

> ---
>  Documentation/devicetree/bindings/submitting-patches.txt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/submitting-patches.txt 
> b/Documentation/devicetree/bindings/submitting-patches.txt
> index 56742bc..7d44eae 100644
> --- a/Documentation/devicetree/bindings/submitting-patches.txt
> +++ b/Documentation/devicetree/bindings/submitting-patches.txt
> @@ -12,6 +12,9 @@ I. For patch submitters
>
> devicetree@vger.kernel.org
>
> + and Cc: the DT maintainers. Use scripts/get_maintainer.pl to identify
> + all of the DT maintainers.
> +
>3) The Documentation/ portion of the patch should come in the series before
>   the code implementing the binding.
>
> --
> 1.8.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH -next] of/platform: Fix sparc:allmodconfig build

2015-03-13 Thread Rob Herring
On Tue, Mar 10, 2015 at 10:31 PM, Guenter Roeck  wrote:
> sparc:allmodconfig fails to build with:
>
> drivers/built-in.o: In function `platform_bus_init':
> (.init.text+0x3684): undefined reference to 
> `of_platform_register_reconfig_notifier'
>
> of_platform_register_reconfig_notifier is only declared if both OF_ADDRESS
> and OF_DYNAMIC are configured. Yet, the include file only declares a dummy
> function if OF_DYNAMIC is not configured. The sparc architecture does not
> configure OF_ADDRESS, but does configure OF_DYNAMIC, causing above error.
>
> Fixes: 801d728c10db ("of/reconfig: Add OF_DYNAMIC notifier for 
> platform_bus_type")
> Cc: Pantelis Antoniou 
> Signed-off-by: Guenter Roeck 

Applied for 4.0. Thanks.

Rob

> ---
>  include/linux/of_platform.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
> index 8a860f0..611a691 100644
> --- a/include/linux/of_platform.h
> +++ b/include/linux/of_platform.h
> @@ -84,7 +84,7 @@ static inline int of_platform_populate(struct device_node 
> *root,
>  static inline void of_platform_depopulate(struct device *parent) { }
>  #endif
>
> -#ifdef CONFIG_OF_DYNAMIC
> +#if defined(CONFIG_OF_DYNAMIC) && defined(CONFIG_OF_ADDRESS)
>  extern void of_platform_register_reconfig_notifier(void);
>  #else
>  static inline void of_platform_register_reconfig_notifier(void) { }
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

2015-03-13 Thread Tony Lindgren
* Eliad Peller  [150312 05:10]:
> Now that we have wlcore device-tree bindings in place
> (for both wl12xx and wl18xx), remove the legacy
> wl12xx_platform_data struct, and move its members
> into the platform device data (that is passed to wlcore)
> 
> Davinci 850 is the only platform that still set
> the platform data in the legacy way (and doesn't
> have DT bindings), so remove the relevant
> code/Kconfig option from the board file (as suggested
> by Sekhar Nori)
> 
> Signed-off-by: Luciano Coelho 
> Signed-off-by: Eliad Peller 
> ---
>  arch/arm/mach-davinci/Kconfig  |  11 ---
>  arch/arm/mach-davinci/board-da850-evm.c| 113 
> -
>  drivers/net/wireless/ti/wilink_platform_data.c |  25 --
>  drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
>  drivers/net/wireless/ti/wlcore/boot.c  |   1 -
>  drivers/net/wireless/ti/wlcore/main.c  |   4 +-
>  drivers/net/wireless/ti/wlcore/sdio.c  |  75 +---
>  drivers/net/wireless/ti/wlcore/wlcore_i.h  |   8 +-
>  include/linux/wl12xx.h |  25 --
>  9 files changed, 36 insertions(+), 245 deletions(-)

I got a build error related to the SPI driver with this series, probably
need to update this patch:

drivers/net/wireless/ti/wlcore/spi.c: In function ‘wl1271_probe’:
drivers/net/wireless/ti/wlcore/spi.c:334:11: error: ‘struct 
wlcore_platdev_data’ has no member named ‘pdata’
  pdev_data.pdata = dev_get_platdata(&spi->dev);
   ^
drivers/net/wireless/ti/wlcore/spi.c:335:16: error: ‘struct 
wlcore_platdev_data’ has no member named ‘pdata’
  if (!pdev_data.pdata) {

Regards,

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


Re: [PATCH] of/overlay: Directly include idr.h

2015-03-13 Thread Rob Herring
On Tue, Feb 17, 2015 at 3:33 AM, Mark Brown  wrote:
> On Tue, Feb 17, 2015 at 11:15:28AM +0200, Pantelis Antoniou wrote:
>> > providing the interface, instead relying on an implicit inclusion. Make
>> > the dependency implict to avoid potential future build issues if the
>
> s/implicit/explicit/

Applied with fixup for 4.0. Thanks.

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


Re: [PATCH v6 2/6] wl12xx: use frequency instead of enumerations for pdata clocks

2015-03-13 Thread Tony Lindgren
* Eliad Peller  [150312 05:09]:
> From: Luciano Coelho 
> 
> Instead of defining an enumeration with the FW specific values for the
> different clock rates, use the actual frequency instead.  Also add a
> boolean to specify whether the clock is XTAL or not.

Thanks for doing this. Just one comment on how we're going to get this
all merged. Chances are this will cause merge conflicts between the
wireless tree and the omap tree for the platform data and dts changes.

Can you please separate the wireless changes in this series so we can
do this in the following sets:

1. Add support for new things to wireless driver

2. Switch platform code to use the new support

3. Remove support for platform data with a follow-up patch

The other option would be to have the whole series in a immutable
branch against v3.0-rc1 that can be merged into both wirelss tree
and omap tree.

Regards,

Tony
 
> Change all board files to reflect this.
> 
> Signed-off-by: Luciano Coelho 
> [Eliad - small fixes, update board file changes]
> Signed-off-by: Eliad Peller 
> ---
>  arch/arm/mach-davinci/board-da850-evm.c |  3 +-
>  arch/arm/mach-omap2/pdata-quirks.c  | 29 
>  drivers/net/wireless/ti/wl12xx/main.c   | 60 
> ++---
>  drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +++
>  include/linux/wl12xx.h  | 27 ++-
>  5 files changed, 103 insertions(+), 44 deletions(-)
> 
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
> b/arch/arm/mach-davinci/board-da850-evm.c
> index 916589c..853b941 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -1386,7 +1386,8 @@ static const short da850_wl12xx_pins[] __initconst = {
>  static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
>   .irq= -1,
>   .irq_trigger= IRQ_TYPE_EDGE_RISING,
> - .board_ref_clock= WL12XX_REFCLOCK_38,
> + .ref_clock_freq = 3840,
> + .ref_clock_xtal = false,
>  };
>  
>  static __init int da850_wl12xx_init(void)
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
> b/arch/arm/mach-omap2/pdata-quirks.c
> index 4449f4c..337cc22 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -39,14 +39,14 @@ static struct twl4030_gpio_platform_data twl_gpio_auxdata;
>  
>  static struct wl12xx_platform_data wl12xx __initdata;
>  
> -static void __init __used legacy_init_wl12xx(unsigned ref_clock,
> -  unsigned tcxo_clock,
> +static void __init __used legacy_init_wl12xx(u32 ref_clock_freq,
> +  u32 tcxo_clock_freq,
>int gpio)
>  {
>   int res;
>  
> - wl12xx.board_ref_clock = ref_clock;
> - wl12xx.board_tcxo_clock = tcxo_clock;
> + wl12xx.ref_clock_freq = ref_clock_freq;
> + wl12xx.tcxo_clock_freq = tcxo_clock_freq;
>   wl12xx.irq = gpio_to_irq(gpio);
>   wl12xx.irq_trigger = IRQ_TYPE_LEVEL_HIGH;
>  
> @@ -57,8 +57,8 @@ static void __init __used legacy_init_wl12xx(unsigned 
> ref_clock,
>   }
>  }
>  #else
> -static inline void legacy_init_wl12xx(unsigned ref_clock,
> -   unsigned tcxo_clock,
> +static inline void legacy_init_wl12xx(u32 ref_clock_freq,
> +   u32 tcxo_clock_freq,
> int gpio)
>  {
>  }
> @@ -130,7 +130,7 @@ static void __init omap3_sbc_t3730_twl_init(void)
>  static void __init omap3_sbc_t3730_legacy_init(void)
>  {
>   omap3_sbc_t3x_usb_hub_init(167, "sb-t35 usb hub");
> - legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 136);
> + legacy_init_wl12xx(3840, 0, 136);
>  }
>  
>  static void __init omap3_sbc_t3530_legacy_init(void)
> @@ -174,12 +174,12 @@ static void __init 
> omap3_igep0030_rev_g_legacy_init(void)
>  
>  static void __init omap3_evm_legacy_init(void)
>  {
> - legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
> + legacy_init_wl12xx(3840, 0, 149);
>  }
>  
>  static void __init omap3_zoom_legacy_init(void)
>  {
> - legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
> + legacy_init_wl12xx(2600, 0, 162);
>  }
>  
>  static void am35xx_enable_emac_int(void)
> @@ -246,7 +246,7 @@ static void __init omap3_sbc_t3517_legacy_init(void)
>   am35xx_emac_reset();
>   hsmmc2_internal_input_clk();
>   omap3_sbc_t3517_wifi_init();
> - legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 145);
> + legacy_init_wl12xx(3840, 0, 145);
>  }
>  
>  static void __init am3517_evm_legacy_init(void)
> @@ -291,18 +291,17 @@ static void __init omap3_tao3530_legacy_init(void)
>  #ifdef CONFIG_ARCH_OMAP4
>  static void __init omap4_sdp_legacy_init(void)
>  {
> - legacy_init_wl12xx(WL12XX_REFCLOCK_26,
> -WL12XX_TCXOCLOCK_26, 53);
> + legacy_init_wl12xx(2600, 2600, 53);
>  }
>  
>

Re: [PATCH v3 10/15] serial: stm32-usart: Add STM32 USART Driver

2015-03-13 Thread Andy Shevchenko
On Thu, Mar 12, 2015 at 11:55 PM, Maxime Coquelin
 wrote:
> From: Maxime Coquelin 
>
> This drivers adds support to the STM32 USART controller, which is a
> standard serial driver.

My comment below.

>
> Signed-off-by: Maxime Coquelin 
> ---
>  drivers/tty/serial/Kconfig   |  17 +
>  drivers/tty/serial/Makefile  |   1 +
>  drivers/tty/serial/stm32-usart.c | 695 
> +++
>  include/uapi/linux/serial_core.h |   3 +
>  4 files changed, 716 insertions(+)
>  create mode 100644 drivers/tty/serial/stm32-usart.c
>
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index d2501f0..880cb4f 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -1611,6 +1611,23 @@ config SERIAL_SPRD_CONSOLE
>   with "earlycon" on the kernel command line. The console is
>   enabled when early_param is processed.
>
> +config SERIAL_STM32
> +   tristate "STMicroelectronics STM32 serial port support"
> +   select SERIAL_CORE
> +   depends on ARM || COMPILE_TEST
> +   help
> + This driver is for the on-chip Serial Controller on
> + STMicroelectronics STM32 MCUs.
> + USART supports Rx & Tx functionality.
> + It support all industry standard baud rates.
> +
> + If unsure, say N.
> +
> +config SERIAL_STM32_CONSOLE
> +   bool "Support for console on STM32"
> +   depends on SERIAL_STM32=y
> +   select SERIAL_CORE_CONSOLE
> +
>  endmenu
>
>  config SERIAL_MCTRL_GPIO
> diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
> index 599be4b..67c5023 100644
> --- a/drivers/tty/serial/Makefile
> +++ b/drivers/tty/serial/Makefile
> @@ -95,6 +95,7 @@ obj-$(CONFIG_SERIAL_FSL_LPUART)   += fsl_lpuart.o
>  obj-$(CONFIG_SERIAL_CONEXANT_DIGICOLOR)+= digicolor-usart.o
>  obj-$(CONFIG_SERIAL_MEN_Z135)  += men_z135_uart.o
>  obj-$(CONFIG_SERIAL_SPRD) += sprd_serial.o
> +obj-$(CONFIG_SERIAL_STM32) += stm32-usart.o
>
>  # GPIOLIB helpers for modem control lines
>  obj-$(CONFIG_SERIAL_MCTRL_GPIO)+= serial_mctrl_gpio.o
> diff --git a/drivers/tty/serial/stm32-usart.c 
> b/drivers/tty/serial/stm32-usart.c
> new file mode 100644
> index 000..61bb065
> --- /dev/null
> +++ b/drivers/tty/serial/stm32-usart.c
> @@ -0,0 +1,695 @@
> +/*
> + * Copyright (C) Maxime Coquelin 2015
> + * Author:  Maxime Coquelin 
> + * License terms:  GNU General Public License (GPL), version 2
> + *
> + * Inspired by st-asc.c from STMicroelectronics (c)
> + */
> +
> +#if defined(CONFIG_SERIAL_STM32_USART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
> +#define SUPPORT_SYSRQ
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME "stm32-usart"
> +
> +/* Register offsets */
> +#define USART_SR   0x00
> +#define USART_DR   0x04
> +#define USART_BRR  0x08
> +#define USART_CR1  0x0c
> +#define USART_CR2  0x10
> +#define USART_CR3  0x14
> +#define USART_GTPR 0x18
> +
> +/* USART_SR */
> +#define USART_SR_PEBIT(0)
> +#define USART_SR_FEBIT(1)
> +#define USART_SR_NFBIT(2)
> +#define USART_SR_ORE   BIT(3)
> +#define USART_SR_IDLE  BIT(4)
> +#define USART_SR_RXNE  BIT(5)
> +#define USART_SR_TCBIT(6)
> +#define USART_SR_TXE   BIT(7)
> +#define USART_SR_LBD   BIT(8)
> +#define USART_SR_CTS   BIT(9)
> +#define USART_SR_ERR_MASK  (USART_SR_LBD | USART_SR_ORE | \
> +USART_SR_FE | USART_SR_PE)
> +/* Dummy bits */
> +#define USART_SR_DUMMY_RX  BIT(16)
> +
> +/* USART_DR */
> +#define USART_DR_MASK  GENMASK(8, 0)
> +
> +/* USART_BRR */
> +#define USART_BRR_DIV_F_MASK   GENMASK(3, 0)
> +#define USART_BRR_DIV_M_MASK   GENMASK(15, 4)
> +#define USART_BRR_DIV_M_SHIFT  4
> +
> +/* USART_CR1 */
> +#define USART_CR1_SBK  BIT(0)
> +#define USART_CR1_RWU  BIT(1)
> +#define USART_CR1_RE   BIT(2)
> +#define USART_CR1_TE   BIT(3)
> +#define USART_CR1_IDLEIE   BIT(4)
> +#define USART_CR1_RXNEIE   BIT(5)
> +#define USART_CR1_TCIE BIT(6)
> +#define USART_CR1_TXEIEBIT(7)
> +#define USART_CR1_PEIE BIT(8)
> +#define USART_CR1_PS   BIT(9)
> +#define USART_CR1_PCE  BIT(10)
> +#define USART_CR1_WAKE BIT(11)
> +#define USART_CR1_MBIT(12)
> +#define USART_CR1_UE   BIT(13)
> +#define USART_CR1_OVER8BIT(15)
> +#define USART_CR1_IE_MASK  GENMASK(8, 4)
> +
> +/* USART_CR2 */
> +#define USART_CR2_ADD_MASK GENMASK(3, 0)
> +#define USART_CR2_LBDL BIT(5)
> +#define USART_CR2_LBDIEBIT(6)
> +#define USART_CR2_LBCL BIT(8)
> +#define USART_CR2_CPHA   

Re: [PATCH v3 07/12] ARM: imx: depend MXC debug board on 3DS machines

2015-03-13 Thread Shawn Guo
On Fri, Mar 13, 2015 at 12:36:15AM +0100, Stefan Agner wrote:
> Depend the MXC debug board on machines which actually support it.
> 
> Signed-off-by: Stefan Agner 

Applied, thanks.

> ---
>  arch/arm/mach-imx/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index c8dffce..d21cb9a 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -21,6 +21,7 @@ config MXC_AVIC
>  
>  config MXC_DEBUG_BOARD
>   bool "Enable MXC debug board(for 3-stack)"
> + depends on MACH_MX27_3DS || MACH_MX31_3DS || MACH_MX35_3DS
>   help
> The debug board is an integral part of the MXC 3-stack(PDK)
> platforms, it can be attached or removed from the peripheral
> -- 
> 2.3.1
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 0/3] imx: add max7310 and usb support for imx6qdl sabreauto

2015-03-13 Thread Shawn Guo
On Fri, Mar 13, 2015 at 02:21:41PM +0800, Peter Chen wrote:
> Peter Chen (3):
>   ARM: imx6qdl-sabreauto.dtsi: add max7310 support
>   ARM: imx6qdl-sabreauto.dtsi: enable USB support
>   ARM: imx_v6_v7_defconfig: Add CONFIG_GPIO_PCA953X

Applied all, thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Patch v3 1/3] dt: OF_UNITTEST make dependency broken, framework fixes

2015-03-13 Thread Rob Herring
On Thu, Mar 12, 2015 at 8:15 AM, Frank Rowand  wrote:
> From: Frank Rowand 
>
> This 3 patch series is not bisectable.  If CONFIG_OF_UNITTEST=y then the 
> kernel
> will not build with just patch 1 or just patches 1 and 2 applied.

If you did 2 patches with the move first, wouldn't that make it
bisectable. However, I'd rather avoid the move.

> If CONFIG_OF_UNITTEST=y then a kernel image make will always cause .version to
> be incremented, even if there are not source changes.  This is caused by
> a lack of dependency tracking and checking for
> drivers/of/unittest-data/testcases.dtb.o.  Fixing the problem was made more
> complicated by the fact that testcases.dtb.o was linked into ../of_unittest.o.

Couldn't we change that to be 2 modules.

> Patch 1 modifies makefiles to move of_unittest.c into unittest-data/ and
> creates missing dependency tracking for testcases.dtb.o.
>
> Patch 2 will move of_unittest.c into unittest-data/
>
> Patch 3 will fix an of_unittest.c include path to account for the move.

This should all be in an intro email, not patch #1.

Rob

>
> Signed-off-by: Frank Rowand 
>
> ---
>
> changes since version 2:
>
>   patch 1:
>   Add .gitignore so that generated files will not get committed.
>
> changes since version 1:
>
>   patch 1:
>   Remove some changes to scripts/Makefile.lib that are not needed.  They
>   were left over from attempts to fix the problem without moving of_unitest.c
>   into unittest-data/.
>
>
>  drivers/of/Makefile |4 ++--
>  drivers/of/unittest-data/.gitignore |2 ++
>  drivers/of/unittest-data/Makefile   |9 +
>  3 files changed, 13 insertions(+), 2 deletions(-)
>
> Index: b/drivers/of/Makefile
> ===
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -6,8 +6,6 @@ obj-$(CONFIG_OF_PROMTREE) += pdt.o
>  obj-$(CONFIG_OF_ADDRESS)  += address.o
>  obj-$(CONFIG_OF_IRQ)+= irq.o
>  obj-$(CONFIG_OF_NET)   += of_net.o
> -obj-$(CONFIG_OF_UNITTEST) += of_unittest.o
> -of_unittest-objs := unittest.o unittest-data/testcases.dtb.o
>  obj-$(CONFIG_OF_MDIO)  += of_mdio.o
>  obj-$(CONFIG_OF_PCI)   += of_pci.o
>  obj-$(CONFIG_OF_PCI_IRQ)  += of_pci_irq.o
> @@ -16,5 +14,7 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_rese
>  obj-$(CONFIG_OF_RESOLVE)  += resolver.o
>  obj-$(CONFIG_OF_OVERLAY) += overlay.o
>
> +obj-$(CONFIG_OF_UNITTEST) += unittest-data/
> +
>  CFLAGS_fdt.o = -I$(src)/../../scripts/dtc/libfdt
>  CFLAGS_fdt_address.o = -I$(src)/../../scripts/dtc/libfdt
> Index: b/drivers/of/unittest-data/Makefile
> ===
> --- /dev/null
> +++ b/drivers/of/unittest-data/Makefile
> @@ -0,0 +1,9 @@
> +
> +obj-$(CONFIG_OF_UNITTEST) += of_unittest.o
> +of_unittest-objs := unittest.o testcases.dtb.o
> +
> +targets += testcases.dtb testcases.dtb.S
> +
> +.SECONDARY: \
> +   $(obj)/testcases.dtb.S \
> +   $(obj)/testcases.dtb
> Index: b/drivers/of/unittest-data/.gitignore
> ===
> --- /dev/null
> +++ b/drivers/of/unittest-data/.gitignore
> @@ -0,0 +1,2 @@
> +testcases.dtb
> +testcases.dtb.S
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [FOR DISCUSSION 0/9] Dove PMU support

2015-03-13 Thread Arnd Bergmann
On Friday 13 March 2015 12:32:11 Russell King - ARM Linux wrote:
> On Fri, Mar 13, 2015 at 01:26:17PM +0100, Arnd Bergmann wrote:
> > On Friday 13 March 2015 12:11:27 Russell King - ARM Linux wrote:
> > > Of course, I also have a patch which adds legacy support to
> > > arch/arm/mach-dove, but I've assumed you're not interested in that...
> > 
> > You mean legacy support in mach-mvebu?
> 
> No.
> 
> As you'll see, this uses a platform device notifier to hook the devices
> onto the appropriate PM domain, which is why the driver needs to be
> registered early.  This also gets used in DT mode with one legacy
> platform device which is dynamically registered (something which can't
> happen with DT.)

Ok, got it. I think that's fine too. If this helps you spend less
time on forward-porting your patches and in turn completing the
full dove support with DT faster, I'm all for merging this one too.

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


Re: [PATCH 6/9] ARM: dt: dove: add Dove PMU DT entry to dove.dtsi

2015-03-13 Thread Russell King - ARM Linux
On Fri, Mar 13, 2015 at 01:30:38PM +0100, Thomas Petazzoni wrote:
> Dear Russell King,
> 
> On Thu, 12 Mar 2015 18:31:21 +, Russell King wrote:
> 
> > +   pmu: power-management@d {
> > +   compatible = "marvell,dove-pmu";
> > +   reg = <0xd 0x8000>, <0xd8000 0x8000>;
> 
> If I'm not wrong, the registers of the RTC are at 0xd8500, which is
> also covered by this new pmu node. It does work because you're using
> of_iomap(), but it isn't really ideal.
> 
> Maybe some sort of syscon/regmap thing should be used?

Please look at the locking that would require and the locking required
for PM domains (and as I've previously explained, apparently the hardware
requires a specific sequence of writes.)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [FOR DISCUSSION 0/9] Dove PMU support

2015-03-13 Thread Russell King - ARM Linux
On Fri, Mar 13, 2015 at 01:26:17PM +0100, Arnd Bergmann wrote:
> On Friday 13 March 2015 12:11:27 Russell King - ARM Linux wrote:
> > On Fri, Mar 13, 2015 at 12:57:11PM +0100, Arnd Bergmann wrote:
> > > On Thursday 12 March 2015 18:30:21 Russell King - ARM Linux wrote:
> > > >  Documentation/devicetree/bindings/soc/dove/pmu.txt |  49 +++
> > > >  arch/arm/boot/dts/dove.dtsi|  25 ++
> > > >  arch/arm/mach-mvebu/Kconfig|   1 +
> > > >  drivers/base/platform.c|   2 +
> > > >  drivers/base/power/common.c|  15 +
> > > >  drivers/base/power/domain.c|  33 +-
> > > >  drivers/soc/Makefile   |   1 +
> > > >  drivers/soc/dove/Makefile  |   1 +
> > > >  drivers/soc/dove/pmu.c | 399 
> > > > +
> > > >  include/linux/pm.h |   1 +
> > > >  include/linux/pm_domain.h  |   4 +
> > > >  include/linux/soc/dove/pmu.h   |   6 +
> > > >  12 files changed, 532 insertions(+), 5 deletions(-)
> > > 
> > > I see add the header file and the global dove_init_pmu() function,
> > > but I don't see a caller of that function. Is that intentional, or
> > > did you accidentally leave out another patch that you meant to include?
> > 
> > I kind'a did - it needs an explicit call from arch/arm/mach-mvebu/dove.c
> > which I haven't added even in my tree (because I don't use that path,
> > even when I test DT booting - I still use most of the arch/arm/mach-dove
> > code when DT booting.)  I'll add that now.
> > 
> > Of course, I also have a patch which adds legacy support to
> > arch/arm/mach-dove, but I've assumed you're not interested in that...
> 
> You mean legacy support in mach-mvebu?

No.

As you'll see, this uses a platform device notifier to hook the devices
onto the appropriate PM domain, which is why the driver needs to be
registered early.  This also gets used in DT mode with one legacy
platform device which is dynamically registered (something which can't
happen with DT.)

 arch/arm/Kconfig |  1 +
 arch/arm/mach-dove/common.c  | 25 ++
 arch/arm/mach-dove/include/mach/pm.h | 17 ---
 arch/arm/mach-dove/irq.c | 87 
 drivers/soc/Makefile |  1 +
 drivers/soc/dove/pmu.c   | 97 
 include/linux/soc/dove/pmu.h | 18 +++
 7 files changed, 142 insertions(+), 104 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97d07ed60a0b..08e7608d1c52 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -519,6 +519,7 @@ config ARCH_DOVE
select PINCTRL
select PINCTRL_DOVE
select PLAT_ORION_LEGACY
+   select PM_GENERIC_DOMAINS if PM
help
  Support for the Marvell Dove SoC 88AP510
 
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 0d1a89298ece..6f3887217674 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -375,6 +376,29 @@ void __init dove_setup_cpu_wins(void)
DOVE_SCRATCHPAD_SIZE);
 }
 
+static const struct dove_pmu_domain_initdata pmu_domains[] __initconst = {
+   {
+   .pwr_mask = PMU_PWR_VPU_PWR_DWN_MASK,
+   .rst_mask = PMU_SW_RST_VIDEO_MASK,
+   .iso_mask = PMU_ISO_VIDEO_MASK,
+   .name = "vpu-domain",
+   }, {
+   .pwr_mask = PMU_PWR_GPU_PWR_DWN_MASK,
+   .rst_mask = PMU_SW_RST_GPU_MASK,
+   .iso_mask = PMU_ISO_GPU_MASK,
+   .name = "gpu-domain",
+   }, {
+   /* sentinel */
+   },
+};
+
+static const struct dove_pmu_initdata pmu_data __initconst = {
+   .pmc_base = DOVE_PMU_VIRT_BASE,
+   .pmu_base = DOVE_PMU_VIRT_BASE + 0x8000,
+   .irq = IRQ_DOVE_PMU,
+   .domains = pmu_domains,
+};
+
 void __init dove_init(void)
 {
pr_info("Dove 88AP510 SoC, TCLK = %d MHz.\n",
@@ -389,6 +413,7 @@ void __init dove_init(void)
dove_clk_init();
 
/* internal devices that every board has */
+   dove_init_pmu_legacy(&pmu_data);
dove_rtc_init();
dove_xor0_init();
dove_xor1_init();
diff --git a/arch/arm/mach-dove/include/mach/pm.h 
b/arch/arm/mach-dove/include/mach/pm.h
index b47f75038686..625a89c15c1f 100644
--- a/arch/arm/mach-dove/include/mach/pm.h
+++ b/arch/arm/mach-dove/include/mach/pm.h
@@ -51,22 +51,5 @@
 #define  CLOCK_GATING_GIGA_PHY_MASK(1 << CLOCK_GATING_BIT_GIGA_PHY)
 
 #define PMU_INTERRUPT_CAUSE(DOVE_PMU_VIRT_BASE + 0x50)
-#define PMU_INTERRUPT_MASK (DOVE_PMU_VIRT_BASE + 0x54)
-
-static inline int pmu_to_irq(int pin)
-{
-   if (pin < NR_PMU_IRQS)
- 

Re: [PATCH 6/9] ARM: dt: dove: add Dove PMU DT entry to dove.dtsi

2015-03-13 Thread Thomas Petazzoni
Dear Russell King,

On Thu, 12 Mar 2015 18:31:21 +, Russell King wrote:

> + pmu: power-management@d {
> + compatible = "marvell,dove-pmu";
> + reg = <0xd 0x8000>, <0xd8000 0x8000>;

If I'm not wrong, the registers of the RTC are at 0xd8500, which is
also covered by this new pmu node. It does work because you're using
of_iomap(), but it isn't really ideal.

Maybe some sort of syscon/regmap thing should be used?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [FOR DISCUSSION 0/9] Dove PMU support

2015-03-13 Thread Arnd Bergmann
On Friday 13 March 2015 12:11:27 Russell King - ARM Linux wrote:
> On Fri, Mar 13, 2015 at 12:57:11PM +0100, Arnd Bergmann wrote:
> > On Thursday 12 March 2015 18:30:21 Russell King - ARM Linux wrote:
> > >  Documentation/devicetree/bindings/soc/dove/pmu.txt |  49 +++
> > >  arch/arm/boot/dts/dove.dtsi|  25 ++
> > >  arch/arm/mach-mvebu/Kconfig|   1 +
> > >  drivers/base/platform.c|   2 +
> > >  drivers/base/power/common.c|  15 +
> > >  drivers/base/power/domain.c|  33 +-
> > >  drivers/soc/Makefile   |   1 +
> > >  drivers/soc/dove/Makefile  |   1 +
> > >  drivers/soc/dove/pmu.c | 399 
> > > +
> > >  include/linux/pm.h |   1 +
> > >  include/linux/pm_domain.h  |   4 +
> > >  include/linux/soc/dove/pmu.h   |   6 +
> > >  12 files changed, 532 insertions(+), 5 deletions(-)
> > 
> > I see add the header file and the global dove_init_pmu() function,
> > but I don't see a caller of that function. Is that intentional, or
> > did you accidentally leave out another patch that you meant to include?
> 
> I kind'a did - it needs an explicit call from arch/arm/mach-mvebu/dove.c
> which I haven't added even in my tree (because I don't use that path,
> even when I test DT booting - I still use most of the arch/arm/mach-dove
> code when DT booting.)  I'll add that now.
> 
> Of course, I also have a patch which adds legacy support to
> arch/arm/mach-dove, but I've assumed you're not interested in that...

You mean legacy support in mach-mvebu?

I don't mind that at all, it was the mvebu maintainers that decided
it would be best to combine the multiplatform and DT work in order
to simplify both. I've also sent a patch set that moves mach-dove
into multiplatform, which is a different way of doing the same thing.

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


Re: [FOR DISCUSSION 0/9] Dove PMU support

2015-03-13 Thread Russell King - ARM Linux
On Fri, Mar 13, 2015 at 12:57:11PM +0100, Arnd Bergmann wrote:
> On Thursday 12 March 2015 18:30:21 Russell King - ARM Linux wrote:
> > This is a re-posting of the patch set which I posted almost 10 months
> > ago to support the Dove PMU, with a few additional changes.  This set
> > is based upon 3.19.
> > 
> > In this set are:
> > 
> > * two patches which Rafael originally acked, but there was indecision
> >   last time around how to handle them due to potential conflicts with
> >   work that Ulf was doing.  These patches have been updated to apply
> >   cleanly to 3.19.  I don't know if people want to take these as
> >   fixes to the PM domain code or not (hence why I'm posting this
> >   series during the merge window - if it weren't for this, I'd hold
> >   it off.)
> 
> I don't seem to have received the first three patches for some reason.
> Can you check if you got them back from the mailing list?

That's because you're not listed as the maintainer for PM domain stuff,
and I forgot to ensure lakml was copied on all patches.

> >  Documentation/devicetree/bindings/soc/dove/pmu.txt |  49 +++
> >  arch/arm/boot/dts/dove.dtsi|  25 ++
> >  arch/arm/mach-mvebu/Kconfig|   1 +
> >  drivers/base/platform.c|   2 +
> >  drivers/base/power/common.c|  15 +
> >  drivers/base/power/domain.c|  33 +-
> >  drivers/soc/Makefile   |   1 +
> >  drivers/soc/dove/Makefile  |   1 +
> >  drivers/soc/dove/pmu.c | 399 
> > +
> >  include/linux/pm.h |   1 +
> >  include/linux/pm_domain.h  |   4 +
> >  include/linux/soc/dove/pmu.h   |   6 +
> >  12 files changed, 532 insertions(+), 5 deletions(-)
> 
> I see add the header file and the global dove_init_pmu() function,
> but I don't see a caller of that function. Is that intentional, or
> did you accidentally leave out another patch that you meant to include?

I kind'a did - it needs an explicit call from arch/arm/mach-mvebu/dove.c
which I haven't added even in my tree (because I don't use that path,
even when I test DT booting - I still use most of the arch/arm/mach-dove
code when DT booting.)  I'll add that now.

Of course, I also have a patch which adds legacy support to
arch/arm/mach-dove, but I've assumed you're not interested in that...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v3 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

2015-03-13 Thread Catalin Marinas
On Fri, Mar 13, 2015 at 10:34:54AM +, Mark Rutland wrote:
> > > Which of spin-table/psci are you planning on using for SMP support, and
> > > when would that be likely to appear?
> > 
> > We have a qcom specific SMP enablement method for this device.  This
> > was one of our first devices so it utilized as much from arm 32-bit as
> > possible.
> 
> Implementation specific enable methods are something we really don't
> want to see for arm64.

I fully agree (and we've been stating this for over two years).

> If PSCI is out of the question then a spin-table shim in your
> bootloader shouldn't be too hard to implement.

And I guess only WFI cpuidle supported in Linux.

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


Re: [PATCH 4/9] dt-bindings: add Marvell PMU documentation

2015-03-13 Thread Arnd Bergmann
On Thursday 12 March 2015 18:31:10 Russell King wrote:
> Add the required DT binding documentation for the Marvell PMU driver.
> 
> Signed-off-by: Russell King 
> 

The binding and DT nodes look ok to me, I'm definitely fine
with taking those through the arm-soc tree, regardless of how
we merge the other changes. The actual driver should probably
go the same way, unless you want to put them in a branch with
the drivers/base changes and have them merged through Rafael's
tree.

Who is picking up patches for mach-dove at the moment? I
know that Gregory Clement has taken over the mvebu git tree
from Jason for the time being, but he's not listed as a maintainer
for dove/mv78xx0/orion and wasn't on Cc to these mails as a
consequence (I've added him for the discussion here).

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


Re: [FOR DISCUSSION 0/9] Dove PMU support

2015-03-13 Thread Arnd Bergmann
On Thursday 12 March 2015 18:30:21 Russell King - ARM Linux wrote:
> This is a re-posting of the patch set which I posted almost 10 months
> ago to support the Dove PMU, with a few additional changes.  This set
> is based upon 3.19.
> 
> In this set are:
> 
> * two patches which Rafael originally acked, but there was indecision
>   last time around how to handle them due to potential conflicts with
>   work that Ulf was doing.  These patches have been updated to apply
>   cleanly to 3.19.  I don't know if people want to take these as
>   fixes to the PM domain code or not (hence why I'm posting this
>   series during the merge window - if it weren't for this, I'd hold
>   it off.)

I don't seem to have received the first three patches for some reason.
Can you check if you got them back from the mailing list?

> 
>  Documentation/devicetree/bindings/soc/dove/pmu.txt |  49 +++
>  arch/arm/boot/dts/dove.dtsi|  25 ++
>  arch/arm/mach-mvebu/Kconfig|   1 +
>  drivers/base/platform.c|   2 +
>  drivers/base/power/common.c|  15 +
>  drivers/base/power/domain.c|  33 +-
>  drivers/soc/Makefile   |   1 +
>  drivers/soc/dove/Makefile  |   1 +
>  drivers/soc/dove/pmu.c | 399 
> +
>  include/linux/pm.h |   1 +
>  include/linux/pm_domain.h  |   4 +
>  include/linux/soc/dove/pmu.h   |   6 +
>  12 files changed, 532 insertions(+), 5 deletions(-)

I see add the header file and the global dove_init_pmu() function,
but I don't see a caller of that function. Is that intentional, or
did you accidentally leave out another patch that you meant to include?

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


Re: [PATCH 2/2] Documentation: omap-twl4030: Remove ti,codec property

2015-03-13 Thread Belisko Marek
On Fri, Mar 13, 2015 at 12:48 PM, Peter Ujfalusi  wrote:
> On 03/13/2015 01:05 PM, Arnd Bergmann wrote:
>> On Thursday 12 March 2015 22:14:59 Marek Belisko wrote:
>>> diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt 
>>> b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
>>> index 1ab6bc8..656165f 100644
>>> --- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
>>> +++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
>>> @@ -4,7 +4,6 @@ Required properties:
>>>  - compatible: "ti,omap-twl4030"
>>>  - ti,model: Name of the sound card (for example "omap3beagle")
>>>  - ti,mcbsp: phandle for the McBSP node
>>> -- ti,codec: phandle for the twl4030 audio node
>>
>> As this was a required property, are you sure that no other operating system
>> uses it?
>>
>> Even if not, you should probably change it to be an optional property, so
>> that the existing dtbs do not become noncompliant after the change.
>
> After I sent my Ack, I also started to think about the same thing. It is
> better to change it to optional.
OK will do and post v2. Thanks.
>
> --
> Péter

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 2/2] Documentation: omap-twl4030: Remove ti,codec property

2015-03-13 Thread Peter Ujfalusi
On 03/13/2015 01:05 PM, Arnd Bergmann wrote:
> On Thursday 12 March 2015 22:14:59 Marek Belisko wrote:
>> diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt 
>> b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
>> index 1ab6bc8..656165f 100644
>> --- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
>> +++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
>> @@ -4,7 +4,6 @@ Required properties:
>>  - compatible: "ti,omap-twl4030"
>>  - ti,model: Name of the sound card (for example "omap3beagle")
>>  - ti,mcbsp: phandle for the McBSP node
>> -- ti,codec: phandle for the twl4030 audio node
> 
> As this was a required property, are you sure that no other operating system
> uses it?
> 
> Even if not, you should probably change it to be an optional property, so
> that the existing dtbs do not become noncompliant after the change.

After I sent my Ack, I also started to think about the same thing. It is
better to change it to optional.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v2 1/5] of/fdt: split off FDT self reservation from memreserve processing

2015-03-13 Thread Ard Biesheuvel
On 12 March 2015 at 22:54, Rob Herring  wrote:
> On Wed, Mar 11, 2015 at 11:00 AM, Ard Biesheuvel
>  wrote:
>> This splits off the reservation of the memory occupied by the FDT
>> binary itself from the processing of the memory reservations it
>> contains. This is necessary because the physical address of the FDT,
>> which is needed to perform the reservation, may not be known to the
>> FDT driver core, i.e., it may be mapped outside the linear direct
>> mapping, in which case __pa() returns a bogus value.
>>
>> Cc: Benjamin Herrenschmidt 
>> Cc: Paul Mackerras 
>> Signed-off-by: Ard Biesheuvel 
>
> Not really the direction I like going by moving more things back to
> arch code, but I haven't come up with any better suggestion so:
>
> Acked-by: Rob Herring 
>

Thanks.

@Russell, Benjamin, Paul: do any of you perhaps have any issues with this?

Regards,
Ard.


>> ---
>>  arch/arm/mm/init.c |  1 +
>>  arch/arm64/mm/init.c   |  1 +
>>  arch/powerpc/kernel/prom.c |  1 +
>>  drivers/of/fdt.c   | 19 ++-
>>  include/linux/of_fdt.h |  2 ++
>>  5 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index 1609b022a72f..0b8657c36fe4 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -317,6 +317,7 @@ void __init arm_memblock_init(const struct machine_desc 
>> *mdesc)
>> if (mdesc->reserve)
>> mdesc->reserve();
>>
>> +   early_init_fdt_reserve_self();
>> early_init_fdt_scan_reserved_mem();
>>
>> /* reserve memory for DMA contiguous allocations */
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index ae85da6307bb..fa2389b0f7f0 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -170,6 +170,7 @@ void __init arm64_memblock_init(void)
>> memblock_reserve(__virt_to_phys(initrd_start), initrd_end - 
>> initrd_start);
>>  #endif
>>
>> +   early_init_fdt_reserve_self();
>> early_init_fdt_scan_reserved_mem();
>>
>> /* 4GB maximum for 32-bit only capable devices */
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index b8e15c678960..093ccfb384af 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -573,6 +573,7 @@ static void __init early_reserve_mem_dt(void)
>> int len;
>> const __be32 *prop;
>>
>> +   early_init_fdt_reserve_self();
>> early_init_fdt_scan_reserved_mem();
>>
>> dt_root = of_get_flat_dt_root();
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 3a896c9aeb74..bbb35cdb06e8 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -561,11 +561,6 @@ void __init early_init_fdt_scan_reserved_mem(void)
>> if (!initial_boot_params)
>> return;
>>
>> -   /* Reserve the dtb region */
>> -   early_init_dt_reserve_memory_arch(__pa(initial_boot_params),
>> - fdt_totalsize(initial_boot_params),
>> - 0);
>> -
>> /* Process header /memreserve/ fields */
>> for (n = 0; ; n++) {
>> fdt_get_mem_rsv(initial_boot_params, n, &base, &size);
>> @@ -579,6 +574,20 @@ void __init early_init_fdt_scan_reserved_mem(void)
>>  }
>>
>>  /**
>> + * early_init_fdt_reserve_self() - reserve the memory used by the FDT blob
>> + */
>> +void __init early_init_fdt_reserve_self(void)
>> +{
>> +   if (!initial_boot_params)
>> +   return;
>> +
>> +   /* Reserve the dtb region */
>> +   early_init_dt_reserve_memory_arch(__pa(initial_boot_params),
>> + fdt_totalsize(initial_boot_params),
>> + 0);
>> +}
>> +
>> +/**
>>   * of_scan_flat_dt - scan flattened tree blob and call callback on each.
>>   * @it: callback function
>>   * @data: context data pointer
>> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
>> index 0ff360d5b3b3..6ef6b33238d3 100644
>> --- a/include/linux/of_fdt.h
>> +++ b/include/linux/of_fdt.h
>> @@ -62,6 +62,7 @@ extern int early_init_dt_scan_chosen(unsigned long node, 
>> const char *uname,
>>  extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
>>  int depth, void *data);
>>  extern void early_init_fdt_scan_reserved_mem(void);
>> +extern void early_init_fdt_reserve_self(void);
>>  extern void early_init_dt_add_memory_arch(u64 base, u64 size);
>>  extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t 
>> size,
>>  bool no_map);
>> @@ -89,6 +90,7 @@ extern u64 fdt_translate_address(const void *blob, int 
>> node_offset);
>>  extern void of_fdt_limit_memory(int limit);
>>  #else /* CONFIG_OF_FLATTREE */
>>  static inline void early_init_fdt_scan_reserved_mem(void) {}
>> +static inline void early_init_fdt_reserve_self(void) {}
>> 

Re: [rtc-linux] [PATCH 2/2] rtc: mediatek: Add MT63xx RTC driver

2015-03-13 Thread Matthias Brugger


On 13/03/15 11:29, Eddie Huang wrote:
> 
> I encounter some trouble when I add code to check return value of
> regmap_read and regmap_write. Every RTC register access through regmap,
> and there are many register read/write in this driver. If I check every
> return value, the driver will become ugly. I try to make this driver
> clean using following macro.
> 
> static int __rtc_read(struct mt6397_rtc *rtc, u32 offset, u32 *data)
> {
> u32 addr = rtc->addr_base + offset;
> 
> if (offset < rtc->addr_range)
> return regmap_read(rtc->regmap, addr, data);
> 
> return -EINVAL;
> }
> 
> #define rtc_read(ret, rtc, offset, data)\
> ({  \
> ret = __rtc_read(rtc, offset, data);\
> if (ret < 0)\
> goto rtc_exit;  \
> })  \
> 

I agree with Sascha on hiding a goto statement in a macro is not a good idea.

> 
> And function call rtc_read, rtc_write looks like:
> 
> static int mtk_rtc_read_time(struct device *dev, struct rtc_time *tm)
> {
> unsigned long time;
> struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> int ret = 0;
> u32 sec;
> 
> mutex_lock(&rtc->lock);
> do {
> rtc_read(ret, rtc, RTC_TC_SEC, &tm->tm_sec);
> rtc_read(ret, rtc, RTC_TC_MIN, &tm->tm_min);
> rtc_read(ret, rtc, RTC_TC_HOU, &tm->tm_hour);
> rtc_read(ret, rtc, RTC_TC_DOM, &tm->tm_mday);
> rtc_read(ret, rtc, RTC_TC_MTH, &tm->tm_mon);
> rtc_read(ret, rtc, RTC_TC_YEA, &tm->tm_year);
> rtc_read(ret, rtc, RTC_TC_SEC, &sec);
> } while (sec < tm->tm_sec);

What about introducing
static int __mtk_rtc_read_time(struct mt6397_rtc *rtc, struct rtc_time *tm, u32 
*sec)
and hide the checks of return values from regmap_read and the offset check in 
there. You return the error code or 0.

This way the while loop would look like this:

do {
ret = __mtk_rtc_read_time(rtc, &tm, &sec);
if (ret < 0)
goto rtc_exit;
} while (sec < tm->tm_sec);

Best regards,
Matthias

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


Re: [PATCH v6 2/4] pci: iProc: define iProc PCIe platform bus binding

2015-03-13 Thread Arnd Bergmann
On Thursday 12 March 2015 16:14:48 Bjorn Helgaas wrote:
> [+cc Rob, Pawel, Mark, Ian, Kumar]
> 
> On Wed, Mar 11, 2015 at 11:06:07AM -0700, Ray Jui wrote:
> > Document the Broadcom iProc PCIe platform interface device tree binding
> > 
> > Signed-off-by: Ray Jui 
> > Reviewed-by: Scott Branden 
> 
> I'd like to get an ack for this from Arnd, Rob, or other device tree folks
> (CC'd).
> 

Sorry, I should have given my ack earlier. I've carefully reviewed the
previous versions and am happy with the current one.

Acked-by: Arnd Bergmann 

for the whole series.

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


Re: [PATCH 2/2] Documentation: omap-twl4030: Remove ti,codec property

2015-03-13 Thread Arnd Bergmann
On Thursday 12 March 2015 22:14:59 Marek Belisko wrote:
> diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt 
> b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
> index 1ab6bc8..656165f 100644
> --- a/Documentation/devicetree/bindings/sound/omap-twl4030.txt
> +++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt
> @@ -4,7 +4,6 @@ Required properties:
>  - compatible: "ti,omap-twl4030"
>  - ti,model: Name of the sound card (for example "omap3beagle")
>  - ti,mcbsp: phandle for the McBSP node
> -- ti,codec: phandle for the twl4030 audio node

As this was a required property, are you sure that no other operating system
uses it?

Even if not, you should probably change it to be an optional property, so
that the existing dtbs do not become noncompliant after the change.

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


Re: [PATCH v3 2/2] i2c: Support for Netlogic XLP9XX/5XX I2C controller.

2015-03-13 Thread Arnd Bergmann
On Friday 13 March 2015 11:59:58 Jayachandran C wrote:
> +- compatible  : should be "netlogic,xlp9xx-i2c"
> 

Use a real model number here, not a wildcard.

Also, please send the binding as a separate patch from the driver.

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


Re: [rtc-linux] [PATCH 2/2] rtc: mediatek: Add MT63xx RTC driver

2015-03-13 Thread Sascha Hauer
Hi Eddie,

On Fri, Mar 13, 2015 at 06:29:23PM +0800, Eddie Huang wrote:
> > regmap_read() and regmap_write() can return errors.  There is no
> > checking for this.
> > 
> 
> I encounter some trouble when I add code to check return value of
> regmap_read and regmap_write. Every RTC register access through regmap,
> and there are many register read/write in this driver. If I check every
> return value, the driver will become ugly. I try to make this driver
> clean using following macro.
> 
> static int __rtc_read(struct mt6397_rtc *rtc, u32 offset, u32 *data)
> {
> u32 addr = rtc->addr_base + offset;
> 
> if (offset < rtc->addr_range)
> return regmap_read(rtc->regmap, addr, data);
> 
> return -EINVAL;
> }
> 
> #define rtc_read(ret, rtc, offset, data)\
> ({  \
> ret = __rtc_read(rtc, offset, data);\
> if (ret < 0)\
> goto rtc_exit;  \
> })  \

Hiding a goto (or return) in a macro is a very bad idea.

what you can do is

ret |= regmap_read(rtc->regmap, RTC_TC_SEC, &tm->tm_sec);
ret |= regmap_read(rtc->regmap, RTC_TC_MIN, &tm->tm_min);

if (ret)
return -EIO;

(Don't return ret in this case though as it might contain different
error codes orred together)

Another possibilty at least for contiguous registers would be
regmap_bulk_read().

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH v4 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

2015-03-13 Thread Mark Rutland
> +/ {
> + chosen {
> + stdout-path = &blsp1_uart2;
> + };

It would be good if we had the configuration too (see
Documentation/devicetree/bindings/chosen.txt), as that avoids any
reliance on kernel defaults.

You can refer to an alias, so this could be:

aliases {
serial0 = &blsp1_uart2;
};

chosen {
stdout-path = "serial0:115200n8";
};

...assuming that 115200n8 is correct for your UART, of course.


[...]

> +#include "skeleton.dtsi"

I'd like to get rid of skeleton.dtsi; it causes more problems than it
solves (the address/size cells mismatch is confusing and hidden, people
forget to fill in memory nodes appropriately, etc).

Please remove this include and place appropriate #address-cells and #size-cells 
here.

I'd strongly recommend going with /#size-cells = <2>; it' will save on a
lot of pain if you need to add PCIe or something with large ranges
later. If things all fall in 4GB within the SoC then have
/soc/#size=cells = <1> and an appropriate /soc/ranges property.

I note this DT doesn't have any memory nodes. Is that an accident or
does the loader fill that in?

If the latter, have an empty node with a comment to that effect.

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


Re: [PATCH v3 2/4] arm64: dts: Add Qualcomm MSM8916 SoC and evaluation board dts

2015-03-13 Thread Mark Rutland
> > Which of spin-table/psci are you planning on using for SMP support, and
> > when would that be likely to appear?
> 
> We have a qcom specific SMP enablement method for this device.  This
> was one of our first devices so it utilized as much from arm 32-bit as
> possible.

Implementation specific enable methods are something we really don't
want to see for arm64. If PSCI is out of the question then a spin-table
shim in your bootloader shouldn't be too hard to implement.

> > Which exception level do CPUs enter the kernel? Even without a
> > virt-capable GIC booting at EL2 is less work for the FW and gives the
> > kernel a better chance of fixing things up (e.g. CNTVOFF).
> 
> I think the enter in EL1.

That's unfortunate, but so long as they are consistent, it's not the end
of the world.

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


Re: [rtc-linux] [PATCH 2/2] rtc: mediatek: Add MT63xx RTC driver

2015-03-13 Thread Eddie Huang
Hi,

On Mon, 2015-02-23 at 13:50 -0800, Andrew Morton wrote:
> On Wed, 28 Jan 2015 17:27:56 +0800 Eddie Huang  
> wrote:
> 
> > From: Tianping Fang 
> > 
> > Add Mediatek MT63xx RTC driver
> 
> There are a couple of checkpatch warnings which should be addressed,
> please:
> 
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #150: 
> new file mode 100644
> 
> WARNING: DT compatible string "mediatek,mt6397-rtc" appears un-documented -- 
> check ./Documentation/devicetree/bindings/
> #488: FILE: drivers/rtc/rtc-mt6397.c:334:
> + { .compatible = "mediatek,mt6397-rtc", },
> 
> 
> 
> 
> >
> > ...
> >
> > +static u16 rtc_read(struct mt6397_rtc *rtc, u32 offset)
> > +{
> > +   u32 rdata = 0;
> > +   u32 addr = rtc->addr_base + offset;
> > +
> > +   if (offset < rtc->addr_range)
> > +   regmap_read(rtc->regmap, addr, &rdata);
> > +
> > +   return (u16)rdata;
> > +}
> > +
> > +static void rtc_write(struct mt6397_rtc *rtc, u32 offset, u32 data)
> > +{
> > +   u32 addr;
> > +
> > +   addr = rtc->addr_base + offset;
> > +
> > +   if (offset < rtc->addr_range)
> > +   regmap_write(rtc->regmap, addr, data);
> > +}
> 
> regmap_read() and regmap_write() can return errors.  There is no
> checking for this.
> 

I encounter some trouble when I add code to check return value of
regmap_read and regmap_write. Every RTC register access through regmap,
and there are many register read/write in this driver. If I check every
return value, the driver will become ugly. I try to make this driver
clean using following macro.

static int __rtc_read(struct mt6397_rtc *rtc, u32 offset, u32 *data)
{
u32 addr = rtc->addr_base + offset;

if (offset < rtc->addr_range)
return regmap_read(rtc->regmap, addr, data);

return -EINVAL;
}

#define rtc_read(ret, rtc, offset, data)\
({  \
ret = __rtc_read(rtc, offset, data);\
if (ret < 0)\
goto rtc_exit;  \
})  \


And function call rtc_read, rtc_write looks like:

static int mtk_rtc_read_time(struct device *dev, struct rtc_time *tm)
{
unsigned long time;
struct mt6397_rtc *rtc = dev_get_drvdata(dev);
int ret = 0;
u32 sec;

mutex_lock(&rtc->lock);
do {
rtc_read(ret, rtc, RTC_TC_SEC, &tm->tm_sec);
rtc_read(ret, rtc, RTC_TC_MIN, &tm->tm_min);
rtc_read(ret, rtc, RTC_TC_HOU, &tm->tm_hour);
rtc_read(ret, rtc, RTC_TC_DOM, &tm->tm_mday);
rtc_read(ret, rtc, RTC_TC_MTH, &tm->tm_mon);
rtc_read(ret, rtc, RTC_TC_YEA, &tm->tm_year);
rtc_read(ret, rtc, RTC_TC_SEC, &sec);
} while (sec < tm->tm_sec);
mutex_unlock(&rtc->lock);

tm->tm_year += RTC_MIN_YEAR_OFFSET;
tm->tm_mon--;
rtc_tm_to_time(tm, &time);

tm->tm_wday = (time / 86400 + 4) % 7;

return 0;

rtc_exit:
mutex_unlock(&rtc->lock);
return ret;
}

It's a little tricky, does anyone have good suggestion ?

Eddie




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


Re: [PATCH v3 05/12] clocksource: add dependencies for Vybrid pit clocksource

2015-03-13 Thread Daniel Lezcano

On 03/13/2015 12:36 AM, Stefan Agner wrote:

Add the minimal dependencies required to use the Vybrid PIT
clocksource driver. Those are not part of the SoC dependencies.

Signed-off-by: Stefan Agner 


Acked-by: Daniel Lezcano 


---
  drivers/clocksource/Kconfig | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 1c2506f..350e742 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -164,6 +164,8 @@ config FSL_FTM_TIMER

  config VF_PIT_TIMER
bool
+   select CLKSRC_MMIO
+   select CLKSRC_OF
help
  Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.





--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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


Re: [PATCH v3 2/2] i2c: Support for Netlogic XLP9XX/5XX I2C controller.

2015-03-13 Thread Uwe Kleine-König
hello,

On Fri, Mar 13, 2015 at 11:59:58AM +0530, Jayachandran C wrote:
> diff --git a/drivers/i2c/busses/i2c-xlp9xx.c b/drivers/i2c/busses/i2c-xlp9xx.c
> new file mode 100644
> index ..2f303ad
> --- /dev/null
> +++ b/drivers/i2c/busses/i2c-xlp9xx.c
> @@ -0,0 +1,446 @@
> +/*
> + * Copyright (c) 2003-2015 Broadcom Corporation
> + *
> + * 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.
> + */
> +
> +/*
> + * see Documentation/devicetree/bindings/i2c/i2c-xlp9xx.txt for device
> + * tree bindings documentation
> + */
When I asked for documentation here, I didn't meant the device tree
binding, but the hardware reference manual.

> [...]
> +static void xlp9xx_i2c_mask_irq(struct xlp9xx_i2c_dev *priv, u32 mask)
> +{
> + mask = xlp9xx_read_i2c_reg(priv, XLP9XX_I2C_INTEN) & ~mask;
> + xlp9xx_write_i2c_reg(priv, XLP9XX_I2C_INTEN, mask);
You didn't comment on my suggestion to add a variable here for improved
readability:

u32 inten = xlp9xx_read_i2c_reg(...);
inten &= ~mask;
xlp9xx_write_i2c_reg(...);

> +}
> +
> +static void xlp9xx_i2c_unmask_irq(struct xlp9xx_i2c_dev *priv, u32 mask)
> +{
> + mask = xlp9xx_read_i2c_reg(priv, XLP9XX_I2C_INTEN) | mask;
> + xlp9xx_write_i2c_reg(priv, XLP9XX_I2C_INTEN, mask);
> +}
> +
> +static void xlp9xx_i2c_set_rx_fifo_thres(struct xlp9xx_i2c_dev *priv,
> +  u32 th)
> +{
> + xlp9xx_write_i2c_reg(priv, XLP9XX_I2C_MFIFOCTRL,
> +  (th << XLP9XX_I2C_MFIFOCTRL_HITH_SHIFT));
parenthesis are not needed here.

I suggested to move the min calculation that you have to do before each
call to this function into it. You replied:

The xlp9xx_i2c_... functions were written to do the
hardware/register operations, so it is better to have this logic
here.

...

> +}
> +
> +static void xlp9xx_i2c_fill_tx_fifo(struct xlp9xx_i2c_dev *priv)
> +{
> + u32 len, i;
> + u8 *buf = priv->msg_buf;
> +
> + len = min(priv->msg_buf_remaining, XLP9XX_I2C_FIFO_SIZE);
... this didn't stop you here though :-) So I'm still convinced that
having the min function in xlp9xx_i2c_set_rx_fifo_thres is a good idea.

> + for (i = 0; i < len; i++)
> + xlp9xx_write_i2c_reg(priv, XLP9XX_I2C_MTXFIFO, buf[i]);
> + priv->msg_buf_remaining -= len;
> + priv->msg_buf += len;
> +}
> [...]
> +static int xlp9xx_i2c_init(struct xlp9xx_i2c_dev *priv)
> +{
> + u32 prescale;
> +
> + /*
> +  * The controller uses 5 * SCL clock internally.
> +  * So prescale value should be divided by 5.
> +  */
> + prescale = (((XLP9XX_I2C_IP_CLK_FREQ / priv->clk_hz) - 8) / 5) - 1;
I still wonder if you should round differently here.

> + xlp9xx_write_i2c_reg(priv, XLP9XX_I2C_CTRL, XLP9XX_I2C_CTRL_RST);
> + xlp9xx_write_i2c_reg(priv, XLP9XX_I2C_CTRL, XLP9XX_I2C_CTRL_EN |
> +  XLP9XX_I2C_CTRL_MASTER);
> + xlp9xx_write_i2c_reg(priv, XLP9XX_I2C_DIV, prescale);
> + xlp9xx_write_i2c_reg(priv, XLP9XX_I2C_INTEN, 0);
> +
> + return 0;
> +}

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC PATCH v15 04/11] ARM: cpuidle: Register cpuidle_ops for QCOM cpus

2015-03-13 Thread Daniel Lezcano

On 03/12/2015 04:06 PM, Lina Iyer wrote:

On Thu, Mar 12 2015 at 06:34 -0600, Daniel Lezcano wrote:

On 03/11/2015 07:16 PM, Stephen Boyd wrote:

On 03/09/15 08:16, Lina Iyer wrote:


[...]


+#if IS_ENABLED(CONFIG_QCOM_PM)


Why not #ifdef CONFIG_QCOM_PM? I thought IS_ENABLED was for C code where
you want to put it in an if () statement.


This is right. But the IS_ENABLED is also valid.

It seems the current trend is to replace #ifdef with #if IS_ENABLED.
It is supposed to prevent to create or'ed conditional with the module
support.

eg:

#if defined(CONFIG_FOO) || defined(CONFIG_FOO_MODULE)

is replaced by:

#if IS_ENABLED(CONFIG_FOO)

Lina: By the way, it would be preferable to use the
CONFIG_ARM_QCOM_CPUIDLE where IS_ENABLED makes more sense even the


Daniel: I dont have CONFIG_ARM_QCOM_CPUIDLE defined anymore. By moving
to generic ARM cpuidle, i removed all changes to drivers/cpuidle/. So I
used the config item that defineds these items.

Also, having two indpendent CONFIG_ items provides a chance that the
declaration is not matched with the definition or vice versa.


I think CONFIG_ARM_QCOM_CPUIDLE should be defined as a bool in the 
Kconfig.arm in drivers/cpuidle.


We may want to disable the different cpuidle drivers even if they rely 
on the generic cpuidle driver.



drivers are not modules (who knows if they are converted as module
again hence #ifdef will be invalid).




+CPUIDLE_OPS(qcom_kpss_v1)
+CPUIDLE_OPS(qcom_kpss_v2)
+#endif





--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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


[PATCH v2 3/7] eeprom: Add bindings for simple eeprom framework

2015-03-13 Thread Srinivas Kandagatla
This patch adds bindings for simple eeprom framework which allows eeprom
consumers to talk to eeprom providers to get access to eeprom cell data.

Signed-off-by: Maxime Ripard 
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla 
---
 .../devicetree/bindings/eeprom/eeprom.txt  | 70 ++
 1 file changed, 70 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt

diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
new file mode 100644
index 000..8348d18
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -0,0 +1,70 @@
+= EEPROM Data Device Tree Bindings =
+
+This binding is intended to represent the location of hardware
+configuration data stored in EEPROMs.
+
+On a significant proportion of boards, the manufacturer has stored
+some data on an EEPROM-like device, for the OS to be able to retrieve
+these information and act upon it. Obviously, the OS has to know
+about where to retrieve these data from, and where they are stored on
+the storage device.
+
+This document is here to document this.
+
+= Data providers =
+Contains bindings specific to provider drivers and data cells as children
+to this node.
+
+= Data cells =
+These are the child nodes of the provider which contain data cell
+information like offset and size in eeprom provider.
+
+Required properties:
+reg:   specifies the offset in byte within that storage device, and the length
+   in bytes of the data we care about.
+   There could be more then one offset-length pairs in this property.
+
+Optional properties:
+As required by specific data parsers/interpreters.
+
+For example:
+
+   /* Provider */
+   qfprom: qfprom@0070 {
+   compatible  = "qcom,qfprom";
+   reg = <0x0070 0x1000>;
+   ...
+
+   /* Data cells */
+   tsens_calibration: calib@404 {
+   reg = <0x404 0x10>;
+   };
+
+   serial_number: sn {
+   reg = <0x104 0x4>, <0x204 0x4>, <0x30c 0x4>;
+
+   };
+   ...
+   };
+
+= Data consumers =
+Are device nodes which consume eeprom data cells.
+
+Required properties:
+
+eeproms: List of phandle and data cell the device might be interested in.
+
+Optional properties:
+
+eeprom-names: List of data cell name strings sorted in the same order
+ as the eeproms property. Consumers drivers will use
+ eeprom-names to differentiate between multiple cells,
+ and hence being able to know what these cells are for.
+
+For example:
+
+   tsens {
+   ...
+   eeproms = <&tsens_calibration>;
+   eeprom-names = "calibration";
+   };
-- 
1.9.1

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


[PATCH v2 6/7] eeprom: qfprom: Add bindings for qfprom

2015-03-13 Thread Srinivas Kandagatla
This patch adds bindings for qfprom found in QCOM SOCs. QFPROM driver
is based on simple eeprom framework.

Signed-off-by: Srinivas Kandagatla 
---
 .../devicetree/bindings/eeprom/qfprom.txt  | 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/eeprom/qfprom.txt

diff --git a/Documentation/devicetree/bindings/eeprom/qfprom.txt 
b/Documentation/devicetree/bindings/eeprom/qfprom.txt
new file mode 100644
index 000..d5baed6
--- /dev/null
+++ b/Documentation/devicetree/bindings/eeprom/qfprom.txt
@@ -0,0 +1,23 @@
+= Qualcomm QFPROM device tree bindings =
+
+This binding is intended to represent QFPROM which is found in most QCOM SOCs.
+
+Required properties:
+- compatible: should be "qcom,qfprom"
+- reg: Should contain registers location and length
+
+= Data cells =
+Are child nodes of qfprom, bindings of which as described in
+bindings/eeprom/eeprom.txt
+
+Example:
+
+   qfprom: qfprom@0070 {
+   compatible  = "qcom,qfprom";
+   reg = <0x0070 0x1000>;
+   ...
+   /* Data cells */
+   tsens_calibration: calib@404 {
+   reg = <0x404 0x10>;
+   };
+   };
-- 
1.9.1

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


  1   2   >