Subject: Kunihiko Imais USB ohci driver doesn't work?

From: "Arjan Opmeer (EMN)" <[email-masked]>
Date: Mon, 28 Aug 2000 16:29:19 +0200

Hi,

I just tested Kunihiko Imais ohci driver for the SA1111 board that he
recently mentioned here on the list, but it doesn't seem to work.
I tested it against kernel 2.4.0-test6-rmk5-np2. It does detect the
ohci hub, but not the USB mouse I connected to the port.  The driver
also detects an overcurrent condition on the port, with, but also
without, the mouse attached.

Did anyone else have success trying this driver?

He also mentioned a possible SA1111 DMA bug which would prevent USB
from working altogether. Does someone know whether Neponset can
suffer from this bug?

Thanks,

Arjan

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: John G Dorsey <[email-masked]>
Date: Mon, 28 Aug 2000 11:16:43 -0400 (EDT)

> from working altogether. Does someone know whether Neponset can

The bug is with the SA-1111; it would appear in any implementation.

See the SA-1111 specification update (June 2000), errata #7.

(Disclaimer: I haven't looked into this yet, and wouldn't be surprised if
the following feature already exists in the kernel.)

One possible solution would be to add a constraints parameter to the
uncached buffer request service. There are at least two constraints that a
viable SA-1111 DMA buffer must meet:

  1. Must reside in whichever dynamic memory bank is wired for SA-1111
     access. (This is jumper-selectable on Neponset, for example.)

  2. If the buffer is placed above the 1MB mark in its respective bank, it
     must reside in a particular range / be addressable with a particular
     mask / &c.

This is necessary for my SAC patch as well, so if you'd like to run with
it, please keep in touch. =)

-jd

---

From: Brad Parker <[email-masked]>
Date: Tue, 29 Aug 2000 10:40:48 -0400

>from working altogether. Does someone know whether Neponset can

I've been working on this on and off for some time.  I have several
variants of the driver, none of which work correctly.

My current problem is that if I run the Intel diag problem first, and
then run linux, the usb controller magically springs to life and works
pretty well.  If I power cycle the h/w it stops working.  So,
obviously something is not being initialized correctly in linux.  I
thought it was the MBREQ/MBGNT gpio lines, but that didn't fix it.
I'm trying to figure out what is missing. The built in hub seems to
work but the usb controller itself seems half dead.  Perhaps a missing
clock, I'm not sure...

You can see this if you turn on SOF interrupts and notice that then
never occur.  Also, the frame # is bogus and never increments.  Root
hub change interrupts do occur.  If you run the diags and then reload
linux SOF interrupts start happening and you get sof interrupts...

The fixes which move the hcca, td's & ed's into 'consistent' memory
seem to help.  So does turning off the specilative ed removal
(EARLY_ED_UNLINK).  There is a bug, however, which looks like
dl_del_list is called twice when a device is removed; I'm not sure
what's causing it but the symptom is an ed is free'd twice.  The way
the new ed allocation code was written it reuses the hwINFO field and
this causes a crash in dl_del_list.  I believe simply moving the link
field will make the problem go away but I plan to track down the real
cause... (once I get the controller to work consistently from power up)

I have not seen any evidence of a dma problem, but one may well exist...

-brad