RE: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings

[Yuantian Tang]

> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
> Sent: Wednesday, September 09, 2015 10:02 PM
> To: Tang Yuantian-B29983 
> Cc: hdego...@redhat.com; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; devicetree@vger.kernel.org
> Subject: Re: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings
> 
> On Wed, Sep 09, 2015 at 05:16:22PM +0800, yuantian.t...@freescale.com
> wrote:
> > From: Tang Yuantian 
> >
> > kbuild test robot reports the warnings:
> > drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
> > >> include/asm-generic/io.h:163:2: warning: 'px_is' may be used
> > >> uninitialized in this function [-Wuninitialized]
> > drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here
> > >> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
> > >> uninitialized in this function [-Wuninitialized]
> > drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here
> >
> > This patch fixed it by assigning 0 to px_is and px_cmd variables.
> > This patch also remove line 'struct ccsr_ahci *reg_base' which is not
> > referred by any other codes and thus a dead one.
> 
> Hmm... I think the problem here is that the complier can't know whether
> qoriq_priv->type would change across intervening function calls.  Maybe a
> better solution is caching the type in a local variable so that the compiler 
> can
> tell that those two tests will always move together?  It generally isn't a 
> good
> idea to clear variables unnecessarily as that can hide actual bugs that 
> compiler
> can detect.
> 
I am not sure if the warning can be removed this way.
But I will send the patch as your suggestion. 
Unfortunately, I can't produce this warning no matter if I add -Wuninitialized.
So please let me know if the new patch is working.

Regards,
Yuantian

> Thanks.
> 
> --
> tejun
--
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 0/2] drm/dsi: DSI for devices with different control bus

[Archit Taneja]

On 09/08/2015 03:57 PM, Andrzej Hajda wrote:

On 09/07/2015 01:46 PM, Archit Taneja wrote:

Thierry,

On 08/21/2015 11:39 AM, Archit Taneja wrote:



On 08/20/2015 05:18 PM, Thierry Reding wrote:

On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote:

Hi Thierry, Lucas,


On 08/19/2015 08:32 PM, Thierry Reding wrote:

On Wed, Aug 19, 2015 at 04:52:24PM +0200, Lucas Stach wrote:

Am Mittwoch, den 19.08.2015, 16:34 +0200 schrieb Thierry Reding:

On Wed, Aug 19, 2015 at 04:17:08PM +0200, Lucas Stach wrote:

Hi Thierry, Archit,


[...]

Perhaps a better way would be to invert this relationship.
According to
your proposal we'd have to have DT like this:

 i2c@... {
 ...

 dsi-device@... {
 ...
 dsi-bus = <&dsi>;
 ...
 };

 ...
 };

 dsi@... {
 ...
 };

Inversing the relationship would become something like this:

 i2c@... {
 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 i2c-bus = <&i2c>;
 ...
 };

 ...
 };

Both of those aren't fundamentally different, and they both have
the
disavantage of lacking ways to transport configuration data that
the
other bus needs to instantiate the dummy device (such as the reg
property for example, denoting the I2C slave address or the DSI
VC).

So how about we create two devices in the device tree and fuse
them at
the driver level:

 i2c@... {
 ...

 i2cdsi: dsi-device@... {
 ...
 };

 ...
 };

 dsi@... {
 ...

 peripheral@... {
 ...
 control = <&i2cdsi>;
 ...
 };

 ...
 };

This way we'll get both an I2C device and a DSI device that we
can fully
describe using the standard device tree bindings. At driver time
we can
get the I2C device from the phandle in the control property of
the DSI
device and use it to execute I2C transactions.


I don't really like to see that you are inventing yet-another-way to
handle devices connected to multiple buses.

Devicetree is structured along the control buses, even if the
devices
are connected to multiple buses, in the DT they are always
children of
the bus that is used to control their registers from the CPUs
perspective. So a DSI encoder that is controlled through i2c is
clearly
a child of the i2c master controller and only of that one.


I think that's a flawed interpretation of what's going on here. The
device in fact has two interfaces: one is I2C, the other is DSI.
In my
opinion that's reason enough to represent it as two logical devices.


Does it really have 2 control interfaces that are used at the same
time?
Or is the DSI connection a passive data bus if the register control
happens through i2c?


The interfaces may not be used at the same time, and the DSI interface
may even be crippled, but the device is still addressable from the DSI
host controller, if for nothing else than for routing the video stream.


If you need to model connections between devices that are not
reflected
through the control bus hierarchy you should really consider
using the
standardized of-graph bindings.
(Documentation/devicetree/bindings/graph.txt)


The problem is that the original proposal would instantiate a dummy
device, so it wouldn't be represented in DT at all. So unless you
do add
two logical devices to DT (one for each bus interface), you don't
have
anything to glue together with an OF graph.


I see that the having dummy device is the least desirable solution.
But
if there is only one control bus to the device I think it should be
one
device sitting beneath the control bus.

You can then use of-graph to model the data path between the DSI
encoder
and device.


But you will be needing a device below the DSI host controller to
represent that endpoint of the connection. The DSI host controller
itself is in no way connected to the I2C adapter. You would have to
add some sort of quirk to the DSI controller binding to allow it to


Thanks for the review.

I implemented this to support ADV7533 DSI to HDMI encoder chip, which
has a DSI video bus and an i2c control bus.

There weren't any quirks as such in the device tree when I tried to
implement this. The DT seems to manage fine without a node
corresponding to a mipi_dsi_device:

i2c_adap@.. {
 adv7533@.. {

 port {
 adv_in: endpoint {
 remote-endpoint = <&dsi_out>;
 };
 };
 };
};

dsi_host@.. {
 ...
 ...

 port {
 dsi_out: endpoint {
 remote-endpoint = <&adv_in>;
 }
 };
};

It's the i2c driver's job to parse the graph and retrieve the
phandle to the dsi host. Using this, it can proceed with
registering itself to this host using the new dsi funcs. This
patch does the same for the adv7533 i2c driver:

http://www.spinics.net/lists/dri-devel/msg86840.html


hook up with a control 

[RESEND PATCH 2/3] reset: hisilicon: document hisi-hi6220 reset controllers bindings

[Chen Feng]

Add DT bindings documentation for hi6220 SoC reset controller.

Signed-off-by: Chen Feng 
---
 .../bindings/reset/hisilicon,hi6220-reset.txt  | 97 ++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  2 +-
 2 files changed, 98 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt

diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt 
b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
new file mode 100644
index 000..8a23f50
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
@@ -0,0 +1,97 @@
+Hisilicon System Reset Controller
+==
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller node must be a sub-node of the chip controller
+node on SoCs.
+
+Required properties:
+- compatible: may be "hisilicon,hisi_reset_ctl"
+- reg: should be register base and length as documented in the
+  datasheet
+- #reset-cells: 1, see below
+
+Example:
+
+   reset_ctrl: reset_ctrl@f7030304 {
+   compatible = "hisilicon,hi6220_reset_ctl";
+   reg = <0x0 0xf7030304 0x0 0x1000>;
+   #reset-cells = <1>;
+   };
+
+Specifying reset lines connected to IP modules
+==
+example:
+
+uart1: uart1@. {
+   ...
+resets = <&reset_ctrl 0x305>;
+   ...
+};
+
+The following RESET_INDEX values are valid for hi6220 SoC:
+   PERIPH_RSTDIS0_MMC0 = 0x000,
+   PERIPH_RSTDIS0_MMC1 = 0x001,
+   PERIPH_RSTDIS0_MMC2 = 0x002,
+   PERIPH_RSTDIS0_NANDC= 0x003,
+   PERIPH_RSTDIS0_USBOTG_BUS   = 0x004,
+   PERIPH_RSTDIS0_POR_PICOPHY  = 0x005,
+   PERIPH_RSTDIS0_USBOTG   = 0x006,
+   PERIPH_RSTDIS0_USBOTG_32K   = 0x007,
+
+   PERIPH_RSTDIS1_HIFI = 0x100,
+   PERIPH_RSTDIS1_DIGACODEC= 0x105,
+
+   PERIPH_RSTEN2_IPF   = 0x200,
+   PERIPH_RSTEN2_SOCP  = 0x201,
+   PERIPH_RSTEN2_DMAC  = 0x202,
+   PERIPH_RSTEN2_SECENG= 0x203,
+   PERIPH_RSTEN2_ABB   = 0x204,
+   PERIPH_RSTEN2_HPM0  = 0x205,
+   PERIPH_RSTEN2_HPM1  = 0x206,
+   PERIPH_RSTEN2_HPM2  = 0x207,
+   PERIPH_RSTEN2_HPM3  = 0x208,
+
+   PERIPH_RSTEN3_CSSYS = 0x300,
+   PERIPH_RSTEN3_I2C0  = 0x301,
+   PERIPH_RSTEN3_I2C1  = 0x302,
+   PERIPH_RSTEN3_I2C2  = 0x303,
+   PERIPH_RSTEN3_I2C3  = 0x304,
+   PERIPH_RSTEN3_UART1 = 0x305,
+   PERIPH_RSTEN3_UART2 = 0x306,
+   PERIPH_RSTEN3_UART3 = 0x307,
+   PERIPH_RSTEN3_UART4 = 0x308,
+   PERIPH_RSTEN3_SSP   = 0x309,
+   PERIPH_RSTEN3_PWM   = 0x30a,
+   PERIPH_RSTEN3_BLPWM = 0x30b,
+   PERIPH_RSTEN3_TSENSOR   = 0x30c,
+   PERIPH_RSTEN3_DAPB  = 0x312,
+   PERIPH_RSTEN3_HKADC = 0x313,
+   PERIPH_RSTEN3_CODEC_SSI = 0x314,
+   PERIPH_RSTEN3_PMUSSI1   = 0x316,
+
+   PERIPH_RSTEN8_RS0   = 0x400,
+   PERIPH_RSTEN8_RS2   = 0x401,
+   PERIPH_RSTEN8_RS3   = 0x402,
+   PERIPH_RSTEN8_MS0   = 0x403,
+   PERIPH_RSTEN8_MS2   = 0x405,
+   PERIPH_RSTEN8_XG2RAM0   = 0x406,
+   PERIPH_RSTEN8_X2SRAM_TZMA   = 0x407,
+   PERIPH_RSTEN8_SRAM  = 0x408,
+   PERIPH_RSTEN8_HARQ  = 0x40a,
+   PERIPH_RSTEN8_DDRC  = 0x40c,
+   PERIPH_RSTEN8_DDRC_APB  = 0x40d,
+   PERIPH_RSTEN8_DDRPACK_APB   = 0x40e,
+   PERIPH_RSTEN8_DDRT  = 0x411,
+
+   PERIPH_RSDIST9_CARM_DAP = 0x500,
+   PERIPH_RSDIST9_CARM_ATB = 0x501,
+   PERIPH_RSDIST9_CARM_LBUS= 0x502,
+   PERIPH_RSDIST9_CARM_POR = 0x503,
+   PERIPH_RSDIST9_CARM_CORE= 0x504,
+   PERIPH_RSDIST9_CARM_DBG = 0x505,
+   PERIPH_RSDIST9_CARM_L2  = 0x506,
+   PERIPH_RSDIST9_CARM_SOCDBG  = 0x507,
+   PERIPH_RSDIST9_CARM_ETM = 0x508,
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 09bb9d1..111537a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -169,7 +169,7 @@
};
 
reset_ctrl: reset_ctrl@f7030304 {
-   compatible = "hisilicon,hisi_reset_ctl";
+   compatible = "hisilicon,hi6220_reset_ctl";
reg = <0x0 0xf7030304 0x0 0x1000>;
 

[RESEND PATCH 1/3] arm64: dts: Add reset dts config for Hisilicon Hi6220 SoC

[Chen Feng]

Add reset controller for hi6220 hikey-board.

Signed-off-by: Chen Feng 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..09bb9d1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,12 @@
clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+   reset_ctrl: reset_ctrl@f7030304 {
+   compatible = "hisilicon,hisi_reset_ctl";
+   reg = <0x0 0xf7030304 0x0 0x1000>;
+   #reset-cells = <1>;
+   };
+
};
 };
-- 
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

[RESEND PATCH 3/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC

[Chen Feng]

Add reset driver for hi6220-hikey board,this driver supply deassert
of IP. on hi6220 SoC.

Signed-off-by: Chen Feng 
---
 drivers/reset/Kconfig  |  1 +
 drivers/reset/Makefile |  1 +
 drivers/reset/hisilicon/Kconfig|  5 +++
 drivers/reset/hisilicon/Makefile   |  1 +
 drivers/reset/hisilicon/hi6220_reset.c | 74 ++
 5 files changed, 82 insertions(+)
 create mode 100644 drivers/reset/hisilicon/Kconfig
 create mode 100644 drivers/reset/hisilicon/Makefile
 create mode 100644 drivers/reset/hisilicon/hi6220_reset.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..df37212 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
  If unsure, say no.
 
 source "drivers/reset/sti/Kconfig"
+source "drivers/reset/hisilicon/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..331d7b2 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_HISI) += hisilicon/
diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
new file mode 100644
index 000..bceed14
--- /dev/null
+++ b/drivers/reset/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config COMMON_RESET_HI6220
+   tristate "Hi6220 Clock Driver"
+   depends on (ARCH_HISI && RESET_CONTROLLER)
+   help
+ Build the Hisilicon Hi6220 reset driver.
diff --git a/drivers/reset/hisilicon/Makefile b/drivers/reset/hisilicon/Makefile
new file mode 100644
index 000..c932f86
--- /dev/null
+++ b/drivers/reset/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
diff --git a/drivers/reset/hisilicon/hi6220_reset.c 
b/drivers/reset/hisilicon/hi6220_reset.c
new file mode 100644
index 000..a88fc57
--- /dev/null
+++ b/drivers/reset/hisilicon/hi6220_reset.c
@@ -0,0 +1,74 @@
+/*
+ * Hisilicon Hi6220 reset controller driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Feng Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void __iomem *src_base;
+static DEFINE_SPINLOCK(reset_lock);
+
+static int hi6220_reset_module(struct reset_controller_dev *rc_dev,
+   unsigned long idx)
+{
+   unsigned long timeout;
+   unsigned long flags;
+   int bit;
+   u32 val;
+
+   int bank = idx >> 8;
+   int offset = idx & 0xff;
+
+   spin_lock_irqsave(&reset_lock, flags);
+
+   val = readl(src_base + (bank * 0x10));
+   writel(val | BIT(offset), src_base + (bank * 0x10));
+
+   spin_unlock_irqrestore(&reset_lock, flags);
+
+   return 0;
+
+}
+
+static struct reset_control_ops hi6220_reset_ops = {
+   .deassert = hi6220_reset_module,
+};
+
+static struct reset_controller_dev hi6220_reset_dev = {
+   .ops = &hi6220_reset_ops,
+   .nr_resets = 0x,
+};
+
+static void __init hi6220_reset_init(void)
+{
+   struct device_node *np;
+   struct reset_control *test = NULL;
+
+   np = of_find_compatible_node(NULL, NULL, "hisilicon,hisi_reset_ctl");
+   if (!np) {
+   pr_err("find reset node in dts error!\n");
+   return;
+   }
+   src_base = of_iomap(np, 0);
+   WARN_ON(!src_base);
+
+   hi6220_reset_dev.of_node = np;
+   if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
+   reset_controller_register(&hi6220_reset_dev);
+}
+
+postcore_initcall(hi6220_reset_init);
+
-- 
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 3/3] reset: hi6220: Reset driver for hisilicon hi6220 SoC

[Chen Feng]

Add reset driver for hi6220-hikey board,this driver supply deassert
of IP. on hi6220 SoC.

Signed-off-by: Chen Feng 
---
 drivers/reset/Kconfig  |  1 +
 drivers/reset/Makefile |  1 +
 drivers/reset/hisilicon/Kconfig|  5 +++
 drivers/reset/hisilicon/Makefile   |  1 +
 drivers/reset/hisilicon/hi6220_reset.c | 74 ++
 5 files changed, 82 insertions(+)
 create mode 100644 drivers/reset/hisilicon/Kconfig
 create mode 100644 drivers/reset/hisilicon/Makefile
 create mode 100644 drivers/reset/hisilicon/hi6220_reset.c

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 0615f50..df37212 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -13,3 +13,4 @@ menuconfig RESET_CONTROLLER
  If unsure, say no.
 
 source "drivers/reset/sti/Kconfig"
+source "drivers/reset/hisilicon/Kconfig"
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..331d7b2 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_HISI) += hisilicon/
diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
new file mode 100644
index 000..bceed14
--- /dev/null
+++ b/drivers/reset/hisilicon/Kconfig
@@ -0,0 +1,5 @@
+config COMMON_RESET_HI6220
+   tristate "Hi6220 Clock Driver"
+   depends on (ARCH_HISI && RESET_CONTROLLER)
+   help
+ Build the Hisilicon Hi6220 reset driver.
diff --git a/drivers/reset/hisilicon/Makefile b/drivers/reset/hisilicon/Makefile
new file mode 100644
index 000..c932f86
--- /dev/null
+++ b/drivers/reset/hisilicon/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_COMMON_RESET_HI6220) += hi6220_reset.o
diff --git a/drivers/reset/hisilicon/hi6220_reset.c 
b/drivers/reset/hisilicon/hi6220_reset.c
new file mode 100644
index 000..a88fc57
--- /dev/null
+++ b/drivers/reset/hisilicon/hi6220_reset.c
@@ -0,0 +1,74 @@
+/*
+ * Hisilicon Hi6220 reset controller driver
+ *
+ * Copyright (c) 2015 Hisilicon Limited.
+ *
+ * Author: Feng Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void __iomem *src_base;
+static DEFINE_SPINLOCK(reset_lock);
+
+static int hi6220_reset_module(struct reset_controller_dev *rc_dev,
+   unsigned long idx)
+{
+   unsigned long timeout;
+   unsigned long flags;
+   int bit;
+   u32 val;
+
+   int bank = idx >> 8;
+   int offset = idx & 0xff;
+
+   spin_lock_irqsave(&reset_lock, flags);
+
+   val = readl(src_base + (bank * 0x10));
+   writel(val | BIT(offset), src_base + (bank * 0x10));
+
+   spin_unlock_irqrestore(&reset_lock, flags);
+
+   return 0;
+
+}
+
+static struct reset_control_ops hi6220_reset_ops = {
+   .deassert = hi6220_reset_module,
+};
+
+static struct reset_controller_dev hi6220_reset_dev = {
+   .ops = &hi6220_reset_ops,
+   .nr_resets = 0x,
+};
+
+static void __init hi6220_reset_init(void)
+{
+   struct device_node *np;
+   struct reset_control *test = NULL;
+
+   np = of_find_compatible_node(NULL, NULL, "hisilicon,hisi_reset_ctl");
+   if (!np) {
+   pr_err("find reset node in dts error!\n");
+   return;
+   }
+   src_base = of_iomap(np, 0);
+   WARN_ON(!src_base);
+
+   hi6220_reset_dev.of_node = np;
+   if (IS_ENABLED(CONFIG_RESET_CONTROLLER))
+   reset_controller_register(&hi6220_reset_dev);
+}
+
+postcore_initcall(hi6220_reset_init);
+
-- 
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 1/3] arm64: dts: Add reset dts config for Hisilicon Hi6220 SoC

[Chen Feng]

Add reset controller for hi6220 hikey-board.

Signed-off-by: Chen Feng 
---
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..09bb9d1 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,12 @@
clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+
+   reset_ctrl: reset_ctrl@f7030304 {
+   compatible = "hisilicon,hisi_reset_ctl";
+   reg = <0x0 0xf7030304 0x0 0x1000>;
+   #reset-cells = <1>;
+   };
+
};
 };
-- 
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 2/3] reset: hisilicon: document hisi-hi6220 reset controllers bindings

[Chen Feng]

Add DT bindings documentation for hi6220 SoC reset controller.

Signed-off-by: Chen Feng 
---
 .../bindings/reset/hisilicon,hi6220-reset.txt  | 97 ++
 arch/arm64/boot/dts/hisilicon/hi6220.dtsi  |  2 +-
 2 files changed, 98 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt

diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt 
b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
new file mode 100644
index 000..8a23f50
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt
@@ -0,0 +1,97 @@
+Hisilicon System Reset Controller
+==
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+The reset controller node must be a sub-node of the chip controller
+node on SoCs.
+
+Required properties:
+- compatible: may be "hisilicon,hisi_reset_ctl"
+- reg: should be register base and length as documented in the
+  datasheet
+- #reset-cells: 1, see below
+
+Example:
+
+   reset_ctrl: reset_ctrl@f7030304 {
+   compatible = "hisilicon,hi6220_reset_ctl";
+   reg = <0x0 0xf7030304 0x0 0x1000>;
+   #reset-cells = <1>;
+   };
+
+Specifying reset lines connected to IP modules
+==
+example:
+
+uart1: uart1@. {
+   ...
+resets = <&reset_ctrl 0x305>;
+   ...
+};
+
+The following RESET_INDEX values are valid for hi6220 SoC:
+   PERIPH_RSTDIS0_MMC0 = 0x000,
+   PERIPH_RSTDIS0_MMC1 = 0x001,
+   PERIPH_RSTDIS0_MMC2 = 0x002,
+   PERIPH_RSTDIS0_NANDC= 0x003,
+   PERIPH_RSTDIS0_USBOTG_BUS   = 0x004,
+   PERIPH_RSTDIS0_POR_PICOPHY  = 0x005,
+   PERIPH_RSTDIS0_USBOTG   = 0x006,
+   PERIPH_RSTDIS0_USBOTG_32K   = 0x007,
+
+   PERIPH_RSTDIS1_HIFI = 0x100,
+   PERIPH_RSTDIS1_DIGACODEC= 0x105,
+
+   PERIPH_RSTEN2_IPF   = 0x200,
+   PERIPH_RSTEN2_SOCP  = 0x201,
+   PERIPH_RSTEN2_DMAC  = 0x202,
+   PERIPH_RSTEN2_SECENG= 0x203,
+   PERIPH_RSTEN2_ABB   = 0x204,
+   PERIPH_RSTEN2_HPM0  = 0x205,
+   PERIPH_RSTEN2_HPM1  = 0x206,
+   PERIPH_RSTEN2_HPM2  = 0x207,
+   PERIPH_RSTEN2_HPM3  = 0x208,
+
+   PERIPH_RSTEN3_CSSYS = 0x300,
+   PERIPH_RSTEN3_I2C0  = 0x301,
+   PERIPH_RSTEN3_I2C1  = 0x302,
+   PERIPH_RSTEN3_I2C2  = 0x303,
+   PERIPH_RSTEN3_I2C3  = 0x304,
+   PERIPH_RSTEN3_UART1 = 0x305,
+   PERIPH_RSTEN3_UART2 = 0x306,
+   PERIPH_RSTEN3_UART3 = 0x307,
+   PERIPH_RSTEN3_UART4 = 0x308,
+   PERIPH_RSTEN3_SSP   = 0x309,
+   PERIPH_RSTEN3_PWM   = 0x30a,
+   PERIPH_RSTEN3_BLPWM = 0x30b,
+   PERIPH_RSTEN3_TSENSOR   = 0x30c,
+   PERIPH_RSTEN3_DAPB  = 0x312,
+   PERIPH_RSTEN3_HKADC = 0x313,
+   PERIPH_RSTEN3_CODEC_SSI = 0x314,
+   PERIPH_RSTEN3_PMUSSI1   = 0x316,
+
+   PERIPH_RSTEN8_RS0   = 0x400,
+   PERIPH_RSTEN8_RS2   = 0x401,
+   PERIPH_RSTEN8_RS3   = 0x402,
+   PERIPH_RSTEN8_MS0   = 0x403,
+   PERIPH_RSTEN8_MS2   = 0x405,
+   PERIPH_RSTEN8_XG2RAM0   = 0x406,
+   PERIPH_RSTEN8_X2SRAM_TZMA   = 0x407,
+   PERIPH_RSTEN8_SRAM  = 0x408,
+   PERIPH_RSTEN8_HARQ  = 0x40a,
+   PERIPH_RSTEN8_DDRC  = 0x40c,
+   PERIPH_RSTEN8_DDRC_APB  = 0x40d,
+   PERIPH_RSTEN8_DDRPACK_APB   = 0x40e,
+   PERIPH_RSTEN8_DDRT  = 0x411,
+
+   PERIPH_RSDIST9_CARM_DAP = 0x500,
+   PERIPH_RSDIST9_CARM_ATB = 0x501,
+   PERIPH_RSDIST9_CARM_LBUS= 0x502,
+   PERIPH_RSDIST9_CARM_POR = 0x503,
+   PERIPH_RSDIST9_CARM_CORE= 0x504,
+   PERIPH_RSDIST9_CARM_DBG = 0x505,
+   PERIPH_RSDIST9_CARM_L2  = 0x506,
+   PERIPH_RSDIST9_CARM_SOCDBG  = 0x507,
+   PERIPH_RSDIST9_CARM_ETM = 0x508,
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi 
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 09bb9d1..111537a 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -169,7 +169,7 @@
};
 
reset_ctrl: reset_ctrl@f7030304 {
-   compatible = "hisilicon,hisi_reset_ctl";
+   compatible = "hisilicon,hi6220_reset_ctl";
reg = <0x0 0xf7030304 0x0 0x1000>;
 

Re: [PATCH 1/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Wu, Songjun]

On 9/9/2015 17:52, Mark Brown wrote:

On Wed, Sep 09, 2015 at 11:16:08AM +0800, Wu, Songjun wrote:

On 9/8/2015 20:23, Mark Brown wrote:



If you want to have three controls you need to write code so that the
user can only change one of them from 0dB at once, returning an error
otherwise.  That was why it looked like they were three separate
controls.



If user operates two or tree controls at the same time, for my
understanding, these operations are serial actually in kernel, not parallel,
and the last operation will be effective. I only write the function
'classd_get_eq_enum' to get the enumeration value, if user changes one of
controls, the other controls will get 0dB. Is my understanding correct?


Yes, that's what's going to end up happening but it's not how controls
are expected to behave - applications will expect changing one control
to leave others unaffected so it's better to return an error rather than
change the other control.

If application change non EQ controls, the others will be unaffected. 
But the classD IP can only supports one EQ control at once, these three 
EQ controls point to the same register field, if application set a 
different EQ control, the error occurs, there will be many errors, it's 
not very reasonable to application. The best way I think is if 
application set one EQ control, the other EQ controls will change to 
0dB, it's also consistent with fact.

--
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/3] devicetree:bindings: add devicetree bindings for Freescale AHCI

[Yuantian Tang]

> -Original Message-
> From: pku@gmail.com [mailto:pku@gmail.com] On Behalf Of Li Yang
> Sent: Thursday, September 10, 2015 7:19 AM
> To: Tang Yuantian-B29983 
> Cc: Hans de Goede ; t...@kernel.org; linux-
> i...@vger.kernel.org; lkml ;
> devicetree@vger.kernel.org
> Subject: Re: [PATCH 2/3] devicetree:bindings: add devicetree bindings for
> Freescale AHCI
> 
> On Mon, Sep 7, 2015 at 3:23 AM,   wrote:
> > From: Tang Yuantian 
> >
> > adds bindings for Freescale QorIQ AHCI SATA controller.
> >
> > Signed-off-by: Tang Yuantian 
> > ---
> >  .../devicetree/bindings/ata/ahci-fsl-qoriq.txt  | 21
> +
> >  1 file changed, 21 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/ata/ahci-fsl-
> qoriq.txt
> >
> > diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
> b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
> > new file mode 100644
> > index 000..b614e3b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
> > @@ -0,0 +1,21 @@
> > +Binding for Freescale QorIQ AHCI SATA Controller
> > +
> > +Required properties:
> > +  - reg: Physical base address and size of the controller's register area.
> > +  - compatible: Compatibility string. Must be 'fsl,-ahci', where
> > +chip could be ls1021a, ls2085a, ls1043a etc.
> > +  - clocks: Input clock specifier. Refer to common clock bindings.
> > +  - interrupts: Interrupt specifier. Refer to interrupt binding.
> > +
> > +Optional properties:
> > +  - dma-coherent: Enable ACHI coherency DMA operation.
> > +  - reg-names: register area names when there are more then 1 regster
> area.
> 
> A few typos here:
> s/ACHI/AHCI/
> s/coherency/coherent/
> s/then/than/
> s/regster/register/
> 
Can't believe there is so many typos. Will fixed in follow-up patch.

Thanks,
Yuantian
> Regards,
> Leo

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Viresh Kumar]

On 09-09-15, 17:57, Stephen Boyd wrote:
> I think it will work for qcom use cases.

Thanks for the Rant Rob, it finally got me moving :)

> We can collapse the
> tables down to one node and have speed bin and version as the
> opp-supported-hw property. The opp-microvolt-names property would

I am probably going to remove opp-microvolt-names property as well, if
we are going to use separate entries for all voltage ranges in OPP
node. i.e. two voltage ranges, slow and fast, like this:

 regulator A   regulator B
opp-microvolt-slow = , ;
opp-microvolt-fast = , ;

> be where we put the different voltage bins. What about the other
> properties like opp-microamp or opp-suspend? Will all of those

Lets keep them as is for now, unless we have a real user.

> also get *-names properties to index into them based on some
> string? I don't actually need those for my devices, but I'm just
> pointing it out in case someone else wants to compress tables but
> they have different microamps or clock latencies, etc.
> 
> Finally, does this mean we will get rid of operating-points-names?

That's the next thing I wanted to ask from Rob. We are surely not
going to use them and there are no users or kernel code to support
them today. Can we get rid of them from the DT ?

-- 
viresh
--
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/2] dt: power: st: Provide bindings for ST's OPPs

[Stephen Boyd]

On 09/09, Rob Herring wrote:
> On 09/09/2015 11:36 AM, Lee Jones wrote:
> >>> Or have I got the wrong end of the stick?
> >>>
> >>> NB: Note the suggested new property names.
> >>
> >> Yeah, all looks fine to me.
> > 
> > I think these names are better:
> > 
> >   opp-supply-range-name => opp-microvolt-names
> >   opp-cuts  => opp-supported-hw
> > 
> > Apart from that, the binding is starting to come together.
> > 
> > Let's see what Rob and Stephen have to say about it.
> 
> Seems reasonable to me.

I think it will work for qcom use cases. We can collapse the
tables down to one node and have speed bin and version as the
opp-supported-hw property. The opp-microvolt-names property would
be where we put the different voltage bins. What about the other
properties like opp-microamp or opp-suspend? Will all of those
also get *-names properties to index into them based on some
string? I don't actually need those for my devices, but I'm just
pointing it out in case someone else wants to compress tables but
they have different microamps or clock latencies, etc.

Finally, does this mean we will get rid of operating-points-names?

-- 
Qualcomm Innovation Center, Inc. is a member of 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] spmi-pmic-arb: support configurable number of peripherals

[Stephen Boyd]

On 09/09, Gilad Avidov wrote:
> On Fri, 4 Sep 2015 17:50:11 -0700
> Stephen Boyd  wrote:
> 
> > On 09/04, Gilad Avidov wrote:
> > > On Thu, 3 Sep 2015 17:16:30 -0700
> > > Stephen Boyd  wrote:
> > > 
> > > > On 09/03, Gilad Avidov wrote:
> 
> I agree that the algorithm is not complicated. However, I still think
> that just reading max of 512 registers is simpler and overhead is small.
> 
> > 
> > > 
> > > > processing to when we're mapping irqs, hopefully speeding up
> > > > probe for the case where you have a handful of irqs to map.
> > > 
> > > Please note that we traverse this mapping table every time a PMIC
> > > driver registers for an interrupt. This means that even if we speed
> > > up the probe of pmic-arb driver we will not speed the system boot
> > > since the probing of the PMIC drivers will register for interrupts.
> > 
> > Do we need to read all 512 entries for a typical system? If we do
> > then I agree reading it all upfront is probably better, but if we
> > only read a sparse amount of entries then we can defer it to when
> 
> We need a many of the 512 entries since for each request_irq() we
> traverse down the. Typically during boot pmic drivers request irqs.
> 
> > it's going to be used. On upstream 8974 dts files with all the
> > devices we have in DT right now, I see 75 unique register reads
> > during boot on apq8074 dragonboard.
> > 
> 
> There are still very few of pmic driver upstreamed. However, many more
> of them are likely to get upstreamed soon. Once all of them will be
> active on upstream I am sure that the number of register access will
> dramatically increase (just as it is today on Codeaurora).

So on the latest hardware I see 33 unique register reads. That's
on the codeaurora android tree. It seems to be less than on 8974.
I'll have to boot up the android tree on 8974 to see how much it
is. The patch is simple:

diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index d7119db49cfe..8aea9f57f7af 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -603,6 +603,7 @@ static int search_mapping_table(struct spmi_pmic_arb_dev 
*pa,
 
for (i = 0; i < SPMI_MAPPING_TABLE_TREE_DEPTH; ++i) {
data = mapping_table[index];
+   pr_info("mapping table %d\n", index);
 
if (ppid & (1 << SPMI_MAPPING_BIT_INDEX(data))) {
if (SPMI_MAPPING_BIT_IS_1_FLAG(data)) {


And then

$ dmesg | grep "mapping table " | sort -u | wc -l

> 
> > > 
> > > > 
> > > > The DT property wouldn't be necessary then. Arguably it's being
> > > > added there to optimize the size of the mapping table and isn't
> > > > really necessary otherwise.
> > > > 
> > > 
> > > We need to know this value for both memory allocation
> > > and for stopping before reading over the bounds of the
> > > mapping_table in HW.
> > > 
> > 
> > Presumably the hardware is correct and isn't telling us to read
> 
> HW tells us nothing about the size of the HW mapping table.
> 
> > entries in the mapping table that are beyond the bounds, so
> > stepping over the bounds of the mapping table cache isn't
> > possible if we always make it the size of the biggest table.
> > 
> 
> The size of the table in RAM is the driver writer choice. It is
> wasteful to have it larger then needed but no harm to stability.
> On the flip side, reading registers beyond the HW bounds can have
> undefined behavior. 

Sure. We could realloc the table at runtime if we really care
about saving the space.

> 
> > @@ -706,11 +712,37 @@ static u32 pmic_arb_offset_v1(struct
> > spmi_pmic_arb_dev *pa, u8 sid, u16 addr) return 0x800 + 0x80 *
> > pa->channel; }
> >  
> > +static u16 find_chan(struct spmi_pmic_arb_dev *pa, u16 ppid)
> > +{
> > +   u32 regval;
> > +   u16 chan;
> > +   u16 _ppid;
> > +
> > +   for (chan = pa->last_channel; ; chan++, pa->last_channel++) {
> > +   regval = readl_relaxed(pa->core +
> > PMIC_ARB_REG_CHNL(chan));
> > +   if (!regval)
> > +   continue;
> > +
> 
> I'm pretty sure that caching this table is way faster then searching it
> by reading from hw per any newly used apid. If we use 512 peripherals
> then we will read this table 512 times.

You missed the part where we don't read this table from hardware
more than once. We read the hw table linearly until we find the
ppid that we were looking for, caching other values along the
way. If that happens to be the whole table then I guess we don't
win anything by doing it here vs. in probe, but hopefully we
don't have to search the entire table on the first try to find
the ppid.

> 
> > +   _ppid = (regval >> 8) & PMIC_ARB_PPID_MASK;
> > +   pa->ppid_to_chan[_ppid] = chan | PMIC_ARB_PPID_VALID;
> > +   if (_ppid == ppid)
> > +   break;
> > +   }
> > +
> > +   return chan;
> > +}
> > +
> > +
> >  /* v2 offset per ppid (chan) and per ee */
> >  static u32 pmic_arb_offset_v2(struct spmi_pmic_arb_dev *pa, u8

Re: [PATCH v2 13/13] dt: power: bq2425x-charger: Cover additional devices

[Krzysztof Kozlowski]

On 10.09.2015 05:15, Andreas Dannenberg wrote:
> On Wed, Sep 09, 2015 at 01:58:09PM +0900, Krzysztof Kozlowski wrote:
>>
>> So we have different bindings. Existing ones:
>> bq2415x.txt - ti,charge-current - maximum charging current in mA
>> bq24257.txt - ti,charge-current - maximum charging current in uA
>> bq25890.txt - ti,charge-current - maximum charging current in uA
>> bq24735.txt - ti,charge-current - charge current (?) in mA
> 
> I just spent some time with the bq24735 datasheet and the way that
> device appears to work is putting the user in control of the charging
> process rather than implementing a fully automatic control loop, but
> either way I still think it's valid to call the property
> ti,charge-current and use a description of "maximum charging current"
> for that device (there is no DT bindings doc however). And yes the unit
> is mA as one can see from reverse-engineering the register settings.

Just for the record: the units used by device registers are not related
to units used in DT binding. You can use whatever you want. The driver
should just convert them.

> 
> On a related note the datasheet for that device says you have to
> periodically re-send the charge current setting every 44...175s to keep
> charging with the configured current or disable the device's watchdog
> timer. Neither of which the driver seems to do. I can probably go back
> and get some HW and test if that driver actually works as advertised.
> (also see http://www.ti.com/lit/ds/symlink/bq24735.pdf, Page 21)

I mentioned existing bindings for reference. To show that it's a mess.
However you cannot change them now (at least easily). You could add new
bindings and mark old as deprecated (still they would have to be
supported by the driver)...

> 
>> bq2415x.txt - ti,current-limit  - maximum current to be drawn in mA
>>
>> New bindings:
>> ti,charge-current (bq24261) - default charge current in mA
>> ti,max-charge-current (bq24261) - maximum charging current in mA
> 
> This ti,max-charge-current is actually an interesting one. It's not a
> device setting as it does not impact any of the device registers at all.
> Instead, it's an artificial limit that can be set through DT that
> prevents somebody from going into sysfs and configuring a charge current
> higher than ti,max-charge-current. In other drivers I have seen that the
> sysfs property reflecting that max charge current is just read-only and
> gives you the maximum the HW is capable of. From a device point of view
> there is nothing configurable about this property.

Hmmm, so now I wonder whether this should be a DT binding. The purpose
of DT isn't the control of the driver like enable some stuff, set some
value used by the driver. The DT provides information about hardware so
the driver could properly configure the device and work with it.

Reason to put this into DT would be:
For example one device configuration (device, board, connected battery)
could handle one maximum value and the other configuration would require
lower one. The device and its capabilities (bq24257 for example) are the
same but configuration changes.


If all configurations of bq24261 device have the same maximum value then
it should not be a DT property but it should be hard-coded in the driver
instead.

Ramakrishna,
Could you describe the reason behind "ti,max-charge-current" and
"pdata.max_cc" in bq24261 driver?

> 
>> ti,current-limit (bq2425x) - maximum current to be drawn in uA
>>
>>
>> Damn it... It's a mess. And there is no device prefixes...
> 
> ACK :)  Let's see how we can bring a little sense into it.
>  
>> The bq24261's bindings look most sensible (max prefix for max charge
>> current) but they are not compatible with existing bindings for
>> different devices.
> 
> Hmm I think they are compatible, it's just a question making the DT
> bindings description for the bq24261 fit better into what's already
> there. For example, like this:
> 
> (1) ti,charge-current: integer, maximum charging current in mA. For this
> device as for others this setting controls the max current the device
> uses to charge the battery so the established description is good
> however the general use of this property name itself is not 100%
> accurate (too late for that).

I agree.

> (2) ti,max-charge-current: Unless there is a good reason to keep it,
> REMOVE this property (alongside ti,max-charge-voltage). Instead, have
> the charger directly report back the maximum device charge current
> (BQ24261_MAX_CC) via sysfs like most other charger drivers do (bq24190,
> bq24257, bq25890, rt9455).

I agree but wait for some more data from Ramakrishna.

> 
>> There is no way to unify or make consistent all of these bindings.
>> However one could try to add new stuff in a more sensible way. For
>> example how about (for bq2425x-charger and bq24261_charger... BTW notice
>> even the difference in using underscore and hyphen!):
> 
> :(  You are talking about the driver .name, right? I saw that too. If
> the bq242

Re: [PATCH linux-next v9 2/3] mfd: devicetree: add bindings for Atmel Flexcom

[Rob Herring]

On 09/09/2015 10:45 AM, Cyrille Pitchen wrote:
> Hi Rob,
> 
> Le 09/09/2015 01:40, Rob Herring a écrit :
>> On 09/01/2015 09:46 AM, Cyrille Pitchen wrote:
>>> This patch documents the DT bindings for the Atmel Flexcom which will be
>>> introduced by sama5d2x SoCs. These bindings will be used by the actual
>>> Flexcom driver to be sent in another patch.
>>>
>>> Signed-off-by: Cyrille Pitchen 
>>> Acked-by: Boris Brezillon 
>>> Acked-by: Alexandre Belloni 
>>
>> A few comments, but in general looks fine.
>>
>>> ---
>>>  .../devicetree/bindings/mfd/atmel-flexcom.txt  | 67 
>>> ++
>>>  1 file changed, 67 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
>>> b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>>> new file mode 100644
>>> index ..fc3511e41542
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>>> @@ -0,0 +1,67 @@
>>> +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication 
>>> Unit)
>>> +
>>> +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
>>> +controller and an USART. Only one function can be used at a time and is 
>>> chosen
>>> +at boot time according to the device tree.
>>
>> Doesn't the board design choose (unless pins go to a header)?
>>
> 
> The function may be chosen once for all by the board design but if we take the
> sama5d2 xplained board as an example, most Flexcoms output their pins to
> headers.
> 
>>> +
>>> +Required properties:
>>> +- compatible:  Should be "atmel,sama5d2-flexcom"
>>> +- reg: Should be the offset/length value for Flexcom 
>>> dedicated
>>> +   I/O registers (without USART, TWI or SPI registers).
>>> +- clocks:  Should be the Flexcom peripheral clock from PMC.
>>> +- #address-cells:  Should be <1>
>>> +- #size-cells: Should be <1>
>>> +- ranges:  Should be one range for the full I/O register region
>>> +   (including USART, TWI and SPI registers).
>>> +- atmel,flexcom-mode:  Should be one of the 3 following macros as 
>>> defined in
>>> +   include/dt-bindings/mfd/atmel-flexcom.h:
>>> +   - ATMEL_FLEXCOM_MODE_USART for USART
>>> +   - ATMEL_FLEXCOM_MODE_SPI for SPI
>>> +   - ATMEL_FLEXCOM_MODE_TWI for I2C
>>> +
>>> +Required child:
>>> +a single child device of type matching the "atmel,flexcom-mode" property.
>>
>> Okay, but why not allow all children and use "status"?
>>
> 
> That is exactly what was proposed in v6 of this series: allow more than one
> child so possibly all children but only one "available" child (status = 
> "okay").
> 
> The Flexocm driver still needs to find out the type of device of this
> available child to know which function is to be enabled (USART, I2C or SPI).
> So the "compatible" attribute was parsed using strstr() to search on of the
> patterns "usart", "spi" or "i2c".
> 
> However the use of strstr() was discussed to know whether the driver should
> looks for a partial or an exact match of the "compatible" string.
> An exact match would require to keep the Flexcom driver synchonized with the
> 3 other drivers every time one of them introduces a new compatibility string,
> which whould have made every driver more difficult to maintain by creating a
> useless dependency.
> So this implementation relying on the "compatible" attribute was abandoned.
> 
> To sum up, no other reliable (and simple) means to guess/extact the device
> type from its DT node was found so we got back to the "atmel,flexcom-mode"
> property.

I wasn't thinking removing this property. If the mode is configured by
the bootloader, then you want to make updates to the configuration as
simple as possible. Updating atmel,flexcom-mode and status for the
children would be much more simple than creating the whole child node.
If that's not a valid usecase, then never mind.

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 v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Rob Herring]

