On 2018-07-20 13:28, Arnd Bergmann wrote:

On Fri, Jul 20, 2018 at 1:13 PM, Peter Rosin [off-list ref] wrote:

quoted

On 2018-07-20 12:57, Arnd Bergmann wrote:

quoted

* What I understand from reading i2c-demux-pinctrl.c, a slave device
  will only ever be observable from one master at a time, when you
  switch over, all children get removed on one master and added to
  the other one, to be probed again by their respective drivers.
  I can see this as a useful feature on i3c as well, in particular to
  deal with the situation where we have i2c slaves connected to a
  pinmux that can switch them between an i3c master and an
  i2c-only master (possibly a gpio based one). That particular use
  case however doesn't seem to fix well in the current code, which
  is structure around i3c buses.

It's pretty easy to come up with examples where this reprobing is
not desirable at all. E.g. if one of the involved I2C devices is
a HDMI encoder (I have a TDA19988 here) sitting in the middle of the
graphics pipeline. Blink-blink on the screen because some *other*
unrelated device needed to be accessed by an alternative master. Not
pretty.

Agreed, we definitely don't want to reprobe all devices during normal
operation for i3c master handover.

What is the least contrived use case that you can think of where we
would want to use one master to talk to one device on the bus,
but another master to talk to another device on the same bus?
I still hope that we can decide that this is not a useful scenario
at all.

If we find a case in which it is needed, we could still deal with it
like this:
- enumerate all slaves connected to the bus for each of the
  two masters
- mark each slave as status="enabled" in at most one of the
  buses, and as disabled everywhere else
- Use dynamic handover according to the bus protocol to
  switch masters without having Linux even know that the
  two buses are shared.

That scenario would then fall completely into the "secondary
master handover" category but require no special handling
in the i3c layer beyond what we need for secondary masters
that are managed by something outside of the kernel's
score (a microcontroller, firmware, ...).

The worst case is not mentioned above, where a single device benefits
from being accessed by two different masters.

That happens e.g. if one master is speedy but triggers a quirk and
one master is slow and reliable, and the device must use the speedy
master for some things (high bandwidth data?) but can't use it for
other things (configuration?) and must fall back to the slow and
reliable master for that.

I don't have an actual example for I2C, maybe Wolfram does? But I can
invent a case. E.g. the speedy DMA-enabled master cannot generate
RESTART, which is a must for (re-)configuration, but not for passing
data to the device.


Also consider some future HW that has several I3C blocks, but they
are not identical. There's one beefy kind and one slim kind (I'm sure
you can find HW with different flavors of I2C blocks). Even if the
HW designers intended for one type of block to be superior in every
aspect, they might have made a mistake? This HW also has a pinmux, so
the SW is free to route different I3C blocks to the actual I3C bus.
Maybe the involved I3C blocks don't see the bus when the pinmux is
in the "wrong" state? Then you can't do a normal handover...


But if you *want* to end up with "that's just too contrived", then
of course that's where you'll end up.

Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html