Re: [PATCH] DT: i2c: Update vendor prefix for 24c00

2016-01-06 Thread Wolfram Sang 
On Mon, Jan 04, 2016 at 08:22:33PM +0200, Andy Shevchenko wrote:
> On Sat, Jan 2, 2016 at 11:21 PM, Wolfram Sang  wrote:
> > On Sun, Dec 27, 2015 at 04:57:48PM +0200, Andy Shevchenko wrote:
> >> On Wed, Dec 23, 2015 at 9:18 PM, Akshay Bhat  
> >> wrote:
> >> > "at" is not a valid vendor prefix, correcting the same to "atmel"
> >> >
> >>
> >> I'm afraid you can't just do this change alone as it's used in some
> >> DTS. Though you may deprecated it along with update of current users.
> >
> > Well, in Linux, I2C core currently strips the vendor anyhow. This will
> > probably be changed somewhen (tm), but for now, the impact for Linux
> > should be extremly close to 0.
> 
> Okay, no objections to the original patch then.

Heh, I just go reminded that eeproms already have a seperate binding
description (Documentation/devicetree/bindings/eeprom/eeprom.txt).

I will update the eeprom bindings and remove the entries from trivial
devices.



signature.asc
Description: Digital signature

[RFC v2 4/4] ARM: shmobile: r8a7790: rework dts to use i2c demuxer

2016-01-06 Thread Wolfram Sang 
From: Wolfram Sang 

Create a seperate bus for HDMI related I2C slaves and assign it
to a i2c-gpio master. It can be switched to the i2c-rcar or
i2c-sh_mobile core at runtime.

Signed-off-by: Wolfram Sang 
---
 arch/arm/boot/dts/r8a7790-lager.dts | 141 ++--
 1 file changed, 88 insertions(+), 53 deletions(-)

diff --git a/arch/arm/boot/dts/r8a7790-lager.dts 
b/arch/arm/boot/dts/r8a7790-lager.dts
index c553abd711eeb3..d8f0ca8e094dad 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -49,6 +49,8 @@
aliases {
serial0 = 
serial1 = 
+   i2c8 = 
+   i2c9 = 
};
 
chosen {
@@ -252,6 +254,79 @@
#clock-cells = <0>;
clock-frequency = <14850>;
};
+
+
+   gpioi2c: i2c@9 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "i2c-gpio";
+   status = "disabled";
+   gpios = < 6 GPIO_ACTIVE_HIGH /* sda */
+ 5 GPIO_ACTIVE_HIGH /* scl */
+   >;
+   i2c-gpio,delay-us = <5>;
+   };
+
+   i2chdmi: i2c@8 {
+
+   compatible = "i2c-demux-pinctrl";
+   i2c-parent = <>, <>, <>;
+   i2c-bus-name = "i2c-hdmi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ak4643: sound-codec@12 {
+   compatible = "asahi-kasei,ak4643";
+
+   #sound-dai-cells = <0>;
+   reg = <0x12>;
+   };
+
+   composite-in@20 {
+   compatible = "adi,adv7180";
+   reg = <0x20>;
+   remote = <>;
+
+   port {
+   adv7180: endpoint {
+   bus-width = <8>;
+   remote-endpoint = <>;
+   };
+   };
+   };
+
+   hdmi@39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
+   };
 };
 
  {
@@ -352,6 +427,11 @@
renesas,function = "iic1";
};
 
+   i2c2_pins: i2c2 {
+   renesas,groups = "i2c2";
+   renesas,function = "i2c2";
+   };
+
iic2_pins: iic2 {
renesas,groups = "iic2";
renesas,function = "iic2";
@@ -532,63 +612,18 @@
pinctrl-names = "default";
 };
 
