Hi Peter, thank you for your answer. It was interesting to learn you have worked around the big endian problem by rewiring the data bus. I guess this means that the lea32_to_cpu() and simular calls would not be safe to use on all architectures, since we have big endian systems connected as both big endian and little endian. You are right that the specification never mentions how the data bus should be wired. If it did, then it could definitely be argued that our boards are wired up "incorrectly". I think it would be possible to modify the driver so that it can take more parameters, instead of a patch which relies on the endianess of the CPU. It would then be possible to specify in the board setup that the data bus is 16-bit and big endian. The patch could be done in such a way so that it doesn't effect other boards, which will initalise the new fields as zero. For example, add a "bool swap_databus_endianess" field which we can set to "true" in our board setups. It can either be solved with if-statements in the write functions (which will add some overhead for all systems), or we can have multiple versions of the write functions, check the new field once and store the function pointer to the correct write function when the driver is set up. Any better ideas of how it can be solved in software? The endianess of the data bus on AVR32AP7000 can unfortunately not be changed either. Modifying the hardware is not an option for us at the moment since we have recently started producing a new batch. Jonas -----Ursprungligt meddelande----- Från: Peter Tyser [mailto:ptyser@xxxxxxxxxxx] Skickat: den 14 april 2009 19:51 Till: Jonas Larsson Kopia: linux-usb@xxxxxxxxxxxxxxx Ämne: Re: ISP1760 USB host driver, big endian and 16-bit data bus Hi Jonas, > We use the ISP1760 USB host driver on our custom made board. The CPU is > an Atmel AVR32AP7000 processor (Big Endian) which is connected to the > ISP1760 chip with a 16-bit data bus. I've used the ISP1761 on a two MPC85xx (big endian cpu and data bus) systems - one with a 16-bit data bus, the other with a 32-bit data bus. > Some modification had to be done to the ISP1760 host driver in order to > get it to work on our board. Same here. For the 8548-based board with a 16-bit data bus the changes I made are implemented slightly differently, but I believe have the same effect (16-bit swapping in isp1760_readl/writel and 16-bit swapping + byte swapping in priv_read/write_copy). For the 8548-based board with a 32-bit data bus, all access to hardware required just byte swapping. > I'm not sure if these modification are required due to big endian, the > 16-bit data bus or due to some design problem on our board. > > I would really appreciate some input on this. My best guess is that NXP assumes that the ISP1670/1 data bus is wired up for little endian operation (of course they never mention this anywhere that I can find:). I believe that this would explain the modifications you referenced for 16-bit operation, as well as the changes I made for 32-bit operation. Unfortunately the endian of the data bus on the MPC85xx processors can not be changed to little endian. Maybe it can be changed on the AVR32AP7000? That could possibly be a quick workaround for your specific setup. > Any ideas of how these changes can be applied to the real driver? There are a few ideas that came to mind, but my first question was should we change the driver? In theory, our boards are wired up "incorrectly" and we could use the driver as is if we re-spun our boards with a different data bus numbering scheme. For example, the next revs of our 85xx-based boards will connect the ISP part with a little endian data bus. So it could be argued we'd be adding a software workaround to hack around our mistake in hardware. That being said, I think lots of people are going to wire up the data bus just like you and I did, so in theory lots of people may need this software workaround. Would the USB maintainers accept a patch which added support to the isp1760 driver for boards with big-endian data buses? Please keep me on CC as I'm not subscribed to this mailinglist. Best, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html