arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++ arch/arm64/boot/dts/qcom/qcs615.dtsi | 78 ++++++++++++++++++++++++++ drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++----- 3 files changed, 121 insertions(+), 14 deletions(-)
QCS615 uses the same video core as SC7180, so reuse the same resource
data of SC7180 for QCS615 to enable video functionality.
There are no resources for the video-decoder and video-encoder nodes
in the device tree, so remove these two nodes from the device tree. In
addition, to ensure that the video codec functions properly, use [3]
to add encoder and decoder node entries in the venus driver.
Validated this series on QCS615 and SC7180.
Note:
This series consist of DT patches and a venus driver patch. The patch
1/3, which is venus driver patch, can be picked independently without
having any functional dependency. But patch 2/3 & patch 3/3, which are
DT patches, still depend on [1].
[1] https://lore.kernel.org/all/20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com
Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
---
Changes in v8:
- 1. Add missing tags.
- 2. Fix the dependency to point to videoCC series alone.
- 3. Fix review comments from Konrad.
- Link to v7: https://lore.kernel.org/r/20250527-add-venus-for-qcs615-v7-0-cca26e2768e3@quicinc.com
Changes in v7:
- 1. Update devicetree patch to fix the cherry-pick patch conflict issue.
- 2. Remove dt-bindings patch from this patch series due to it has been
picked.
- Link to v6: https://lore.kernel.org/r/20241219-add-venus-for-qcs615-v6-0-e9a74d3b003d@quicinc.com
Changes in v6:
- 1. Remove video-decoder and video-encoder nodes from the device tree
- 2. Add a new dependency.
- 3. Fix missing tag.
- 4. Update commit message.
- Link to v5: https://lore.kernel.org/r/20241217-add-venus-for-qcs615-v5-0-747395d9e630@quicinc.com
Changes in v5:
- 1. Remove extra blank lines in yaml files.
- 2. Add new variables in the driver while keeping the order of the
original variables. And remove unnecessary variable initialization.
- 3. Update commit message.
- 4. Update the order of nodes in the device tree.
- Link to v4: https://lore.kernel.org/r/20241213-add-venus-for-qcs615-v4-0-7e2c9a72d309@quicinc.com
Changes in v4:
- 1. Remove qcom,qcs615-venus.yaml and use qcom,sc7180-venus.yaml for
qcs615 dt-bindings.
- 2. Add "qcom,qcs615-venus" compatible into qcom,sc7180-venus.yaml.
- 3. Remove qcs615 resource from the driver and use sc7180 resource for
the qcs615.
- 4. Use the frequency in the opp-table in devicetree for the driver.
For compatibility, if getting data from the opp table fails, the data
in the frequency table will be used.
- 5. Keep the reverse Christmas tree order coding style.
- 6. Add "qcom,sc7180-venus" compatible in devicetree.
- 7. Update cover letter message.
- Link to v3: https://lore.kernel.org/r/20241125-add-venus-for-qcs615-v3-0-5a376b97a68e@quicinc.com
Changes in v3:
- 1. Remove the ‘|’ after 'description' in the qcom,qcs615-venus.yaml.
- 2. Add a blank line before 'opp-table' in the qcom,qcs615-venus.yaml.
- 3. Put ‘additionalProperties’ before ‘properties’ in the
qcom,qcs615-venus.yaml.
- 4. Update the subject of qcom,qcs615-venus.yaml patch.
- Link to v2: https://lore.kernel.org/r/20241112-add-venus-for-qcs615-v2-0-e67947f957af@quicinc.com
Changes in v2:
- 1. The change-id of DT and driver are removed.
- 2. Add qcom,qcs615-venus.yaml files to explain DT.
- 3. The order of driver's commit and DT's commit is adjusted. Place the
driver's commit before the DT's commit.
- 4. Extends driver's commit message.
- 5. Split DT's commit into two commits. Add the venus node to the
qcs615.dtsi file. Then in the qcs615-ride.dts file enable the venus node.
- 6. Modify alignment, sort, upper and lower case letters issue.
- 7. Update cover letter message description.
- Link to v1: https://lore.kernel.org/r/20241008-add_qcs615_video-v1-0-436ce07bfc63@quicinc.com
---
Renjiang Han (3):
media: venus: pm_helpers: use opp-table for the frequency
arm64: dts: qcom: qcs615: add venus node to devicetree
arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec
arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++
arch/arm64/boot/dts/qcom/qcs615.dtsi | 78 ++++++++++++++++++++++++++
drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++-----
3 files changed, 121 insertions(+), 14 deletions(-)
---
base-commit: 176e917e010cb7dcc605f11d2bc33f304292482b
change-id: 20250526-add-venus-for-qcs615-a547540656d1
prerequisite-message-id: <20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com>
prerequisite-patch-id: afd2dce9e6066b1f6ce0b41ceafe0dd47ad97c40
prerequisite-patch-id: f8d64c8cf6cd883dc7bbb2a4ed6d5a4db85c536d
Best regards,
--
Renjiang Han <quic_renjiang@quicinc.com>
On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: > QCS615 uses the same video core as SC7180, so reuse the same resource > data of SC7180 for QCS615 to enable video functionality. > > There are no resources for the video-decoder and video-encoder nodes > in the device tree, so remove these two nodes from the device tree. In > addition, to ensure that the video codec functions properly, use [3] > to add encoder and decoder node entries in the venus driver. > > Validated this series on QCS615 and SC7180. > > Note: > This series consist of DT patches and a venus driver patch. The patch > 1/3, which is venus driver patch, can be picked independently without > having any functional dependency. But patch 2/3 & patch 3/3, which are > DT patches, still depend on [1]. I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core on QCS615 over(?)clocked. > > [1] https://lore.kernel.org/all/20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com > > Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com> > --- > Changes in v8: > - 1. Add missing tags. > - 2. Fix the dependency to point to videoCC series alone. > - 3. Fix review comments from Konrad. > - Link to v7: https://lore.kernel.org/r/20250527-add-venus-for-qcs615-v7-0-cca26e2768e3@quicinc.com > > Changes in v7: > - 1. Update devicetree patch to fix the cherry-pick patch conflict issue. > - 2. Remove dt-bindings patch from this patch series due to it has been > picked. > - Link to v6: https://lore.kernel.org/r/20241219-add-venus-for-qcs615-v6-0-e9a74d3b003d@quicinc.com > > Changes in v6: > - 1. Remove video-decoder and video-encoder nodes from the device tree > - 2. Add a new dependency. > - 3. Fix missing tag. > - 4. Update commit message. > - Link to v5: https://lore.kernel.org/r/20241217-add-venus-for-qcs615-v5-0-747395d9e630@quicinc.com > > Changes in v5: > - 1. Remove extra blank lines in yaml files. > - 2. Add new variables in the driver while keeping the order of the > original variables. And remove unnecessary variable initialization. > - 3. Update commit message. > - 4. Update the order of nodes in the device tree. > - Link to v4: https://lore.kernel.org/r/20241213-add-venus-for-qcs615-v4-0-7e2c9a72d309@quicinc.com > > Changes in v4: > - 1. Remove qcom,qcs615-venus.yaml and use qcom,sc7180-venus.yaml for > qcs615 dt-bindings. > - 2. Add "qcom,qcs615-venus" compatible into qcom,sc7180-venus.yaml. > - 3. Remove qcs615 resource from the driver and use sc7180 resource for > the qcs615. > - 4. Use the frequency in the opp-table in devicetree for the driver. > For compatibility, if getting data from the opp table fails, the data > in the frequency table will be used. > - 5. Keep the reverse Christmas tree order coding style. > - 6. Add "qcom,sc7180-venus" compatible in devicetree. > - 7. Update cover letter message. > - Link to v3: https://lore.kernel.org/r/20241125-add-venus-for-qcs615-v3-0-5a376b97a68e@quicinc.com > > Changes in v3: > - 1. Remove the ‘|’ after 'description' in the qcom,qcs615-venus.yaml. > - 2. Add a blank line before 'opp-table' in the qcom,qcs615-venus.yaml. > - 3. Put ‘additionalProperties’ before ‘properties’ in the > qcom,qcs615-venus.yaml. > - 4. Update the subject of qcom,qcs615-venus.yaml patch. > - Link to v2: https://lore.kernel.org/r/20241112-add-venus-for-qcs615-v2-0-e67947f957af@quicinc.com > > Changes in v2: > - 1. The change-id of DT and driver are removed. > - 2. Add qcom,qcs615-venus.yaml files to explain DT. > - 3. The order of driver's commit and DT's commit is adjusted. Place the > driver's commit before the DT's commit. > - 4. Extends driver's commit message. > - 5. Split DT's commit into two commits. Add the venus node to the > qcs615.dtsi file. Then in the qcs615-ride.dts file enable the venus node. > - 6. Modify alignment, sort, upper and lower case letters issue. > - 7. Update cover letter message description. > - Link to v1: https://lore.kernel.org/r/20241008-add_qcs615_video-v1-0-436ce07bfc63@quicinc.com > > --- > Renjiang Han (3): > media: venus: pm_helpers: use opp-table for the frequency > arm64: dts: qcom: qcs615: add venus node to devicetree > arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec > > arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++ > arch/arm64/boot/dts/qcom/qcs615.dtsi | 78 ++++++++++++++++++++++++++ > drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++----- > 3 files changed, 121 insertions(+), 14 deletions(-) > --- > base-commit: 176e917e010cb7dcc605f11d2bc33f304292482b > change-id: 20250526-add-venus-for-qcs615-a547540656d1 > prerequisite-message-id: <20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com> > prerequisite-patch-id: afd2dce9e6066b1f6ce0b41ceafe0dd47ad97c40 > prerequisite-patch-id: f8d64c8cf6cd883dc7bbb2a4ed6d5a4db85c536d > > Best regards, > -- > Renjiang Han <quic_renjiang@quicinc.com> > -- With best wishes Dmitry
On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: > On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: >> QCS615 uses the same video core as SC7180, so reuse the same resource >> data of SC7180 for QCS615 to enable video functionality. >> >> There are no resources for the video-decoder and video-encoder nodes >> in the device tree, so remove these two nodes from the device tree. In >> addition, to ensure that the video codec functions properly, use [3] >> to add encoder and decoder node entries in the venus driver. >> >> Validated this series on QCS615 and SC7180. >> >> Note: >> This series consist of DT patches and a venus driver patch. The patch >> 1/3, which is venus driver patch, can be picked independently without >> having any functional dependency. But patch 2/3 & patch 3/3, which are >> DT patches, still depend on [1]. > I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core > on QCS615 over(?)clocked. Agree, so we need to make sure that the driver patch is not picked after the DT patch. > >> [1] https://lore.kernel.org/all/20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com >> >> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com> >> --- >> Changes in v8: >> - 1. Add missing tags. >> - 2. Fix the dependency to point to videoCC series alone. >> - 3. Fix review comments from Konrad. >> - Link to v7: https://lore.kernel.org/r/20250527-add-venus-for-qcs615-v7-0-cca26e2768e3@quicinc.com >> >> Changes in v7: >> - 1. Update devicetree patch to fix the cherry-pick patch conflict issue. >> - 2. Remove dt-bindings patch from this patch series due to it has been >> picked. >> - Link to v6: https://lore.kernel.org/r/20241219-add-venus-for-qcs615-v6-0-e9a74d3b003d@quicinc.com >> >> Changes in v6: >> - 1. Remove video-decoder and video-encoder nodes from the device tree >> - 2. Add a new dependency. >> - 3. Fix missing tag. >> - 4. Update commit message. >> - Link to v5: https://lore.kernel.org/r/20241217-add-venus-for-qcs615-v5-0-747395d9e630@quicinc.com >> >> Changes in v5: >> - 1. Remove extra blank lines in yaml files. >> - 2. Add new variables in the driver while keeping the order of the >> original variables. And remove unnecessary variable initialization. >> - 3. Update commit message. >> - 4. Update the order of nodes in the device tree. >> - Link to v4: https://lore.kernel.org/r/20241213-add-venus-for-qcs615-v4-0-7e2c9a72d309@quicinc.com >> >> Changes in v4: >> - 1. Remove qcom,qcs615-venus.yaml and use qcom,sc7180-venus.yaml for >> qcs615 dt-bindings. >> - 2. Add "qcom,qcs615-venus" compatible into qcom,sc7180-venus.yaml. >> - 3. Remove qcs615 resource from the driver and use sc7180 resource for >> the qcs615. >> - 4. Use the frequency in the opp-table in devicetree for the driver. >> For compatibility, if getting data from the opp table fails, the data >> in the frequency table will be used. >> - 5. Keep the reverse Christmas tree order coding style. >> - 6. Add "qcom,sc7180-venus" compatible in devicetree. >> - 7. Update cover letter message. >> - Link to v3: https://lore.kernel.org/r/20241125-add-venus-for-qcs615-v3-0-5a376b97a68e@quicinc.com >> >> Changes in v3: >> - 1. Remove the ‘|’ after 'description' in the qcom,qcs615-venus.yaml. >> - 2. Add a blank line before 'opp-table' in the qcom,qcs615-venus.yaml. >> - 3. Put ‘additionalProperties’ before ‘properties’ in the >> qcom,qcs615-venus.yaml. >> - 4. Update the subject of qcom,qcs615-venus.yaml patch. >> - Link to v2: https://lore.kernel.org/r/20241112-add-venus-for-qcs615-v2-0-e67947f957af@quicinc.com >> >> Changes in v2: >> - 1. The change-id of DT and driver are removed. >> - 2. Add qcom,qcs615-venus.yaml files to explain DT. >> - 3. The order of driver's commit and DT's commit is adjusted. Place the >> driver's commit before the DT's commit. >> - 4. Extends driver's commit message. >> - 5. Split DT's commit into two commits. Add the venus node to the >> qcs615.dtsi file. Then in the qcs615-ride.dts file enable the venus node. >> - 6. Modify alignment, sort, upper and lower case letters issue. >> - 7. Update cover letter message description. >> - Link to v1: https://lore.kernel.org/r/20241008-add_qcs615_video-v1-0-436ce07bfc63@quicinc.com >> >> --- >> Renjiang Han (3): >> media: venus: pm_helpers: use opp-table for the frequency >> arm64: dts: qcom: qcs615: add venus node to devicetree >> arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec >> >> arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++ >> arch/arm64/boot/dts/qcom/qcs615.dtsi | 78 ++++++++++++++++++++++++++ >> drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++----- >> 3 files changed, 121 insertions(+), 14 deletions(-) >> --- >> base-commit: 176e917e010cb7dcc605f11d2bc33f304292482b >> change-id: 20250526-add-venus-for-qcs615-a547540656d1 >> prerequisite-message-id: <20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com> >> prerequisite-patch-id: afd2dce9e6066b1f6ce0b41ceafe0dd47ad97c40 >> prerequisite-patch-id: f8d64c8cf6cd883dc7bbb2a4ed6d5a4db85c536d >> >> Best regards, >> -- >> Renjiang Han <quic_renjiang@quicinc.com> >> -- Best Regards, Renjiang
On 31/05/2025 01:05, Renjiang Han wrote: >>> >>> Note: >>> This series consist of DT patches and a venus driver patch. The patch >>> 1/3, which is venus driver patch, can be picked independently without >>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>> DT patches, still depend on [1]. >> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core >> on QCS615 over(?)clocked. > Agree, so we need to make sure that the driver patch is not picked after > the DT patch. This statement is confusing. 1/3 states that there will be a fallback if there is no OPP table present. Giving the code a glance, I believe that is so, freq_table should be used if there is no OPP specified in the DT. I think we are having a hard time here understanding what you are saying. My understanding: - venus modification is standalone 1/3 Qcs615 will fallback if no OPP is present - dt modification 2/3 3/3 is therefore also independent of driver --- bod
On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: > On 31/05/2025 01:05, Renjiang Han wrote: >>>> >>>> Note: >>>> This series consist of DT patches and a venus driver patch. The patch >>>> 1/3, which is venus driver patch, can be picked independently without >>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>> DT patches, still depend on [1]. >>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>> core >>> on QCS615 over(?)clocked. >> Agree, so we need to make sure that the driver patch is not picked >> after the DT patch. > > This statement is confusing. > > 1/3 states that there will be a fallback if there is no OPP table > present. > > Giving the code a glance, I believe that is so, freq_table should be > used if there is no OPP specified in the DT. > > I think we are having a hard time here understanding what you are saying. > > My understanding: > > - venus modification is standalone 1/3 > Qcs615 will fallback if no OPP is present > > - dt modification 2/3 3/3 is therefore also independent of driver > > --- > bod yes, let me re-spin this with driver patch alone. Once that gets in, will bring in the DT patches. -- Best Regards, Renjiang
On 06/06/2025 14:37, Renjiang Han wrote: > > On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >> On 31/05/2025 01:05, Renjiang Han wrote: >>>>> >>>>> Note: >>>>> This series consist of DT patches and a venus driver patch. The patch >>>>> 1/3, which is venus driver patch, can be picked independently without >>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>> DT patches, still depend on [1]. >>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>>> core >>>> on QCS615 over(?)clocked. >>> Agree, so we need to make sure that the driver patch is not picked >>> after the DT patch. >> >> This statement is confusing. >> >> 1/3 states that there will be a fallback if there is no OPP table >> present. >> >> Giving the code a glance, I believe that is so, freq_table should be >> used if there is no OPP specified in the DT. >> >> I think we are having a hard time here understanding what you are saying. >> >> My understanding: >> >> - venus modification is standalone 1/3 >> Qcs615 will fallback if no OPP is present >> >> - dt modification 2/3 3/3 is therefore also independent of driver >> >> --- >> bod > yes, let me re-spin this with driver patch alone. Once that gets in, > will bring in the DT patches. Did you read my feedback? There is no "once that gets in". DTS is an independent hardware description and your patchset claiming there is dependency is just broken. I am repeating this since few emails, so shall I NAK it that you will address the main issue you have? Best regards, Krzysztof
On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: > On 06/06/2025 14:37, Renjiang Han wrote: >> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>> Note: >>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>> DT patches, still depend on [1]. >>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>>>> core >>>>> on QCS615 over(?)clocked. >>>> Agree, so we need to make sure that the driver patch is not picked >>>> after the DT patch. >>> This statement is confusing. >>> >>> 1/3 states that there will be a fallback if there is no OPP table >>> present. >>> >>> Giving the code a glance, I believe that is so, freq_table should be >>> used if there is no OPP specified in the DT. >>> >>> I think we are having a hard time here understanding what you are saying. >>> >>> My understanding: >>> >>> - venus modification is standalone 1/3 >>> Qcs615 will fallback if no OPP is present >>> >>> - dt modification 2/3 3/3 is therefore also independent of driver >>> >>> --- >>> bod >> yes, let me re-spin this with driver patch alone. Once that gets in, >> will bring in the DT patches. > Did you read my feedback? There is no "once that gets in". DTS is an > independent hardware description and your patchset claiming there is > dependency is just broken. > > I am repeating this since few emails, so shall I NAK it that you will > address the main issue you have? > > Best regards, > Krzysztof Hi Krzysztof SC7180 and QCS615 use the same video core. Only difference lies in the freq_table for the video. Freq_table is generally determined at SOC level. The Venus driver does not currently handle freq_table compatibility well across platforms. This patch enables the driver to use the OPP-table from the DT, addressing the frequency compatibility issue. -- Best Regards, Renjiang
On 06/06/2025 14:51, Renjiang Han wrote: > > On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: >> On 06/06/2025 14:37, Renjiang Han wrote: >>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>>> Note: >>>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>>> DT patches, still depend on [1]. >>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>>>>> core >>>>>> on QCS615 over(?)clocked. >>>>> Agree, so we need to make sure that the driver patch is not picked >>>>> after the DT patch. >>>> This statement is confusing. >>>> >>>> 1/3 states that there will be a fallback if there is no OPP table >>>> present. >>>> >>>> Giving the code a glance, I believe that is so, freq_table should be >>>> used if there is no OPP specified in the DT. >>>> >>>> I think we are having a hard time here understanding what you are saying. >>>> >>>> My understanding: >>>> >>>> - venus modification is standalone 1/3 >>>> Qcs615 will fallback if no OPP is present >>>> >>>> - dt modification 2/3 3/3 is therefore also independent of driver >>>> >>>> --- >>>> bod >>> yes, let me re-spin this with driver patch alone. Once that gets in, >>> will bring in the DT patches. >> Did you read my feedback? There is no "once that gets in". DTS is an >> independent hardware description and your patchset claiming there is >> dependency is just broken. >> >> I am repeating this since few emails, so shall I NAK it that you will >> address the main issue you have? >> >> Best regards, >> Krzysztof > > Hi Krzysztof > > SC7180 and QCS615 use the same video core. Only difference lies in the > freq_table for the video. Freq_table is generally determined at SOC level. > The Venus driver does not currently handle freq_table compatibility well > across platforms. This patch enables the driver to use the OPP-table from > the DT, addressing the frequency compatibility issue. This does not resolve the main problem at all. If SW cannot use the fallback alone, your fallback has no meaning and is not only confusing but actually incorrect. And based on previous statements like "overclocking" it is not only incorrect, but even harmful. Best regards, Krzysztof
On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote: > On 06/06/2025 14:51, Renjiang Han wrote: >> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: >>> On 06/06/2025 14:37, Renjiang Han wrote: >>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>>>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>>>> Note: >>>>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>>>> DT patches, still depend on [1]. >>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>>>>>> core >>>>>>> on QCS615 over(?)clocked. >>>>>> Agree, so we need to make sure that the driver patch is not picked >>>>>> after the DT patch. >>>>> This statement is confusing. >>>>> >>>>> 1/3 states that there will be a fallback if there is no OPP table >>>>> present. >>>>> >>>>> Giving the code a glance, I believe that is so, freq_table should be >>>>> used if there is no OPP specified in the DT. >>>>> >>>>> I think we are having a hard time here understanding what you are saying. >>>>> >>>>> My understanding: >>>>> >>>>> - venus modification is standalone 1/3 >>>>> Qcs615 will fallback if no OPP is present >>>>> >>>>> - dt modification 2/3 3/3 is therefore also independent of driver >>>>> >>>>> --- >>>>> bod >>>> yes, let me re-spin this with driver patch alone. Once that gets in, >>>> will bring in the DT patches. >>> Did you read my feedback? There is no "once that gets in". DTS is an >>> independent hardware description and your patchset claiming there is >>> dependency is just broken. >>> >>> I am repeating this since few emails, so shall I NAK it that you will >>> address the main issue you have? >>> >>> Best regards, >>> Krzysztof >> Hi Krzysztof >> >> SC7180 and QCS615 use the same video core. Only difference lies in the >> freq_table for the video. Freq_table is generally determined at SOC level. >> The Venus driver does not currently handle freq_table compatibility well >> across platforms. This patch enables the driver to use the OPP-table from >> the DT, addressing the frequency compatibility issue. > This does not resolve the main problem at all. If SW cannot use the > fallback alone, your fallback has no meaning and is not only confusing > but actually incorrect. And based on previous statements like > "overclocking" it is not only incorrect, but even harmful. > > Best regards, > Krzysztof The fallback is only triggered when there is no OPP table in the DT. Since the QCS615 DT will include an OPP table, the fallback logic will not be used. Also, if the freq from the freq_table and the OPP table are the same, would it be acceptable to drop the freq_table from the driver? -- Best Regards, Renjiang
On 06/06/2025 15:32, Renjiang Han wrote: > > On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote: >> On 06/06/2025 14:51, Renjiang Han wrote: >>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: >>>> On 06/06/2025 14:37, Renjiang Han wrote: >>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>>>>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>>>>> Note: >>>>>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>>>>> DT patches, still depend on [1]. >>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>>>>>>> core >>>>>>>> on QCS615 over(?)clocked. >>>>>>> Agree, so we need to make sure that the driver patch is not picked >>>>>>> after the DT patch. >>>>>> This statement is confusing. >>>>>> >>>>>> 1/3 states that there will be a fallback if there is no OPP table >>>>>> present. >>>>>> >>>>>> Giving the code a glance, I believe that is so, freq_table should be >>>>>> used if there is no OPP specified in the DT. >>>>>> >>>>>> I think we are having a hard time here understanding what you are saying. >>>>>> >>>>>> My understanding: >>>>>> >>>>>> - venus modification is standalone 1/3 >>>>>> Qcs615 will fallback if no OPP is present >>>>>> >>>>>> - dt modification 2/3 3/3 is therefore also independent of driver >>>>>> >>>>>> --- >>>>>> bod >>>>> yes, let me re-spin this with driver patch alone. Once that gets in, >>>>> will bring in the DT patches. >>>> Did you read my feedback? There is no "once that gets in". DTS is an >>>> independent hardware description and your patchset claiming there is >>>> dependency is just broken. >>>> >>>> I am repeating this since few emails, so shall I NAK it that you will >>>> address the main issue you have? >>>> >>>> Best regards, >>>> Krzysztof >>> Hi Krzysztof >>> >>> SC7180 and QCS615 use the same video core. Only difference lies in the >>> freq_table for the video. Freq_table is generally determined at SOC level. >>> The Venus driver does not currently handle freq_table compatibility well >>> across platforms. This patch enables the driver to use the OPP-table from >>> the DT, addressing the frequency compatibility issue. >> This does not resolve the main problem at all. If SW cannot use the >> fallback alone, your fallback has no meaning and is not only confusing >> but actually incorrect. And based on previous statements like >> "overclocking" it is not only incorrect, but even harmful. >> >> Best regards, >> Krzysztof > The fallback is only triggered when there is no OPP table in the DT. No. I don't think you understand how fallback works. Fallback will be applied on any QCS615 DTS without front compatible. Best regards, Krzysztof
On 6/7/25 11:46 AM, Krzysztof Kozlowski wrote: > On 06/06/2025 15:32, Renjiang Han wrote: >> >> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote: >>> On 06/06/2025 14:51, Renjiang Han wrote: >>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: >>>>> On 06/06/2025 14:37, Renjiang Han wrote: >>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>>>>>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>>>>>> Note: >>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>>>>>> DT patches, still depend on [1]. >>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>>>>>>>> core >>>>>>>>> on QCS615 over(?)clocked. >>>>>>>> Agree, so we need to make sure that the driver patch is not picked >>>>>>>> after the DT patch. >>>>>>> This statement is confusing. >>>>>>> >>>>>>> 1/3 states that there will be a fallback if there is no OPP table >>>>>>> present. >>>>>>> >>>>>>> Giving the code a glance, I believe that is so, freq_table should be >>>>>>> used if there is no OPP specified in the DT. >>>>>>> >>>>>>> I think we are having a hard time here understanding what you are saying. >>>>>>> >>>>>>> My understanding: >>>>>>> >>>>>>> - venus modification is standalone 1/3 >>>>>>> Qcs615 will fallback if no OPP is present >>>>>>> >>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver >>>>>>> >>>>>>> --- >>>>>>> bod >>>>>> yes, let me re-spin this with driver patch alone. Once that gets in, >>>>>> will bring in the DT patches. >>>>> Did you read my feedback? There is no "once that gets in". DTS is an >>>>> independent hardware description and your patchset claiming there is >>>>> dependency is just broken. >>>>> >>>>> I am repeating this since few emails, so shall I NAK it that you will >>>>> address the main issue you have? >>>>> >>>>> Best regards, >>>>> Krzysztof >>>> Hi Krzysztof >>>> >>>> SC7180 and QCS615 use the same video core. Only difference lies in the >>>> freq_table for the video. Freq_table is generally determined at SOC level. >>>> The Venus driver does not currently handle freq_table compatibility well >>>> across platforms. This patch enables the driver to use the OPP-table from >>>> the DT, addressing the frequency compatibility issue. >>> This does not resolve the main problem at all. If SW cannot use the >>> fallback alone, your fallback has no meaning and is not only confusing >>> but actually incorrect. And based on previous statements like >>> "overclocking" it is not only incorrect, but even harmful. >>> >>> Best regards, >>> Krzysztof >> The fallback is only triggered when there is no OPP table in the DT. > > No. I don't think you understand how fallback works. Fallback will be > applied on any QCS615 DTS without front compatible. Please read each other's messages.. Krzysztof refers to the fallback compatible mechanism, which means the proposed QCS615 node will match against the driver containing the sc7180 compatible. BOD refers to the driver falling back to using the hardcoded sc7180 freq_table when the OPP table is absent (which will not be the case for QCS615 since the node will be introduced with an OPP table on day 0). This patchset is okay to merge in proposed order (dt patches a cycle after the venus patch) Konrad
On 06/06/2025 14:32, Renjiang Han wrote: > > On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote: >> On 06/06/2025 14:51, Renjiang Han wrote: >>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: >>>> On 06/06/2025 14:37, Renjiang Han wrote: >>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>>>>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>>>>> Note: >>>>>>>>> This series consist of DT patches and a venus driver patch. The >>>>>>>>> patch >>>>>>>>> 1/3, which is venus driver patch, can be picked independently >>>>>>>>> without >>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, >>>>>>>>> which are >>>>>>>>> DT patches, still depend on [1]. >>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>>>>>>> core >>>>>>>> on QCS615 over(?)clocked. >>>>>>> Agree, so we need to make sure that the driver patch is not picked >>>>>>> after the DT patch. >>>>>> This statement is confusing. >>>>>> >>>>>> 1/3 states that there will be a fallback if there is no OPP table >>>>>> present. >>>>>> >>>>>> Giving the code a glance, I believe that is so, freq_table should be >>>>>> used if there is no OPP specified in the DT. >>>>>> >>>>>> I think we are having a hard time here understanding what you are >>>>>> saying. >>>>>> >>>>>> My understanding: >>>>>> >>>>>> - venus modification is standalone 1/3 >>>>>> Qcs615 will fallback if no OPP is present >>>>>> >>>>>> - dt modification 2/3 3/3 is therefore also independent of driver >>>>>> >>>>>> --- >>>>>> bod >>>>> yes, let me re-spin this with driver patch alone. Once that gets in, >>>>> will bring in the DT patches. >>>> Did you read my feedback? There is no "once that gets in". DTS is an >>>> independent hardware description and your patchset claiming there is >>>> dependency is just broken. >>>> >>>> I am repeating this since few emails, so shall I NAK it that you will >>>> address the main issue you have? >>>> >>>> Best regards, >>>> Krzysztof >>> Hi Krzysztof >>> >>> SC7180 and QCS615 use the same video core. Only difference lies in the >>> freq_table for the video. Freq_table is generally determined at SOC >>> level. >>> The Venus driver does not currently handle freq_table compatibility well >>> across platforms. This patch enables the driver to use the OPP-table >>> from >>> the DT, addressing the frequency compatibility issue. >> This does not resolve the main problem at all. If SW cannot use the >> fallback alone, your fallback has no meaning and is not only confusing >> but actually incorrect. And based on previous statements like >> "overclocking" it is not only incorrect, but even harmful. >> >> Best regards, >> Krzysztof > The fallback is only triggered when there is no OPP table in the DT. > Since the QCS615 DT will include an OPP table, the fallback logic will > not be used. > > Also, if the freq from the freq_table and the OPP table are the same, > would it be acceptable to drop the freq_table from the driver? If you drop the freq_table, you will need to apply OPPs for the sc7180 to DTS first before venus or you'll break sc7180. I think TBH you should add a freq_tbl for QCS615 and make it so the order of patch application doesn't matter wrt adding OPP support. - Add QCS freq_tbl - Add OPP support Then do whatever in DTS, nothing can break in this case. As we've established the fallback isn't a fallback because it falls back to wrong data, so lets fix that. --- bod
On 06/06/2025 15:53, Bryan O'Donoghue wrote: > On 06/06/2025 14:32, Renjiang Han wrote: >> >> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote: >>> On 06/06/2025 14:51, Renjiang Han wrote: >>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: >>>>> On 06/06/2025 14:37, Renjiang Han wrote: >>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>>>>>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>>>>>> Note: >>>>>>>>>> This series consist of DT patches and a venus driver patch. >>>>>>>>>> The patch >>>>>>>>>> 1/3, which is venus driver patch, can be picked independently >>>>>>>>>> without >>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, >>>>>>>>>> which are >>>>>>>>>> DT patches, still depend on [1]. >>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get >>>>>>>>> video >>>>>>>>> core >>>>>>>>> on QCS615 over(?)clocked. >>>>>>>> Agree, so we need to make sure that the driver patch is not picked >>>>>>>> after the DT patch. >>>>>>> This statement is confusing. >>>>>>> >>>>>>> 1/3 states that there will be a fallback if there is no OPP table >>>>>>> present. >>>>>>> >>>>>>> Giving the code a glance, I believe that is so, freq_table should be >>>>>>> used if there is no OPP specified in the DT. >>>>>>> >>>>>>> I think we are having a hard time here understanding what you are >>>>>>> saying. >>>>>>> >>>>>>> My understanding: >>>>>>> >>>>>>> - venus modification is standalone 1/3 >>>>>>> Qcs615 will fallback if no OPP is present >>>>>>> >>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver >>>>>>> >>>>>>> --- >>>>>>> bod >>>>>> yes, let me re-spin this with driver patch alone. Once that gets in, >>>>>> will bring in the DT patches. >>>>> Did you read my feedback? There is no "once that gets in". DTS is an >>>>> independent hardware description and your patchset claiming there is >>>>> dependency is just broken. >>>>> >>>>> I am repeating this since few emails, so shall I NAK it that you will >>>>> address the main issue you have? >>>>> >>>>> Best regards, >>>>> Krzysztof >>>> Hi Krzysztof >>>> >>>> SC7180 and QCS615 use the same video core. Only difference lies in the >>>> freq_table for the video. Freq_table is generally determined at SOC >>>> level. >>>> The Venus driver does not currently handle freq_table compatibility >>>> well >>>> across platforms. This patch enables the driver to use the OPP-table >>>> from >>>> the DT, addressing the frequency compatibility issue. >>> This does not resolve the main problem at all. If SW cannot use the >>> fallback alone, your fallback has no meaning and is not only confusing >>> but actually incorrect. And based on previous statements like >>> "overclocking" it is not only incorrect, but even harmful. >>> >>> Best regards, >>> Krzysztof >> The fallback is only triggered when there is no OPP table in the DT. >> Since the QCS615 DT will include an OPP table, the fallback logic will >> not be used. >> >> Also, if the freq from the freq_table and the OPP table are the same, >> would it be acceptable to drop the freq_table from the driver? No, it's not acceptable, because then you'll break support for old DTs, which is a no-go. > > If you drop the freq_table, you will need to apply OPPs for the sc7180 > to DTS first before venus or you'll break sc7180. > > I think TBH you should add a freq_tbl for QCS615 and make it so the > order of patch application doesn't matter wrt adding OPP support. That would require adding board data for QCS615, which definitely doesn't look like a good solution. It is _exactly_ the same as SC7180. I'm against duplicating it just for the sake of having freq_tbl. > > - Add QCS freq_tbl > - Add OPP support > > Then do whatever in DTS, nothing can break in this case. > > As we've established the fallback isn't a fallback because it falls back > to wrong data, so lets fix that. Why isn't it a fallback? With the driver changes in place, the fallback is totally correct. -- With best wishes Dmitry
On 07/06/2025 03:13, Dmitry Baryshkov wrote: >> >> As we've established the fallback isn't a fallback because it falls >> back to wrong data, so lets fix that. > > Why isn't it a fallback? With the driver changes in place, the fallback > is totally correct. Its not a fallback _as_is_ I'm fine either way - Apply 1/3 and then re-submit 2/3 3/3 or - Enumerate a QCS615 table - Apply 1/3 here --- bod
On 07/06/2025 10:16, Bryan O'Donoghue wrote: > On 07/06/2025 03:13, Dmitry Baryshkov wrote: >>> >>> As we've established the fallback isn't a fallback because it falls >>> back to wrong data, so lets fix that. >> >> Why isn't it a fallback? With the driver changes in place, the >> fallback is totally correct. > > Its not a fallback _as_is_ > > I'm fine either way > > - Apply 1/3 and then re-submit 2/3 3/3 Let's settle on this option. I think it is the cleanest option. > > or > > - Enumerate a QCS615 table > - Apply 1/3 here > > --- > bod -- With best wishes Dmitry
On 6/7/2025 10:13 AM, Dmitry Baryshkov wrote: > On 06/06/2025 15:53, Bryan O'Donoghue wrote: >> On 06/06/2025 14:32, Renjiang Han wrote: >>> >>> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote: >>>> On 06/06/2025 14:51, Renjiang Han wrote: >>>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: >>>>>> On 06/06/2025 14:37, Renjiang Han wrote: >>>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>>>>>>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>>>>>>> Note: >>>>>>>>>>> This series consist of DT patches and a venus driver patch. >>>>>>>>>>> The patch >>>>>>>>>>> 1/3, which is venus driver patch, can be picked >>>>>>>>>>> independently without >>>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, >>>>>>>>>>> which are >>>>>>>>>>> DT patches, still depend on [1]. >>>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get >>>>>>>>>> video >>>>>>>>>> core >>>>>>>>>> on QCS615 over(?)clocked. >>>>>>>>> Agree, so we need to make sure that the driver patch is not >>>>>>>>> picked >>>>>>>>> after the DT patch. >>>>>>>> This statement is confusing. >>>>>>>> >>>>>>>> 1/3 states that there will be a fallback if there is no OPP table >>>>>>>> present. >>>>>>>> >>>>>>>> Giving the code a glance, I believe that is so, freq_table >>>>>>>> should be >>>>>>>> used if there is no OPP specified in the DT. >>>>>>>> >>>>>>>> I think we are having a hard time here understanding what you >>>>>>>> are saying. >>>>>>>> >>>>>>>> My understanding: >>>>>>>> >>>>>>>> - venus modification is standalone 1/3 >>>>>>>> Qcs615 will fallback if no OPP is present >>>>>>>> >>>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver >>>>>>>> >>>>>>>> --- >>>>>>>> bod >>>>>>> yes, let me re-spin this with driver patch alone. Once that gets >>>>>>> in, >>>>>>> will bring in the DT patches. >>>>>> Did you read my feedback? There is no "once that gets in". DTS is an >>>>>> independent hardware description and your patchset claiming there is >>>>>> dependency is just broken. >>>>>> >>>>>> I am repeating this since few emails, so shall I NAK it that you >>>>>> will >>>>>> address the main issue you have? >>>>>> >>>>>> Best regards, >>>>>> Krzysztof >>>>> Hi Krzysztof >>>>> >>>>> SC7180 and QCS615 use the same video core. Only difference lies in >>>>> the >>>>> freq_table for the video. Freq_table is generally determined at >>>>> SOC level. >>>>> The Venus driver does not currently handle freq_table >>>>> compatibility well >>>>> across platforms. This patch enables the driver to use the >>>>> OPP-table from >>>>> the DT, addressing the frequency compatibility issue. >>>> This does not resolve the main problem at all. If SW cannot use the >>>> fallback alone, your fallback has no meaning and is not only confusing >>>> but actually incorrect. And based on previous statements like >>>> "overclocking" it is not only incorrect, but even harmful. >>>> >>>> Best regards, >>>> Krzysztof >>> The fallback is only triggered when there is no OPP table in the DT. >>> Since the QCS615 DT will include an OPP table, the fallback logic will >>> not be used. >>> >>> Also, if the freq from the freq_table and the OPP table are the same, >>> would it be acceptable to drop the freq_table from the driver? > > No, it's not acceptable, because then you'll break support for old > DTs, which is a no-go. > >> >> If you drop the freq_table, you will need to apply OPPs for the >> sc7180 to DTS first before venus or you'll break sc7180. >> >> I think TBH you should add a freq_tbl for QCS615 and make it so the >> order of patch application doesn't matter wrt adding OPP support. > > That would require adding board data for QCS615, which definitely > doesn't look like a good solution. It is _exactly_ the same as SC7180. > I'm against duplicating it just for the sake of having freq_tbl. > >> >> - Add QCS freq_tbl >> - Add OPP support >> >> Then do whatever in DTS, nothing can break in this case. >> >> As we've established the fallback isn't a fallback because it falls >> back to wrong data, so lets fix that. > > Why isn't it a fallback? With the driver changes in place, the > fallback is totally correct. Agree. Also, currently, both the freq_table and the opp-table are present in the driver and DT code, and their frequency values are identical. This driver patch is simply switching the frequency source from freq_table to opp-table. Therefore, I think this patch is an enhancement to the driver's functionality and can be submitted independently, as it is not part of any specific project. -- Best Regards, Renjiang
On 6/6/2025 8:23 PM, Bryan O'Donoghue wrote: > On 06/06/2025 14:32, Renjiang Han wrote: >> >> On 6/6/2025 8:56 PM, Krzysztof Kozlowski wrote: >>> On 06/06/2025 14:51, Renjiang Han wrote: >>>> On 6/6/2025 8:44 PM, Krzysztof Kozlowski wrote: >>>>> On 06/06/2025 14:37, Renjiang Han wrote: >>>>>> On 6/5/2025 8:34 PM, Bryan O'Donoghue wrote: >>>>>>> On 31/05/2025 01:05, Renjiang Han wrote: >>>>>>>>>> Note: >>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>>>>>> DT patches, still depend on [1]. >>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video >>>>>>>>> core >>>>>>>>> on QCS615 over(?)clocked. >>>>>>>> Agree, so we need to make sure that the driver patch is not picked >>>>>>>> after the DT patch. >>>>>>> This statement is confusing. >>>>>>> >>>>>>> 1/3 states that there will be a fallback if there is no OPP table >>>>>>> present. >>>>>>> >>>>>>> Giving the code a glance, I believe that is so, freq_table should be >>>>>>> used if there is no OPP specified in the DT. >>>>>>> >>>>>>> I think we are having a hard time here understanding what you are saying. >>>>>>> >>>>>>> My understanding: >>>>>>> >>>>>>> - venus modification is standalone 1/3 >>>>>>> Qcs615 will fallback if no OPP is present >>>>>>> >>>>>>> - dt modification 2/3 3/3 is therefore also independent of driver >>>>>>> >>>>>>> --- >>>>>>> bod >>>>>> yes, let me re-spin this with driver patch alone. Once that gets in, >>>>>> will bring in the DT patches. >>>>> Did you read my feedback? There is no "once that gets in". DTS is an >>>>> independent hardware description and your patchset claiming there is >>>>> dependency is just broken. >>>>> >>>>> I am repeating this since few emails, so shall I NAK it that you will >>>>> address the main issue you have? >>>>> >>>>> Best regards, >>>>> Krzysztof >>>> Hi Krzysztof >>>> >>>> SC7180 and QCS615 use the same video core. Only difference lies in the >>>> freq_table for the video. Freq_table is generally determined at SOC level. >>>> The Venus driver does not currently handle freq_table compatibility well >>>> across platforms. This patch enables the driver to use the OPP-table from >>>> the DT, addressing the frequency compatibility issue. >>> This does not resolve the main problem at all. If SW cannot use the >>> fallback alone, your fallback has no meaning and is not only confusing >>> but actually incorrect. And based on previous statements like >>> "overclocking" it is not only incorrect, but even harmful. >>> >>> Best regards, >>> Krzysztof >> The fallback is only triggered when there is no OPP table in the DT. >> Since the QCS615 DT will include an OPP table, the fallback logic will >> not be used. >> >> Also, if the freq from the freq_table and the OPP table are the same, >> would it be acceptable to drop the freq_table from the driver? > > If you drop the freq_table, you will need to apply OPPs for the sc7180 to DTS > first before venus or you'll break sc7180. > > I think TBH you should add a freq_tbl for QCS615 and make it so the order of > patch application doesn't matter wrt adding OPP support. That would my proposal too here. Add the proper table in driver resources for QCS615, so that either of OPP or fallback would not matter and would be carrying right values either way(no over clocking). Regards, Vikash > > - Add QCS freq_tbl > - Add OPP support > > Then do whatever in DTS, nothing can break in this case. > > As we've established the fallback isn't a fallback because it falls back to > wrong data, so lets fix that. > > --- > bod
On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: > > On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: > > On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: > > > QCS615 uses the same video core as SC7180, so reuse the same resource > > > data of SC7180 for QCS615 to enable video functionality. > > > > > > There are no resources for the video-decoder and video-encoder nodes > > > in the device tree, so remove these two nodes from the device tree. In > > > addition, to ensure that the video codec functions properly, use [3] > > > to add encoder and decoder node entries in the venus driver. > > > > > > Validated this series on QCS615 and SC7180. > > > > > > Note: > > > This series consist of DT patches and a venus driver patch. The patch > > > 1/3, which is venus driver patch, can be picked independently without > > > having any functional dependency. But patch 2/3 & patch 3/3, which are > > > DT patches, still depend on [1]. > > I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core > > on QCS615 over(?)clocked. > Agree, so we need to make sure that the driver patch is not picked after the > DT patch. Worse: we need to make sure that the driver patch is present in the branch which picks up DT patches. Otherwise building & testing that branch (which is not unfrequent when doing git bisect) will fail. The easiest way to ensure that is to merge driver changes in v6.N and then DT changes in v6.N+1. -- With best wishes Dmitry
On 02/06/2025 08:16, Dmitry Baryshkov wrote: > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: >> >> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: >>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: >>>> QCS615 uses the same video core as SC7180, so reuse the same resource >>>> data of SC7180 for QCS615 to enable video functionality. >>>> >>>> There are no resources for the video-decoder and video-encoder nodes >>>> in the device tree, so remove these two nodes from the device tree. In >>>> addition, to ensure that the video codec functions properly, use [3] >>>> to add encoder and decoder node entries in the venus driver. >>>> >>>> Validated this series on QCS615 and SC7180. >>>> >>>> Note: >>>> This series consist of DT patches and a venus driver patch. The patch >>>> 1/3, which is venus driver patch, can be picked independently without >>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>> DT patches, still depend on [1]. >>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core >>> on QCS615 over(?)clocked. >> Agree, so we need to make sure that the driver patch is not picked after the >> DT patch. > > Worse: we need to make sure that the driver patch is present in the > branch which picks up DT patches. Otherwise building & testing that Well, that's a NAK then (although depends what you mean by DT). Best regards, Krzysztof
On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On 02/06/2025 08:16, Dmitry Baryshkov wrote: > > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: > >> > >> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: > >>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: > >>>> QCS615 uses the same video core as SC7180, so reuse the same resource > >>>> data of SC7180 for QCS615 to enable video functionality. > >>>> > >>>> There are no resources for the video-decoder and video-encoder nodes > >>>> in the device tree, so remove these two nodes from the device tree. In > >>>> addition, to ensure that the video codec functions properly, use [3] > >>>> to add encoder and decoder node entries in the venus driver. > >>>> > >>>> Validated this series on QCS615 and SC7180. > >>>> > >>>> Note: > >>>> This series consist of DT patches and a venus driver patch. The patch > >>>> 1/3, which is venus driver patch, can be picked independently without > >>>> having any functional dependency. But patch 2/3 & patch 3/3, which are > >>>> DT patches, still depend on [1]. > >>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core > >>> on QCS615 over(?)clocked. > >> Agree, so we need to make sure that the driver patch is not picked after the > >> DT patch. > > > > Worse: we need to make sure that the driver patch is present in the > > branch which picks up DT patches. Otherwise building & testing that > > > Well, that's a NAK then (although depends what you mean by DT). I mean qcs615.dtsi. I'd suggest an immutable branch for the driver patch. Or just merging the patches in two consequent releases. -- With best wishes Dmitry
On 05/06/2025 14:30, Dmitry Baryshkov wrote: > On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote: >> >> On 02/06/2025 08:16, Dmitry Baryshkov wrote: >>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: >>>> >>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: >>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: >>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource >>>>>> data of SC7180 for QCS615 to enable video functionality. >>>>>> >>>>>> There are no resources for the video-decoder and video-encoder nodes >>>>>> in the device tree, so remove these two nodes from the device tree. In >>>>>> addition, to ensure that the video codec functions properly, use [3] >>>>>> to add encoder and decoder node entries in the venus driver. >>>>>> >>>>>> Validated this series on QCS615 and SC7180. >>>>>> >>>>>> Note: >>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>> DT patches, still depend on [1]. >>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core >>>>> on QCS615 over(?)clocked. >>>> Agree, so we need to make sure that the driver patch is not picked after the >>>> DT patch. >>> >>> Worse: we need to make sure that the driver patch is present in the >>> branch which picks up DT patches. Otherwise building & testing that >> >> >> Well, that's a NAK then (although depends what you mean by DT). > > I mean qcs615.dtsi. I'd suggest an immutable branch for the driver Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into one branch. > patch. Or just merging the patches in two consequent releases. That's a new device nodes, new hardware so it should not be blocked by any driver patch. This is just totally broken process / patchset / work. Best regards, Krzysztof
On 05/06/2025 13:33, Krzysztof Kozlowski wrote: > On 05/06/2025 14:30, Dmitry Baryshkov wrote: >> On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote: >>> >>> On 02/06/2025 08:16, Dmitry Baryshkov wrote: >>>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: >>>>> >>>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: >>>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: >>>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource >>>>>>> data of SC7180 for QCS615 to enable video functionality. >>>>>>> >>>>>>> There are no resources for the video-decoder and video-encoder nodes >>>>>>> in the device tree, so remove these two nodes from the device tree. In >>>>>>> addition, to ensure that the video codec functions properly, use [3] >>>>>>> to add encoder and decoder node entries in the venus driver. >>>>>>> >>>>>>> Validated this series on QCS615 and SC7180. >>>>>>> >>>>>>> Note: >>>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>>> DT patches, still depend on [1]. >>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core >>>>>> on QCS615 over(?)clocked. >>>>> Agree, so we need to make sure that the driver patch is not picked after the >>>>> DT patch. >>>> >>>> Worse: we need to make sure that the driver patch is present in the >>>> branch which picks up DT patches. Otherwise building & testing that >>> >>> >>> Well, that's a NAK then (although depends what you mean by DT). >> >> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver > > Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into > one branch. > >> patch. Or just merging the patches in two consequent releases. > > That's a new device nodes, new hardware so it should not be blocked by > any driver patch. This is just totally broken process / patchset / work. > > Best regards, > Krzysztof Reading this thread, I don't think that is the case. I don't see how patches 2/3 or 3/3 depend on 1/3. The frequency table is a fallback in the driver and the DT changes are completely straight forward. TBH, I think we are hitting an email comms/social barrier here, not a technical one. @Renjiang can you please confirm that freq_table is a fallback, qcs615 will work without OPP table and the DTS stuff doesn't depend on the driver. TBH, I don't see how the DTS can or should but... --- bod
On 6/5/2025 8:40 PM, Bryan O'Donoghue wrote: >>>> Well, that's a NAK then (although depends what you mean by DT). >>> >>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver >> >> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into >> one branch. >> >>> patch. Or just merging the patches in two consequent releases. >> >> That's a new device nodes, new hardware so it should not be blocked by >> any driver patch. This is just totally broken process / patchset / work. >> >> Best regards, >> Krzysztof > > Reading this thread, I don't think that is the case. > > I don't see how patches 2/3 or 3/3 depend on 1/3. > > The frequency table is a fallback in the driver and the DT changes are > completely straight forward. > > TBH, I think we are hitting an email comms/social barrier here, not a > technical one. > > @Renjiang can you please confirm that freq_table is a fallback, qcs615 > will work without OPP table and the DTS stuff doesn't depend on the > driver. yes, freq_table is a fallback. driver will use freq_table without OPP table. the DTS doesn't depend on the driver. > > TBH, I don't see how the DTS can or should but... > > --- > bod -- Best Regards, Renjiang
On 6/6/2025 11:52 AM, Renjiang Han wrote: > > On 6/5/2025 8:40 PM, Bryan O'Donoghue wrote: >>>>> Well, that's a NAK then (although depends what you mean by DT). >>>> >>>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver >>> >>> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into >>> one branch. >>> >>>> patch. Or just merging the patches in two consequent releases. >>> >>> That's a new device nodes, new hardware so it should not be blocked by >>> any driver patch. This is just totally broken process / patchset / >>> work. >>> >>> Best regards, >>> Krzysztof >> >> Reading this thread, I don't think that is the case. >> >> I don't see how patches 2/3 or 3/3 depend on 1/3. >> >> The frequency table is a fallback in the driver and the DT changes >> are completely straight forward. >> >> TBH, I think we are hitting an email comms/social barrier here, not a >> technical one. >> >> @Renjiang can you please confirm that freq_table is a fallback, >> qcs615 will work without OPP table and the DTS stuff doesn't depend >> on the driver. > yes, freq_table is a fallback. driver will use freq_table without OPP > table. the DTS doesn't depend on the driver. To correct my previous response: For this project, the driver patch needs to be merged first. Since it falls back to SC7180, but their frequencies are different which is reflected in the OPP table defined in the DTS. The DTS patch is intended to enable video function on the QCS615 platform. The driver patch is to switch from using the driver freq_table to the OPP table from the DTS. Without it, the driver will continue to use the internal freq_table as before. Therefore, if the DTS patch is applied without the driver patch, the video function will be enabled on the QCS615 platform, but the driver will use the SC7180 frequency table, which can lead to an overclocking issue. >> >> TBH, I don't see how the DTS can or should but... >> >> --- >> bod > -- Best Regards, Renjiang
On 06/06/2025 09:51, Renjiang Han wrote: >>> >>> Reading this thread, I don't think that is the case. >>> >>> I don't see how patches 2/3 or 3/3 depend on 1/3. >>> >>> The frequency table is a fallback in the driver and the DT changes >>> are completely straight forward. >>> >>> TBH, I think we are hitting an email comms/social barrier here, not a >>> technical one. >>> >>> @Renjiang can you please confirm that freq_table is a fallback, >>> qcs615 will work without OPP table and the DTS stuff doesn't depend >>> on the driver. >> yes, freq_table is a fallback. driver will use freq_table without OPP >> table. the DTS doesn't depend on the driver. > To correct my previous response: > For this project, the driver patch needs to be merged first. Since it > falls back to SC7180, but their frequencies are different which is > reflected in the OPP table defined in the DTS. > > The DTS patch is intended to enable video function on the QCS615 platform. > > The driver patch is to switch from using the driver freq_table to the > OPP table from the DTS. Without it, the driver will continue to use the > internal freq_table as before. > > Therefore, if the DTS patch is applied without the driver patch, the video > function will be enabled on the QCS615 platform, but the driver will use > the SC7180 frequency table, which can lead to an overclocking issue. This means devices are not really compatible and DTS is not correct. Best regards, Krzysztof
On 06/06/2025 08:54, Krzysztof Kozlowski wrote: > On 06/06/2025 09:51, Renjiang Han wrote: >>>> >>>> Reading this thread, I don't think that is the case. >>>> >>>> I don't see how patches 2/3 or 3/3 depend on 1/3. >>>> >>>> The frequency table is a fallback in the driver and the DT changes >>>> are completely straight forward. >>>> >>>> TBH, I think we are hitting an email comms/social barrier here, not a >>>> technical one. >>>> >>>> @Renjiang can you please confirm that freq_table is a fallback, >>>> qcs615 will work without OPP table and the DTS stuff doesn't depend >>>> on the driver. >>> yes, freq_table is a fallback. driver will use freq_table without OPP >>> table. the DTS doesn't depend on the driver. >> To correct my previous response: >> For this project, the driver patch needs to be merged first. Since it >> falls back to SC7180, but their frequencies are different which is >> reflected in the OPP table defined in the DTS. >> >> The DTS patch is intended to enable video function on the QCS615 platform. >> >> The driver patch is to switch from using the driver freq_table to the >> OPP table from the DTS. Without it, the driver will continue to use the >> internal freq_table as before. >> >> Therefore, if the DTS patch is applied without the driver patch, the video >> function will be enabled on the QCS615 platform, but the driver will use >> the SC7180 frequency table, which can lead to an overclocking issue. > > This means devices are not really compatible and DTS is not correct. The devices are compatible: all programming interface is the same. Having the freq table in the driver is an error. -- With best wishes Dmitry
On Thu, Jun 05, 2025 at 01:40:03PM +0100, Bryan O'Donoghue wrote: > On 05/06/2025 13:33, Krzysztof Kozlowski wrote: > > On 05/06/2025 14:30, Dmitry Baryshkov wrote: > > > On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > > > > > On 02/06/2025 08:16, Dmitry Baryshkov wrote: > > > > > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: > > > > > > > > > > > > On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: > > > > > > > On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: > > > > > > > > QCS615 uses the same video core as SC7180, so reuse the same resource > > > > > > > > data of SC7180 for QCS615 to enable video functionality. > > > > > > > > > > > > > > > > There are no resources for the video-decoder and video-encoder nodes > > > > > > > > in the device tree, so remove these two nodes from the device tree. In > > > > > > > > addition, to ensure that the video codec functions properly, use [3] > > > > > > > > to add encoder and decoder node entries in the venus driver. > > > > > > > > > > > > > > > > Validated this series on QCS615 and SC7180. > > > > > > > > > > > > > > > > Note: > > > > > > > > This series consist of DT patches and a venus driver patch. The patch > > > > > > > > 1/3, which is venus driver patch, can be picked independently without > > > > > > > > having any functional dependency. But patch 2/3 & patch 3/3, which are > > > > > > > > DT patches, still depend on [1]. > > > > > > > I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core > > > > > > > on QCS615 over(?)clocked. > > > > > > Agree, so we need to make sure that the driver patch is not picked after the > > > > > > DT patch. > > > > > > > > > > Worse: we need to make sure that the driver patch is present in the > > > > > branch which picks up DT patches. Otherwise building & testing that > > > > > > > > > > > > Well, that's a NAK then (although depends what you mean by DT). > > > > > > I mean qcs615.dtsi. I'd suggest an immutable branch for the driver > > > > Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into > > one branch. Surely it can... Like any other cross-subsystem dependency. > > > > > patch. Or just merging the patches in two consequent releases. > > > > That's a new device nodes, new hardware so it should not be blocked by > > any driver patch. This is just totally broken process / patchset / work. > > > > Best regards, > > Krzysztof > > Reading this thread, I don't think that is the case. > > I don't see how patches 2/3 or 3/3 depend on 1/3. Please correct me if I'm wrong. Without driver changes from patch 1, the driver will always use frequency table from the driver itself. In this case it will be the frequency table (and corners) for SC7180, which would make venus driver overclock the hardware on QCS615. > > The frequency table is a fallback in the driver and the DT changes are > completely straight forward. > > TBH, I think we are hitting an email comms/social barrier here, not a > technical one. I assume so. > > @Renjiang can you please confirm that freq_table is a fallback, qcs615 will > work without OPP table and the DTS stuff doesn't depend on the driver. > > TBH, I don't see how the DTS can or should but... > > --- > bod > -- With best wishes Dmitry
On 05/06/2025 18:02, Dmitry Baryshkov wrote: > On Thu, Jun 05, 2025 at 01:40:03PM +0100, Bryan O'Donoghue wrote: >> On 05/06/2025 13:33, Krzysztof Kozlowski wrote: >>> On 05/06/2025 14:30, Dmitry Baryshkov wrote: >>>> On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>>> >>>>> On 02/06/2025 08:16, Dmitry Baryshkov wrote: >>>>>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: >>>>>>> >>>>>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: >>>>>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: >>>>>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource >>>>>>>>> data of SC7180 for QCS615 to enable video functionality. >>>>>>>>> >>>>>>>>> There are no resources for the video-decoder and video-encoder nodes >>>>>>>>> in the device tree, so remove these two nodes from the device tree. In >>>>>>>>> addition, to ensure that the video codec functions properly, use [3] >>>>>>>>> to add encoder and decoder node entries in the venus driver. >>>>>>>>> >>>>>>>>> Validated this series on QCS615 and SC7180. >>>>>>>>> >>>>>>>>> Note: >>>>>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>>>>> DT patches, still depend on [1]. >>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core >>>>>>>> on QCS615 over(?)clocked. >>>>>>> Agree, so we need to make sure that the driver patch is not picked after the >>>>>>> DT patch. >>>>>> >>>>>> Worse: we need to make sure that the driver patch is present in the >>>>>> branch which picks up DT patches. Otherwise building & testing that >>>>> >>>>> >>>>> Well, that's a NAK then (although depends what you mean by DT). >>>> >>>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver >>> >>> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into >>> one branch. > > Surely it can... Like any other cross-subsystem dependency. Sure it cannot, because this breaks the basic rule of not mixing drivers into DTS. Arm soc maintainers are not merging drivers back to DTS and the DTS must not go via drivers tree. These are basic assumptions around DTS, see subsystem profile for more explanations. Best regards, Krzysztof
On 05/06/2025 18:12, Krzysztof Kozlowski wrote: > On 05/06/2025 18:02, Dmitry Baryshkov wrote: >> On Thu, Jun 05, 2025 at 01:40:03PM +0100, Bryan O'Donoghue wrote: >>> On 05/06/2025 13:33, Krzysztof Kozlowski wrote: >>>> On 05/06/2025 14:30, Dmitry Baryshkov wrote: >>>>> On Thu, 5 Jun 2025 at 13:13, Krzysztof Kozlowski <krzk@kernel.org> wrote: >>>>>> >>>>>> On 02/06/2025 08:16, Dmitry Baryshkov wrote: >>>>>>> On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: >>>>>>>> >>>>>>>> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: >>>>>>>>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: >>>>>>>>>> QCS615 uses the same video core as SC7180, so reuse the same resource >>>>>>>>>> data of SC7180 for QCS615 to enable video functionality. >>>>>>>>>> >>>>>>>>>> There are no resources for the video-decoder and video-encoder nodes >>>>>>>>>> in the device tree, so remove these two nodes from the device tree. In >>>>>>>>>> addition, to ensure that the video codec functions properly, use [3] >>>>>>>>>> to add encoder and decoder node entries in the venus driver. >>>>>>>>>> >>>>>>>>>> Validated this series on QCS615 and SC7180. >>>>>>>>>> >>>>>>>>>> Note: >>>>>>>>>> This series consist of DT patches and a venus driver patch. The patch >>>>>>>>>> 1/3, which is venus driver patch, can be picked independently without >>>>>>>>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>>>>>>>> DT patches, still depend on [1]. >>>>>>>>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core >>>>>>>>> on QCS615 over(?)clocked. >>>>>>>> Agree, so we need to make sure that the driver patch is not picked after the >>>>>>>> DT patch. >>>>>>> >>>>>>> Worse: we need to make sure that the driver patch is present in the >>>>>>> branch which picks up DT patches. Otherwise building & testing that >>>>>> >>>>>> >>>>>> Well, that's a NAK then (although depends what you mean by DT). >>>>> >>>>> I mean qcs615.dtsi. I'd suggest an immutable branch for the driver >>>> >>>> Sorry, but no, DTS cannot depend on drivers. You CANNOT merge them into >>>> one branch. >> >> Surely it can... Like any other cross-subsystem dependency. > > Sure it cannot, because this breaks the basic rule of not mixing drivers > into DTS. Arm soc maintainers are not merging drivers back to DTS and > the DTS must not go via drivers tree. These are basic assumptions around > DTS, see subsystem profile for more explanations. Ack, so v6.N+1, which is also fine. -- With best wishes Dmitry
On 05/06/2025 17:02, Dmitry Baryshkov wrote: > Please correct me if I'm wrong. Without driver changes from patch 1, the > driver will always use frequency table from the driver itself. In this > case it will be the frequency table (and corners) for SC7180, which > would make venus driver overclock the hardware on QCS615. True. Yes, let's apply 1/3 and then re-submit 2 and 3 once it hits -next. --- bod
On 05/06/2025 17:39, Bryan O'Donoghue wrote: > On 05/06/2025 17:02, Dmitry Baryshkov wrote: >> Please correct me if I'm wrong. Without driver changes from patch 1, the >> driver will always use frequency table from the driver itself. In this >> case it will be the frequency table (and corners) for SC7180, which >> would make venus driver overclock the hardware on QCS615. > > True. > > Yes, let's apply 1/3 and then re-submit 2 and 3 once it hits -next. Not enough. 1/3 should hit Bjorn's tree, see Arnd's rejection for 6.15 patchset. -- With best wishes Dmitry
On 6/2/2025 2:16 PM, Dmitry Baryshkov wrote: > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: >> On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: >>> On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: >>>> QCS615 uses the same video core as SC7180, so reuse the same resource >>>> data of SC7180 for QCS615 to enable video functionality. >>>> >>>> There are no resources for the video-decoder and video-encoder nodes >>>> in the device tree, so remove these two nodes from the device tree. In >>>> addition, to ensure that the video codec functions properly, use [3] >>>> to add encoder and decoder node entries in the venus driver. >>>> >>>> Validated this series on QCS615 and SC7180. >>>> >>>> Note: >>>> This series consist of DT patches and a venus driver patch. The patch >>>> 1/3, which is venus driver patch, can be picked independently without >>>> having any functional dependency. But patch 2/3 & patch 3/3, which are >>>> DT patches, still depend on [1]. >>> I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core >>> on QCS615 over(?)clocked. >> Agree, so we need to make sure that the driver patch is not picked after the >> DT patch. > Worse: we need to make sure that the driver patch is present in the > branch which picks up DT patches. Otherwise building & testing that > branch (which is not unfrequent when doing git bisect) will fail. > > The easiest way to ensure that is to merge driver changes in v6.N and > then DT changes in v6.N+1. Yes, now DT patches are pending videocc DT patch. I think the venus driver patch will likely be picked no later than the DT patches. -- Best Regards, Renjiang
On Thu, Jun 05, 2025 at 07:24:55PM +0800, Renjiang Han wrote: > > On 6/2/2025 2:16 PM, Dmitry Baryshkov wrote: > > On Sat, May 31, 2025 at 08:05:24AM +0800, Renjiang Han wrote: > > > On 5/31/2025 4:27 AM, Dmitry Baryshkov wrote: > > > > On Fri, May 30, 2025 at 09:32:12AM +0530, Renjiang Han wrote: > > > > > QCS615 uses the same video core as SC7180, so reuse the same resource > > > > > data of SC7180 for QCS615 to enable video functionality. > > > > > > > > > > There are no resources for the video-decoder and video-encoder nodes > > > > > in the device tree, so remove these two nodes from the device tree. In > > > > > addition, to ensure that the video codec functions properly, use [3] > > > > > to add encoder and decoder node entries in the venus driver. > > > > > > > > > > Validated this series on QCS615 and SC7180. > > > > > > > > > > Note: > > > > > This series consist of DT patches and a venus driver patch. The patch > > > > > 1/3, which is venus driver patch, can be picked independently without > > > > > having any functional dependency. But patch 2/3 & patch 3/3, which are > > > > > DT patches, still depend on [1]. > > > > I'd say 2/3 and 3/3 still depend on 1/3, otherwise we can get video core > > > > on QCS615 over(?)clocked. > > > Agree, so we need to make sure that the driver patch is not picked after the > > > DT patch. > > Worse: we need to make sure that the driver patch is present in the > > branch which picks up DT patches. Otherwise building & testing that > > branch (which is not unfrequent when doing git bisect) will fail. > > > > The easiest way to ensure that is to merge driver changes in v6.N and > > then DT changes in v6.N+1. > Yes, now DT patches are pending videocc DT patch. I think the > venus driver patch will likely be picked no later than the DT patches. Please read carefully: it's a question of the patch being present in the _same_ branch before DT patches are picked up. -- With best wishes Dmitry
On Fri, 30 May 2025 09:32:12 +0530, Renjiang Han wrote:
> QCS615 uses the same video core as SC7180, so reuse the same resource
> data of SC7180 for QCS615 to enable video functionality.
>
> There are no resources for the video-decoder and video-encoder nodes
> in the device tree, so remove these two nodes from the device tree. In
> addition, to ensure that the video codec functions properly, use [3]
> to add encoder and decoder node entries in the venus driver.
>
> Validated this series on QCS615 and SC7180.
>
> Note:
> This series consist of DT patches and a venus driver patch. The patch
> 1/3, which is venus driver patch, can be picked independently without
> having any functional dependency. But patch 2/3 & patch 3/3, which are
> DT patches, still depend on [1].
>
> [1] https://lore.kernel.org/all/20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com
>
> Signed-off-by: Renjiang Han <quic_renjiang@quicinc.com>
> ---
> Changes in v8:
> - 1. Add missing tags.
> - 2. Fix the dependency to point to videoCC series alone.
> - 3. Fix review comments from Konrad.
> - Link to v7: https://lore.kernel.org/r/20250527-add-venus-for-qcs615-v7-0-cca26e2768e3@quicinc.com
>
> Changes in v7:
> - 1. Update devicetree patch to fix the cherry-pick patch conflict issue.
> - 2. Remove dt-bindings patch from this patch series due to it has been
> picked.
> - Link to v6: https://lore.kernel.org/r/20241219-add-venus-for-qcs615-v6-0-e9a74d3b003d@quicinc.com
>
> Changes in v6:
> - 1. Remove video-decoder and video-encoder nodes from the device tree
> - 2. Add a new dependency.
> - 3. Fix missing tag.
> - 4. Update commit message.
> - Link to v5: https://lore.kernel.org/r/20241217-add-venus-for-qcs615-v5-0-747395d9e630@quicinc.com
>
> Changes in v5:
> - 1. Remove extra blank lines in yaml files.
> - 2. Add new variables in the driver while keeping the order of the
> original variables. And remove unnecessary variable initialization.
> - 3. Update commit message.
> - 4. Update the order of nodes in the device tree.
> - Link to v4: https://lore.kernel.org/r/20241213-add-venus-for-qcs615-v4-0-7e2c9a72d309@quicinc.com
>
> Changes in v4:
> - 1. Remove qcom,qcs615-venus.yaml and use qcom,sc7180-venus.yaml for
> qcs615 dt-bindings.
> - 2. Add "qcom,qcs615-venus" compatible into qcom,sc7180-venus.yaml.
> - 3. Remove qcs615 resource from the driver and use sc7180 resource for
> the qcs615.
> - 4. Use the frequency in the opp-table in devicetree for the driver.
> For compatibility, if getting data from the opp table fails, the data
> in the frequency table will be used.
> - 5. Keep the reverse Christmas tree order coding style.
> - 6. Add "qcom,sc7180-venus" compatible in devicetree.
> - 7. Update cover letter message.
> - Link to v3: https://lore.kernel.org/r/20241125-add-venus-for-qcs615-v3-0-5a376b97a68e@quicinc.com
>
> Changes in v3:
> - 1. Remove the ‘|’ after 'description' in the qcom,qcs615-venus.yaml.
> - 2. Add a blank line before 'opp-table' in the qcom,qcs615-venus.yaml.
> - 3. Put ‘additionalProperties’ before ‘properties’ in the
> qcom,qcs615-venus.yaml.
> - 4. Update the subject of qcom,qcs615-venus.yaml patch.
> - Link to v2: https://lore.kernel.org/r/20241112-add-venus-for-qcs615-v2-0-e67947f957af@quicinc.com
>
> Changes in v2:
> - 1. The change-id of DT and driver are removed.
> - 2. Add qcom,qcs615-venus.yaml files to explain DT.
> - 3. The order of driver's commit and DT's commit is adjusted. Place the
> driver's commit before the DT's commit.
> - 4. Extends driver's commit message.
> - 5. Split DT's commit into two commits. Add the venus node to the
> qcs615.dtsi file. Then in the qcs615-ride.dts file enable the venus node.
> - 6. Modify alignment, sort, upper and lower case letters issue.
> - 7. Update cover letter message description.
> - Link to v1: https://lore.kernel.org/r/20241008-add_qcs615_video-v1-0-436ce07bfc63@quicinc.com
>
> ---
> Renjiang Han (3):
> media: venus: pm_helpers: use opp-table for the frequency
> arm64: dts: qcom: qcs615: add venus node to devicetree
> arm64: dts: qcom: qcs615-ride: enable venus node to initialize video codec
>
> arch/arm64/boot/dts/qcom/qcs615-ride.dts | 4 ++
> arch/arm64/boot/dts/qcom/qcs615.dtsi | 78 ++++++++++++++++++++++++++
> drivers/media/platform/qcom/venus/pm_helpers.c | 53 ++++++++++++-----
> 3 files changed, 121 insertions(+), 14 deletions(-)
> ---
> base-commit: 176e917e010cb7dcc605f11d2bc33f304292482b
> change-id: 20250526-add-venus-for-qcs615-a547540656d1
> prerequisite-message-id: <20250119-qcs615-mm-v2-dt-nodes-v2-0-c46ab4080989@quicinc.com>
> prerequisite-patch-id: afd2dce9e6066b1f6ce0b41ceafe0dd47ad97c40
> prerequisite-patch-id: f8d64c8cf6cd883dc7bbb2a4ed6d5a4db85c536d
>
> Best regards,
> --
> Renjiang Han <quic_renjiang@quicinc.com>
>
>
>
My bot found new DTB warnings on the .dts files added or changed in this
series.
Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.
If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:
pip3 install dtschema --upgrade
This patch series was applied (using b4) to base:
Base: using specified base-commit 176e917e010cb7dcc605f11d2bc33f304292482b
Deps: looking for dependencies matching 2 patch-ids
Deps: Applying prerequisite patch: [PATCH v2 1/2] arm64: dts: qcom: qcs615: Add clock nodes for multimedia clock
Deps: Applying prerequisite patch: [PATCH v2 2/2] arm64: dts: qcom: qcs615: Add CPU scaling clock node
If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)
New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/qcom/' for 20250530-add-venus-for-qcs615-v8-0-c0092ac616d0@quicinc.com:
In file included from arch/arm64/boot/dts/qcom/qcs615-ride.dts:10:
arch/arm64/boot/dts/qcom/qcs615.dtsi:6:10: fatal error: dt-bindings/clock/qcom,qcs615-camcc.h: No such file or directory
6 | #include <dt-bindings/clock/qcom,qcs615-camcc.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [scripts/Makefile.dtbs:131: arch/arm64/boot/dts/qcom/qcs615-ride.dtb] Error 1
make[2]: *** [scripts/Makefile.build:470: arch/arm64/boot/dts/qcom] Error 2
make[2]: Target 'arch/arm64/boot/dts/qcom/qcs615-ride.dtb' not remade because of errors.
make[1]: *** [/home/rob/proj/linux-dt-testing/Makefile:1477: qcom/qcs615-ride.dtb] Error 2
make: *** [Makefile:248: __sub-make] Error 2
make: Target 'qcom/apq8096-ifc6640.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-j3ltetw.dtb' not remade because of errors.
make: Target 'qcom/msm8998-fxtec-pro1.dtb' not remade because of errors.
make: Target 'qcom/sm7325-nothing-spacewar.dtb' not remade because of errors.
make: Target 'qcom/sm7125-xiaomi-curtana.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-dell-xps13-9345.dtb' not remade because of errors.
make: Target 'qcom/msm8998-mtp.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-a5u-eur.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-lenovo-thinkpad-x13s.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r3-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-crd-pro.dtb' not remade because of errors.
make: Target 'qcom/sm6115p-lenovo-j606f.dtb' not remade because of errors.
make: Target 'qcom/msm8998-sony-xperia-yoshino-maple.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp454.dtb' not remade because of errors.
make: Target 'qcom/qcs6490-rb3gen2.dtb' not remade because of errors.
make: Target 'qcom/msm8992-xiaomi-libra.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-r4.dtb' not remade because of errors.
make: Target 'qcom/sdm450-motorola-ali.dtb' not remade because of errors.
make: Target 'qcom/x1e78100-lenovo-thinkpad-t14s-oled.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-quackingstick-r0.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel360-wifi.dtb' not remade because of errors.
make: Target 'qcom/sdm630-sony-xperia-ganges-kirin.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-coachz-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/sdm845-lg-judyp.dtb' not remade because of errors.
make: Target 'qcom/sdm845-cheza-r3.dtb' not remade because of errors.
make: Target 'qcom/msm8939-wingtech-wt82918.dtb' not remade because of errors.
make: Target 'qcom/qrb2210-rb1.dtb' not remade because of errors.
make: Target 'qcom/msm8996-mtp.dtb' not remade because of errors.
make: Target 'qcom/sm8750-mtp.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-zombie.dtb' not remade because of errors.
make: Target 'qcom/msm8992-lg-bullhead-rev-10.dtb' not remade because of errors.
make: Target 'qcom/qrb5165-rb5.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-lenovo-yoga-slim7x.dtb' not remade because of errors.
make: Target 'qcom/sm8550-qrd.dtb' not remade because of errors.
make: Target 'qcom/sdm630-sony-xperia-nile-discovery.dtb' not remade because of errors.
make: Target 'qcom/sm8550-sony-xperia-yodo-pdx234.dtb' not remade because of errors.
make: Target 'qcom/msm8939-huawei-kiwi.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-wormdingler-rev1-inx.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-microsoft-arcata.dtb' not remade because of errors.
make: Target 'qcom/sdm845-oneplus-fajita.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-nots-r4.dtb' not remade because of errors.
make: Target 'qcom/sdm660-xiaomi-lavender.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-coachz-r1.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r10.dtb' not remade because of errors.
make: Target 'qcom/msm8939-wingtech-wt82918hd.dtb' not remade because of errors.
make: Target 'qcom/ipq6018-cp01-c1.dtb' not remade because of errors.
make: Target 'qcom/msm8916-motorola-surnia.dtb' not remade because of errors.
make: Target 'qcom/sm8350-microsoft-surface-duo2.dtb' not remade because of errors.
make: Target 'qcom/qcm6490-idp.dtb' not remade because of errors.
make: Target 'qcom/sm8550-mtp.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-a3u-eur.dtb' not remade because of errors.
make: Target 'qcom/sdm845-sony-xperia-tama-akari.dtb' not remade because of errors.
make: Target 'qcom/x1p42100-crd.dtb' not remade because of errors.
make: Target 'qcom/sm8250-mtp.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-nots-r9.dtb' not remade because of errors.
make: Target 'qcom/sm8250-xiaomi-elish-csot.dtb' not remade because of errors.
make: Target 'qcom/msm8916-wingtech-wt88047.dtb' not remade because of errors.
make: Target 'qcom/msm8916-thwc-ufi001c.dtb' not remade because of errors.
make: Target 'qcom/msm8998-xiaomi-sagit.dtb' not remade because of errors.
make: Target 'qcom/qcs8550-aim300-aiot.dtb' not remade because of errors.
make: Target 'qcom/sdm450-lenovo-tbx605f.dtb' not remade because of errors.
make: Target 'qcom/sm8250-xiaomi-elish-boe.dtb' not remade because of errors.
make: Target 'qcom/qcs404-evb-4000.dtb' not remade because of errors.
make: Target 'qcom/qcs9100-ride.dtb' not remade because of errors.
make: Target 'qcom/msm8996-sony-xperia-tone-kagura.dtb' not remade because of errors.
make: Target 'qcom/sm8150-sony-xperia-kumano-griffin.dtb' not remade because of errors.
make: Target 'qcom/sdm670-google-sargo.dtb' not remade because of errors.
make: Target 'qcom/x1e001de-devkit.dtb' not remade because of errors.
make: Target 'qcom/sa8775p-ride.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-crd.dtb' not remade because of errors.
make: Target 'qcom/ipq5424-rdp466.dtb' not remade because of errors.
make: Target 'qcom/sc8180x-lenovo-flex-5g.dtb' not remade because of errors.
make: Target 'qcom/sdm845-lg-judyln.dtb' not remade because of errors.
make: Target 'qcom/sm6125-xiaomi-ginkgo.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r3-kb.dtb' not remade because of errors.
make: Target 'qcom/msm8916-motorola-osprey.dtb' not remade because of errors.
make: Target 'qcom/sm8250-xiaomi-pipa.dtb' not remade because of errors.
make: Target 'qcom/sdm845-oneplus-enchilada.dtb' not remade because of errors.
make: Target 'qcom/msm8956-sony-xperia-loire-suzu.dtb' not remade because of errors.
make: Target 'qcom/sc7280-idp.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-evoker-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-homestar-r4.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-rossa.dtb' not remade because of errors.
make: Target 'qcom/apq8039-t2.dtb' not remade because of errors.
make: Target 'qcom/msm8916-motorola-harpia.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-e5.dtb' not remade because of errors.
make: Target 'qcom/sc7280-idp2.dtb' not remade because of errors.
make: Target 'qcom/apq8016-sbc-d3-camera-mezzanine.dtb' not remade because of errors.
make: Target 'qcom/msm8939-sony-xperia-kanuti-tulip.dtb' not remade because of errors.
make: Target 'qcom/ipq8074-hk01.dtb' not remade because of errors.
make: Target 'qcom/sm8150-mtp.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp433.dtb' not remade because of errors.
make: Target 'qcom/sdm845-sony-xperia-tama-apollo.dtb' not remade because of errors.
make: Target 'qcom/msm8998-lenovo-miix-630.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-karin.dtb' not remade because of errors.
make: Target 'qcom/sdm630-sony-xperia-nile-pioneer.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-grandmax.dtb' not remade because of errors.
make: Target 'qcom/msm8916-alcatel-idol347.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp453.dtb' not remade because of errors.
make: Target 'qcom/sc7180-acer-aspire1.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-r1.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-e7.dtb' not remade because of errors.
make: Target 'qcom/ipq5018-rdp432-c2.dtb' not remade because of errors.
make: Target 'qcom/apq8016-schneider-hmibsc.dtb' not remade because of errors.
make: Target 'qcom/qrb4210-rb2.dtb' not remade because of errors.
make: Target 'qcom/ipq5018-tplink-archer-ax55-v1.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-evoker.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-kingoftown.dtb' not remade because of errors.
make: Target 'qcom/sm4450-qrd.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-j5.dtb' not remade because of errors.
make: Target 'qcom/msm8998-asus-novago-tp370ql.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r2-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8992-lg-h815.dtb' not remade because of errors.
make: Target 'qcom/sdx75-idp.dtb' not remade because of errors.
make: Target 'qcom/sm8350-sony-xperia-sagami-pdx215.dtb' not remade because of errors.
make: Target 'qcom/apq8096-db820c.dtb' not remade because of errors.
make: Target 'qcom/msm8996-sony-xperia-tone-keyaki.dtb' not remade because of errors.
make: Target 'qcom/msm8916-longcheer-l8150.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-suzuran.dtb' not remade because of errors.
make: Target 'qcom/sdm845-mtp.dtb' not remade because of errors.
make: Target 'qcom/sm6375-sony-xperia-murray-pdx225.dtb' not remade because of errors.
make: Target 'qcom/msm8916-yiming-uz801v3.dtb' not remade because of errors.
make: Target 'qcom/qcs9100-ride-r3.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-hp-omnibook-x14.dtb' not remade because of errors.
make: Target 'qcom/msm8953-xiaomi-vince.dtb' not remade because of errors.
make: Target 'qcom/sdm845-cheza-r2.dtb' not remade because of errors.
make: Target 'qcom/ipq5332-rdp441.dtb' not remade because of errors.
make: Target 'qcom/msm8992-lg-bullhead-rev-101.dtb' not remade because of errors.
make: Target 'qcom/msm8917-xiaomi-riva.dtb' not remade because of errors.
make: Target 'qcom/msm8996-xiaomi-gemini.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-r9.dtb' not remade because of errors.
make: Target 'qcom/msm8998-sony-xperia-yoshino-lilac.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-gprimeltecan.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel360-lte.dtb' not remade because of errors.
make: Target 'qcom/sdm845-shift-axolotl.dtb' not remade because of errors.
make: Target 'qcom/msm8996-oneplus3t.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-zombie-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r3.dtb' not remade because of errors.
make: Target 'qcom/sar2130p-qar2130p.dtb' not remade because of errors.
make: Target 'qcom/sm8650-hdk.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-herobrine-r1.dtb' not remade because of errors.
make: Target 'qcom/msm8916-longcheer-l8910.dtb' not remade because of errors.
make: Target 'qcom/sdm630-sony-xperia-nile-voyager.dtb' not remade because of errors.
make: Target 'qcom/sm8450-hdk.dtb' not remade because of errors.
make: Target 'qcom/msm8929-wingtech-wt82918hd.dtb' not remade because of errors.
make: Target 'qcom/sm8250-sony-xperia-edo-pdx203.dtb' not remade because of errors.
make: Target 'qcom/sm8350-hdk.dtb' not remade because of errors.
make: Target 'qcom/ipq8074-hk10-c1.dtb' not remade because of errors.
make: Target 'qcom/sm8450-qrd.dtb' not remade because of errors.
make: Target 'qcom/msm8916-lg-c50.dtb' not remade because of errors.
make: Target 'qcom/sm8250-sony-xperia-edo-pdx206.dtb' not remade because of errors.
make: Target 'qcom/sm7225-fairphone-fp4.dtb' not remade because of errors.
make: Target 'qcom/sa8155p-adp.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-qcp.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r1-kb.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-grandprimelte.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-zombie-nvme-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-homestar-r3.dtb' not remade because of errors.
make: Target 'qcom/ipq5332-rdp474.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-asus-vivobook-s15.dtb' not remade because of errors.
make: Target 'qcom/sm8150-microsoft-surface-duo.dtb' not remade because of errors.
make: Target 'qcom/msm8996pro-xiaomi-scorpio.dtb' not remade because of errors.
make: Target 'qcom/x1e78100-lenovo-thinkpad-t14s.dtb' not remade because of errors.
make: Target 'qcom/sm8150-hdk.dtb' not remade because of errors.
make: Target 'qcom/sc8180x-primus.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r10-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-j5x.dtb' not remade because of errors.
make: Target 'qcom/sc7180-idp.dtb' not remade because of errors.
make: Target 'qcom/msm8916-mtp.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-hp-elitebook-ultra-g1q.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-r10.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-zombie-nvme.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-microsoft-romulus15.dtb' not remade because of errors.
make: Target 'qcom/qru1000-idp.dtb' not remade because of errors.
make: Target 'qcom/msm8998-hp-envy-x2.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-wormdingler-rev1-boe-rt5682s.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel-parade.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r9-kb.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-wormdingler-rev1-boe.dtb' not remade because of errors.
make: Target 'qcom/qcs615-ride.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-coachz-r3-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7280-crd-r3.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-gt58.dtb' not remade because of errors.
make: Target 'qcom/sa8775p-ride-r3.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-villager-r1.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel-ti.dtb' not remade because of errors.
make: Target 'qcom/qcm6490-shift-otter.dtb' not remade because of errors.
make: Target 'qcom/qcs8300-ride.dtb' not remade because of errors.
make: Target 'qcom/apq8016-sbc.dtb' not remade because of errors.
make: Target 'qcom/msm8996pro-xiaomi-natrium.dtb' not remade because of errors.
make: Target 'qcom/sdm845-samsung-starqltechn.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8953-xiaomi-tissot.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r9.dtb' not remade because of errors.
make: Target 'qcom/sm6125-xiaomi-laurel-sprout.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-sumire.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-serranove.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-coachz-r3.dtb' not remade because of errors.
make: Target 'qcom/sdm845-sony-xperia-tama-akatsuki.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp449.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8916-lg-m216.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-crd.dtb' not remade because of errors.
make: Target 'qcom/apq8094-sony-xperia-kitakami-karin_windy.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r9-lte.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel-lte-ti.dtb' not remade because of errors.
make: Target 'qcom/msm8996-sony-xperia-tone-dora.dtb' not remade because of errors.
make: Target 'qcom/sa8295p-adp.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-ivy.dtb' not remade because of errors.
make: Target 'qcom/sdm845-xiaomi-beryllium-ebbg.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r3.dtb' not remade because of errors.
make: Target 'qcom/msm8998-oneplus-dumpling.dtb' not remade because of errors.
make: Target 'qcom/sm8650-mtp.dtb' not remade because of errors.
make: Target 'qcom/msm8996-oneplus3.dtb' not remade because of errors.
make: Target 'qcom/sm8550-hdk.dtb' not remade because of errors.
make: Target 'qcom/x1e80100-microsoft-romulus13.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8939-samsung-a7.dtb' not remade because of errors.
make: Target 'qcom/qcm6490-fairphone-fp5.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-huawei-gaokun3.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-wormdingler-rev1-inx-rt5682s.dtb' not remade because of errors.
make: Target 'qcom/msm8953-xiaomi-mido.dtb' not remade because of errors.
make: Target 'qcom/msm8916-asus-z00l.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r2.dtb' not remade because of errors.
make: Target 'qcom/sm6350-sony-xperia-lena-pdx213.dtb' not remade because of errors.
make: Target 'qcom/sdm632-fairphone-fp3.dtb' not remade because of errors.
make: Target 'qcom/msm8953-motorola-potter.dtb' not remade because of errors.
make: Target 'qcom/sda660-inforce-ifc6560.dtb' not remade because of errors.
make: Target 'qcom/sm8150-sony-xperia-kumano-bahamut.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pazquel-lte-parade.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-homestar-r2.dtb' not remade because of errors.
make: Target 'qcom/sm8250-hdk.dtb' not remade because of errors.
make: Target 'qcom/sm8650-qrd.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-microsoft-blackrock.dtb' not remade because of errors.
make: Target 'qcom/ipq8074-hk10-c2.dtb' not remade because of errors.
make: Target 'qcom/msm8953-xiaomi-daisy.dtb' not remade because of errors.
make: Target 'qcom/sc8280xp-crd.dtb' not remade because of errors.
make: Target 'qcom/sdm850-samsung-w737.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-nots-r5.dtb' not remade because of errors.
make: Target 'qcom/msm8916-samsung-gt510.dtb' not remade because of errors.
make: Target 'qcom/sdm850-lenovo-yoga-c630.dtb' not remade because of errors.
make: Target 'qcom/msm8916-thwc-uf896.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r10-kb.dtb' not remade because of errors.
make: Target 'qcom/msm8994-sony-xperia-kitakami-satsuki.dtb' not remade because of errors.
make: Target 'qcom/sdm632-motorola-ocean.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-villager-r1-lte.dtb' not remade because of errors.
make: Target 'qcom/sm6115-fxtec-pro1x.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r3-lte.dtb' not remade because of errors.
make: Target 'qcom/msm8998-sony-xperia-yoshino-poplar.dtb' not remade because of errors.
make: Target 'qcom/msm8916-huawei-g7.dtb' not remade because of errors.
make: Target 'qcom/msm8916-wingtech-wt86518.dtb' not remade because of errors.
make: Target 'qcom/sm8350-sony-xperia-sagami-pdx214.dtb' not remade because of errors.
make: Target 'qcom/msm8916-wingtech-wt86528.dtb' not remade because of errors.
make: Target 'qcom/sdm845-db845c.dtb' not remade because of errors.
make: Target 'qcom/sa8540p-ride.dtb' not remade because of errors.
make: Target 'qcom/msm8939-longcheer-l9100.dtb' not remade because of errors.
make: Target 'qcom/qdu1000-idp.dtb' not remade because of errors.
make: Target 'qcom/sm8550-samsung-q5q.dtb' not remade because of errors.
make: Target 'qcom/msm8992-msft-lumia-octagon-talkman.dtb' not remade because of errors.
make: Target 'qcom/msm8916-gplus-fl8005a.dtb' not remade because of errors.
make: Target 'qcom/sm8350-mtp.dtb' not remade because of errors.
make: Target 'qcom/msm8956-sony-xperia-loire-kugo.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-r1.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-pompom-r1.dtb' not remade because of errors.
make: Target 'qcom/msm8998-oneplus-cheeseburger.dtb' not remade because of errors.
make: Target 'qcom/sc7280-herobrine-villager-r0.dtb' not remade because of errors.
make: Target 'qcom/sm8750-qrd.dtb' not remade because of errors.
make: Target 'qcom/sm4250-oneplus-billie2.dtb' not remade because of errors.
make: Target 'qcom/sdm636-sony-xperia-ganges-mermaid.dtb' not remade because of errors.
make: Target 'qcom/qcs404-evb-1000.dtb' not remade because of errors.
make: Target 'qcom/ipq5332-rdp442.dtb' not remade because of errors.
make: Target 'qcom/sdm845-cheza-r1.dtb' not remade because of errors.
make: Target 'qcom/msm8994-msft-lumia-octagon-cityman.dtb' not remade because of errors.
make: Target 'qcom/msm8916-acer-a1-724.dtb' not remade because of errors.
make: Target 'qcom/sdm845-xiaomi-beryllium-tianma.dtb' not remade because of errors.
make: Target 'qcom/sm6125-sony-xperia-seine-pdx201.dtb' not remade because of errors.
make: Target 'qcom/sdm845-xiaomi-polaris.dtb' not remade because of errors.
make: Target 'qcom/ipq9574-rdp418.dtb' not remade because of errors.
make: Target 'qcom/msm8216-samsung-fortuna3g.dtb' not remade because of errors.
make: Target 'qcom/sm8450-sony-xperia-nagara-pdx223.dtb' not remade because of errors.
make: Target 'qcom/sm8450-sony-xperia-nagara-pdx224.dtb' not remade because of errors.
make: Target 'qcom/sm7125-xiaomi-joyeuse.dtb' not remade because of errors.
make: Target 'qcom/msm8994-huawei-angler-rev-101.dtb' not remade because of errors.
make: Target 'qcom/ipq5332-rdp468.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-lazor-limozeen-nots-r10.dtb' not remade because of errors.
make: Target 'qcom/sc7180-trogdor-quackingstick-r0-lte.dtb' not remade because of errors.
© 2016 - 2025 Red Hat, Inc.