Document the binding for TI K3 BIST (Built-In Self Test) block.
Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
.../bindings/misc/ti,j784s4-bist.yaml | 66 +++++++++++++++++++
1 file changed, 66 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
diff --git a/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
new file mode 100644
index 000000000000..bd1b42734b3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2024 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/misc/ti,j784s4-bist.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 BIST
+
+maintainers:
+ - Neha Malcom Francis <n-francis@ti.com>
+
+description:
+ The BIST (Built-In Self Test) module is an IP block present in K3 devices
+ that support triggering of BIST tests, both PBIST (Memory BIST) and LBIST
+ (Logic BIST) on a core. Both tests are destructive in nature. At boot, BIST
+ is executed by hardware for the MCU domain automatically as part of HW POST.
+
+properties:
+ compatible:
+ const: ti,j784s4-bist
+
+ reg:
+ minItems: 2
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: cfg
+ - const: ctrl_mmr
+
+ clocks:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ ti,bist-instance:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ the BIST instance in the SoC represented as an integer
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ti,bist-instance
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/soc/ti,sci_pm_domain.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ bist@33c0000 {
+ compatible = "ti,j784s4-bist";
+ reg = <0x00 0x033c0000 0x00 0x400>,
+ <0x00 0x0010c1a0 0x00 0x01c>;
+ reg-names = "cfg", "ctrl_mmr";
+ clocks = <&k3_clks 237 7>;
+ power-domains = <&k3_pds 237 TI_SCI_PD_EXCLUSIVE>;
+ ti,bist-instance = <14>;
+ };
+ };
--
2.34.1On Thu, Nov 28, 2024 at 07:38:24PM +0530, Neha Malcom Francis wrote:
> Document the binding for TI K3 BIST (Built-In Self Test) block.
>
A nit, subject: drop second/last, redundant "dt-binding". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> ---
> .../bindings/misc/ti,j784s4-bist.yaml | 66 +++++++++++++++++++
> 1 file changed, 66 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
soc directory, not misc.
>
> diff --git a/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
> new file mode 100644
> index 000000000000..bd1b42734b3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
> @@ -0,0 +1,66 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2024 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/misc/ti,j784s4-bist.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments K3 BIST
> +
> +maintainers:
> + - Neha Malcom Francis <n-francis@ti.com>
> +
> +description:
> + The BIST (Built-In Self Test) module is an IP block present in K3 devices
> + that support triggering of BIST tests, both PBIST (Memory BIST) and LBIST
> + (Logic BIST) on a core. Both tests are destructive in nature. At boot, BIST
> + is executed by hardware for the MCU domain automatically as part of HW POST.
> +
> +properties:
> + compatible:
> + const: ti,j784s4-bist
> +
> + reg:
> + minItems: 2
Drop minItems
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: cfg
> + - const: ctrl_mmr
> +
> + clocks:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + ti,bist-instance:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + the BIST instance in the SoC represented as an integer
No instance indices are allowed. Drop.
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - ti,bist-instance
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/soc/ti,sci_pm_domain.h>
> + bus {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + bist@33c0000 {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
Come with something, don't just use device name.
> + compatible = "ti,j784s4-bist";
> + reg = <0x00 0x033c0000 0x00 0x400>,
> + <0x00 0x0010c1a0 0x00 0x01c>;
Misaligned code.
Best regards,
Krzysztof
Hi Krzysztof,
On 29/11/24 12:50, Krzysztof Kozlowski wrote:
> On Thu, Nov 28, 2024 at 07:38:24PM +0530, Neha Malcom Francis wrote:
>> Document the binding for TI K3 BIST (Built-In Self Test) block.
>>
>
> A nit, subject: drop second/last, redundant "dt-binding". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
>> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
>> ---
>> .../bindings/misc/ti,j784s4-bist.yaml | 66 +++++++++++++++++++
>> 1 file changed, 66 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
>
> soc directory, not misc.
>
>>
>> diff --git a/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
>> new file mode 100644
>> index 000000000000..bd1b42734b3d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/ti,j784s4-bist.yaml
>> @@ -0,0 +1,66 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2024 Texas Instruments Incorporated
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/misc/ti,j784s4-bist.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Texas Instruments K3 BIST
>> +
>> +maintainers:
>> + - Neha Malcom Francis <n-francis@ti.com>
>> +
>> +description:
>> + The BIST (Built-In Self Test) module is an IP block present in K3 devices
>> + that support triggering of BIST tests, both PBIST (Memory BIST) and LBIST
>> + (Logic BIST) on a core. Both tests are destructive in nature. At boot, BIST
>> + is executed by hardware for the MCU domain automatically as part of HW POST.
>> +
>> +properties:
>> + compatible:
>> + const: ti,j784s4-bist
>> +
>> + reg:
>> + minItems: 2
>
> Drop minItems
>
>> + maxItems: 2
>> +
>> + reg-names:
>> + items:
>> + - const: cfg
>> + - const: ctrl_mmr
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> + power-domains:
>> + maxItems: 1
>> +
>> + ti,bist-instance:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + description:
>> + the BIST instance in the SoC represented as an integer
>
> No instance indices are allowed. Drop.
>
Question on this, this is not a property that is driven by software but rather
indicates which register sequences have to be picked up for triggering this test
from this instance. So I don't see how I can workaround this without getting
this number. Or maybe call it ID rather than instance?
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - reg-names
>> + - ti,bist-instance
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/soc/ti,sci_pm_domain.h>
>> + bus {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + bist@33c0000 {
>
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>
> Come with something, don't just use device name.
>
>> + compatible = "ti,j784s4-bist";
>> + reg = <0x00 0x033c0000 0x00 0x400>,
>> + <0x00 0x0010c1a0 0x00 0x01c>;
>
> Misaligned code.
>
> Best regards,
> Krzysztof
>
For the rest of the comments, got it! thanks for the review!
--
Thanking You
Neha Malcom Francis
On 29/11/2024 08:43, Neha Malcom Francis wrote: >>> + >>> + power-domains: >>> + maxItems: 1 >>> + >>> + ti,bist-instance: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: >>> + the BIST instance in the SoC represented as an integer >> >> No instance indices are allowed. Drop. >> > > Question on this, this is not a property that is driven by software but rather > indicates which register sequences have to be picked up for triggering this test > from this instance. So I don't see how I can workaround this without getting > this number. Or maybe call it ID rather than instance? I don't understand how the device operates, so what is exactly behind some sequences of registers for triggering this test. You described property as index or ID of one instance of the block. That's not what we want in the binding. That's said maybe other, different hardware characteristic is behind, who knows. Or maybe it's about callers... or maybe that's not hardware property at all, but runtime OS, who knows. Best regards, Krzysztof
Hi Krzysztof On 29/11/24 14:45, Krzysztof Kozlowski wrote: > On 29/11/2024 08:43, Neha Malcom Francis wrote: >>>> + >>>> + power-domains: >>>> + maxItems: 1 >>>> + >>>> + ti,bist-instance: >>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>> + description: >>>> + the BIST instance in the SoC represented as an integer >>> >>> No instance indices are allowed. Drop. >>> >> >> Question on this, this is not a property that is driven by software but rather >> indicates which register sequences have to be picked up for triggering this test >> from this instance. So I don't see how I can workaround this without getting >> this number. Or maybe call it ID rather than instance? > > I don't understand how the device operates, so what is exactly behind > some sequences of registers for triggering this test. You described > property as index or ID of one instance of the block. That's not what we > want in the binding. That's said maybe other, different hardware > characteristic is behind, who knows. Or maybe it's about callers... or > maybe that's not hardware property at all, but runtime OS, who knows. > Sorry for such a late reply, but I was hoping to get more details on this "ID" and never got back to the thread... The best way I can describe is this device (BIST) runs a safety diagnostic test on a bunch of processors/blocks (let's call them targets). There's a mapping between the instance of this device and the targets it will run the test. This ID was essentially letting the BIST driver know which are these targets. Should I perhaps trigger it the other way around; a target driver asks for it's safety test to be run by pointing to the BIST instance? However the issue with this approach is, the architecture of this safety test device is that once triggered, it will run the test on all the targets it controls and that should be reflected in the software arch as well right? Yet another way would be the BIST points out the targets it controls via their phandles in its node... but this approach would trigger the probe of these targets before the test runs on them. And in hardware, the test must run only one before the device is used, else we see indefinite behavior. > Best regards, > Krzysztof -- Thanking You Neha Malcom Francis
On 13/03/2025 12:14, Neha Malcom Francis wrote: > Hi Krzysztof > > On 29/11/24 14:45, Krzysztof Kozlowski wrote: >> On 29/11/2024 08:43, Neha Malcom Francis wrote: >>>>> + >>>>> + power-domains: >>>>> + maxItems: 1 >>>>> + >>>>> + ti,bist-instance: >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + description: >>>>> + the BIST instance in the SoC represented as an integer >>>> >>>> No instance indices are allowed. Drop. >>>> >>> >>> Question on this, this is not a property that is driven by software but rather >>> indicates which register sequences have to be picked up for triggering this test >>> from this instance. So I don't see how I can workaround this without getting >>> this number. Or maybe call it ID rather than instance? >> >> I don't understand how the device operates, so what is exactly behind >> some sequences of registers for triggering this test. You described >> property as index or ID of one instance of the block. That's not what we >> want in the binding. That's said maybe other, different hardware >> characteristic is behind, who knows. Or maybe it's about callers... or >> maybe that's not hardware property at all, but runtime OS, who knows. >> > > Sorry for such a late reply, but I was hoping to get more details on > this "ID" and never got back to the thread... > > The best way I can describe is this device (BIST) runs a safety > diagnostic test on a bunch of processors/blocks (let's call them > targets). There's a mapping between the instance of this device and the > targets it will run the test. This ID was essentially letting the BIST > driver know which are these targets. So you want to configure some target? Then this is your property. If you want to configure 'foo' difference in DT, you do not write 'bar'... Anyway, no clue, original emails are long time not in my inbox. Context disappeared also long time ago. Best regards, Krzysztof
Hi Krzysztof, On 19/03/25 13:16, Krzysztof Kozlowski wrote: > On 13/03/2025 12:14, Neha Malcom Francis wrote: >> Hi Krzysztof >> >> On 29/11/24 14:45, Krzysztof Kozlowski wrote: >>> On 29/11/2024 08:43, Neha Malcom Francis wrote: >>>>>> + >>>>>> + power-domains: >>>>>> + maxItems: 1 >>>>>> + >>>>>> + ti,bist-instance: >>>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>>> + description: >>>>>> + the BIST instance in the SoC represented as an integer >>>>> >>>>> No instance indices are allowed. Drop. >>>>> >>>> >>>> Question on this, this is not a property that is driven by software but rather >>>> indicates which register sequences have to be picked up for triggering this test >>>> from this instance. So I don't see how I can workaround this without getting >>>> this number. Or maybe call it ID rather than instance? >>> >>> I don't understand how the device operates, so what is exactly behind >>> some sequences of registers for triggering this test. You described >>> property as index or ID of one instance of the block. That's not what we >>> want in the binding. That's said maybe other, different hardware >>> characteristic is behind, who knows. Or maybe it's about callers... or >>> maybe that's not hardware property at all, but runtime OS, who knows. >>> >> >> Sorry for such a late reply, but I was hoping to get more details on >> this "ID" and never got back to the thread... >> >> The best way I can describe is this device (BIST) runs a safety >> diagnostic test on a bunch of processors/blocks (let's call them >> targets). There's a mapping between the instance of this device and the >> targets it will run the test. This ID was essentially letting the BIST >> driver know which are these targets. > > > So you want to configure some target? Then this is your property. If you > want to configure 'foo' difference in DT, you do not write 'bar'... > So the difficulty in doing this is, what I mentioned in the earlier email just copying it over again: "Yet another way would be the BIST points out the targets it controls via their phandles in its node... but this approach would trigger the probe of these targets before the test runs on them. And in hardware, the test must run only one before the device is used, else we see indefinite behavior." Property that has a list of strings (targets) instead of phandles maybe? Would that be acceptable? > Anyway, no clue, original emails are long time not in my inbox. Context > disappeared also long time ago. > Completely understand, delay from my end, sorry! > > Best regards, > Krzysztof -- Thanking You Neha Malcom Francis
On 19/03/2025 10:02, Neha Malcom Francis wrote: > Hi Krzysztof, > > On 19/03/25 13:16, Krzysztof Kozlowski wrote: >> On 13/03/2025 12:14, Neha Malcom Francis wrote: >>> Hi Krzysztof >>> >>> On 29/11/24 14:45, Krzysztof Kozlowski wrote: >>>> On 29/11/2024 08:43, Neha Malcom Francis wrote: >>>>>>> + >>>>>>> + power-domains: >>>>>>> + maxItems: 1 >>>>>>> + >>>>>>> + ti,bist-instance: >>>>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>>>> + description: >>>>>>> + the BIST instance in the SoC represented as an integer >>>>>> >>>>>> No instance indices are allowed. Drop. >>>>>> >>>>> >>>>> Question on this, this is not a property that is driven by software but rather >>>>> indicates which register sequences have to be picked up for triggering this test >>>>> from this instance. So I don't see how I can workaround this without getting >>>>> this number. Or maybe call it ID rather than instance? >>>> >>>> I don't understand how the device operates, so what is exactly behind >>>> some sequences of registers for triggering this test. You described >>>> property as index or ID of one instance of the block. That's not what we >>>> want in the binding. That's said maybe other, different hardware >>>> characteristic is behind, who knows. Or maybe it's about callers... or >>>> maybe that's not hardware property at all, but runtime OS, who knows. >>>> >>> >>> Sorry for such a late reply, but I was hoping to get more details on >>> this "ID" and never got back to the thread... >>> >>> The best way I can describe is this device (BIST) runs a safety >>> diagnostic test on a bunch of processors/blocks (let's call them >>> targets). There's a mapping between the instance of this device and the >>> targets it will run the test. This ID was essentially letting the BIST >>> driver know which are these targets. >> >> >> So you want to configure some target? Then this is your property. If you >> want to configure 'foo' difference in DT, you do not write 'bar'... >> > > So the difficulty in doing this is, what I mentioned in the earlier > email just copying it over again: > > "Yet another way would be the BIST points out the targets it controls via > their phandles in its node... but this approach would trigger the probe No, it would not. Which part of OF kernel code causes probe ordering (device links) if some random phandle appears? > of these targets before the test runs on them. And in hardware, the test > must run only one before the device is used, else we see indefinite > behavior." > > Property that has a list of strings (targets) instead of phandles maybe? > Would that be acceptable? Best regards, Krzysztof
On 24/03/25 12:53, Krzysztof Kozlowski wrote: > On 19/03/2025 10:02, Neha Malcom Francis wrote: >> Hi Krzysztof, >> >> On 19/03/25 13:16, Krzysztof Kozlowski wrote: >>> On 13/03/2025 12:14, Neha Malcom Francis wrote: >>>> Hi Krzysztof >>>> >>>> On 29/11/24 14:45, Krzysztof Kozlowski wrote: >>>>> On 29/11/2024 08:43, Neha Malcom Francis wrote: >>>>>>>> + >>>>>>>> + power-domains: >>>>>>>> + maxItems: 1 >>>>>>>> + >>>>>>>> + ti,bist-instance: >>>>>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>>>>> + description: >>>>>>>> + the BIST instance in the SoC represented as an integer >>>>>>> >>>>>>> No instance indices are allowed. Drop. >>>>>>> >>>>>> >>>>>> Question on this, this is not a property that is driven by software but rather >>>>>> indicates which register sequences have to be picked up for triggering this test >>>>>> from this instance. So I don't see how I can workaround this without getting >>>>>> this number. Or maybe call it ID rather than instance? >>>>> >>>>> I don't understand how the device operates, so what is exactly behind >>>>> some sequences of registers for triggering this test. You described >>>>> property as index or ID of one instance of the block. That's not what we >>>>> want in the binding. That's said maybe other, different hardware >>>>> characteristic is behind, who knows. Or maybe it's about callers... or >>>>> maybe that's not hardware property at all, but runtime OS, who knows. >>>>> >>>> >>>> Sorry for such a late reply, but I was hoping to get more details on >>>> this "ID" and never got back to the thread... >>>> >>>> The best way I can describe is this device (BIST) runs a safety >>>> diagnostic test on a bunch of processors/blocks (let's call them >>>> targets). There's a mapping between the instance of this device and the >>>> targets it will run the test. This ID was essentially letting the BIST >>>> driver know which are these targets. >>> >>> >>> So you want to configure some target? Then this is your property. If you >>> want to configure 'foo' difference in DT, you do not write 'bar'... >>> >> >> So the difficulty in doing this is, what I mentioned in the earlier >> email just copying it over again: >> >> "Yet another way would be the BIST points out the targets it controls via >> their phandles in its node... but this approach would trigger the probe > > No, it would not. Which part of OF kernel code causes probe ordering > (device links) if some random phandle appears? Going through device links now, I realize I may have come to the wrong conclusion while writing the driver. Let me try to respin the driver using this approach then post which I will resume this series. > >> of these targets before the test runs on them. And in hardware, the test >> must run only one before the device is used, else we see indefinite >> behavior." >> >> Property that has a list of strings (targets) instead of phandles maybe? >> Would that be acceptable? > > > > Best regards, > Krzysztof -- Thanking You Neha Malcom Francis
© 2016 - 2026 Red Hat, Inc.