Thank you. This indeed works.
The CONFIG_NONCOHERENT_IO option is set by default in config-shared.in when
one selects the db1500 board (among others). Does anyone have
recommendations as to how to modify config-shared.in to give others the
option of disabling this default behavior?
Possible places could be:
1. Add an override defaults sub-menu for the boards that support disabling
CONFIG_NONCOHERENT_IO.
2. Add a CONFIG_NONCOHERENT_IO item to the bottom of "Machine Selection"
menu. (There is already a "High Memory Support" option at the bottom of the
"machine Selection" menu.)
3. Add a CONFIG_NONCOHERENT_IO item to the "Override CPU options" sub-menu
(in the "CPU Selection" menu).
4....
Thanks, John
-----Original Message-----
From: Eric DeVolder [mailto:eric.devolder@amd.com]
Sent: Monday, October 18, 2004 12:28 PM
To: Yates, John
Subject: Re: Hi-Speed USB controller and au1500
I'm guessing that CONFIG_NONCOHERENT_IO is set which means that the
buffers used by USB are non-cached, and so the LL/SC combinations
performed by the USB stack to the structs in this non-cached area will
always fail. (Examine the MIPS LL/SC...only works to cached spaces...)
Depending upon which version of the Au1500 you have,
CONFIG_NONCOHERENT_IO was necessary due to coherency bugs. I believe
everything should be fixed with Au1500 AD so that CONFIG_NONCOHERENT_IO
isn't needed....
Eric
Yates, John wrote:
>Hello all,
>
>I am having a problem using a PCI USB 2.0 Hi-Speed controller (EHCI) with
>the dbau1500 eval kit with kernel 2.4.26. I have traced the problem down to
>a call to atomic_add() (in include/asm-mips/atomic.h) that uses assembly to
>access ll/sc registers of the mips architecture. If I override CPU options
>and disable ll/sc when configuring the kernel, everything works fine.
>However this causes the atomic_add() to use
>local_irq_save()/local_irq_restore(). I am assuming this will cause quite
a
>performance hit since atomic_add() gets called all over the place. I
should
>include that the ll/sc version of atomic_add() seems to work fine until the
>call from the usb infrastructure.
>
>Below is a code trail that leads to the call to atomic_add():
>
>
>hub.c: usb_hub_port_connect_change()
>usb.c: usb_set_address()
>usb.c: usb_control_msg()
>usb.c: usb_internal_control_msg()
>usb.c: usb_start_wait_urb()
>usb.c: usb_submit_urb()
>usb.c: submit_urb()
>hcd.c: hcd_submit_urb()
>host/ehci-hcd.c: ehci_urb_enqueue() (urb_enqueue
>function ptr)
>host/ehci-q.c: submit_async()
>host/ehci-q.c: qh_append_tds()
>host/ehci-mem.c: qh_get()
>atomic.h atomic_inc()
>atomic.h #define atomic_inc(v) atomic_add(1,(v)) <-
>uses ll/sc
>
>To reproduce my results:
>
>Plug in a Hi-Speed USB 2.0 controller into your pci slot and boot with a
usb
>ehci enabled kernel. Be sure to disable the non-pci usb host that is
>built-in to the au1500 when building the kernel. (I have tried two
>controllers (NEC and ALi) with identical results.)
>
>Plug a Hi-Speed device (thumb drive or external HD) into the controller.
>(system stops responding here)
>
>Low/Full speed devices work without a problem because they use the ohci or
>uhci drivers.
>
>
>Any help or direction will be greatly appreciated.
>
>John
>
>
>
>
|