added proper mailing lists...I hope
--
- Danielle Costantino
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.
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).
Any comments would be appreciated, I am just looking if there is
interest in this.
Thanks,
On Wed, Oct 1, 2014 at 11:43 AM, Guenter Roeck <[email protected]> wrote:
> On Wed, Oct 01, 2014 at 11:39:49AM -0700, Danielle Costantino wrote:
>> added proper mailing lists...I hope
>>
>
> Hi Danielle,
>
> I don't see the actual proposal, and I don't find anything on the web
> either when looking for the headline :-(.
>
> Guenter
--
- Danielle Costantino
On Wed, Oct 01, 2014 at 11:39:49AM -0700, Danielle Costantino wrote:
> added proper mailing lists...I hope
>
Hi Danielle,
I don't see the actual proposal, and I don't find anything on the web
either when looking for the headline :-(.
Guenter
On Wed, Oct 1, 2014 at 12:41 PM, Guenter Roeck <[email protected]> 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.
> 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.
>
> Thanks,
> Guenter
Thanks
--
- Danielle Costantino
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.
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 ?
Thanks,
Guenter
On Wed, Oct 01, 2014 at 01:03:59PM -0700, Danielle Costantino wrote:
> On Wed, Oct 1, 2014 at 12:41 PM, Guenter Roeck <[email protected]> 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
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.
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 <[email protected]> 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 <[email protected]> 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
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 <[email protected]> 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 <[email protected]> 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
Thanks, I will probably work on error return values for master
selectors and add IRQ support to the pca9541 driver.
On Wed, Oct 1, 2014 at 1:43 PM, Guenter Roeck <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> 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
--
- Danielle Costantino
> 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).
We have a documented fault code for ArbitrationLost and that is -EAGAIN
(see Documentation/i2c/fault-codes). If a driver does use something
else, patches are very welcome.
Other than that, I find this thread very confusing. Of course can
another master modify the clients, this is what multi-master is all
about, no?
On Wed, Oct 01, 2014 at 11:10:47PM +0200, Wolfram Sang wrote:
>
> > 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).
>
> We have a documented fault code for ArbitrationLost and that is -EAGAIN
> (see Documentation/i2c/fault-codes). If a driver does use something
> else, patches are very welcome.
>
> Other than that, I find this thread very confusing. Of course can
> another master modify the clients, this is what multi-master is all
> about, no?
>
That is the point I was trying to make in one of my earlier replies.
Guenter
On Wed, Oct 01, 2014 at 02:16:57PM -0700, Guenter Roeck wrote:
> On Wed, Oct 01, 2014 at 11:10:47PM +0200, Wolfram Sang wrote:
> >
> > > 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).
> >
> > We have a documented fault code for ArbitrationLost and that is -EAGAIN
> > (see Documentation/i2c/fault-codes). If a driver does use something
> > else, patches are very welcome.
> >
> > Other than that, I find this thread very confusing. Of course can
> > another master modify the clients, this is what multi-master is all
> > about, no?
> >
> That is the point I was trying to make in one of my earlier replies.
Yes, and I wondered why the thread continued after that, so I thought
I'll bring it up again :) No, seriously, I did not understand the reply
to that mail of yours, but I'll try again tomorrow after some sleep.