Hi Krzysztof,
On 5/27/24 16:38, Krzysztof Kozlowski wrote:
On 27/05/2024 13:39, Bastien Curutchet wrote:
The i2c-gpio-mux can be used to describe a multiplexer built upon
several i2c isolators having an enable pin (such as LTC4310). These
isolators can need some time between their enable pin's assertion and
the first i2c transfer.
Add a 'transition-delay-ms' property that indicates the delay to be
respected before doing the first i2c transfer.
That's quite limited hardware description, comparing to cover letter.
Please provide full description here, not in cover letter. This is the
binding, so the hardware part.
Ok, I'll add details in next iteration.
Anyway, this does not look like property of mux itself. If there is no
isolator, the mux would work fine, right?
In the case I'm thinking about, there is no mux at all on the hardware,
only two isolators. Each of them have several devices behind. I use the
i2c-gpio-mux to drive the isolators enable pins to always enable only
one of the isolators at a time.
Then why you are not adding this property to every possible bus and I2C
controller? I2C isolator could be placed there as well.
I actually thought about adding a description of I2C isolators because
my real use case is only one I2C isolator on a I2C bus. The isolator has
an enable pin that I want to drive low when the bus is unused to save
power.
But I didn't find a proper way to describe it. I think a property for
I2C controllers is not ideal to describe the GPIO, the transition-delay
and the fact that there could be devices in front of the isolator and/or
devices behind it (see below)
+------------+
| GPIO |
| controller |
+------------+
+------------+ |
| I2C |------+-------------+ |
| controller | | | |
+------------+ +---+---+ +------+------+ |
| dev A | | I2C EN|---------------+
+-------+ | isolator |
+------+------+
|
+-------+-----------+-------
| |
+---+---+ +---+---+
| dev B | | dev C |
+-------+ +-------+
So I started to describe it as a device itself but then I realized that
I was doing something very similar to the i2c-gpio-mux description
that's why I finally submitted this patch series.
So just like RC binding, that's not a property of I2C mux. Maybe this
fits usage of GPIO RC / delay binding.
IMHO that’s more of a MUX property than an RC binding because every MUX
needs some time to switch from one bus to another. It’s just that for
the vast majority of MUXes, this time is so small that it doesn’t need
to be described.
Best regards,
Bastien