On 09/09/2015 11:36 AM, Lee Jones wrote:
>>> Or have I got the wrong end of the stick?
>>>
>>> NB: Note the suggested new property names.
>>
>> Yeah, all looks fine to me.
> 
> I think these names are better:
> 
>   opp-supply-range-name => opp-microvolt-names
>   opp-cuts  => opp-supported-hw
> 
> Apart from that, the binding is starting to come together.
> 
> Let's see what Rob and Stephen have to say about it.

Seems reasonable to me.

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 v2 04/10] doc/bindings: Update PCIe devicetree binding documentation for LS2080A

[Li Yang]

On Wed, Sep 9, 2015 at 4:07 AM, Arnd Bergmann  wrote:
> On Tuesday 08 September 2015 15:06:16 Li Yang wrote:
>> On Mon, Sep 7, 2015 at 6:32 AM, Arnd Bergmann  wrote:
>> > On Friday 04 September 2015 12:27:46 Bhupesh Sharma wrote:
>> >> @@ -4,7 +4,8 @@ This PCIe host controller is based on the Synopsis 
>> >> Designware PCIe IP
>> >>  and thus inherits all the common properties defined in 
>> >> designware-pcie.txt.
>> >>
>> >>  Required properties:
>> >> -- compatible: should contain the platform identifier such as 
>> >> "fsl,ls1021a-pcie"
>> >> +- compatible: should contain the platform identifier such as 
>> >> "fsl,ls1021a-pcie",
>> >> +  "fsl,ls2080a-pcie".
>> >>  - reg: base addresses and lengths of the PCIe controller
>> >>  - interrupts: A list of interrupt outputs of the controller. Must 
>> >> contain an
>> >>entry for each entry in the interrupt-names property.
>> >>
>> >
>> > Are the two PCIe hosts mutually compatible? If they are, you should mandate
>> > one of the strings as the base model for identification, with the 
>> > additional
>> > model being optional for identification of the specific SoC.
>>
>> It seems that controllers on these chips are not exactly the same.
>> They will get different driver data by matching the compatible
>> strings.  Probably we could define a more generic compatible string,
>> such as "fsl,layerscape-pcie" or "fsl,ls-pcie".
>>
>> >
>> > It would also be good to add a string with the specific version number of 
>> > the
>> > designware PCIe block that is being used there.
>>
>> The binding has mentioned to reference the designware-pcie.txt.  But
>> it might be more clear to mention the designware compatible string
>> "snps,dw-pcie" again in the compatible part.  Currently there is no
>> version number defined in the designware-pcie binding.  It might be
>> hard to get this information for some SoCs.
>
> For most of them, the information is available and then it should be
> added. Obviously if you can't find it out, it's hard to guess and
> you have to leave it out for that particular chip.

Actually I don't know any approach to get the version number of the
designware block used.  Maybe they are actually using the same version
of the IP block, and the differences in the driver are actually caused
by the differences in SoC integration.

>
> A lot of devices also have some internal version register that you
> can read out.

There doesn't seem to be this kind of register for the PCIe block.

Minghuan,

Please correct me if you know more. :)

Regards,
Leo
--
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] power: bq24261_charger: Add support for TI BQ24261 charger

[Krzysztof Kozlowski]

On 10.09.2015 02:31, Andreas Dannenberg wrote:
> On Wed, Sep 09, 2015 at 01:17:11PM +0900, Krzysztof Kozlowski wrote:
>> On 09.09.2015 11:26, Andreas Dannenberg wrote:
>>> Krzysztof, good observation! In bq2425x_charger.c (formerly known as
>>> bq24257_charger.c :) that I worked on the unit used was uA. At that time
>>> I did a quick check and there didn't seem to be a clear standard whether
>>> to use the "micro" or "milli" units - different drivers use different
>>> units. However there seems to be a tendency for the TI drivers to prefer
>>> "milli" (bq2415x_charger.c, bq24735-charger.c)
>>>
>>> Personally I think "milli" units are more appropriate for chargers since
>>> they provide sufficient granularity and the numbers don't become too big
>>> (try typing a voltage in the Volt-range in uV, it's very easy to get the
>>> number of 0s wrong). However since the driver was already there I left
>>> that aspect alone to preserve compatibility.
>>
>> I am fine with both units but milli indeed seems easier to judge by fast
>> looking and less error-prone. Whatever you choose - choose the same one. :)
> 
> Ok sounds good. If so, I could go ahead and change the units in the
> bq2425x_charger.c over to mA and mV?

Wait, these are existing bindings (for bq24257). You cannot change
existing binding.

Best regards,
Krzysztof

> It would be a bit labor some and I
> also want to see what Laurentiu thinks but this way we could have most
> of those TI charger drivers use the same units (the new bq24261 driver
> Ram posted also uses mA/mV). Except bq25890_charger.c that would
> still use uA/uV
> 
> Laurentiu -- what made you chose the "micro" units for bq24257_charger.c
> and bq25890_charger.c?



--
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] power: bq24261_charger: Add support for TI BQ24261 charger

[Krzysztof Kozlowski]

On 10.09.2015 03:11, Pallala, Ramakrishna wrote:
>>> +Optional properties:
>>> +- ti,thermal-sensing: boolean, if present thermal regulation will be
>>> +enabled;
>>
>> What is the requirement for thermal-sensing? Can it be enabled always?
>> If yes, then this is not really a hardware property.
> TI BQ24261 has provision to add Battery Pack thermistor but it has no ADC 
> read it.
> So a HW designer would or may not add the thermistor to charger and instead 
> he can
> connect to the Fuel Gauge.

Thanks for explanation, makes sense.

> 
>>> +- ti,enable-user-write: boolean, if present driver will allow the user 
>>> space
>>> +to control the charging current and voltage through sysfs;
>>
>> This is not DT property. It does not describe hardware.
> We needed a mechanism to enable the sysfs writes on certain properties.
> If DT is not the place where should it go?

DT is not the place. As I discussed later with Andreas, if you really
need this and if mainline is a place for that then probably this should
be compile option (a Kconfig symbol).

I found one more issue after Andreas comments but I respond in that email.

Best regards,
Krzysztof
--
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 03/10] Documentation/dts: Add bindings for QIXIS FPGA controller found on FSL boards

[Li Yang]

On Sat, Sep 5, 2015 at 3:11 AM, Sharma Bhupesh
 wrote:
>> From: pku@gmail.com [mailto:pku@gmail.com]
>> Sent: Saturday, September 05, 2015 2:43 AM
>> On Fri, Sep 4, 2015 at 3:16 PM, Sharma Bhupesh
>>  wrote:
>> >> From: pku@gmail.com [mailto:pku@gmail.com]
>> >> Sent: Friday, September 04, 2015 10:27 PM On Fri, Sep 4, 2015 at 1:57
>> >> AM, Bhupesh Sharma  wrote:
>> >> > This patch adds bindings for QIXIS FPGA controller found on FSL
>> boards.
>> >>
>> >> A general comment: when you are updating the device tree bindings.
>> >> You should cc the devicetree@vger.kernel.org mailing list.
>> >>
>> >> >
>> >> > Some Freescale boards like LS2080AQDS/LS2080ARDB have an on-board
>> >> > FPGA/CPLD connected to the IFC controller. The bindings specified
>> >> > in this patch cater to those on-board FPGA/CPLD controllers.
>> >>
>> >> We already have the binding defined in
>> >> Documentation/devicetree/bindings/powerpc/fsl/board.txt.  We probably
>> >> should just move it to a more generic location.
>> >
>> > Consolidation of powerpc and ARM bindings is something that needs to
>> > be targeted by a separate patch-series, perhaps in future.
>> >
>> > There are a number of duplications that can be looked into, but I
>> > don't think this patchset should depend on that.
>>
>> There might be some duplication, but we shouldn't be adding more.  :) I
>> would rather you directly updating that file than creating a new file
>> even though the original one was in a wrong directory.
>>
>
> IMO a PowerPC binding update makes no sense in a ARM machine patchset sent
> on a arm specific mailing list.

So the best approach is to merge the change with the original binding
and put it into a common place.  Although there were a lot of non-arch
specific bindings placed into the arch folder, we should stop adding
more now.

Regards,
Leo
--
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] spmi-pmic-arb: support configurable number of peripherals

[Gilad Avidov]

On Fri, 4 Sep 2015 17:50:11 -0700
Stephen Boyd  wrote:

> On 09/04, Gilad Avidov wrote:
> > On Thu, 3 Sep 2015 17:16:30 -0700
> > Stephen Boyd  wrote:
> > 
> > > On 09/03, Gilad Avidov wrote:
> > > > +supported by HW. Default (minimum
> > > > supported) is 128. +
> > > > +Example V1 PMIC-Arbiter:
> > > >  
> > > > spmi {
> > > > compatible = "qcom,spmi-pmic-arb";
> > > > @@ -62,4 +66,32 @@ Example:
> > > >  
> > > > interrupt-controller;
> > > > #interrupt-cells = <4>;
> > > > +
> > > > +   qcom,max-peripherals = <256>;
> > > 
> > > If it's v1 isn't it always 128? So having 256 here is just
> > > confusing.
> > 
> > Hi Stephen,
> > 
> > Actually some v1 chipsets, such as Dragonboard APQ8074, support 256
> > peripherals.
> 
> Then the commit text should be updated. It only mentions that v2
> HW has sub-versions which support more than 128.
> 

Correct, I'll update the commit text.

> > 
> > > 
> > > > +   };
> > > > +
> > > > @@ -129,14 +131,15 @@ struct spmi_pmic_arb_dev {
> > > > u8  channel;
> > > > int irq;
> > > > u8  ee;
> > > > -   u8  min_apid;
> > > > -   u8  max_apid;
> > > > -   u32
> > > > mapping_table[SPMI_MAPPING_TABLE_LEN];
> > > > +   u16 min_irq_apid;
> > > > +   u16 max_irq_apid;
> > > > +   u16 max_apid;
> > > > +   u32 *mapping_table;
> > > > struct irq_domain   *domain;
> > > > struct spmi_controller  *spmic;
> > > > -   u16 apid_to_ppid[256];
> > > > +   u16 *irq_apid_to_ppid;
> > > 
> > > Please drop all this renaming noise, or at the least, put it in a
> > > different patch. More than half the patch is just changing the
> > > names of these variables for what seems like no reason.
> > > 
> > 
> > Regarding the change of max/min_apid to max/min_irq_apid:
> > max_apid was already used but the name does not make good sense.
> > Since really it is not the max_apid supported. Instead it is the
> > largest apid which interrupt is currently requested for. But now we
> > need a value that is actually the maximum supported apid. This is
> > why repurposed max_apid and corrected the previous naming.
> 
> max_apid in this patch is only used in probe, so there's no need
> for that variable to be a member of the structure. Meaning we can
> leave max_apid alone and call this new variable max_periphs or
> something like that and leave it local to the probe function.
> 

I'll avoid the renaming altogether.

> > 
> > > > const struct pmic_arb_ver_ops *ver_ops;
> > > > -   u8  *ppid_to_chan;
> > > > +   u16 *ppid_to_chan;
> > > >  };
> > > >  
> > > > struct spmi_pmic_arb_dev *pa =
> > > > irq_get_handler_data(irq); struct irq_chip *chip =
> > > > irq_get_chip(irq); void __iomem *intr = pa->intr;
> > > > -   int first = pa->min_apid >> 5;
> > > > -   int last = pa->max_apid >> 5;
> > > > +   int first = pa->min_irq_apid >> 5;
> > > > +   int last = pa->max_irq_apid >> 5;
> > > > u32 status;
> > > > int i, id;
> > > >  
> > > > @@ -903,14 +915,30 @@ static int spmi_pmic_arb_probe(struct
> > > > platform_device *pdev) 
> > > > pa->ee = ee;
> > > >  
> > > > -   for (i = 0; i < ARRAY_SIZE(pa->mapping_table); ++i)
> > > > -   pa->mapping_table[i] = readl_relaxed(
> > > > -   pa->cnfg +
> > > > SPMI_MAPPING_TABLE_REG(i));
> > > > +   pa->irq_apid_to_ppid = devm_kzalloc(&ctrl->dev,
> > > > pa->max_apid *
> > > > +
> > > > sizeof(*pa->irq_apid_to_ppid),
> > > > +   GFP_KERNEL);
> > > > +   if (!pa->irq_apid_to_ppid) {
> > > > +   err = -ENOMEM;
> > > > +   goto err_put_ctrl;
> > > > +   }
> > > > +
> > > > +   pa->mapping_table = devm_kzalloc(&ctrl->dev,
> > > > +   (pa->max_apid - 1) *
> > > > sizeof(u32),
> > > > +   GFP_KERNEL);
> > > > +   if (!pa->mapping_table) {
> > > > +   err = -ENOMEM;
> > > > +   goto err_put_ctrl;
> > > > +   }
> > > > +
> > > > +   for (i = 0; i < (pa->max_apid - 1); ++i)
> > > > +   pa->mapping_table[i] = readl_relaxed(pa->cnfg +
> > > > +
> > > > SPMI_MAPPING_TABLE_REG(i));
> > 
> > > we're searching through the mapping table we can cache the value
> > > from the register if the entry isn't 0. This delays the
> > 
> > Greedy approach (reading upto 512 registers from hw) have very small
> > upfront penalty since sequential reads take place very fast
> > and HW acceleration (prefetching) will improve it. A lazy approach
> > will required much more 

Re: [PATCH 2/3] devicetree:bindings: add devicetree bindings for Freescale AHCI

[Li Yang]

On Mon, Sep 7, 2015 at 3:23 AM,   wrote:
> From: Tang Yuantian 
>
> adds bindings for Freescale QorIQ AHCI SATA controller.
>
> Signed-off-by: Tang Yuantian 
> ---
>  .../devicetree/bindings/ata/ahci-fsl-qoriq.txt  | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
>
> diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt 
> b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
> new file mode 100644
> index 000..b614e3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
> @@ -0,0 +1,21 @@
> +Binding for Freescale QorIQ AHCI SATA Controller
> +
> +Required properties:
> +  - reg: Physical base address and size of the controller's register area.
> +  - compatible: Compatibility string. Must be 'fsl,-ahci', where
> +chip could be ls1021a, ls2085a, ls1043a etc.
> +  - clocks: Input clock specifier. Refer to common clock bindings.
> +  - interrupts: Interrupt specifier. Refer to interrupt binding.
> +
> +Optional properties:
> +  - dma-coherent: Enable ACHI coherency DMA operation.
> +  - reg-names: register area names when there are more then 1 regster area.

A few typos here:
s/ACHI/AHCI/
s/coherency/coherent/
s/then/than/
s/regster/register/

Regards,
Leo
--
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] ahci: added a new driver for supporting Freescale AHCI sata

[Li Yang]

On Sun, Sep 6, 2015 at 12:39 AM, Yuantian Tang
 wrote:
> Hi,
>
{snip}
>>
>> This will break booting new kernels with old dtb files, something which in
>> general is considered a big non-no, I suggest adding a comment that this has
>> been superseded by the new ahci_qoriq.c code, and maybe add a date to
>> retire the compatible in say a year from now.
>>
> There is no old dtb because LS* platforms are not been upstreamed yet.
> So I think we can safely replace it without breaking anything.

Please make sure all the internal development trees are updated
complying to this new binding.

Regards,
Leo
--
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 v3] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.

[David Daney]

From: David Daney 

It is perfectly legitimate for a PCI device to have an
PCI_INTERRUPT_PIN value of zero.  This happens if the device doesn't
use interrupts, or on PCIe devices, where only MSI/MSI-X are
supported.

Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
messages by moving the printing code into of_irq_parse_pci(), and only
emitting the message for cases where PCI_INTERRUPT_PIN == 0 is not the
cause for an early exit.

Signed-off-by: David Daney 
---

Changes in v3: Also print the message for failures in
of_irq_parse_raw() (also suggested by Frank Rowand).

Changes in v2: Move the print function in to of_irq_parse_pci() at a
common error exit point (as suggested by Frank Rowand).


 drivers/of/of_pci_irq.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 1710d9d..2306313 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -38,8 +38,8 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq
 */
rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
if (rc != 0)
-   return rc;
-   /* No pin, exit */
+   goto err;
+   /* No pin, exit with no error message. */
if (pin == 0)
return -ENODEV;
 
@@ -53,8 +53,10 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq
ppnode = pci_bus_to_OF_node(pdev->bus);
 
/* No node for host bridge ? give up */
-   if (ppnode == NULL)
-   return -EINVAL;
+   if (ppnode == NULL) {
+   rc = -EINVAL;
+   goto err;
+   }
} else {
/* We found a P2P bridge, check if it has a node */
ppnode = pci_device_to_OF_node(ppdev);
@@ -86,7 +88,13 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq
out_irq->args[0] = pin;
laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
laddr[1] = laddr[2] = cpu_to_be32(0);
-   return of_irq_parse_raw(laddr, out_irq);
+   rc = of_irq_parse_raw(laddr, out_irq);
+   if (rc)
+   goto err;
+   return 0;
+err:
+   dev_err(&pdev->dev, "of_irq_parse_pci() failed with rc=%d\n", rc);
+   return rc;
 }
 EXPORT_SYMBOL_GPL(of_irq_parse_pci);
 
@@ -105,10 +113,8 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 
slot, u8 pin)
int ret;
 
ret = of_irq_parse_pci(dev, &oirq);
-   if (ret) {
-   dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n", 
ret);
+   if (ret)
return 0; /* Proper return code 0 == NO_IRQ */
-   }
 
return irq_create_of_mapping(&oirq);
 }
-- 
1.7.11.7

--
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] power: bq24261_charger: Add support for TI BQ24261 charger

[Alexey Klimov]

Hi Ramakrishna,

On Sun, Sep 6, 2015 at 8:23 PM, Ramakrishna Pallala
 wrote:
> Add new charger driver support for BQ24261 charger IC.
>
> BQ24261 charger driver relies on extcon notifications to get the
> charger cable type and based on that it will set the charging parameters.
>
> Signed-off-by: Ramakrishna Pallala 
> Signed-off-by: Jennt TC 
> ---
>  .../devicetree/bindings/power/bq24261.txt  |   37 +
>  drivers/power/Kconfig  |6 +
>  drivers/power/Makefile |1 +
>  drivers/power/bq24261_charger.c| 1208 
> 

[..]

