| Message ID | 20250613140402.3619465-2-jorge.ramirez@oss.qualcomm.com |
|---|---|
| State | New |
| Headers | show |
| Series | media: venus: Add QCM2290 support with AR50_LITE core | expand |
On 13/06/2025 15:03, Jorge Ramirez-Ortiz wrote: > + video-decoder { > + compatible = "venus-decoder"; > + }; > + > + video-encoder { > + compatible = "venus-encoder"; > + }; Not necessary, drop. --- bod
On 13/06/25 15:20:57, Bryan O'Donoghue wrote: > On 13/06/2025 15:03, Jorge Ramirez-Ortiz wrote: > > + video-decoder { > > + compatible = "venus-decoder"; > > + }; > > + > > + video-encoder { > > + compatible = "venus-encoder"; > > + }; > > Not necessary, drop. ok > > --- > bod
On 16/06/2025 14:52, Jorge Ramirez wrote: >> >>> + The Venus AR50_LITE IP is a video encode and decode accelerator present >>> + on Qualcomm platforms >>> + >>> +allOf: >>> + - $ref: qcom,venus-common.yaml# >>> + >>> +properties: >>> + compatible: >>> + const: qcom,qcm2290-venus >>> + >>> + power-domains: >>> + minItems: 2 >>> + maxItems: 3 >>> + >>> + power-domain-names: >>> + minItems: 2 >> >> Why is this flexible? Either you have two or three. Not mixed. > > please check 5b380f242f360256c96e96adabeb7ce9ec784306 This does not explain why this is optional HERE. You cannot use for a new platform an argument that some existing platform was changed in ABI-preserving way. BTW, also subject prefixes needs fixing. For DTS: it is never "arch". For this patch: wrong order (see DT submitting patches). Best regards, Krzysztof
On 16/06/25 18:23:18, Krzysztof Kozlowski wrote: > On 16/06/2025 18:18, Jorge Ramirez wrote: > > On 16/06/25 16:41:44, Krzysztof Kozlowski wrote: > >> On 16/06/2025 14:52, Jorge Ramirez wrote: > >>>> > >>>>> + The Venus AR50_LITE IP is a video encode and decode accelerator present > >>>>> + on Qualcomm platforms > >>>>> + > >>>>> +allOf: > >>>>> + - $ref: qcom,venus-common.yaml# > >>>>> + > >>>>> +properties: > >>>>> + compatible: > >>>>> + const: qcom,qcm2290-venus > >>>>> + > >>>>> + power-domains: > >>>>> + minItems: 2 > >>>>> + maxItems: 3 > >>>>> + > >>>>> + power-domain-names: > >>>>> + minItems: 2 > >>>> > >>>> Why is this flexible? Either you have two or three. Not mixed. > >>> > >>> please check 5b380f242f360256c96e96adabeb7ce9ec784306 > >> > >> This does not explain why this is optional HERE. You cannot use for a > >> new platform an argument that some existing platform was changed in > >> ABI-preserving way. > > > > thanks for quick the follow up. > > > > but bear with me please because I dont follow - why can the same logic > > be used - it being applicable - and therefore result in a definition > > similar to those other platforms? > > Because this platform either has 2 or 3, not both. Unless that's not > true, but then please share some arguments. as with every other venus schema with more than 1 power domain, the argument is the same one that I have shared with you a couple of messages back (DVFS). verbatim: Venus needs to vote for the performance state of a power domain (cx) to be able to support DVFS. This 'cx' power domain is controlled by rpm and is a common power domain (scalable) not specific to venus alone. This is optional in the sense that, leaving this power domain out does not really impact the functionality but just makes the platform a little less power efficient. Seeing all these venus schemas follow the same pattern, it seems to me that this is the correct way of implementing the above. You seem to disagree. please could you explain? > > Best regards, > Krzysztof
On 16/06/2025 18:59, Jorge Ramirez wrote: > On 16/06/25 18:23:18, Krzysztof Kozlowski wrote: >> On 16/06/2025 18:18, Jorge Ramirez wrote: >>> On 16/06/25 16:41:44, Krzysztof Kozlowski wrote: >>>> On 16/06/2025 14:52, Jorge Ramirez wrote: >>>>>> >>>>>>> + The Venus AR50_LITE IP is a video encode and decode accelerator present >>>>>>> + on Qualcomm platforms >>>>>>> + >>>>>>> +allOf: >>>>>>> + - $ref: qcom,venus-common.yaml# >>>>>>> + >>>>>>> +properties: >>>>>>> + compatible: >>>>>>> + const: qcom,qcm2290-venus >>>>>>> + >>>>>>> + power-domains: >>>>>>> + minItems: 2 >>>>>>> + maxItems: 3 >>>>>>> + >>>>>>> + power-domain-names: >>>>>>> + minItems: 2 >>>>>> >>>>>> Why is this flexible? Either you have two or three. Not mixed. >>>>> >>>>> please check 5b380f242f360256c96e96adabeb7ce9ec784306 >>>> >>>> This does not explain why this is optional HERE. You cannot use for a >>>> new platform an argument that some existing platform was changed in >>>> ABI-preserving way. >>> >>> thanks for quick the follow up. >>> >>> but bear with me please because I dont follow - why can the same logic >>> be used - it being applicable - and therefore result in a definition >>> similar to those other platforms? >> >> Because this platform either has 2 or 3, not both. Unless that's not >> true, but then please share some arguments. > > as with every other venus schema with more than 1 power domain, the > argument is the same one that I have shared with you a couple of > messages back (DVFS). > > verbatim: > Venus needs to vote for the performance state of a power domain (cx) > to be able to support DVFS. This 'cx' power domain is controlled by > rpm and is a common power domain (scalable) not specific to > venus alone. This is optional in the sense that, leaving this power > domain out does not really impact the functionality but just makes > the platform a little less power efficient. That's not definition of optional. The domain is needed for this device, the device is one way or another having its rails routed to that domain. It is not optional. > > Seeing all these venus schemas follow the same pattern, it seems to me > that this is the correct way of implementing the above. No for the reason I mentioned earlier. > > You seem to disagree. please could you explain? I already explained. You add new device, so argument to preserve ABI, which was accepted THAT TIME, is not valid. You do not have ABI. Best regards, Krzysztof
On 17/06/25 08:14:23, Krzysztof Kozlowski wrote: > On 16/06/2025 18:59, Jorge Ramirez wrote: > > On 16/06/25 18:23:18, Krzysztof Kozlowski wrote: > >> On 16/06/2025 18:18, Jorge Ramirez wrote: > >>> On 16/06/25 16:41:44, Krzysztof Kozlowski wrote: > >>>> On 16/06/2025 14:52, Jorge Ramirez wrote: > >>>>>> > >>>>>>> + The Venus AR50_LITE IP is a video encode and decode accelerator present > >>>>>>> + on Qualcomm platforms > >>>>>>> + > >>>>>>> +allOf: > >>>>>>> + - $ref: qcom,venus-common.yaml# > >>>>>>> + > >>>>>>> +properties: > >>>>>>> + compatible: > >>>>>>> + const: qcom,qcm2290-venus > >>>>>>> + > >>>>>>> + power-domains: > >>>>>>> + minItems: 2 > >>>>>>> + maxItems: 3 > >>>>>>> + > >>>>>>> + power-domain-names: > >>>>>>> + minItems: 2 > >>>>>> > >>>>>> Why is this flexible? Either you have two or three. Not mixed. > >>>>> > >>>>> please check 5b380f242f360256c96e96adabeb7ce9ec784306 > >>>> > >>>> This does not explain why this is optional HERE. You cannot use for a > >>>> new platform an argument that some existing platform was changed in > >>>> ABI-preserving way. > >>> > >>> thanks for quick the follow up. > >>> > >>> but bear with me please because I dont follow - why can the same logic > >>> be used - it being applicable - and therefore result in a definition > >>> similar to those other platforms? > >> > >> Because this platform either has 2 or 3, not both. Unless that's not > >> true, but then please share some arguments. > > > > as with every other venus schema with more than 1 power domain, the > > argument is the same one that I have shared with you a couple of > > messages back (DVFS). > > > > verbatim: > > Venus needs to vote for the performance state of a power domain (cx) > > to be able to support DVFS. This 'cx' power domain is controlled by > > rpm and is a common power domain (scalable) not specific to > > venus alone. This is optional in the sense that, leaving this power > > domain out does not really impact the functionality but just makes > > the platform a little less power efficient. > > That's not definition of optional. The domain is needed for this device, > the device is one way or another having its rails routed to that domain. > It is not optional. > > > > > Seeing all these venus schemas follow the same pattern, it seems to me > > that this is the correct way of implementing the above. > > No for the reason I mentioned earlier. So just to close this story up, were these two commits wrongly reviewed and signed off then ? Please do notice they were also - just like this one - new additions and not a change in an ABI preserving way as you characterize them. e48b839b6699c2268e545360e06962bb76ff5b8d 8d3a1cb32124eaeb3f2efe4889de214d3b658d8d > > > > > You seem to disagree. please could you explain? > > I already explained. You add new device, so argument to preserve ABI, > which was accepted THAT TIME, is not valid. You do not have ABI. as per the two commits above, this is not an argument to 'presereve' an ABI - this looks to me like an implementation. anyhow, if everyone agrees this is the only way to move this forward will do just fix this to three then. please let me know. > > > Best regards, > Krzysztof
On 17/06/2025 08:47, Jorge Ramirez wrote: > On 17/06/25 08:14:23, Krzysztof Kozlowski wrote: >> On 16/06/2025 18:59, Jorge Ramirez wrote: >>> On 16/06/25 18:23:18, Krzysztof Kozlowski wrote: >>>> On 16/06/2025 18:18, Jorge Ramirez wrote: >>>>> On 16/06/25 16:41:44, Krzysztof Kozlowski wrote: >>>>>> On 16/06/2025 14:52, Jorge Ramirez wrote: >>>>>>>> >>>>>>>>> + The Venus AR50_LITE IP is a video encode and decode accelerator present >>>>>>>>> + on Qualcomm platforms >>>>>>>>> + >>>>>>>>> +allOf: >>>>>>>>> + - $ref: qcom,venus-common.yaml# >>>>>>>>> + >>>>>>>>> +properties: >>>>>>>>> + compatible: >>>>>>>>> + const: qcom,qcm2290-venus >>>>>>>>> + >>>>>>>>> + power-domains: >>>>>>>>> + minItems: 2 >>>>>>>>> + maxItems: 3 >>>>>>>>> + >>>>>>>>> + power-domain-names: >>>>>>>>> + minItems: 2 >>>>>>>> >>>>>>>> Why is this flexible? Either you have two or three. Not mixed. >>>>>>> >>>>>>> please check 5b380f242f360256c96e96adabeb7ce9ec784306 >>>>>> >>>>>> This does not explain why this is optional HERE. You cannot use for a >>>>>> new platform an argument that some existing platform was changed in >>>>>> ABI-preserving way. >>>>> >>>>> thanks for quick the follow up. >>>>> >>>>> but bear with me please because I dont follow - why can the same logic >>>>> be used - it being applicable - and therefore result in a definition >>>>> similar to those other platforms? >>>> >>>> Because this platform either has 2 or 3, not both. Unless that's not >>>> true, but then please share some arguments. >>> >>> as with every other venus schema with more than 1 power domain, the >>> argument is the same one that I have shared with you a couple of >>> messages back (DVFS). >>> >>> verbatim: >>> Venus needs to vote for the performance state of a power domain (cx) >>> to be able to support DVFS. This 'cx' power domain is controlled by >>> rpm and is a common power domain (scalable) not specific to >>> venus alone. This is optional in the sense that, leaving this power >>> domain out does not really impact the functionality but just makes >>> the platform a little less power efficient. >> >> That's not definition of optional. The domain is needed for this device, >> the device is one way or another having its rails routed to that domain. >> It is not optional. >> >>> >>> Seeing all these venus schemas follow the same pattern, it seems to me >>> that this is the correct way of implementing the above. >> >> No for the reason I mentioned earlier. > > So just to close this story up, were these two commits wrongly > reviewed and signed off then ? Please do notice they were also - just > like this one - new additions and not a change in an ABI preserving way > as you characterize them. > > e48b839b6699c2268e545360e06962bb76ff5b8d > 8d3a1cb32124eaeb3f2efe4889de214d3b658d8d I was waiting for this argument: there was something similar some years ago (but even months ago...) and it got reviewed, so I can do the same. You can even go further back. Take commits for DT bindings from 2013 and use that against our new review. So many different things were accepted in 2013. You can take any driver code from 2013. Huh, people actually do! People still send .owner=THIS_MODULE. In 2013 this was reviewed and accepted, so I can send it, right? And then people are not happy that they patches receive too much detailed review or review takes too much time or whatever other reason... Yeah if any review you ever give will be some day used against you, you would think 10 times and be 10 times more picky then necessary. This is like an ultimate, super, triple combo argument against reviewers and maintainers to discredit their work. I will not play such games. Best regards, Krzysztof
On 17/06/25 08:56:37, Krzysztof Kozlowski wrote: > On 17/06/2025 08:47, Jorge Ramirez wrote: > > On 17/06/25 08:14:23, Krzysztof Kozlowski wrote: > >> On 16/06/2025 18:59, Jorge Ramirez wrote: > >>> On 16/06/25 18:23:18, Krzysztof Kozlowski wrote: > >>>> On 16/06/2025 18:18, Jorge Ramirez wrote: > >>>>> On 16/06/25 16:41:44, Krzysztof Kozlowski wrote: > >>>>>> On 16/06/2025 14:52, Jorge Ramirez wrote: > >>>>>>>> > >>>>>>>>> + The Venus AR50_LITE IP is a video encode and decode accelerator present > >>>>>>>>> + on Qualcomm platforms > >>>>>>>>> + > >>>>>>>>> +allOf: > >>>>>>>>> + - $ref: qcom,venus-common.yaml# > >>>>>>>>> + > >>>>>>>>> +properties: > >>>>>>>>> + compatible: > >>>>>>>>> + const: qcom,qcm2290-venus > >>>>>>>>> + > >>>>>>>>> + power-domains: > >>>>>>>>> + minItems: 2 > >>>>>>>>> + maxItems: 3 > >>>>>>>>> + > >>>>>>>>> + power-domain-names: > >>>>>>>>> + minItems: 2 > >>>>>>>> > >>>>>>>> Why is this flexible? Either you have two or three. Not mixed. > >>>>>>> > >>>>>>> please check 5b380f242f360256c96e96adabeb7ce9ec784306 > >>>>>> > >>>>>> This does not explain why this is optional HERE. You cannot use for a > >>>>>> new platform an argument that some existing platform was changed in > >>>>>> ABI-preserving way. > >>>>> > >>>>> thanks for quick the follow up. > >>>>> > >>>>> but bear with me please because I dont follow - why can the same logic > >>>>> be used - it being applicable - and therefore result in a definition > >>>>> similar to those other platforms? > >>>> > >>>> Because this platform either has 2 or 3, not both. Unless that's not > >>>> true, but then please share some arguments. > >>> > >>> as with every other venus schema with more than 1 power domain, the > >>> argument is the same one that I have shared with you a couple of > >>> messages back (DVFS). > >>> > >>> verbatim: > >>> Venus needs to vote for the performance state of a power domain (cx) > >>> to be able to support DVFS. This 'cx' power domain is controlled by > >>> rpm and is a common power domain (scalable) not specific to > >>> venus alone. This is optional in the sense that, leaving this power > >>> domain out does not really impact the functionality but just makes > >>> the platform a little less power efficient. > >> > >> That's not definition of optional. The domain is needed for this device, > >> the device is one way or another having its rails routed to that domain. > >> It is not optional. > >> > >>> > >>> Seeing all these venus schemas follow the same pattern, it seems to me > >>> that this is the correct way of implementing the above. > >> > >> No for the reason I mentioned earlier. > > > > So just to close this story up, were these two commits wrongly > > reviewed and signed off then ? Please do notice they were also - just > > like this one - new additions and not a change in an ABI preserving way > > as you characterize them. > > > > e48b839b6699c2268e545360e06962bb76ff5b8d > > 8d3a1cb32124eaeb3f2efe4889de214d3b658d8d > > I was waiting for this argument: there was something similar some years > ago (but even months ago...) and it got reviewed, so I can do the same. > how could you not? two opposing schema views can not be right. If you knew this, you should have raised. There is only so many hours in a day. > You can even go further back. Take commits for DT bindings from 2013 and > use that against our new review. So many different things were accepted > in 2013. > > You can take any driver code from 2013. Huh, people actually do! People > still send .owner=THIS_MODULE. In 2013 this was reviewed and accepted, > so I can send it, right? > > And then people are not happy that they patches receive too much > detailed review or review takes too much time or whatever other > reason... Yeah if any review you ever give will be some day used against > you, you would think 10 times and be 10 times more picky then necessary. > > This is like an ultimate, super, triple combo argument against reviewers > and maintainers to discredit their work. I will not play such games. huh? You are overthinking this: I have zero interest on evaluating anyones work; however I need to make sure we do the right thing when merging this - discussing previous interpretations in search of a coherent story is not "discrediting" but the obvious thing to do (do not assume malice let alone throw straw-man my way). What you are asking me to do is not consistent with what has been done in the past: since those commits were signed by well known maintainers just as yourself I needed to understand the delta as well as making sure everyone is aligned. I understood your point, but I also understood theirs as being accepted. hence I need someone to confirm which way to go. if that someone is yourself, just confirm it and I'll move forward.
On 17/06/2025 09:30, Jorge Ramirez wrote: > On 17/06/25 08:56:37, Krzysztof Kozlowski wrote: >> On 17/06/2025 08:47, Jorge Ramirez wrote: >>> On 17/06/25 08:14:23, Krzysztof Kozlowski wrote: >>>> On 16/06/2025 18:59, Jorge Ramirez wrote: >>>>> On 16/06/25 18:23:18, Krzysztof Kozlowski wrote: >>>>>> On 16/06/2025 18:18, Jorge Ramirez wrote: >>>>>>> On 16/06/25 16:41:44, Krzysztof Kozlowski wrote: >>>>>>>> On 16/06/2025 14:52, Jorge Ramirez wrote: >>>>>>>>>> >>>>>>>>>>> + The Venus AR50_LITE IP is a video encode and decode accelerator present >>>>>>>>>>> + on Qualcomm platforms >>>>>>>>>>> + >>>>>>>>>>> +allOf: >>>>>>>>>>> + - $ref: qcom,venus-common.yaml# >>>>>>>>>>> + >>>>>>>>>>> +properties: >>>>>>>>>>> + compatible: >>>>>>>>>>> + const: qcom,qcm2290-venus >>>>>>>>>>> + >>>>>>>>>>> + power-domains: >>>>>>>>>>> + minItems: 2 >>>>>>>>>>> + maxItems: 3 >>>>>>>>>>> + >>>>>>>>>>> + power-domain-names: >>>>>>>>>>> + minItems: 2 >>>>>>>>>> >>>>>>>>>> Why is this flexible? Either you have two or three. Not mixed. >>>>>>>>> >>>>>>>>> please check 5b380f242f360256c96e96adabeb7ce9ec784306 >>>>>>>> >>>>>>>> This does not explain why this is optional HERE. You cannot use for a >>>>>>>> new platform an argument that some existing platform was changed in >>>>>>>> ABI-preserving way. >>>>>>> >>>>>>> thanks for quick the follow up. >>>>>>> >>>>>>> but bear with me please because I dont follow - why can the same logic >>>>>>> be used - it being applicable - and therefore result in a definition >>>>>>> similar to those other platforms? >>>>>> >>>>>> Because this platform either has 2 or 3, not both. Unless that's not >>>>>> true, but then please share some arguments. >>>>> >>>>> as with every other venus schema with more than 1 power domain, the >>>>> argument is the same one that I have shared with you a couple of >>>>> messages back (DVFS). >>>>> >>>>> verbatim: >>>>> Venus needs to vote for the performance state of a power domain (cx) >>>>> to be able to support DVFS. This 'cx' power domain is controlled by >>>>> rpm and is a common power domain (scalable) not specific to >>>>> venus alone. This is optional in the sense that, leaving this power >>>>> domain out does not really impact the functionality but just makes >>>>> the platform a little less power efficient. >>>> >>>> That's not definition of optional. The domain is needed for this device, >>>> the device is one way or another having its rails routed to that domain. >>>> It is not optional. >>>> >>>>> >>>>> Seeing all these venus schemas follow the same pattern, it seems to me >>>>> that this is the correct way of implementing the above. >>>> >>>> No for the reason I mentioned earlier. >>> >>> So just to close this story up, were these two commits wrongly >>> reviewed and signed off then ? Please do notice they were also - just >>> like this one - new additions and not a change in an ABI preserving way >>> as you characterize them. >>> >>> e48b839b6699c2268e545360e06962bb76ff5b8d >>> 8d3a1cb32124eaeb3f2efe4889de214d3b658d8d >> >> I was waiting for this argument: there was something similar some years >> ago (but even months ago...) and it got reviewed, so I can do the same. Waiting and hoping discussion will end earlier... but I guess I should anticipate your arguments and find preemptively some commits from 4 years ago. Well, I have just 100 patches on patchwork with status "Needs Review", so I will not go through past commits anticipating other persons arguments when reviewing that person's patches. Help in reviews is always appreciated, especially if by any chance you are unhappy with me not having time to bring past commits into the review discussions. Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml new file mode 100644 index 000000000000..ffa72f1e27f3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml @@ -0,0 +1,153 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,qcm2290-venus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QCM2290 Venus video encode and decode accelerators + +maintainers: + - Stanimir Varbanov <stanimir.varbanov@linaro.org> + +description: | + The Venus AR50_LITE IP is a video encode and decode accelerator present + on Qualcomm platforms + +allOf: + - $ref: qcom,venus-common.yaml# + +properties: + compatible: + const: qcom,qcm2290-venus + + power-domains: + minItems: 2 + maxItems: 3 + + power-domain-names: + minItems: 2 + items: + - const: venus + - const: vcodec0 + - const: cx + + clocks: + maxItems: 6 + + clock-names: + items: + - const: core + - const: iface + - const: bus + - const: throttle + - const: vcodec0_core + - const: vcodec0_bus + + iommus: + minItems: 1 + maxItems: 5 + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: video-mem + - const: cpu-cfg + + operating-points-v2: true + opp-table: + type: object + + video-decoder: + type: object + + properties: + compatible: + const: venus-decoder + + required: + - compatible + + deprecated: true + additionalProperties: false + + video-encoder: + type: object + + properties: + compatible: + const: venus-encoder + + required: + - compatible + + deprecated: true + additionalProperties: false + +required: + - compatible + - power-domain-names + - iommus + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,gcc-qcm2290.h> + #include <dt-bindings/interconnect/qcom,qcm2290.h> + #include <dt-bindings/interconnect/qcom,rpm-icc.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + venus: video-codec@5a00000 { + compatible = "qcom,qcm2290-venus"; + reg = <0x5a00000 0xff000>; + interrupts = <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>; + + power-domains = <&gcc GCC_VENUS_GDSC>, + <&gcc GCC_VCODEC0_GDSC>, + <&rpmpd QCM2290_VDDCX>; + power-domain-names = "venus", "vcodec0", "cx"; + operating-points-v2 = <&venus_opp_table>; + + clocks = <&gcc GCC_VIDEO_VENUS_CTL_CLK>, + <&gcc GCC_VIDEO_AHB_CLK>, + <&gcc GCC_VENUS_CTL_AXI_CLK>, + <&gcc GCC_VIDEO_THROTTLE_CORE_CLK>, + <&gcc GCC_VIDEO_VCODEC0_SYS_CLK>, + <&gcc GCC_VCODEC0_AXI_CLK>; + clock-names = "core", "iface", "bus", "throttle", + "vcodec0_core", "vcodec0_bus"; + + memory-region = <&pil_video_mem>; + iommus = <&apps_smmu 0x860 0x0>, + <&apps_smmu 0x880 0x0>, + <&apps_smmu 0x861 0x04>, + <&apps_smmu 0x863 0x0>, + <&apps_smmu 0x804 0xE0>; + + interconnects = <&mmnrt_virt MASTER_VIDEO_P0 0 &bimc SLAVE_EBI1 0>, + <&bimc MASTER_APPSS_PROC 0 &config_noc SLAVE_VENUS_CFG 0>; + interconnect-names = "video-mem", "cpu-cfg"; + + venus_opp_table: opp-table { + compatible = "operating-points-v2"; + opp-133000000 { + opp-hz = /bits/ 64 <133000000>; + required-opps = <&rpmpd_opp_low_svs>; + }; + opp-240000000 { + opp-hz = /bits/ 64 <240000000>; + required-opps = <&rpmpd_opp_svs>; + }; + }; + + video-decoder { + compatible = "venus-decoder"; + }; + + video-encoder { + compatible = "venus-encoder"; + }; + };
Add a schema for the venus video encoder/decoder on the qcm2290. Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> --- .../bindings/media/qcom,qcm2290-venus.yaml | 153 ++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml