Re: [PATCH 1/2] dt-bindings: misc: bist: Add BIST dt-binding for TI K3 devices

[Neha Malcom Francis <n-francis@ti.com>]

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