[U-Boot-Users] reg ISP 1561 integration with u-boot1.1.6
mk at denx.de
Thu Jan 11 11:17:02 CET 2007
Matthias Fuchs <matthias.fuchs at esd-electronics.com> writes:
> On Wednesday 10 January 2007 23:01, Markus Klotzbücher wrote:
>> Matthias Fuchs <matthias.fuchs at 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
>> > Here are my (first) questions:
>> > 1) 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.
>> > 2) 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!
More information about the U-Boot