Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1370546 > unrolled thread

Re: N900 sleep mode (in 4.5-rc0, if that matters)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: N900 sleep mode (in 4.5-rc0, if that matters) Pali Rohár <pali.rohar@gmail.com> - 2016-04-04 13:10 +0200
    Re: N900 sleep mode (in 4.5-rc0, if that matters) Tony Lindgren <tony@atomide.com> - 2016-04-05 00:40 +0200

#1370546 — Re: N900 sleep mode (in 4.5-rc0, if that matters)

On Wednesday 30 March 2016 12:12:09 Tony Lindgren wrote:
> > How idle system do I need to have? Screen is blanked and machine
> > should be mostly idle, but there's X running on another vt with Mate
> > desktop, and some python scripts... GSM modem should be online.
> 
> Well I think it's the USB only you have blocking deeper idle states.
> 
> Are you sure you rmmod:ed all the USB related modules like in my
> test script?
> 
> MUSB currently has an unresolved issue where it blocks idle states
> if loaded.

Is somebody working on this musb issue? Is there any progress?

-- 
Pali Rohár
pali.rohar@gmail.com

[toc] | [next] | [standalone]

#1370939

* Pali Rohár <pali.rohar@gmail.com> [160404 04:10]:
> On Wednesday 30 March 2016 12:12:09 Tony Lindgren wrote:
> > > How idle system do I need to have? Screen is blanked and machine
> > > should be mostly idle, but there's X running on another vt with Mate
> > > desktop, and some python scripts... GSM modem should be online.
> > 
> > Well I think it's the USB only you have blocking deeper idle states.
> > 
> > Are you sure you rmmod:ed all the USB related modules like in my
> > test script?
> > 
> > MUSB currently has an unresolved issue where it blocks idle states
> > if loaded.
> 
> Is somebody working on this musb issue? Is there any progress?

No idea when I might get to it.. Please take a look if you have  a
chance to work on it, I think all we have to do:

1. Change musb_gadget_pullup() to run as tasklet/delayed_work to
   avoid trying to access I2C PHY's from atomic context. See
   3e43a0725637 ("usb: musb: core: add pm_runtime_irq_safe()")
   for more info. Not sure if this should be done in a generic
   way or for MUSB only. It could be that I remember wrong what
   I thought needs to be done. But we want to get rid of the
   pm_runtime_irq_save() as that currently forever blocks PM
   for the MUSB hardware specific wrapper driver.

2. Remove pm_runtime_irq_safe() added in commit 3e43a0725637

Adding Bin to Cc, maybe he has some better fix in mind.

Regards,

Tony

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web