> +static int bq24261_probe(struct i2c_client *client,
> +const struct i2c_device_id *id)
> +{
> +   struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> +   struct power_supply_config charger_cfg = {};
> +   struct bq24261_charger *chip;
> +   int ret;
> +   enum bq2426x_model model;
> +
> +   adapter = to_i2c_adapter(client->dev.parent);

Please also check if you really need to call to_i2c_adapter() twice.

-- 
Best regards, Klimov Alexey
--
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] power: bq24261_charger: Add support for TI BQ24261 charger

[Andreas Dannenberg]

Hi Ram, thanks for submitting this, please see some feedback inlined...

On Sun, Sep 06, 2015 at 10:53:07PM +0530, Ramakrishna Pallala wrote:
> Add new charger driver support for BQ24261 charger IC.
> 
> BQ24261 charger driver relies on extcon notifications to get the
> charger cable type and based on that it will set the charging parameters.
> 
> Signed-off-by: Ramakrishna Pallala 
> Signed-off-by: Jennt TC 
> ---
>  .../devicetree/bindings/power/bq24261.txt  |   37 +
>  drivers/power/Kconfig  |6 +
>  drivers/power/Makefile |1 +
>  drivers/power/bq24261_charger.c| 1208 
> 
>  include/linux/power/bq24261_charger.h  |   27 +
>  5 files changed, 1279 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/bq24261.txt
>  create mode 100644 drivers/power/bq24261_charger.c
>  create mode 100644 include/linux/power/bq24261_charger.h
> 
> diff --git a/Documentation/devicetree/bindings/power/bq24261.txt 
> b/Documentation/devicetree/bindings/power/bq24261.txt
> new file mode 100644
> index 000..25fc5c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/bq24261.txt
> @@ -0,0 +1,37 @@
> +Binding for TI bq24261 Li-Ion Charger
> +
> +Required properties:
> +- compatible: Should contain one of the following:
> +* "ti,bq24261"
> +- reg: integer, i2c address of the device.
> +- ti,charge-current: integer, default charging current (in mA);
> +- ti,charge-voltage: integer, default charging voltage (in mV);

If you look at other chargers (bq2415x, bq24257, ...) this property
should probably be called ti,battery-regulation-voltage.

> +- ti,termination-current: integer, charge will be terminated when current in
> +constant-voltage phase drops below this value (in mA);

> +- ti,max-charge-current: integer, maximum charging current (in mA);
> +- ti,max-charge-voltage: integer, maximum charging voltage (in mV);

What's the background of having these two properties? They don't impact
any device HW settings, but rather look like some safeguard if somebody
manipulates the sysfs to not exceed certain boundaries.

> +- ti,min-charge-temperature: integer, minimum charging temperature (in DegC);
> +- ti,max-charge-temperature: integer, maximum charging temperature (in DegC).

All this does is passing these values down to the sysfs and exposing
them through POWER_SUPPLY_PROP_TEMP_MAX/POWER_SUPPLY_PROP_TEMP_MIN. What
value does this provide?

> +
> +Optional properties:
> +- ti,thermal-sensing: boolean, if present thermal regulation will be enabled;

I received feedback for one of my recent patches that it's better to use an
integer property as it can be overridden and with that is more
flexible.

> +- ti,enable-user-write: boolean, if present driver will allow the user space
> +to control the charging current and voltage through sysfs;

This idea came from me :) but we should probably get rid of this
capability. And the writability of charge current/voltage properties
through sysfs altogether. My use case for this was to enable better
testing but there is other ways this can be accomplished. However since
some other drivers expose such capability I wonder what other
reasons/use cases there might be (besides helping development and
testing)?

> +
> +Example:
> +
> +bq25890 {
> +compatible = "ti,bq24261
> +reg = <0x6b>;
> +
> +ti,charge-current = <1000>;
> +ti,charge-voltage = <4200>;
> +ti,termination-current = <128>;
> +ti,max-charge-current = <3000>;
> +ti,max-charge-voltage = <4350>;
> +ti,min-charge-temperature = <0>;
> +ti,max-charge-temperature = <60>;
> +
> +ti,thermal-sensing;
> +ti,enable-user-write;
> +};
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index f8758d6..cd47d0d 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -396,6 +396,12 @@ config CHARGER_BQ24190
>   help
> Say Y to enable support for the TI BQ24190 battery charger.
>  
> +config CHARGER_BQ24261
> + tristate "TI BQ24261 charger driver"
> + depends on I2C && EXTCON
> + help
> +   Say Y here to enable support for TI BQ24261 battery charger.
> +
>  config CHARGER_BQ24257
>   tristate "TI BQ24257 battery charger driver"
>   depends on I2C
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 5752ce8..bec8409 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -59,6 +59,7 @@ obj-$(CONFIG_CHARGER_MAX8997)   += max8997_charger.o
>  obj-$(CONFIG_CHARGER_MAX8998)+= max8998_charger.o
>  obj-$(CONFIG_CHARGER_BQ2415X)+= bq2415x_charger.o
>  obj-$(CONFIG_CHARGER_BQ24190)+= bq24190_charger.o
> +obj-$(CONFIG_CHARGER_BQ24261)+= bq24261_charger.o
>  obj-$(CONFIG_CHARGER_BQ24257)+= bq24257_charger.o
>  obj-$(CONFIG_CHARGER_BQ24735)+= bq24735-charger.o
>  obj-$

Re: [PATCH v2 13/13] dt: power: bq2425x-charger: Cover additional devices

[Andreas Dannenberg]

On Wed, Sep 09, 2015 at 01:58:09PM +0900, Krzysztof Kozlowski wrote:
> On 09.09.2015 11:48, Andreas Dannenberg wrote:
> > On Wed, Sep 09, 2015 at 09:27:06AM +0900, Krzysztof Kozlowski wrote:
> >> On 09.09.2015 09:12, Andreas Dannenberg wrote:
> >>> Extend the bq2425x charger's device tree documentation to cover the
> >>> bq24250 and bq24257 devices as well as recent feature additions.
> >>>
> >>> Signed-off-by: Andreas Dannenberg 
> >>
> >> Hi,
> >>
> >> Thanks for updates. Everything pointed previous looks good. After
> >> looking at Ramakrishna Pallala's (Cc-ed) patch ("power: bq24261_charger:
> >> Add support for TI BQ24261 charger") I have only one comment below.
> > 
> > Thanks for all your efforts and time checking those patches!
> > 
> >>
> >>> ---
> >>>  .../devicetree/bindings/power/bq24257.txt  | 21 ---
> >>>  .../devicetree/bindings/power/bq2425x.txt  | 70 
> >>> ++
> >>>  2 files changed, 70 insertions(+), 21 deletions(-)
> >>>  delete mode 100644 Documentation/devicetree/bindings/power/bq24257.txt
> >>>  create mode 100644 Documentation/devicetree/bindings/power/bq2425x.txt
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/power/bq24257.txt 
> >>> b/Documentation/devicetree/bindings/power/bq24257.txt
> >>> deleted file mode 100644
> >>> index 5c9d394..000
> >>> --- a/Documentation/devicetree/bindings/power/bq24257.txt
> >>> +++ /dev/null
> >>> @@ -1,21 +0,0 @@
> >>> -Binding for TI bq24257 Li-Ion Charger
> >>> -
> >>> -Required properties:
> >>> -- compatible: Should contain one of the following:
> >>> - * "ti,bq24257"
> >>> -- reg:  integer, i2c address of the device.
> >>> -- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
> >>> -- ti,charge-current:integer, maximum charging current in uA.
> >>> -- ti,termination-current:  integer, charge will be terminated when 
> >>> current in
> >>> -constant-voltage phase drops below this value (in 
> >>> uA).
> >>> -
> >>> -Example:
> >>> -
> >>> -bq24257 {
> >>> - compatible = "ti,bq24257";
> >>> - reg = <0x6a>;
> >>> -
> >>> - ti,battery-regulation-voltage = <420>;
> >>> - ti,charge-current = <100>;
> >>> - ti,termination-current = <5>;
> >>> -};
> >>> diff --git a/Documentation/devicetree/bindings/power/bq2425x.txt 
> >>> b/Documentation/devicetree/bindings/power/bq2425x.txt
> >>> new file mode 100644
> >>> index 000..3e171c3
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/power/bq2425x.txt
> >>> @@ -0,0 +1,70 @@
> >>> +Binding for TI bq2425x Li-Ion Charger
> >>> +
> >>> +Required properties:
> >>> +- compatible: Should contain one of the following:
> >>> + * "ti,bq24250"
> >>> + * "ti,bq24251"
> >>> + * "ti,bq24257"
> >>> +- reg: integer, i2c address of the device.
> >>> +- stat-gpios: GPIO used for the devices STAT_IN pin. Alternatively the 
> >>> pin can
> >>> +also be defined through the standard interrupt definition properties 
> >>> (see
> >>> +optional properties section below). Only use one method.
> >>> +- ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
> >>> +- ti,charge-current: integer, maximum charging current in uA.
> >>> +- ti,termination-current: integer, charge will be terminated when 
> >>> current in
> >>> +constant-voltage phase drops below this value (in uA).
> >>> +
> >>> +Optional properties:
> >>> +- pg-gpios: GPIO used for connecting the bq2425x device PG (Power Good) 
> >>> pin.
> >>> +This pin is not available on all devices however it should be used if
> >>> +possible as this is the recommended way to obtain the charger's 
> >>> input PG
> >>> +state. If this pin is not specified a software-based approach for PG
> >>> +detection is used.
> >>> +- ti,current-limit: The maximum current to be drawn from the charger's 
> >>> input
> >>> +(in uA). If this property is not specified a USB D+/D- signal based 
> >>> charger
> >>> +type detection is used (if available) and the input limit current is 
> >>> set
> >>> +accordingly. If the D+/D- based detection is not available on a 
> >>> given device
> >>> +a default of 500,000 is used (=500mA).
> >>
> >> I understand this is different property than "ti,charge-current:
> >> integer, default charging current (in mA)" from bq24261_charger patch?
> > 
> > Correct this is what "ti,current-limit" is for. And I borrowed that
> > definition from bq2415x_charger.c where it's used in the same context.
> > The reason for this property to exist is for systems where the external
> > power supply does more than just charging the battery, such as supplying
> > the system while it's charging or after it has finished charging. All
> > this only makes sense of course if the "ti,current-limit" is larger than
> > "ti,charge-current".
> > 
> > And if you see a few lines above the bq24257 driver also has a
> > "ti,charge-current" property. And yes this is what actually controls how

Re: [PATCH 1/2] fsl: Add binding for RCPM

[Scott Wood]

On Wed, 2015-09-09 at 14:42 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng 
> 
> RCPM is the Run Control and Power Management module performs all
> device-level tasks associated with device run control and power
> management.
> 
> Add this for freescale powerpc platform and layerscape platform.
> 
> Signed-off-by: Chenhui Zhao 
> Signed-off-by: Tang Yuantian 
> Signed-off-by: Wang Dongsheng 
> 
> diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt 
> b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> new file mode 100644
> index 000..284070c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> @@ -0,0 +1,64 @@
> +* Run Control and Power Management
> +---
> +The RCPM performs all device-level tasks associated with device run control
> +and power management.
> +
> +Required properites:
> +  - reg : Offset and length of the register set of RCPM block.
> +  - compatible : Sould contain a chip-specific RCPM block compatible string
> + and (if applicable) may contain a chassis-version RCPM compatible 
> string.
> + Chip-specific strings are of the form "fsl,-rcpm", such as:
> + * "fsl,p2041-rcpm"
> + * "fsl,p3041-rcpm"
> + * "fsl,p4080-rcpm"
> + * "fsl,p5020-rcpm"
> + * "fsl,p5040-rcpm"
> + * "fsl,t4240-rcpm"
> + * "fsl,b4420-rcpm"
> + * "fsl,b4860-rcpm"
> +
> + Chassis-version strings are of the form "fsl,qoriq-rcpm-",
> + such as:
> + * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
> + * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
> + * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> +
> +All references to "1.0" and "2.0" refer to the QorIQ chassis version to
> +which the chip complies.
> +Chassis Version  Example Chips
> +---  ---
> +1.0  p4080, p5020, p5040, p2041, p3041
> +2.0  t4240, b4860, b4420
> +2.1  t1040, ls1021
> +
> +Example:
> +The RCPM node for T4240:
> + rcpm:  global-utilities@e2000{
> + compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
> + reg = <0xe2000 0x1000>;
> + };
> +
> +The RCPM node for P4080:
> + rcpm:  global-utilities@e2000{
> + compatible = "fsl,qoriq-rcpm-1.0";
> + reg = <0xe2000 0x1000>;
> + };

I would avoid putting the p4080 example in the binding, as we don't want to 
make it look like it's OK to leave out the specific chip compatible.

> +* Freescale RCPM Wakeup Source Device Tree Bindings
> +---
> +Required rcpm-wakeup property should be added to a device node if the 
> device
> +can be used as a wakeup source.
> +
> +  - rcpm-wakeup: should contain a pointer to the rcpm node and the
> + corresponding bit of device in the register.

The corresponding bit in *what* register?

-Scott

--
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 2/2] deps: avoid multiple calls to memmove by just setting duplicates to 0

[Alexander Holler]

Besides make the code (almost unmeasurable) faster, this makes the
ugly looking loop I've used to remove duplicates cleaner.
Disadvantage is that the ordered array now contains 'holes' and the
number of elements in the array doesn't really match the number
of ordered elements. But this only makes a difference for debugging.

This patch also adds an of_node_put() for duplicate dt nodes, something
I previously had forgotten.

Signed-off-by: Alexander Holler 
---
 drivers/of/of_dependencies.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/of/of_dependencies.c b/drivers/of/of_dependencies.c