-  {
-   status = "okay";
-   pinctrl-0 = <_pins>;
-   pinctrl-names = "default";
+  {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "i2c-hdmi";
 
clock-frequency = <10>;
+};
 
-   ak4643: codec@12 {
-   compatible = "asahi-kasei,ak4643";
-   #sound-dai-cells = <0>;
-   reg = <0x12>;
-   };
-
-   composite-in@20 {
-   compatible = "adi,adv7180";
-   reg = <0x20>;
-   remote = <>;
-
-   port {
-   adv7180: endpoint {
-   bus-width = <8>;
-   remote-endpoint = <>;
-   };
-   };
-   };
-
-   hdmi@39 {
-   compatible = "adi,adv7511w";
-   reg = <0x39>;
-   interrupt-parent = <>;
-   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
-
-   adi,input-depth = <8>;
-   adi,input-colorspace = "rgb";
-   adi,input-clock = "1x";
-   adi,input-style = <1>;
-   adi,input-justification = "evenly";
-
-

Re: [RFC v2 2/4] dt-bindings: i2c: mux: demux-pinctrl: add bindings

2016-01-06 Thread Geert Uytterhoeven 
Hi Wolfram,

On Wed, Jan 6, 2016 at 2:51 PM, Wolfram Sang  wrote:
> These bindings allow an I2C bus to switch between multiple masters. This
> is not hot-swichting because connected I2C slaves will be
> re-instantiated. It is meant to select the best I2C core at runtime once
> the task is known. Example: Prefer i2c-gpio over another I2C core
> because of HW errata affetcing your use case.

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
> @@ -0,0 +1,155 @@

> +Here is a snipplet for a bus to be demuxed. It contains various i2c clients 
> for

snippet

> +HDMI, so the bus is named "i2c-hdmi":
> +
> +   i2chdmi: i2c@8 {

Would it make sense to call the node "i2c-bus@8"?
> +
> +   compatible = "i2c-demux-pinctrl";
> +   i2c-parent = <>, <>, <>;

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 1/4] of: make of_mutex public

2016-01-06 Thread Wolfram Sang 
From: Wolfram Sang 

If we want to use OF_DYNAMIC features outside the of framework, we need
to access this lock.

Signed-off-by: Wolfram Sang 
---
 drivers/of/of_private.h | 1 -
 include/linux/of.h  | 2 ++
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 8e882e706cd8c6..f92ec41efb5dfd 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -31,7 +31,6 @@ struct alias_prop {
char stem[0];
 };
 
-extern struct mutex of_mutex;
 extern struct list_head aliases_lookup;
 extern struct kset *of_kset;
 
diff --git a/include/linux/of.h b/include/linux/of.h
index dd10626a615fb1..acac979063f067 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -32,6 +32,8 @@
 typedef u32 phandle;
 typedef u32 ihandle;
 
+extern struct mutex of_mutex;
+
 struct property {
char*name;
int length;
-- 
2.1.4

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

[RFC v2 0/4] i2c/of: switch I2C IP cores at runtime via OF_DYNAMIC

2016-01-06 Thread Wolfram Sang 
I know this is gonna be a controversial series, but we have a usecase for this 
:)

This series allows an I2C bus to switch between multiple masters, i.e. a
n-to-1-demuxer. This is not hot-switching because connected I2C slaves will be
re-instantiated. It is meant to select the best I2C core at runtime once the
task is known. Example: Prefer i2c-gpio over another I2C core because of HW
errata affecting your current runtime configuration.

It works by using OF_DYNAMIC and en-/disabling the i2c parent as needed. See
the binding docs for more details. Because this is largely using OF_DYNAMIC, I
decided to post the whole series to the dt list.

Changes since RFC v1:

* gracefully handle if i2c adapters are not present at runtime
  (driver not loaded yet)
* added more documentation and examples
* properly put the i2c adapters after use
* respect PAGE_SIZE in sysfs_show

This has been tested on a Renesas Lager board switching between i2c-gpio and
two different IP cores (i2c-rcar and i2c-sh_mobile). The rebinding seems to be
working as expected. However, in practice, I couldn't use the HDMI i2c slaves
with another controller yet, because the rcar-du driver OOPSes when unbinding.
This seems unrelated to this series because it can also be triggered via
sysfs-unbind. soc-camera also had problems properly cleaning up on unbind, a
patch for this already has been sent. So, this series is for sure a good test
for the unbind path of drivers.

Let me know what you think.

Thanks,

   Wolfram


Wolfram Sang (4):
  of: make of_mutex public
  dt-bindings: i2c: mux: demux-pinctrl: add bindings
  i2c: mux: demux-pinctrl: add driver
  ARM: shmobile: r8a7790: rework dts to use i2c demuxer

 .../devicetree/bindings/i2c/i2c-demux-pinctrl.txt  | 155 
 arch/arm/boot/dts/r8a7790-lager.dts| 141 +++
 drivers/i2c/muxes/Kconfig  |   9 +
 drivers/i2c/muxes/Makefile |   2 +
 drivers/i2c/muxes/i2c-demux-pinctrl.c  | 276 +
 drivers/of/of_private.h|   1 -
 include/linux/of.h |   2 +
 7 files changed, 532 insertions(+), 54 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
 create mode 100644 drivers/i2c/muxes/i2c-demux-pinctrl.c

-- 
2.1.4

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

[RFC v2 3/4] i2c: mux: demux-pinctrl: add driver

2016-01-06 Thread Wolfram Sang 
From: Wolfram Sang 

This driver allows an I2C bus to switch between multiple masters. This
is not hot-swichting because connected I2C slaves will be
re-instantiated. It is meant to select the best I2C core at runtime once
the task is known. Example: Prefer i2c-gpio over another I2C core
because of HW errata affetcing your use case.

Signed-off-by: Wolfram Sang 
---
 drivers/i2c/muxes/Kconfig |   9 ++
 drivers/i2c/muxes/Makefile|   2 +
 drivers/i2c/muxes/i2c-demux-pinctrl.c | 276 ++
 3 files changed, 287 insertions(+)
 create mode 100644 drivers/i2c/muxes/i2c-demux-pinctrl.c

diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index f06b0e24673b87..7b5da5ff7b16f9 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -72,4 +72,13 @@ config I2C_MUX_REG
  This driver can also be built as a module.  If so, the module
  will be called i2c-mux-reg.
 
+config I2C_DEMUX_PINCTRL
+   tristate "pinctrl-based I2C demultiplexer"
+   depends on PINCTRL
+   select OF_DYNAMIC
+   help
+ If you say yes to this option, support will be included for an I2C
+ demultiplexer that uses the pinctrl subsystem. This is useful if you
+ want to change the I2C master at run-time depending on features.
+
 endmenu
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index e89799b76a9280..7c267c29b19196 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -3,6 +3,8 @@
 
 obj-$(CONFIG_I2C_ARB_GPIO_CHALLENGE)   += i2c-arb-gpio-challenge.o
 
+obj-$(CONFIG_I2C_DEMUX_PINCTRL)+= i2c-demux-pinctrl.o
+
 obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_PCA9541)  += i2c-mux-pca9541.o
 obj-$(CONFIG_I2C_MUX_PCA954x)  += i2c-mux-pca954x.o
diff --git a/drivers/i2c/muxes/i2c-demux-pinctrl.c 
b/drivers/i2c/muxes/i2c-demux-pinctrl.c
new file mode 100644
index 00..5ec2779b176432
--- /dev/null
+++ b/drivers/i2c/muxes/i2c-demux-pinctrl.c
@@ -0,0 +1,276 @@
+/*
+ * Pinctrl based I2C DeMultiplexer
+ *
+ * Copyright (C) 2015-16 by Wolfram Sang, Sang Engineering 

+ * Copyright (C) 2015-16 by Renesas Electronics Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; version 2 of the License.
+ *
+ * See the bindings doc for DTS setup.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct i2c_demux_pinctrl_chan {
+   struct device_node *parent_np;
+   struct i2c_adapter *parent_adap;
+   struct of_changeset chgset;
+};
+
+struct i2c_demux_pinctrl_priv {
+   int cur_chan;
+   int num_chan;
+   struct device *dev;
+   const char *bus_name;
+   struct i2c_adapter cur_adap;
+   struct i2c_algorithm algo;
+   struct i2c_demux_pinctrl_chan chan[];
+};
+
+static struct property status_okay = { .name = "status", .length = 3, .value = 
"ok" };
+
+static int i2c_demux_master_xfer(struct i2c_adapter *adap, struct i2c_msg 
msgs[], int num)
+{
+   struct i2c_demux_pinctrl_priv *priv = adap->algo_data;
+   struct i2c_adapter *parent = priv->chan[priv->cur_chan].parent_adap;
+
+   return __i2c_transfer(parent, msgs, num);
+}
+
+static u32 i2c_demux_functionality(struct i2c_adapter *adap)
+{
+   struct i2c_demux_pinctrl_priv *priv = adap->algo_data;
+   struct i2c_adapter *parent = priv->chan[priv->cur_chan].parent_adap;
+
+   return parent->algo->functionality(parent);
+}
+
+static int i2c_demux_activate_master(struct i2c_demux_pinctrl_priv *priv, u32 
new_chan)
+{
+   struct i2c_adapter *adap;
+   struct pinctrl *p;
+   int ret;
+
+   mutex_lock(_mutex);
+   ret = of_changeset_apply(>chan[new_chan].chgset);
+   mutex_unlock(_mutex);
+   if (ret)
+   goto err;
+
+   adap = of_find_i2c_adapter_by_node(priv->chan[new_chan].parent_np);
+   if (!adap) {
+   ret = -ENODEV;
+   goto err;
+   }
+
+   p = devm_pinctrl_get_select(adap->dev.parent, priv->bus_name);
+   if (IS_ERR(p)) {
+   ret = PTR_ERR(p);
+   goto err_with_put;
+   }
+
+   priv->chan[new_chan].parent_adap = adap;
+   priv->cur_chan = new_chan;
+
+   /* Now fill out current adapter structure. cur_chan must be up to date 
*/
+   priv->algo.master_xfer = i2c_demux_master_xfer;
+   priv->algo.functionality = i2c_demux_functionality;
+
+   snprintf(priv->cur_adap.name, sizeof(priv->cur_adap.name),
+"i2c-demux (master i2c-%d)", i2c_adapter_id(adap));
+   priv->cur_adap.owner = THIS_MODULE;
+   priv->cur_adap.algo = >algo;
+   priv->cur_adap.algo_data = priv;
+

Re: [RFC v2 3/4] i2c: mux: demux-pinctrl: add driver

2016-01-06 Thread Geert Uytterhoeven 
Hi Wolfram,

On Wed, Jan 6, 2016 at 2:51 PM, Wolfram Sang  wrote:
> From: Wolfram Sang 
>
> This driver allows an I2C bus to switch between multiple masters. This
> is not hot-swichting because connected I2C slaves will be

switching

> re-instantiated. It is meant to select the best I2C core at runtime once
> the task is known. Example: Prefer i2c-gpio over another I2C core
> because of HW errata affetcing your use case.

affecting

> --- /dev/null
> +++ b/drivers/i2c/muxes/i2c-demux-pinctrl.c
> @@ -0,0 +1,276 @@
> +/*
> + * Pinctrl based I2C DeMultiplexer
> + *
> + * Copyright (C) 2015-16 by Wolfram Sang, Sang Engineering 
> 
> + * Copyright (C) 2015-16 by Renesas Electronics Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; version 2 of the License.
> + *
> + * See the bindings doc for DTS setup.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct i2c_demux_pinctrl_chan {
> +   struct device_node *parent_np;
> +   struct i2c_adapter *parent_adap;
> +   struct of_changeset chgset;
> +};
> +
> +struct i2c_demux_pinctrl_priv {
> +   int cur_chan;
> +   int num_chan;

This is always positive, so you can make num_chan and a few loop counters
unsigned.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

2016-01-06 Thread Crt Mori 
Hi Wolfram and Peter,
I will give my opinion about the path chosen although it should be
taken lightly.

I can see that hardware guys missed the software guys again on the
development path, but since this happens more often than not, I would
say it seems OK to have support for this as long as it does not make
more complex (longer) standard i2c transfers. I would support to have
additional mutex before mux as that will make less chance that someone
forgets to lock mutex before mux and proposed solution seems valid.

Regards,
Crt

On 5 January 2016 at 19:48, Wolfram Sang  wrote:
> Peter,
>
>> PS. needs a bunch of testing, I do not have access to all the involved hw
>
> First of all, thanks for diving into this topic and the huge effort you
> apparently have put into it.
>
> It is obviously a quite intrusive series, so it needs careful review.
> TBH, I can't really tell when I have the bandwidth to do that, so I hope
> other people will step up. And yes, it needs serious testing.
>
> To all: Although I appreciate any review support, I'd think the first
> thing to be done should be a very high level review - is this series
> worth the huge update? Is the path chosen proper? Stuff like this. I'd
> appreciate Acks or Revs for that. Stuff like fixing checkpatch warnings
> and other minor stuff should come later.
>
> Thanks,
>
>Wolfram
>
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC v2 2/4] dt-bindings: i2c: mux: demux-pinctrl: add bindings

2016-01-06 Thread Wolfram Sang 
From: Wolfram Sang 

These bindings allow an I2C bus to switch between multiple masters. This
is not hot-swichting because connected I2C slaves will be
re-instantiated. It is meant to select the best I2C core at runtime once
the task is known. Example: Prefer i2c-gpio over another I2C core
because of HW errata affetcing your use case.

Signed-off-by: Wolfram Sang 
---
 .../devicetree/bindings/i2c/i2c-demux-pinctrl.txt  | 155 +
 1 file changed, 155 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt 
b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
new file mode 100644
index 00..de571be68f4754
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
@@ -0,0 +1,155 @@
+Pinctrl-based I2C Bus DeMux
+
+This binding describes an I2C bus demultiplexer that uses pin multiplexing to
+route the I2C signals, and represents the pin multiplexing configuration using
+the pinctrl device tree bindings. This may be used to select one I2C IP core at
+runtime which may have a better feature set for a given task than another I2C
+IP core on the SoC. The most simple example is to fall back to GPIO bitbanging
+if your current runtime configuration hits an errata of the internal IP core.
+
++---+
+| SoC   |
+|   |   +-+  +-+
+|   ++  |   | dev |  | dev |
+|   |I2C IP Core1|--\   |   +-+  +-+
+|   ++   \---+  |  ||
+||Pinctrl|--|--++
+|   ++   +---+  |
+|   |I2C IP Core2|--/   |
+|   ++  |
+|   |
++---+
+
+Required properties:
+- compatible: "i2c-demux-pinctrl"
+- i2c-parent: List of phandles of I2C masters available for selection. The 
first
+ one will be used as default.
+- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
+   parents.
+
+Furthermore, I2C mux properties and child nodes. See mux.txt in this directory.
+
+Example:
+
+Here is a snipplet for a bus to be demuxed. It contains various i2c clients for
+HDMI, so the bus is named "i2c-hdmi":
+
+   i2chdmi: i2c@8 {
+
+   compatible = "i2c-demux-pinctrl";
+   i2c-parent = <>, <>, <>;
+   i2c-bus-name = "i2c-hdmi";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ak4643: sound-codec@12 {
+   compatible = "asahi-kasei,ak4643";
+
+   #sound-dai-cells = <0>;
+   reg = <0x12>;
+   };
+
+   composite-in@20 {
+   compatible = "adi,adv7180";
+   reg = <0x20>;
+   remote = <>;
+
+   port {
+   adv7180: endpoint {
+   bus-width = <8>;
+   remote-endpoint = <>;
+   };
+   };
+   };
+
+   hdmi@39 {
+   compatible = "adi,adv7511w";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+   adi,input-style = <1>;
+   adi,input-justification = "evenly";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   adv7511_in: endpoint {
+   remote-endpoint = 
<_out_lvds0>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   adv7511_out: endpoint {
+   remote-endpoint = <_con>;
+   };
+   };
+   };
+   };
+   };
+
+And for clarification, here are the snipplets for the i2c-parents:
+
+   gpioi2c: i2c@9 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "i2c-gpio";
+   status = "disabled";
+   gpios = < 6 GPIO_ACTIVE_HIGH /*

Re: [RFC v2 1/4] of: make of_mutex public

2016-01-06 Thread Geert Uytterhoeven 
Hi Wolfram,

On Wed, Jan 6, 2016 at 2:51 PM, Wolfram Sang  wrote:
> From: Wolfram Sang 
>
> If we want to use OF_DYNAMIC features outside the of framework, we need
> to access this lock.

As I2C_DEMUX_PINCTRL is tristate, you want to add an EXPORT_SYMBOL_GPL(), too.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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 00/16] intel-lpss: support non-ACPI platforms

2016-01-06 Thread Laura Abbott 

On 01/05/2016 03:59 PM, Rafael J. Wysocki wrote:

On Tuesday, January 05, 2016 09:57:35 AM Laura Abbott wrote:

On 12/06/2015 05:44 PM, Rafael J. Wysocki wrote:

On Monday, November 30, 2015 05:11:28 PM Andy Shevchenko wrote:

This series includes few logical sets that bring a support of non-ACPI
platforms for Intel Skylake.

First part is a refactoring of built-in device properties support:
- keep single value inside the structure
- provide helper macros to define built-in properties
- fall back to secondary fwnode if primary has no asked property

Second is a propagating built-in device properties in platform core.

Third one is modifications to MFD code and intel-lpss.c driver in particular
to define and pass built-in properties to the individual drivers.

And last part is a fix for I2C bug found on Lenovo Yoga hardware and a first
converted user.

Built-in device properties is an alternative to platform data. It provides a
unified API that drivers can use to cover all cases at once: DT, ACPI, and
built-in properties.

With this series applied a platform data can be considered obsolete. Moreover,
built-in device properties allow to adjust the existing configuration, for
example, in cases when ACPI values are wrong on some platforms.

The series has been tested on available hardware and doesn't break current
behaviour. But we ask people who have the affected hardware to apply the series
on your side and check with Lenovo hardware.

Changelog v2:
- fix isuues found by kbuild bot (kbuild)
- append a patch to propagate device properties in polatform code (Arnd)
- update few existing and add couple of new patches due to above
- check with kmemleak

Andy Shevchenko (9):
device property: always check for fwnode type
device property: rename helper functions
device property: refactor built-in properties support
device property: keep single value inplace
device property: improve readability of macros
device property: return -EINVAL when property isn't found in ACPI
device property: Fallback to secondary fwnode if primary misses the
  property
mfd: core: propagate device properties to sub devices drivers
mfd: intel-lpss: Pass HSUART configuration via properties

Heikki Krogerus (1):
device property: helper macros for property entry creation

Mika Westerberg (6):
device property: Take a copy of the property set
driver core: platform: Add support for built-in device properties
driver core: Do not overwrite secondary fwnode with NULL if it is set
mfd: intel-lpss: Add support for passing device properties
mfd: intel-lpss: Pass SDA hold time to I2C host controller driver
i2c: designware: Convert to use unified device property API


I'm going to queue up this series for v4.5.

If there are any problems with it or objections from anyone, please let me know.




Raising an old thread, I pulled this series into Fedora rawhide and
while it worked for Lenovo Yoga we received a report that it caused
a regression on the Dell Inspiron 7559 (see
https://bugzilla.redhat.com/show_bug.cgi?id=1275718#c27) . I haven't
asked the reporter about bisecting to see which patch broke it.
Were there any known follow up patches?


There were a few.

All of them are in my linux-next branch if you can try this one.

Alternatively, I can expose a branch with these to you to test.

Thanks,
Rafael



I picked up all the patches from the device-properties merge but the
problem still shows up. Are there others I should pick up? Hardware
details about the touchpad are at 
https://bugzilla.redhat.com/show_bug.cgi?id=1275718#c34

Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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 8/8] i2c-mux: relax locking of the top i2c adapter during i2c controlled muxing

2016-01-06 Thread Rob Herring 
On Tue, Jan 05, 2016 at 04:57:18PM +0100, Peter Rosin wrote:
> From: Peter Rosin 
> 
> With a i2c topology like the following
> 
>GPIO ---|  -- BAT1
> |  v /
>I2C  -+--+ MUX
>  |   \
>EEPROM -- BAT2

Yuck. One would think you would just use an I2C controlled mux in this 
case...
 
> there is a locking problem with the GPIO controller since it is a client
> on the same i2c bus that it muxes. Transfers to the mux clients (e.g. BAT1)
> will lock the whole i2c bus prior to attempting to switch the mux to the
> correct i2c segment. In the above case, the GPIO device is an I/O expander
> with an i2c interface, and since the GPIO subsystem knows nothing (and
> rightfully so) about the lockless needs of the i2c mux code, this results
> in a deadlock when the GPIO driver issues i2c transfers to modify the
> mux.
> 
> So, observing that while it is needed to have the i2c bus locked during the
> actual MUX update in order to avoid random garbage on the slave side, it
> is not strictly a must to have it locked over the whole sequence of a full
> select-transfer-deselect mux client operation. The mux itself needs to be
> locked, so transfers to clients behind the mux are serialized, and the mux
> needs to be stable during all i2c traffic (otherwise individual mux slave
> segments might see garbage, or worse).
> 
> Add devive tree properties (bool named i2c-controlled) to i2c-mux-gpio and
> i2c-mux-pinctrl that asserts that the the gpio/pinctrl is controlled via
> the same i2c bus that it muxes.

Can't you determine this condition by checking the mux parent and gpio 
parent are the same i2c controller?

Alternatively, can't you just always do the locking like i2c-controlled 
is set when a mux is involved? What is the harm in doing that if the 
GPIO is controlled somewhere else?

I would prefer to see a solution not requiring DT updates to fix and 
this change seems like it is working around kernel issues.

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

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

2016-01-06 Thread Antti Palosaari 

On 01/05/2016 05:57 PM, Peter Rosin wrote:

From: Peter Rosin 

Hi!

I have a pair of boards with this i2c topology:

GPIO ---|  -- BAT1
 |  v /
I2C  -+--B---+ MUX
  |   \
EEPROM -- BAT2

(B denotes the boundary between the boards)


Handling of I2C muxes that close channel automatically, after the first 
I2C stop (P) is seen?


For example channel is selected to BAT1 => there is EEPROM write => mux 
closes channel BAT1 => access to BAT1 will fail. Is it possible to lock 
whole adapter, but allow only traffic to i2c mux client?


regards
Antti



The problem with this is that the GPIO controller sits on the same i2c bus
that it MUXes. For pca954x devices this is worked around by using unlocked
transfers when updating the MUX. I have no such luck as the GPIO is a general
purpose IO expander and the MUX is just a random bidirectional MUX, unaware
of the fact that it is muxing an i2c bus, and extending unlocked transfers
into the GPIO subsystem is too ugly to even think about. But the general hw
approach is sane in my opinion, with the number of connections between the
two boards minimized. To put is plainly, I need support for it.

So, I observe that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect operation. The MUX itself needs to be locked, so
transfers to clients behind the mux are serialized, and the MUX needs to be
stable during all i2c traffic (otherwise individual mux slave segments
might see garbage).

This series accomplishes this by adding a dt property to i2c-mux-gpio and
i2c-mux-pinctrl that can be used to state that the mux is updated by means
of the muxed master bus, and that the select-transfer-deselect operations
should be locked individually. When this holds, the i2c bus *is* locked
during muxing, since the muxing happens as part of i2c transfers. This
is true even if the MUX is updated with several transfers to the GPIO (at
least as long as *all* MUX changes are using the i2s master bus). A lock
is added to the mux so that transfers through the mux are serialized.

Concerns:
- The locking is perhaps too complex?
- I worry about the priority inheritance aspect of the adapter lock. When
   the transfers behind the mux are divided into select-transfer-deselect all
   locked individually, low priority transfers get more chances to interfere
   with high priority transfers.
- When doing an i2c_transfer() in_atomic() context of with irqs_disabled(),
   there is a higher possibility that the mux is not returned to its idle
   state after a failed (-EAGAIN) transfer due to trylock.

To summarize the series, there's some i2c-mux infrastructure cleanup work
first (I think that part stands by itself as desireable regardless), the
locking changes are in the last three patches of the series, with the real
meat in 8/8.

PS. needs a bunch of testing, I do not have access to all the involved hw

Changes since v1:
- Allocate mux core and (optional) priv in a combined allocation.
- Killed dev_err messages triggered by memory allocation failure.
- Fix the device specific i2c muxes that I had overlooked.
- Rebased on top of v4.4-rc8 (was based on v4.4-rc6 previously).

Cheers,
Peter

Peter Rosin (8):
   i2c-mux: add common core data for every mux instance
   i2c-mux: move select and deselect ops to i2c_mux_core
   i2c-mux: move the slave side adapter management to i2c_mux_core
   i2c-mux: remove the mux dev pointer from the mux per channel data
   i2c-mux: pinctrl: get rid of the driver private struct device pointer
   i2c: allow adapter drivers to override the adapter locking
   i2c: muxes always lock the parent adapter
   i2c-mux: relax locking of the top i2c adapter during i2c controlled
 muxing

  .../devicetree/bindings/i2c/i2c-mux-gpio.txt   |   2 +
  .../devicetree/bindings/i2c/i2c-mux-pinctrl.txt|   4 +
  drivers/i2c/i2c-core.c |  59 ++---
  drivers/i2c/i2c-mux.c  | 272 +
  drivers/i2c/muxes/i2c-arb-gpio-challenge.c |  46 ++--
  drivers/i2c/muxes/i2c-mux-gpio.c   |  58 ++---
  drivers/i2c/muxes/i2c-mux-pca9541.c|  58 +++--
  drivers/i2c/muxes/i2c-mux-pca954x.c|  66 ++---
  drivers/i2c/muxes/i2c-mux-pinctrl.c|  89 +++
  drivers/i2c/muxes/i2c-mux-reg.c|  63 ++---
  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c |  33 +--
  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |   2 +-
  drivers/media/dvb-frontends/m88ds3103.c|  23 +-
  drivers/media/dvb-frontends/m88ds3103_priv.h   |   2 +-
  drivers/media/dvb-frontends/rtl2830.c  |  24 +-

Re: [RFC v2 3/4] i2c: mux: demux-pinctrl: add driver

2016-01-06 Thread Rob Herring 
On Wed, Jan 6, 2016 at 7:51 AM, Wolfram Sang  wrote:
> From: Wolfram Sang 
>
> This driver allows an I2C bus to switch between multiple masters. This
> is not hot-swichting because connected I2C slaves will be
> re-instantiated. It is meant to select the best I2C core at runtime once
> the task is known. Example: Prefer i2c-gpio over another I2C core
> because of HW errata affetcing your use case.
>
> Signed-off-by: Wolfram Sang 

[...]

> +static int i2c_demux_activate_master(struct i2c_demux_pinctrl_priv *priv, 
> u32 new_chan)
> +{
> +   struct i2c_adapter *adap;
> +   struct pinctrl *p;
> +   int ret;
> +
> +   mutex_lock(_mutex);
> +   ret = of_changeset_apply(>chan[new_chan].chgset);
> +   mutex_unlock(_mutex);

Looks like you need this patch[1] rather than exposing of_mutex.

Rob

[1] https://patchwork.ozlabs.org/patch/539938/
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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] i2c: designware: Do not require clock when SSCN and FFCN are provided

2016-01-06 Thread Loc Ho 
Hi All,

>> The current driver uses input clock source frequency to calculate
>> values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
>> currently have a good way to provide the frequency information.
>> Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used
>> to directly provide these values. So, the clock information should
>> no longer be required during probing.
>>
>> However, since clk can be invalid, additional checks must be done where
>> we are making use of it.
>>
>> Signed-off-by: Mika Westerberg 
>> Signed-off-by: Suravee Suthikulpanit 
>> Tested-by: Loc Ho 
>> ---
>>
>> Note: This has been tested on AMD Seattle RevB for both DT and ACPI.
>>
>> Changes from V3 (https://lkml.org/lkml/2015/12/22/596):
>> * Add i2c_dw_plat_prepare_clk() per Andy's suggestion
>> * Add tested-by Loc Ho.
>
> The changes from V3 are big enough that I'd appreciate a new Tested-by
> tag.

I had tested this via this mixes of test cases:

a. NO APD driver + this patch ==> HCNT/LCNT as expected
b. with APD driver + this patch ==> HCNT/LCNT as expected
c. with APD driver + this patch + double the frequency APD driver ==>
HCNT/LCNT as expected
d. with APD driver + this patch + double the frequency APD driver +
comment out the ACPI parameter retrieve ==> HCNT/LCNT changed as
expected

Therefore, you can add my - Tested-by: Loc Ho 

-Loc
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" 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] i2c: designware: Do not require clock when SSCN and FFCN are provided

2016-01-06 Thread Suravee Suthikulpanit 

Hi,

On 01/06/2016 06:31 PM, Loc Ho wrote:

Hi All,


The current driver uses input clock source frequency to calculate
values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
currently have a good way to provide the frequency information.
Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used
to directly provide these values. So, the clock information should
no longer be required during probing.

However, since clk can be invalid, additional checks must be done where
we are making use of it.

Signed-off-by: Mika Westerberg 
Signed-off-by: Suravee Suthikulpanit 
Tested-by: Loc Ho 
---

Note: This has been tested on AMD Seattle RevB for both DT and ACPI.

Changes from V3 (https://lkml.org/lkml/2015/12/22/596):
 * Add i2c_dw_plat_prepare_clk() per Andy's suggestion
 * Add tested-by Loc Ho.


The changes from V3 are big enough that I'd appreciate a new Tested-by
tag.


I had tested this via this mixes of test cases:

a. NO APD driver + this patch ==> HCNT/LCNT as expected
b. with APD driver + this patch ==> HCNT/LCNT as expected
c. with APD driver + this patch + double the frequency APD driver ==>
HCNT/LCNT as expected
d. with APD driver + this patch + double the frequency APD driver +
comment out the ACPI parameter retrieve ==> HCNT/LCNT changed as
expected

Therefore, you can add my - Tested-by: Loc Ho 

-Loc



Thanks Loc,

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