[PATCH v13 6/8] media: dt-bindings: wave5: add Chips&Media 521c codec IP support
Sebastian Fricke
sebastian.fricke at collabora.com
Thu Oct 26 09:33:39 PDT 2023
Hey Krzysztof,
On 22.10.2023 18:12, Krzysztof Kozlowski wrote:
>On 17/10/2023 15:39, Devarsh Thakkar wrote:
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - clocks
>>> + - interrupts
>>> +
>>
>> Is it possible to keep interrupts property as optional given HW can still work
>> without it if SW does polling of ISR using registers?
>>
>> The reason to ask is in TI AM62A SoC (which also uses this codec) there is an
>> SoC errata of missing interrupt line to A53 and we are using SW based polling
>> locally to run the driver.
>>
>> We were planning to upstream that SW based polling support patch in CnM driver
>> once this base initial driver patch series gets merged, but just wanted to
>> check if upfront it is possible to have interrupts property as optional so
>> that we don't have to change the binding doc again to make it optional later on.
>>
>> Also note that the polling patch won't be specific to AM62A, other SoC's too
>> which use this wave5 hardware if they want can enable polling by choice (by
>> removing interrupt property)
>>
>> Could you please share your opinion on this ?
>
>You know, if you do not have interrupt line connected, how could it be
>required, right? If the hardware does not require interrupt to be
>connected then bindings should not require it.
Alright, so I will make the interrupt optional in the DT binding.
By simply removing it from this list:
required:
- compatible
- reg
- clocks
- interrupts
Is it possible to make it required later on for certain SoC by adding
something along the lines of:
allOf:
- if:
properties:
compatible:
contains:
enum:
- soc_compatible...
...
then:
properties:
interrupts: true
?
>
>Best regards,
>Krzysztof
Sincerely,
Sebastian
>
>_______________________________________________
>Kernel mailing list -- kernel at mailman.collabora.com
>To unsubscribe send an email to kernel-leave at mailman.collabora.com
More information about the linux-arm-kernel
mailing list