[13/23] dt-bindings: arm: add Tesla FSD ARM SoC

Commit Message

Alim Akhtar Jan. 13, 2022, 12:11 p.m. UTC

Add device tree bindings for the Tesla FSD ARM SoC.

Cc: [e-mail]
Signed-off-by: Alim Akhtar <[e-mail]>
---
 .../devicetree/bindings/arm/tesla.yaml        | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/tesla.yaml

Comments

Krzysztof Kozlowski Jan. 13, 2022, 12:33 p.m. UTC | #1

On 13/01/2022 13:11, Alim Akhtar wrote:
> Add device tree bindings for the Tesla FSD ARM SoC.
> 
> Cc: [e-mail]
> Signed-off-by: Alim Akhtar <[e-mail]>
> ---
>  .../devicetree/bindings/arm/tesla.yaml        | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/tesla.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/tesla.yaml b/Documentation/devicetree/bindings/arm/tesla.yaml
> new file mode 100644
> index 000000000000..9f89cde76c85
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/tesla.yaml
> @@ -0,0 +1,25 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/tesla.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Tesla Full Self Driving(FSD) platforms device tree bindings
> +
> +maintainers:
> +  - Alim Akhtar <[e-mail]>
> +  - [e-mail]
> +
> +properties:
> +  $nodename:
> +    const: '/'
> +  compatible:
> +    oneOf:
> +
> +      - description: FSD SoC board
> +        items:
> +          - const: tesla,fsd

Either this is a SoC or a board compatible... Cannot be both.

> +
> +additionalProperties: true
> +
> +...
> 


Best regards,
Krzysztof

Alim Akhtar Jan. 14, 2022, 4:57 p.m. UTC | #2