index 85cef84..ac0c0f5 100644
--- a/drivers/of/of_dependencies.c
+++ b/drivers/of/of_dependencies.c
@@ -323,21 +323,20 @@ static bool __init all_compatibles_same(struct 
device_node *node1,
 /*
  * The order is based on devices but we are calling drivers.
  * Therefor the order contains some drivers more than once.
- * Remove the duplicates.
+ * Disable the duplicates by setting them to 0.
  */
-static void __init of_init_remove_duplicates(void)
+static void __init of_init_disable_duplicates(void)
 {
unsigned i, j;
 
for (i = 1; i < order.count; ++i)
for (j = 0; j < i; ++j) {
+   if (!order.order[j])
+   continue;
if (all_compatibles_same(order.order[j],
order.order[i])) {
-   --order.count;
-   memmove(&order.order[i], &order.order[i+1],
-   (order.count - i) *
-   sizeof(order.order[0]));
-   --i;
+   of_node_put(order.order[i]);
+   order.order[i] = 0;
break;
}
}
@@ -416,7 +415,8 @@ static void __init build_tgroups(void)
unsigned dist = 0;
 
for (i = 0; i < order.count; ++i) {
-   if (distance[order.order[i]->phandle] != dist) {
+   if (order.order[i] &&
+   distance[order.order[i]->phandle] != dist) {
dist = distance[order.order[i]->phandle];
count_groups++;
tgroup[count_groups].start = i;
@@ -436,6 +436,8 @@ static void __init of_init_print_order(void)
 
pr_info("Initialization order:\n");
for (i = 0; i < order.count; ++i) {
+   if (!order.order[i])
+   continue;
 #ifdef CONFIG_OF_DEPENDENCIES_PARALLEL
pr_info("init %u 0x%x (group %u)", i,
order.order[i]->phandle,
@@ -496,10 +498,10 @@ static int __init of_init_build_order(void)
 
 #ifdef CONFIG_OF_DEPENDENCIES_PARALLEL
build_order_by_distance();
-   of_init_remove_duplicates();
+   of_init_disable_duplicates();
build_tgroups();
 #else
-   of_init_remove_duplicates();
+   of_init_disable_duplicates();
 #endif
 
 #ifdef CONFIG_OF_DEPENDENCIES_PRINT_INIT_ORDER
@@ -516,7 +518,8 @@ static void __init of_init_free_order(void)
unsigned i;
 
for (i = 0; i < order.count; ++i)
-   of_node_put(order.order[i]);
+   if (order.order[i])
+   of_node_put(order.order[i]);
order.count = 0;
/* remove_new_phandles(); */
 }
@@ -593,8 +596,10 @@ static int __init initcall_thread(void *thread_nr)
start = atomic_read(&ostart);
count = atomic_read(&ocount);
while ((i = atomic_dec_return(&shared_counter)) >= 0)
-   init_if_matched(order.order[start + count - 1 - i],
-   (unsigned)thread_nr);
+   if (order.order[start + count - 1 - i])
+   init_if_matched(
+   order.order[start + count - 1 - i],
+(unsigned)thread_nr);
prepare_to_wait(&group_waitqueue, &wait, TASK_UNINTERRUPTIBLE);
if (!atomic_dec_and_test(&count_initcall_threads)) {
schedule();
@@ -629,7 +634,8 @@ static void __init of_init_drivers_non_threaded(void)
 
if (!of_init_build_order()) {
for (i = 0; i < order.count; ++i)
-   init_if_matched(order.order[i], 0);
+   if (order.order[i])
+   init_if_matched(order.order[i], 0);
of_init_free_order();
}
ac = __annotated_initcall_start;
-- 
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

[PATCH 1/2] deps: parallel initialization of (device-)drivers

[Alexander Holler]

This initializes drivers (annotated or in the initcall level device)
in parallel.

Which drivers can be initialized in parallel is calculated by using
the dependencies. That means, currently, only annotated drivers which
are are referenced in the used DT will be in order. For all others it
is assumed that, as long as they belong to the same initcall level
(device), they can be called in any order.

Unfortunately this isn't allways true and several drivers are depending
on the link-order (based on the Makefile and the directory). This is,
imho, a bug or at least a very fragile way to do such and should be,
again imho, fixed. Otherwise problems might arise if e.g. a driver is
moved from staging to its final position (which changes its place in
the list of initcalls too).
But this isn't really the topic of this patch and I'm mentioning this
here just as a warning or as hint in case someone experiences problems
when enabling the feature this patch provides.

Signed-off-by: Alexander Holler 
---
 drivers/of/Kconfig   |  20 
 drivers/of/of_dependencies.c | 245 ++-
 2 files changed, 261 insertions(+), 4 deletions(-)

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 26c4b1a..7e6e910 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -132,4 +132,24 @@ config OF_DEPENDENCIES_DEBUG_CALLS_OF_ANNOTATED_INITCALLS
help
  Used for debugging purposes.
 
+config OF_DEPENDENCIES_PARALLEL
+   bool "Initialize annotated initcalls in parallel"
+   depends on OF_DEPENDENCIES
+   help
+ Calculates which (annotated) initcalls can be called in parallel
+ and calls them using multiple threads. Be warned, this doesn't
+ work always as it should because of missing dependencies and
+ because it assumes that drivers belonging to the same initcall
+ level can be called in an order different than the order they
+ are linked.
+
+config OF_DEPENDENCIES_THREADS
+   int "Number of threads to use for parallel initialization"
+   depends on OF_DEPENDENCIES_PARALLEL
+   default 0
+   help
+ 0 means the number of threads used for parallel initialization
+ of drivers equals the number of online CPUs.
+ 1 means the threaded initialization is disabled.
+
 endif # OF
diff --git a/drivers/of/of_dependencies.c b/drivers/of/of_dependencies.c
index 06435d5..85cef84 100644
--- a/drivers/of/of_dependencies.c
+++ b/drivers/of/of_dependencies.c
@@ -11,12 +11,16 @@
  */
 
 #include 
+#include 
 
 #define MAX_DT_NODES 1000 /* maximum number of vertices */
 #define MAX_EDGES (MAX_DT_NODES*2) /* maximum number of edges (dependencies) */
 
 struct edgenode {
uint32_t y; /* phandle */
+#ifdef CONFIG_OF_DEPENDENCIES_PARALLEL
+   uint32_t x;
+#endif
struct edgenode *next; /* next edge in list */
 };
 
@@ -120,6 +124,9 @@ static int __init insert_edge(uint32_t x, uint32_t y)
graph.include_node[x] = 1;
graph.include_node[y] = 1;
p->y = y;
+#ifdef CONFIG_OF_DEPENDENCIES_PARALLEL
+   p->x = x;
+#endif
p->next = graph.edges[x];
graph.edges[x] = p; /* insert at head of list */
 
@@ -336,6 +343,90 @@ static void __init of_init_remove_duplicates(void)
}
 }
 
+#ifdef CONFIG_OF_DEPENDENCIES_PARALLEL
+/*
+ * The algorithm I've used below to calculate the max. distance for
+ * nodes to the root node likely isn't the fasted. But based on the
+ * already done implementation of the topological sort, this is an
+ * easy way to achieve this. Instead of first doing an topological
+ * sort and then using the stuff below to calculate the distances,
+ * using an algorithm which does spit out distances directly would
+ * be likely faster.
+ * If you want to spend the time, you could have a look e.g. at the
+ * topic 'layered graph drawing'.
+ */
+/* max. distance from a node to root */
+static unsigned distance[MAX_DT_NODES+1] __initdata;
+static struct device_node *order_by_distance[MAX_DT_NODES+1] __initdata;
+
+static void __init calc_max_distance(uint32_t v)
+{
+   unsigned i;
+   unsigned max_dist = 0;
+
+   for (i = 0; i < graph.nedges; ++i)
+   if (graph.edge_slots[i].x == v)
+   max_dist = max(max_dist,
+   distance[graph.edge_slots[i].y] + 1);
+   distance[v] = max_dist;
+}
+
+static void __init calc_distances(void)
+{
+   unsigned i;
+
+   for (i = 0; i < order.count; ++i)
+   calc_max_distance(order.order[i]->phandle);
+}
+
+static void __init build_order_by_distance(void)
+{
+   unsigned i, j;
+   unsigned max_distance = 0;
+   unsigned new_order_count = 0;
+
+   calc_distances();
+   order_by_distance[new_order_count++] = order.order[0];
+   for (i = 1; i < order.count; ++i) {
+   if (distance[order.order[i]->phandle] == 1)
+   order_by_distance[new_order_count++]

[PATCH 0/2] deps: parallel initialization of (device-)drivers

[Alexander Holler]

Hello,

as already mentioned, I've implemented the stuff to initialize drivers
in parallel. What follows are two patches to be used on top of my
already posted series (for 4.2) which implements annotated initcalls
and DT based dependencies.

But be warned: many drivers which are in the same initcall level
still depend on the link order given by the Makefile and directoy
(-name) and therefor will fail. That means without moving them to other
initcall levels or explicit dependencies (which are a TODO) for these
drivers, the whole stuff currently works only for some configurations
and you likely will need to add several patches for your board.

I've already posted two patches to move two drivers into another
initcall level. While playing with the stuff, I've found several
more drivers which are suffering under the same problem and need
the same modification:

block/noop-iosched.c
crypto/hmac.c
cryoto/sha_generic.c
drivers/mtd/ofpart.c
drivers/tty/serial/8250/8250_core.c

To offer an impression how this patch series might work in action,
below is the relevant part from the kernel log for a configuration
I'm using successfully on an imx6q.

Maybe someone has interest in that stuff.

Regards,

Alexander Holler

---
(...)
[2.628325] Thread 0 calling (ordered) initcall for driver reg-fixed-voltage 
(regulator-fixed)
[2.629196] Thread 3 calling (ordered) initcall for driver imx6q-pinctrl 
(fsl,imx6q-iomuxc)
[2.629331] Thread 0 calling (ordered) initcall for driver gpio-mxc 
(fsl,imx1-gpio)
[2.630276] imx6q-pinctrl 20e.iomuxc: initialized IMX pinctrl driver
[2.632543] Thread 0 calling (ordered) initcall for driver anatop_regulator 
(fsl,anatop-regulator)
[2.632556] Thread 1 calling (ordered) initcall for driver imx-sdma 
(fsl,imx6q-sdma)
[2.632563] Thread 2 calling (ordered) initcall for driver mxs-dma 
(fsl,imx23-dma-apbh)
[2.632598] Thread 3 calling (ordered) initcall for driver sram (mmio-sram)
[2.634502] mxs-dma 11.dma-apbh: initialized
[2.634848] Thread 3 calling (ordered) initcall for driver mxs_phy 
(fsl,imx6sx-usbphy)
[2.635165] Thread 0 calling (ordered) initcall for driver imx2-wdt 
(fsl,imx21-wdt)
[2.635181] Thread 2 calling (ordered) initcall for driver snvs_rtc 
(fsl,sec-v4.0-mon-rtc-lp)
[2.635493] snvs_rtc 20cc034.snvs-rtc-lp: rtc core: setting system clock to 
2015-09-09 16:37:09 UTC (1441816629)
[2.635813] snvs_rtc 20cc034.snvs-rtc-lp: rtc core: registered 
20cc034.snvs-rtc-lp as rtc0
[2.635978] Thread 2 calling (ordered) initcall for driver ahci-imx 
(fsl,imx53-ahci)
[2.636317] imx-sdma 20ec000.sdma: initialized
[2.636322] ahci-imx 220.sata: fsl,transmit-level-mV not specified, 
using 0024
[2.636332] ahci-imx 220.sata: fsl,transmit-boost-mdB not specified, 
using 0480
[2.636338] ahci-imx 220.sata: fsl,transmit-atten-16ths not specified, 
using 2000
[2.636347] ahci-imx 220.sata: fsl,receive-eq-mdB not specified, using 
0500
[2.636690] Thread 1 calling (ordered) initcall for driver wandboard-rfkill 
(wand,imx6q-wandboard-rfkill)
[2.637160] imx-sdma 20ec000.sdma: loaded firmware 1.1
[2.637166] imx2-wdt 20bc000.wdog: timeout 60 sec (nowayout=0)
[2.637283] wandboard-rfkill rfkill: Wandboard rfkill initialization
[2.637402] Thread 0 calling (ordered) initcall for driver leds-gpio 
(gpio-leds)
[2.637422] wandboard-rfkill rfkill: Turning of power
[2.639193] ahci-imx 220.sata: SSS flag set, parallel bus scan disabled
[2.639253] ahci-imx 220.sata: AHCI 0001.0300 32 slots 1 ports 3 Gbps 
0x1 impl platform mode
[2.639299] ahci-imx 220.sata: flags: ncq sntf stag pm led clo only pmp 
pio slum part ccc apst
[2.640579] scsi host0: ahci-imx
[2.640902] ata1: SATA max UDMA/133 mmio [mem 0x0220-0x02203fff] port 
0x100 irq 67
[2.663463] wandboard-rfkill rfkill: initialize wifi chip
[2.663642] wandboard-rfkill rfkill: wifi-rfkill registered.
[2.663720] wandboard-rfkill rfkill: initialize bluetooth chip
[2.663919] wandboard-rfkill rfkill: bluetooth-rfkill registered.
[2.664289] Thread 1 calling (ordered) initcall for driver imx-gpc 
(fsl,imx6q-gpc)
[2.664335] Thread 3 calling (ordered) initcall for driver imx-uart 
(fsl,imx6q-uart)
[2.664769] 202.serial: ttymxc0 at MMIO 0x202 (irq = 23, base_baud = 
500) is a IMX
[2.983471] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[2.984610] ata1.00: ATA-8: Hitachi HTS542525K9SA00, BBFOC31P, max UDMA/133
[2.984620] ata1.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[2.985793] ata1.00: configured for UDMA/133
[2.985912] Default I/O scheduler not found. Using noop.
[2.986213] scsi 0:0:0:0: Direct-Access ATA  Hitachi HTS54252 C31P 
PQ: 0 ANSI: 5
[2.986776] scsi 0:0:0:0: Failed to register bsg queue, errno=-19
[3.734832] console [ttymxc0] enabled
[3.739241] 21ec000.serial: ttymxc2 at MMIO 0x21ec000 (ir

Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes

[Greg KH]

On Wed, Sep 09, 2015 at 10:14:46AM -0300, Emilio López wrote:
> On 09/09/15 01:12, Guenter Roeck wrote:
> >On 09/08/2015 08:58 PM, Greg KH wrote:
> >>On Tue, Sep 08, 2015 at 06:10:16PM -0700, Guenter Roeck wrote:
> >>>Hi Emilio,
> >>>
> >>>On 09/08/2015 05:51 PM, Emilio López wrote:
> Hi Greg & Guenter,
> 
> >>>[ ... ]
> >>>
> >>>Unless I am missing something, this is not explained anywhere,
> >>>but it is
> >>>not entirely trivial to understand. I think it should be documented.
> 
> I agree. I couldn't find any mention of what this int was supposed
> to be by looking at Documentation/ (is_visible is not even mentioned
> :/) or include/linux/sysfs.h. Once we settle on something I'll
> document it before sending a v2.
> 
> >>>In the include file ? No strong preference, though.
> >>>
> By the way, I wrote a quick coccinelle script to match is_visible()
> users which reference the index (included below), and it found
> references to drivers which do not seem to use any binary
> attributes, so I believe changing the index meaning shouldn't be an
> issue.
> 
> >>>Good.
> >>>
> >>I agree, make i the number of the bin attribute and that should solve
> >>this issue.
> >>
> >No, that would conflict with the "normal" use of is_visible for
> >non-binary
> >attributes, and make the index all but useless, since the
> >is_visible function
> >would have to search through all the attributes anyway to figure
> >out which one
> >is being checked.
> 
> Yeah, using the same indexes would be somewhat pointless, although
> not many seem to be using it anyway (only 14 files matched). Others
> seem to be comparing the attr* instead. An alternative would be to
> use negative indexes for binary attributes and positive indexes for
> normal attributes.
> 
> >>>... and I probably wrote or reviewed a significant percentage of
> >>>those ;-).
> >>>
> >>>Using negative numbers for binary attributes is an interesting idea.
> >>>Kind of unusual, though. Greg, any thoughts on that ?
> >>
> >>Ick, no, that's a mess, maybe we just could drop the index alltogether?
> >>
> >
> >No, please don't. Having to manually compare dozens of index pointers
> >would be
> >even more of a mess.
> 
> So, what about keeping it the way it is in the patch, and documenting it
> thoroughly? Otherwise, we could introduce another "is_bin_visible" function
> to do this same thing but just on binary attributes, but I'd rather not add
> a new function pointer if possible.

is_bin_visiable makes sense to me instead of trying to overload the
index number in some crazy way.  There's no issue with adding another
function pointer.

thanks,

greg k-h
--
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 RFC 4/5] ASoC: davinci-mcasp: Get rid of bclk_lrclk_ratio in private data

[Jyri Sarha]

The slot_width is for essentially same thing. Instead of storing
bclk_lrclk_ratio, just store the slot_width. Comments has been updated
accordingly and some variable names changed to more descriptive.

Signed-off-by: Jyri Sarha 
---
 sound/soc/davinci/davinci-mcasp.c | 56 ++-
 1 file changed, 31 insertions(+), 25 deletions(-)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index de1e3a8..25ff1fc 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -87,7 +87,6 @@ struct davinci_mcasp {
u8  *serial_dir;
u8  version;
u8  bclk_div;
-   u16 bclk_lrclk_ratio;
int streams;
u32 irq_request[2];
int dma_request[2];
@@ -558,8 +557,21 @@ static int __davinci_mcasp_set_clkdiv(struct snd_soc_dai 
*dai, int div_id,
mcasp->bclk_div = div;
break;
 
-   case 2: /* BCLK/LRCLK ratio */
-   mcasp->bclk_lrclk_ratio = div;
+   case 2: /*
+* BCLK/LRCLK ratio descries how many bit-clock cycles
+* fit into one frame. The clock ratio is given for a
+* full period of data (for I2S format both left and
+* right channels), so it has to be divided by number
+* of tdm-slots (for I2S - divided by 2).
+* Instead of storing this ratio, we calculate a new
+* tdm_slot width by dividing the the ratio by the
+* number of configured tdm slots.
+*/
+   mcasp->slot_width = div / mcasp->tdm_slots;
+   if (div % mcasp->tdm_slots)
+   dev_warn(mcasp->dev,
+"%s(): BCLK/LRCLK %d is not divisible by %d 
tdm slots",
+div, mcasp->tdm_slots);
break;
 
default:
@@ -682,11 +694,13 @@ static int davinci_mcasp_set_tdm_slot(struct snd_soc_dai 
*dai,
 }
 
 static int davinci_config_channel_size(struct davinci_mcasp *mcasp,
-  int word_length)
+  int sample_width)
 {
u32 fmt;
-   u32 tx_rotate = (word_length / 4) & 0x7;
-   u32 mask = (1ULL << word_length) - 1;
+   u32 tx_rotate = (sample_width / 4) & 0x7;
+   u32 mask = (1ULL << sample_width) - 1;
+   u32 slot_width = sample_width;
+
/*
 * For captured data we should not rotate, inversion and masking is
 * enoguh to get the data to the right position:
@@ -699,31 +713,23 @@ static int davinci_config_channel_size(struct 
davinci_mcasp *mcasp,
u32 rx_rotate = 0;
 
/*
-* if s BCLK-to-LRCLK ratio has been configured via the set_clkdiv()
-* callback, take it into account here. That allows us to for example
-* send 32 bits per channel to the codec, while only 16 of them carry
-* audio payload.
-* The clock ratio is given for a full period of data (for I2S format
-* both left and right channels), so it has to be divided by number of
-* tdm-slots (for I2S - divided by 2).
+* Setting the tdm slot width either with set_clkdiv() or
+* set_tdm_slot() allows us to for example send 32 bits per
+* channel to the codec, while only 16 of them carry audio
+* payload.
 */
-   if (mcasp->bclk_lrclk_ratio) {
-   u32 slot_length = mcasp->bclk_lrclk_ratio / mcasp->tdm_slots;
-
+   if (mcasp->slot_width) {
/*
-* When we have more bclk then it is needed for the data, we
-* need to use the rotation to move the received samples to have
-* correct alignment.
+* When we have more bclk then it is needed for the
+* data, we need to use the rotation to move the
+* received samples to have correct alignment.
 */
-   rx_rotate = (slot_length - word_length) / 4;
-   word_length = slot_length;
-   } else if (mcasp->slot_width) {
-   rx_rotate = (mcasp->slot_width - word_length) / 4;
-   word_length = mcasp->slot_width;
+   slot_width = mcasp->slot_width;
+   rx_rotate = (slot_width - sample_width) / 4;
}
 
/* mapping of the XSSZ bit-field as described in the datasheet */
-   fmt = (word_length >> 1) - 1;
+   fmt = (slot_width >> 1) - 1;
 
if (mcasp->op_mode != DAVINCI_MCASP_DIT_MODE) {
mcasp_mod_bits(mcasp, DAVINCI_MCASP_RXFMT_REG, RXSSZ(fmt),
-- 
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 RFC 1/5] ASoC: davinci-mcasp: Set .symmetric_rates = 1 in snd_soc_dai_driver

[Jyri Sarha]

The TX and RX direction share the same bit clock and frame sync, so
the samplerate must be the same to both directions.

Signed-off-by: Jyri Sarha 
---
 sound/soc/davinci/davinci-mcasp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index fa0511b..bbd1987 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1304,6 +1304,7 @@ static struct snd_soc_dai_driver davinci_mcasp_dai[] = {
.ops= &davinci_mcasp_dai_ops,
 
.symmetric_samplebits   = 1,
+   .symmetric_rates= 1,
},
{
.name   = "davinci-mcasp.1",
-- 
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 RFC 2/5] ASoC: simple-card: Add tdm slot mask support to simple-card

[Jyri Sarha]

Adds DT binding for explicitly choosing a tdm mask for DAI and uses it
in simple-card. The API for snd_soc_of_parse_tdm_slot() has also been
changed.

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/sound/tdm-slot.txt | 11 +-
 include/sound/simple_card.h|  2 ++
 include/sound/soc.h|  2 ++
 sound/soc/generic/simple-card.c|  8 +--
 sound/soc/soc-core.c   | 25 ++
 5 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt 
b/Documentation/devicetree/bindings/sound/tdm-slot.txt
index 6a2c842..34cf70e 100644
--- a/Documentation/devicetree/bindings/sound/tdm-slot.txt
+++ b/Documentation/devicetree/bindings/sound/tdm-slot.txt
@@ -4,11 +4,15 @@ This specifies audio DAI's TDM slot.
 
 TDM slot properties:
 dai-tdm-slot-num : Number of slots in use.
-dai-tdm-slot-width :  Width in bits for each slot.
+dai-tdm-slot-width : Width in bits for each slot.
+dai-tdm-slot-tx-mask : Transmit direction slot mask, optional
+dai-tdm-slot-rx-mask : Receive direction slot mask, optional
 
 For instance:
dai-tdm-slot-num = <2>;
dai-tdm-slot-width = <8>;
+   dai-tdm-slot-tx-mask = <0 1>;
+   dai-tdm-slot-rx-mask = <1 0>;
 
 And for each spcified driver, there could be one .of_xlate_tdm_slot_mask()
 to specify a explicit mapping of the channels and the slots. If it's absent
@@ -18,3 +22,8 @@ tx and rx masks.
 For snd_soc_of_xlate_tdm_slot_mask(), the tx and rx masks will use a 1 bit
 for an active slot as default, and the default active bits are at the LSB of
 the masks.
+
+The explicit masks are given as array of integers, where the first
+number presents bit-0 (LSB), second presents bit-1, etc. Any non zero
+number is considered 1 and 0 is 0. snd_soc_of_xlate_tdm_slot_mask()
+does not do anything, if either mask is set non zero value.
diff --git a/include/sound/simple_card.h b/include/sound/simple_card.h
index b9b4f28..0399352 100644
--- a/include/sound/simple_card.h
+++ b/include/sound/simple_card.h
@@ -19,6 +19,8 @@ struct asoc_simple_dai {
unsigned int sysclk;
int slots;
int slot_width;
+   unsigned int tx_slot_mask;
+   unsigned int rx_slot_mask;
struct clk *clk;
 };
 
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 4cef20e..ca009bf 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -1598,6 +1598,8 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
 int snd_soc_of_parse_audio_simple_widgets(struct snd_soc_card *card,
  const char *propname);
 int snd_soc_of_parse_tdm_slot(struct device_node *np,
+ unsigned int *tx_mask,
+ unsigned int *rx_mask,
  unsigned int *slots,
  unsigned int *slot_width);
 void snd_soc_of_parse_audio_prefix(struct snd_soc_card *card,
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 3ff76d4..54c3320 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -151,7 +151,9 @@ static int __asoc_simple_card_dai_init(struct snd_soc_dai 
*dai,
}
 
if (set->slots) {
-   ret = snd_soc_dai_set_tdm_slot(dai, 0, 0,
+   ret = snd_soc_dai_set_tdm_slot(dai,
+  set->tx_slot_mask,
+  set->rx_slot_mask,
set->slots,
set->slot_width);
if (ret && ret != -ENOTSUPP) {
@@ -243,7 +245,9 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
return ret;
 
/* Parse TDM slot */
-   ret = snd_soc_of_parse_tdm_slot(np, &dai->slots, &dai->slot_width);
+   ret = snd_soc_of_parse_tdm_slot(np, &dai->tx_slot_mask,
+   &dai->rx_slot_mask,
+   &dai->slots, &dai->slot_width);
if (ret)
return ret;
 
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index c81aec9..1929f0e 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -3289,13 +3289,38 @@ int snd_soc_of_parse_audio_simple_widgets(struct 
snd_soc_card *card,
 }
 EXPORT_SYMBOL_GPL(snd_soc_of_parse_audio_simple_widgets);
 
+static int snd_soc_of_get_slot_mask(struct device_node *np,
+   const char *prop_name,
+   unsigned int *mask)
+{
+   u32 val;
+   const u32 *of_slot_mask = of_get_property(np, prop_name, &val);
+   int i;
+
+   if (!of_slot_mask)
+   return 0;
+   val /= sizeof(u32);
+   for (i = 0; i < val; i++)
+   if (be32_to_cpup(&of_slot_mask[i]))
+   *mask 

[PATCH RFC 5/5] ASoC: tlv320aic3x: Improve tdm support

[Jyri Sarha]

Before this patch the set_tdm_slots() callback did not store the value
of slot width anywhere. The tdm support only worked if selected slot
width was equal to the sample width. With this patch all sample widths
that fit into the slot width are supported. There unused bits are
filled unnecessarily in the capture direction, but the other end of
the i2s bus should be able to ignore them.

Signed-off-by: Jyri Sarha 
---
 sound/soc/codecs/tlv320aic3x.c | 30 ++
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 1a82b19..f1c9fff 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -80,6 +80,7 @@ struct aic3x_priv {
unsigned int sysclk;
unsigned int dai_fmt;
unsigned int tdm_delay;
+   unsigned int slot_width;
struct list_head list;
int master;
int gpio_reset;
@@ -1025,10 +1026,14 @@ static int aic3x_hw_params(struct snd_pcm_substream 
*substream,
u8 data, j, r, p, pll_q, pll_p = 1, pll_r = 1, pll_j = 1;
u16 d, pll_d = 1;
int clk;
+   int width = aic3x->slot_width;
+
+   if (!width)
+   width = params_width(params);
 
/* select data word length */
data = snd_soc_read(codec, AIC3X_ASD_INTF_CTRLB) & (~(0x3 << 4));
-   switch (params_width(params)) {
+   switch (width) {
case 16:
break;
case 20:
@@ -1170,12 +1175,16 @@ static int aic3x_prepare(struct snd_pcm_substream 
*substream,
struct snd_soc_codec *codec = dai->codec;
struct aic3x_priv *aic3x = snd_soc_codec_get_drvdata(codec);
int delay = 0;
+   int width = aic3x->slot_width;
+
+   if (!width)
+   width = substream->runtime->sample_bits;
 
/* TDM slot selection only valid in DSP_A/_B mode */
if (aic3x->dai_fmt == SND_SOC_DAIFMT_DSP_A)
-   delay += (aic3x->tdm_delay + 1);
+   delay += (aic3x->tdm_delay*width + 1);
else if (aic3x->dai_fmt == SND_SOC_DAIFMT_DSP_B)
-   delay += aic3x->tdm_delay;
+   delay += aic3x->tdm_delay*width;
 
/* Configure data delay */
snd_soc_write(codec, AIC3X_ASD_INTF_CTRLC, delay);
@@ -1296,7 +1305,20 @@ static int aic3x_set_dai_tdm_slot(struct snd_soc_dai 
*codec_dai,
return -EINVAL;
}
 
-   aic3x->tdm_delay = lsb * slot_width;
+   switch (slot_width) {
+   case 16:
+   case 20:
+   case 24:
+   case 32:
+   break;
+   default:
+   dev_err(codec->dev, "Unsupported slot width %d\n", slot_width);
+   return -EINVAL;
+   }
+
+
+   aic3x->tdm_delay = lsb;
+   aic3x->slot_width = slot_width;
 
/* DOUT in high-impedance on inactive bit clocks */
snd_soc_update_bits(codec, AIC3X_ASD_INTF_CTRLA,
-- 
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 RFC 3/5] ASoC: davinci-mcasp: Add set_tdm_slots() support

[Jyri Sarha]

Implements set_tdm_slot() callback for mcasp. Channel constraints are
updated according to the configured tdm mask and slots each time
set_tdm_slot() is called. The special case when slot width is set to
zero is allowed and it means that slot width is the same as the sample
width.

Signed-off-by: Jyri Sarha 
---
 sound/soc/davinci/davinci-mcasp.c | 255 ++
 1 file changed, 174 insertions(+), 81 deletions(-)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index bbd1987..de1e3a8 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -80,6 +80,8 @@ struct davinci_mcasp {
 
/* McASP specific data */
int tdm_slots;
+   u32 tdm_mask[2];
+   int slot_width;
u8  op_mode;
u8  num_serializer;
u8  *serial_dir;
@@ -601,6 +603,84 @@ static int davinci_mcasp_set_sysclk(struct snd_soc_dai 
*dai, int clk_id,
return 0;
 }
 
+/* All serializers must have equal number of channels */
+static int davinci_mcasp_ch_constraint(struct davinci_mcasp *mcasp, int stream,
+  int serializers)
+{
+   struct snd_pcm_hw_constraint_list *cl = &mcasp->chconstr[stream];
+   unsigned int *list = (unsigned int *) cl->list;
+   int slots = mcasp->tdm_slots;
+   int i, count = 0;
+
+   if (mcasp->tdm_mask[stream])
+   slots = hweight32(mcasp->tdm_mask[stream]);
+
+   for (i = 2; i <= slots; i++)
+   list[count++] = i;
+
+   for (i = 2; i <= serializers; i++)
+   list[count++] = i*slots;
+
+   cl->count = count;
+
+   return 0;
+}
+
+static int davinci_mcasp_set_ch_constraints(struct davinci_mcasp *mcasp)
+{
+   int rx_serializers = 0, tx_serializers = 0, ret, i;
+
+   for (i = 0; i < mcasp->num_serializer; i++)
+   if (mcasp->serial_dir[i] == TX_MODE)
+   tx_serializers++;
+   else if (mcasp->serial_dir[i] == RX_MODE)
+   rx_serializers++;
+
+   ret = davinci_mcasp_ch_constraint(mcasp, SNDRV_PCM_STREAM_PLAYBACK,
+ tx_serializers);
+   if (ret)
+   return ret;
+
+   ret = davinci_mcasp_ch_constraint(mcasp, SNDRV_PCM_STREAM_CAPTURE,
+ rx_serializers);
+
+   return ret;
+}
+
+
+static int davinci_mcasp_set_tdm_slot(struct snd_soc_dai *dai,
+ unsigned int tx_mask,
+ unsigned int rx_mask,
+ int slots, int slot_width)
+{
+   struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(dai);
+
+   dev_dbg(mcasp->dev,
+"%s() tx_mask 0x%08x rx_mask 0x%08x slots %d width %d\n",
+__func__, tx_mask, rx_mask, slots, slot_width);
+
+   if (tx_mask >= (1<= (1 32 || slot_width % 4 != 0)) {
+   dev_err(mcasp->dev, "%s: Unsupported slot_width %d\n",
+   __func__, slot_width);
+   return -EINVAL;
+   }
+
+   mcasp->tdm_slots = slots;
+   mcasp->tdm_mask[SNDRV_PCM_STREAM_PLAYBACK] = rx_mask;
+   mcasp->tdm_mask[SNDRV_PCM_STREAM_CAPTURE] = tx_mask;
+   mcasp->slot_width = slot_width;
+
+   return davinci_mcasp_set_ch_constraints(mcasp);
+}
+
 static int davinci_config_channel_size(struct davinci_mcasp *mcasp,
   int word_length)
 {
@@ -637,6 +717,9 @@ static int davinci_config_channel_size(struct davinci_mcasp 
*mcasp,
 */
rx_rotate = (slot_length - word_length) / 4;
word_length = slot_length;
+   } else if (mcasp->slot_width) {
+   rx_rotate = (mcasp->slot_width - word_length) / 4;
+   word_length = mcasp->slot_width;
}
 
/* mapping of the XSSZ bit-field as described in the datasheet */
@@ -782,33 +865,50 @@ static int mcasp_i2s_hw_param(struct davinci_mcasp 
*mcasp, int stream,
 
/*
 * If more than one serializer is needed, then use them with
-* their specified tdm_slots count. Otherwise, one serializer
-* can cope with the transaction using as many slots as channels
-* in the stream, requires channels symmetry
+* all the specified tdm_slots. Otherwise, one serializer can
+* cope with the transaction using just as many slots as there
+* are channels in the stream.
 */
-   active_serializers = (channels + total_slots - 1) / total_slots;
-   if (active_serializers == 1)
-   active_slots = channels;
-   else
-   active_slot

[PATCH RFC 0/5] ASoC: TDM stuff for simple-card, mcasp, and tlv320aic3x

[Jyri Sarha]

The first patch is an independent fix.

The symmetric_samplebits constraint could probably be removed too
(with some changes to mcasp code too), but as tlv320aic3x family
codecs won't support it, I could not test it.

Jyri Sarha (5):
  ASoC: davinci-mcasp: Set .symmetric_rates = 1 in snd_soc_dai_driver
  ASoC: simple-card: Add tdm slot mask support to simple-card
  ASoC: davinci-mcasp: Add set_tdm_slots() support
  ASoC: davinci-mcasp: Get rid of bclk_lrclk_ratio in private data
  ASoC: tlv320aic3x: Improve tdm support

 .../devicetree/bindings/sound/tdm-slot.txt |  11 +-
 include/sound/simple_card.h|   2 +
 include/sound/soc.h|   2 +
 sound/soc/codecs/tlv320aic3x.c |  30 +-
 sound/soc/davinci/davinci-mcasp.c  | 306 ++---
 sound/soc/generic/simple-card.c|   8 +-
 sound/soc/soc-core.c   |  25 ++
 7 files changed, 274 insertions(+), 110 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 v5 0/6] bcm2835: auxiliar device support for spi

[Eric Anholt]

Alexander Stein  writes:

> Hi,
> On Tuesday 08 September 2015 18:48:07, Eric Anholt wrote:
>> I finally had a chance to sit down and look at what the hardware's doing
>> with the enable bit (also, I've read a whole lot more of the hardware
>> now, so I'm a lot faster at answering questions like this).  The enable
>> bits are a clock gate off of the VPU clock.
>
> Are any hardware documents about such things available (in public)?

Nope, I just went through the HDL to see how things were routed.

>> I knocked together the enable bits as a clock gate driver, since I'd
>> just written very similar code for the audio domain clock driver (and I
>> assume you are grumpy about how much time you've spent on this one
>> stupid register).  It's up at
>> https://github.com/anholt/linux/tree/bcm2835-clock-aux and I can submit
>> it if you like the result.  I've compile tested it only, but I'm hoping
>> you could just drop your aux SPI driver on top of it and have things
>> work.
>
> IMHO line 45 
> (https://github.com/anholt/linux/commit/facb4ba917a1b9f6c2ee0cea7d529acf55f584dd#diff-1b6f753c132811b3f6d70f5b31866950R45)
>  should be like this
>> onecell->clks = kzalloc(sizeof(*onecell->clks) * BCM2835_AUX_CLOCK_COUNT, 
>> GFP_KERNEL);
> or you will only allocate a single struct clk*.

Thanks, that was a bug in my other clock driver, too!


signature.asc
Description: PGP signature

RE: [PATCH] power: bq24261_charger: Add support for TI BQ24261 charger

[Pallala, Ramakrishna]

Hi, 

> From: k.kozlowsk...@gmail.com [mailto:k.kozlowsk...@gmail.com] On Behalf
> Of Krzysztof Kozlowski
> Sent: Monday, September 7, 2015 9:28 AM
> To: Pallala, Ramakrishna
> Cc: linux-ker...@vger.kernel.org; linux...@vger.kernel.org;
> devicetree@vger.kernel.org; Sebastian Reichel; Tc, Jenny; Andreas Dannenberg
> Subject: Re: [PATCH] power: bq24261_charger: Add support for TI BQ24261
> charger
> 
> 2015-09-07 2:23 GMT+09:00 Ramakrishna Pallala
> :
> >
> > Add new charger driver support for BQ24261 charger IC.
> >
> > BQ24261 charger driver relies on extcon notifications to get the
> > charger cable type and based on that it will set the charging parameters.
> >
> > Signed-off-by: Ramakrishna Pallala 
> > Signed-off-by: Jennt TC 
> > ---
> >  .../devicetree/bindings/power/bq24261.txt  |   37 +
> >  drivers/power/Kconfig  |6 +
> >  drivers/power/Makefile |1 +
> >  drivers/power/bq24261_charger.c| 1208 
> > 
> >  include/linux/power/bq24261_charger.h  |   27 +
> >  5 files changed, 1279 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/power/bq24261.txt
> >  create mode 100644 drivers/power/bq24261_charger.c  create mode
> > 100644 include/linux/power/bq24261_charger.h
> >
> > diff --git a/Documentation/devicetree/bindings/power/bq24261.txt
> > b/Documentation/devicetree/bindings/power/bq24261.txt
> > new file mode 100644
> > index 000..25fc5c4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/power/bq24261.txt
> > @@ -0,0 +1,37 @@
> > +Binding for TI bq24261 Li-Ion Charger
> 
> Please split the bindings into separate patch (the first patch in patchset).
Ok.


> > +
> > +Required properties:
> > +- compatible: Should contain one of the following:
> > +* "ti,bq24261"
> > +- reg: integer, i2c address of the device.
> > +- ti,charge-current: integer, default charging current (in mA);
> > +- ti,charge-voltage: integer, default charging voltage (in mV);
> > +- ti,termination-current: integer, charge will be terminated when current 
> > in
> > +constant-voltage phase drops below this value (in mA);
> > +- ti,max-charge-current: integer, maximum charging current (in mA);
> > +- ti,max-charge-voltage: integer, maximum charging voltage (in mV);
> > +- ti,min-charge-temperature: integer, minimum charging temperature
> > +(in DegC);
> > +- ti,max-charge-temperature: integer, maximum charging temperature (in
> DegC).
> 
> Before accepting "[PATCH 13/13] dt: power: bq24257-charger: Cover additional
> devices"
> http://www.spinics.net/lists/devicetree/msg92134.html
> 
> could you and Andreas figure out common bindings? Look at this:
> 
> +- ti,charge-current: integer, maximum charging current in uA.
> +- ti,charge-current: integer, default charging current (in mA);
> 
> Different meaning and different units. This is madness! :)
This is being closed by Andreas and we would probably go with mA/mV

> In the same time you are adding TI-common bindings (not device specific, there
> is no prefix) so I would expect exactly the same bindings if it is possible.
Ok...i will check with other charger driver DT settings and fix it.

> > +Optional properties:
> > +- ti,thermal-sensing: boolean, if present thermal regulation will be
> > +enabled;
> 
> What is the requirement for thermal-sensing? Can it be enabled always?
> If yes, then this is not really a hardware property.
TI BQ24261 has provision to add Battery Pack thermistor but it has no ADC read 
it.
So a HW designer would or may not add the thermistor to charger and instead he 
can
connect to the Fuel Gauge.

> > +- ti,enable-user-write: boolean, if present driver will allow the user 
> > space
> > +to control the charging current and voltage through sysfs;
> 
> This is not DT property. It does not describe hardware.
We needed a mechanism to enable the sysfs writes on certain properties.
If DT is not the place where should it go?

Thanks,
Ram

N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH v2] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.

[David Daney]

On 09/09/2015 10:44 AM, Frank Rowand wrote:

Second attempt at this reply.  The first reply was mangled.

On 9/8/2015 11:28 AM, David Daney wrote:

From: David Daney 

It is perfectly legitimate for a PCI device to have an
PCI_INTERRUPT_PIN value of zero.  This happens if the device doesn't
use interrupts, or on PCIe devices, where only MSI/MSI-X are
supported.

Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
messages by moving the printing code into of_irq_parse_pci(), and only
emitting the message for cases where PCI_INTERRUPT_PIN == 0 is not the
cause for an early exit.

Signed-off-by: David Daney 
---
Changes in v2: Move the print function in to of_irq_parse_pci() at a
common error exit point (as suggested by Frank Rowand).



[...]

@@ -87,6 +89,9 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq
laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
laddr[1] = laddr[2] = cpu_to_be32(0);



return of_irq_parse_raw(laddr, out_irq);


should be:

 rc = of_irq_parse_raw(laddr, out_irq);
 if (rc)
 goto err;
 return 0;



You are right.  I will send v3.

Thanks,
David Daney


+err:
+   dev_err(&pdev->dev, "of_irq_parse_pci() failed with rc=%d\n", rc);
+   return rc;


--
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] arm: rpi: Device tree modifications for U-Boot

[Simon Glass]

Hi,

On Friday, 28 August 2015, Simon Glass  wrote:
>
> Hi Rob,
>
> On 25 August 2015 at 10:22, Rob Herring  wrote:
> > On Sat, Aug 15, 2015 at 8:46 AM, Simon Glass  wrote:
> >> Hi Rob,
> >>
> >> On 14 August 2015 at 14:29, Rob Herring  wrote:
> >>> On Fri, Aug 14, 2015 at 1:34 PM, Simon Glass  wrote:
>  -linux-tegra
> 
>  Hi,
> 
>  On 12 August 2015 at 07:21, Simon Glass  wrote:
> > Hi Lucas,
> >
> > On 11 August 2015 at 11:05, Lucas Stach  wrote:
> >> Hi Simon,
> >>
> >> why did you send this to the Tegra ML?
> >>
> >> Am Dienstag, den 11.08.2015, 08:25 -0600 schrieb Simon Glass:
> >>> This updates the device tree from the kernel version to something 
> >>> suitable
> >>> for U-Boot:
> >>>
> >>> - Add stdout-path alias for console
> >>> - Mark the /soc node to be available pre-relocation so that the early
> >>> serial console works (we need the 'ranges' property to be available)
> >>>
> >>> I find it quite strange that you must explicitly enable the parent
> >>> node, but not the uart node.
> >>
> >> U-Boot tries hard to find and bind the UART using the stdout-path
> >> link. I would like to add it in the UART node also but we were able to
> >> work around it so far.
> >>
> >>>
> >>>
> >>> Signed-off-by: Simon Glass 
> >>> ---
> >>>
> >>>  arch/arm/boot/dts/bcm2835.dtsi | 4 +++-
> >>>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi 
> >>> b/arch/arm/boot/dts/bcm2835.dtsi
> >>> index 301c73f..bd6bff6 100644
> >>> --- a/arch/arm/boot/dts/bcm2835.dtsi
> >>> +++ b/arch/arm/boot/dts/bcm2835.dtsi
> >>> @@ -8,6 +8,7 @@
> >>>
> >>>   chosen {
> >>>   bootargs = "earlyprintk console=ttyAMA0";
> >>> + stdout-path = &uart;
> >>>   };
> >>>
> >>>   soc {
> >>> @@ -16,6 +17,7 @@
> >>>   #size-cells = <1>;
> >>>   ranges = <0x7e00 0x2000 0x0200>;
> >>>   dma-ranges = <0x4000 0x 0x2000>;
> >>> + u-boot,dm-pre-reloc;
> >>
> >> Why do you need this and why should upstream carry your favourite
> >> bootloaders configuration? This is in no way hardware description.
> >
> > I'm not sure how much you know about U-Boot, so let me know if you
> > need more info.
> >
> > U-Boot normally starts up by setting up its serial UART and displaying
> > a banner message. At this stage typically only a few devices are
> > initialised (e.g. maybe just the UART). It then relocates itself to
> > the top of memory and starts up all the devices. It throws away any
> > previous devices that it set up before relocation and starts again.
> >
> > U-Boot uses a thing called driver model (dm) which handles driver
> > binding and probing. Driver model has the device tree and would
> > normally scan through it and create devices for everything it finds.
> >>>
> >>> How do you debug the DM itself? It seems like you still would need
> >>> something earlier for debug like earlycon in the kernel. u-boot DM is
> >>> probably simple enough you can get away with using it early, but you
> >>> often can't as the complexity increases. Ultimately you need something
> >>> simple that just hits all the registers needed to get characters out.
> >>> What happens when you add pinmux, clocks, PMIC, power domains, etc. to
> >>> the DM and they all become dependencies for the UART?
> >>
> >> This doesn't seem like a device tree binding question but let me try
> >> to answer it.
> >>
> >> This is a problem - one of the challenges of driver model is that the
> >> UART gets further away from the reset vector.
> >
> > This is a common problem for any complex embedded system. Nothing
> > special about u-boot here. So either we don't need anything because
> > everyone else has dealt with the problem in some way or we need a
> > common solution because we all have this problem.
>
> I'm struggling to understand the value of this statement - is it just
> philosophizing? I do have a real problem and would like to solve it.
> Please make a concrete suggestion.
>
> >
> >> In U-Boot there is a single debug UART which can be supported by the
> >> various serial drivers (only one can be selected on each platform).
> >> There is a special debug_uart_init() function which is supposed to set
> >> up the UART for that platform. After that, and until driver model UART
> >> is up, console output can go through the debug UART.
> >
> > So you don't need this for the common case of an early console, but
> > only for platforms needing some other platform specific setup?
>
> The debug UART is generally disabled and has very limited use. It is
> hard-coded and does not use the device tree. I mentioned it because
> you asked "How do you debug the DM itself". You dropped that from the
> contex

Re: [PATCH v2] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.

[Frank Rowand]

Second attempt at this reply.  The first reply was mangled.

On 9/8/2015 11:28 AM, David Daney wrote:
> From: David Daney 
> 
> It is perfectly legitimate for a PCI device to have an
> PCI_INTERRUPT_PIN value of zero.  This happens if the device doesn't
> use interrupts, or on PCIe devices, where only MSI/MSI-X are
> supported.
> 
> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error
> messages by moving the printing code into of_irq_parse_pci(), and only
> emitting the message for cases where PCI_INTERRUPT_PIN == 0 is not the
> cause for an early exit.
> 
> Signed-off-by: David Daney 
> ---
> Changes in v2: Move the print function in to of_irq_parse_pci() at a
> common error exit point (as suggested by Frank Rowand).
> 
> 
>  drivers/of/of_pci_irq.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
> index 1710d9d..0be8b65 100644
> --- a/drivers/of/of_pci_irq.c
> +++ b/drivers/of/of_pci_irq.c
> @@ -38,8 +38,8 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
> of_phandle_args *out_irq
>*/
>   rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);
>   if (rc != 0)
> - return rc;
> - /* No pin, exit */
> + goto err;
> + /* No pin, exit with no error message. */
>   if (pin == 0)
>   return -ENODEV;
>  
> @@ -53,8 +53,10 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
> of_phandle_args *out_irq
>   ppnode = pci_bus_to_OF_node(pdev->bus);
>  
>   /* No node for host bridge ? give up */
> - if (ppnode == NULL)
> - return -EINVAL;
> + if (ppnode == NULL) {
> + rc = -EINVAL;
> + goto err;
> + }
>   } else {
>   /* We found a P2P bridge, check if it has a node */
>   ppnode = pci_device_to_OF_node(ppdev);
> @@ -87,6 +89,9 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
> of_phandle_args *out_irq
>   laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));
>   laddr[1] = laddr[2] = cpu_to_be32(0);

>   return of_irq_parse_raw(laddr, out_irq);

should be:

rc = of_irq_parse_raw(laddr, out_irq);
if (rc)
goto err;
return 0;

> +err:
> + dev_err(&pdev->dev, "of_irq_parse_pci() failed with rc=%d\n", rc);
> + return rc;
>  }
>  EXPORT_SYMBOL_GPL(of_irq_parse_pci);
>  
> @@ -105,10 +110,8 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, 
> u8 slot, u8 pin)
>   int ret;
>  
>   ret = of_irq_parse_pci(dev, &oirq);
> - if (ret) {
> - dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n", 
> ret);
> + if (ret)
>   return 0; /* Proper return code 0 == NO_IRQ */
> - }
>  
>   return irq_create_of_mapping(&oirq);
>  }
> 

--
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] of_pci_irq: Silence bogus "of_irq_parse_pci() failed ..." messages.

[Frank Rowand]

On 9/8/2015 11:28 AM, David Daney wrote:

> From: David Daney 

> 

> It is perfectly legitimate for a PCI device to have an

> PCI_INTERRUPT_PIN value of zero.  This happens if the device doesn't

> use interrupts, or on PCIe devices, where only MSI/MSI-X are

> supported.

> 

> Silence the annoying "of_irq_parse_pci() failed with rc=-19" error

> messages by moving the printing code into of_irq_parse_pci(), and only

> emitting the message for cases where PCI_INTERRUPT_PIN == 0 is not the

> cause for an early exit.

> 

> Signed-off-by: David Daney 

> ---

> Changes in v2: Move the print function in to of_irq_parse_pci() at a

> common error exit point (as suggested by Frank Rowand).

> 

> 

>  drivers/of/of_pci_irq.c | 17 ++---

>  1 file changed, 10 insertions(+), 7 deletions(-)

> 

> diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c

> index 1710d9d..0be8b65 100644

> --- a/drivers/of/of_pci_irq.c

> +++ b/drivers/of/of_pci_irq.c

> @@ -38,8 +38,8 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
> of_phandle_args *out_irq

>*/

>   rc = pci_read_config_byte(pdev, PCI_INTERRUPT_PIN, &pin);

>   if (rc != 0)

> - return rc;

> - /* No pin, exit */

> + goto err;

> + /* No pin, exit with no error message. */

>   if (pin == 0)

>   return -ENODEV;

>  

> @@ -53,8 +53,10 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
> of_phandle_args *out_irq

>   ppnode = pci_bus_to_OF_node(pdev->bus);

>  

>   /* No node for host bridge ? give up */

> - if (ppnode == NULL)

> - return -EINVAL;

> + if (ppnode == NULL) {

> + rc = -EINVAL;

> + goto err;

> + }

>   } else {

>   /* We found a P2P bridge, check if it has a node */

>   ppnode = pci_device_to_OF_node(ppdev);

> @@ -87,6 +89,9 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
> of_phandle_args *out_irq

>   laddr[0] = cpu_to_be32((pdev->bus->number << 16) | (pdev->devfn << 8));

>   laddr[1] = laddr[2] = cpu_to_be32(0);


>   return of_irq_parse_raw(laddr, out_irq);


should be:

rc = of_irq_parse_raw(laddr, out_irq);
if (rc)
goto err;
return 0;

> +err:

> + dev_err(&pdev->dev, "of_irq_parse_pci() failed with rc=%d\n", rc);

> + return rc;

>  }

>  EXPORT_SYMBOL_GPL(of_irq_parse_pci);

>  

> @@ -105,10 +110,8 @@ int of_irq_parse_and_map_pci(const struct pci_dev *dev, 
> u8 slot, u8 pin)

>   int ret;

>  

>   ret = of_irq_parse_pci(dev, &oirq);

> - if (ret) {

> - dev_err(&dev->dev, "of_irq_parse_pci() failed with rc=%d\n", 
> ret);

> + if (ret)

>   return 0; /* Proper return code 0 == NO_IRQ */

> - }

>  

>   return irq_create_of_mapping(&oirq);

>  }

> 



--
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] power: bq24261_charger: Add support for TI BQ24261 charger

[Andreas Dannenberg]

On Wed, Sep 09, 2015 at 01:17:11PM +0900, Krzysztof Kozlowski wrote:
> On 09.09.2015 11:26, Andreas Dannenberg wrote:
> > Krzysztof, good observation! In bq2425x_charger.c (formerly known as
> > bq24257_charger.c :) that I worked on the unit used was uA. At that time
> > I did a quick check and there didn't seem to be a clear standard whether
> > to use the "micro" or "milli" units - different drivers use different
> > units. However there seems to be a tendency for the TI drivers to prefer
> > "milli" (bq2415x_charger.c, bq24735-charger.c)
> > 
> > Personally I think "milli" units are more appropriate for chargers since
> > they provide sufficient granularity and the numbers don't become too big
> > (try typing a voltage in the Volt-range in uV, it's very easy to get the
> > number of 0s wrong). However since the driver was already there I left
> > that aspect alone to preserve compatibility.
> 
> I am fine with both units but milli indeed seems easier to judge by fast
> looking and less error-prone. Whatever you choose - choose the same one. :)

Ok sounds good. If so, I could go ahead and change the units in the
bq2425x_charger.c over to mA and mV? It would be a bit labor some and I
also want to see what Laurentiu thinks but this way we could have most
of those TI charger drivers use the same units (the new bq24261 driver
Ram posted also uses mA/mV). Except bq25890_charger.c that would
still use uA/uV

Laurentiu -- what made you chose the "micro" units for bq24257_charger.c
and bq25890_charger.c?

Thanks,

--
Andreas Dannenberg
Texas Instruments Inc

--
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 v1 1/2] soc: ti: display firmware file name as part of boot log

[Murali Karicheri]

On 09/09/2015 01:12 PM, santosh.shilim...@oracle.com wrote:

On 9/9/15 9:38 AM, Murali Karicheri wrote:

On 09/04/2015 11:53 PM, santosh.shilim...@oracle.com wrote:

On 9/4/15 5:46 PM, Murali Karicheri wrote:

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---


Looks fine. Will pick both the patches.



Thanks Santhosh.

Is there a requirement to add the firmware to linux-firmware.git. Right
now I have provided link to ti git repo that has the firmware. I have
the patch ready in case this is required. Do you know?


Standard distro's will look for linux-firmware.git as a source to get
the firmware files used by kernel so yes, you should add these firmware
files to that repo.

Ok. Will send a patch for this.

Murali


Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
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 v1 1/2] soc: ti: display firmware file name as part of boot log

[santosh.shilim...@oracle.com]

On 9/9/15 9:38 AM, Murali Karicheri wrote:

On 09/04/2015 11:53 PM, santosh.shilim...@oracle.com wrote:

On 9/4/15 5:46 PM, Murali Karicheri wrote:

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---


Looks fine. Will pick both the patches.



Thanks Santhosh.

Is there a requirement to add the firmware to linux-firmware.git. Right
now I have provided link to ti git repo that has the firmware. I have
the patch ready in case this is required. Do you know?


Standard distro's will look for linux-firmware.git as a source to get
the firmware files used by kernel so yes, you should add these firmware
files to that repo.

Regards,
Santosh
--
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/5] Input: goodix - reset device at init

[Bastien Nocera]

On Thu, 2015-07-30 at 11:27 +, Tirdea, Irina wrote:
> I can send some additional patches that will simplify testing the
> configuration update to the Goodix device. I think this feature is
> the easiest
> to test so we can determine if writing to the interrupt pin actually
> works.
> However, even if it is a BIOS problem and the code will work, the
> warning
> will still be printed in dmesg.


Somehow missed this mail before replying to the current patchset. I'd
be fine with that, though it's still not clear to me whether the
BIOS/hardware is at fault, or the code that's being added to the driver
;)

Cheers
--
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 v5 1/9] Input: goodix - sort includes alphabetically

[Bastien Nocera]

On Mon, 2015-09-07 at 17:36 +0300, Irina Tirdea wrote:
> Signed-off-by: Irina Tirdea 

Acked-by: Bastien Nocera 

> ---
>  drivers/input/touchscreen/goodix.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/goodix.c
> b/drivers/input/touchscreen/goodix.c
> index e36162b..6ae28c5 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -14,18 +14,18 @@
>   * Software Foundation; version 2 of the License.
>   */
>  
> -#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
>  #include 
> -#include 
> -#include 
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
>  #include 
>  
>  struct goodix_ts_data {
--
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 v5 2/9] Input: goodix - use actual config length for each device type

[Bastien Nocera]

On Mon, 2015-09-07 at 17:36 +0300, Irina Tirdea wrote:
> Each of the Goodix devices supported by this driver has a fixed size
> for
> the configuration information registers. The size varies depending on
> the
> device and is specified in the datasheet.
> 
> Use the proper configuration length as specified in the datasheet for
> each device model, so we do not read more than the actual size of the
> configuration registers.
> 
> Signed-off-by: Irina Tirdea 

Acked-by: Bastien Nocera 

> ---
>  drivers/input/touchscreen/goodix.c | 25 +++--
>  1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/goodix.c
> b/drivers/input/touchscreen/goodix.c
> index 6ae28c5..7be6eab 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -36,6 +36,7 @@ struct goodix_ts_data {
>   unsigned int max_touch_num;
>   unsigned int int_trigger_type;
>   bool rotated_screen;
> + int cfg_len;
>  };
>  
>  #define GOODIX_MAX_HEIGHT4096
> @@ -45,6 +46,8 @@ struct goodix_ts_data {
>  #define GOODIX_MAX_CONTACTS  10
>  
>  #define GOODIX_CONFIG_MAX_LENGTH 240
> +#define GOODIX_CONFIG_911_LENGTH 186
> +#define GOODIX_CONFIG_967_LENGTH 228
>  
>  /* Register defines */
>  #define GOODIX_READ_COOR_ADDR0x814E
> @@ -115,6 +118,23 @@ static int goodix_i2c_read(struct i2c_client
> *client,
>   return ret < 0 ? ret : (ret != ARRAY_SIZE(msgs) ? -EIO : 0);
>  }
>  
> +static int goodix_get_cfg_len(u16 id)
> +{
> + switch (id) {
> + case 911:
> + case 9271:
> + case 9110:
> + case 927:
> + case 928:
> + return GOODIX_CONFIG_911_LENGTH;
> + case 912:
> + case 967:
> + return GOODIX_CONFIG_967_LENGTH;
> + default:
> + return GOODIX_CONFIG_MAX_LENGTH;
> + }
> +}
> +
>  static int goodix_ts_read_input_report(struct goodix_ts_data *ts, u8
> *data)
>  {
>   int touch_num;
> @@ -230,8 +250,7 @@ static void goodix_read_config(struct
> goodix_ts_data *ts)
>   int error;
>  
>   error = goodix_i2c_read(ts->client, GOODIX_REG_CONFIG_DATA,
> - config,
> - GOODIX_CONFIG_MAX_LENGTH);
> + config, ts->cfg_len);
>   if (error) {
>   dev_warn(&ts->client->dev,
>"Error reading config (%d), using
> defaults\n",
> @@ -398,6 +417,8 @@ static int goodix_ts_probe(struct i2c_client
> *client,
>   return error;
>   }
>  
> + ts->cfg_len = goodix_get_cfg_len(id_info);
> +
>   goodix_read_config(ts);
>  
>   error = goodix_request_input_dev(ts, version_info, id_info);
--
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 v5 3/9] Input: goodix - reset device at init

[Bastien Nocera]

On Mon, 2015-09-07 at 17:36 +0300, Irina Tirdea wrote:
> After power on, it is recommended that the driver resets the device.
> The reset procedure timing is described in the datasheet and is used
> at device init (before writing device configuration) and
> for power management. It is a sequence of setting the interrupt
> and reset pins high/low at specific timing intervals. This procedure
> also includes setting the slave address to the one specified in the
> ACPI/device tree.
> 
> This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> driver gt9xx.c for Android (publicly available in Android kernel
> trees for various devices).
> 
> For reset the driver needs to control the interrupt and
> reset gpio pins (configured through ACPI/device tree). For devices
> that do not have the gpio pins declared, the functionality depending
> on these pins will not be available, but the device can still be used
> with basic functionality.

This throws:
Sep 09 18:22:47 winbook kernel: Goodix-TS i2c-GDIX1001:00: ID 9271, version: 
1040
Sep 09 18:22:47 winbook kernel: [ cut here ]
Sep 09 18:22:47 winbook kernel: WARNING: CPU: 3 PID: 3298 at 
drivers/pinctrl/intel/pinctrl-baytrail.c:338 
byt_gpio_direction_output+0x97/0xa0()
Sep 09 18:22:47 winbook kernel: Potential Error: Setting GPIO with 
direct_irq_en to output
Sep 09 18:22:47 winbook kernel: Modules linked in:
Sep 09 18:22:47 winbook kernel:  goodix_backport(OE+) hid_logitech_hidpp 
hid_logitech_dj cdc_mbim cdc_wdm cdc_ncm usbnet mii uvcvideo videobuf2_vmalloc 
videobuf2_core videobuf2_memops v4l2_common snd_usb_audio v
Sep 09 18:22:47 winbook kernel:  snd_soc_sst_byt_rt5640_mach coretemp 
snd_soc_sst_baytrail_pcm iTCO_vendor_support snd_soc_sst_ipc kvm_intel 
snd_soc_sst_dsp gpio_keys kvm snd_intel_sst_acpi snd_intel_sst_core sn
Sep 09 18:22:47 winbook kernel:  lockd grace sunrpc i915 mmc_block i2c_algo_bit 
drm_kms_helper drm sdhci_acpi video sdhci mmc_core i2c_hid [last unloaded: 
goodix]
Sep 09 18:22:47 winbook kernel: CPU: 3 PID: 3298 Comm: insmod Tainted: G
   OE   4.2.0-0.rc3.git4.2.fc22.i686 #1
Sep 09 18:22:47 winbook kernel: Hardware name: WinBook TW100/TW100, BIOS 
1.02.00 08/25/2014
Sep 09 18:22:47 winbook kernel:  c0d439a7 bb4c1aaf  de2f7bb4 c0aa23b9 
de2f7bf4 de2f7be4 c045c677
Sep 09 18:22:47 winbook kernel:  c0cbe3b8 de2f7c14 0ce2 c0cbe3f4 0152 
c073cd87 c073cd87 f7c5e0b8
Sep 09 18:22:47 winbook kernel:  f4bb309c f7c5e0b0 de2f7c00 c045c6ee 0009 
de2f7bf4 c0cbe3b8 de2f7c14
Sep 09 18:22:47 winbook kernel: Call Trace:
Sep 09 18:22:47 winbook kernel:  [] dump_stack+0x41/0x52
Sep 09 18:22:47 winbook kernel:  [] warn_slowpath_common+0x87/0xc0
Sep 09 18:22:47 winbook kernel:  [] ? 
byt_gpio_direction_output+0x97/0xa0
Sep 09 18:22:47 winbook kernel:  [] ? 
byt_gpio_direction_output+0x97/0xa0
Sep 09 18:22:47 winbook kernel:  [] warn_slowpath_fmt+0x3e/0x60
Sep 09 18:22:47 winbook kernel:  [] 
byt_gpio_direction_output+0x97/0xa0
Sep 09 18:22:47 winbook kernel:  [] ? byt_gpio_irq_handler+0xc0/0xc0
Sep 09 18:22:47 winbook kernel:  [] 
_gpiod_direction_output_raw+0x59/0x1c0
Sep 09 18:22:47 winbook kernel:  [] gpiod_direction_output+0x2a/0x50
Sep 09 18:22:47 winbook kernel:  [] ? msleep+0x2b/0x40
Sep 09 18:22:47 winbook kernel:  [] goodix_reset+0x3e/0x90 
[goodix_backport]
Sep 09 18:22:47 winbook kernel:  [] goodix_ts_probe+0x27e/0x5a0 
[goodix_backport]
Sep 09 18:22:47 winbook kernel:  [] i2c_device_probe+0x101/0x1b0
Sep 09 18:22:47 winbook kernel:  [] ? sysfs_create_link+0x25/0x50
Sep 09 18:22:47 winbook kernel:  [] ? 
goodix_configure_dev+0x1e0/0x1e0 [goodix_backport]

Which is the same error I had previously:
https://lkml.org/lkml/2015/6/30/434

I was testing this on a Onda v975w, but I'm now testing it on a WinBook
TW100.


> +/*
> + * ACPI table specifies gpio pins in this order: first rst pin and
> + * then interrupt pin.
> + */
> +static const struct dmi_system_id goodix_rst_pin_first[] = {
> +#if defined(CONFIG_DMI) && defined(CONFIG_X86)
> + {
> + .ident = "WinBook TW100",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "WinBook"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "TW100")
> + }
> + },

The DSDT for the WinBook one is here:
https://people.gnome.org/~hadess/Winbook%20TW100%20DSDT.dsl

For reference, the DSDT for the Onda, the tablet I tested this on some
months ago:
https://bugzilla.kernel.org/attachment.cgi?id=149331

Cheers
--
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 v1 1/2] soc: ti: display firmware file name as part of boot log

[Murali Karicheri]

On 09/04/2015 11:53 PM, santosh.shilim...@oracle.com wrote:

On 9/4/15 5:46 PM, Murali Karicheri wrote:

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---


Looks fine. Will pick both the patches.



Thanks Santhosh.

Is there a requirement to add the firmware to linux-firmware.git. Right 
now I have provided link to ti git repo that has the firmware. I have 
the patch ready in case this is required. Do you know?


Murali

Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
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/2] dt: power: st: Provide bindings for ST's OPPs

[Lee Jones]

> > Or have I got the wrong end of the stick?
> > 
> > NB: Note the suggested new property names.
> 
> Yeah, all looks fine to me.

I think these names are better:

  opp-supply-range-name => opp-microvolt-names
  opp-cuts  => opp-supported-hw

Apart from that, the binding is starting to come together.

Let's see what Rob and Stephen have to say about it.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
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 v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Viresh Kumar]

On 09-09-15, 14:39, Lee Jones wrote:
> Okay, I see what you mean.  Sound fine, although only allows up to 31
> versions.  Not an issue for us I don't think, but could be for other
> vendors.  Taking a recent example, the kernel recently went up to
> v2.6.39 and some of the stable releases have gone up to v3.4.108.
> Depends what you wish to support.

Oh, that is always expandable. No one is stopping a platform to have
hw-versions as: cuts_part1 cuts_part2 cuts_part3, and that will give
us 96 bits :)

> > So, its not name of the supply really, but a virtual name given to the
> > voltage-range which we need to pick based on the hardware version.
> 
> We usually call these 'names'; reg-names, clock-names, pinctrl-names,
> phy-names, dma-names, etc.

Probably (opp-)supply-range-name suits well.

> > > I guess this is a Qcom specific feature.  I'll let Stephen comment.
> > 
> > No. So, my plan was to use this instead of the st,avs & pcode thing
> > you have got in your bindings. So, instead of 'slow' and 'fast' from
> > my example, it will have the corresponding strings for pcode numbers.
> > And at runtime the platform will pass a string to the OPP library, to
> > activate/add OPPs only for a specific opp-supply-version.
> 
> So you're using it to index into a 2 dimensional array of opp-hz's.

s/opp-hz's/opp-microvolt

> 
> Eek!

:)

> > I don't want 20 nodes but only ONE. And in your case, you may only
> > want to use pcode in the opp-supply-range-name property. But its fine
> > if you want to enable/disable some OPPs based on that as well :)
> 
> I'm not seeing how this can be achieved with 1 node.
> 
> I guess you mean one node per frequency?

Within an OPP table, OPP-nodes must have unique frequencies. i.e.
two nodes can't have same frequency.

In simple terms (mapping to your case) it is going to be like:
opp-table will have this:
opp-supply-range-names = "avs1", "avs2", ... , "avsn";

Each OPP node will have
opp-microvolt = , ,  ... ;

The platform with tell opp core to use avsX and OPP core will take
care of rest.

> > Not really. So this is the logic (I perhaps need to write the
> > paragraph in the bindings in a better way):
> > 1. A regulator's voltage can be supplied as  or  
> > now.
> 
> Understood.  I don't think we'll be using that, but if it's useful to
> others, then fine.

Bindings for this are already present in kernel, so this wasn't new.

> > 2. For each regulator we need to have an array of size mentioned above.
> 
> Using 2 properties to index in a 2D array like this look scarily like
> it'll be prone to all sorts of fumbling errors.
> 
> The complexity of all this will reduce massively by having a separate
> node per -supply.  Using the same nodes for this is
> squeezing too much into a single node.  I was put off as soon as I saw
> you using 2D arrays in DT.

So for the pcode thing, probably a separate entry like:
opp-microvolt-pcode0 can be added to make things easy. opp-microvolts
bindings are already added to support multiple regulators, and I don't
really want to touch that again :)

