On Thu, 22 Sep 2016, Oliver Neukum wrote:
> On Wed, 2016-09-21 at 10:35 -0400, Alan Stern wrote:
> > On Wed, 21 Sep 2016, Oliver Neukum wrote:
>
> > > Yes, but this is not the point. A heuristic with a timeout makes
> > > sense only if the uses are unpredictable. If you know with a high
> > >
On Thu, 22 Sep 2016, Ulf Hansson wrote:
> >> > > An observation I made, is when the sdmmc device gets runtime resumed
> >> > > (pm_runtime_get_sync()), the parent device (the usb device) may also
> >> > > become runtime resumed (unless it's already). In this sequence, but
> >> > > *only* when
On Wed, 2016-09-21 at 10:35 -0400, Alan Stern wrote:
> On Wed, 21 Sep 2016, Oliver Neukum wrote:
> > Yes, but this is not the point. A heuristic with a timeout makes
> > sense only if the uses are unpredictable. If you know with a high
> > degree of probability when the next activity comes, you
On 21 September 2016 at 16:45, Alan Stern wrote:
> On Wed, 21 Sep 2016, Ulf Hansson wrote:
>
>> > > My concern is also 2s autosuspend timeout which is set for the usb
>> > > device. Somehow I feel we need to be able "share" more information
>> > > between a parent-child
On Wed, 21 Sep 2016, Ulf Hansson wrote:
> > > My concern is also 2s autosuspend timeout which is set for the usb
> > > device. Somehow I feel we need to be able "share" more information
> > > between a parent-child relationship, in this case between the sdmmc
> > > device and the usb device.
> >
On Wed, 21 Sep 2016, Oliver Neukum wrote:
> On Tue, 2016-09-20 at 10:12 -0400, Alan Stern wrote:
> > On Tue, 20 Sep 2016, Oliver Neukum wrote:
>
> > That shouldn't be an issue in this case, at least, not with the current
> > code. The sdmmc and memstick drivers block autosuspend if media is
>
On 20 September 2016 at 16:09, Alan Stern wrote:
>
> On Tue, 20 Sep 2016, Ulf Hansson wrote:
>
> > >> I am wondering what you think would be a good autosuspend timeout in
> > >> this case? It seems to me that the only thing the rtsx driver really
> > >> care about is to
On Tue, 2016-09-20 at 10:12 -0400, Alan Stern wrote:
> On Tue, 20 Sep 2016, Oliver Neukum wrote:
> That shouldn't be an issue in this case, at least, not with the current
> code. The sdmmc and memstick drivers block autosuspend if media is
> present.
Good.
>
> > > Which means that
On Tue, 20 Sep 2016, Oliver Neukum wrote:
> On Mon, 2016-09-19 at 14:02 -0400, Alan Stern wrote:
> > > We can for sure enable autosuspend for the sdmmc device, although as
> > > soon as an SD card will be detected the rtsx driver will increase
> > the
> > > runtime PM usage count. The count is
On Tue, 20 Sep 2016, Ulf Hansson wrote:
> >> I am wondering what you think would be a good autosuspend timeout in
> >> this case? It seems to me that the only thing the rtsx driver really
> >> care about is to tell the parent device that it needs to be runtime
> >> resumed during a certain
On Mon, 2016-09-19 at 14:02 -0400, Alan Stern wrote:
> > We can for sure enable autosuspend for the sdmmc device, although as
> > soon as an SD card will be detected the rtsx driver will increase
> the
> > runtime PM usage count. The count is decreased when the card is
> > removed (or failed to be
On 19 September 2016 at 20:02, Alan Stern wrote:
> On Mon, 19 Sep 2016, Ulf Hansson wrote:
>
>> On 18 September 2016 at 04:30, Alan Stern wrote:
>> > On Sat, 17 Sep 2016, Ulf Hansson wrote:
>> >
>> >> Each access of the parent device (usb
On Mon, 19 Sep 2016, Ulf Hansson wrote:
> On 18 September 2016 at 04:30, Alan Stern wrote:
> > On Sat, 17 Sep 2016, Ulf Hansson wrote:
> >
> >> Each access of the parent device (usb device) needs to be done in runtime
> >> resumed state. Currently this isn't case while
On 18 September 2016 at 04:30, Alan Stern wrote:
> On Sat, 17 Sep 2016, Ulf Hansson wrote:
>
>> Each access of the parent device (usb device) needs to be done in runtime
>> resumed state. Currently this isn't case while changing the leds, so let's
>> add
On Sat, 17 Sep 2016, Ulf Hansson wrote:
> Each access of the parent device (usb device) needs to be done in runtime
> resumed state. Currently this isn't case while changing the leds, so let's
> add pm_runtime_get_sync() and pm_runtime_put() around these calls.
>
> Signed-off-by: Ulf Hansson
Each access of the parent device (usb device) needs to be done in runtime
resumed state. Currently this isn't case while changing the leds, so let's
add pm_runtime_get_sync() and pm_runtime_put() around these calls.
Signed-off-by: Ulf Hansson
---
While discussing an
16 matches
Mail list logo