[RFC 0/4] prototype: switch I2C IP cores at runtime

[RFC 0/4] prototype: switch I2C IP cores at runtime

[Wolfram Sang]

Some SoC (like Renesas RCar Gen2) have different I2C IP cores with different
feature sets. This is an experimental patch series to let those different IP
cores access the same I2C bus at runtime. Finally, we have some code to talk
about :) Unlike previous sketched versions, this one does not require a
remove/probe-cycle of I2C bus drivers which would mean complete
reinitialization of all connected I2C clients. However, the first two patches
need serious discussion. So, have a look if you are interested...

These patches are only sent to the sh-list for now. I'd like to have consensus
here before involving people from the outside.


Wolfram Sang (4):
  pinctrl: allow to unselect a state
  i2c: mux: add function to reparent a mux
  ARM: shmobile: r8a7790: lager: add i2c-demuxer to dts
  i2c: mux: demux-pinctrl: add driver

 .../devicetree/bindings/i2c/i2c-demux-pinctrl.txt  |  65 ++++++++
 arch/arm/boot/dts/r8a7790-lager.dts                |  54 ++++--
 drivers/i2c/i2c-mux.c                              |   8 +
 drivers/i2c/muxes/Kconfig                          |   6 +
 drivers/i2c/muxes/Makefile                         |   2 +
 drivers/i2c/muxes/i2c-demux-pinctrl.c              | 183 +++++++++++++++++++++
 drivers/pinctrl/core.c                             |  34 ++--
 include/linux/i2c-mux.h                            |   2 +
 include/linux/pinctrl/consumer.h                   |   5 +
 9 files changed, 334 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
 create mode 100644 drivers/i2c/muxes/i2c-demux-pinctrl.c

-- 
2.1.3

Re: [RFC 0/4] prototype: switch I2C IP cores at runtime

[Geert Uytterhoeven]

Hi Wolfram,

On Mon, Dec 15, 2014 at 9:20 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> Some SoC (like Renesas RCar Gen2) have different I2C IP cores with different
> feature sets. This is an experimental patch series to let those different IP
> cores access the same I2C bus at runtime. Finally, we have some code to talk

Thanks for your series!

> about :) Unlike previous sketched versions, this one does not require a
> remove/probe-cycle of I2C bus drivers which would mean complete
> reinitialization of all connected I2C clients. However, the first two patches

Not having to remove/probe all slaves is great!

> need serious discussion. So, have a look if you are interested...

I don't really have comments about the first two patches, as they are
"implementation details".

I'm mostly approaching this from the DT point of view, as DT describes the
hardware, so the description should reflect the actual hardware topology as
closely as possible.

Currently DT describes (let's keep using i2c as an example):
  - one ore more i2c masters (in .dtsi),
  - an i2c bus (in .dts), which is a child of one particular i2c master node,
  - pinctrl (in .dts) to link the i2c bus to one particular i2c master.

Obviously this does not match the hardware, as
  (1) pinctrl is dynamic, and
  (2) the i2c bus is not hard-tied to that specific i2c master instance.

What does describe the hardware is:
  - one or more i2c masters (in .dtsi),
  - pinctrl for the i2c masters (tables/code under drivers/pinctrl/),
  - an i2c bus (in .dts), defined by actual pin connections,
  - pinctrl (in .dts) to link the pin connections used by the i2c bus to one
    default i2c master (is this needed?).
With the above description, switching can be controlled from pinctrl,
triggered by the user or by availability of drivers and/or QoS.
Of course callbacks are needed to inform i2c masters (or the i2c subsystem
if you want to avoid remove/probe-cycles) if a bus is moved to another
master.

Your "i2c-demux" in DT is actually a description of an i2c bus.
But instead of linking it to pins, it contains a list of all i2c masters.
If I want to add an i2c-gpio master, I'll have to add it to DT. That sounds
insignificant, but (in theory) all I/O masters could be implemented using GPIO.
So one day someone may implement an xxx-gpio driver for whatever bus,
and I think it should be supported out-of-the-box. When using pins, and thus
describing the i2c bus in a pin-centric way, that will just work.

Notes: for other buses, it may be required to support using only a subset of
all pins, depending on which SoC module is used. E.g.
  - A QSPI FLASH uses 4 wires in quad transfer mode, but only 2 in dual
    or single transfer mode, and not all SPI masters support quad transfer
    mode,
  - A serial port may or may not support RTS/CTS depending on the used
    serial module.

So... let's hint "Send", wait and see...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

Re: [RFC 0/4] prototype: switch I2C IP cores at runtime

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]

Hi Geert,

finally going back to this topic.

