> Back last fall you mentioned something about needing to add a workaround
> to the UHCI driver's port reset code for VIA hardware.  It had to do with
> making sure the controller was suspended before doing the reset.  Can you
> remember the details?  Is it still needed?

Hi Alan, this work around is still needed with the latest 2.6 kernels (which is
not surprising since it is a hardware problem).  It is only needed for the VIA
hub with PCI id 1106, 3038.  Here is an extract from my original email
(http://sourceforge.net/mailarchive/message.php?msg_id=2307801):

> THE PROBLEM: plugging in a new device, with a device already
> plugged in, causes the existing device to malfunction, either by
> causing some urbs to fail (the case with my webcam) or all urbs
> to fail from then on (the case with my speedtouch modem).
> 
> THE SOLUTION: this problem does not occur with windows.  By
> observing reads and writes to the USB I/O registers I found
> that some VIA specific code (viausb.sys) does the following
> on a PORT_RESET:
> 
> Clears the run/stop bit in USBCMD.
> Writes the numbers 0 to 1023 consecutively to port 0x80.
> Sets the enter global suspend mode bit in USBCMD.
> Calls the standard port reset function in uhcd.sys.
> Clears the force global resume bit in USBCMD.
> Sets the force global resume and enter global suspend mode bits in USBCMD.
> Writes the numbers 0 to 1023 consecutively to port 0x80.
> Clears the force global resume and enter global suspend mode bits, and
>         sets the run/stop bit in USBCMD.
> 
> In essence: the host controller is suspended before the port reset, and
> woken up afterwards.

The following patch worked most of the time (not all of the time, presumably
because it was sometimes being un-suspended in the middle):

--- linux/drivers/usb/uhci.c.orig�������2002-10-25 22:54:25.000000000 +0200
+++ linux/drivers/usb/uhci.c����2002-10-26 00:20:11.000000000 +0200
@@ -2184,6 +2184,9 @@
������������������������SET_RH_PORTSTAT(USBPORTSC_SUSP);
������������������������OK(0);
����������������case RH_PORT_RESET:
+�����������������������if (uhci->rh.needs_suspend)
+�������������������������������suspend_hc (uhci);
+
������������������������SET_RH_PORTSTAT(USBPORTSC_PR);
������������������������mdelay(50);�����/* USB v1.1 7.1.7.3 */
������������������������uhci->rh.c_p_r[wIndex - 1] = 1;
@@ -2192,6 +2195,10 @@
������������������������SET_RH_PORTSTAT(USBPORTSC_PE);
������������������������mdelay(10);
������������������������SET_RH_PORTSTAT(0xa);
+
+�����������������������if (uhci->rh.needs_suspend)
+�������������������������������wakeup_hc (uhci);
+
������������������������OK(0);
����������������case RH_PORT_POWER:
������������������������OK(0); /* port power ** */
@@ -2817,6 +2824,11 @@
�
��������uhci->rh.numports = port;
�
+�������uhci->rh.needs_suspend = 0;
+
+�������if ((dev->vendor == 0x1106) && (dev->device == 0x3038))
+���������������uhci->rh.needs_suspend = 1;
+
��������uhci->bus->root_hub = uhci->rh.dev = usb_alloc_dev(NULL, uhci->bus);
��������if (!uhci->rh.dev) {
����������������err("unable to allocate root hub");
--- linux/drivers/usb/uhci.h.orig�������2002-10-25 22:54:20.000000000 +0200
+++ linux/drivers/usb/uhci.h����2002-10-25 22:55:57.000000000 +0200
@@ -274,6 +274,7 @@
��������int send;
��������int interval;
��������int numports;
+�������int needs_suspend;
��������int c_p_r[8];
��������struct timer_list rh_int_timer;
�};

I should mention (down here at the bottom of the email where hopefully no-one
from VIA is going to notice :) ), that I did quite a bit of rummaging around inside
VIA's "filter driver" for windows.  This driver (which you can get from their website)
basically contains a bunch of workarounds for various hardware problems.  It checks
your hardware against a list of PCI ids and turns on various hacks depending on what
you have.  I was only concerned about the hardware I had at that time, but it seems
clear to me that one way to get better support for VIA hardware would be to implement
those hacks in linux.  I used to have a nicely annotated decompilation at one point...

All the best,

Duncan.


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to