forcing PS/2 USB emulation off

forcing PS/2 USB emulation off

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

To get the touchpad to work on my Compaq Presario r3004 notebook, in
addition to ALPS Touchpad patches by Dmitry Torokhov, I needed a patch
by Vojtech Pavlik that disabled PS/2 USB emulation early in the boot.
The BIOS didn't have an option to disable it, and, without it, PS/2
mouse detection wouldn't find anything and, if psmouse is built into
the kernel, as it happens to be the case for Fedora Core kernels,
there's no way to re-probe.

Having no idea of how safe/portable Vojtech's patch was, and assuming
some people might actually be relying on PS/2 USB emulation, I figured
it would be a good idea to not enable the code by default, requiring a
command-line option to do it instead.

The whole story is at
http://www.ic.unicamp.br/~oliva/snapshots/FC3-r3004/

Here's Vojtech's patch, updated to 2.6.9-rc4-bk2-ish (Fedora Core
kernel-2.6.8-1.624).  Is there a good reason to keep it out of the
base kernel?

Thanks to Vojtech and Dmitry for getting most of the work done, and
Arjan for pointing out the possibility of, and the existence of a
patch for, disabling USB emulation early in the boot.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: linux-2.6.9-nops2usbemul.patch --]
[-- Type: text/x-patch, Size: 3221 bytes --]

This patch introduces an option to force PS/2 USB emulation off.  Most
of the patch is by Vojtech Pavlik, I only updated it to 2.6.9ish
kernel and made it conditional on the nops2usbemul option.

--- a/drivers/pci/quirks.c	2004-10-17 04:24:28.000000000 -0300
+++ b/drivers/pci/quirks.c	2004-10-17 15:19:35.000000000 -0300
@@ -545,6 +545,76 @@
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID,		PCI_ANY_ID,			quirk_cardbus_legacy );
 