> I'm mostly approaching this from the DT point of view, as DT describes the
> hardware, so the description should reflect the actual hardware topology as
> closely as possible.
> 
> Currently DT describes (let's keep using i2c as an example):
>   - one ore more i2c masters (in .dtsi),
>   - an i2c bus (in .dts), which is a child of one particular i2c master node,
>   - pinctrl (in .dts) to link the i2c bus to one particular i2c master.
> 
> Obviously this does not match the hardware, as
>   (1) pinctrl is dynamic, and
>   (2) the i2c bus is not hard-tied to that specific i2c master instance.
> 
> What does describe the hardware is:
>   - one or more i2c masters (in .dtsi),
>   - pinctrl for the i2c masters (tables/code under drivers/pinctrl/),
>   - an i2c bus (in .dts), defined by actual pin connections,
>   - pinctrl (in .dts) to link the pin connections used by the i2c bus to one
>     default i2c master (is this needed?).
> With the above description, switching can be controlled from pinctrl,
> triggered by the user or by availability of drivers and/or QoS.

If I understood correctly, we currently can't describe this in DT this
way. If we wanted to connect a bus to pins, we need to tie it to the pin
names like "GP5_5" for SCL and "GP5_6" to SDA. We don't have those, we
only have the function groups like "iic2" or "i2c2". And even if we had
those, we would need a reverse mapping to check if "GP5_5" can be
configured to this or that I2C core. Or?

> Your "i2c-demux" in DT is actually a description of an i2c bus.
> But instead of linking it to pins, it contains a list of all i2c masters.

Yes, one layer of indirection. The list is (currently) only used to get
the desired pin mapping.

> If I want to add an i2c-gpio master, I'll have to add it to DT. That sounds
> insignificant, but (in theory) all I/O masters could be implemented using GPIO.
> So one day someone may implement an xxx-gpio driver for whatever bus,
> and I think it should be supported out-of-the-box. When using pins, and thus
> describing the i2c bus in a pin-centric way, that will just work.

If my assumption about the reverse mapping above holds true, I don't
think this is worth the hazzle?

Thanks for your feedback!

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC 0/4] prototype: switch I2C IP cores at runtime

[Laurent Pinchart]

Hi Geert,

On Monday 05 January 2015 15:28:09 Geert Uytterhoeven wrote:
> On Mon, Dec 15, 2014 at 9:20 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
> > Some SoC (like Renesas RCar Gen2) have different I2C IP cores with
> > different feature sets. This is an experimental patch series to let those
> > different IP cores access the same I2C bus at runtime. Finally, we have
> > some code to talk
>
> Thanks for your series!
> 
> > about :) Unlike previous sketched versions, this one does not require a
> > remove/probe-cycle of I2C bus drivers which would mean complete
> > reinitialization of all connected I2C clients. However, the first two
> > patches
>
> Not having to remove/probe all slaves is great!
> 
> > need serious discussion. So, have a look if you are interested...
> 
> I don't really have comments about the first two patches, as they are
> "implementation details".
> 
> I'm mostly approaching this from the DT point of view, as DT describes the
> hardware, so the description should reflect the actual hardware topology as
> closely as possible.
> 
> Currently DT describes (let's keep using i2c as an example):
>   - one ore more i2c masters (in .dtsi),
>   - an i2c bus (in .dts), which is a child of one particular i2c master
> node, - pinctrl (in .dts) to link the i2c bus to one particular i2c master.
> 
> Obviously this does not match the hardware, as
>   (1) pinctrl is dynamic, and
>   (2) the i2c bus is not hard-tied to that specific i2c master instance.
> 
> What does describe the hardware is:
>   - one or more i2c masters (in .dtsi),
>   - pinctrl for the i2c masters (tables/code under drivers/pinctrl/),
>   - an i2c bus (in .dts), defined by actual pin connections,
>   - pinctrl (in .dts) to link the pin connections used by the i2c bus to one
> default i2c master (is this needed?).
> With the above description, switching can be controlled from pinctrl,
> triggered by the user or by availability of drivers and/or QoS.
> Of course callbacks are needed to inform i2c masters (or the i2c subsystem
> if you want to avoid remove/probe-cycles) if a bus is moved to another
> master.
> 
> Your "i2c-demux" in DT is actually a description of an i2c bus.
> But instead of linking it to pins, it contains a list of all i2c masters.
> If I want to add an i2c-gpio master, I'll have to add it to DT. That sounds
> insignificant, but (in theory) all I/O masters could be implemented using
> GPIO. So one day someone may implement an xxx-gpio driver for whatever bus,
> and I think it should be supported out-of-the-box. When using pins, and
> thus describing the i2c bus in a pin-centric way, that will just work.
> 
> Notes: for other buses, it may be required to support using only a subset of
> all pins, depending on which SoC module is used. E.g.
>   - A QSPI FLASH uses 4 wires in quad transfer mode, but only 2 in dual
>     or single transfer mode, and not all SPI masters support quad transfer
>     mode,
>   - A serial port may or may not support RTS/CTS depending on the used
>     serial module.
> 
> So... let's hint "Send", wait and see...

For what it's worth, embedded audio has a similar issue with I2S busses that 
can have multiple masters. We've discussed at the FOSDEM how this could be 
represented in DT using the graph OF bindings, and concluded that we probably 
need a DT node to represent the bus itself.

-- 
Regards,

Laurent Pinchart