[PATCH 1/3] devicetree: add vendor prefix for Aurora VLSI

[PATCH 1/3] devicetree: add vendor prefix for Aurora VLSI

[Mans Rullgard]

This adds the vendor prefix "aurora" for Aurora VLSI, Inc.

Signed-off-by: Mans Rullgard <mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..380ce10 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -30,6 +30,7 @@ artesyn	Artesyn Embedded Technologies Inc.
 asahi-kasei	Asahi Kasei Corp.
 atmel	Atmel Corporation
 auo	AU Optronics Corporation
+aurora	Aurora VLSI, Inc.
 avago	Avago Technologies
 avic	Shanghai AVIC Optoelectronics Co., Ltd.
 axis	Axis Communications AB
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Mans Rullgard]

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.
+- 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

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Rob Herring]

On Thu, Oct 22, 2015 at 9:02 AM, Mans Rullgard <mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org> 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-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
> ---
>  .../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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Marc Gonzalez]

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.

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Rob Herring]

On Fri, Oct 23, 2015 at 7:10 AM, Marc Gonzalez
<marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org> 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-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
>> ---
>>  .../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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Måns Rullgård]

Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org> 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-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
>> ---
>>  .../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.

-- 
Måns Rullgård
mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Marc Gonzalez]

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.

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Måns Rullgård]

Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org> 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-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>>  .../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.

-- 
Måns Rullgård
mans-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Marc Gonzalez]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Måns Rullgård]

Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org> 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-2StjZFpD7GcAvxtiuMwx3w@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Marc Gonzalez]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Måns Rullgård]

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.

-- 
Måns Rullgård
mans@mansr.com

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Marc Gonzalez]

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.

Re: [PATCH 2/3] devicetree: add binding for Aurora VLSI NB8800 Ethernet controller

[Måns Rullgård]

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.

-- 
Måns Rullgård
mans@mansr.com

Re: [PATCH 1/3] devicetree: add vendor prefix for Aurora VLSI

[Rob Herring]

On Thu, Oct 22, 2015 at 9:02 AM, Mans Rullgard <mans@mansr.com> wrote:
> This adds the vendor prefix "aurora" for Aurora VLSI, Inc.
>
> Signed-off-by: Mans Rullgard <mans@mansr.com>

Acked-by: Rob Herring <robh@kernel.org>

> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 82d2ac9..380ce10 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -30,6 +30,7 @@ artesyn       Artesyn Embedded Technologies Inc.
>  asahi-kasei    Asahi Kasei Corp.
>  atmel  Atmel Corporation
>  auo    AU Optronics Corporation
> +aurora Aurora VLSI, Inc.
>  avago  Avago Technologies
>  avic   Shanghai AVIC Optoelectronics Co., Ltd.
>  axis   Axis Communications AB
> --
> 2.5.3
>