+#if defined(__i386__) || defined(__x86_64__)
+#define UHCI_USBLEGSUP 0xc0 /* legacy support */
+#define UHCI_USBCMD 0 /* command register */
+#define UHCI_USBINTR 4 /* interrupt register */
+#define UHCI_USBLEGSUP_DEFAULT 0x2000 /* only PIRQ enable set */
+#define UHCI_USBCMD_GRESET 0x0004 /* Global reset */
+
+#define OHCI_CONTROL 0x04
+#define OHCI_CMDSTATUS 0x08
+#define OHCI_INTRENABLE 0x10
+#define OHCI_OCR (1 << 3) /* ownership change request */
+#define OHCI_CTRL_IR (1 << 8) /* interrupt routing */
+#define OHCI_INTR_OC (1 << 30) /* ownership change */
+
+/* If the BIOS doesn't have an option to disable legacy USB emulation,
+   and such emulation actually gets in the way of proper probing of
+   PS/2 devices, the nops2usbemul option should help.  */
+static void __init quirk_usb_disable_smm_bios(struct pci_dev *pdev)
+{
+  extern char saved_command_line[];
+
+  if (!strstr(saved_command_line, "nops2usbemul"))
+    return;
+
+  if (pdev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x00)) { /* UHCI */
+    int i;
+    unsigned long base = 0;;
+
+    for (i = 0; i < PCI_ROM_RESOURCE; i++)
+      if ((pci_resource_flags(pdev, i) & IORESOURCE_IO)) {
+	base = pci_resource_start(pdev, i);
+	break;
+      }
+
+    if (!base)
+      return;
+
+    outw(0, base + UHCI_USBINTR);
+    outw(UHCI_USBCMD_GRESET, base + UHCI_USBCMD);
+    set_current_state(TASK_UNINTERRUPTIBLE);
+    schedule_timeout((HZ*50+999) / 1000);
+    outw(0, base + UHCI_USBCMD);
+    set_current_state(TASK_UNINTERRUPTIBLE);
+    schedule_timeout((HZ*10+999) / 1000);
+
+    pci_write_config_word(pdev, UHCI_USBLEGSUP, UHCI_USBLEGSUP_DEFAULT);
+  }
+
+  if (pdev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x10)) { /* OHCI */
+    char *base = ioremap_nocache(pci_resource_start(pdev, 0),
+				 pci_resource_len(pdev, 0));
+    if (base == NULL) return;
+
+    if (readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
+      int temp = 500; /* arbitrary: five seconds */
+      writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
+      writel(OHCI_OCR, base + OHCI_CMDSTATUS);
+      while (temp && readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
+	temp--;
+	set_current_state(TASK_UNINTERRUPTIBLE);
+	schedule_timeout( HZ / 100);
+      }
+    }
+    iounmap(base);
+  }
+}
+
+DECLARE_PCI_FIXUP_FINAL(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_disable_smm_bios);
+#endif
+
 /*
  * Following the PCI ordering rules is optional on the AMD762. I'm not
  * sure what the designers were smoking but let's not inhale...

--- a/Documentation/kernel-parameters.txt	2004-10-17 04:23:11.000000000 -0300
+++ b/Documentation/kernel-parameters.txt	2004-10-17 15:19:15.000000000 -0300
@@ -818,6 +818,8 @@
 
 	nousb		[USB] Disable the USB subsystem
 
+	nops2usbemul	[PCI,IA-32,X86_64] Disable PS/2 USB emulation
+
 	nowb		[ARM]
  
 	opl3=		[HW,OSS]

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]


-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: forcing PS/2 USB emulation off

[Greg KH]

On Sun, Oct 17, 2004 at 04:34:35PM -0300, Alexandre Oliva wrote:
> 
> Here's Vojtech's patch, updated to 2.6.9-rc4-bk2-ish (Fedora Core
> kernel-2.6.8-1.624).  Is there a good reason to keep it out of the
> base kernel?

It's already in the -mm kernels, and will be sent to Linus after 2.6.9
is out.  If you could test that kernel and verify that it works for this
situation, I would appreciate it.

thanks,

greg k-h

Re: forcing PS/2 USB emulation off

[Alexandre Oliva]

On Oct 17, 2004, Greg KH <greg@kroah.com> wrote:

> On Sun, Oct 17, 2004 at 04:34:35PM -0300, Alexandre Oliva wrote:
>> 
>> Here's Vojtech's patch, updated to 2.6.9-rc4-bk2-ish (Fedora Core
>> kernel-2.6.8-1.624).  Is there a good reason to keep it out of the
>> base kernel?

> It's already in the -mm kernels, and will be sent to Linus after 2.6.9
> is out.  If you could test that kernel and verify that it works for this
> situation, I would appreciate it.

Cool!  It works, as far as enabling the kernel to see there's a mouse
there.  Unfortunately, it doesn't recognize it as an ALPS touchpad,
just as a regular PS/2 mouse.  I haven't tried to figure out why yet.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: forcing PS/2 USB emulation off

[Alan Cox]

On Sul, 2004-10-17 at 23:57, Greg KH wrote:
> It's already in the -mm kernels, and will be sent to Linus after 2.6.9
> is out.  If you could test that kernel and verify that it works for this
> situation, I would appreciate it.

It would be ok if someone bothered to copy the USB core code (or better
yet call into it) but the patch in the -mm tree doesn't know about the
zillion OHCI controller bugs, and doesn't know about the suprise
interrupt on switch from BIOS->host you sometimes see.

The real fix is to link the USB code early enough to run before the PC
keyboard code. I've had this confirmed by BIOS folks as well.

But *please* if you are going to copy USB mode switching code copy
working code including all the nasty gungy details!

Re: forcing PS/2 USB emulation off

[Dmitry Torokhov]

On Sunday 17 October 2004 02:34 pm, Alexandre Oliva wrote:
> To get the touchpad to work on my Compaq Presario r3004 notebook, in
> addition to ALPS Touchpad patches by Dmitry Torokhov, I needed a patch
> by Vojtech Pavlik that disabled PS/2 USB emulation early in the boot.
> The BIOS didn't have an option to disable it, and, without it, PS/2
> mouse detection wouldn't find anything and, if psmouse is built into
> the kernel, as it happens to be the case for Fedora Core kernels,
> there's no way to re-probe.

Actually, now there is. Starting with 2.6.9 it is possible to force
either rescan or reconnect for devices connected to serio ports:

	echo -n "reconnect"  > /sys/bus/serio/devices/serio1/driver

should cause re-probe. Just FYI. As Greg said the USB handoff patch
is in -mm three and should take care of most of the issues.

BTW, I think that handoff should be activated by default. I am lurking
in Gentoo forums and there are coultless people having problems with
their mice/touchpads detected properly unless they load their USB drivers
first.

-- 
Dmitry

Re: forcing PS/2 USB emulation off

[Greg KH]

On Sun, Oct 17, 2004 at 10:48:16PM -0500, Dmitry Torokhov wrote:
> 
> BTW, I think that handoff should be activated by default. I am lurking
> in Gentoo forums and there are coultless people having problems with
> their mice/touchpads detected properly unless they load their USB drivers
> first.

I'm a little leary of changing the way the kernel grabs the USB hardware
from the way we have been doing it for the past 6 years.  So by
providing the option for people who have broken machines like these, we
will let them work properly, and it should not affect any of the zillion
other people out there with working hardware.

Or, if we can determine a specific model of hardware that really needs
this option enabled, we can do that automatically.  If you look at the
patch, we do that for some specific IBM machines for this very reason.

Is there any consistancy with the type of hardware that you see being
reported for this issue?

thanks,

greg k-h

Re: forcing PS/2 USB emulation off

[Alexandre Oliva]

On Oct 18, 2004, Greg KH <greg@kroah.com> wrote:

> Is there any consistancy with the type of hardware that you see being
> reported for this issue?

I've googled around and found a lot of reports of such issues on the
HP Presario 3000Z series, as well as some other HP notebook series
(nx5000?) that (kind of :-) supports Athlon64 processors.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: forcing PS/2 USB emulation off

[Alan Cox]

On Llu, 2004-10-18 at 19:31, Alexandre Oliva wrote:
> > Is there any consistancy with the type of hardware that you see being
> > reported for this issue?
> 
> I've googled around and found a lot of reports of such issues on the
> HP Presario 3000Z series, as well as some other HP notebook series
> (nx5000?) that (kind of :-) supports Athlon64 processors.

The main problem ones in Red Hat bugzilla are anythign E7xxx based (this
seems to be the department of lost causes), but which has a "fix" akin
to Greg's for UHCI only and the HP (and other eMachines identical)
laptops which is fixed by BIOS updating to the newer model (warranty and
risk your own...)

Alan

Re: forcing PS/2 USB emulation off

[Alexandre Oliva]

On Oct 20, 2004, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Llu, 2004-10-18 at 19:31, Alexandre Oliva wrote:
>> > Is there any consistancy with the type of hardware that you see being
>> > reported for this issue?
>> 
>> I've googled around and found a lot of reports of such issues on the
>> HP Presario 3000Z series, as well as some other HP notebook series
>> (nx5000?) that (kind of :-) supports Athlon64 processors.

> The main problem ones in Red Hat bugzilla are anythign E7xxx based (this
> seems to be the department of lost causes), but which has a "fix" akin
> to Greg's for UHCI only and the HP (and other eMachines identical)
> laptops which is fixed by BIOS updating to the newer model (warranty and
> risk your own...)

Updating the BIOS doesn't actually fix my (Presario r3004).  The
Errata #93 message become less common, but aren't completely gone, and
the touchpad isn't recognized either way.  FWIW, a BIOS upgrade to my
wife's box (a supposed-to-be-identical notebook) makes the clock 3x
too fast.  So upgrading the BIOS, even if it fixed the USB hand-off
problem, would make the box unusable for this other problem.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: forcing PS/2 USB emulation off

[Vojtech Pavlik]

On Mon, Oct 18, 2004 at 09:45:39AM -0700, Greg KH wrote:

> I'm a little leary of changing the way the kernel grabs the USB hardware
> from the way we have been doing it for the past 6 years.  So by
> providing the option for people who have broken machines like these, we
> will let them work properly, and it should not affect any of the zillion
> other people out there with working hardware.
> 
> Or, if we can determine a specific model of hardware that really needs
> this option enabled, we can do that automatically.  If you look at the
> patch, we do that for some specific IBM machines for this very reason.
> 
> Is there any consistancy with the type of hardware that you see being
> reported for this issue?
 
Like 30% of all notebooks? ;) They do boot without the USB handoff, the
PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
detection is possible due to the BIOS interference.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: forcing PS/2 USB emulation off

[Dmitry Torokhov]

On Tuesday 19 October 2004 01:30 am, Vojtech Pavlik wrote:
> On Mon, Oct 18, 2004 at 09:45:39AM -0700, Greg KH wrote:
> 
> > I'm a little leary of changing the way the kernel grabs the USB hardware
> > from the way we have been doing it for the past 6 years.  So by
> > providing the option for people who have broken machines like these, we
> > will let them work properly, and it should not affect any of the zillion
> > other people out there with working hardware.
> > 
> > Or, if we can determine a specific model of hardware that really needs
> > this option enabled, we can do that automatically.  If you look at the
> > patch, we do that for some specific IBM machines for this very reason.
> > 
> > Is there any consistancy with the type of hardware that you see being
> > reported for this issue?
>  
> Like 30% of all notebooks? ;) They do boot without the USB handoff, the
> PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
> detection is possible due to the BIOS interference.
> 

I will send a list of examples tomorrow but so far it includes IBM
Thinkpads, Dells, Sonys, Compaqs, Fujitsus, Toshibas, Supermicro-based
boards and nonames. 

We risk growing that DMI list pretty big ;)

-- 
Dmitry

Re: forcing PS/2 USB emulation off

[Dmitry Torokhov]

On Tuesday 19 October 2004 01:48 am, Dmitry Torokhov wrote:
> On Tuesday 19 October 2004 01:30 am, Vojtech Pavlik wrote:
> > On Mon, Oct 18, 2004 at 09:45:39AM -0700, Greg KH wrote:
> > 
> > > I'm a little leary of changing the way the kernel grabs the USB hardware
> > > from the way we have been doing it for the past 6 years.  So by
> > > providing the option for people who have broken machines like these, we
> > > will let them work properly, and it should not affect any of the zillion
> > > other people out there with working hardware.
> > > 
> > > Or, if we can determine a specific model of hardware that really needs
> > > this option enabled, we can do that automatically.  If you look at the
> > > patch, we do that for some specific IBM machines for this very reason.
> > > 
> > > Is there any consistancy with the type of hardware that you see being
> > > reported for this issue?
> >  
> > Like 30% of all notebooks? ;) They do boot without the USB handoff, the
> > PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
> > detection is possible due to the BIOS interference.
> > 
> 
> I will send a list of examples tomorrow but so far it includes IBM
> Thinkpads, Dells, Sonys, Compaqs, Fujitsus, Toshibas, Supermicro-based
> boards and nonames. 
> 
> We risk growing that DMI list pretty big ;)
> 

OK, here are the different cases that I was able to find:

http://www.ussg.iu.edu/hypermail/linux/kernel/0401.3/0484.html
Sony Vaio GR7/K - PhoenixBIOS 4.0 Release 6.0 - R0208C0.
... Anyway I solved this problem loading uhci_hcd + hid before
psmouse in /etc/modules

http://mike2k.de/cgi-bin/t40.cgi
Thinkpad T40p
... When booting a 2.6.2 kernel with apm enabled, the synaptics
touchpad is not recognized by the Kernel if a USB Mouse is plugged
in at boottime and thus only the usb mouse is usable.

http://lkml.org/lkml/2004/7/6/32
Unknown
> > input: SynPS/2 Synaptics TouchPad on isa0060/serio1
> 
> Try making psmouse modular as well and load it _after_ all USB stuff is
> loaded - you may be having issues with USB Legacy emulation.

Ok, this has fixed it. At least the other way round: compiling in the
basic usb stuff and psmouse did the trick in -mm6, too.

http://www.redhat.com/archives/fedora-test-list/2004-June/msg00168.html
Supermicro boards seem to have problems
... As far as people can currently tell that is down to supermicro bios bugs.
Compiling the HCD in hides this by turning off USB legacy emulation before
the bios can get involved - so the kernel ends up talking to the real
PS/2 hardware.

http://seclists.org/lists/linux-kernel/2004/Mar/0348.html
Model: unknown
> On Tuesday 02 March 2004 05:03 am, Emiliano 'AlberT' Gabrielli wrote: 
> > Hi all, 
> > I have a strange behaviour on my laptop: touchpad is not probed by the 
> > kernel (2.6.3) *if* and only if at boot time the USB mouse is plugged in 
> > ... 
> 
> It is usually caused by USB Legacy emulation - BIOS makes a USB mouse look 
> like a PS/2 mouse. Look in your BIOS setup if there is an option to turn it 
> off. Otherwise you will have to load ehci/uhci_hcd and hid modules before 
> loading psmouse module as loading full-blown USB support disables that 
> emulation. 
perfect, now all works fine 
thank you so much

http://forums.gentoo.org/viewtopic.php?t=169145
sony vaio PCG-R600HFPD
(handoff did not seem to help in this case though)

http://forums.gentoo.org/viewtopic.php?t=178056&highlight=
Vaio PCG-GRX650.
Result unknown

http://forums.gentoo.org/viewtopic.php?t=215876&highlight=
Model: unknown
... it works like a charm when compiled psmouse as a module.

http://forums.gentoo.org/viewtopic.php?t=223819&highlight=
Premio 6010N (czech made in ATComputers)

http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/1930.html
Fujitsu S7010
May help.

http://www.fedoraforum.org/forum/archive/index.php/t-21097.html
... I have a Toshiba A70, and needed to disable 'legacy USB support'
in the bios. As soon as I did that, the touchpad (minus wheel
functionality) began working.

http://forums.gentoo.org/viewtopic.php?p=1665865#1665865
Keyboard does not work unless usb-handoff is used.

http://bugme.osdl.org/show_bug.cgi?id=1882
IBM T40

There is also issue of IBMs reporting presence of an active multiplexing
controller unless USB is activated before i8042.

J.A. Magallon has complained that his mouse is jerky unless legacy
emulation is disabled.

Note that only staring with 2.6 PS/2 initialization happens before
USB because before GPM/X was doing it way after USB has been activated
event if USB was compiled as modules.

-- 
Dmitry

Re: forcing PS/2 USB emulation off

[Alan Cox]

On Maw, 2004-10-19 at 07:30, Vojtech Pavlik wrote:
> Like 30% of all notebooks? ;) They do boot without the USB handoff, the
> PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
> detection is possible due to the BIOS interference.

I started in favour of avoiding always doing the handoff, but now I'm
convinced handoff should be the default. 

Alan

Re: forcing PS/2 USB emulation off

[Vojtech Pavlik]

On Wed, Oct 20, 2004 at 08:56:43PM +0100, Alan Cox wrote:

> On Maw, 2004-10-19 at 07:30, Vojtech Pavlik wrote:
> > Like 30% of all notebooks? ;) They do boot without the USB handoff, the
> > PS/2 mouse works, but only as a PS/2 mouse, no extended capabilities
> > detection is possible due to the BIOS interference.
> 
> I started in favour of avoiding always doing the handoff, but now I'm
> convinced handoff should be the default. 

And I would be fine to move the atkbd/psmouse initialization down in the
Makefiles so that USB gets initialized first - but what do we do about
the modular case? 

I do agree that we should have only one copy of the handoff code,
regardless of where it's living.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

Re: forcing PS/2 USB emulation off

[Tim Hockin]

On Thu, Oct 21, 2004 at 08:21:03AM +0200, Vojtech Pavlik wrote:
> And I would be fine to move the atkbd/psmouse initialization down in the
> Makefiles so that USB gets initialized first - but what do we do about
> the modular case? 
> 
> I do agree that we should have only one copy of the handoff code,
> regardless of where it's living.

I just wanted to pipe up and say that I'm being hit by this same bug this
week.  Except in my case, the system sometimes blows up and reboots during
kb probing (2.4.x kernel).  I've not tried 2.6 on this box yet.

I don't know what the right answer is yet, but it sure is frustrating.

RE: forcing PS/2 USB emulation off

[Aleksey Gorelov]

 
>-----Original Message-----
>From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] 
>Sent: Wednesday, October 20, 2004 12:54 PM
>To: Greg KH
>Cc: Alexandre Oliva; Linux Kernel Mailing List; Vojtech 
>Pavlik; Dmitry Torokhov
>Subject: Re: forcing PS/2 USB emulation off
>
>On Sul, 2004-10-17 at 23:57, Greg KH wrote:
>> It's already in the -mm kernels, and will be sent to Linus 
>after 2.6.9
>> is out.  If you could test that kernel and verify that it 
>works for this
>> situation, I would appreciate it.
>
>It would be ok if someone bothered to copy the USB core code (or better
>yet call into it) but the patch in the -mm tree doesn't know about the
>zillion OHCI controller bugs, and doesn't know about the suprise
>interrupt on switch from BIOS->host you sometimes see.

Isn't this interrupt disabled at that point, and status are cleared
right
after handoff ? Have you actually been able to see a problem with such 
an interrupt with this patch applied ?

>
>The real fix is to link the USB code early enough to run before the PC
>keyboard code. I've had this confirmed by BIOS folks as well.

That would be nice, but -mm patch covers not only keyboard/mouse issues,
but lockups as well. Unfortunately, to work around this, handoff should 
happen not only pretty early, but before you start enabling shared (with
USB)
interrupts for your cards.

Aleks.

RE: forcing PS/2 USB emulation off

[Alan Cox]

On Iau, 2004-10-21 at 00:22, Aleksey Gorelov wrote:
> Isn't this interrupt disabled at that point, and status are cleared
> right
> after handoff ? Have you actually been able to see a problem with such 
> an interrupt with this patch applied ?

I've seen one Nvidia case where flipping the USB over caused an
immediate IRQ on that line.

Re: forcing PS/2 USB emulation off

[Alexandre Oliva]

On Oct 20, 2004, "Aleksey Gorelov" <Aleksey_Gorelov@Phoenix.com> wrote:

>> It would be ok if someone bothered to copy the USB core code (or better
>> yet call into it) but the patch in the -mm tree doesn't know about the
>> zillion OHCI controller bugs, and doesn't know about the suprise
>> interrupt on switch from BIOS->host you sometimes see.

> Isn't this interrupt disabled at that point, and status are cleared
> right after handoff?

I've no idea, but as soon as I started using the USB handoff patch,
I've consistently got the K8 Errata #93 message as the first message
(or maybe one of the first few) I get on boot.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: forcing PS/2 USB emulation off

[Pete Zaitcev]

On 17 Oct 2004 16:34:35 -0300, Alexandre Oliva <aoliva@redhat.com> wrote:

> Here's Vojtech's patch, updated to 2.6.9-rc4-bk2-ish (Fedora Core
> kernel-2.6.8-1.624).  Is there a good reason to keep it out of the
> base kernel?

Looks like something pre-historic. But I cannot blame you for not paying
attention to little elves working on patches, because there was no way
to do it. If hackers always sent their patches to mailing lists instead
of maintainers directly, it might have saved hacking on obsolete patches
and made world a better place, I reckon. Attached is the latest I have,
but with all the activity under the carpet I cannot be sure that one is
the head of the development either.

Anyone having a newer version please speak up.

-- Pete

Subject: [PATCH] early usb handoff for 2.6
From: john stultz <johnstul@us.ibm.com>
To: greg@kroah.com
Cc: zaitcev@redhat.com, Aleksey_Gorelov@Phoenix.com, vojtech@suse.cz
Message-Id: <1094778721.29408.178.camel@cog.beaverton.ibm.com>
Date: Thu, 09 Sep 2004 18:12:02 -0700

Greg,
        Apparently there is an issue w/ the IBM x440/x445's BIOS's USB
Legacy support. Due to the delay in issuing SMI's across the IOAPICs,
its possible for I/O to ports 60/64 to cause register corruption. 

The solution is to disable the BIOS's USB Legacy support early in
boot(via PCI quirks) for x440/x445 systems. 

Originally written by Vojtech against SuSE's tree, this patch was then
updated to disable EHCI by Aleksey Gorelov, cleaned up by Pete Zaitcev
for 2.4 and finally tweaked and updated against 2.6 by me.

I've lightly tested this version of the patch, but it differs little
from what Aleksey, Pete and I have been testing for 2.4. 

Please consider for inclusion into your tree for further testing?

thanks
-john

linux-2.6.9-rc1_usb-handoff_A3.patch
====================================
diff -Nru a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt	2004-09-09 17:59:01 -07:00
+++ b/Documentation/kernel-parameters.txt	2004-09-09 17:59:01 -07:00
@@ -1270,6 +1270,8 @@
 
 	uart6850=	[HW,OSS]
 			Format: <io>,<irq>
+
+	usb-handoff	[HW] Enable early USB BIOS -> OS handoff
  
 	video=		[FB] Frame buffer configuration
 			See Documentation/fb/modedb.txt.
diff -Nru a/drivers/pci/quirks.c b/drivers/pci/quirks.c
--- a/drivers/pci/quirks.c	2004-09-09 17:59:01 -07:00
+++ b/drivers/pci/quirks.c	2004-09-09 17:59:01 -07:00
@@ -826,6 +826,236 @@
 	pci_read_config_byte(dev, 0x77, &val);
 }
 
+
+#define UHCI_USBLEGSUP		0xc0		/* legacy support */
+#define UHCI_USBCMD		0		/* command register */
+#define UHCI_USBSTS		2		/* status register */
+#define UHCI_USBINTR		4		/* interrupt register */
+#define UHCI_USBLEGSUP_DEFAULT	0x2000		/* only PIRQ enable set */
+#define UHCI_USBCMD_RUN		(1 << 0)	/* RUN/STOP bit */
+#define UHCI_USBCMD_GRESET	(1 << 2)	/* Global reset */
+#define UHCI_USBCMD_CONFIGURE	(1 << 6)	/* config semaphore */
+#define UHCI_USBSTS_HALTED	(1 << 5)	/* HCHalted bit */
+
+#define OHCI_CONTROL		0x04
+#define OHCI_CMDSTATUS		0x08
+#define OHCI_INTRSTATUS		0x0c
+#define OHCI_INTRENABLE		0x10
+#define OHCI_INTRDISABLE	0x14
+#define OHCI_OCR		(1 << 3)	/* ownership change request */
+#define OHCI_CTRL_IR		(1 << 8)	/* interrupt routing */
+#define OHCI_INTR_OC		(1 << 30)	/* ownership change */
+
+#define EHCI_HCC_PARAMS		0x08		/* extended capabilities */
+#define EHCI_USBCMD		0		/* command register */
+#define EHCI_USBCMD_RUN		(1 << 0)	/* RUN/STOP bit */
+#define EHCI_USBSTS		4		/* status register */
+#define EHCI_USBSTS_HALTED	(1 << 12)	/* HCHalted bit */
+#define EHCI_USBINTR		8		/* interrupt register */
+#define EHCI_USBLEGSUP		0		/* legacy support register */
+#define EHCI_USBLEGSUP_BIOS	(1 << 16)	/* BIOS semaphore */
+#define EHCI_USBLEGSUP_OS	(1 << 24)	/* OS semaphore */
+#define EHCI_USBLEGCTLSTS	4		/* legacy control/status */
+#define EHCI_USBLEGCTLSTS_SOOE	(1 << 13)	/* SMI on ownership change */
+
+int usb_early_handoff __initdata = 0;
+static int __init usb_handoff_early(char *str)
+{
+	usb_early_handoff = 1;
+	return 0;
+}
+__setup("usb-handoff", usb_handoff_early);
+
+static void __init quirk_usb_handoff_uhci(struct pci_dev *pdev)
+{
+	unsigned long base = 0;
+	int wait_time, delta;
+	u16 val, sts;
+	int i;
+
+	for (i = 0; i < PCI_ROM_RESOURCE; i++)
+		if ((pci_resource_flags(pdev, i) & IORESOURCE_IO)) {
+			base = pci_resource_start(pdev, i);
+			break;
+		}
+
+	if (!base)
+		return;
+
+	/*
+	 * stop controller
+	 */
+	sts = inw(base + UHCI_USBSTS);
+	val = inw(base + UHCI_USBCMD);
+	val &= ~(u16)(UHCI_USBCMD_RUN | UHCI_USBCMD_CONFIGURE);
+	outw(val, base + UHCI_USBCMD);
+
+	/*
+	 * wait while it stops if it was running
+	 */
+	if ((sts & UHCI_USBSTS_HALTED) == 0)
+	{
+		wait_time = 1000;
+		delta = 100;
+
+		do {
+			outw(0x1f, base + UHCI_USBSTS);
+			udelay(delta);
+			wait_time -= delta;
+			val = inw(base + UHCI_USBSTS);
+			if (val & UHCI_USBSTS_HALTED)
+				break;
+		} while (wait_time > 0);
+	}
+
+	/*
+	 * disable interrupts & legacy support
+	 */
+	outw(0, base + UHCI_USBINTR);
+	outw(0x1f, base + UHCI_USBSTS);
+	pci_read_config_word(pdev, UHCI_USBLEGSUP, &val);
+	if (val & 0xbf) 
+		pci_write_config_word(pdev, UHCI_USBLEGSUP, UHCI_USBLEGSUP_DEFAULT);
+		
+}
+
+static void __init quirk_usb_handoff_ohci(struct pci_dev *pdev)
+{
+	char *base;
+	int wait_time;
+
+	base = ioremap_nocache(pci_resource_start(pdev, 0),
+				     pci_resource_len(pdev, 0));
+	if (base == NULL) return;
+
+	if (readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
+		wait_time = 500; /* 0.5 seconds */
+		writel(OHCI_INTR_OC, base + OHCI_INTRENABLE);
+		writel(OHCI_OCR, base + OHCI_CMDSTATUS);
+		while (wait_time > 0 && 
+				readl(base + OHCI_CONTROL) & OHCI_CTRL_IR) {
+			wait_time -= 10;
+			set_current_state(TASK_UNINTERRUPTIBLE);
+			schedule_timeout((HZ*10 + 999) / 1000);
+		}
+	}
+
+	/*
+	 * disable interrupts
+	 */
+	writel(~(u32)0, base + OHCI_INTRDISABLE);
+	writel(~(u32)0, base + OHCI_INTRSTATUS);
+
+	iounmap(base);
+}
+
+static void __init quirk_usb_disable_ehci(struct pci_dev *pdev)
+{
+	int wait_time, delta;
+	char *base, *op_reg_base;
+	u32 hcc_params, val, temp;
+	u8 cap_length;
+
+	base = ioremap_nocache(pci_resource_start(pdev, 0),
+				pci_resource_len(pdev, 0));
+	if (base == NULL) return;
+
+	cap_length = readb(base);
+	op_reg_base = base + cap_length;
+	hcc_params = readl(base + EHCI_HCC_PARAMS);
+	hcc_params = (hcc_params >> 8) & 0xff;
+	if (hcc_params) {
+		pci_read_config_dword(pdev, 
+					hcc_params + EHCI_USBLEGSUP,
+					&val);
+		if (((val & 0xff) == 1) && (val & EHCI_USBLEGSUP_BIOS)) {
+			/*
+			 * Ok, BIOS is in smm mode, try to hand off...
+			 */
+			pci_read_config_dword(pdev,
+						hcc_params + EHCI_USBLEGCTLSTS,
+						&temp);
+			pci_write_config_dword(pdev,
+						hcc_params + EHCI_USBLEGCTLSTS,
+						temp | EHCI_USBLEGCTLSTS_SOOE);
+			val |= EHCI_USBLEGSUP_OS;
+			pci_write_config_dword(pdev, 
+						hcc_params + EHCI_USBLEGSUP, 
+						val);
+
+			wait_time = 500;
+			do {
+				set_current_state(TASK_UNINTERRUPTIBLE);
+				schedule_timeout((HZ*10+999)/1000);
+				wait_time -= 10;
+				pci_read_config_dword(pdev,
+						hcc_params + EHCI_USBLEGSUP,
+						&val);
+			} while (wait_time && (val & EHCI_USBLEGSUP_BIOS));
+			if (!wait_time) {
+				/*
+				 * well, possibly buggy BIOS...
+				 */
+				printk(KERN_WARNING "EHCI early BIOS handoff "
+						"failed (BIOS bug ?)\n");
+				pci_write_config_dword(pdev,
+						hcc_params + EHCI_USBLEGSUP,
+						EHCI_USBLEGSUP_OS);
+				pci_write_config_dword(pdev,
+						hcc_params + EHCI_USBLEGCTLSTS,
+						0);
+			}
+		}
+	}
+
+	/*
+	 * halt EHCI & disable its interrupts in any case
+	 */
+	val = readl(op_reg_base + EHCI_USBSTS);
+	if ((val & EHCI_USBSTS_HALTED) == 0) {
+		val = readl(op_reg_base + EHCI_USBCMD);
+		val &= ~EHCI_USBCMD_RUN;
+		writel(val, op_reg_base + EHCI_USBCMD);
+
+		wait_time = 2000;
+		delta = 100;
+		do {
+			writel(0x3f, op_reg_base + EHCI_USBSTS);
+			udelay(delta);
+			wait_time -= delta;
+			val = readl(op_reg_base + EHCI_USBSTS);
+			if ((val == ~(u32)0) || (val & EHCI_USBSTS_HALTED)) {
+				break;
+			}
+		} while (wait_time > 0);
+	}
+	writel(0, op_reg_base + EHCI_USBINTR);
+	writel(0x3f, op_reg_base + EHCI_USBSTS);
+
+	iounmap(base);
+
+	return;
+}
+
+
+
+static void __init quirk_usb_early_handoff(struct pci_dev *pdev)
+{
+	if (!usb_early_handoff)
+		return;
+
+	if (pdev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x00)) { /* UHCI */
+		quirk_usb_handoff_uhci(pdev);
+	} else if (pdev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x10)) { /* OHCI */
+		quirk_usb_handoff_ohci(pdev);
+	} else if (pdev->class == ((PCI_CLASS_SERIAL_USB << 8) | 0x20)) { /* EHCI */
+		quirk_usb_disable_ehci(pdev);
+	}
+
+	return;
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, quirk_usb_early_handoff);
+
 /*
  * ... This is further complicated by the fact that some SiS96x south
  * bridges pretend to be 85C503/5513 instead.  In that case see if we
diff -Nru a/include/asm-i386/mach-summit/mach_mpparse.h b/include/asm-i386/mach-summit/mach_mpparse.h
--- a/include/asm-i386/mach-summit/mach_mpparse.h	2004-09-09 17:59:01 -07:00
+++ b/include/asm-i386/mach-summit/mach_mpparse.h	2004-09-09 17:59:01 -07:00
@@ -22,6 +22,7 @@
 {
 }
 
+extern int usb_early_handoff;
 static inline int mps_oem_check(struct mp_config_table *mpc, char *oem, 
 		char *productid)
 {
@@ -31,6 +32,7 @@
 			 || !strncmp(productid, "RUTHLESS SMP", 12))){
 		use_cyclone = 1; /*enable cyclone-timer*/
 		setup_summit();
+		usb_early_handoff = 1;
 		return 1;
 	}
 	return 0;
@@ -44,6 +46,7 @@
 	     || !strncmp(oem_table_id, "EXA", 3))){
 		use_cyclone = 1; /*enable cyclone-timer*/
 		setup_summit();
+		usb_early_handoff = 1;
 		return 1;
 	}
 	return 0;

RE: forcing PS/2 USB emulation off

[Aleksey Gorelov]

>-----Original Message-----
>From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] 
>Sent: Thursday, October 21, 2004 2:35 AM
>To: Aleksey Gorelov
>Cc: Greg KH; Alexandre Oliva; Linux Kernel Mailing List; 
>Vojtech Pavlik; Dmitry Torokhov
>Subject: RE: forcing PS/2 USB emulation off
>
>On Iau, 2004-10-21 at 00:22, Aleksey Gorelov wrote:
>> Isn't this interrupt disabled at that point, and status are cleared
>> right
>> after handoff ? Have you actually been able to see a problem 
>with such 
>> an interrupt with this patch applied ?
>
>I've seen one Nvidia case where flipping the USB over caused an
>immediate IRQ on that line.
>

I expect it to be disabled at controller level at the time patch works.
Probably, something enabled it before quirk in Nvidia case...

Aleks.