[U-Boot-Users] reg ISP 1561 integration with u-boot1.1.6

["Markus Klotzbücher" <mk@denx.de>]

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: 
>> > 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!

Regards

Markus Klotzbuecher