Thread (2 messages) 2 messages, 2 authors, 2012-10-24
DORMANTno replies

[PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver

From: Maxime Ripard <hidden>
Date: 2012-10-24 08:37:57
Also in: linux-i2c

Hi Peter,

Le 23/10/2012 21:51, Peter Korsgaard a ?crit :
quoted
quoted
quoted
quoted
quoted
"MR" == Maxime Ripard [off-list ref] writes:
Hi Maxime,

I'm fine with the idea, but a few comments:


MR> Allow the i2c-mux-gpio to be used by a device tree enabled device. The
MR> bindings are inspired by the one found in the i2c-mux-pinctrl driver.

MR> Signed-off-by: Maxime Ripard [off-list ref]
MR> ---
MR>  .../devicetree/bindings/i2c/i2c-mux-gpio.txt       |   81 ++++++++++
MR>  drivers/i2c/muxes/i2c-mux-gpio.c                   |  169 +++++++++++++++-----
MR>  2 files changed, 211 insertions(+), 39 deletions(-)
MR>  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt

MR> diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
MR> new file mode 100644
MR> index 0000000..335fc4e
MR> --- /dev/null
MR> +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
MR> @@ -0,0 +1,81 @@
MR> +GPIO-based I2C Bus Mux
MR> +
MR> +This binding describes an I2C bus multiplexer that uses GPIOs to
MR> +route the I2C signals.
MR> +
MR> +                                  +-----+  +-----+
MR> +                                  | dev |  | dev |
MR> +    +------------+                +-----+  +-----+
MR> +    | SoC        |                   |        |
MR> +    |            |          /--------+--------+
MR> +    |   +------+ |  +------+    child bus A, on GPIO value set to 0
MR> +    |   | I2C  |-|--| Mux  |
MR> +    |   +------+ |  +--+---+    child bus B, on GPIO value set to 1
MR> +    |            |     |    \----------+--------+--------+
MR> +    |   +------+ |     |               |        |        |
MR> +    |   | GPIO |-|-----+            +-----+  +-----+  +-----+
MR> +    |   +------+ |                  | dev |  | dev |  | dev |
MR> +    +------------+                  +-----+  +-----+  +-----+
MR> +
MR> +Required properties:
MR> +- compatible: i2c-mux-gpio
MR> +- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
MR> +  port is connected to.
MR> +- mux-gpios: list of gpios to use to control the muxer

s/to use to/used to/


MR> +* Standard I2C mux properties. See mux.txt in this directory.
MR> +* I2C child bus nodes. See mux.txt in this directory.
MR> +
MR> +Optional properties:
MR> +- idle-state: value to set to the muxer when idle. When no value is

How about 'bitmask defining mux state when idle' instead?
Since the array documented as using the bitmasks in the platform_data
and described as an array of bitmasks is called "values", and the file
mux.txt talks about "numbers" to put into reg, won't this be confusing
to have three names for the exact same thing?
MR> +  given, it defaults to the last value used.
MR> +
MR> +For each i2c child node, an I2C child bus will be created. They will
MR> +be numbered based on the reg property of each node.

As far as I can see they are dynamically assigned numbers in the order
they are listed in the dt.
Ah, yes.
MR> +
MR> +Whenever an access is made to a device on a child bus, the value set
MR> +in the revelant node's reg property will be output using the list of
MR> +GPIOs, the first in the list holding the most-significant value.

Isn't it the other way around, E.G. first gpio in mux-gpios controlled
by LSB of reg property, next gpio by lsb+1,  ..?
True indeed.
MR> +
MR> +If an idle state is defined, using the idle-state (optional) property,
MR> +whenever an access is not being made to a device on a child bus, the
MR> +idle value will be programmed into the GPIOs.

s/idle value will be programmed into the GPIOS/GPIOS set according to
the idle value bitmask/
Once again, I'm really not fond of the term "bitmask".

[..]
MR> diff --git a/drivers/i2c/muxes/i2c-mux-gpio.c b/drivers/i2c/muxes/i2c-mux-gpio.c
MR> index 566a675..7ebef01 100644
MR> --- a/drivers/i2c/muxes/i2c-mux-gpio.c
MR> +++ b/drivers/i2c/muxes/i2c-mux-gpio.c
MR> @@ -16,11 +16,13 @@
MR>  #include <linux/module.h>
MR>  #include <linux/slab.h>
MR>  #include <linux/gpio.h>
MR> +#include <linux/of_i2c.h>
MR> +#include <linux/of_gpio.h>
 
MR>  struct gpiomux {
MR>  	struct i2c_adapter *parent;
MR>  	struct i2c_adapter **adap; /* child busses */
MR> -	struct i2c_mux_gpio_platform_data data;
MR> +	struct i2c_mux_gpio_platform_data *data;


Why this change? I don't see why it is needed and the patch would be a
lot easier to review without all the s/.data/->data/ noise.
Ah yes, since mux is already allocated using kcalloc, we don't need to
do it for data as well. I will remove it.

Thanks,
Maxime




-- 
Maxime Ripard, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help