public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
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

  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