From: Bastien Curutchet <bastien.curutchet@bootlin.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
Peter Rosin <peda@axentia.se>, Andi Shyti <andi.shyti@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Peter Korsgaard <peter.korsgaard@barco.com>,
Wolfram Sang <wsa@kernel.org>
Cc: linux-i2c@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
herve.codina@bootlin.com, christophercordahi@nanometrics.ca
Subject: Re: [PATCH 1/3] dt-bindings: i2c: gpio: Add 'transition-delay-ms' property
Date: Tue, 28 May 2024 08:59:06 +0200 [thread overview]
Message-ID: <1cfef2c3-3b24-469d-b55a-377f2d42756b@bootlin.com> (raw)
In-Reply-To: <4f4db483-6042-4f85-9c64-8d3ad9290506@kernel.org>
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
next prev parent reply other threads:[~2024-05-28 6:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-27 11:39 [PATCH 0/3] i2c: mux: gpio: Add 'transition-delay-ms' property Bastien Curutchet
2024-05-27 11:39 ` [PATCH 1/3] dt-bindings: i2c: " Bastien Curutchet
2024-05-27 14:38 ` Krzysztof Kozlowski
2024-05-28 6:59 ` Bastien Curutchet [this message]
2024-05-28 7:49 ` Krzysztof Kozlowski
2024-05-27 11:39 ` [PATCH 2/3] i2c: mux: gpio: Re-order #include to match alphabetic order Bastien Curutchet
2024-05-27 11:39 ` [PATCH 3/3] i2c: mux: gpio: Add support for the 'transition-delay-ms' property Bastien Curutchet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1cfef2c3-3b24-469d-b55a-377f2d42756b@bootlin.com \
--to=bastien.curutchet@bootlin.com \
--cc=andi.shyti@kernel.org \
--cc=christophercordahi@nanometrics.ca \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=herve.codina@bootlin.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=peter.korsgaard@barco.com \
--cc=robh@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox