On 26/10/2015 13:05, Måns Rullgård wrote: > Marc Gonzalez 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? It was called smp8910. (They broke the naming convention, but at least it's clearly set apart from other "normal" chips.) >>>> 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. The only difference between chips '2N' and '2N+1' used to be Macrovision support... But the rule was broken for smp8759, which has more features than smp8758 (e.g. HDMI-in and PCIe) >> 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. OK. >> 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" AFAICT, the list of tango4 chips is (in chronological order) 8910, 8734, 8756, 8758, 8759 The problem I see is that Sigma already has plans for non-tango4 87xx SoCs (two in fact: 8760 and 8762, as far as I've heard). (What a mess.) I would think the "chip family" needs to use the code-name like tango3 or tango4 (for lack of a better discriminant). Also, (purely hypothetical) suppose something changed in 8756 and up. How would the 8758 pick up the improvement, but not the 8734? I'm also confused, because I thought I read somewhere not to use wildcards in compatible strings... <Looking> It was there: http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property (Sorry, some of this stuff is a bit hard for me to grok.) Finally, I think what you decide to do can also be done for the interrupt controller, right? > - 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. I think my brain is having a device tree indigestion :-( Maybe things will clear up in a few hours. Regards. -- 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