>-----Original Message-----
>From: Krzysztof Kozlowski [mailto:[e-mail]]
>Sent: Thursday, January 13, 2022 6:03 PM
>To: Alim Akhtar <[e-mail]>; linux-arm-
>[e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]; [e-mail];
>[e-mail]; [e-mail]; [e-mail];
>[e-mail]; [e-mail]; linux-samsung-
>[e-mail]; [e-mail]; [e-mail]
>Subject: Re: [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC
>
>On 13/01/2022 13:11, Alim Akhtar wrote:
>> Add device tree bindings for the Tesla FSD ARM SoC.
>>
>> Cc: [e-mail]
>> Signed-off-by: Alim Akhtar <[e-mail]>
>> ---
>>  .../devicetree/bindings/arm/tesla.yaml        | 25 +++++++++++++++++++
>>  1 file changed, 25 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/arm/tesla.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/tesla.yaml
>> b/Documentation/devicetree/bindings/arm/tesla.yaml
>> new file mode 100644
>> index 000000000000..9f89cde76c85
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/tesla.yaml
>> @@ -0,0 +1,25 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
>> +---
>> +$id:
>> +https://protect2.fireeye.com/v1/url?k=2f0fac44-70949546-2f0e270b-0cc4
>> +7a312ab0-50c826f7b1999a5f&q=1&e=bcbf277f-4e93-4705-8f6a-
>2beaa7eb31e2&
>> +u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Farm%2Ftesla.yaml%23
>> +$schema:
>> +https://protect2.fireeye.com/v1/url?k=d8493fe2-87d206e0-d848b4ad-0cc4
>> +7a312ab0-f4e5046adc7da972&q=1&e=bcbf277f-4e93-4705-8f6a-
>2beaa7eb31e2&
>> +u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
>> +
>> +title: Tesla Full Self Driving(FSD) platforms device tree bindings
>> +
>> +maintainers:
>> +  - Alim Akhtar <[e-mail]>
>> +  - [e-mail]
>> +
>> +properties:
>> +  $nodename:
>> +    const: '/'
>> +  compatible:
>> +    oneOf:
>> +
>> +      - description: FSD SoC board
>> +        items:
>> +          - const: tesla,fsd
>
>Either this is a SoC or a board compatible... Cannot be both.
>
Actually we call this as fsd board, so let me add accordingly compatible (fsd-baord) for board.
Thanks
>> +
>> +additionalProperties: true
>> +
>> +...
>>
>
>
>Best regards,
>Krzysztof

Krzysztof Kozlowski Jan. 14, 2022, 5:29 p.m. UTC | #3

On 14/01/2022 17:57, Alim Akhtar wrote:
> 
> 
>> -----Original Message-----
>> From: Krzysztof Kozlowski [mailto:[e-mail]]
>> Sent: Thursday, January 13, 2022 6:03 PM
>> To: Alim Akhtar <[e-mail]>; linux-arm-
>> [e-mail]; [e-mail]
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; linux-samsung-
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC
>>
>> On 13/01/2022 13:11, Alim Akhtar wrote:
>>> Add device tree bindings for the Tesla FSD ARM SoC.
>>>
>>> Cc: [e-mail]
>>> Signed-off-by: Alim Akhtar <[e-mail]>
>>> ---
>>>  .../devicetree/bindings/arm/tesla.yaml        | 25 +++++++++++++++++++
>>>  1 file changed, 25 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/arm/tesla.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/tesla.yaml
>>> b/Documentation/devicetree/bindings/arm/tesla.yaml
>>> new file mode 100644
>>> index 000000000000..9f89cde76c85
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/tesla.yaml
>>> @@ -0,0 +1,25 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
>>> +---
>>> +$id:
>>> +https://protect2.fireeye.com/v1/url?k=2f0fac44-70949546-2f0e270b-0cc4
>>> +7a312ab0-50c826f7b1999a5f&q=1&e=bcbf277f-4e93-4705-8f6a-
>> 2beaa7eb31e2&
>>> +u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Farm%2Ftesla.yaml%23
>>> +$schema:
>>> +https://protect2.fireeye.com/v1/url?k=d8493fe2-87d206e0-d848b4ad-0cc4
>>> +7a312ab0-f4e5046adc7da972&q=1&e=bcbf277f-4e93-4705-8f6a-
>> 2beaa7eb31e2&
>>> +u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
>>> +
>>> +title: Tesla Full Self Driving(FSD) platforms device tree bindings
>>> +
>>> +maintainers:
>>> +  - Alim Akhtar <[e-mail]>
>>> +  - [e-mail]
>>> +
>>> +properties:
>>> +  $nodename:
>>> +    const: '/'
>>> +  compatible:
>>> +    oneOf:
>>> +
>>> +      - description: FSD SoC board
>>> +        items:
>>> +          - const: tesla,fsd
>>
>> Either this is a SoC or a board compatible... Cannot be both.
>>
> Actually we call this as fsd board, so let me add accordingly compatible (fsd-baord) for board.
> Thanks

It's confusing and probably not accurate. In your series fsd is three
things in the same time: an architecture, a SoC and a board (DTS). The
last two should definitely be different. You probably have some eval
board (how it is called also in Tesla open source git) or some specific
product board.

I cannot judge how different this is from Exynos subarchitecture -
looking at patches it is not different - so I could understand a FSD
sub-arch with only one SoC.


Best regards,
Krzysztof

Alim Akhtar Jan. 17, 2022, 1:26 p.m. UTC | #4

Hi Krzysztof

>-----Original Message-----
>From: Krzysztof Kozlowski [mailto:[e-mail]]
>Sent: Friday, January 14, 2022 11:00 PM
>To: Alim Akhtar <[e-mail]>; linux-arm-
>[e-mail]; [e-mail]
>Cc: [e-mail]; [e-mail]; [e-mail];
>[e-mail]; [e-mail]; [e-mail];
>[e-mail]; [e-mail]; linux-samsung-
>[e-mail]; [e-mail]; [e-mail]
>Subject: Re: [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC
>
>On 14/01/2022 17:57, Alim Akhtar wrote:
>>
>>
>>> -----Original Message-----
>>> From: Krzysztof Kozlowski [mailto:[e-mail]]
>>> Sent: Thursday, January 13, 2022 6:03 PM
>>> To: Alim Akhtar <[e-mail]>; linux-arm-
>>> [e-mail]; [e-mail]
>>> Cc: [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail];
>>> [e-mail];
>>> [e-mail]; [e-mail]; linux-samsung-
>>> [e-mail]; [e-mail]; [e-mail]
>>> Subject: Re: [PATCH 13/23] dt-bindings: arm: add Tesla FSD ARM SoC
>>>
>>> On 13/01/2022 13:11, Alim Akhtar wrote:
>>>> Add device tree bindings for the Tesla FSD ARM SoC.
>>>>
>>>> Cc: [e-mail]
>>>> Signed-off-by: Alim Akhtar <[e-mail]>
>>>> ---
>>>>  .../devicetree/bindings/arm/tesla.yaml        | 25 +++++++++++++++++++
>>>>  1 file changed, 25 insertions(+)
>>>>  create mode 100644
>Documentation/devicetree/bindings/arm/tesla.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/tesla.yaml
>>>> b/Documentation/devicetree/bindings/arm/tesla.yaml
>>>> new file mode 100644
>>>> index 000000000000..9f89cde76c85
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/tesla.yaml
>>>> @@ -0,0 +1,25 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause %YAML 1.2
>>>> +---
>>>> +$id:
>>>> +https://protect2.fireeye.com/v1/url?k=2f0fac44-70949546-2f0e270b-0c
>>>> +c4
>>>> +7a312ab0-50c826f7b1999a5f&q=1&e=bcbf277f-4e93-4705-8f6a-
>>> 2beaa7eb31e2&
>>>>
>+u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Farm%2Ftesla.yaml%23
>>>> +$schema:
>>>> +https://protect2.fireeye.com/v1/url?k=d8493fe2-87d206e0-d848b4ad-
>0c
>>>> +c4
>>>> +7a312ab0-f4e5046adc7da972&q=1&e=bcbf277f-4e93-4705-8f6a-
>>> 2beaa7eb31e2&
>>>> +u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
>>>> +
>>>> +title: Tesla Full Self Driving(FSD) platforms device tree bindings
>>>> +
>>>> +maintainers:
>>>> +  - Alim Akhtar <[e-mail]>
>>>> +  - [e-mail]
>>>> +
>>>> +properties:
>>>> +  $nodename:
>>>> +    const: '/'
>>>> +  compatible:
>>>> +    oneOf:
>>>> +
>>>> +      - description: FSD SoC board
>>>> +        items:
>>>> +          - const: tesla,fsd
>>>
>>> Either this is a SoC or a board compatible... Cannot be both.
>>>
>> Actually we call this as fsd board, so let me add accordingly compatible (fsd-
>baord) for board.
>> Thanks
>
>It's confusing and probably not accurate. In your series fsd is three things in
>the same time: an architecture, a SoC and a board (DTS). The last two should
>definitely be different. You probably have some eval board (how it is called
>also in Tesla open source git) or some specific product board.
>
Understood, let me clear this confusion in the patchset-2 where fsd board will have its own compatible and 
of course SoC will have its own (shared with fsd architecture) compatible.

>I cannot judge how different this is from Exynos subarchitecture - looking at
>patches it is not different - so I could understand a FSD sub-arch with only one
>SoC.
>
I understand, it is a bit difficult to visualize it with the current patch set.
As discuss on the other thread, FSD is different, more over the vendor is different, internal design is different.
>
>Best regards,
>Krzysztof

Arnd Bergmann Jan. 17, 2022, 2:14 p.m. UTC | #5

On Mon, Jan 17, 2022 at 2:26 PM Alim Akhtar <[e-mail]> wrote:
>
> >I cannot judge how different this is from Exynos subarchitecture - looking at
> >patches it is not different - so I could understand a FSD sub-arch with only one
> >SoC.
> >
> I understand, it is a bit difficult to visualize it with the current patch set.
> As discuss on the other thread, FSD is different, more over the vendor is different, internal design is different.

Is it based on another SoC design then? Most new SoCs are derived from
some other
one, so it makes sense to put it into the same family. E.g. the Apple
M1 takes bits from
both Exynos and PA-Semi SoCs but has more newly added components than
either one.

I would argue that if this SoC shares the pinctrl, clock, spi, adc,
and timer implementation
with Exynos, we should consider it part of the Exynos family,
regardless of what other
blocks may exist next to those.

       Arnd

Krzysztof Kozlowski Jan. 17, 2022, 3 p.m. UTC | #6

On 17/01/2022 15:14, Arnd Bergmann wrote:
> On Mon, Jan 17, 2022 at 2:26 PM Alim Akhtar <[e-mail]> wrote:
>>
>>> I cannot judge how different this is from Exynos subarchitecture - looking at
>>> patches it is not different - so I could understand a FSD sub-arch with only one
>>> SoC.
>>>
>> I understand, it is a bit difficult to visualize it with the current patch set.
>> As discuss on the other thread, FSD is different, more over the vendor is different, internal design is different.
> 
> Is it based on another SoC design then? Most new SoCs are derived from
> some other
> one, so it makes sense to put it into the same family. E.g. the Apple
> M1 takes bits from
> both Exynos and PA-Semi SoCs but has more newly added components than
> either one.

It seems Apple M1 shares only few bits with SoC. I am aware of only UART
driver as directly re-usable.

> 
> I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> and timer implementation

Plus: UART, watchdog, PWM, I2C, I2S, USB PHY, DWC3 USB (in Exynos
flavor), UFS (also in Exynos-looking flavor), MFC (video codec), some
similarities in DW PCIe, TMU (thermal). Looking at DTS there are
differences but just few comparing to most of shared blocks.

Additionally SoC BSP (and maybe SoC itself...) was actually developed or
co-developed by Samsung, judging by copyrights in the BSP code. Even the
original DTSI has:

	TURBO TRAV SoC device tree source
	Copyright (c) 2017 Samsung Electronics Co., Ltd.


Tesla could still customize it a lot, but it is a strong hint that most
of it came from Samsung LSI and shares with existing Samsung designs.

Have in mind that recent Exynos chips are significantly different than
early ARMv7 or ARMv8 designs and we still consider them part of Exynos
family.

> with Exynos, we should consider it part of the Exynos family,
> regardless of what other
> blocks may exist next to those.

Yes. I don't see the benefit of keeping it outside of Exynos. It will
sprinkle "depends on ARCH_EXYNOS || ARCH_FSD" all over (or depend on
Exynos like you suggested).


Best regards,
Krzysztof

Olof Johansson Jan. 17, 2022, 8:41 p.m. UTC | #7

On Mon, Jan 17, 2022 at 7:00 AM Krzysztof Kozlowski
<[e-mail]> wrote:
>
> On 17/01/2022 15:14, Arnd Bergmann wrote:
> > On Mon, Jan 17, 2022 at 2:26 PM Alim Akhtar <[e-mail]> wrote:
> >>
> >>> I cannot judge how different this is from Exynos subarchitecture - looking at
> >>> patches it is not different - so I could understand a FSD sub-arch with only one
> >>> SoC.
> >>>
> >> I understand, it is a bit difficult to visualize it with the current patch set.
> >> As discuss on the other thread, FSD is different, more over the vendor is different, internal design is different.
> >
> > Is it based on another SoC design then? Most new SoCs are derived from
> > some other
> > one, so it makes sense to put it into the same family. E.g. the Apple
> > M1 takes bits from
> > both Exynos and PA-Semi SoCs but has more newly added components than
> > either one.

I think it's a misnomer to call SoCs like these "based on each other".
What often happens is that a manufacturer reuses IPs between designs
since they're there, they're available and they work and there's
little reason to redo it, etc.

For cases such as a vendor building a custom SoC for a specific
customer (which, from the looks of this patchset seems to be the case
-- this is not something I say with insider information :-), it makes
sense to reuse IP blocks in the same way. It's actually a competitive
benefit of the vendor to have silicon-proven IPs in this manner.

Does this mean that this custom-built product is a part of a product
family? I don't think that's the primary conclusion I would make --
it's more complex than that. And it also doesn't make all that much of
a difference whether it's considered a family member or not. I would
be very surprised if this SoC had a Samsung marketing name, since to
my knowledge it's not sold to any other customer.

If all we're arguing here about is a toplevel compatible and a Kconfig
variable, then I don't see a need to spend a whole lot of time on this
-- as long as it's not a change that ends up proliferating the whole
source tree. I.e. if you want to create a new sub-arch, make sure it
selects or depends on EXYNOS so you don't need to sprinkle a lot of
"EXYNOS" -> "EXYNOS || TESLA" edits in the tree (as per below in the
email).

Same with the DT bindings. Can you just augment to make the tesla
vendor prefix an allowed one for the exynos bindings where it makes
sense?  Toplevel board (and SoC) compats can of course still be
independent.

> It seems Apple M1 shares only few bits with SoC. I am aware of only UART
> driver as directly re-usable.
>
> >
> > I would argue that if this SoC shares the pinctrl, clock, spi, adc,
> > and timer implementation
>
> Plus: UART, watchdog, PWM, I2C, I2S, USB PHY, DWC3 USB (in Exynos
> flavor), UFS (also in Exynos-looking flavor), MFC (video codec), some
> similarities in DW PCIe, TMU (thermal). Looking at DTS there are
> differences but just few comparing to most of shared blocks.
>
> Additionally SoC BSP (and maybe SoC itself...) was actually developed or
> co-developed by Samsung, judging by copyrights in the BSP code. Even the
> original DTSI has:
>
>         TURBO TRAV SoC device tree source
>         Copyright (c) 2017 Samsung Electronics Co., Ltd.
>
>
> Tesla could still customize it a lot, but it is a strong hint that most
> of it came from Samsung LSI and shares with existing Samsung designs.
>
> Have in mind that recent Exynos chips are significantly different than
> early ARMv7 or ARMv8 designs and we still consider them part of Exynos
> family.
>
> > with Exynos, we should consider it part of the Exynos family,
> > regardless of what other
> > blocks may exist next to those.
>
> Yes. I don't see the benefit of keeping it outside of Exynos. It will
> sprinkle "depends on ARCH_EXYNOS || ARCH_FSD" all over (or depend on
> Exynos like you suggested).

Depend or select (but select is a slippery slope so might be better
avoided) seems like a pretty good option here to me.


-Olof

Patch

diff --git a/Documentation/devicetree/bindings/arm/tesla.yaml b/Documentation/devicetree/bindings/arm/tesla.yaml
new file mode 100644
index 000000000000..9f89cde76c85
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/tesla.yaml
@@ -0,0 +1,25 @@ 
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/tesla.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tesla Full Self Driving(FSD) platforms device tree bindings
+
+maintainers:
+  - Alim Akhtar <[e-mail]>
+  - [e-mail]
+
+properties:
+  $nodename:
+    const: '/'
+  compatible:
+    oneOf:
+
+      - description: FSD SoC board
+        items:
+          - const: tesla,fsd
+
+additionalProperties: true
+
+...