On Monday, April 25, 2011, Rafael J. Wysocki wrote:
> On Saturday, April 23, 2011, Rafael J. Wysocki wrote:
> > On Friday, April 22, 2011, Alan Stern wrote:
> > > On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
> > >
> > > > > The barrier would not prevent the race between the notifier and
> > > >
On Tuesday, April 26, 2011, Guennadi Liakhovetski wrote:
> Hi
Hi,
> On Mon, 25 Apr 2011, Rafael J. Wysocki wrote:
>
> > On Saturday, April 23, 2011, Rafael J. Wysocki wrote:
> > > On Friday, April 22, 2011, Alan Stern wrote:
> > > > On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
> > > >
> > > >
Hi
On Mon, 25 Apr 2011, Rafael J. Wysocki wrote:
> On Saturday, April 23, 2011, Rafael J. Wysocki wrote:
> > On Friday, April 22, 2011, Alan Stern wrote:
> > > On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
> > >
> > > > > The barrier would not prevent the race between the notifier and
> > > > >
On Saturday, April 23, 2011, Rafael J. Wysocki wrote:
> On Friday, April 22, 2011, Alan Stern wrote:
> > On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
> >
> > > > The barrier would not prevent the race between the notifier and runtie
> > > > PM
> > > > from taking place. Why don't we do somethin
On Friday, April 22, 2011, Alan Stern wrote:
> On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
>
> > > The barrier would not prevent the race between the notifier and runtie PM
> > > from taking place. Why don't we do something like this instead:
> > >
> > > ---
> > > drivers/base/dd.c |3 ++-
On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
> > The barrier would not prevent the race between the notifier and runtie PM
> > from taking place. Why don't we do something like this instead:
> >
> > ---
> > drivers/base/dd.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
>
On Friday, April 22, 2011, Rafael J. Wysocki wrote:
> On Friday, April 22, 2011, Alan Stern wrote:
> > On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
> >
> > > > The subsystem should be smart enough to handle runtime PM requests while
> > > > the driver's remove callback is running.
> > >
> > > If
On Friday, April 22, 2011, Alan Stern wrote:
> On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
>
> > > The subsystem should be smart enough to handle runtime PM requests while
> > > the driver's remove callback is running.
> >
> > If we make such a rule, we may as well remove all of the runtime PM
On Fri, 22 Apr 2011, Rafael J. Wysocki wrote:
> > The subsystem should be smart enough to handle runtime PM requests while
> > the driver's remove callback is running.
>
> If we make such a rule, we may as well remove all of the runtime PM
> calls from __device_release_driver().
>
> > > I think
On Thursday, April 21, 2011, Alan Stern wrote:
> On Thu, 21 Apr 2011, Rafael J. Wysocki wrote:
>
> > > > If we choose this approach, then yes, we should provide a suitable API,
> > > > but
> > > > I'm still thinking it would be simpler to move the
> > > > pm_runtime_put_sync() before driver_sysf
On Thu, 21 Apr 2011, Rafael J. Wysocki wrote:
> > > If we choose this approach, then yes, we should provide a suitable API,
> > > but
> > > I'm still thinking it would be simpler to move the pm_runtime_put_sync()
> > > before driver_sysfs_remove() and make the rule as I said previously. :-)
> >
On Thursday, April 21, 2011, Alan Stern wrote:
> On Thu, 21 Apr 2011, Rafael J. Wysocki wrote:
>
> > > > What about making a rule that it is invalid to schedule a future suspend
> > > > or queue a resume request of a device whose driver is being removed?
> > > >
> > > > Arguably, we can't prevent
On Thu, 21 Apr 2011, Rafael J. Wysocki wrote:
> > > What about making a rule that it is invalid to schedule a future suspend
> > > or queue a resume request of a device whose driver is being removed?
> > >
> > > Arguably, we can't prevent people from shooting themselves in the foot
> > > this
>
On Thursday, April 21, 2011, Alan Stern wrote:
> On Wed, 20 Apr 2011, Rafael J. Wysocki wrote:
>
> > On Wednesday, April 20, 2011, Alan Stern wrote:
> > > On Wed, 20 Apr 2011, Rafael J. Wysocki wrote:
> > >
> > > > On Wednesday, April 20, 2011, Alan Stern wrote:
> > > > > On Wed, 20 Apr 2011, Gue
On Wed, 20 Apr 2011, Rafael J. Wysocki wrote:
> On Wednesday, April 20, 2011, Alan Stern wrote:
> > On Wed, 20 Apr 2011, Rafael J. Wysocki wrote:
> >
> > > On Wednesday, April 20, 2011, Alan Stern wrote:
> > > > On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
> > > ...
> > > > Ah, now I see the
On Wednesday, April 20, 2011, Alan Stern wrote:
> On Wed, 20 Apr 2011, Rafael J. Wysocki wrote:
>
> > On Wednesday, April 20, 2011, Alan Stern wrote:
> > > On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
> > ...
> > > Ah, now I see the problem. It looks like we did not give sufficient
> > > tho
On Wed, 20 Apr 2011, Rafael J. Wysocki wrote:
> On Wednesday, April 20, 2011, Alan Stern wrote:
> > On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
> ...
> > Ah, now I see the problem. It looks like we did not give sufficient
> > thought to the case where a device starts off (and therefore shou
[Added linux-pm to the CC list.]
On Wednesday, April 20, 2011, Alan Stern wrote:
> On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
...
> Ah, now I see the problem. It looks like we did not give sufficient
> thought to the case where a device starts off (and therefore should
> finish up) in a po
On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
> As I said above - I did mean probe() and remove(). Now, I have now traced
> down the cause of my problem. In dd.c::driver_probe_device():
>
> pm_runtime_get_noresume(dev);
> pm_runtime_barrier(dev);
> ret = really_probe(dev, d
On Wed, 20 Apr 2011, Alan Stern wrote:
> On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
>
> > Thanks to all for clarifications. Since everyone is convinced, that that
> > idle function in mmc bus.c is appropriate, I restored it and managed to
> > achieve my goals also without it by adjusting
On Wed, 20 Apr 2011, Guennadi Liakhovetski wrote:
> Thanks to all for clarifications. Since everyone is convinced, that that
> idle function in mmc bus.c is appropriate, I restored it and managed to
> achieve my goals also without it by adjusting the platform runtime pm and
> power domain proto
Thanks to all for clarifications. Since everyone is convinced, that that
idle function in mmc bus.c is appropriate, I restored it and managed to
achieve my goals also without it by adjusting the platform runtime pm and
power domain prototype support.
But I still need those "cheating" calls to
On Tue, 19 Apr 2011, Guennadi Liakhovetski wrote:
> On Tue, 19 Apr 2011, Ohad Ben-Cohen wrote:
>
> > On Tue, Apr 19, 2011 at 1:46 PM, Guennadi Liakhovetski
> > wrote:
> > > MMC bus PM operations implement a .runtime_idle() method, which calls
> > > pm_runtime_suspend(), but this call is not bala
On Tue, Apr 19, 2011 at 4:23 PM, Guennadi Liakhovetski
wrote:
> Seeing a "struct dev_pm_ops" instance with .runtime_suspend(),
> .runtime_resume(), and .runtime_idle() methods I understand, that
> "suspend" and "resume" are two counterparts, that balance each other. Now
> with "idle" I am not sure
On Tue, 19 Apr 2011, Ohad Ben-Cohen wrote:
> On Tue, Apr 19, 2011 at 1:46 PM, Guennadi Liakhovetski
> wrote:
> > MMC bus PM operations implement a .runtime_idle() method, which calls
> > pm_runtime_suspend(), but this call is not balanced by a resume
> > counterpart,
>
> What's the exact flow yo
On Tue, Apr 19, 2011 at 1:46 PM, Guennadi Liakhovetski
wrote:
> MMC bus PM operations implement a .runtime_idle() method, which calls
> pm_runtime_suspend(), but this call is not balanced by a resume
> counterpart,
What's the exact flow you refer to ?
> which causes problems with repeated card-p
MMC bus PM operations implement a .runtime_idle() method, which calls
pm_runtime_suspend(), but this call is not balanced by a resume
counterpart, which causes problems with repeated card-plug and driver-load
cycles. Removing this method fixes the disbalance.
Signed-off-by: Guennadi Liakhovetsk
27 matches
Mail list logo
