Message-ID: <CAAVjN7dyiSonvsEfawTSi_bJ9umxMFfmA_WAdwz=Yd6wsN4uzA@mail.gmail.com>
Date:	Wed, 1 Oct 2014 13:49:45 -0700
From:	Danielle Costantino <danielle.costantino@...il.com>
To:	Guenter Roeck <groeck@...iper.net>
Cc:	linux-i2c <linux-i2c@...r.kernel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Rajat Jain <rajatjain@...iper.net>
Subject: Re: Fwd: [Proposal] PM sleep children of inactive I2C bus segments
 off Masters in multi-master systems

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 <groeck@...iper.net> 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 <groeck@...iper.net> 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@...iper.net> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists