Re: [linux-usb-devel] [PATCH] Re-power USB ports on wakeup

2005-03-16 Thread Jack Malmostoso
Ciao David Brownell, nel tuo messaggio dicevi:

> This patch is self-evidently incorrect:

So you suggest not to apply it?
I mean, it can damage the hardware, or is it just "unclean"?

Thank you.

-- 
On Oct 5 1991, 8.53 AM; Linus Benedict Torvalds said:
>I can (well, almost) hear you asking yourselves "why?". Hurd will be
>out in a year (or two, or next month, who knows), and I've already got
>minix.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [linux-usb-devel] [PATCH] Re-power USB ports on wakeup

2005-03-16 Thread Michael Schmitz
> > Seems something gets reset upon the first replugging after wakeup. Any
> > idea what that might be?
>
> Not really. If i had an idea, I'd try to find a proper patch :)

Maybe David or BenH have a hint or two.

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [linux-usb-devel] [PATCH] Re-power USB ports on wakeup

2005-03-16 Thread Michael Schmitz
> > Doesn't work for me ... the device attached to the port is still
> > powered down after wakeup.
>
> Yes, me too, but at least it's seen if you reconnect it. For me at
> least ?

Right, that works. I left the mouse connected ... Funny enough, now that
I repeat the test it works even with the mouse connected.

After unloading and reloading the module, the mouse isn't found (powered
down) on the first wakeup, then powers up after replugging and powers up
again after further wakeup, with no replugging necessary.

Seems something gets reset upon the first replugging after wakeup. Any
idea what that might be?

Besides, I didn't apply that patch on top of your first one, rather used
pristine sources ... in case that matters.

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [linux-usb-devel] [PATCH] Re-power USB ports on wakeup

2005-03-16 Thread Colin Leroy
On 16 Mar 2005 at 15h03, Michael Schmitz wrote:

Hi, 

> Seems something gets reset upon the first replugging after wakeup. Any
> idea what that might be?

Not really. If i had an idea, I'd try to find a proper patch :)

> Besides, I didn't apply that patch on top of your first one, rather
> used pristine sources ... in case that matters.

That's correct.

-- 
Colin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [linux-usb-devel] [PATCH] Re-power USB ports on wakeup

2005-03-16 Thread Michael Schmitz
> Another idea. Is it harmful to "re-power" already powered ports? For
> example like this:
>
> Signed-off-by: Colin Leroy <[EMAIL PROTECTED]>
> --- a/drivers/usb/host/ehci-hcd.c 2005-03-15 17:28:52.0 +0100
> +++ b/drivers/usb/host/ehci-hcd.c 2005-03-16 14:44:06.0 +0100
> @@ -773,14 +775,12 @@
>   /* here we "know" root ports should always stay powered;
>* but some controllers may lost all power.
>*/
> - if (powerup) {
> - ehci_dbg (ehci, "...powerup ports...\n");
> - for (port = HCS_N_PORTS (ehci->hcs_params); port > 0; )
> - (void) ehci_hub_control(hcd,
> - SetPortFeature, USB_PORT_FEAT_POWER,
> - port--, NULL, 0);
> - msleep(20);
> - }
> + ehci_dbg (ehci, "...powerup ports...\n");
> + for (port = HCS_N_PORTS (ehci->hcs_params); port > 0; )
> + (void) ehci_hub_control(hcd,
> + SetPortFeature, USB_PORT_FEAT_POWER,
> + port--, NULL, 0);
> + msleep(20);
>   }
>
>   return retval;

Doesn't work for me ... the device attached to the port is still powered
down after wakeup.

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [linux-usb-devel] [PATCH] Re-power USB ports on wakeup

2005-03-16 Thread Colin Leroy

On 16 Mar 2005 at 15h03, Michael Schmitz wrote:

Hi, 

> Doesn't work for me ... the device attached to the port is still
> powered down after wakeup.

Yes, me too, but at least it's seen if you reconnect it. For me at
least ?

-- 
Colin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [linux-usb-devel] [PATCH] Re-power USB ports on wakeup

2005-03-16 Thread Colin Leroy
On 15 Mar 2005 at 17h03, David Brownell wrote:

Hi, 

