Hi Sarah,
I will resubmit the patch with these changes shortly.
On Fri, Aug 9, 2013 at 10:22 AM, Sarah Sharp
wrote:
> Hi Shawn,
>
> I noticed that the ChromeOS kernel tree is still using this particular
> patch, and thought it was probably time to revisit it.
>
> On Sat, May 25, 2013 at
Hi Sarah,
I will resubmit the patch with these changes shortly.
On Fri, Aug 9, 2013 at 10:22 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
Hi Shawn,
I noticed that the ChromeOS kernel tree is still using this particular
patch, and thought it was probably time to revisit it.
On Sat,
Hi Shawn,
I noticed that the ChromeOS kernel tree is still using this particular
patch, and thought it was probably time to revisit it.
On Sat, May 25, 2013 at 09:57:57AM -0700, Shawn Nematbakhsh wrote:
> Hi Sarah and Alan,
>
> Thanks for the comments. I will make the following revisions:
>
>
Hi Shawn,
I noticed that the ChromeOS kernel tree is still using this particular
patch, and thought it was probably time to revisit it.
On Sat, May 25, 2013 at 09:57:57AM -0700, Shawn Nematbakhsh wrote:
Hi Sarah and Alan,
Thanks for the comments. I will make the following revisions:
1.
On Wednesday 29 May 2013 16:32:38 Don Zickus wrote:
> On Wed, May 29, 2013 at 12:38:28PM -0700, Sarah Sharp wrote:
> > On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> > > The policy we want to achieve is to disable runtime PM iff there is a
> > > device connected that doesn't have
On Wednesday 29 May 2013 16:32:38 Don Zickus wrote:
On Wed, May 29, 2013 at 12:38:28PM -0700, Sarah Sharp wrote:
On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have
On Wed, May 29, 2013 at 12:38:28PM -0700, Sarah Sharp wrote:
> On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> > The policy we want to achieve is to disable runtime PM iff there is a
> > device connected that doesn't have persist_enabled or a reset_resume()
> > handler and whose
On Wed, 29 May 2013, Sarah Sharp wrote:
> On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> > The policy we want to achieve is to disable runtime PM iff there is a
> > device connected that doesn't have persist_enabled or a reset_resume()
> > handler and whose parent/root hub
On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
> The policy we want to achieve is to disable runtime PM iff there is a
> device connected that doesn't have persist_enabled or a reset_resume()
> handler and whose parent/root hub resets on resume, right?
Makes sense. However, not
On Tue, 28 May 2013, Julius Werner wrote:
> The policy we want to achieve is to disable runtime PM iff there is a
> device connected that doesn't have persist_enabled or a reset_resume()
> handler and whose parent/root hub resets on resume, right? So couldn't
Probably just root hub, not parent.
On Tue, 28 May 2013, Julius Werner wrote:
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on resume, right? So couldn't
Probably just root hub, not parent. A
On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on resume, right?
Makes sense. However, not all
On Wed, 29 May 2013, Sarah Sharp wrote:
On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on
On Wed, May 29, 2013 at 12:38:28PM -0700, Sarah Sharp wrote:
On Tue, May 28, 2013 at 02:41:18PM -0700, Julius Werner wrote:
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on resume, right? So couldn't
we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing)
generic
On Sat, May 25, 2013 at 09:57:57AM -0700, Shawn Nematbakhsh wrote:
> Hi Sarah and Alan,
>
> Thanks for the comments. I will make the following revisions:
>
> 1. Call pm_runtime_get_noresume only when the first device is connected,
> and call pm_runtime_put when the last device is disconnected.
>
On Sat, May 25, 2013 at 09:57:57AM -0700, Shawn Nematbakhsh wrote:
Hi Sarah and Alan,
Thanks for the comments. I will make the following revisions:
1. Call pm_runtime_get_noresume only when the first device is connected,
and call pm_runtime_put when the last device is disconnected.
2.
The policy we want to achieve is to disable runtime PM iff there is a
device connected that doesn't have persist_enabled or a reset_resume()
handler and whose parent/root hub resets on resume, right? So couldn't
we remove the HCD-specific XHCI_RESET_ON_RESUME and set the (existing)
generic
Hi Sarah and Alan,
Thanks for the comments. I will make the following revisions:
1. Call pm_runtime_get_noresume only when the first device is
connected, and call pm_runtime_put when the last device is
disconnected.
2. Wrap the calls in an ifdef CONFIG_USB_DEFAULT_PERSIST.
3. Make sure that all
On Fri, 24 May 2013, Sarah Sharp wrote:
> On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote:
> > If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
> > a reset will be performed upon runtime resume. Any previously suspended
> > devices attached to the
On Fri, 24 May 2013, Sarah Sharp wrote:
On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote:
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will
Hi Sarah and Alan,
Thanks for the comments. I will make the following revisions:
1. Call pm_runtime_get_noresume only when the first device is
connected, and call pm_runtime_put when the last device is
disconnected.
2. Wrap the calls in an ifdef CONFIG_USB_DEFAULT_PERSIST.
3. Make sure that all
On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote:
> If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
> a reset will be performed upon runtime resume. Any previously suspended
> devices attached to the controller will be re-enumerated at this time.
> This will
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will cause problems, for example, if an open system call on the
device
On Fri, May 24, 2013 at 11:12:57AM -0700, Shawn Nematbakhsh wrote:
If a USB controller with XHCI_RESET_ON_RESUME goes to runtime suspend,
a reset will be performed upon runtime resume. Any previously suspended
devices attached to the controller will be re-enumerated at this time.
This will
26 matches
Mail list logo
