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. If you change the macro, it will break our host controller driver. It is very unlikely that we will change the hardware in the near future. I hope you can find a solution that will work for you and us. Thanks, Julie. > -----Original Message----- > From: Jan Andersson [mailto:jan@xxxxxxxxxxx] > Sent: Tuesday, January 26, 2010 7:07 PM > To: Julie Zhu; John Linn > Cc: Jonas Ekergarn > Subject: ehci-xilinx-of.c and big_endian_mmio > > Dear Julie and John, > > I am writing to you as you were listed in the commit message adding > support for the Xilinx USB host controller. > > I am in the process of adding support for another host controller and I > believe that I have found an issue with the definition of the HC_LENGTH > and HC_VERSION macros defined in include/linux/usb/ehci-def.h. > > There is a thread about in on the linux-usb mailing list, the most > recent message at the time of writing can be found here: > http://marc.info/?l=linux-usb&m=126441448626924&w=2 > > To summarize the thread: The EHCI specification defines the CAPLENGTH > register as an 8-bit register at offset 0. The linux EHCI code reads > out > CAPLENGTH and HCIVERSION using a 32-bit access, in a big endian system > this means that CAPLENGTH will be on bits 31:24 of the word (since the > byte at offset 0 is the most significant byte). The macro for selecting > CAPLENGTH looks like (from ehci-def.h): > > #define HC_LENGTH(p) (((p)>>00)&0x00ff) /* bits 7:0 */ > > In other words, the code selects the byte at offset 3 (for a big endian > system). > > From what I can gather from the Xilinx DS734 XPS USB Host Controller > (v1.01a) Data sheet, your controller has CAPLENGTH at offset 0. But for > some reason it still seems to work? What I want to do is to incorporate > something like what was suggested by Alan Stern in the thread > previously > referenced: > > #define HC_LENGTH(ehci, p) (0xff & ((p) >> \ > (ehci_big_endian_mmio(ehci) ? 24 : 0))) > #define HC_VERSION(ehci, p) (0xffff & ((p) >> \ > (ehci_big_endian_mmio(ehci) ? 0 : 16))) > > Would this addition break the driver for your controller? > > Best regards, > Jan > > -- > ----------------------------------------------- > Jan Andersson Email: jan@xxxxxxxxxxx > Digital Design Tel: +46 31 7758659 > Aeroflex Gaisler AB www.aeroflex.com/gaisler > ----------------------------------------------- > 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