> This patch is self-evidently incorrect:  by definition, a suspended
> port maintains VBUS power.  Otherwise the device connected to the
> port will get disconnected, rather than suspended ... and it won't
> be able to issue wakeup events.  All suspending does is stop sending
> USB traffic down the port, notably SOF tokens; the device connected
> to the port then enters a low power mode, typically consuming at most
> 500uA from VBUS (vs typically 100mA when it's active/configured).

Another idea. Is it harmful to "re-power" already powered ports? For
example like this:

Signed-off-by: Colin Leroy <[EMAIL PROTECTED]>
--- a/drivers/usb/host/ehci-hcd.c   2005-03-15 17:28:52.0 +0100
+++ b/drivers/usb/host/ehci-hcd.c   2005-03-16 14:44:06.0 +0100
@@ -773,14 +775,12 @@
/* here we "know" root ports should always stay powered;
 * but some controllers may lost all power.
 */
-   if (powerup) {
-   ehci_dbg (ehci, "...powerup ports...\n");
-   for (port = HCS_N_PORTS (ehci->hcs_params); port > 0; )
-   (void) ehci_hub_control(hcd,
-   SetPortFeature, USB_PORT_FEAT_POWER,
-   port--, NULL, 0);
-   msleep(20);
-   }
+   ehci_dbg (ehci, "...powerup ports...\n");
+   for (port = HCS_N_PORTS (ehci->hcs_params); port > 0; )
+   (void) ehci_hub_control(hcd,
+   SetPortFeature, USB_PORT_FEAT_POWER,
+   port--, NULL, 0);
+   msleep(20);
}
 
return retval;


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Re: [linux-usb-devel] [PATCH] Re-power USB ports on wakeup

2005-03-15 Thread David Brownell
On Tuesday 15 March 2005 8:34 am, Colin Leroy wrote:
> Hi list,
> 
> Most of us have problems with USB unresponsive after one out of two
> wakeups. This patch fixes it for me; it looks like the port status
> isn't automatically updated (to ~PORT_POWER) when sleeping...
> 
> So this patch just unpowers the ports manually at the end of ehci_suspend.
> I don't know if it's really correct: Ben & Greg, I'd like your comments. if
> it's fine, can you push it upstream?

Well, neither Ben nor Greg maintain that driver, so I'll stick my
nose in instead.

This patch is self-evidently incorrect:  by definition, a suspended
port maintains VBUS power.  Otherwise the device connected to the
port will get disconnected, rather than suspended ... and it won't
be able to issue wakeup events.  All suspending does is stop sending
USB traffic down the port, notably SOF tokens; the device connected
to the port then enters a low power mode, typically consuming at most
500uA from VBUS (vs typically 100mA when it's active/configured).

There's something else going on here.  Please provide a more complete
problem description to linux-usb-devel.  For example, compile with
CONFIG_USB_DEBUG and provide the /sys/class/usb_host/usbN/registers
file on initial boot, then after a resume that worked, then after
one that didn't.

Is this S1, S2, or S3 suspend?  What are the relevant BIOS settings
for USB?  (BIOS modes are particularly relevant with "swsusp" paths,
which are actually reboot paths not suspend paths.)  Is this witth
CONFIG_USB_SUSPEND or not?

- Dave



> Signed-off-by: Colin Leroy <[EMAIL PROTECTED]>
> --- a/drivers/usb/host/ehci-hcd.c 2005-03-15 17:28:52.0 +0100
> +++ b/drivers/usb/host/ehci-hcd.c 2005-03-15 17:29:52.0 +0100
> @@ -701,6 +701,7 @@
>  static int ehci_suspend (struct usb_hcd *hcd, u32 state)
>  {
>   struct ehci_hcd *ehci = hcd_to_ehci (hcd);
> + unsigned port;
>  
>   if (time_before (jiffies, ehci->next_statechange))
>   msleep (100);
> @@ -716,6 +717,16 @@
>   // save (PCI) FLADJ in case of Vaux power loss
>   // ... we'd only use it to handle clock skew
>  
> + /* Suspend all ports manually (to get them powered at resume) */
> + for (port = HCS_N_PORTS (ehci->hcs_params); port > 0; ) {
> + u32 status;
> + port--;
> + status = readl (&ehci->regs->port_status [port]);
> + writel (status & ~PORT_POWER,
> + &ehci->regs->port_status [port]);
> + ehci_dbg(ehci, "port %d unpowered\n", port);
> + }
> +
>   return 0;
>  }
>  
> 
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]