[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-usb-devel
Subject:    [linux-usb-devel] Linux MIPS - bus_to_virt()/virt_to_bus() question
From:       Jun Sun <jsun () mvista ! com>
Date:       2000-09-27 17:30:23
[Download RAW message or body]


(This is the really strange.  I tried to send out this email yesterday,
but apparently it got lost.  Here is another try.  Please cc your reply
to my email account directly)

I wonder if anybody has been successful in running USB on a MIPS
machine.

I can get usbdevfs mounted and look under /proc/bus/usb/*.  However if I
try to hook a USB mouse, I get a timeout error.  See my earlier posting
below.

I first suspect the CPU did not get an interrupt.  Can someone confirm
if ohci driver gets the reply through an interrupt or not?  In this
case, the driver sends out "set address" control message, calls
schedule_timeout() and gets timeout in the end.

I also notice a lot of bus_to_virt()/virt_to_bus() conversions.  What is
the purpose of getting bus address?

Unlike i386, MIPS cache does not snoop on memory bus, and therefore it
does not maitain cache consistency automatically.  I am afraid if a
device gets the bus address and modifies the system RAM content, the
driver would still read stale data through the cached virtual addresses.

Is this a possible source of problem?

BTW, I have already fixed the pci_alloc_consistent() to return uncached
virtual addresses.  Apparently USB still passes cache virtual addresses
when it calls virt_to_bus().

Jun

=====================================================

[an earlier posting]

I am playing with USB in Linux kernel 2.4-test5 for MIPS.  The USB
subsystem basically started running.  I can mount usbdevfs and see the
devices and drivers.

However, if I plug in a USB mouse, I get a time error.  See below.

sh-2.03# usb.c: USB new device connect, assigned device number
2                usb_control/bulk_msg: timeout
usb-ohci.c: unlink URB timeout!
usb.c: USB device not accepting new address (error=-145)
usb.c: USB new device connect, assigned device number -1
usb.c: USB device not accepting new address (error=-12)
usb.c: USB disconnect on device
-1                                              


------

I looked into this problem.  It appears the usb code sends out a control
message and then wait on an interrupt reply.  Is this right?

If this is the case, then I probably have two possibilities : 

1) the control message is not sent out to the bus; or somehow not
received by the mouse
2) the mouse gets the control message and sends out a reply.  But the
interrupt was not routed correctly to the usb interrupt handler.

I can handle case 2).  Is there a way to verify if it is case 1).

Thanks.

Jun
_______________________________________________
linux-usb-devel mailing list
linux-usb-devel@lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/linux-usb-devel

[prev in list] [next in list] [prev in thread] [next in thread]