Hi Matthias,
Matthias Fuchs matthias.fuchs@esd-electronics.com writes:
On Wednesday 10 January 2007 23:01, Markus Klotzbücher wrote:
Matthias Fuchs matthias.fuchs@esd-electronics.com writes:
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.
I get it. So in the end we have four cases: byte swapping register access or not _and_ byte swapping data or not. Right? Doesn't sound too complicated.
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?
Yes, I did test it successfully.
- 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 :-)
Did you see the comment in usb_ohci.c:1355? It's to make sure a transaction has completed before a new one is started. I'm not insisting to keep this if it's useless, but we need to prove that first. Obviously it was put there for some reason.
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.
That would be great!
Regards
Markus Klotzbuecher