On Thu, Apr 18, 2013 at 8:18 AM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
All right, I've finally come back to this long thread. To sum up:
xHCI hosts that have the effected TI redriver may lose device connect
events when in D3hot or D3cold, if the port goes into Compliance Mode.
All right, I've finally come back to this long thread. To sum up:
xHCI hosts that have the effected TI redriver may lose device connect
events when in D3hot or D3cold, if the port goes into Compliance Mode.
Effected xHCI hosts may lose device connect events (or wake events, if
those happen
- correct comp_mode_recovery_timer on
return from hibernate
On 03/14/2013 05:42 PM, Alexis R. Cortes wrote:
Hi Sarah,
On 3/11/2013 5:20 PM, Sarah Sharp wrote:
On Mon, Mar 11, 2013 at 05:33:26PM +, Cortes, Alexis wrote:
Hi Sarah,
Sorry for my
On Mon, 25 Mar 2013, Sarah Sharp wrote:
On Mon, Mar 25, 2013 at 11:14:15PM +0100, Rafael J. Wysocki wrote:
On Monday, March 25, 2013 02:35:37 PM Sarah Sharp wrote:
Alan,
Is there a way to disable runtime PM for a PCI host controller, but
still allow the system to
]
Sent: Friday, March 22, 2013 11:44 AM
To: Cortes, Alexis
Cc: Sarah Sharp; Alan Stern; linux-usb@vger.kernel.org; r...@sisk.pl;
dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on
return from hibernate
On 03/14/2013 05:42 PM
...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on
return from hibernate
On 03/14/2013 05:42 PM, Alexis R. Cortes wrote:
Hi Sarah,
On 3/11/2013 5:20 PM, Sarah Sharp wrote:
On Mon, Mar 11, 2013 at 05:33:26PM +, Cortes
-usb@vger.kernel.org; r...@sisk.pl;
dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return
from hibernate
On 03/14/2013 05:42 PM, Alexis R. Cortes wrote:
Hi Sarah,
On 3/11/2013 5:20 PM, Sarah Sharp wrote:
On Mon, Mar 11, 2013 at 05:33:26PM +
.
-Original Message-
From: Tony Camuso [mailto:tcam...@redhat.com]
Sent: Friday, March 22, 2013 11:44 AM
To: Cortes, Alexis
Cc: Sarah Sharp; Alan Stern; linux-usb@vger.kernel.org; r...@sisk.pl;
dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return
To: Cortes, Alexis
Cc: Sarah Sharp; Alan Stern; linux-usb@vger.kernel.org; r...@sisk.pl;
dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return
from hibernate
On 03/14/2013 05:42 PM, Alexis R. Cortes wrote:
Hi Sarah,
On 3/11/2013 5:20
On 03/14/2013 05:42 PM, Alexis R. Cortes wrote:
Hi Sarah,
On 3/11/2013 5:20 PM, Sarah Sharp wrote:
On Mon, Mar 11, 2013 at 05:33:26PM +, Cortes, Alexis wrote:
Hi Sarah,
Sorry for my delayed response, I was investigating this. By 'Inactive' state
you mean the Compliance mode? since
: Friday, March 22, 2013 11:44 AM
To: Cortes, Alexis
Cc: Sarah Sharp; Alan Stern; linux-usb@vger.kernel.org; r...@sisk.pl;
dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from
hibernate
On 03/14/2013 05:42 PM, Alexis R. Cortes wrote:
Hi Sarah,
On 3/11
On 03/22/2013 02:33 PM, Cortes, Alexis wrote:
Hi Tony,
Well, considering the circumstances, the only issue I see here is that the
system won't be able to wake on a device connect if the port to which the
device was connected enters in compliance mode (I might add that compliance
mode is not
; Quach, Brian; Llamas, Jorge
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from
hibernate
On 03/22/2013 02:33 PM, Cortes, Alexis wrote:
Hi Tony,
Well, considering the circumstances, the only issue I see here is that the
system won't be able to wake on a device
: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return
from hibernate
On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote:
On Tue, 5 Mar 2013, Sarah Sharp wrote:
static void compliance_mode_recovery(unsigned long arg) { ...
for (i = 0; i xhci-num_usb3_ports; i
: [PATCH v4] xhci - correct comp_mode_recovery_timer on return from
hibernate
On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote:
On Tue, 5 Mar 2013, Sarah Sharp wrote:
static void compliance_mode_recovery(unsigned long arg) { ...
for (i = 0; i xhci-num_usb3_ports; i
...@sisk.pl; dzic...@redhat.com
Subject: Re: [PATCH v4] xhci - correct comp_mode_recovery_timer on return
from hibernate
On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote:
On Tue, 5 Mar 2013, Sarah Sharp wrote:
static void compliance_mode_recovery(unsigned long arg
On Tue, 5 Mar 2013, Sarah Sharp wrote:
static void compliance_mode_recovery(unsigned long arg)
{
...
for (i = 0; i xhci-num_usb3_ports; i++) {
temp = xhci_readl(xhci, xhci-usb3_ports[i]);
if ((temp PORT_PLS_MASK) == USB_SS_PORT_LS_COMP_MOD) {
On Tue, Mar 05, 2013 at 03:14:10PM -0800, Sarah Sharp wrote:
*/
static void compliance_mode_recovery_timer_init(struct xhci_hcd *xhci)
{
+ if (timer_pending(xhci-comp_mode_recovery_timer)) {
+ xhci_dbg(xhci, Compliance Mode Recovery Timer already
active.\n);
+
On Wed, 6 Mar 2013, Don Zickus wrote:
On Tue, Mar 05, 2013 at 03:14:10PM -0800, Sarah Sharp wrote:
*/
static void compliance_mode_recovery_timer_init(struct xhci_hcd *xhci)
{
+ if (timer_pending(xhci-comp_mode_recovery_timer)) {
+ xhci_dbg(xhci, Compliance Mode
On Wed, Mar 06, 2013 at 10:12:14AM -0500, Alan Stern wrote:
On Tue, 5 Mar 2013, Sarah Sharp wrote:
static void compliance_mode_recovery(unsigned long arg)
{
...
for (i = 0; i xhci-num_usb3_ports; i++) {
temp = xhci_readl(xhci, xhci-usb3_ports[i]);
On Wed, 6 Mar 2013, Sarah Sharp wrote:
If xhci_suspend deletes the Compliance Mode Recovery timer then the
timer will never fire while the controller is in D3cold. The problem
won't arise.
Alex,
Can the USB 3.0 port go into the Inactive sate while the host is in
D3hot or D3cold?
Hi Sarah, Tony,
On 2/27/2013 6:20 PM, Sarah Sharp wrote: On Wed, Feb 27, 2013 at 04:41:45PM
-0500, Alan Stern wrote:
Well, at this point, I have to say that Alex knows more about the quirk
than I do. However, my gut feeling is that bus_suspend/resume is not
the right place to stop the
On 02/27/2013 07:20 PM, Sarah Sharp wrote:
Basically, I'd like Tony to make his first patch work, rather than
pursuing moving the timer manipulation to xhci_bus_suspend/resume.
Not to add confusion, but here is a less intrusive patch that simply
checks to see if the Compliance Mode Recovery
On 02/26/2013 11:11 AM, Alan Stern wrote:
On Tue, 26 Feb 2013, Tony Camuso wrote:
Then should I continue to pursue relocating calls to init and delete
the compliance mode recovery timer to xhci_bus_suspend/resume?
I don't know. If you think the scheme will work then pursue it,
otherwise
On Wed, 27 Feb 2013, Tony Camuso wrote:
On 02/26/2013 11:11 AM, Alan Stern wrote:
On Tue, 26 Feb 2013, Tony Camuso wrote:
Then should I continue to pursue relocating calls to init and delete
the compliance mode recovery timer to xhci_bus_suspend/resume?
I don't know. If you think the
On Wed, Feb 27, 2013 at 04:41:45PM -0500, Alan Stern wrote:
On Wed, 27 Feb 2013, Tony Camuso wrote:
I was able to make the scheme work by adding the following
immediately upon entering compliance_recovery_node_timer_init()
if (timer_pending(xhci-comp_mode_recovery_timer)) {
On 02/27/2013 07:20 PM, Sarah Sharp wrote:
I would like be conservative here, and keep as much of the current code
we have (with the compliance timer being manipulated in xhci_suspend and
xhci_resume). That was the code that was submitted by TI, and we should
stick as close to it as possible,
On 02/25/2013 05:15 PM, Alan Stern wrote:
Probably because the buses are registered at boot but there aren't
any devices plugged in. (Or maybe there are devices, but the system
is too busy doing other things during boot to detect them for a
while.) Since the buses are idle, they get suspended.
On Tue, 26 Feb 2013, Tony Camuso wrote:
On 02/25/2013 05:15 PM, Alan Stern wrote:
Probably because the buses are registered at boot but there aren't
any devices plugged in. (Or maybe there are devices, but the system
is too busy doing other things during boot to detect them for a
On 02/21/2013 05:04 PM, Alan Stern wrote:
Would it be simpler to delete the timer in xhci_bus_suspend() and
restart it in xhci_bus_resume()? Then you wouldn't need to care
about the difference between suspend and hibernation.
Alan,
I tried implementing this. There were some static
On Mon, 25 Feb 2013, Tony Camuso wrote:
On 02/21/2013 05:04 PM, Alan Stern wrote:
Would it be simpler to delete the timer in xhci_bus_suspend() and
restart it in xhci_bus_resume()? Then you wouldn't need to care
about the difference between suspend and hibernation.
Alan,
I tried
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.
The fix created a timer, comp_mode_recovery_timer, which is deleted from
a timer list when
Sarah,
Here it is. Just finished testing it.
The differences between this v4 patch and the v1 patch is an explanation
that incorporates the knowledge shared by Alan Stern concerning what is
actually happening.
I have omitted the cosmetic changes suggested by Sergei. There may be
one cosmetic
On Thu, 21 Feb 2013, Tony Camuso wrote:
Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP
Hardware) was a workaround for systems using the SN65LVPE502CP,
controller, but it introduced a bug in resume from hibernate.
The fix created a timer, comp_mode_recovery_timer,
On Thu, Feb 21, 2013 at 05:04:49PM -0500, Alan Stern wrote:
On Thu, 21 Feb 2013, Tony Camuso wrote:
This patch avoids the problem by deleting the timer in xhci_resume()
when resuming from hibernate. Now xhci_resume() can safely make the
call to create a new instance of this timer, whether
35 matches
Mail list logo
