| Message ID | 1445522558-5808-2-git-send-email-mans@mansr.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Thu, Oct 22, 2015 at 9:02 AM, Mans Rullgard <mans@mansr.com> 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. > > Signed-off-by: Mans Rullgard <mans@mansr.com> > --- > .../devicetree/bindings/net/aurora,nb8800.txt | 26 ++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt > > diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt b/Documentation/devicetree/bindings/net/aurora,nb8800.txt > new file mode 100644 > index 0000000..c19f615 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt > @@ -0,0 +1,26 @@ > +* Aurora VLSI AU-NB8800 Ethernet controller > + > +Required properties: > +- compatible: Should be "aurora,nb8800", "sigma,smp8640-ethernet" > + The latter indicates presence of extra features added by Sigma Designs. These should be in opposite order. Most specific comes first. > +- reg: Should be MMIO address space of the device > +- interrupts: Should contain the interrupt specifier for the device > +- interrupt-parent: Should be a phandle for the interrupt controller > +- clocks: Should be a phandle for the clock for the device > + > +Common properties described in ethernet.txt: > +- local-mac-address > +- mac-address > +- max-speed > +- phy-mode > + > +Example: > + > +ethernet@26000 { > + compatible = "aurora,nb8800"; > + reg = <0x10000 0x800>; > + interrupts = <42>; > + clocks = <&sys_clk>; > + max-speed = <1000>; > + phy-connection-type = "rgmii"; > +}; > -- > 2.5.3 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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. > > Signed-off-by: Mans Rullgard <mans@mansr.com> > --- > .../devicetree/bindings/net/aurora,nb8800.txt | 26 ++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt > > diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt b/Documentation/devicetree/bindings/net/aurora,nb8800.txt > new file mode 100644 > index 0000000..c19f615 > --- /dev/null > +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt > @@ -0,0 +1,26 @@ > +* Aurora VLSI AU-NB8800 Ethernet controller > + > +Required properties: > +- compatible: Should be "aurora,nb8800", "sigma,smp8640-ethernet" > + The latter indicates presence of extra features added by Sigma Designs. 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). 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.) Would it be possible to have a compatible string which makes it clear that it is an Aurora MAC with vendor-specific tweaks? Something like "sigma,aurora-nb8800-mac" ? > +- reg: Should be MMIO address space of the device > +- interrupts: Should contain the interrupt specifier for the device > +- interrupt-parent: Should be a phandle for the interrupt controller > +- clocks: Should be a phandle for the clock for the device > + > +Common properties described in ethernet.txt: > +- local-mac-address > +- mac-address > +- max-speed > +- phy-mode > + > +Example: > + > +ethernet@26000 { > + compatible = "aurora,nb8800"; > + reg = <0x10000 0x800>; > + interrupts = <42>; I thought one had to specify also whether the device sent "edge" or "level" IRQs? > + clocks = <&sys_clk>; > + max-speed = <1000>; > + phy-connection-type = "rgmii"; > +}; Regards. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 23, 2015 at 7:10 AM, Marc Gonzalez <marc_gonzalez@sigmadesigns.com> 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. >> >> Signed-off-by: Mans Rullgard <mans@mansr.com> >> --- >> .../devicetree/bindings/net/aurora,nb8800.txt | 26 ++++++++++++++++++++++ >> 1 file changed, 26 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt >> >> diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt b/Documentation/devicetree/bindings/net/aurora,nb8800.txt >> new file mode 100644 >> index 0000000..c19f615 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt >> @@ -0,0 +1,26 @@ >> +* Aurora VLSI AU-NB8800 Ethernet controller >> + >> +Required properties: >> +- compatible: Should be "aurora,nb8800", "sigma,smp8640-ethernet" >> + The latter indicates presence of extra features added by Sigma Designs. > > 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). > > 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.) The block may seem the same, but do you really know? Same block can have different operating frequencies depending on the physical design. A specific string is insurance in case you do find some difference as that should not require you do update your DTB (the traditional model is DTB is part of firmware and independent of OS versions). Having a generic string for matching is fine, but you also need a specific one. Often the first chip with a block is the generic string. New SOCs can then claim compatibility with old versions and existing drivers. > Would it be possible to have a compatible string which makes it > clear that it is an Aurora MAC with vendor-specific tweaks? > Something like "sigma,aurora-nb8800-mac" ? That is what is done here essentially. You can debate on the exact name if you like. >> +- reg: Should be MMIO address space of the device >> +- interrupts: Should contain the interrupt specifier for the device >> +- interrupt-parent: Should be a phandle for the interrupt controller >> +- clocks: Should be a phandle for the clock for the device >> + >> +Common properties described in ethernet.txt: >> +- local-mac-address >> +- mac-address >> +- max-speed >> +- phy-mode >> + >> +Example: >> + >> +ethernet@26000 { >> + compatible = "aurora,nb8800"; >> + reg = <0x10000 0x800>; >> + interrupts = <42>; > > I thought one had to specify also whether the device sent "edge" > or "level" IRQs? That is entirely dependent on the interrupt controller you are attached to. Often that is not a configurable property for hard wired IRQs. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> writes: > 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. >> >> Signed-off-by: Mans Rullgard <mans@mansr.com> >> --- >> .../devicetree/bindings/net/aurora,nb8800.txt | 26 ++++++++++++++++++++++ >> 1 file changed, 26 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt >> >> diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt b/Documentation/devicetree/bindings/net/aurora,nb8800.txt >> new file mode 100644 >> index 0000000..c19f615 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt >> @@ -0,0 +1,26 @@ >> +* Aurora VLSI AU-NB8800 Ethernet controller >> + >> +Required properties: >> +- compatible: Should be "aurora,nb8800", "sigma,smp8640-ethernet" >> + The latter indicates presence of extra features added by Sigma Designs. > > 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). > > 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. There also appear to be some differences (bug fixes?) between 8643 and 8759 (the ones I have) not documented anywhere. > Would it be possible to have a compatible string which makes it > clear that it is an Aurora MAC with vendor-specific tweaks? > Something like "sigma,aurora-nb8800-mac" ? This doesn't indicate which Sigma modifications are present. If the driver is at some point modified to take advantage of features/fixes in newer chips, it's good to have a naming scheme that can accommodate that. For the SMP8759 devicetree, one could set the compatible list to "sigma,smp8759-ethernet", "sigma,smp8640-ethernet", "aurora,nb8800" indicating the exact device even if the driver currently doesn't care, that it is compatible with the 8640 baseline, and finally the plain aurora as a last fallback. >> +- reg: Should be MMIO address space of the device >> +- interrupts: Should contain the interrupt specifier for the device >> +- interrupt-parent: Should be a phandle for the interrupt controller >> +- clocks: Should be a phandle for the clock for the device >> + >> +Common properties described in ethernet.txt: >> +- local-mac-address >> +- mac-address >> +- max-speed >> +- phy-mode >> + >> +Example: >> + >> +ethernet@26000 { >> + compatible = "aurora,nb8800"; >> + reg = <0x10000 0x800>; >> + interrupts = <42>; > > I thought one had to specify also whether the device sent "edge" > or "level" IRQs? Depends on the interrupt controller. This is just an example.
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. >>> >>> Signed-off-by: Mans Rullgard <mans@mansr.com> >>> --- >>> .../devicetree/bindings/net/aurora,nb8800.txt | 26 ++++++++++++++++++++++ >>> 1 file changed, 26 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt >>> >>> diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt b/Documentation/devicetree/bindings/net/aurora,nb8800.txt >>> new file mode 100644 >>> index 0000000..c19f615 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt >>> @@ -0,0 +1,26 @@ >>> +* Aurora VLSI AU-NB8800 Ethernet controller >>> + >>> +Required properties: >>> +- compatible: Should be "aurora,nb8800", "sigma,smp8640-ethernet" >>> + The latter indicates presence of extra features added by Sigma Designs. >> >> 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). >> >> 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. > > There also appear to be some differences (bug fixes?) between 8643 and > 8759 (the ones I have) not documented anywhere. I'm trying to locate someone who would know these kinds of details. >> Would it be possible to have a compatible string which makes it >> clear that it is an Aurora MAC with vendor-specific tweaks? >> Something like "sigma,aurora-nb8800-mac" ? > > This doesn't indicate which Sigma modifications are present. If the > driver is at some point modified to take advantage of features/fixes in > newer chips, it's good to have a naming scheme that can accommodate > that. > > For the SMP8759 devicetree, one could set the compatible list to > "sigma,smp8759-ethernet", "sigma,smp8640-ethernet", "aurora,nb8800" > indicating the exact device even if the driver currently doesn't care, > that it is compatible with the 8640 baseline, and finally the plain > aurora as a last fallback. I will update my vantage-1172 DT accordingly. >> I thought one had to specify also whether the device sent "edge" >> or "level" IRQs? > > Depends on the interrupt controller. This is just an example. Sorry for the noise. (I thought edge/level was a device property, as in "I'll just pulse that IRQ, or I'll hold it until someone asks me to shut up.") Regards. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> 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. >>>> >>>> Signed-off-by: Mans Rullgard <mans@mansr.com> >>>> --- >>>> .../devicetree/bindings/net/aurora,nb8800.txt | 26 ++++++++++++++++++++++ >>>> 1 file changed, 26 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt b/Documentation/devicetree/bindings/net/aurora,nb8800.txt >>>> new file mode 100644 >>>> index 0000000..c19f615 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt >>>> @@ -0,0 +1,26 @@ >>>> +* Aurora VLSI AU-NB8800 Ethernet controller >>>> + >>>> +Required properties: >>>> +- compatible: Should be "aurora,nb8800", "sigma,smp8640-ethernet" >>>> + The latter indicates presence of extra features added by Sigma Designs. >>> >>> 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). >>> >>> 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. >> >> There also appear to be some differences (bug fixes?) between 8643 and >> 8759 (the ones I have) not documented anywhere. > > I'm trying to locate someone who would know these kinds of details. More specifically, the DMA completion interrupts seem to behave differently. >>> I thought one had to specify also whether the device sent "edge" >>> or "level" IRQs? >> >> Depends on the interrupt controller. This is just an example. > > Sorry for the noise. (I thought edge/level was a device property, > as in "I'll just pulse that IRQ, or I'll hold it until someone > asks me to shut up.") Most devices keep the interrupt request line high until explicitly cleared by a driver. Whether you want edge or level triggering depends on the driver design and if the interrupt is shared with other devices.
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... >> 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 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. > 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). 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? >> Would it be possible to have a compatible string which makes it >> clear that it is an Aurora MAC with vendor-specific tweaks? >> Something like "sigma,aurora-nb8800-mac" ? > > This doesn't indicate which Sigma modifications are present. If the > driver is at some point modified to take advantage of features/fixes in > newer chips, it's good to have a naming scheme that can accommodate > that. > > For the SMP8759 devicetree, one could set the compatible list to > "sigma,smp8759-ethernet", "sigma,smp8640-ethernet", "aurora,nb8800" > indicating the exact device even if the driver currently doesn't care, > that it is compatible with the 8640 baseline, and finally the plain > aurora as a last fallback. [Preserved for context] Regards. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> 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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> writes: >>> 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.) Right, and you just illustrated why wildcards are bad. Sorry for the confusion. I should have known better than to look at existing bindings. Let's drop that idea. Let's try something else: Device trees list the exact chip, the oldest chip with the same features, and the oldest compatible chip. From the sound of things, that means the smp8759 should use "sigma,smp8759-ethernet", "sigma,smp8910-ethernet", "sigma,smp8642-ethernet", "aurora,nb8800". > Finally, I think what you decide to do can also be done for the > interrupt controller, right? Sure, the same scheme should be used for all on-chip devices.
On 26/10/2015 14:54, Måns Rullgård wrote: > Let's try something else: > > Device trees list the exact chip, the oldest chip with the same > features, and the oldest compatible chip. From the sound of things, > that means the smp8759 should use "sigma,smp8759-ethernet", > "sigma,smp8910-ethernet", "sigma,smp8642-ethernet", "aurora,nb8800". (I want to make sure I didn't misunderstand.) In my hypothetical example where something changed in 8756 and up... for a 8734 DT, I would specify: smp8734, smp8910, smp8642, nb8800 for a 8758 DT, I would specify: smp8758, smp8756, smp8642, nb8800 Is that correct? If yes, that works for me. Regards. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> writes: > On 26/10/2015 14:54, Måns Rullgård wrote: > >> Let's try something else: >> >> Device trees list the exact chip, the oldest chip with the same >> features, and the oldest compatible chip. From the sound of things, >> that means the smp8759 should use "sigma,smp8759-ethernet", >> "sigma,smp8910-ethernet", "sigma,smp8642-ethernet", "aurora,nb8800". > > (I want to make sure I didn't misunderstand.) In my hypothetical > example where something changed in 8756 and up... > > for a 8734 DT, I would specify: smp8734, smp8910, smp8642, nb8800 > for a 8758 DT, I would specify: smp8758, smp8756, smp8642, nb8800 If the 8756 were still compatible with 8910 (which has features not in 8642), it should include both. The list gets long, but it's probably the least maintenance in the end.
diff --git a/Documentation/devicetree/bindings/net/aurora,nb8800.txt b/Documentation/devicetree/bindings/net/aurora,nb8800.txt new file mode 100644 index 0000000..c19f615 --- /dev/null +++ b/Documentation/devicetree/bindings/net/aurora,nb8800.txt @@ -0,0 +1,26 @@ +* Aurora VLSI AU-NB8800 Ethernet controller + +Required properties: +- compatible: Should be "aurora,nb8800", "sigma,smp8640-ethernet" + The latter indicates presence of extra features added by Sigma Designs. +- reg: Should be MMIO address space of the device +- interrupts: Should contain the interrupt specifier for the device +- interrupt-parent: Should be a phandle for the interrupt controller +- clocks: Should be a phandle for the clock for the device + +Common properties described in ethernet.txt: +- local-mac-address +- mac-address +- max-speed +- phy-mode + +Example: + +ethernet@26000 { + compatible = "aurora,nb8800"; + reg = <0x10000 0x800>; + interrupts = <42>; + clocks = <&sys_clk>; + max-speed = <1000>; + phy-connection-type = "rgmii"; +};
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. Signed-off-by: Mans Rullgard <mans@mansr.com> --- .../devicetree/bindings/net/aurora,nb8800.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/aurora,nb8800.txt