Hi, Jan, please see my reply at the end of the email. > -----Original Message----- > From: Jan Andersson [mailto:jan@xxxxxxxxxxx] > Sent: Wednesday, January 27, 2010 9:42 AM > To: Julie Zhu > Cc: John Linn; linux-usb@xxxxxxxxxxxxxxx; Jonas Ekergarn > Subject: Re: ehci-xilinx-of.c and big_endian_mmio > > Julie Zhu wrote: > > Hi, Jan, > > > > You are right about our data sheet has offset 0 for CAPLENGTH for > > version 1.01a, which is wrong. The document maintainer failed to > update > > the document, sorry about that. > > > > Our initial hardware had the CAPLENGTH at offset at 0. However, after > > failed in Linux and read Linux's definition on HC_LENGTH macro, we > > changed our understanding of the EHCI spec as the following: > > > > 1. In the first word, 32-bit, CAPLENGTH is at offset 0. > > 2. All registers are accessed as 32-bit. > > 3. Xilinx XPS USB Host is a big endian host controller. If we define > > CAPLENGTH in the hardware at offset 0, after reading in the 32-bit > word, > > CAPLENGTH becomes offset 3 in the word; this will make the > > hardware/software definition messy. > > > > Based on this, we had changed our hardware to have CAPLENGTH at > offset > > 3, which is reflected in the data sheet for v1.02a. > > Thanks for your reply Julie. I sent similar e-mails to all maintainers > of ehci-glue that assigned big_endian_mmio. Assuming that the other > drivers are correct it looks like all other host controller vendors, > that have drivers included in mainline, also chose this route. I guess > that it is a tribute to Linux that its code now supersedes the actual > specification for the register interface :-) > I do not agree with you that what Linux is doing is a violation to the EHCI spec. It is taken as granted that a definition in big endian swaps the bytes versus the definition in little endian. Since all values are accessed in 32-bits, definitions have to be taken into the context that everything is viewed in 32-bit word. So, if put the EHCI spec of CAPLEN is the first byte in the first word, then what Linux defines and what we have done are exactly what the EHCI spec says. Same goes to the bit definitions. We swap all the bits in the word, 31th becomes first, and first becomes 31th, which is different from the spec. Do you think that is a violation to the spec too? And how will it work if we keep all the bit positions as the same as the EHCI spec? Thanks, Julie. This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- 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
