Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments off Masters in multi-master systems

[Guenter Roeck]

On Wed, Oct 01, 2014 at 01:03:59PM -0700, Danielle Costantino wrote:
> On Wed, Oct 1, 2014 at 12:41 PM, Guenter Roeck <groeck@xxxxxxxxxxx> wrote:
> > On Wed, Oct 01, 2014 at 11:44:59AM -0700, Danielle Costantino wrote:
> >> Re-sending Proposal:
> >>
> >> Currently I2C mux devices that support multiple master arbitration are
> >> the i2c-mux-pca9541 and i2c-arb-gpio-challenge drivers. I propose to
> >> add the ability to configure an interrupt pin from the Master Selector
> >> device to indicate that bus ownership has been lost. Once the device
> >> loses ownership, all of its children should enter a pm sleep mode (as
> >> you can't talk to them at this point) until master-ship has been
> >> reacquired.
> >>
> > Not sure I understand what you are proposing here.
> 
> Lets say you have a active - standby based multi-master system. If the
> other master forced arbitration (took mastership) the next transation
> on any slaves of that bus would return EAGAIN or EBUSY.
> 
> Another point is that once mastership has been lost, the configuration
> of the devices on that bus are no longer known to be valid...therefor
> a re-init of those devices may be needed.
> 
Unfortunately that is a generic problem in a multi-master system.
You never know if the other end reconfigured a device or not,
even if there was no error.

> > A typical use case would be a power supply such as the one supported by
> > drivers/hwmon/lineage-pem.c from both an active and standby system
> > controller. The power supply needs to be accessible from both controllers.
> > If one controller looses access, it can only mean that it did not follow
> > the access protocol. Similar, one controller enforcing access means that
> > it either does not follow the access protocol either, or that the other
> > end did not follow the protocol (or maybe the other end died).
> >
> > In all cases, loss of access does not mean that the end device can or should
> > be put in sleep mode, not even logically. All it means is that there was
> > an access protocol error. Not sure if there is anything that can be done
> > about that, but putting the device into sleep mode does not seem to be
> > an appropriate response to me.
> >
> >> This has come up as an issue when the master loses control over a bus
> >> the return code of all transactions to its lave devices is EIO (not
> >> very helpful).
> >>
> > But, again, doesn't that mean that there was some access protocol error ?
> > Shouldn't it try to re-acquire mastership instead, and block all accesses
> > to slaves until it acquired it ?
> 
> EIO is such a generic error it makes finding weather there was a
> problem communicating or is no longer master of the bus segment.
> 
AFAICS the only time the pca9541 driver returns -EIO is if a transaction
did not complete. Only possible improvement I could imagine would be to
check if mastership was lost if there was an error, and return something
more useful if that is the case. Both -EBUSY or -EAGAIN might make sense
here; I don't really know what would be better or more appropriate.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/