On 25/08/2025 13:37, Mukesh Ojha wrote: > On Sat, Aug 23, 2025 at 05:53:50PM +0200, Krzysztof Kozlowski wrote: >> The Qualcomm SoC Iris video codec is an evolution of previous Venus and >> it comes with its own Iris Linux drivers. These new drivers were >> accepted under condition they actually improve state of afairs, instead >> of duplicating old, legacy solutions. >> >> Unfortunately binding still references common parts of Venus without >> actual need and benefit. For example Iris does not use fake >> "video-firmware" device node (fake because there is no actual device >> underlying it and it was added only to work around some Linux issues >> with IOMMU mappings). >> >> Stop referencing venus-common schema in the new Qualcomm Iris bindings >> and move all necessary properties, except unused "video-firmware" (no >> driver usage, no DTS). >> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> >> --- >> .../devicetree/bindings/media/qcom,sm8550-iris.yaml | 13 ++++++++++++- >> 1 file changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml >> index c79bf2101812..320227f437a1 100644 >> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml >> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml >> @@ -26,6 +26,9 @@ properties: >> - qcom,sm8550-iris >> - qcom,sm8650-iris >> >> + reg: >> + maxItems: 1 >> + >> power-domains: >> maxItems: 4 >> >> @@ -45,6 +48,12 @@ properties: >> - const: core >> - const: vcodec0_core >> >> + firmware-name: >> + maxItems: 1 >> + >> + interrupts: >> + maxItems: 1 >> + >> interconnects: >> maxItems: 2 >> >> @@ -69,6 +78,9 @@ properties: >> >> dma-coherent: true >> >> + memory-region: >> + maxItems: 1 >> + >> operating-points-v2: true >> >> opp-table: >> @@ -85,7 +97,6 @@ required: >> - dma-coherent >> >> allOf: >> - - $ref: qcom,venus-common.yaml# >> - if: > > Saw your reply on > https://lore.kernel.org/lkml/59951c47-1015-4598-a885-25f8f1a27c64@xxxxxxxxxx/ > > Just trying to understand ABI here, how all of a sudden we remove a binding > for a hardware just because it did not get noticed until yet that as it is > not a real device and we always say device tree binding should not depend on > drivers but the device but we are saying Iris does not use fake "video-firmware" > device node for removal. I am a bit confused. About what? What is unclear in standard DT ABI rules? > > Whether removing will not break any ABI as initial binding enables the IRIS > related code to use video-firmware, now we are removing it. > I believe, removing binding always break ABI ? or is it depend on driver > code not using it ? There is no single user of this, out of tree (I briefly checked) and in-tree, so there is no ABI impact. I am changing the documentation of the ABI, but there is no actual ABI break because impact is 0. I am really sorry but it seems you ask about basics of DT, so please first get into docs and other existing discussions. Best regards, Krzysztof
