[PATCH 2/4] dt-bindings: media: Add bindings for raspberrypi,rp1-cfe

Tomi Valkeinen tomi.valkeinen at ideasonboard.com
Tue Mar 19 07:03:52 PDT 2024


On 19/03/2024 15:05, Naushir Patuck wrote:
> On Tue, 19 Mar 2024 at 13:02, Krzysztof Kozlowski
> <krzysztof.kozlowski at linaro.org> wrote:
>>
>> On 19/03/2024 13:57, Naushir Patuck wrote:
>>>>>>
>>>>>> See writing bindings. Compatibles should be SoC specific. In some cases
>>>>>> generic fallbacks make sense, in some note. But don't just choose
>>>>>> "generic fallback" because you want. Provide rationale.
>>>>>
>>>>> If the compatible is SoC specific, I suppose "raspberrypi,rp1-cfe"
>>>>> would be the correct string.
>>>>
>>>> Sure, but then please think what if rp1 is on Rpi6, called exactly the
>>>> same (rp1), with some minor differences? Could it be?
>>>
>>> Yes, this is definitely possible.  In such cases, I would expect the
>>> hardware to have a version register that would be queried by the
>>> driver to adjust for minor differences, and the compatible string
>>> remains the same.  Does that seem reasonable?
>>
>> The "would expect" is concerning. The register(s) must be there already,
>> with proper value.
>>
> 
> A version register already exists in the current hardware, so we will
> update it to identify future hardware revisions.

But that's a version register for the FE block, not for the whole 
module, right? Are you suggesting that you'll make sure the FE version 
will be changed every time anything in the bigger CFE block is changed, 
and thus the FE version would also reflect the whole CFE version?

Can there be versions without the FE block, with just the CSI-2 parts?

Also, I'm still wondering about the RP1 part there in the compatible 
string. Is it necessary? The CFE is located in the RP1 co-processor, but 
is that relevant?

Is there a versioning for the whole RP1 chip? Maybe it's going to the 
wrong direction if we use the board/SoC for this compatible name, as 
it's actually the RP1 where the CFE is located in, not the SoC.

  Tomi




More information about the linux-arm-kernel mailing list