> > Now this is what I call as ONE entry.
> > 
> > For each opp-supply-range-name string, we need a copy of this..
> 
> Fortunately for us we'll only have single celled opp-microvolt
> properties.

Haha. FWIW, you can't use voltage-tolerance with OPP-v2 bindings as
the triplets have replaced it. Just in case you were planning to use
that :)

> So I think our offering would look like this:
> 
> cpus {
>   cpu@0 {
>   compatible = "arm,cortex-a7";
>   vcc-supply = <&cpu_supply0>;
>   operating-points-v2 = <&cpu0_opp_table>;
>   };
> };
> 
> cpu0_opp_table: opp_table0 {
>   compatible = "operating-points-v2";
>   opp-microvolt-names = "1", "2",  "3",  "4",  "5",  "6",  "7",  "8"
> "9", "10", "11", "12", "13", "14", "15", "16";
> 
>   opp0 {
>   /*  Major   Minor   Substrate */
>   /*  all all all   */
>   opp-supported-hw = <0x  0x  0x>
>   opp-hz   = <10>;
>   opp-microvolt= <90>, <915000>, <915000>, <925000>,
>  <925000>, <925000>, <935000>, <945000>,
>  <945000>, <945000>, <945000>, <955000>,
>  <956000>, <975000>, <975000>, <975000>,
>   };

So this is based of the solution I proposed. But if we were to choose
the one you gave, it will be:

opp-microvolt-1 = <90>;
opp-microvolt-2 = <915000>;
opp-microvolt-3 = <915000>;
opp-microvolt-4 = <925000>;
opp-microvolt-5 = <925000>;
opp-microvolt-6 = <925000>;
opp-microvolt-7 = <935000>;
opp-microvolt-8 = <945000>;
opp-microvolt-9 = <945000>;
opp-microvo

Re: [PATCH linux-next v6 1/8] mtd: spi-nor: read JEDEC ID with multiple I/O protocols

[Cyrille Pitchen]

Hi Marek,

Le 09/09/2015 15:59, Marek Vasut a écrit :
> On Wednesday, September 09, 2015 at 03:24:11 PM, Cyrille Pitchen wrote:
>> When their quad or dual I/O mode is enabled, Micron and Macronix spi-nor
>> memories don't reply to the regular Read ID (0x9f) command. Instead they
>> reply to a new dedicated command Read ID Multiple I/O (0xaf).
>>
>> If the Read ID (0x9f) command fails (the read ID is all 1's or all 0's),
>> then the Read ID Multiple I/O (0xaf) is used, first with SPI 4-4-4 protocol
>> (supported by both Micron and Macronix memories), lately with SPI-2-2-2
>> protocol (supported only by Micron memories).
>>
>> Signed-off-by: Cyrille Pitchen 
>> ---
>>  drivers/mtd/spi-nor/spi-nor.c | 28 +++-
>>  include/linux/mtd/spi-nor.h   | 23 +--
>>  2 files changed, 48 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index f59aedfe1462..80a0db078aaa 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -703,8 +703,9 @@ static const struct flash_info spi_nor_ids[] = {
>>
>>  static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
>>  {
>> -int tmp;
>> +int i, tmp;
>>  u8  id[SPI_NOR_MAX_ID_LEN];
>> +enum spi_protocol   proto[2] = {SPI_PROTO_4_4_4, SPI_PROTO_2_2_2};
>>  const struct flash_info *info;
>>
>>  tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
>> @@ -713,6 +714,25 @@ static const struct flash_info *spi_nor_read_id(struct
>> spi_nor *nor) return ERR_PTR(tmp);
>>  }
>>
>> +/* Special case for Micron/Macronix qspi nor. */
>> +for (i = 0; i < ARRAY_SIZE(proto); ++i) {
>> +if (!((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
>> +  (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00)))
>> +break;
>> +
>> +nor->erase_proto = proto[i];
>> +nor->read_proto = proto[i];
>> +nor->write_proto = proto[i];
>> +nor->reg_proto = proto[i];
>> +tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID,
>> +id, SPI_NOR_MAX_ID_LEN);
>> +if (tmp < 0) {
>> +dev_dbg(nor->dev,
>> +" error %d reading JEDEC ID (MULTI IO)\n", tmp);
> 
> Don't you have one space too much in front of the " error" ?
> 

Probably, I've just copied and pasted the dev_dbg() message few lines above when
the regular SPINOR_OP_RDID fails, then appended the "(MULTI IO)" string to make
think consistent but I don't mind removing the leading space.

tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
if (tmp < 0) {
dev_dbg(nor->dev, " error %d reading JEDEC ID\n", tmp);
return ERR_PTR(tmp);
}

>> +return ERR_PTR(tmp);
>> +}
>> +}
>> +
>>  for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
>>  info = &spi_nor_ids[tmp];
>>  if (info->id_len) {
> 
> [...]
> 

Best Regards,

Cyrille
--
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 linux-next v9 2/3] mfd: devicetree: add bindings for Atmel Flexcom

[Cyrille Pitchen]

Hi Rob,

Le 09/09/2015 01:40, Rob Herring a écrit :
> On 09/01/2015 09:46 AM, Cyrille Pitchen wrote:
>> This patch documents the DT bindings for the Atmel Flexcom which will be
>> introduced by sama5d2x SoCs. These bindings will be used by the actual
>> Flexcom driver to be sent in another patch.
>>
>> Signed-off-by: Cyrille Pitchen 
>> Acked-by: Boris Brezillon 
>> Acked-by: Alexandre Belloni 
> 
> A few comments, but in general looks fine.
> 
>> ---
>>  .../devicetree/bindings/mfd/atmel-flexcom.txt  | 67 
>> ++
>>  1 file changed, 67 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
>> b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>> new file mode 100644
>> index ..fc3511e41542
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>> @@ -0,0 +1,67 @@
>> +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication 
>> Unit)
>> +
>> +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
>> +controller and an USART. Only one function can be used at a time and is 
>> chosen
>> +at boot time according to the device tree.
> 
> Doesn't the board design choose (unless pins go to a header)?
> 

The function may be chosen once for all by the board design but if we take the
sama5d2 xplained board as an example, most Flexcoms output their pins to
headers.

>> +
>> +Required properties:
>> +- compatible:   Should be "atmel,sama5d2-flexcom"
>> +- reg:  Should be the offset/length value for Flexcom 
>> dedicated
>> +I/O registers (without USART, TWI or SPI registers).
>> +- clocks:   Should be the Flexcom peripheral clock from PMC.
>> +- #address-cells:   Should be <1>
>> +- #size-cells:  Should be <1>
>> +- ranges:   Should be one range for the full I/O register region
>> +(including USART, TWI and SPI registers).
>> +- atmel,flexcom-mode:   Should be one of the 3 following macros as 
>> defined in
>> +include/dt-bindings/mfd/atmel-flexcom.h:
>> +- ATMEL_FLEXCOM_MODE_USART for USART
>> +- ATMEL_FLEXCOM_MODE_SPI for SPI
>> +- ATMEL_FLEXCOM_MODE_TWI for I2C
>> +
>> +Required child:
>> +a single child device of type matching the "atmel,flexcom-mode" property.
> 
> Okay, but why not allow all children and use "status"?
> 

That is exactly what was proposed in v6 of this series: allow more than one
child so possibly all children but only one "available" child (status = 
"okay").

The Flexocm driver still needs to find out the type of device of this
available child to know which function is to be enabled (USART, I2C or SPI).
So the "compatible" attribute was parsed using strstr() to search on of the
patterns "usart", "spi" or "i2c".

However the use of strstr() was discussed to know whether the driver should
looks for a partial or an exact match of the "compatible" string.
An exact match would require to keep the Flexcom driver synchonized with the
3 other drivers every time one of them introduces a new compatibility string,
which whould have made every driver more difficult to maintain by creating a
useless dependency.
So this implementation relying on the "compatible" attribute was abandoned.

To sum up, no other reliable (and simple) means to guess/extact the device
type from its DT node was found so we got back to the "atmel,flexcom-mode"
property.

>> +
>> +The reg property of this child should be:
>> +- <0x200 0x200> for USART
>> +- <0x400 0x200> for SPI
>> +- <0x600 0x200> for I2C
>> +
>> +The phandle provided by the clocks property of the child is the same as one 
>> for
>> +the Flexcom parent.
>> +
>> +Other properties remain unchanged. See documentation of the respective 
>> device:
>> +- ../serial/atmel-usart.txt
>> +- ../spi/spi_atmel.txt
>> +- ../i2c/i2c-at91.txt
>> +
>> +Example:
>> +
>> +flexcom@f8034000 {
>> +compatible = "atmel,sama5d2-flexcom";
>> +reg = <0xf8034000 0x200>;
>> +clocks = <&flx0_clk>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges = <0x0 0xf8034000 0x800>;
>> +atmel,flexcom-mode = ;
>> +
>> +spi@400 {
>> +compatible = "atmel,at91rm9200-spi";
>> +reg = <0x400 0x200>;
>> +interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&pinctrl_flx0_default>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +clocks = <&flx0_clk>;
>> +clock-names = "spi_clk";
>> +atmel,fifo-size = <32>;
>> +
>> +mtd_dataflash@0 {
>> +compatible = "atmel,at25f512b";
>> +reg = <0>;
>> +spi-max-frequency = <2000>;
>> +};
>> +};
>> +

Re: [PATCH linux-next v6 1/8] mtd: spi-nor: read JEDEC ID with multiple I/O protocols

[Marek Vasut]

On Wednesday, September 09, 2015 at 03:24:11 PM, Cyrille Pitchen wrote:
> When their quad or dual I/O mode is enabled, Micron and Macronix spi-nor
> memories don't reply to the regular Read ID (0x9f) command. Instead they
> reply to a new dedicated command Read ID Multiple I/O (0xaf).
> 
> If the Read ID (0x9f) command fails (the read ID is all 1's or all 0's),
> then the Read ID Multiple I/O (0xaf) is used, first with SPI 4-4-4 protocol
> (supported by both Micron and Macronix memories), lately with SPI-2-2-2
> protocol (supported only by Micron memories).
> 
> Signed-off-by: Cyrille Pitchen 
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 28 +++-
>  include/linux/mtd/spi-nor.h   | 23 +--
>  2 files changed, 48 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index f59aedfe1462..80a0db078aaa 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -703,8 +703,9 @@ static const struct flash_info spi_nor_ids[] = {
> 
>  static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
>  {
> - int tmp;
> + int i, tmp;
>   u8  id[SPI_NOR_MAX_ID_LEN];
> + enum spi_protocol   proto[2] = {SPI_PROTO_4_4_4, SPI_PROTO_2_2_2};
>   const struct flash_info *info;
> 
>   tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
> @@ -713,6 +714,25 @@ static const struct flash_info *spi_nor_read_id(struct
> spi_nor *nor) return ERR_PTR(tmp);
>   }
> 
> + /* Special case for Micron/Macronix qspi nor. */
> + for (i = 0; i < ARRAY_SIZE(proto); ++i) {
> + if (!((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
> +   (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00)))
> + break;
> +
> + nor->erase_proto = proto[i];
> + nor->read_proto = proto[i];
> + nor->write_proto = proto[i];
> + nor->reg_proto = proto[i];
> + tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID,
> + id, SPI_NOR_MAX_ID_LEN);
> + if (tmp < 0) {
> + dev_dbg(nor->dev,
> + " error %d reading JEDEC ID (MULTI IO)\n", tmp);

Don't you have one space too much in front of the " error" ?

> + return ERR_PTR(tmp);
> + }
> + }
> +
>   for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
>   info = &spi_nor_ids[tmp];
>   if (info->id_len) {

[...]
--
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/5] Add eeprom to the Olimex series of boards

[Olliver Schinagl]

On 09-09-15 16:05, Maxime Ripard wrote:

On Wed, Sep 09, 2015 at 11:25:10AM +0200, Olliver Schinagl wrote:

Some of the olimex series of boards feature a permanently connected eeprom on
i2c-1. This patch series adds them on all the boards that have them according
to the spec-sheets.

I explicitly added my personal --Tested-by to boards I actually tested.

Testing your changes is the strict minimum before testing your
patches. Just like running checkpatch on them, which you clearly
failed to do, otherwise you would have seen that this is not the right
syntax. Drop the tested-by, fix your SoB.
Actually, I did run check-patch and it complained about the format, but 
it was the same as when outputted with a git -s. I obviously missed 
something there! So I double check that. I will resubmit without a 
tested-by for the boards I did test it on.



There are two boards, that according to the sheets have them as well
and physically inspecting the boards shows them clearly, I did not
actually test them on those the boards that are missing the
--Tested-by.

Then don't send those patches.
I put them out there so someone could pick up on that with the least 
amount of effort. I will drop them


Maxime



--
Met vriendelijke groeten, Kind regards, 与亲切的问候

Olliver Schinagl
Research & Development
Ultimaker B.V.

--
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/4] MIPS: ath79: Add USB support on the TL-WR1043ND

[Arnd Bergmann]

On Wednesday 09 September 2015 16:14:59 Alban wrote:
> On Mon, 07 Sep 2015 15:20:42 +0200
> Arnd Bergmann  wrote:
> 
> > On Tuesday 01 September 2015 17:23:10 Alban Bedel wrote:
> > > 
> > > this serie add a driver for the USB phy on the ATH79 SoCs and enable the
> > > USB port on the TL-WR1043ND. The phy controller is really trivial as it
> > > only use reset lines.
> > > 
> > 
> > Is this a common thing to have? If other PHY devices are like this, we
> > could instead add a simple generic PHY driver that just asserts all
> > its reset lines in the order as provided, rather than making this a
> > hardware specific driver that ends up getting copied several times.
> 
> I don't know how common it is. However I agree that a simple driver that
> can start a clock and toggle a few GPIO and/or reset would make sense.
> 
> However in the case of the ATH79 SoC some models have a reset line that
> is misused to force the PHY in sleep mode. Sadly this extra reset must
> be asserted for the PHY to work, so it wouldn't fit in such a generic
> design.
> 
> Still we could have such a generic driver and let the ATH79 driver
> build on top of it. Honestly that's what I wanted to do, but getting
> generic drivers with DT support accepted is not easy. That's why I went
> with this driver, it is technically inferior but much easier to get
> considered for merging.

Ok, fair enough. If we end up doing a more generic driver for this,
we can still consider adding the compatible string there, potentially
with some workaround for the sleep mode.

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 0/4] MIPS: ath79: Add USB support on the TL-WR1043ND

[Alban]

On Mon, 07 Sep 2015 15:20:42 +0200
Arnd Bergmann  wrote:

> On Tuesday 01 September 2015 17:23:10 Alban Bedel wrote:
> > 
> > this serie add a driver for the USB phy on the ATH79 SoCs and enable the
> > USB port on the TL-WR1043ND. The phy controller is really trivial as it
> > only use reset lines.
> > 
> 
> Is this a common thing to have? If other PHY devices are like this, we
> could instead add a simple generic PHY driver that just asserts all
> its reset lines in the order as provided, rather than making this a
> hardware specific driver that ends up getting copied several times.

I don't know how common it is. However I agree that a simple driver that
can start a clock and toggle a few GPIO and/or reset would make sense.

However in the case of the ATH79 SoC some models have a reset line that
is misused to force the PHY in sleep mode. Sadly this extra reset must
be asserted for the PHY to work, so it wouldn't fit in such a generic
design.

Still we could have such a generic driver and let the ATH79 driver
build on top of it. Honestly that's what I wanted to do, but getting
generic drivers with DT support accepted is not easy. That's why I went
with this driver, it is technically inferior but much easier to get
considered for merging.

Alban
--
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/3] ARM: dts: sun5i: Add sun5i-q8-common.dtsi

