On 8/25/2025 5:32 PM, Krzysztof Kozlowski wrote: > 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. > My understanding here is that the interface "video-firmware" is already defined in the binding. There could be possible out-of-tree users of it, might not be possible for us to look into all of those out=of-tree users. I support such cleanups, but also need to understand how this is not an ABI break, just that there are no in-tree DTS user means no ABI break ? Would appreciate if you could point to any guidelines if my understanding is not correct, i am currently referring to [1] [1]https://docs.kernel.org/devicetree/bindings/ABI.html Regards, Vikash > 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
