On Thu, Sep 12, 2013 at 02:07:48PM -0700, Kevin Hilman wrote:
> IMO, this decision belongs to the PM domain, not to the core. We have
> an established legacy with the current core default (auto) and changing
> that means lots of breakage.
Yup.
> The "forbid by default" can just as easily be han
Aaron Lu writes:
> On 09/11/2013 06:32 AM, Rafael J. Wysocki wrote:
>> On Tuesday, September 10, 2013 10:35:22 PM Mark Brown wrote:
>>> On Tue, Sep 10, 2013 at 10:04:21PM +0200, Rafael J. Wysocki wrote:
On Tuesday, September 10, 2013 05:13:21 PM Mark Brown wrote:
>>>
> OK, that is very m
On Wed, Sep 11, 2013 at 12:14:09PM +0100, Mark Brown wrote:
> On Wed, Sep 11, 2013 at 02:05:43PM +0300, Mika Westerberg wrote:
>
> > I'll also look into converting the existing I2C client drivers to use this
> > method. One question, though, is it better to have the conversion in the
> > same patc
On Wed, Sep 11, 2013 at 02:05:43PM +0300, Mika Westerberg wrote:
> I'll also look into converting the existing I2C client drivers to use this
> method. One question, though, is it better to have the conversion in the
> same patch that introduces the I2C core runtime PM change or as a separate
> pa
On Wed, Sep 11, 2013 at 10:55:52AM +0100, Mark Brown wrote:
> On Wed, Sep 11, 2013 at 09:01:16AM +0800, Aaron Lu wrote:
>
> > Looks like, it all boils down to how many I2C devices should be allowed
> > for runtime PM by default and how many I2C devices should be forbidden.
> > , and then we allow/
On Wed, Sep 11, 2013 at 09:01:16AM +0800, Aaron Lu wrote:
> Looks like, it all boils down to how many I2C devices should be allowed
> for runtime PM by default and how many I2C devices should be forbidden.
> , and then we allow/forbid runtime PM for the majority case in I2C core
> while individual
On 09/11/2013 06:32 AM, Rafael J. Wysocki wrote:
> On Tuesday, September 10, 2013 10:35:22 PM Mark Brown wrote:
>> On Tue, Sep 10, 2013 at 10:04:21PM +0200, Rafael J. Wysocki wrote:
>>> On Tuesday, September 10, 2013 05:13:21 PM Mark Brown wrote:
>>
OK, that is very much not the model which em
On Tuesday, September 10, 2013 10:35:22 PM Mark Brown wrote:
> On Tue, Sep 10, 2013 at 10:04:21PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, September 10, 2013 05:13:21 PM Mark Brown wrote:
>
> > > OK, that is very much not the model which embedded systems follow, in
> > > embedded systems th
On Tue, Sep 10, 2013 at 10:04:21PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 10, 2013 05:13:21 PM Mark Brown wrote:
> > OK, that is very much not the model which embedded systems follow, in
> > embedded systems the driver for the device is fully in control of its
> > own power. It g
On Tuesday, September 10, 2013 05:13:21 PM Mark Brown wrote:
> On Tue, Sep 10, 2013 at 05:26:31PM +0300, Mika Westerberg wrote:
> > On Tue, Sep 10, 2013 at 01:27:54PM +0100, Mark Brown wrote:
>
> > > > There is one difference though -- runtime PM is now blocked by default
> > > > and
> > > > it n
On Tue, Sep 10, 2013 at 05:26:31PM +0300, Mika Westerberg wrote:
> On Tue, Sep 10, 2013 at 01:27:54PM +0100, Mark Brown wrote:
> > > There is one difference though -- runtime PM is now blocked by default and
> > > it needs to be unblocked from the userspace per each device.
> > ...as you say.
>
On Tue, Sep 10, 2013 at 01:27:54PM +0100, Mark Brown wrote:
> On Tue, Sep 10, 2013 at 10:51:00AM +0300, Mika Westerberg wrote:
> > On Mon, Sep 09, 2013 at 04:40:28PM +0100, Mark Brown wrote:
>
> > > How is this going to interact with client devices which are already
> > > enabling runtime PM for t
On Tue, Sep 10, 2013 at 10:51:00AM +0300, Mika Westerberg wrote:
> On Mon, Sep 09, 2013 at 04:40:28PM +0100, Mark Brown wrote:
> > How is this going to interact with client devices which are already
> > enabling runtime PM for themselves, and what are the advantages of doing
> > this over having t
On Tuesday, September 10, 2013 10:51:00 AM Mika Westerberg wrote:
> On Mon, Sep 09, 2013 at 04:40:28PM +0100, Mark Brown wrote:
> > On Mon, Sep 09, 2013 at 04:34:38PM +0300, Mika Westerberg wrote:
> >
> > > + /*
> > > + * Enable runtime PM for the client device. If the client wants to
> > > + *
On Mon, Sep 09, 2013 at 04:40:28PM +0100, Mark Brown wrote:
> On Mon, Sep 09, 2013 at 04:34:38PM +0300, Mika Westerberg wrote:
>
> > + /*
> > +* Enable runtime PM for the client device. If the client wants to
> > +* participate on runtime PM it should call pm_runtime_put() in its
> > +
On Mon, Sep 09, 2013 at 04:34:38PM +0300, Mika Westerberg wrote:
> + /*
> + * Enable runtime PM for the client device. If the client wants to
> + * participate on runtime PM it should call pm_runtime_put() in its
> + * probe() callback.
> + *
> + * User still needs to
From: Aaron Lu
This patch adds runtime PM support for the I2C bus in a similar way that
has been done for PCI bus already. This means that the I2C bus core
prepares runtime PM for a client device just before a driver is about to be
bound to it. Devices that are not bound to any driver are not pre
17 matches
Mail list logo