[Maxime Ripard]

On Tue, Sep 08, 2015 at 11:26:51PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 09/08/2015 04:33 PM, Maxime Ripard wrote:
> >On Sat, Sep 05, 2015 at 04:55:52PM +0200, Hans de Goede wrote:
> >>This is the sun5i / a13 version of sun8i-q8-common.dtsi for use in dts
> >>files for a13 q8 based tablets. Compared to sun8i this uses uart1 for the
> >>serial console, and PG0 for card-detect for mmc0.
> >>
> >>This also adds pmic and otg support, which both use the same config on
> >>all known q8 a13 devices. This is not present in sun5i-q8-common.dtsi
> >>because pmic / otg support for sun8i has not yet been merged.
> >>
> >>Signed-off-by: Hans de Goede 
> >
> >Are we going to have any user but the one you posted in the patch 3
> >planned?
> 
> Depends on what I can get my hands on / what is in the post atm.
> 
> One difference in fex files of different 18 variants is how the usb wifi is
> powered, either via a gpio or via ldo3. Also there are differences in which
> accelerometer is used, so eventually I expect there to be several users
> of this dtsi.

But no difference in the SoC used (A13 vs A10s)?

I'm not sure having 18 DTs for a single board name is going to be
really helpful. It would be something to be supported by some quirks
mechanism, instead of having to require the user to pick the right one.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH 0/5] Add eeprom to the Olimex series of boards

[Maxime Ripard]

On Wed, Sep 09, 2015 at 11:25:10AM +0200, Olliver Schinagl wrote:
> Some of the olimex series of boards feature a permanently connected eeprom on
> i2c-1. This patch series adds them on all the boards that have them according
> to the spec-sheets.
> 
> I explicitly added my personal --Tested-by to boards I actually tested.

Testing your changes is the strict minimum before testing your
patches. Just like running checkpatch on them, which you clearly
failed to do, otherwise you would have seen that this is not the right
syntax. Drop the tested-by, fix your SoB.

> There are two boards, that according to the sheets have them as well
> and physically inspecting the boards shows them clearly, I did not
> actually test them on those the boards that are missing the
> --Tested-by.

Then don't send those patches.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings

[Tejun Heo]

On Wed, Sep 09, 2015 at 05:16:22PM +0800, yuantian.t...@freescale.com wrote:
> From: Tang Yuantian 
> 
> kbuild test robot reports the warnings:
> drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
> >> include/asm-generic/io.h:163:2: warning: 'px_is' may be used
> >> uninitialized in this function [-Wuninitialized]
> drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here
> >> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
> >> uninitialized in this function [-Wuninitialized]
> drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here
> 
> This patch fixed it by assigning 0 to px_is and px_cmd variables.
> This patch also remove line 'struct ccsr_ahci *reg_base' which is
> not referred by any other codes and thus a dead one.

Hmm... I think the problem here is that the complier can't know
whether qoriq_priv->type would change across intervening function
calls.  Maybe a better solution is caching the type in a local
variable so that the compiler can tell that those two tests will
always move together?  It generally isn't a good idea to clear
variables unnecessarily as that can hide actual bugs that compiler can
detect.

Thanks.

-- 
tejun
--
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 v7 1/5] dt-bindings: Add usb3.0 phy binding for MT65xx SoCs

[Rob Herring]

On 09/08/2015 01:17 AM, Chunfeng Yun wrote:
> add a DT binding documentation of usb3.0 phy for MT65xx
> SoCs from Mediatek.
> 
> Signed-off-by: Chunfeng Yun 

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 69 
> ++
>  1 file changed, 69 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> new file mode 100644
> index 000..5812d20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
> @@ -0,0 +1,69 @@
> +mt65xx USB3.0 PHY binding
> +--
> +
> +This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
> +
> +Required properties (controller (parent) node):
> + - compatible: should be "mediatek,mt8173-u3phy"
> + - reg   : offset and length of register for phy, exclude port's
> +   register.
> + - clocks: a list of phandle + clock-specifier pairs, one for each
> +   entry in clock-names
> + - clock-names   : must contain
> +   "u3phya_ref": for reference clock of usb3.0 analog phy.
> +
> +Required nodes   : a sub-node is required for each port the controller
> +   provides. Address range information including the usual
> +   'reg' property is used inside these nodes to describe
> +   the controller's topology. These nodes are translated
> +   by the driver's .xlate() function.
> +
> +Required properties (port (child) node):
> +- reg: address and length of the register set for the port.
> +- #phy-cells : should be 1 (See second example)
> +   cell after port phandle is phy type from:
> + - PHY_TYPE_USB2
> + - PHY_TYPE_USB3
> +
> +Example:
> +
> +u3phy: usb-phy@1129 {
> + compatible = "mediatek,mt8173-u3phy";
> + reg = <0 0x1129 0 0x800>;
> + clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
> + clock-names = "u3phya_ref";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + status = "okay";
> +
> + phy_port0: port@11290800 {
> + reg = <0 0x11290800 0 0x800>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +
> + phy_port1: port@11291000 {
> + reg = <0 0x11291000 0 0x800>;
> + #phy-cells = <1>;
> + status = "okay";
> + };
> +};
> +
> +Specifying phy control of devices
> +-
> +
> +Device nodes should specify the configuration required in their "phys"
> +property, containing a phandle to the phy port node and a device type;
> +phy-names for each port are optional.
> +
> +Example:
> +
> +#include 
> +
> +usb30: usb@1127 {
> + ...
> + phys = <&phy_port0 PHY_TYPE_USB3>;
> + phy-names = "usb3-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 v2 2/2] MIPS: ath79: add irq chip ar7240-misc-intc

[Alban]

On Wed,  9 Sep 2015 11:16:18 +0200
Alexander Couzens  wrote:

> The ar7240 misc irq chip use ack handler
> instead of ack_mask handler. All new ath79 chips use
> the ar7240 misc irq chip
> 
> Signed-off-by: Alexander Couzens 
> ---
>  .../interrupt-controller/qca,ath79-misc-intc.txt | 20 
> ++--
>  arch/mips/ath79/irq.c| 10 ++
>  2 files changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
>  
> b/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
> index 391717a..ec96b1f 100644
> --- 
> a/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
> +++ 
> b/Documentation/devicetree/bindings/interrupt-controller/qca,ath79-misc-intc.txt
> @@ -4,8 +4,8 @@ The MISC interrupt controller is a secondary controller for 
> lower priority
>  interrupt.
>  
>  Required Properties:
> -- compatible: has to be "qca,-cpu-intc", "qca,ar7100-misc-intc"
> -  as fallback
> +- compatible: has to be "qca,-cpu-intc", "qca,ar7100-misc-intc" or
> +  "qca,-cpu-intc", "qca,ar7240-misc-intc"
>  - reg: Base address and size of the controllers memory area
>  - interrupt-parent: phandle of the parent interrupt controller.
>  - interrupts: Interrupt specifier for the controllers interrupt.
> @@ -13,6 +13,9 @@ Required Properties:
>  - #interrupt-cells : Specifies the number of cells needed to encode interrupt
>source, should be 1
>  
> +Compatible fallback depends on the SoC. Use ar7100 for ar71xx and ar913x,
> +use ar7240 for all other SoCs.
> +
>  Please refer to interrupts.txt in this directory for details of the common
>  Interrupt Controllers bindings used by client devices.
>  
> @@ -28,3 +31,16 @@ Example:
>   interrupt-controller;
>   #interrupt-cells = <1>;
>   };
> +
> +Another example:
> +
> + interrupt-controller@18060010 {
> + compatible = "qca,ar9331-misc-intc", qca,ar7240-misc-intc";
> + reg = <0x18060010 0x4>;
> +
> + interrupt-parent = <&cpuintc>;
> + interrupts = <6>;
> +
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> diff --git a/arch/mips/ath79/irq.c b/arch/mips/ath79/irq.c
> index c9c0124..fd58f8b 100644
> --- a/arch/mips/ath79/irq.c
> +++ b/arch/mips/ath79/irq.c
> @@ -319,6 +319,16 @@ static int __init ar7100_misc_intc_of_init(
>  IRQCHIP_DECLARE(ar7100_misc_intc, "qca,ar7100-misc-intc",
>   ar7100_misc_intc_of_init);
>  
> +static int __init ar7240_misc_intc_of_init(
> + struct device_node *node, struct device_node *parent)
> +{
> + ath79_misc_irq_chip.irq_ack = ar724x_misc_irq_ack;
> + return ath79_misc_intc_of_init(node, parent);
> +}
> +
> +IRQCHIP_DECLARE(ar7240_misc_intc, "qca,ar7240-misc-intc",
> + ar7240_misc_intc_of_init);
> +
>  static int __init ar79_cpu_intc_of_init(
>   struct device_node *node, struct device_node *parent)
>  {

Acked-by: Alban Bedel 
--
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] MIPS: ath79: set missing irq ack handler for ar7100-misc-intc irq chip

[Alban]

On Wed,  9 Sep 2015 11:16:17 +0200
Alexander Couzens  wrote:

> The irq ack handler was forgotten while introducing OF support.
> Only ar71xx and ar933x based devices require it.
> 
> Signed-off-by: Alexander Couzens 
> ---
>  arch/mips/ath79/irq.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/mips/ath79/irq.c b/arch/mips/ath79/irq.c
> index afb0096..c9c0124 100644
> --- a/arch/mips/ath79/irq.c
> +++ b/arch/mips/ath79/irq.c
> @@ -308,8 +308,16 @@ static int __init ath79_misc_intc_of_init(
>  
>   return 0;
>  }
> -IRQCHIP_DECLARE(ath79_misc_intc, "qca,ar7100-misc-intc",
> - ath79_misc_intc_of_init);
> +
> +static int __init ar7100_misc_intc_of_init(
> + struct device_node *node, struct device_node *parent)
> +{
> + ath79_misc_irq_chip.irq_mask_ack = ar71xx_misc_irq_mask;
> + return ath79_misc_intc_of_init(node, parent);
> +}
> +
> +IRQCHIP_DECLARE(ar7100_misc_intc, "qca,ar7100-misc-intc",
> + ar7100_misc_intc_of_init);
>  
>  static int __init ar79_cpu_intc_of_init(
>   struct device_node *node, struct device_node *parent)

Acked-by: Alban Bedel 
--
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/2] MIPS: ath79: set missing irq ack handler for ar7100-misc-intc irq chip

[Alban]

On Wed, 9 Sep 2015 11:04:06 +0200
Alexander Couzens  wrote:

> On Thu, 3 Sep 2015 10:32:45 +0200
> Alban  wrote:
> 
> > > -IRQCHIP_DECLARE(ath79_misc_intc, "qca,ar7100-misc-intc",
> > > - ath79_misc_intc_of_init);
> > > +
> > > +static int __init ar7100_misc_intc_of_init(
> > > + struct device_node *node, struct device_node *parent)
> > > +{
> > > + pr_info("IRQ: Setup ar7100 misc IRQ controller from
> > > devicetree.\n");
> > 
> > Debug left over?
> 
> I'll remove it in next patch. I added it because you mentioned a log
> message in your last review.

I meant the commit log, sorry for the misunderstanding.

Alban


signature.asc
Description: PGP signature

Re: [PATCH v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Lee Jones]

On Wed, 09 Sep 2015, Viresh Kumar wrote:
> On 09-09-15, 08:59, Lee Jones wrote:
> > Thanks for doing this Viresh.  I appreciate your efforts.
> 
> I wanted to get this sorted out, before we meet face to face :)
> 
> > > -8<-
> > > From: Viresh Kumar 
> > > Date: Wed, 9 Sep 2015 11:47:37 +0530
> > > Subject: [PATCH] PM / OPP: Add "opp-cuts" and "opp-supply-version" 
> > > bindings
> > > 
> > > For many platforms it is unknown until runtime, about which OPPs should
> > > be used or if used what should be voltage range for the supplies for a
> > > particular frequency. And this mostly depends on the version of the
> > > device or hardware, for which the OPPs are getting used.
> > > 
> > > This patch adds two new OPP bindings to get this solved.
> > > 
> > > 1. "opp-cuts": The purpose of this binding is to allow the platform to
> > >identify the valid OPPs based on the different levels of versions
> > >with which the hardware is identified.
> > 
> > "cuts" is a very specific name for such a generic property.
> 
> I agree... I wasn't concerned much about naming on the first try and
> so just wrote it quickly enough to get an overall idea ..
> 
> > You are using the format I suggested weeks ago, which I like.
> 
> I must have missed that :(
> 
> > So how about:
> > 
> > opp-hw-version:
> > User defined array containing a hierarchy of version numbers.
> > 
> > E.g: Taking kernel version v2.6.19 for instance:
> > <2, 6, 19>;
> > 
> > E.g: Representing Major 2 Minor 0, Cuts ALL and Substrate 5:
> > <2, 0, 0x, 5>;
> 
> At least what I suggested in my attempt here is a bit different than
> what you might be thinking. For example, consider a case with single
> level of hierarchy, say cuts. And that the SoC has got 10 different
> cuts, and we name them 0-9. So, the values I was looking to fill to
> the opp-hw-version field is like: (1 << version_num). So, if an OPP
> supports version 2, 5 and 7, the value will be 0x00A4. i.e. with
> the respective bit positions set. And by this way only 0x can
> mean all versions ..

Okay, I see what you mean.  Sound fine, although only allows up to 31
versions.  Not an issue for us I don't think, but could be for other
vendors.  Taking a recent example, the kernel recently went up to
v2.6.39 and some of the stable releases have gone up to v3.4.108.
Depends what you wish to support.

> > > 2. "opp-supply-name": The purpose of this binding is to allow the
> > >platform to select the voltage range of the power supplies, for a
> > >valid OPP.
> > 
> > Did you mean 'opp-supply-version', like in the example below?
> 
> Urg. Yeah.
> 
> > I suggest '-name' would be better than '-version'.
> 
> So, its not name of the supply really, but a virtual name given to the
> voltage-range which we need to pick based on the hardware version.

We usually call these 'names'; reg-names, clock-names, pinctrl-names,
phy-names, dma-names, etc.

> > I guess this is a Qcom specific feature.  I'll let Stephen comment.
> 
> No. So, my plan was to use this instead of the st,avs & pcode thing
> you have got in your bindings. So, instead of 'slow' and 'fast' from
> my example, it will have the corresponding strings for pcode numbers.
> And at runtime the platform will pass a string to the OPP library, to
> activate/add OPPs only for a specific opp-supply-version.

So you're using it to index into a 2 dimensional array of opp-hz's.

Eek!

> Maybe we can name it 'opp-supply-range-name'..
> 
> > > Both of these can be used together, as well as independently.
> > > 
> > > Signed-off-by: Viresh Kumar 
> > > ---
> > >  Documentation/devicetree/bindings/opp/opp.txt | 90 
> > > +++
> > >  1 file changed, 90 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
> > > b/Documentation/devicetree/bindings/opp/opp.txt
> > > index c56a6b1a44ef..def75f7a3614 100644
> > > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > > @@ -98,6 +98,13 @@ This describes the OPPs belonging to a device. This 
> > > node can have following
> > >information. But for multiple power-supplies, this must be set to pass
> > >triplet style values.
> > >  
> > > +- opp-supply-version: One or more strings describing version of the 
> > > supplies on
> > 
> > What kind of supplies?  Supplies to me means regulator supplies, which
> > I fear would be too easily confused with the regulator '*-supply'
> > property.
> 
> Yeah, its more like opp-supply-range-names ..
> 
> > > +  the platform. This is useful for the cases, where the platform wants 
> > > to select
> > > +  the voltage range for supplies at runtime, based on the specific 
> > > version of
> > > +  the hardware. There should be one entry in opp-microvolt array, for 
> > > each
> > > +  string present here. OPPs for the device must be configured, only for 
> > > a single
> > > +  

[PATCH linux-next v6 5/8] Documentation: mtd: add a DT property to set the number of dummy cycles

[Cyrille Pitchen]

Depending on the SPI clock frequency, the Fast Read op code and the
Single/Dual Data Rate mode, the number of dummy cycles can be tuned to
improve transfer speed.
The actual number of dummy cycles is specific for each memory model and is
provided by the manufacturer thanks to the memory datasheet.

Signed-off-by: Cyrille Pitchen 
---
 Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt 
b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
index 2bee68103b01..4387567d8024 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
@@ -19,6 +19,11 @@ Optional properties:
all chips and support for it can not be detected at runtime.
Refer to your chips' datasheet to check if this is supported
by your chip.
+- m25p,num-dummy-cycles : Set the number of dummy cycles for Fast Read 
commands.
+  Depending on the manufacturer additional dedicated
+  commands are sent to the flash memory so the
+  controller and the memory can agree on the number of
+  dummy cycles to use.
 
 Example:
 
@@ -29,4 +34,5 @@ Example:
reg = <0>;
spi-max-frequency = <4000>;
m25p,fast-read;
+   m25p,num-dummy-cycles = <8>;
};
-- 
1.8.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

[PATCH linux-next v6 8/8] mtd: atmel-quadspi: add driver for Atmel QSPI controller

[Cyrille Pitchen]

This driver add support to the new Atmel QSPI controller embedded into
sama5d2x SoCs. It expects a NOR memory to be connected to the QSPI
controller.

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/Kconfig |   7 +
 drivers/mtd/spi-nor/Makefile|   1 +
 drivers/mtd/spi-nor/atmel-quadspi.c | 889 
 3 files changed, 897 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 89bf4c1faa2b..7a3d55429550 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -29,6 +29,13 @@ config SPI_FSL_QUADSPI
  This controller does not support generic SPI. It only supports
  SPI NOR.
 
+config SPI_ATMEL_QUADSPI
+   tristate "Atmel Quad SPI Controller"
+   depends on OF && HAS_DMA && (ARCH_AT91 || COMPILE_TEST)
+   help
+ This enables support for the Quad SPI controller in master mode.
+ We only connect the NOR to this controller now.
+
 config SPI_NXP_SPIFI
tristate "NXP SPI Flash Interface (SPIFI)"
depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index e5ef8582..f5d23d7379bb 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_MTD_SPI_NOR)  += spi-nor.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
+obj-$(CONFIG_SPI_ATMEL_QUADSPI)+= atmel-quadspi.o
 obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c 
b/drivers/mtd/spi-nor/atmel-quadspi.c
new file mode 100644
index ..dc0c1d8293d5
--- /dev/null
+++ b/drivers/mtd/spi-nor/atmel-quadspi.c
@@ -0,0 +1,889 @@
+/*
+ * Driver for Atmel QSPI Controller
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Cyrille Pitchen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ *
+ * This driver is based on drivers/mtd/spi-nor/fsl-quadspi.c from Freescale.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* QSPI register offsets */
+#define QSPI_CR  0x  /* Control Register */
+#define QSPI_MR  0x0004  /* Mode Register */
+#define QSPI_RD  0x0008  /* Receive Data Register */
+#define QSPI_TD  0x000c  /* Transmit Data Register */
+#define QSPI_SR  0x0010  /* Status Register */
+#define QSPI_IER 0x0014  /* Interrupt Enable Register */
+#define QSPI_IDR 0x0018  /* Interrupt Disable Register */
+#define QSPI_IMR 0x001c  /* Interrupt Mask Register */
+#define QSPI_SCR 0x0020  /* Serial Clock Register */
+
+#define QSPI_IAR 0x0030  /* Instruction Address Register */
+#define QSPI_ICR 0x0034  /* Instruction Code Register */
+#define QSPI_IFR 0x0038  /* Instruction Frame Register */
+
+#define QSPI_SMR 0x0040  /* Scrambling Mode Register */
+#define QSPI_SKR 0x0044  /* Scrambling Key Register */
+
+#define QSPI_WPMR0x00E4  /* Write Protection Mode Register */
+#define QSPI_WPSR0x00E8  /* Write Protection Status Register */
+
+#define QSPI_VERSION 0x00FC  /* Version Register */
+
+
+/* Bitfields in QSPI_CR (Control Register) */
+#define QSPI_CR_QSPIEN  BIT(0)
+#define QSPI_CR_QSPIDIS BIT(1)
+#define QSPI_CR_SWRST   BIT(7)
+#define QSPI_CR_LASTXFERBIT(24)
+
+/* Bitfields in QSPI_MR (Mode Register) */
+#define QSPI_MR_SSM BIT(0)
+#define QSPI_MR_LLB BIT(1)
+#define QSPI_MR_WDRBT   BIT(2)
+#define QSPI_MR_SMRMBIT(3)
+#define QSPI_MR_CSMODE_MASK GENMASK(5, 4)
+#define QSPI_MR_CSMODE_NOT_RELOADED (0 << 4)
+#define QSPI_MR_CSMODE_LASTXFER (1 << 4)
+#define QSPI_MR_CSMODE_SYSTEMATICALLY   (2 << 4)
+#define QSPI_MR_NBBITS_MASK GENMASK(11, 8)
+#define QSPI_MR_NBBITS(n)   n) - 8) << 8) & 
QSPI_MR_NBBITS_MASK)
+#define QSPI_MR_DLYBCT_MASK GENMASK(23, 16)
+#define QSPI_MR_DLYBCT(n)   (((n) << 16) & QSPI_MR_DLYBCT_MASK)
+#define QSPI_MR_DLYCS_MASK  GENMASK(31, 24)
+#define QSPI_MR_DLYCS(n)(((n) << 24) & QSPI_MR_DLYCS_MASK)
+
+/* Bitfields in QSPI_SR/QSPI_IER/QSPI_IDR/QSPI_IMR  *

Re: [PATCH 1/3] sysfs: Fix is_visible() support for binary attributes

[Guenter Roeck]

On 09/09/2015 06:14 AM, Emilio López wrote:

On 09/09/15 01:12, Guenter Roeck wrote:

On 09/08/2015 08:58 PM, Greg KH wrote:

On Tue, Sep 08, 2015 at 06:10:16PM -0700, Guenter Roeck wrote:

Hi Emilio,

On 09/08/2015 05:51 PM, Emilio López wrote:

Hi Greg & Guenter,


[ ... ]


Unless I am missing something, this is not explained anywhere,
but it is
not entirely trivial to understand. I think it should be documented.


I agree. I couldn't find any mention of what this int was supposed
to be by looking at Documentation/ (is_visible is not even mentioned
:/) or include/linux/sysfs.h. Once we settle on something I'll
document it before sending a v2.


In the include file ? No strong preference, though.


By the way, I wrote a quick coccinelle script to match is_visible()
users which reference the index (included below), and it found
references to drivers which do not seem to use any binary
attributes, so I believe changing the index meaning shouldn't be an
issue.


Good.


I agree, make i the number of the bin attribute and that should solve
this issue.


No, that would conflict with the "normal" use of is_visible for
non-binary
attributes, and make the index all but useless, since the
is_visible function
would have to search through all the attributes anyway to figure
out which one
is being checked.


Yeah, using the same indexes would be somewhat pointless, although
not many seem to be using it anyway (only 14 files matched). Others
seem to be comparing the attr* instead. An alternative would be to
use negative indexes for binary attributes and positive indexes for
normal attributes.


... and I probably wrote or reviewed a significant percentage of
those ;-).

Using negative numbers for binary attributes is an interesting idea.
Kind of unusual, though. Greg, any thoughts on that ?


Ick, no, that's a mess, maybe we just could drop the index alltogether?



No, please don't. Having to manually compare dozens of index pointers
would be
even more of a mess.


So, what about keeping it the way it is in the patch, and documenting it thoroughly? 
Otherwise, we could introduce another "is_bin_visible" function to do this same 
thing but just on binary attributes, but I'd rather not add a new function pointer if 
possible.



I would prefer to keep and document it.

Guenter

--
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 linux-next v6 6/8] mtd: spi-nor: allow to tune the number of dummy cycles

[Cyrille Pitchen]

The number of dummy cycles used during Fast Read commands can be reduced
to improve transfer performances. Each manufacturer has a dedicated set of
registers to provide the memory with the exact number of dummy cycles it
should expect. Both the memory and the (Q)SPI controller must agree on
this number of dummy cycles.

The number of dummy cycles can be found into the memory datasheet and
mostly depends on the SPI clock frequency, the Fast Read op code and the
Single/Dual Data Rate mode.

Probing JEDEC Serial Flash Discoverable Parameters (SFDP) tables would
only provide the driver with a high enough number of dummy cycles for each
Fast Read command to be used for all clock frequencies: this solution
would not be optimized.

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/spi-nor.c | 102 ++
 include/linux/mtd/spi-nor.h   |   2 +
 2 files changed, 85 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 820a2177ed5e..7405a1450dd1 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -121,24 +121,6 @@ static int read_cr(struct spi_nor *nor)
 }
 
 /*
- * Dummy Cycle calculation for different type of read.
- * It can be used to support more commands with
- * different dummy cycle requirements.
- */
-static inline int spi_nor_read_dummy_cycles(struct spi_nor *nor)
-{
-   switch (nor->flash_read) {
-   case SPI_NOR_FAST:
-   case SPI_NOR_DUAL:
-   case SPI_NOR_QUAD:
-   return 8;
-   case SPI_NOR_NORMAL:
-   return 0;
-   }
-   return 0;
-}
-
-/*
  * Write status register 1 byte
  * Returns negative if error occurred.
  */
@@ -1194,6 +1176,86 @@ static void tune_manufacturer_commands(struct spi_nor 
*nor,
}
 }
 
+static int micron_set_dummy_cycles(struct spi_nor *nor)
+{
+   int ret;
+   u8 val, mask;
+
+   /* Read the Volatile Configuration Register (VCR). */
+   ret = nor->read_reg(nor, SPINOR_OP_RD_VCR, &val, 1);
+   if (ret < 0) {
+   dev_err(nor->dev, "error %d reading VCR\n", ret);
+   return ret;
+   }
+
+   write_enable(nor);
+
+   /* Update the number of dummy into the VCR. */
+   mask = GENMASK(7, 4);
+   val &= ~mask;
+   val |= (nor->read_dummy << 4) & mask;
+   ret = nor->write_reg(nor, SPINOR_OP_WR_VCR, &val, 1, 0);
+   if (ret < 0) {
+   dev_err(nor->dev, "error while writing VCR register\n");
+   return ret;
+   }
+
+   ret = spi_nor_wait_till_ready(nor);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+/*
+ * Dummy Cycle calculation for different type of read.
+ * It can be used to support more commands with
+ * different dummy cycle requirements.
+ */
+static int spi_nor_read_dummy_cycles(struct spi_nor *nor,
+const struct flash_info *info)
+{
+   struct device_node *np = nor->dev->of_node;
+   struct device *dev = nor->dev;
+   u32 num_dummy_cycles;
+
+   if (np && !of_property_read_u32(np, "m25p,num-dummy-cycles",
+   &num_dummy_cycles)) {
+   nor->read_dummy = num_dummy_cycles;
+
+   /*
+* This switch block might be moved at the end of the function,
+* once nor->read_dummy has been set, but it was not tested with
+* all Micron memories.
+* Now the "m25p,num-dummy-cycles" property needs to be
+* explicitly set in the device tree so the switch statement is
+* executed. This should avoid unwanted side effects and keep
+* backward compatibility.
+*/
+   switch (JEDEC_MFR(info)) {
+   case CFI_MFR_ST:
+   return micron_set_dummy_cycles(nor);
+   default:
+   dev_warn(dev,
+"Tuning of the number of dummy cycles is not 
implemented for spi-nor of this manufacturer,\n"
+"ignoring the DT property value and falling 
back to the framework default settings.\n");
+   break;
+   }
+   }
+
+   /* Fallback to legacy code. */
+   switch (nor->flash_read) {
+   case SPI_NOR_FAST:
+   case SPI_NOR_DUAL:
+   case SPI_NOR_QUAD:
+   nor->read_dummy = 8;
+   case SPI_NOR_NORMAL:
+   nor->read_dummy = 0;
+   }
+
+   return 0;
+}
+
 static int spi_nor_check(struct spi_nor *nor)
 {
if (!nor->dev || !nor->read || !nor->write ||
@@ -1387,7 +1449,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
enum read_mode mode)
/* Tune read, page program and erase commands */
tune_manufacturer_commands(nor, info);
 
-   nor->read_dummy = spi_nor_read_dummy_cycles(nor);
+   ret = spi_nor_read_dummy_cycles(n

[PATCH v2 1/1] ARM: dts: sun7i: Enable axp209 driver on olinuxino lime2

[Olliver Schinagl]

The Olimex OLinuXino Lime2 uses the same AXP209 as was recently
introduced this driver for its power regulation.

Signed-off-by: Olliver Schinagl 
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 87 +
 1 file changed, 31 insertions(+), 56 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..dd90a1d 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -71,14 +71,6 @@
default-state = "on";
};
};
-
-   reg_axp_ipsout: axp_ipsout {
-   compatible = "regulator-fixed";
-   regulator-name = "axp-ipsout";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   regulator-always-on;
-   };
 };
 
 &ahci {
@@ -86,6 +78,10 @@
status = "okay";
 };
 
+&cpu0 {
+   cpu-supply = <®_dcdc2>;
+};
+
 &ehci0 {
status = "okay";
 };
@@ -112,57 +108,9 @@
status = "okay";
 
axp209: pmic@34 {
-   compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
-
-   acin-supply = <®_axp_ipsout>;
-   vin2-supply = <®_axp_ipsout>;
-   vin3-supply = <®_axp_ipsout>;
-   ldo24in-supply = <®_axp_ipsout>;
-   ldo3in-supply = <®_axp_ipsout>;
-
-   regulators {
-   vdd_rtc: ldo1 {
-   regulator-min-microvolt = <130>;
-   regulator-max-microvolt = <130>;
-   regulator-always-on;
-   };
-
-   avcc: ldo2 {
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
-
-   vcc_csi0: ldo3 {
-   regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <350>;
-   regulator-always-on;
-   };
-
-   vcc_csi1: ldo4 {
-   regulator-min-microvolt = <125>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
-
-   vdd_cpu: dcdc2 {
-   regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <2275000>;
-   regulator-always-on;
-   };
-
-   vdd_int: dcdc3 {
-   regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <350>;
-   regulator-always-on;
-   };
-   };
};
 };
 
@@ -243,6 +191,33 @@
status = "okay";
 };
 
+#include "axp209.dtsi"
+
+®_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <145>;
+   regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 ®_usb0_vbus {
pinctrl-0 = <&usb0_vbus_pin_lime2>;
gpio = <&pio 2 17 GPIO_ACTIVE_HIGH>;
-- 
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

[PATCH v2 0/1] Enable axp209 on OLinuXino lime2

[Olliver Schinagl]

This patch adds the new AXP209 node on the OLinuXino Lime2.
The previously submitted otg enablement patch is needed to avoid merge
conflicts.

Signed-off-by: Olliver Schinagl 

Olliver Schinagl (1):
  ARM: dts: sun7i: Enable axp209 driver on olinuxino lime2

 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 87 +
 1 file changed, 31 insertions(+), 56 deletions(-)

-- 
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

[PATCH linux-next v6 7/8] Documentation: atmel-quadspi: add binding file for Atmel QSPI driver

[Cyrille Pitchen]

This patch documents the DT bindings for the driver of the Atmel QSPI
controller embedded inside sama5d2x SoCs.

Signed-off-by: Cyrille Pitchen 
Acked-by: Nicolas Ferre 
Acked-by: Marek Vasut 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/mtd/atmel-quadspi.txt  | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt

diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
new file mode 100644
index ..0b8d545bb198
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
@@ -0,0 +1,29 @@
+* Atmel Quad Serial Peripheral Interface (QSPI)
+
+Required properties:
+- compatible: should be "atmel,sama5d2-qspi"
+- reg:the first contains the register location and length,
+  the second contains the memory mapping address and length
+- interrupts: should contain the interrupt for the device
+- clocks: the phandle of the clock needed by the QSPI controller
+- #address-cells: should be <1>
+- #size-cells:should be <0>
+
+Example:
+
+spi@f002 {
+   compatible = "atmel,sama5d2-qspi";
+   reg = <0xf002 0x100>,
+ <0xd000 0x800>;
+   interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
+   clocks = <&spi0_clk>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_spi0_default>;
+   status = "okay";
+
+   m25p80@0 {
+   ...
+   };
+};
-- 
1.8.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

[PATCH linux-next v6 4/8] mtd: spi-nor: use optimized commands for read/write/erase operations

[Cyrille Pitchen]

The op codes used by the spi-nor framework are now tuned depending on the
memory manufacturer.

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/spi-nor.c | 156 +++---
 include/linux/mtd/spi-nor.h   |   6 ++
 2 files changed, 138 insertions(+), 24 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 4b36aada3f4c..820a2177ed5e 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -193,6 +193,8 @@ static inline int set_4byte(struct spi_nor *nor, const 
struct flash_info *info,
write_disable(nor);
 
return status;
+   case CFI_MFR_AMD:
+   return 0;
default:
/* Spansion style */
nor->cmd_buf[0] = enable << 7;
@@ -945,7 +947,7 @@ static int spansion_quad_enable(struct spi_nor *nor)
}
 
/* set read/write protocols */
-   nor->read_proto = SPI_PROTO_1_1_4;
+   nor->read_proto = SPI_PROTO_1_4_4;
nor->write_proto = SPI_PROTO_1_1_4;
 
return 0;
@@ -1059,7 +1061,7 @@ static int set_dual_mode(struct spi_nor *nor, const 
struct flash_info *info)
return status;
case CFI_MFR_MACRONIX:
case CFI_MFR_AMD:
-   nor->read_proto = SPI_PROTO_1_1_2;
+   nor->read_proto = SPI_PROTO_1_2_2;
break;
default:
break;
@@ -1068,6 +1070,130 @@ static int set_dual_mode(struct spi_nor *nor, const 
struct flash_info *info)
return 0;
 }
 
+static void macronix_set_commands(struct spi_nor *nor)
+{
+   switch (nor->flash_read) {
+   case SPI_NOR_QUAD: /* QPI mode */
+   nor->read_opcode = SPINOR_OP_READ_1_4_4;
+   break;
+
+   case SPI_NOR_DUAL:
+   nor->read_opcode = SPINOR_OP_READ_1_2_2;
+   break;
+
+   case SPI_NOR_FAST:
+   nor->read_opcode = SPINOR_OP_READ_FAST;
+   break;
+
+   case SPI_NOR_NORMAL:
+   default:
+   nor->read_opcode = SPINOR_OP_READ;
+   break;
+   }
+
+   nor->program_opcode = SPINOR_OP_PP;
+}
+
+static void micron_set_commands(struct spi_nor *nor)
+{
+   switch (nor->flash_read) {
+   case SPI_NOR_QUAD: /* Quad I/O operations */
+   nor->read_opcode = SPINOR_OP_READ_1_4_4;
+   break;
+
+   case SPI_NOR_DUAL: /* Dual I/O operations */
+   nor->read_opcode = SPINOR_OP_READ_1_2_2;
+   break;
+
+   case SPI_NOR_FAST:
+   nor->read_opcode = SPINOR_OP_READ_FAST;
+   break;
+
+   case SPI_NOR_NORMAL:
+   default:
+   nor->read_opcode = SPINOR_OP_READ;
+   break;
+   }
+
+   nor->program_opcode = SPINOR_OP_PP;
+}
+
+static void spansion_set_commands(struct spi_nor *nor,
+ const struct flash_info *info)
+{
+   bool addr_4byte = (nor->addr_width == 4);
+   struct mtd_info *mtd = nor->mtd;
+
+   switch (nor->flash_read) {
+   case SPI_NOR_QUAD:
+   if (addr_4byte) {
+   nor->read_opcode = SPINOR_OP_READ4_1_4_4;
+   nor->program_opcode = SPINOR_OP_PP_4B_1_1_4;
+   } else {
+   nor->read_opcode = SPINOR_OP_READ_1_4_4;
+   nor->program_opcode = SPINOR_OP_PP_1_1_4;
+   }
+   break;
+
+   case SPI_NOR_DUAL:
+   if (addr_4byte) {
+   nor->read_opcode = SPINOR_OP_READ4_1_2_2;
+   nor->program_opcode = SPINOR_OP_PP_4B;
+   } else {
+   nor->read_opcode = SPINOR_OP_READ_1_2_2;
+   nor->program_opcode = SPINOR_OP_PP;
+   }
+   break;
+
+   case SPI_NOR_FAST:
+   if (addr_4byte) {
+   nor->read_opcode = SPINOR_OP_READ4_FAST;
+   nor->program_opcode = SPINOR_OP_PP_4B;
+   } else {
+   nor->read_opcode = SPINOR_OP_READ_FAST;
+   nor->program_opcode = SPINOR_OP_PP;
+   }
+   break;
+
+   case SPI_NOR_NORMAL:
+   default:
+   if (addr_4byte) {
+   nor->read_opcode = SPINOR_OP_READ4;
+   nor->program_opcode = SPINOR_OP_PP_4B;
+   } else {
+   nor->read_opcode = SPINOR_OP_READ;
+   nor->program_opcode = SPINOR_OP_PP;
+   }
+   break;
+   }
+
+   if (addr_4byte) {
+   nor->erase_opcode = SPINOR_OP_SE_4B;
+   mtd->erasesize = info->sector_size;
+   }
+}
+
+static void tune_manufacturer_commands(struct spi_nor *nor,
+  const struct flash_info *info)
+{
+   switch (JEDEC_MFR(info)) {
+   case CFI_MFR_MACRONIX:

[PATCH linux-next v6 3/8] mtd: spi-nor: update the SPI protocol when enabling manufacturer Quad mode

[Cyrille Pitchen]

Micron:
Once their Quad SPI protocol enabled, Micron spi-nor memories expect all
commands to use the SPI 4-4-4 protocol. Also when the Dual SPI protocol is
enabled, all commands must use the SPI 2-2-2 protocol.

Macronix:
When the QPI mode is enabled, all commands must use the SPI 4-4-4 protocol.

Spansion:
When Quad I/O operations are enabled, the Fast Read Quad Output (0x6b / 0x6c)
commands use the SPI 1-1-4 protocol, the Page Program Quad Output (0x32 /
0x34) command use the SPI 1-1-4 protocol whereas other commands use the
SPI 1-1-1 protocol.

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/spi-nor.c | 74 ---
 include/linux/mtd/spi-nor.h   |  1 +
 2 files changed, 70 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 80a0db078aaa..4b36aada3f4c 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -891,6 +891,12 @@ static int macronix_quad_enable(struct spi_nor *nor)
nor->cmd_buf[0] = val | SR_QUAD_EN_MX;
nor->write_reg(nor, SPINOR_OP_WRSR, nor->cmd_buf, 1, 0);
 
+   /* Once QPI mode enabled, all commands use SPI 4-4-4 protocol. */
+   nor->erase_proto = SPI_PROTO_4_4_4;
+   nor->read_proto = SPI_PROTO_4_4_4;
+   nor->write_proto = SPI_PROTO_4_4_4;
+   nor->reg_proto = SPI_PROTO_4_4_4;
+
if (spi_nor_wait_till_ready(nor))
return 1;
 
@@ -938,10 +944,16 @@ static int spansion_quad_enable(struct spi_nor *nor)
return -EINVAL;
}
 
+   /* set read/write protocols */
+   nor->read_proto = SPI_PROTO_1_1_4;
+   nor->write_proto = SPI_PROTO_1_1_4;
+
return 0;
 }
 
-static int micron_quad_enable(struct spi_nor *nor)
+static int micron_set_protocol(struct spi_nor *nor,
+  u8 mask, u8 value,
+  enum spi_protocol proto)
 {
int ret;
u8 val;
@@ -954,14 +966,20 @@ static int micron_quad_enable(struct spi_nor *nor)
 
write_enable(nor);
 
-   /* set EVCR, enable quad I/O */
-   nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+   /* set EVCR protocol bits */
+   nor->cmd_buf[0] = (val & ~mask) | value;
ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
if (ret < 0) {
dev_err(nor->dev, "error while writing EVCR register\n");
return ret;
}
 
+   /* switch protocol for ALL commands */
+   nor->erase_proto = proto;
+   nor->read_proto = proto;
+   nor->write_proto = proto;
+   nor->reg_proto = proto;
+
ret = spi_nor_wait_till_ready(nor);
if (ret)
return ret;
@@ -972,14 +990,23 @@ static int micron_quad_enable(struct spi_nor *nor)
dev_err(nor->dev, "error %d reading EVCR\n", ret);
return ret;
}
-   if (val & EVCR_QUAD_EN_MICRON) {
-   dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+   if ((val & mask) != value) {
+   dev_err(nor->dev, "Micron EVCR protocol bits not valid\n");
return -EINVAL;
}
 
return 0;
 }
 
+static inline int micron_quad_enable(struct spi_nor *nor)
+{
+   /* Clear Quad bit to enable quad mode */
+   return micron_set_protocol(nor,
+  EVCR_QUAD_EN_MICRON | EVCR_DUAL_EN_MICRON,
+  EVCR_DUAL_EN_MICRON,
+  SPI_PROTO_4_4_4);
+}
+
 static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 {
int status;
@@ -1009,6 +1036,38 @@ static int set_quad_mode(struct spi_nor *nor, const 
struct flash_info *info)
}
 }
 
+static inline int micron_dual_enable(struct spi_nor *nor)
+{
+   /* Clear Dual bit but keep Quad bit set to enable dual mode */
+   return micron_set_protocol(nor,
+  EVCR_QUAD_EN_MICRON | EVCR_DUAL_EN_MICRON,
+  EVCR_QUAD_EN_MICRON,
+  SPI_PROTO_2_2_2);
+}
+
+static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
+{
+   int status;
+
+   switch (JEDEC_MFR(info)) {
+   case CFI_MFR_ST:
+   status = micron_dual_enable(nor);
+   if (status) {
+   dev_err(nor->dev, "Micron dual-read not enabled\n");
+   return -EINVAL;
+   }
+   return status;
+   case CFI_MFR_MACRONIX:
+   case CFI_MFR_AMD:
+   nor->read_proto = SPI_PROTO_1_1_2;
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
 static int spi_nor_check(struct spi_nor *nor)
 {
if (!nor->dev || !nor->read || !nor->write ||
@@ -1160,6 +1219,11 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
enum read_mode mode)
}
nor->flash_re

[PATCH linux-next v6 1/8] mtd: spi-nor: read JEDEC ID with multiple I/O protocols

[Cyrille Pitchen]

When their quad or dual I/O mode is enabled, Micron and Macronix spi-nor
memories don't reply to the regular Read ID (0x9f) command. Instead they
reply to a new dedicated command Read ID Multiple I/O (0xaf).

If the Read ID (0x9f) command fails (the read ID is all 1's or all 0's),
then the Read ID Multiple I/O (0xaf) is used, first with SPI 4-4-4 protocol
(supported by both Micron and Macronix memories), lately with SPI-2-2-2
protocol (supported only by Micron memories).

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/spi-nor.c | 28 +++-
 include/linux/mtd/spi-nor.h   | 23 +--
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index f59aedfe1462..80a0db078aaa 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -703,8 +703,9 @@ static const struct flash_info spi_nor_ids[] = {
 
 static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
 {
-   int tmp;
+   int i, tmp;
u8  id[SPI_NOR_MAX_ID_LEN];
+   enum spi_protocol   proto[2] = {SPI_PROTO_4_4_4, SPI_PROTO_2_2_2};
const struct flash_info *info;
 
tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
@@ -713,6 +714,25 @@ static const struct flash_info *spi_nor_read_id(struct 
spi_nor *nor)
return ERR_PTR(tmp);
}
 
+   /* Special case for Micron/Macronix qspi nor. */
+   for (i = 0; i < ARRAY_SIZE(proto); ++i) {
+   if (!((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
+ (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00)))
+   break;
+
+   nor->erase_proto = proto[i];
+   nor->read_proto = proto[i];
+   nor->write_proto = proto[i];
+   nor->reg_proto = proto[i];
+   tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID,
+   id, SPI_NOR_MAX_ID_LEN);
+   if (tmp < 0) {
+   dev_dbg(nor->dev,
+   " error %d reading JEDEC ID (MULTI IO)\n", tmp);
+   return ERR_PTR(tmp);
+   }
+   }
+
for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
info = &spi_nor_ids[tmp];
if (info->id_len) {
@@ -1013,6 +1033,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
enum read_mode mode)
if (ret)
return ret;
 
+   /* Reset SPI protocol for all commands */
+   nor->erase_proto = SPI_PROTO_1_1_1;
+   nor->read_proto = SPI_PROTO_1_1_1;
+   nor->write_proto = SPI_PROTO_1_1_1;
+   nor->reg_proto = SPI_PROTO_1_1_1;
+
if (name)
info = spi_nor_match_id(name);
/* Try to auto-detect if chip name wasn't specified or not found */
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index e5409524bb0a..66a5f144728a 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -57,8 +57,9 @@
 #define SPINOR_OP_BRWR 0x17/* Bank register write */
 
 /* Used for Micron flashes only. */
-#define SPINOR_OP_RD_EVCR  0x65/* Read EVCR register */
-#define SPINOR_OP_WD_EVCR  0x61/* Write EVCR register */
+#define SPINOR_OP_MIO_RDID 0xaf/* Multiple I/O Read JEDEC ID */
+#define SPINOR_OP_RD_EVCR  0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR  0x61/* Write EVCR register */
 
 /* Status Register bits. */
 #define SR_WIP 1   /* Write in progress */
@@ -87,6 +88,16 @@ enum read_mode {
SPI_NOR_QUAD,
 };
 
+enum spi_protocol {
+   SPI_PROTO_1_1_1,/* SPI */
+   SPI_PROTO_1_1_2,/* Dual Output */
+   SPI_PROTO_1_1_4,/* Quad Output */
+   SPI_PROTO_1_2_2,/* Dual IO */
+   SPI_PROTO_1_4_4,/* Quad IO */
+   SPI_PROTO_2_2_2,/* Dual Command */
+   SPI_PROTO_4_4_4,/* Quad Command */
+};
+
 /**
  * struct spi_nor_xfer_cfg - Structure for defining a Serial Flash transfer
  * @wren:  command for "Write Enable", or 0x00 for not required
@@ -142,6 +153,10 @@ enum spi_nor_option_flags {
  * @sst_write_second:  used by the SST write operation
  * @flags: flag options for the current SPI-NOR (SNOR_F_*)
  * @cfg:   used by the read_xfer/write_xfer
+ * @erase_proto:   the SPI protocol used by erase operations
+ * @read_proto:the SPI protocol used by read operations
+ * @write_proto:   the SPI protocol used by write operations
+ * @reg_proto  the SPI protocol used by read_reg/write_reg operations
  * @cmd_buf:   used by the write_reg
  * @prepare:   [OPTIONAL] do some preparations for the
  * read/write/erase/lock/unlock operations
@@ -169,6 +184,10 @@ struc

[PATCH linux-next v6 2/8] mtd: spi-nor: remove unused read_xfer/write_xfer hooks

[Cyrille Pitchen]

struct spi_nor_xfer_cfg and read_xfer/write_xfer hooks were never used by
any driver. Do some cleanup by removing them.

Signed-off-by: Cyrille Pitchen 
---
 include/linux/mtd/spi-nor.h | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 66a5f144728a..08e405cbb6af 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -98,33 +98,6 @@ enum spi_protocol {
SPI_PROTO_4_4_4,/* Quad Command */
 };
 
-/**
- * struct spi_nor_xfer_cfg - Structure for defining a Serial Flash transfer
- * @wren:  command for "Write Enable", or 0x00 for not required
- * @cmd:   command for operation
- * @cmd_pins:  number of pins to send @cmd (1, 2, 4)
- * @addr:  address for operation
- * @addr_pins: number of pins to send @addr (1, 2, 4)
- * @addr_width:number of address bytes
- * (3,4, or 0 for address not required)
- * @mode:  mode data
- * @mode_pins: number of pins to send @mode (1, 2, 4)
- * @mode_cycles:   number of mode cycles (0 for mode not required)
- * @dummy_cycles:  number of dummy cycles (0 for dummy not required)
- */
-struct spi_nor_xfer_cfg {
-   u8  wren;
-   u8  cmd;
-   u8  cmd_pins;
-   u32 addr;
-   u8  addr_pins;
-   u8  addr_width;
-   u8  mode;
-   u8  mode_pins;
-   u8  mode_cycles;
-   u8  dummy_cycles;
-};
-
 #define SPI_NOR_MAX_CMD_SIZE   8
 enum spi_nor_ops {
SPI_NOR_OPS_READ = 0,
@@ -152,7 +125,6 @@ enum spi_nor_option_flags {
  * @flash_read:the mode of the read
  * @sst_write_second:  used by the SST write operation
  * @flags: flag options for the current SPI-NOR (SNOR_F_*)
- * @cfg:   used by the read_xfer/write_xfer
  * @erase_proto:   the SPI protocol used by erase operations
  * @read_proto:the SPI protocol used by read operations
  * @write_proto:   the SPI protocol used by write operations
@@ -162,8 +134,6 @@ enum spi_nor_option_flags {
  * read/write/erase/lock/unlock operations
  * @unprepare: [OPTIONAL] do some post work after the
  * read/write/erase/lock/unlock operations
- * @read_xfer: [OPTIONAL] the read fundamental primitive
- * @write_xfer:[OPTIONAL] the writefundamental primitive
  * @read_reg:  [DRIVER-SPECIFIC] read out the register
  * @write_reg: [DRIVER-SPECIFIC] write data to the register
  * @read:  [DRIVER-SPECIFIC] read data from the SPI NOR
@@ -191,15 +161,10 @@ struct spi_nor {
enum read_mode  flash_read;
boolsst_write_second;
u32 flags;
-   struct spi_nor_xfer_cfg cfg;
u8  cmd_buf[SPI_NOR_MAX_CMD_SIZE];
 
int (*prepare)(struct spi_nor *nor, enum spi_nor_ops ops);
void (*unprepare)(struct spi_nor *nor, enum spi_nor_ops ops);
-   int (*read_xfer)(struct spi_nor *nor, struct spi_nor_xfer_cfg *cfg,
-u8 *buf, size_t len);
-   int (*write_xfer)(struct spi_nor *nor, struct spi_nor_xfer_cfg *cfg,
- u8 *buf, size_t len);
int (*read_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len);
int (*write_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len,
int write_enable);
-- 
1.8.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

[PATCH linux-next v6 0/8] add driver for Atmel QSPI controller

[Cyrille Pitchen]

ChangeLog

v6:
- add new patch which tries to read the JEDEC ID with different SPI protocols
  and different commands: 0x9f (SPI-1-1-1), 0xaf (SPI-4-4-4) and finally
  0xaf (SPI-2-2-2).
- remove the set_protocol() hook from struct spi_nor and add 4 new members
  instead of type enum spi_protocol:
  read_proto, write_proto, erase_proto, reg_proto.
  The relevant protocol value should be checked by the driver specific read(),
  write(), erase(), read_reg() and write_reg() hook implementations.
- remove unused hooks: write_xfer() and read_xfer().
- tune the op code for read, write and erase commands depending on the memory
  manufacturer.
- remove some previously added "Acked-by" since the protocol switch strategy
  has been changed but not discussed yet.

v5:
- remove unused inline functions qspi_read[bw]() and qspi_write[bw](),
  keep only qspi_readl() and qspi_writel().
- use reinit_completion() instead of init_completion() during run time,
  call init_completion() once for all in the probe().
- add a dev_warn() when trying to tune the number of dummy cycles for
  spi-nor of a not supported manufacturer then fall back to the default
  framework value.
- reword some comments.
- add "Acked-by: Marek Vasut " for patches 1 and 4.
- add "Acked-by: Bean Huo " for patch 1.

v4:
- add "OF && HAS_DMA" dependency in Kconfig for Atmel Quad SPI driver.
- return -ENOMEM instead of the return code of dma_mapping_error() as this
  function returns a boolean on ARM achitecture.
- add "Acked-by: Nicolas Ferre " for Atmel Quad
  SPI driver and its DT binding documentation.

v3:
- reword the comment which explains that spi_nor_set_protocol() is used by
  the spi-nor framework to notify lower layers, especially the (Q)SPI
  controller about a protocol change.
- change the definitions of register/bitfield macros in the Atmel QSPI
  controller driver: get rid of concatenation operator and use BIT and
  GENMASK macros when possible.
- use #define[SPACE] instead of #define[TAB]

v2:
- remove the patches to set the "latency code" of Spansion QSPI memories
  (support of Spansion memories may be submitted in later series).
- rename "qspi" node into "spi" in the DT example to fit ePAPR standard.
- remove the useless "qspi0" label from the DT node example.
- remove the leading 0 from the size of the second memory region to make
  it consistent with the size of the first memory region.
- indent the DT bindings documentation to make it more readable.
- remove the useless ".bus  = &platform_bus_type," line from the
  platform driver definition.

v1:

This series of patches add support for the new Atmel QSPI controller
embedded inside sama5d2x SoCs.

These patches were first developped for linux-3.18-at91 and tested on a
sama5d27 Xplained ultra board, which embeds a Micron n25q128a13 QSPI NOR
flash memory. Then the series was adapted for mainline.

Cyrille Pitchen (8):
  mtd: spi-nor: read JEDEC ID with multiple I/O protocols
  mtd: spi-nor: remove unused read_xfer/write_xfer hooks
  mtd: spi-nor: update the SPI protocol when enabling manufacturer Quad
mode
  mtd: spi-nor: use optimized commands for read/write/erase operations
  Documentation: mtd: add a DT property to set the number of dummy
cycles
  mtd: spi-nor: allow to tune the number of dummy cycles
  Documentation: atmel-quadspi: add binding file for Atmel QSPI driver
  mtd: atmel-quadspi: add driver for Atmel QSPI controller

 .../devicetree/bindings/mtd/atmel-quadspi.txt  |  29 +
 .../devicetree/bindings/mtd/jedec,spi-nor.txt  |   6 +
 drivers/mtd/spi-nor/Kconfig|   7 +
 drivers/mtd/spi-nor/Makefile   |   1 +
 drivers/mtd/spi-nor/atmel-quadspi.c| 889 +
 drivers/mtd/spi-nor/spi-nor.c  | 356 +++--
 include/linux/mtd/spi-nor.h|  63 +-
 7 files changed, 1269 insertions(+), 82 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
 create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c

-- 
1.8.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 1/3] sysfs: Fix is_visible() support for binary attributes

[Emilio López]

On 09/09/15 01:12, Guenter Roeck wrote:

On 09/08/2015 08:58 PM, Greg KH wrote:

On Tue, Sep 08, 2015 at 06:10:16PM -0700, Guenter Roeck wrote:

Hi Emilio,

On 09/08/2015 05:51 PM, Emilio López wrote:

Hi Greg & Guenter,


[ ... ]


Unless I am missing something, this is not explained anywhere,
but it is
not entirely trivial to understand. I think it should be documented.


I agree. I couldn't find any mention of what this int was supposed
to be by looking at Documentation/ (is_visible is not even mentioned
:/) or include/linux/sysfs.h. Once we settle on something I'll
document it before sending a v2.


In the include file ? No strong preference, though.


By the way, I wrote a quick coccinelle script to match is_visible()
users which reference the index (included below), and it found
references to drivers which do not seem to use any binary
attributes, so I believe changing the index meaning shouldn't be an
issue.


Good.


I agree, make i the number of the bin attribute and that should solve
this issue.


No, that would conflict with the "normal" use of is_visible for
non-binary
attributes, and make the index all but useless, since the
is_visible function
would have to search through all the attributes anyway to figure
out which one
is being checked.


Yeah, using the same indexes would be somewhat pointless, although
not many seem to be using it anyway (only 14 files matched). Others
seem to be comparing the attr* instead. An alternative would be to
use negative indexes for binary attributes and positive indexes for
normal attributes.


... and I probably wrote or reviewed a significant percentage of
those ;-).

Using negative numbers for binary attributes is an interesting idea.
Kind of unusual, though. Greg, any thoughts on that ?


Ick, no, that's a mess, maybe we just could drop the index alltogether?



No, please don't. Having to manually compare dozens of index pointers
would be
even more of a mess.


So, what about keeping it the way it is in the patch, and documenting it 
thoroughly? Otherwise, we could introduce another "is_bin_visible" 
function to do this same thing but just on binary attributes, but I'd 
rather not add a new function pointer if possible.


Cheers,
Emilio
--
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/3] mtd: mtk-nor: mtk serial flash controller driver

[Lothar Waßmann]

Hi,

> > +   writeb(len, mt8173_nor->base + MTK_NOR_CNT_REG);
> > +   return mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PRG_CMD);
> > +}
> > +
> > +static int mt8173_nor_get_para(struct mt8173_nor *mt8173_nor, u8 *buf, int 
> > len)
> > +{
> > +   if (len > 1) {
> > +   /* read JEDEC ID need 4 bytes commands */
> > +   mt8173_nor_set_cmd(mt8173_nor, 0, 32, SPINOR_OP_RDID);
> > +   buf[2] = readb(mt8173_nor->base + MTK_NOR_SHREG0_REG);
> > +   buf[1] = readb(mt8173_nor->base + MTK_NOR_SHREG1_REG);
> > +   buf[0] = readb(mt8173_nor->base + MTK_NOR_SHREG2_REG);
> > +   } else {
> > +   if (mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_RDSR_CMD)) {
> > +   dev_err(mt8173_nor->dev, "read status failed!\n");
> > +   return -EINVAL;
> > +   }
> > +   *buf = readb(mt8173_nor->base + MTK_NOR_RDSR_REG);
> > +   }
> > +   return 0;
> > +}
> > +
> > +/* cmd1 sent to nor flash, cmd2 write to nor controller */
> > +static int mt8173_nor_set_para(struct mt8173_nor *mt8173_nor, int cmd1,
> > +  int cmd2)
> > +{
> > +   if (mt8173_nor_set_cmd(mt8173_nor, 0, 8, SPINOR_OP_WREN)) {
> > +   dev_err(mt8173_nor->dev,
> > +   "write enable failed in write protect!\n");
> > +   return -EINVAL;
> > +   }
> > +   writeb(cmd1, mt8173_nor->base + MTK_NOR_PRGDATA5_REG);
> > +   writeb(8, mt8173_nor->base + MTK_NOR_CNT_REG);
> > +   if (mt8173_nor_execute_cmd(mt8173_nor, cmd2)) {
> > +   dev_err(mt8173_nor->dev, "execute cmd failed!\n");
> 
> mt8173_nor_execute_cmd() will already have printed an error message.
> 
And mt8173_nor_execute_cmd()/mt8173_nor_set_cmd() returned an error
code which should be promoted to the caller rather than
inventing a new one.
The same for other instances of this code fragment.


Lothar Waßmann
--
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] clk: shmobile: div6: Make clock-output-names optional

[Geert Uytterhoeven]

Renesas DIV6 clocks provide a single clock output.  Hence make the
"clock-output-names" DT property optional instead of mandatory. In case
the DT property is omitted the DT node name will be used.

Rename the variable "name" to "clk_name" to make the code more similar
with fixed-factor-clock.c, and to avoid a conflict with a nested local
variable while we're at it.

Signed-off-by: Geert Uytterhoeven 
---
 .../devicetree/bindings/clock/renesas,cpg-div6-clocks.txt   |  4 
 drivers/clk/shmobile/clk-div6.c | 13 +++--
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt 
b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
index e1bdf14ac2dfdab2..361315db3d8cfb58 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
@@ -21,6 +21,10 @@ Required Properties:
 clocks must be specified.  For clocks with multiple parents, invalid
 settings must be specified as "<0>".
   - #clock-cells: Must be 0
+
+
+Optional Properties:
+
   - clock-output-names: The name of the clock as a free-form string
 
 
diff --git a/drivers/clk/shmobile/clk-div6.c b/drivers/clk/shmobile/clk-div6.c
index b4c8d6746f68a7b8..57016ff9c585fc6e 100644
--- a/drivers/clk/shmobile/clk-div6.c
+++ b/drivers/clk/shmobile/clk-div6.c
@@ -178,10 +178,9 @@ static void __init cpg_div6_clock_init(struct device_node 
*np)
const char **parent_names;
struct clk_init_data init;
struct div6_clock *clock;
-   const char *name;
+   const char *clk_name = np->name;
struct clk *clk;
unsigned int i;
-   int ret;
 
clock = kzalloc(sizeof(*clock), GFP_KERNEL);
if (!clock)
@@ -215,13 +214,7 @@ static void __init cpg_div6_clock_init(struct device_node 
*np)
clock->div = (clk_readl(clock->reg) & CPG_DIV6_DIV_MASK) + 1;
 
/* Parse the DT properties. */
-   ret = of_property_read_string(np, "clock-output-names", &name);
-   if (ret < 0) {
-   pr_err("%s: failed to get %s DIV6 clock output name\n",
-  __func__, np->name);
-   goto error;
-   }
-
+   of_property_read_string(np, "clock-output-names", &clk_name);
 
for (i = 0, valid_parents = 0; i < num_parents; i++) {
const char *name = of_clk_get_parent_name(np, i);
@@ -255,7 +248,7 @@ static void __init cpg_div6_clock_init(struct device_node 
*np)
}
 
/* Register the clock. */
-   init.name = name;
+   init.name = clk_name;
init.ops = &cpg_div6_clock_ops;
init.flags = CLK_IS_BASIC;
init.parent_names = parent_names;
-- 
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 v3 1/9] ARM: dts: imx6dql-nitrogen6x: add touchscreen support

