.../devicetree/bindings/media/qcom,sm8550-iris.yaml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
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@linaro.org>
---
.../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:
properties:
compatible:
--
2.48.1On 8/23/2025 9:23 PM, 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@linaro.org> > --- > .../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: > properties: > compatible: Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
On 23/08/2025 17:53, 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@linaro.org> > --- > .../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: > properties: > compatible: Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
On Sat, 23 Aug 2025 17:53:50 +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@linaro.org> > --- > .../devicetree/bindings/media/qcom,sm8550-iris.yaml | 13 ++++++++++++- > 1 file changed, 12 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
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@linaro.org> > --- > .../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@kernel.org/ 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. 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 ? > properties: > compatible: > -- > 2.48.1 > -- -Mukesh Ojha
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@linaro.org> >> --- >> .../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@kernel.org/ > > 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
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@linaro.org> >>> --- >>> .../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@kernel.org/ >> >> 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
On 28/08/2025 15:49, Vikash Garodia wrote: >>> >>> 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 There are no such. > possible for us to look into all of those out=of-tree users. We both know there are no such so you claiming "maybe not possible" is quite misleading. Qualcomm does not use it and that's the only possible case. We can verify it and I did verify this. > I support such cleanups, but also need to understand how this is not an ABI You are just making up fake obstacles. > 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] There are hundreds of discussions describing this and I am not going to do your homework. In none of other qcom media camss/iris/venus patches affecting ABI you raised that problem. Even remotely, so I cannot understand these questions here differently than just spreading some sort of FUD over this patch just to keep that broken video-firmware design for future users. >> I am really sorry but it seems you ask about basics of DT, so please >> first get into docs and other existing discussions. Again, read the docs and existing discussions. I am not going to do your homework. Best regards, Krzysztof
On 8/28/25 3:57 PM, Krzysztof Kozlowski wrote: > On 28/08/2025 15:49, Vikash Garodia wrote: >>>> >>>> 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 > > There are no such. I believe the confusion here comes from the requirement that was set out for the iris driver to support existing (venus-supported) platforms without binding alterations Bindings for SM8550 Iris (as in, the hardware block) only came out with the iris driver, so there was no legacy to support in this case Konrad
On 8/28/2025 7:27 PM, Krzysztof Kozlowski wrote: > On 28/08/2025 15:49, Vikash Garodia wrote: >>>> >>>> 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 > > There are no such. > >> possible for us to look into all of those out=of-tree users. > > We both know there are no such so you claiming "maybe not possible" is > quite misleading. Qualcomm does not use it and that's the only possible > case. We can verify it and I did verify this. > there are no such known to me either, maybe i would take this as a sufficiency check to drop/deprecate an interface. >> I support such cleanups, but also need to understand how this is not an ABI > > You are just making up fake obstacles. > > >> 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] > > There are hundreds of discussions describing this and I am not going to > do your homework. > > In none of other qcom media camss/iris/venus patches affecting ABI you > raised that problem. Even remotely, so I cannot understand these > questions here differently than just spreading some sort of FUD over > this patch just to keep that broken video-firmware design for future users. As i said earlier, we can find alternatives to video-firmware, its fine. I am not bringing this discussion to support retaining video-firmware. > >>> I am really sorry but it seems you ask about basics of DT, so please >>> first get into docs and other existing discussions. > > Again, read the docs and existing discussions. I am not going to do your > homework. The doc i pointed earlier does not capture any such case, hence was requesting you to point any doc. > > Best regards, > Krzysztof
On 28/08/2025 15:57, Krzysztof Kozlowski wrote: > >> 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] > > There are hundreds of discussions describing this and I am not going to > do your homework. > > In none of other qcom media camss/iris/venus patches affecting ABI you And the proof that you talk about ABI only when it is convenient for you - where are any comments from you in these threads affecting ABI: https://lore.kernel.org/all/20250121120901.1841142-2-quic_vikramsa@quicinc.com/ v1-v6: https://lore.kernel.org/all/20241209-media-staging-24-11-25-rb3-hw-compat-string-v5-3-ef7e5f85f302@linaro.org/ https://lore.kernel.org/all/20211206151811.39271-3-robert.foss@linaro.org/ https://lore.kernel.org/all/20250426-b4-media-committers-25-04-25-camss-supplies-v3-1-19e5e72ffc3e@linaro.org/ > raised that problem. Even remotely, so I cannot understand these > questions here differently than just spreading some sort of FUD over > this patch just to keep that broken video-firmware design for future users. Best regards, Krzysztof
On Mon, Aug 25, 2025 at 02:02:56PM +0200, 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@linaro.org> > >> --- > >> .../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@kernel.org/ > > > > 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? > i.e., If a driver is not using a particular binding at any time, its binding can be removed. > > > > 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. Something is unclear, that is why you are willing to change. > > I am really sorry but it seems you ask about basics of DT, so please > first get into docs and other existing discussions. You are right, I'm learning and not an expert. > > Best regards, > Krzysztof -- -Mukesh Ojha
© 2016 - 2025 Red Hat, Inc.