Re: [PATCH 1/2] dt-bindings: mux: Document mux-states property

[Peter Rosin]

On 2021-11-30 21:14, Rob Herring wrote:
> On Tue, Nov 30, 2021 at 05:48:46PM +0530, Aswath Govindraju wrote:
>> In some cases, it is required to provide the state to which the mux
>> controller has be set to, from the consumer device tree node. Document the
>> property mux-states that can be used for adding this support.
> 
> I having a hard time understanding why you need this. One consumer 
> configures a mux one way and another consumer another way? How do you 
> arbitrate that? Please elaborate on what 'some cases' are and why it's 
> required.
> 
> Can't you just add a cell for the 'state' allowing for 1-2 cells 
> instead of 0-1?

A mux controller can control several muxes. That happens e.g. when the
same gpio lines are connected to several mux chips in parallel. When
you operate one mux, the other parallel muxes just follow along. If
these muxes are then used orthogonally, coordination is needed. The real
world case I had was I2C and an analog signal connected to an ADC that
went through parallel/dependent muxes like this. It is simply not
possible to freely mux the I2C bus and the analog signal, they are tied
together and dependent and must coordinate their accesses.

The addition now is that Aswath wants a mux control client to "point
at" a single state instead of the whole mux control, and I see that as
a usable addition. It seems like a natural place to specify a single mux
state that some driver needs in some circumstance.

But, since a mux control is inherently a shared resource (see above),
one consumer might need a specific state and some other consumer might
need the whole mux control and manage the states as e.g. the existing
i2c-mux-gpmux binding is doing. So, you need to be able to specify both
ways to point at muxes; either to a single mux state, or to the whole mux
control.

While you could make the extra cell optional, that does not work for
the mux/adi,adg792a binding, since it is using the #mux-control-cells
property to determine which mode it should operate its three muxes in.
Either with one common/parallel mux control, or with three independent
mux controls.

So, that binding is already in the 0-1 territory, and adding an optional
extra cell makes it 0-1-2 with no way to determine what is intended when
the cell count is 1 (three independent mux controls OR one mux control
and a state). I see no way to add the extra state to that binding, short
of adding an extra property somewhere for that driver, but I simply did
not want to go that path because it would get inconsistent when trying
to add that in a backwards compatible way. Or rather, that was my
conclusion.

Suggestions welcome...

Cheers,
Peter