From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus =?iso-8859-1?Q?Klotzb=FCcher?= Date: Thu, 11 Jan 2007 11:17:02 +0100 Subject: [U-Boot-Users] reg ISP 1561 integration with u-boot1.1.6 In-Reply-To: <200701110950.08710.matthias.fuchs@esd-electronics.com> (Matthias Fuchs's message of "Thu, 11 Jan 2007 09:50:08 +0100") References: <4ac2955e0701040358u5699f021o163696f8cf70ba4a@mail.gmail.com> <200701101813.45863.matthias.fuchs@esd-electronics.com> <873b6izglg.fsf@denx.de> <200701110950.08710.matthias.fuchs@esd-electronics.com> Message-ID: <873b6hna01.fsf@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Matthias, Matthias Fuchs writes: > On Wednesday 10 January 2007 23:01, Markus Klotzb?cher wrote: >> Matthias Fuchs 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