[Gary Bisson]

This patch adds the different touchscreens that can be connected using
the displays available for this board.
http://boundarydevices.com/product-category/displays/

Signed-off-by: Gary Bisson 
---
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi 
b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 340bc8e..5466368 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -247,6 +247,21 @@
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3>;
status = "okay";
+
+   touchscreen@04 {
+   compatible = "eeti,egalax_ts";
+   reg = <0x04>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+   wakeup-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+   };
+
+   touchscreen@38 {
+   compatible = "edt,edt-ft5x06";
+   reg = <0x38>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
+   };
 };
 
 &iomuxc {
@@ -258,6 +273,7 @@
fsl,pins = <
/* SGTL5000 sys_mclk */
MX6QDL_PAD_GPIO_0__CCM_CLKO10x030b0
+   MX6QDL_PAD_GPIO_9__GPIO1_IO09   0x1b0b0
>;
};
 
-- 
2.5.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 v3 6/9] ARM: dts: imx6q-nitrogen6x: change manufacturer to Boundary Devices

[Gary Bisson]

Signed-off-by: Gary Bisson 
---
 arch/arm/boot/dts/imx6q-nitrogen6x.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6q-nitrogen6x.dts 
b/arch/arm/boot/dts/imx6q-nitrogen6x.dts
index 8088cfc..d168633 100644
--- a/arch/arm/boot/dts/imx6q-nitrogen6x.dts
+++ b/arch/arm/boot/dts/imx6q-nitrogen6x.dts
@@ -46,8 +46,8 @@
 #include "imx6qdl-nitrogen6x.dtsi"
 
 / {
-   model = "Freescale i.MX6 Quad Nitrogen6x Board";
-   compatible = "fsl,imx6q-nitrogen6x", "fsl,imx6q";
+   model = "Boundary Devices i.MX6 Quad Nitrogen6x Board";
+   compatible = "boundary,imx6q-nitrogen6x", "fsl,imx6q";
 };
 
 &sata {
-- 
2.5.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 v3 9/9] ARM: dts: imx: add Boundary Devices Nitrogen6_Lite board

[Gary Bisson]

Based on an i.MX6 Solo with 512MB DDR3.

http://boundarydevices.com/product/nitrogen6_lite/

Signed-off-by: Gary Bisson 
---
 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/imx6dl-nit6xlite.dts   |  49 +++
 arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi | 630 +++
 3 files changed, 680 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6dl-nit6xlite.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cc29515..b4afb42 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -284,6 +284,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-gw551x.dtb \
imx6dl-gw552x.dtb \
imx6dl-hummingboard.dtb \
+   imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
imx6dl-phytec-pbab01.dtb \
imx6dl-rex-basic.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-nit6xlite.dts 
b/arch/arm/boot/dts/imx6dl-nit6xlite.dts
new file mode 100644
index 000..e0161e4
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-nit6xlite.dts
@@ -0,0 +1,49 @@
+/*
+ * Copyright 2015 Boundary Devices, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-nit6xlite.dtsi"
+
+/ {
+   model = "Boundary Devices i.MX6 Solo Nitrogen6_Lite Board";
+   compatible = "boundary,imx6dl-nit6xlite", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi 
b/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
new file mode 100644
index 000..24d7d3f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-nit6xlite.dtsi
@@ -0,0 +1,630 @@
+/*
+ * Copyright 2015 Boundary Devices, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING

[PATCH v3 7/9] ARM: dts: imx6dl-nitrogen6x: change manufacturer to Boundary Devices

[Gary Bisson]

Signed-off-by: Gary Bisson 
---
 arch/arm/boot/dts/imx6dl-nitrogen6x.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-nitrogen6x.dts 
b/arch/arm/boot/dts/imx6dl-nitrogen6x.dts
index 54bc4cd..8398f97 100644
--- a/arch/arm/boot/dts/imx6dl-nitrogen6x.dts
+++ b/arch/arm/boot/dts/imx6dl-nitrogen6x.dts
@@ -46,6 +46,6 @@
 #include "imx6qdl-nitrogen6x.dtsi"
 
 / {
-   model = "Freescale i.MX6 DualLite Nitrogen6x Board";
-   compatible = "fsl,imx6dl-nitrogen6x", "fsl,imx6dl";
+   model = "Boundary Devices i.MX6 DualLite Nitrogen6x Board";
+   compatible = "boundary,imx6dl-nitrogen6x", "fsl,imx6dl";
 };
-- 
2.5.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 v3 5/9] of: Add Boundary Devices Inc. vendor prefix

[Gary Bisson]

This patch adds the vendor prefix for Boundary Devices Inc. which is a
supplier of ARM-based single board computers and System-on-Modules for
the general embedded market.

Website: http://boundarydevices.com/

Signed-off-by: Gary Bisson 
---
 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 ac5f0c3..4c67e2a 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -34,6 +34,7 @@ avago Avago Technologies
 avic   Shanghai AVIC Optoelectronics Co., Ltd.
 axis   Axis Communications AB
 bosch  Bosch Sensortec GmbH
+boundary   Boundary Devices Inc.
 brcm   Broadcom Corporation
 buffaloBuffalo, Inc.
 calxedaCalxeda
-- 
2.5.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 v3 4/9] ARM: dts: imx6qdl-sabrelite: relicense under GPLv2/X11

[Gary Bisson]

Signed-off-by: Gary Bisson 
---
 arch/arm/boot/dts/imx6dl-sabrelite.dts   | 40 
 arch/arm/boot/dts/imx6q-sabrelite.dts| 40 
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 40 
 3 files changed, 105 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts 
b/arch/arm/boot/dts/imx6dl-sabrelite.dts
index 2de0447..0f06ca5 100644
--- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
@@ -2,12 +2,42 @@
  * Copyright 2011 Freescale Semiconductor, Inc.
  * Copyright 2011 Linaro Ltd.
  *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
  *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 /dts-v1/;
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts 
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 96e4688..66d10d8 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -2,12 +2,42 @@
  * Copyright 2011 Freescale Semiconductor, Inc.
  * Copyright 2011 Linaro Ltd.
  *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
  *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * 

[PATCH v3 2/9] ARM: dts: imx6qdl-nitrogen6x: add wifi wl1271 support

[Gary Bisson]

Signed-off-by: Gary Bisson 
---
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 55 +++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi 
b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 5466368..2ce7cb4 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -65,6 +65,19 @@
pinctrl-0 = <&pinctrl_can_xcvr>;
gpio = <&gpio1 2 GPIO_ACTIVE_LOW>;
};
+
+   reg_wlan_vmmc: regulator@4 {
+   compatible = "regulator-fixed";
+   reg = <4>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_wlan_vmmc>;
+   regulator-name = "reg_wlan_vmmc";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   gpio = <&gpio6 15 GPIO_ACTIVE_HIGH>;
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
};
 
gpio-keys {
@@ -411,6 +424,18 @@
>;
};
 
+   pinctrl_usdhc2: usdhc2grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17071
+   MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10071
+   MX6QDL_PAD_SD2_DAT0__SD2_DATA0  0x17071
+   MX6QDL_PAD_SD2_DAT1__SD2_DATA1  0x17071
+   MX6QDL_PAD_SD2_DAT2__SD2_DATA2  0x17071
+   MX6QDL_PAD_SD2_DAT3__SD2_DATA3  0x17071
+   MX6QDL_PAD_NANDF_CS2__GPIO6_IO150x000b0
+   >;
+   };
+
pinctrl_usdhc3: usdhc3grp {
fsl,pins = <
MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
@@ -434,6 +459,15 @@
MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x1b0b0 /* CD */
>;
};
+
+   pinctrl_wlan_vmmc: wlan_vmmcgrp {
+   fsl,pins = <
+   MX6QDL_PAD_NANDF_CS0__GPIO6_IO110x100b0
+   MX6QDL_PAD_NANDF_CS2__GPIO6_IO150x000b0
+   MX6QDL_PAD_NANDF_CS3__GPIO6_IO160x000b0
+   MX6QDL_PAD_SD1_CLK__OSC32K_32K_OUT  0x000b0
+   >;
+   };
};
 };
 
@@ -505,6 +539,27 @@
status = "okay";
 };
 
+&usdhc2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_usdhc2>;
+   bus-width = <4>;
+   non-removable;
+   vmmc-supply = <®_wlan_vmmc>;
+   cap-power-off-card;
+   keep-power-in-suspend;
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@2 {
+   compatible = "ti,wl1271";
+   reg = <2>;
+   interrupt-parent = <&gpio6>;
+   interrupts = <14 IRQ_TYPE_LEVEL_HIGH>;
+   ref-clock-frequency = <3840>;
+   };
+};
+
 &usdhc3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc3>;
-- 
2.5.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 v3 0/9] ARM: dts: update Boundary Devices boards support

[Gary Bisson]

Hi all,

This series is a follow-up to the previous series that added LCD display
support.
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/364425.html

This one aims at adding touchscreen and WiFi support for Nitrogen6x as well as
adding two boards: Nitrogen6_Max and Nit6xlite.

It also takes care of updating the licenses to be GPLv2/X11.

The series has been tested against linux-next tag next-20150909.

Note that imx_v6_v7_defconfig has been used with the following additions:
CONFIG_TOUCHSCREEN_EDT_FT5X06=y
CONFIG_I2C_MUX_GPIO=y
CONFIG_RTC_DRV_M41T80=y

Modifications:
v2->v3:
- Rename nodes to general class of device as suggested by Philipp and Russell.
- Remove useless wakeup-gpio field for edt,ft5x06 touchscreen
- Add missing muxing for interrupt GPIO
- Rebased on next-20150909
v1->v2:
- Add Boundary Devices Inc. to vendor prefixes
- Relicense devices trees to GPLv2/X11 as suggested by Fabio for:
  - Nitrogen6x
  - SabreLite
  - Nit6xLite
  - Nitrogen6_MAX
- Change manufacturer to Boundary Devices as suggested by Fabio for:
  - Nitrogen6x
  - Nit6xLite
  - Nitrogen6_MAX
- Fixed missing macros for gpio/irq values as suggested by Philipp.
- Rebased on next-20150908

Regards,
Gary

Gary Bisson (9):
  ARM: dts: imx6dql-nitrogen6x: add touchscreen support
  ARM: dts: imx6qdl-nitrogen6x: add wifi wl1271 support
  ARM: dts: imx6qdl-nitrogen6x: relicense under GPLv2/X11
  ARM: dts: imx6qdl-sabrelite: relicense under GPLv2/X11
  of: Add Boundary Devices Inc. vendor prefix
  ARM: dts: imx6q-nitrogen6x: change manufacturer to Boundary Devices
  ARM: dts: imx6dl-nitrogen6x: change manufacturer to Boundary Devices
  ARM: dts: imx: add Boundary Devices Nitrogen6_Max board
  ARM: dts: imx: add Boundary Devices Nitrogen6_Lite board

 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/imx6dl-nit6xlite.dts |  49 ++
 arch/arm/boot/dts/imx6dl-nitrogen6x.dts|  44 +-
 arch/arm/boot/dts/imx6dl-sabrelite.dts |  40 +-
 arch/arm/boot/dts/imx6q-nitrogen6_max.dts  |  53 ++
 arch/arm/boot/dts/imx6q-nitrogen6x.dts |  44 +-
 arch/arm/boot/dts/imx6q-sabrelite.dts  |  40 +-
 ...6qdl-nitrogen6x.dtsi => imx6qdl-nit6xlite.dtsi} | 396 ++
 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi   | 873 +
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi  | 111 ++-
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi   |  40 +-
 12 files changed, 1523 insertions(+), 170 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6dl-nit6xlite.dts
 create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_max.dts
 copy arch/arm/boot/dts/{imx6qdl-nitrogen6x.dtsi => imx6qdl-nit6xlite.dtsi} 
(50%)
 create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi

-- 
2.5.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 v3 8/9] ARM: dts: imx: add Boundary Devices Nitrogen6_Max board

[Gary Bisson]

Based on i.MX6 Quad with 4GB of DDR3.

http://boundarydevices.com/product/nitrogen6max/

Signed-off-by: Gary Bisson 
---
 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/imx6q-nitrogen6_max.dts|  53 ++
 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 873 +++
 3 files changed, 927 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx6q-nitrogen6_max.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..cc29515 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -313,6 +313,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-gw552x.dtb \
imx6q-hummingboard.dtb \
imx6q-nitrogen6x.dtb \
+   imx6q-nitrogen6_max.dtb \
imx6q-phytec-pbab01.dtb \
imx6q-rex-pro.dtb \
imx6q-sabreauto.dtb \
diff --git a/arch/arm/boot/dts/imx6q-nitrogen6_max.dts 
b/arch/arm/boot/dts/imx6q-nitrogen6_max.dts
new file mode 100644
index 000..d417457
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-nitrogen6_max.dts
@@ -0,0 +1,53 @@
+/*
+ * Copyright 2015 Boundary Devices, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-nitrogen6_max.dtsi"
+
+/ {
+   model = "Boundary Devices i.MX6 Quad Nitrogen6_MAX Board";
+   compatible = "boundary,imx6q-nitrogen6_max", "fsl,imx6q";
+};
+
+&sata {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi 
b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
new file mode 100644
index 000..a35d54f
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -0,0 +1,873 @@
+/*
+ * Copyright 2015 Boundary Devices, Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROV

[PATCH v3 3/9] ARM: dts: imx6qdl-nitrogen6x: relicense under GPLv2/X11

[Gary Bisson]

Signed-off-by: Gary Bisson 
---
 arch/arm/boot/dts/imx6dl-nitrogen6x.dts   | 40 +++
 arch/arm/boot/dts/imx6q-nitrogen6x.dts| 40 +++
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 40 +++
 3 files changed, 105 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/imx6dl-nitrogen6x.dts 
b/arch/arm/boot/dts/imx6dl-nitrogen6x.dts
index 5f4d33c..54bc4cd 100644
--- a/arch/arm/boot/dts/imx6dl-nitrogen6x.dts
+++ b/arch/arm/boot/dts/imx6dl-nitrogen6x.dts
@@ -3,12 +3,42 @@
  * Copyright 2012 Freescale Semiconductor, Inc.
  * Copyright 2011 Linaro Ltd.
  *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
  *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
  */
 
 /dts-v1/;
diff --git a/arch/arm/boot/dts/imx6q-nitrogen6x.dts 
b/arch/arm/boot/dts/imx6q-nitrogen6x.dts
index a57866b..8088cfc 100644
--- a/arch/arm/boot/dts/imx6q-nitrogen6x.dts
+++ b/arch/arm/boot/dts/imx6q-nitrogen6x.dts
@@ -3,12 +3,42 @@
  * Copyright 2012 Freescale Semiconductor, Inc.
  * Copyright 2011 Linaro Ltd.
  *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
  *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE 

Re: [PATCH-v2 2/7] mmc: sdhci-pxav3: binding: Add pxa1928 compatible support

[Vaibhav Hiremath]

On Wednesday 09 September 2015 05:19 AM, Rob Herring wrote:

On 09/07/2015 06:18 AM, Vaibhav Hiremath wrote:

With support for pxa1928 family of devices , this patch
updates the binding document with compatible property
of "marvell,pxav3-1928-sdhci".

Signed-off-by: Vaibhav Hiremath 
---
  Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt 
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 3d1b449..29edcf5 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -5,7 +5,7 @@ and the properties used by the sdhci-pxav2 and sdhci-pxav3 
drivers.

  Required properties:
  - compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or
-  "marvell,armada-380-sdhci".
+  "marvell,armada-380-sdhci" or "marvell,pxav3-1928-sdhci".


v3 is implied by pxa1928. So I'd just do "marvell,pxa1928-sdhci" to
better match the chip name.



Ok, No issues.

I followed the existing "armada-380-sdhci" naming style.
Will correct it in next version.


Thanks,
Vaibhav
--
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] ahci: qoriq: fixed using uninitialized variable warnings

[Hans de Goede]

Hi,

On 09-09-15 11:16, yuantian.t...@freescale.com wrote:

From: Tang Yuantian 

kbuild test robot reports the warnings:
drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':

include/asm-generic/io.h:163:2: warning: 'px_is' may be used
uninitialized in this function [-Wuninitialized]

drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here

include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
uninitialized in this function [-Wuninitialized]

drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here

This patch fixed it by assigning 0 to px_is and px_cmd variables.
This patch also remove line 'struct ccsr_ahci *reg_base' which is
not referred by any other codes and thus a dead one.

Signed-off-by: Tang Yuantian 


LGTM: Acked-by: Hans de Goede 

Regards,

Hans



---
  drivers/ata/ahci_qoriq.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index e5e4988..f790852 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -49,7 +49,6 @@ enum ahci_qoriq_type {
  };

  struct ahci_qoriq_priv {
-   struct ccsr_ahci *reg_base;
enum ahci_qoriq_type type;
void __iomem *ecc_addr;
  };
@@ -67,7 +66,7 @@ static int ahci_qoriq_hardreset(struct ata_link *link, 
unsigned int *class,
  {
const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
void __iomem *port_mmio = ahci_port_base(link->ap);
-   u32 px_cmd, px_is, px_val;
+   u32 px_cmd = 0, px_is = 0, px_val;
struct ata_port *ap = link->ap;
struct ahci_port_priv *pp = ap->private_data;
struct ahci_host_priv *hpriv = ap->host->private_data;


--
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] fbdev: ssd1307fb: add ssd1309 support

[Lad, Prabhakar]

On Tue, Sep 8, 2015 at 8:19 PM, Olliver Schinagl
 wrote:
> The ssd1307fb driver supports a lot of chips from the ssd130xfb series.
> This patch adds the ssd1309 chip, a 128x64 OLED driver chip. It is very
> similar to the other chips and only has some definitions added to
> support it.
>
> Signed-off-by: Olliver Schinagl 

Acked-by: Lad, Prabhakar 

Cheers,
--Prabhakar Lad
--
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/9] ARM: dts: imx6dql-nitrogen6x: add touchscreen support

[Gary Bisson]

Hi,

On Tue, Sep 8, 2015 at 4:49 PM, Philipp Zabel  wrote:
> Am Dienstag, den 08.09.2015, 16:34 +0200 schrieb Gary Bisson:
>> This patch adds the different touchscreens that can be connected using
>> the displays available for this board.
>> http://boundarydevices.com/product-category/displays/
>>
>> Signed-off-by: Gary Bisson 
>> ---
>>  arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi 
>> b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
>> index ad16dce..24b667d 100644
>> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
>> @@ -284,6 +284,22 @@
>>   pinctrl-names = "default";
>>   pinctrl-0 = <&pinctrl_i2c3>;
>>   status = "okay";
>> +
>> + egalax_ts@04 {
>
> I'd prefer to use generic names for the nodes, such as "touchscreen@04",
> and "touchscreen@38" below.

Ok will do. Plus for the two new boards, I'll try to follow Russell comment.

>> + compatible = "eeti,egalax_ts";
>> + reg = <0x04>;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
>> + wakeup-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + ft5x06_ts@38 {
>> + compatible = "edt,edt-ft5x06";
>> + reg = <0x38>;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
>> + wakeup-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
>
> This should be wake-gpios and GPIO_ACTIVE_HIGH according to the other
> users.

Actually I'm going to remove that line. First it should be wake-gpios
instead of wakeup-gpios. When I realized and changed it the driver
wouldn't work at all. Indeed looking at the source code and other
example it looks like it should be a different GPIO than the interrupt
one.

For the eGalax, the driver output a 1 and 0 to create the falling edge
that wakes the controller up and then releases the gpio as an input
for interrupts. But in the edt driver, the GPIO is kept as an output
which prevents from receiving any interrupt. Seems that the ft5x06
controllers on our display doesn't need any wake-up signal.

I'll submit a v3 very soon.

Regards,
Gary
--
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] ahci: qoriq: fixed using uninitialized variable warnings

[Yuantian.Tang]

From: Tang Yuantian 

kbuild test robot reports the warnings:
drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
>> include/asm-generic/io.h:163:2: warning: 'px_is' may be used
>> uninitialized in this function [-Wuninitialized]
drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here
>> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
>> uninitialized in this function [-Wuninitialized]
drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here

This patch fixed it by assigning 0 to px_is and px_cmd variables.
This patch also remove line 'struct ccsr_ahci *reg_base' which is
not referred by any other codes and thus a dead one.

Signed-off-by: Tang Yuantian 
---
 drivers/ata/ahci_qoriq.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index e5e4988..f790852 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -49,7 +49,6 @@ enum ahci_qoriq_type {
 };
 
 struct ahci_qoriq_priv {
-   struct ccsr_ahci *reg_base;
enum ahci_qoriq_type type;
void __iomem *ecc_addr;
 };
@@ -67,7 +66,7 @@ static int ahci_qoriq_hardreset(struct ata_link *link, 
unsigned int *class,
 {
const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
void __iomem *port_mmio = ahci_port_base(link->ap);
-   u32 px_cmd, px_is, px_val;
+   u32 px_cmd = 0, px_is = 0, px_val;
struct ata_port *ap = link->ap;
struct ahci_port_priv *pp = ap->private_data;
struct ahci_host_priv *hpriv = ap->host->private_data;
-- 
2.1.0.27.g96db324

--
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/2] ASoC: atmel-classd: add the Audio Class D Amplifier code

[Mark Brown]

On Wed, Sep 09, 2015 at 11:16:08AM +0800, Wu, Songjun wrote:
> On 9/8/2015 20:23, Mark Brown wrote:

> >If you want to have three controls you need to write code so that the
> >user can only change one of them from 0dB at once, returning an error
> >otherwise.  That was why it looked like they were three separate
> >controls.

> If user operates two or tree controls at the same time, for my
> understanding, these operations are serial actually in kernel, not parallel,
> and the last operation will be effective. I only write the function
> 'classd_get_eq_enum' to get the enumeration value, if user changes one of
> controls, the other controls will get 0dB. Is my understanding correct?

Yes, that's what's going to end up happening but it's not how controls
are expected to behave - applications will expect changing one control
to leave others unaffected so it's better to return an error rather than
change the other control.


signature.asc
Description: Digital signature

Re: [PATCH v4 0/22] On-demand device probing

[Tomeu Vizoso]

On 9 September 2015 at 03:33, Rob Herring  wrote:
> On 09/08/2015 02:30 AM, Tomeu Vizoso wrote:
>> On 7 September 2015 at 22:50, Rob Herring  wrote:
>>> On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso  
>>> wrote:
 Hello,

 I have a problem with the panel on my Tegra Chromebook taking longer
 than expected to be ready during boot (Stéphane Marchesin reported what
 is basically the same issue in [0]), and have looked into ordered
 probing as a better way of solving this than moving nodes around in the
 DT or playing with initcall levels and linking order.

 While reading the thread [1] that Alexander Holler started with his
 series to make probing order deterministic, it occurred to me that it
 should be possible to achieve the same by probing devices as they are
 referenced by other devices.

 This basically reuses the information that is already implicit in the
 probe() implementations, saving us from refactoring existing drivers or
 adding information to DTBs.

 During review of v1 of this series Linus Walleij suggested that it
 should be the device driver core to make sure that dependencies are
 ready before probing a device. I gave this idea a try [2] but Mark Brown
 pointed out to the logic duplication between the resource acquisition
 and dependency discovery code paths (though I think it's fairly minor).

 To address that code duplication I experimented with Arnd's devm_probe
 [3] concept of having drivers declare their dependencies instead of
 acquiring them during probe, and while it worked [4], I don't think we
 end up winning anything when compared to just probing devices on-demand
 from resource getters.

 One remaining objection is to the "sprinkling" of calls to
 of_device_probe() in the resource getters of each subsystem, but I think
 it's the right thing to do given that the storage of resources is
 currently subsystem-specific.

 We could avoid the above by moving resource storage into the core, but I
 don't think there's a compelling case for that.

 I have tested this on boards with Tegra, iMX.6, Exynos, Rockchip and
 OMAP SoCs, and these patches were enough to eliminate all the deferred
 probes (except one in PandaBoard because omap_dma_system doesn't have a
 firmware node as of yet).

 Have submitted a branch [5] with only these patches on top of thursday's
 linux-next to kernelci.org and I don't see any issues that could be
 caused by them. For some reason it currently has more passes than the
 version of -next it's based on!

 With this series I get the kernel to output to the panel in 0.5s,
 instead of 2.8s.

 Regards,

 Tomeu

 [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html

 [1] https://lkml.org/lkml/2014/5/12/452

 [2] https://lkml.org/lkml/2015/6/17/305

 [3] http://article.gmane.org/gmane.linux.ports.arm.kernel/277689

 [4] https://lkml.org/lkml/2015/7/21/441a

 [5] 
 https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=on-demand-probes-v6

 [6] 
 http://kernelci.org/boot/all/job/collabora/kernel/v4.2-11902-g25d80c927f8b/

 [7] http://kernelci.org/boot/all/job/next/kernel/next-20150903/

 Changes in v4:
 - Added bus.pre_probe callback so the probes of Primecell devices can be
   deferred if their device IDs cannot be yet read because of the clock
   driver not having probed when they are registered. Maybe this goes
   overboard and the matching information should be in the DT if there is
   one.
>>>
>>> Seems overboard to me or at least a separate problem.
>>
>> It's a separate problem but this was preventing the series from
>> working on a few boards.
>
> What is the failure? Not booting? Fixing not working would certainly not
> be overboard.

On the device I was testing on (qemu's vexpress-a15 machine) the
machine booted and I was able to open a ssh session, but serial was
broken among other AMBA devices:

/memory-controller@2b0a
/memory-controller@7ffd
/dma@7ffb
/smb/motherboard/iofpga@3,/sysctl@02
/smb/motherboard/iofpga@3,/aaci@04
/smb/motherboard/iofpga@3,/mmci@05
/smb/motherboard/iofpga@3,/kmi@06
/smb/motherboard/iofpga@3,/kmi@07
/smb/motherboard/iofpga@3,/uart@09
/smb/motherboard/iofpga@3,/uart@0a
/smb/motherboard/iofpga@3,/uart@0b
/smb/motherboard/iofpga@3,/uart@0c
/smb/motherboard/iofpga@3,/wdt@0f
/smb/motherboard/iofpga@3,/timer@11
/smb/motherboard/iofpga@3,/timer@12
/smb/motherboard/iofpga@3,/rtc@17
/smb/motherboard/iofpga@3,/clcd@1f

Another way of avoiding this particular problem would be not delaying
the probe of devices in the configuration bus, by