Hi,
> I needed to modify the drivers/usb/Makefile before it would compile
> in:
>
> diff -dbBurN linux-2.6.11-mm2/drivers/usb/Makefile
> linux-2.6.11-mm2-oscar4_usb/drivers/usb/Makefile
> --- linux-2.6.11-mm2/drivers/usb/Makefile 2005-04-25
> 15:29:50.000000000 -0500
> +++ linux-2.6.11-mm2-oscar4_usb/drivers/usb/Makefile 2005-04-25
> 16:51:24.000000000 -0500
> @@ -12,6 +12,7 @@
> obj-$(CONFIG_USB_OHCI_HCD) += host/
> obj-$(CONFIG_USB_UHCI_HCD) += host/
> obj-$(CONFIG_USB_SL811_HCD) += host/
> +obj-$(CONFIG_USB_ISP1362_HCD) += host/
> obj-$(CONFIG_ETRAX_USB_HOST) += host/
>
> obj-$(CONFIG_USB_ACM) += class/
>
Sorry, I missed this file when creating the patch.
> I had some trouble at first with HCuPINT_CLKRDY, but we solved that
> earlier in the list. I used the define 'USE_32BIT' to 0.
> Isn't the ISP1362 16-bit only? You can do 32-bit accesses on the
> 16-bit bus, but then you violate the (fussy) timing for sure! That
>
That depends on the capabilities of the processors memory
interface. At least on PXA you can program the memory timing so that
individual memory cycles don't require any software delays. The timing
specs are fully met even for 32 bit accesses.
> I had a bigger problem with the isp1362_[read,write]_fifo
> functions.. the writesl / writesw calls also completely violated
> the timing requirements. They caused back-to-back writes (and I'm
> assuming reads) with 20ns write-high-to-write-low time, but it has
> to be 110ns. I don't think this can be solved (atleast on my chip)
> with bus timing, so I rewrote these functions to be simpler. Since
>
If this is the case you probably also had to introduce software
delays in the isp1362_read_data16() and isp1362_write_data16()
functions.
And you probably also should have an OR gate in your hardware that
prevents the chips WE being asserted when CS is deasserted as
recommended in the ISP1362 Errata Document. Otherwise you possibly
cannot guarantee the 132ns idle time between successive assertions of
WE (no matter whether CS is asserted also).
Did you enable the CHIP_BUFFER_TEST to assert that your accesses to
the chip registers and buffers are working porperly?
> if (len >= 2) {
> RDBG("%s: Using readsw for %d words\n",
> __FUNCTION__, len >> 1);
> readsw(isp1362_hcd->data_reg, dp, len >> 1);
> @@ -736,6 +771,22 @@
> (u8)data, (u32)dp);
> *dp = (u8)data;
> }
> +#else
> + while ( len >= 2 )
> + {
> + data = isp1362_read_data16(isp1362_hcd);
> + *dp++ = (u8)data;
> + *dp++ = (u8)(data >> 8);
> + len -= 2;
> + }
> +
> + if ( len > 0 )
> + {
> + data = isp1362_read_data16(isp1362_hcd);
> + *dp++ = (u8)data;
> + len--;
> + }
> +#endif
> }
The '(len > 0)' case should be the same under all circumstances, so
the '#endif' could be placed right before it.
Lothar Wassmann
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
