On Wed, Oct 01, 2014 at 01:32:28PM -0700, Danielle Costantino wrote: > My goal was to automatically put the devices behind the master > selector in a (logical) state where all settings would be verified and > if needed corrected and initialized back to how the device was > configured prior to giving up the bus. > That kind of reaction could result in a re-configuration war if both masters disagree how devices should be configured. Also, unless I am missing something, it would require changes in pretty much every i2c client driver. That doesn't really sound feasible to me. Maybe you can find an error code which with some level of confidence reflects "lost mastership". Then you can implement whatever makes sense for your use case in your user space application(s). Guenter > The error return is the main issue, but I was hoping to automate > multi-master bus re-initialization. > > On Wed, Oct 1, 2014 at 1:20 PM, Guenter Roeck <groeck@xxxxxxxxxxx> wrote: > > 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 > > > > -- > - Danielle Costantino -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
