
On Wednesday 10 January 2007 23:01, Markus Klotzbücher wrote:
Hi Matthias,
Matthias Fuchs matthias.fuchs@esd-electronics.com writes:
it's working. I modified the testing-USB branch to run against a PCI OHCI controller (Philips ISP1561) on the APC405 board (PowerPC PPC405GPr).
Enumeration and USB storage is working. I do not dare to say 'working well'.
The main changes concern endianess fixes. The former code only supports OHCI controller with the same endianess as the CPU. The other fix allows a offset
IIRC same problem with the 440EP and MPC5200, thats what the extra #ifdef in drivers/usb_ohci.c:103 is for.
These are different issues! usb_ohci.c uses readl and writel to access the controller's registers from the CPU (e.g. ohci.regs). The original code never swaps here. But a PCI OHCI controller on a PowerPC needs it. The mXX_swap macros are used to swap data fields in structures that are passed to the host controller indirectly.
to access the system RAM by the busmastering OHCI controller. I called this constant CFG_PCIRAM_BASE. But the name is a little bit confusion, isn't it?
Here are my (first) questions:
- What do I have to do in usb_board_stop() and usb_board_init_fail()?
My current code can only initialize the OHCI controller once. A 2nd 'usb start' does not find any devices.
You might not have to do anything, but maybe you'll need to do some board dependant cleanup for example. If not just leave them empty.
I thought that I have to do something here because stopping and restarting the usb stuff does not work at the moment on my system. Does it work on other systems? I do not have any target with onchip USB at the moment (...but comming soon :-). Did anyone test the merged code on a 440EP so far?
- I had to disable the 'return -1' statement for an unfinished urb in
sohci_submit_job(). Why isn't it finished?
I really don't know, I guess only you can answer this!
This answer helps me a lot. Why is the urb_finished stuff needed? I go better without :-)
Please do not blame me for the board dependent code still in the usb_ohci.c file. I will move it later.
Who else shall we blame then ;-) ?
So please blame be. I just though about leaving the generic PCI OHCI code in the file. When it has been made fully generic, it is not CPU or even board dependant. PCI device identification constants (better classcode) could be defined in the board config header and that's it for CONFIG_USB_OHCI_PCI.
Matthias