Marc Gonzalez <marc_gonzalez@xxxxxxxxxxxxxxxx> writes: > On 23/10/2015 15:41, Måns Rullgård wrote: > >> Marc Gonzalez wrote: >> >>> On 22/10/2015 16:02, Mans Rullgard wrote: >>> >>>> This adds a binding for the Aurora VLSI NB8800 Ethernet controller >>>> using the "aurora,nb8800" compatible string. When used in Sigma >>>> Designs chips a few additional control registers are available. >>>> This variant is indicated by the "sigma,smp8640-ethernet" compatible >>>> string. >>> >>> I've been meaning to ask a noob question to the devicetree group >>> about how names for compatible strings are chosen. >>> >>> Sigma Designs has two active SoC families, Tango3 (which consists of >>> about a dozen MIPS-based SoCs, typically named SMP86xx) and Tango4 >>> (a few ARM-based SoCs, typically named SMP87xx). I should note that >>> there is no SMP8640 SoC AFAIK, rather SMP864x is a Tango3 sub-family >>> (I could locate 42,43,44,45,46). > > Just to make things a bit more confusing, I learned that Sigma made > one MIPS-based Tango4 SoC... That explains the presence of tango4 mentions in a Sigma MIPS kernel tree I found. Do you know what it was called? >>> AFAIK, all our SoCs are using the same Aurora NB8800 Ethernet MAC, >>> along with the extra features. I find it odd to use a specific SoC >>> model to refer to this device, instead of a more generic name. >>> (It's weird having to mention smp8640 in the tango4 DT.) >> >> I picked 8640 since all 8640 or higher chips are compatible (863x chips >> (tango2) are not). Some of the later versions have additional extra >> features, but they all work with the basic driver. > > According to my branch's FAEs, the first Tango3 was SMP8644. I don't know which was first out the door, but judging by marketing materials, 8642, 8644, and 8646 were available around the same time. All of these also have an odd-numbered variant (8643 etc) without Macrovision features. > I showed the DT to a colleague, and his reaction was: "Don't use > smp8640, it will confuse other engineers, Sigma didn't make a 8640 > SoC." > > http://www.qobuz.com/info/IMG/pdf/SMP8643.pdf > > Would you be willing to change the compatible string to > "sigma,smp8644-foo" or "sigma,smp864x-foo" ? > > If it's not possible, I suppose I can add comments in the DT, to clear > the potential confusion for Sigma engineers. My intent was certainly not to confuse. Sigma product brochures talk about the "SMP8640 series," so I figured that would be a good way of referring to them as a group. See e.g. this PDF, now gone from the main sigmadesigns.com site: http://wayback.archive.org/web/20150101024010/http://www.sigmadesigns.com/uploads/documents/selection_guide.pdf >> There also appear to be some differences (bug fixes?) between 8643 and >> 8759 (the ones I have) not documented anywhere. > > Suppose you identify these differences, and you make the appropriate > changes to the driver. What compatible string would you use to refer > to the new features? I used "sigma,tango4-ethernet" but IIUC it must > be more specific, such as the first Tango4 chip to implement these > changes (I guess that would be the SMP8734). There are differences even within the tango3 family. The SMP867x chips have features not present on the earlier ones. The tango3 and tango4 codenames are too unspecific to be of use here. It's better to use exact chip designations. > So I should write something like this in my DT? > > eth0: ethernet@26000 { > compatible = "sigma,smp8734-ethernet", "sigma,smp8640-ethernet", "aurora,nb8800"; > > Hmmm, you mention this below, but you used "sigma,smp8759-ethernet". > What about earlier chips? OK, how about this scheme then: - Device trees list the exact chip, the chip family, the oldest compatible family, and finally the basic "aurora,nb8800". For the SMP8759 that would look like this: "sigma,smp8759-ethernet", "sigma,smp87xx-ethernet", "sigma,smp864x-ethernet", "aurora,nb8800" - Drivers match against whatever they need to in order to safely identify features. If the driver finds a match for e.g. "sigma,smp864x-ethernet" it is allowed to make use of any features present in all chips of that family (even if the actual chip is a later one, the DT says it's compatible). If a specific chip is found to need a bug workaround or whatever, the driver can enable that by matching on the exact string. This approach means that if the driver is updated to support newer features, no change is needed to the devicetree, and if a new chip shows up, say a hypothetical smp8764, a driver with support for the smp87xx family will automatically recognise it without changes. Unfortunately the 863x (tango2) chips are not compatible with 864x and later, so it's not safe to use a catch-all smp86xx. Speaking more generally about device trees, for chip families like this, it can be a good solution to have all the common parts in, say, smp87xx.dtsi which is included by chip-specific files, i.e. smp8734.dtsi and smp8759.dtsi, with overrides and additions as necessary. These files can then be included by the actual board files such as smp8759-vantage.dts which can apply further tweaks and add nodes for off-chip peripherals. -- Måns Rullgård mans@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
