* Re: [RFC 0/4] prototype: switch I2C IP cores at runtime
2014-12-15 20:20 [RFC 0/4] prototype: switch I2C IP cores at runtime Wolfram Sang
@ 2015-01-05 14:28 ` Geert Uytterhoeven
2015-03-14 11:43 ` Wolfram Sang
2015-03-14 14:37 ` Laurent Pinchart
2 siblings, 0 replies; 4+ messages in thread
From: Geert Uytterhoeven @ 2015-01-05 14:28 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [RFC 0/4] prototype: switch I2C IP cores at runtime
2014-12-15 20:20 [RFC 0/4] prototype: switch I2C IP cores at runtime Wolfram Sang
2015-01-05 14:28 ` Geert Uytterhoeven
@ 2015-03-14 11:43 ` Wolfram Sang
2015-03-14 14:37 ` Laurent Pinchart
2 siblings, 0 replies; 4+ messages in thread
From: Wolfram Sang @ 2015-03-14 11:43 UTC (permalink / raw)
To: linux-sh
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC 0/4] prototype: switch I2C IP cores at runtime
2014-12-15 20:20 [RFC 0/4] prototype: switch I2C IP cores at runtime Wolfram Sang
2015-01-05 14:28 ` Geert Uytterhoeven
2015-03-14 11:43 ` Wolfram Sang
@ 2015-03-14 14:37 ` Laurent Pinchart
2 siblings, 0 replies; 4+ messages in thread
From: Laurent Pinchart @ 2015-03-14 14:37 UTC (permalink / raw)
To: linux-sh
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
^ permalink raw reply [flat|nested] 4+ messages in thread