> From: Matthijs Kooijman [mailto:matthijs@xxxxxxxx] > Sent: Wednesday, April 17, 2013 10:15 AM ... > > > As you might gather from the above, I'm not really in the loop about how > > > the hardware works here, so I don't think I'm qualified to decide on the > > > best approach here... Perhaps I should adapt my patch to just the > > > non-phy related parameters and we can do the phy-stuff later when it is > > > clear how they should work? > > > > That won't work. The Phy parameters have to be set according to > > the type of Phy that is connected, and some of them cannot be > > autodetected. So they have to be defined somewhere. > Actually, for my particular hardware this would be fine, since the > defaults work (but the defaults / autodetected values for the non-phy > params are also fine, so I don't really need any of this dt patch, I > just coded it up for completeness). For now, I think you should just put in the minimum amount of stuff that you need, and let any future users be responsible for adding what they need. It could be that nobody will need anything else. > Regarding this "cannot be autodetected" stuff: I was wondering about the > phy_utmi_width parameter (which has a big "NOT DETECTABLE" comment in > the code). I noticed there is value in HWCFG4 that specifies wether the > hardware can do 8, 16, or both 8 and 16 bits. In the case of 8 and 16, > this means the value for this parameter can be autodetected (rather, the > hardware simply ignores whatever you write, I think). IIRC my hardware > had 8/16 set in the HWCFG4 register, but both 8 and 16 bits work. My > suspicion is that the particular PHY used in my platform simply supports > both 8 and 16 bits, but that might not always be the case (even though > the dwc controller _does_ support both values). Does this sound correct > to you? Yes, exactly. If you have a core which was configured for both 8 and 16 bits, then the value to use depends on the phy, and cannot be auto detected as far as I can see. -- Paul -- 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
