Add power sequence for vpu4 by reusing from previous generation wherever
possible. Hook up vpu4 op with vpu4 specific implemtation or resue from
earlier generation wherever feasible, like clock calculation in this
case.
Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
---
drivers/media/platform/qcom/iris/Makefile | 1 +
.../platform/qcom/iris/iris_platform_common.h | 7 +
drivers/media/platform/qcom/iris/iris_vpu4x.c | 369 +++++++++++++++++++++
drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
4 files changed, 378 insertions(+)
diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
index fad3be044e5fe783db697a592b4f09de4d42d0d2..2abbd3aeb4af07e52bf372a4b2f352463529c92c 100644
--- a/drivers/media/platform/qcom/iris/Makefile
+++ b/drivers/media/platform/qcom/iris/Makefile
@@ -22,6 +22,7 @@ qcom-iris-objs += iris_buffer.o \
iris_venc.o \
iris_vpu2.o \
iris_vpu3x.o \
+ iris_vpu4x.o \
iris_vpu_buffer.o \
iris_vpu_common.o \
diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
index 29900c3ea9b9ebbab614c804a249b08ba6001494..bc78cf7c77718666ddac86d6913b4d380991018f 100644
--- a/drivers/media/platform/qcom/iris/iris_platform_common.h
+++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
@@ -57,6 +57,10 @@ enum platform_clk_type {
IRIS_AXI1_CLK,
IRIS_CTRL_FREERUN_CLK,
IRIS_HW_FREERUN_CLK,
+ IRIS_BSE_HW_CLK,
+ IRIS_VPP0_HW_CLK,
+ IRIS_VPP1_HW_CLK,
+ IRIS_APV_HW_CLK,
};
struct platform_clk_data {
@@ -191,6 +195,9 @@ struct icc_vote_data {
enum platform_pm_domain_type {
IRIS_CTRL_POWER_DOMAIN,
IRIS_HW_POWER_DOMAIN,
+ IRIS_VPP0_HW_POWER_DOMAIN,
+ IRIS_VPP1_HW_POWER_DOMAIN,
+ IRIS_APV_HW_POWER_DOMAIN,
};
struct iris_platform_data {
diff --git a/drivers/media/platform/qcom/iris/iris_vpu4x.c b/drivers/media/platform/qcom/iris/iris_vpu4x.c
new file mode 100644
index 0000000000000000000000000000000000000000..a8db02ce5c5ec583c4027166b34ce51d3d683b4e
--- /dev/null
+++ b/drivers/media/platform/qcom/iris/iris_vpu4x.c
@@ -0,0 +1,369 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/iopoll.h>
+#include <linux/reset.h>
+
+#include "iris_instance.h"
+#include "iris_vpu_common.h"
+#include "iris_vpu_register_defines.h"
+
+#define AON_WRAPPER_MVP_NOC_RESET_SYNCRST (AON_MVP_NOC_RESET + 0x08)
+#define CPU_CS_APV_BRIDGE_SYNC_RESET (CPU_BASE_OFFS + 0x174)
+#define MVP_NOC_RESET_REQ_MASK 0x70103
+#define VPU_IDLE_BITS 0x7103
+#define WRAPPER_EFUSE_MONITOR (WRAPPER_BASE_OFFS + 0x08)
+
+#define APV_CLK_HALT BIT(1)
+#define CORE_CLK_HALT BIT(0)
+#define CORE_PWR_ON BIT(1)
+#define DISABLE_VIDEO_APV_BIT BIT(27)
+#define DISABLE_VIDEO_VPP1_BIT BIT(28)
+#define DISABLE_VIDEO_VPP0_BIT BIT(29)
+
+static int iris_vpu4x_genpd_set_hwmode(struct iris_core *core, bool hw_mode, u32 efuse_value)
+{
+ int ret;
+
+ ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], hw_mode);
+ if (ret)
+ return ret;
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP0_BIT)) {
+ ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs
+ [IRIS_VPP0_HW_POWER_DOMAIN], hw_mode);
+ if (ret)
+ goto restore_hw_domain_mode;
+ }
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP1_BIT)) {
+ ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs
+ [IRIS_VPP1_HW_POWER_DOMAIN], hw_mode);
+ if (ret)
+ goto restore_vpp0_domain_mode;
+ }
+
+ if (!(efuse_value & DISABLE_VIDEO_APV_BIT)) {
+ ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs
+ [IRIS_APV_HW_POWER_DOMAIN], hw_mode);
+ if (ret)
+ goto restore_vpp1_domain_mode;
+ }
+
+ return 0;
+
+restore_vpp1_domain_mode:
+ if (!(efuse_value & DISABLE_VIDEO_VPP1_BIT))
+ dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_VPP1_HW_POWER_DOMAIN],
+ !hw_mode);
+restore_vpp0_domain_mode:
+ if (!(efuse_value & DISABLE_VIDEO_VPP0_BIT))
+ dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_VPP0_HW_POWER_DOMAIN],
+ !hw_mode);
+restore_hw_domain_mode:
+ dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], !hw_mode);
+
+ return ret;
+}
+
+static int iris_vpu4x_power_on_apv(struct iris_core *core)
+{
+ int ret;
+
+ ret = iris_enable_power_domains(core,
+ core->pmdomain_tbl->pd_devs[IRIS_APV_HW_POWER_DOMAIN]);
+ if (ret)
+ return ret;
+
+ ret = iris_prepare_enable_clock(core, IRIS_APV_HW_CLK);
+ if (ret)
+ goto disable_apv_hw_power_domain;
+
+ return 0;
+
+disable_apv_hw_power_domain:
+ iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_APV_HW_POWER_DOMAIN]);
+
+ return ret;
+}
+
+static void iris_vpu4x_power_off_apv(struct iris_core *core)
+{
+ bool handshake_done, handshake_busy;
+ u32 value, count = 0;
+ int ret;
+
+ value = readl(core->reg_base + WRAPPER_CORE_CLOCK_CONFIG);
+
+ if (value & APV_CLK_HALT)
+ writel(0x0, core->reg_base + WRAPPER_CORE_CLOCK_CONFIG);
+
+ do {
+ writel(REQ_POWER_DOWN_PREP, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
+ usleep_range(10, 20);
+ value = readl(core->reg_base + AON_WRAPPER_MVP_NOC_LPI_STATUS);
+
+ handshake_done = value & NOC_LPI_STATUS_DONE;
+ handshake_busy = value & (NOC_LPI_STATUS_DENY | NOC_LPI_STATUS_ACTIVE);
+
+ if (handshake_done || !handshake_busy)
+ break;
+
+ writel(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
+ usleep_range(10, 20);
+
+ } while (++count < 1000);
+
+ if (!handshake_done && handshake_busy)
+ dev_err(core->dev, "LPI handshake timeout\n");
+
+ writel(0x080200, core->reg_base + AON_WRAPPER_MVP_NOC_RESET_REQ);
+ ret = readl_poll_timeout(core->reg_base + AON_WRAPPER_MVP_NOC_RESET_ACK,
+ value, value & 0x080200, 200, 2000);
+ if (ret)
+ goto disable_clocks_and_power;
+
+ writel(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_RESET_SYNCRST);
+ writel(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_RESET_REQ);
+ ret = readl_poll_timeout(core->reg_base + AON_WRAPPER_MVP_NOC_RESET_ACK,
+ value, value == 0x0, 200, 2000);
+ if (ret)
+ goto disable_clocks_and_power;
+
+ writel(CORE_BRIDGE_SW_RESET | CORE_BRIDGE_HW_RESET_DISABLE, core->reg_base +
+ CPU_CS_APV_BRIDGE_SYNC_RESET);
+ writel(CORE_BRIDGE_HW_RESET_DISABLE, core->reg_base + CPU_CS_APV_BRIDGE_SYNC_RESET);
+ writel(0x0, core->reg_base + CPU_CS_APV_BRIDGE_SYNC_RESET);
+
+disable_clocks_and_power:
+ iris_disable_unprepare_clock(core, IRIS_APV_HW_CLK);
+ iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_APV_HW_POWER_DOMAIN]);
+}
+
+static void iris_vpu4x_ahb_sync_reset_apv(struct iris_core *core)
+{
+ writel(CORE_BRIDGE_SW_RESET | CORE_BRIDGE_HW_RESET_DISABLE, core->reg_base +
+ CPU_CS_APV_BRIDGE_SYNC_RESET);
+ writel(CORE_BRIDGE_HW_RESET_DISABLE, core->reg_base + CPU_CS_APV_BRIDGE_SYNC_RESET);
+ writel(0x0, core->reg_base + CPU_CS_APV_BRIDGE_SYNC_RESET);
+}
+
+static void iris_vpu4x_ahb_sync_reset_hardware(struct iris_core *core)
+{
+ writel(CORE_BRIDGE_SW_RESET | CORE_BRIDGE_HW_RESET_DISABLE, core->reg_base +
+ CPU_CS_AHB_BRIDGE_SYNC_RESET);
+ writel(CORE_BRIDGE_HW_RESET_DISABLE, core->reg_base + CPU_CS_AHB_BRIDGE_SYNC_RESET);
+ writel(0x0, core->reg_base + CPU_CS_AHB_BRIDGE_SYNC_RESET);
+}
+
+static int iris_vpu4x_enable_hardware_clocks(struct iris_core *core, u32 efuse_value)
+{
+ int ret;
+
+ ret = iris_prepare_enable_clock(core, IRIS_AXI_CLK);
+ if (ret)
+ return ret;
+
+ ret = iris_prepare_enable_clock(core, IRIS_HW_FREERUN_CLK);
+ if (ret)
+ goto disable_axi_clock;
+
+ ret = iris_prepare_enable_clock(core, IRIS_HW_CLK);
+ if (ret)
+ goto disable_hw_free_run_clock;
+
+ ret = iris_prepare_enable_clock(core, IRIS_BSE_HW_CLK);
+ if (ret)
+ goto disable_hw_clock;
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP0_BIT)) {
+ ret = iris_prepare_enable_clock(core, IRIS_VPP0_HW_CLK);
+ if (ret)
+ goto disable_bse_hw_clock;
+ }
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP1_BIT)) {
+ ret = iris_prepare_enable_clock(core, IRIS_VPP1_HW_CLK);
+ if (ret)
+ goto disable_vpp0_hw_clock;
+ }
+
+ return 0;
+
+disable_vpp0_hw_clock:
+ if (!(efuse_value & DISABLE_VIDEO_VPP0_BIT))
+ iris_disable_unprepare_clock(core, IRIS_VPP0_HW_CLK);
+disable_bse_hw_clock:
+ iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
+disable_hw_clock:
+ iris_disable_unprepare_clock(core, IRIS_HW_CLK);
+disable_hw_free_run_clock:
+ iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
+disable_axi_clock:
+ iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
+
+ return ret;
+}
+
+static void iris_vpu4x_disable_hardware_clocks(struct iris_core *core, u32 efuse_value)
+{
+ if (!(efuse_value & DISABLE_VIDEO_VPP1_BIT))
+ iris_disable_unprepare_clock(core, IRIS_VPP1_HW_CLK);
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP0_BIT))
+ iris_disable_unprepare_clock(core, IRIS_VPP0_HW_CLK);
+
+ iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
+ iris_disable_unprepare_clock(core, IRIS_HW_CLK);
+ iris_disable_unprepare_clock(core, IRIS_HW_FREERUN_CLK);
+ iris_disable_unprepare_clock(core, IRIS_AXI_CLK);
+}
+
+static int iris_vpu4x_power_on_hardware(struct iris_core *core)
+{
+ u32 efuse_value = readl(core->reg_base + WRAPPER_EFUSE_MONITOR);
+ int ret;
+
+ ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
+ if (ret)
+ return ret;
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP0_BIT)) {
+ ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs
+ [IRIS_VPP0_HW_POWER_DOMAIN]);
+ if (ret)
+ goto disable_hw_power_domain;
+ }
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP1_BIT)) {
+ ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs
+ [IRIS_VPP1_HW_POWER_DOMAIN]);
+ if (ret)
+ goto disable_vpp0_power_domain;
+ }
+
+ ret = iris_vpu4x_enable_hardware_clocks(core, efuse_value);
+ if (ret)
+ goto disable_vpp1_power_domain;
+
+ if (!(efuse_value & DISABLE_VIDEO_APV_BIT)) {
+ ret = iris_vpu4x_power_on_apv(core);
+ if (ret)
+ goto disable_hw_clocks;
+
+ iris_vpu4x_ahb_sync_reset_apv(core);
+ }
+
+ iris_vpu4x_ahb_sync_reset_hardware(core);
+
+ ret = iris_vpu4x_genpd_set_hwmode(core, true, efuse_value);
+ if (ret)
+ goto disable_apv_power_domain;
+
+ return 0;
+
+disable_apv_power_domain:
+ if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
+ iris_vpu4x_power_off_apv(core);
+disable_hw_clocks:
+ iris_vpu4x_disable_hardware_clocks(core, efuse_value);
+disable_vpp1_power_domain:
+ if (!(efuse_value & DISABLE_VIDEO_VPP1_BIT))
+ iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs
+ [IRIS_VPP1_HW_POWER_DOMAIN]);
+disable_vpp0_power_domain:
+ if (!(efuse_value & DISABLE_VIDEO_VPP0_BIT))
+ iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs
+ [IRIS_VPP0_HW_POWER_DOMAIN]);
+disable_hw_power_domain:
+ iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
+
+ return ret;
+}
+
+static void iris_vpu4x_power_off_hardware(struct iris_core *core)
+{
+ u32 efuse_value = readl(core->reg_base + WRAPPER_EFUSE_MONITOR);
+ bool handshake_done, handshake_busy;
+ u32 value, count = 0;
+ int ret;
+
+ iris_vpu4x_genpd_set_hwmode(core, false, efuse_value);
+
+ if (!(efuse_value & DISABLE_VIDEO_APV_BIT))
+ iris_vpu4x_power_off_apv(core);
+
+ value = readl(core->reg_base + WRAPPER_CORE_POWER_STATUS);
+
+ if (!(value & CORE_PWR_ON))
+ goto disable_clocks_and_power;
+
+ value = readl(core->reg_base + WRAPPER_CORE_CLOCK_CONFIG);
+
+ if (value & CORE_CLK_HALT)
+ writel(0x0, core->reg_base + WRAPPER_CORE_CLOCK_CONFIG);
+
+ readl_poll_timeout(core->reg_base + VCODEC_SS_IDLE_STATUSN, value,
+ value & VPU_IDLE_BITS, 2000, 20000);
+
+ do {
+ writel(REQ_POWER_DOWN_PREP, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
+ usleep_range(10, 20);
+ value = readl(core->reg_base + AON_WRAPPER_MVP_NOC_LPI_STATUS);
+
+ handshake_done = value & NOC_LPI_STATUS_DONE;
+ handshake_busy = value & (NOC_LPI_STATUS_DENY | NOC_LPI_STATUS_ACTIVE);
+
+ if (handshake_done || !handshake_busy)
+ break;
+
+ writel(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_LPI_CONTROL);
+ usleep_range(10, 20);
+
+ } while (++count < 1000);
+
+ if (!handshake_done && handshake_busy)
+ dev_err(core->dev, "LPI handshake timeout\n");
+
+ writel(MVP_NOC_RESET_REQ_MASK, core->reg_base + AON_WRAPPER_MVP_NOC_RESET_REQ);
+ ret = readl_poll_timeout(core->reg_base + AON_WRAPPER_MVP_NOC_RESET_ACK,
+ value, value & MVP_NOC_RESET_REQ_MASK, 200, 2000);
+ if (ret)
+ goto disable_clocks_and_power;
+
+ writel(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_RESET_SYNCRST);
+ writel(0x0, core->reg_base + AON_WRAPPER_MVP_NOC_RESET_REQ);
+ ret = readl_poll_timeout(core->reg_base + AON_WRAPPER_MVP_NOC_RESET_ACK,
+ value, value == 0x0, 200, 2000);
+ if (ret)
+ goto disable_clocks_and_power;
+
+ writel(CORE_BRIDGE_SW_RESET | CORE_BRIDGE_HW_RESET_DISABLE, core->reg_base +
+ CPU_CS_AHB_BRIDGE_SYNC_RESET);
+ writel(CORE_BRIDGE_HW_RESET_DISABLE, core->reg_base + CPU_CS_AHB_BRIDGE_SYNC_RESET);
+ writel(0x0, core->reg_base + CPU_CS_AHB_BRIDGE_SYNC_RESET);
+
+disable_clocks_and_power:
+ iris_vpu4x_disable_hardware_clocks(core, efuse_value);
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP1_BIT))
+ iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs
+ [IRIS_VPP1_HW_POWER_DOMAIN]);
+
+ if (!(efuse_value & DISABLE_VIDEO_VPP0_BIT))
+ iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs
+ [IRIS_VPP0_HW_POWER_DOMAIN]);
+
+ iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
+}
+
+const struct vpu_ops iris_vpu4x_ops = {
+ .power_off_hw = iris_vpu4x_power_off_hardware,
+ .power_on_hw = iris_vpu4x_power_on_hardware,
+ .power_off_controller = iris_vpu35_vpu4x_power_off_controller,
+ .power_on_controller = iris_vpu35_vpu4x_power_on_controller,
+ .program_bootup_registers = iris_vpu35_vpu4x_program_bootup_registers,
+ .calc_freq = iris_vpu3x_vpu4x_calculate_frequency,
+};
diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.h b/drivers/media/platform/qcom/iris/iris_vpu_common.h
index 7cf4304604cca590544a938c7e811c202cea3d93..f6dffc613b822341fb21e12de6b1395202f62cde 100644
--- a/drivers/media/platform/qcom/iris/iris_vpu_common.h
+++ b/drivers/media/platform/qcom/iris/iris_vpu_common.h
@@ -12,6 +12,7 @@ extern const struct vpu_ops iris_vpu2_ops;
extern const struct vpu_ops iris_vpu3_ops;
extern const struct vpu_ops iris_vpu33_ops;
extern const struct vpu_ops iris_vpu35_ops;
+extern const struct vpu_ops iris_vpu4x_ops;
struct vpu_ops {
void (*power_off_hw)(struct iris_core *core);
--
2.34.1On 12/10/2025 6:06 PM, Vikash Garodia wrote: > Add power sequence for vpu4 by reusing from previous generation wherever > possible. Hook up vpu4 op with vpu4 specific implemtation or resue from > earlier generation wherever feasible, like clock calculation in this > case. > > Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> > Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> > Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> > --- > drivers/media/platform/qcom/iris/Makefile | 1 + > .../platform/qcom/iris/iris_platform_common.h | 7 + > drivers/media/platform/qcom/iris/iris_vpu4x.c | 369 +++++++++++++++++++++ > drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 + > 4 files changed, 378 insertions(+) > Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Thanks, Dikshita
On 16/01/2026 10:51, Dikshita Agarwal wrote: > > > On 12/10/2025 6:06 PM, Vikash Garodia wrote: >> Add power sequence for vpu4 by reusing from previous generation wherever >> possible. Hook up vpu4 op with vpu4 specific implemtation or resue from >> earlier generation wherever feasible, like clock calculation in this >> case. >> >> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> >> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> >> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> >> --- >> drivers/media/platform/qcom/iris/Makefile | 1 + >> .../platform/qcom/iris/iris_platform_common.h | 7 + >> drivers/media/platform/qcom/iris/iris_vpu4x.c | 369 +++++++++++++++++++++ >> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 + >> 4 files changed, 378 insertions(+) >> > > Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Thank you for reviewing this code. I would like to point that it took one month for Qualcomm to review this Qualcomm patch and in the same time Vikash is sending emails (more than one!) that Bryan does not review that fast as expected. I do not find it acceptable approach to harass community reviewers that way. Even if you do it internally, not on the lists. I think this review timeline is final argument for Vikash to stop pushing such narratives and complains, because your review is expected to be BEFORE the maintainer upper in the upstream flow. Best regards, Krzysztof
On 1/16/2026 4:16 PM, Krzysztof Kozlowski wrote: > On 16/01/2026 10:51, Dikshita Agarwal wrote: >> >> >> On 12/10/2025 6:06 PM, Vikash Garodia wrote: >>> Add power sequence for vpu4 by reusing from previous generation wherever >>> possible. Hook up vpu4 op with vpu4 specific implemtation or resue from >>> earlier generation wherever feasible, like clock calculation in this >>> case. >>> >>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> >>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> >>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> >>> --- >>> drivers/media/platform/qcom/iris/Makefile | 1 + >>> .../platform/qcom/iris/iris_platform_common.h | 7 + >>> drivers/media/platform/qcom/iris/iris_vpu4x.c | 369 +++++++++++++++++++++ >>> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 + >>> 4 files changed, 378 insertions(+) >>> >> >> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> > > > Thank you for reviewing this code. I would like to point that it took > one month for Qualcomm to review this Qualcomm patch and in the same > time Vikash is sending emails (more than one!) that Bryan does not > review that fast as expected. > > I do not find it acceptable approach to harass community reviewers that > way. Even if you do it internally, not on the lists. > > I think this review timeline is final argument for Vikash to stop > pushing such narratives and complains, because your review is expected > to be BEFORE the maintainer upper in the upstream flow. Since these changes were posted by Vikash, who is a co‑maintainer of this driver, I initially waited for reviews from other community members before adding my own tags. We did receive review comments on most of the patches, and I intentionally held back my Reviewed-by tags to allow space for broader feedback. Now that the series has been on the mailing list for about a month without any remaining open comments, I have gone ahead and reviewed the patches, Since The changes look good to me and are ready for this merge cycle. Thanks, Dikshita > > Best regards, > Krzysztof
On 16/01/2026 12:30, Dikshita Agarwal wrote: >> >> I think this review timeline is final argument for Vikash to stop >> pushing such narratives and complains, because your review is expected >> to be BEFORE the maintainer upper in the upstream flow. > > Since these changes were posted by Vikash, who is a co‑maintainer of this > driver, I initially waited for reviews from other community members before > adding my own tags. We did receive review comments on most of the patches, This is not how it works. > and I intentionally held back my Reviewed-by tags to allow space for > broader feedback. > > Now that the series has been on the mailing list for about a month without > any remaining open comments, I have gone ahead and reviewed the patches, You as a driver maintainer should review within few days, week maximum. Not a month. And IT IS DOCUMENTED. You do not need to wait for anyone in the community for performing your side of driver review. Performing review after one month is not really responsible, but the only party you affect is your own team, so sure, I don't mind. But DO NOT apply such rule of waiting months for the rest of the community. Please read Documentation/maintainer/feature-and-driver-maintainers.rst which gives you clear guidelines what is expected, including the timeline. If you disagree and claim Iris is maintained by you in weeks-time (one month), that rule will apply to all of us, entire community and also to Bryan - we all can look at patches to Iris within that timeframe. Best regards, Krzysztof
On 1/16/2026 4:16 PM, Krzysztof Kozlowski wrote: > On 16/01/2026 10:51, Dikshita Agarwal wrote: >> >> >> On 12/10/2025 6:06 PM, Vikash Garodia wrote: >>> Add power sequence for vpu4 by reusing from previous generation wherever >>> possible. Hook up vpu4 op with vpu4 specific implemtation or resue from >>> earlier generation wherever feasible, like clock calculation in this >>> case. >>> >>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> >>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> >>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> >>> --- >>> drivers/media/platform/qcom/iris/Makefile | 1 + >>> .../platform/qcom/iris/iris_platform_common.h | 7 + >>> drivers/media/platform/qcom/iris/iris_vpu4x.c | 369 +++++++++++++++++++++ >>> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 + >>> 4 files changed, 378 insertions(+) >>> >> >> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> > > > Thank you for reviewing this code. I would like to point that it took > one month for Qualcomm to review this Qualcomm patch and in the same > time Vikash is sending emails (more than one!) that Bryan does not > review that fast as expected. Firstly, the ask to Bryan have been to pull patches (not stressed on review part), infact, even fixes are waiting for merge window while they can easily go into RCs. This part of the process need some improvement. I have also appreciated him when he pulled long series for initial codec enablement, i think you missed those part. > > I do not find it acceptable approach to harass community reviewers that > way. Even if you do it internally, not on the lists. > > I think this review timeline is final argument for Vikash to stop > pushing such narratives and complains, because your review is expected > to be BEFORE the maintainer upper in the upstream flow. My understanding is that, if maintainer raise patches, then its more of reviews from community and having RB tag from any of community member or no open comments implies the series is good to go. This series is lying there for a month without any open comment, there is nothing pending here to pull them. Regards, Vikash > > Best regards, > Krzysztof
On 16/01/2026 11:27, Vikash Garodia wrote: >> Thank you for reviewing this code. I would like to point that it took >> one month for Qualcomm to review this Qualcomm patch and in the same >> time Vikash is sending emails (more than one!) that Bryan does not >> review that fast as expected. > Firstly, the ask to Bryan have been to pull patches (not stressed on > review part), infact, even fixes are waiting for merge window while they > can easily go into RCs. This part of the process need some improvement. > > I have also appreciated him when he pulled long series for initial codec > enablement, i think you missed those part. > >> I do not find it acceptable approach to harass community reviewers that >> way. Even if you do it internally, not on the lists. lol >> I think this review timeline is final argument for Vikash to stop >> pushing such narratives and complains, because your review is expected >> to be BEFORE the maintainer upper in the upstream flow. > My understanding is that, if maintainer raise patches, then its more of > reviews from community and having RB tag from any of community member or > no open comments implies the series is good to go. > > This series is lying there for a month without any open comment, there > is nothing pending here to pull them. 2/6 patches in this series were marked in patchwork as having no RB so they weren't pulled. That's the whole story here. --- bod
On 16/01/2026 12:27, Vikash Garodia wrote: > > On 1/16/2026 4:16 PM, Krzysztof Kozlowski wrote: >> On 16/01/2026 10:51, Dikshita Agarwal wrote: >>> >>> >>> On 12/10/2025 6:06 PM, Vikash Garodia wrote: >>>> Add power sequence for vpu4 by reusing from previous generation wherever >>>> possible. Hook up vpu4 op with vpu4 specific implemtation or resue from >>>> earlier generation wherever feasible, like clock calculation in this >>>> case. >>>> >>>> Co-developed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> >>>> Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> >>>> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> >>>> --- >>>> drivers/media/platform/qcom/iris/Makefile | 1 + >>>> .../platform/qcom/iris/iris_platform_common.h | 7 + >>>> drivers/media/platform/qcom/iris/iris_vpu4x.c | 369 +++++++++++++++++++++ >>>> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 + >>>> 4 files changed, 378 insertions(+) >>>> >>> >>> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> >> >> >> Thank you for reviewing this code. I would like to point that it took >> one month for Qualcomm to review this Qualcomm patch and in the same >> time Vikash is sending emails (more than one!) that Bryan does not >> review that fast as expected. > > Firstly, the ask to Bryan have been to pull patches (not stressed on > review part), infact, even fixes are waiting for merge window while they > can easily go into RCs. This part of the process need some improvement. Lack of timeline reviews is the process needing improvement. Please read feature-and-driver-maintainers.rst document to understand the expectations of you. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.