* Re: [PATCH 08/11] media: iris: Add power sequence for Glymur
From: Vishnu Reddy @ 2026-04-17 16:04 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu
In-Reply-To: <1de1a366-a325-428e-9dcc-1333bb85ed82@oss.qualcomm.com>
On 4/14/2026 3:19 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> Add power sequence hooks for controller, vcodec and vcodec1. reuse the
>> existing code where ever is possible. add vcodec1 power on and off code
>> separately which has different power domains and clocks.
>>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> .../platform/qcom/iris/iris_platform_common.h | 9 ++
>> drivers/media/platform/qcom/iris/iris_vpu3x.c | 123 +++++++++++++++++++++
>> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
>> .../platform/qcom/iris/iris_vpu_register_defines.h | 7 ++
>> 4 files changed, 140 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> index 30e9d4d288c6..e3c1aff770dd 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> @@ -61,6 +61,9 @@ enum platform_clk_type {
>> IRIS_VPP0_HW_CLK,
>> IRIS_VPP1_HW_CLK,
>> IRIS_APV_HW_CLK,
>> + IRIS_AXI_VCODEC1_CLK,
>> + IRIS_VCODEC1_CLK,
>> + IRIS_VCODEC1_FREERUN_CLK,
>> };
>>
>> struct platform_clk_data {
>> @@ -208,6 +211,12 @@ enum platform_pm_domain_type {
>> IRIS_CTRL_POWER_DOMAIN,
>> IRIS_VCODEC_POWER_DOMAIN,
>> IRIS_VPP0_HW_POWER_DOMAIN,
>> + /*
>> + * On Glymur, vcodec1 power domain is at the same index in pd_devs[]
>> + * as IRIS_VPP0_HW_POWER_DOMAIN. Alias it so that the Glymur power
>> + * domain table is indexed correctly.
>> + */
>> + IRIS_VCODEC1_POWER_DOMAIN = IRIS_VPP0_HW_POWER_DOMAIN,
> This feels really fragile..
I'm thinking to add wrapper and use the power domain name to find the
index from the
platform data instead of using the enum values. I'll try this if that works.
> [...]
>
>> +static bool iris_vpu36_hw1_power_collapsed(struct iris_core *core)
>> +{
>> + u32 value, pwr_status;
>> +
>> + value = readl(core->reg_base + WRAPPER_CORE_POWER_STATUS);
>> + pwr_status = value & BIT(4);
>> +
>> + return pwr_status ? false : true;
> return !pwr_status
Ack.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH 10/11] media: iris: Add platform data for glymur
From: Vishnu Reddy @ 2026-04-17 15:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <zieokmtef7z4sqle7dgy4rv7t3egcgzji5fwrogc7pz4sz4msa@gthghxow3gkf>
On 4/14/2026 9:35 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:30:06AM +0530, Vishnu Reddy wrote:
>> Add glymur platform data by reusing most of the SM8550 definitions.
>> Move configuration that differs in a per-SoC platform specific data.
>>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/Makefile | 1 +
>> .../platform/qcom/iris/iris_platform_common.h | 1 +
>> .../media/platform/qcom/iris/iris_platform_gen2.c | 100 +++++++++++++++++++++
>> .../platform/qcom/iris/iris_platform_glymur.c | 93 +++++++++++++++++++
>> .../platform/qcom/iris/iris_platform_glymur.h | 17 ++++
>> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
>> 6 files changed, 216 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
>> index 6f4052b98491..677513c7c045 100644
>> --- a/drivers/media/platform/qcom/iris/Makefile
>> +++ b/drivers/media/platform/qcom/iris/Makefile
>> @@ -11,6 +11,7 @@ qcom-iris-objs += iris_buffer.o \
>> iris_hfi_gen2_response.o \
>> iris_hfi_queue.o \
>> iris_platform_gen2.o \
>> + iris_platform_glymur.o \
>> iris_power.o \
>> iris_probe.o \
>> iris_resources.o \
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> index aeb70f54be10..a279ea462ee6 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> @@ -41,6 +41,7 @@ enum pipe_type {
>> PIPE_4 = 4,
>> };
>>
>> +extern const struct iris_platform_data glymur_data;
>> extern const struct iris_platform_data qcs8300_data;
>> extern const struct iris_platform_data sc7280_data;
>> extern const struct iris_platform_data sm8250_data;
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> index 47c6b650f0b4..fa2115092be8 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> @@ -12,6 +12,7 @@
>> #include "iris_vpu_buffer.h"
>> #include "iris_vpu_common.h"
>>
>> +#include "iris_platform_glymur.h"
>> #include "iris_platform_qcs8300.h"
>> #include "iris_platform_sm8650.h"
>> #include "iris_platform_sm8750.h"
>> @@ -921,6 +922,105 @@ static const u32 sm8550_enc_op_int_buf_tbl[] = {
>> BUF_SCRATCH_2,
>> };
>>
>> +const struct iris_platform_data glymur_data = {
> If you add a platform-specific file, then move the data to the file too.
glymur_data reusing the most of the sm8550 definitions which is in this
source file.
one option is to introduce gen2 header file and extern all the glymur
required definitions
in that. glymur source can include that gen2 header.
> Also, please use iris_something prefix for all your visible symbols.
Ack, I'll add iris prefix.
>> + .get_instance = iris_hfi_gen2_get_instance,
>> + .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>> + .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
>> + .get_vpu_buffer_size = iris_vpu_buf_size,
>> + .vpu_ops = &iris_vpu36_ops,
>> + .set_preset_registers = iris_set_sm8550_preset_registers,
>> + .init_cb_devs = glymur_init_cb_devs,
>> + .deinit_cb_devs = glymur_deinit_cb_devs,
>> + .icc_tbl = sm8550_icc_table,
>> + .icc_tbl_size = ARRAY_SIZE(sm8550_icc_table),
>> + .clk_rst_tbl = glymur_clk_reset_table,
>> + .clk_rst_tbl_size = ARRAY_SIZE(glymur_clk_reset_table),
>> + .bw_tbl_dec = sm8550_bw_table_dec,
>> + .bw_tbl_dec_size = ARRAY_SIZE(sm8550_bw_table_dec),
>> + .pmdomain_tbl = glymur_pmdomain_table,
>> + .pmdomain_tbl_size = ARRAY_SIZE(glymur_pmdomain_table),
>> + .opp_pd_tbl = sm8550_opp_pd_table,
>> + .opp_pd_tbl_size = ARRAY_SIZE(sm8550_opp_pd_table),
>> + .clk_tbl = glymur_clk_table,
>> + .clk_tbl_size = ARRAY_SIZE(glymur_clk_table),
>> + .opp_clk_tbl = glymur_opp_clk_table,
>> + /* Upper bound of DMA address range */
>> + .dma_mask = 0xffe00000 - 1,
>> + .fwname = "qcom/vpu/vpu36_p4_s7.mbn",
>> + .pas_id = IRIS_PAS_ID,
>> + .dual_core = true,
>> + .inst_iris_fmts = platform_fmts_sm8550_dec,
>> + .inst_iris_fmts_size = ARRAY_SIZE(platform_fmts_sm8550_dec),
>> + .inst_caps = &platform_inst_cap_sm8550,
>> + .inst_fw_caps_dec = inst_fw_cap_sm8550_dec,
>> + .inst_fw_caps_dec_size = ARRAY_SIZE(inst_fw_cap_sm8550_dec),
>> + .inst_fw_caps_enc = inst_fw_cap_sm8550_enc,
>> + .inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_sm8550_enc),
>> + .tz_cp_config_data = tz_cp_config_glymur,
>> + .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_glymur),
>> + .core_arch = VIDEO_ARCH_LX,
>> + .hw_response_timeout = HW_RESPONSE_TIMEOUT_VALUE,
>> + .ubwc_config = &ubwc_config_sm8550,
>> + .num_vpp_pipe = 4,
>> + .max_session_count = 16,
>> + .max_core_mbpf = NUM_MBS_8K * 2,
>> + .max_core_mbps = ((8192 * 4320) / 256) * 60,
>> + .dec_input_config_params_default =
>> + sm8550_vdec_input_config_params_default,
>> + .dec_input_config_params_default_size =
>> + ARRAY_SIZE(sm8550_vdec_input_config_params_default),
>> + .dec_input_config_params_hevc =
>> + sm8550_vdec_input_config_param_hevc,
>> + .dec_input_config_params_hevc_size =
>> + ARRAY_SIZE(sm8550_vdec_input_config_param_hevc),
>> + .dec_input_config_params_vp9 =
>> + sm8550_vdec_input_config_param_vp9,
>> + .dec_input_config_params_vp9_size =
>> + ARRAY_SIZE(sm8550_vdec_input_config_param_vp9),
>> + .dec_input_config_params_av1 =
>> + sm8550_vdec_input_config_param_av1,
>> + .dec_input_config_params_av1_size =
>> + ARRAY_SIZE(sm8550_vdec_input_config_param_av1),
>> + .dec_output_config_params =
>> + sm8550_vdec_output_config_params,
>> + .dec_output_config_params_size =
>> + ARRAY_SIZE(sm8550_vdec_output_config_params),
>> +
>> + .enc_input_config_params =
>> + sm8550_venc_input_config_params,
>> + .enc_input_config_params_size =
>> + ARRAY_SIZE(sm8550_venc_input_config_params),
>> + .enc_output_config_params =
>> + sm8550_venc_output_config_params,
>> + .enc_output_config_params_size =
>> + ARRAY_SIZE(sm8550_venc_output_config_params),
>> +
>> + .dec_input_prop = sm8550_vdec_subscribe_input_properties,
>> + .dec_input_prop_size = ARRAY_SIZE(sm8550_vdec_subscribe_input_properties),
>> + .dec_output_prop_avc = sm8550_vdec_subscribe_output_properties_avc,
>> + .dec_output_prop_avc_size =
>> + ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_avc),
>> + .dec_output_prop_hevc = sm8550_vdec_subscribe_output_properties_hevc,
>> + .dec_output_prop_hevc_size =
>> + ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_hevc),
>> + .dec_output_prop_vp9 = sm8550_vdec_subscribe_output_properties_vp9,
>> + .dec_output_prop_vp9_size =
>> + ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_vp9),
>> + .dec_output_prop_av1 = sm8550_vdec_subscribe_output_properties_av1,
>> + .dec_output_prop_av1_size =
>> + ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_av1),
>> +
>> + .dec_ip_int_buf_tbl = sm8550_dec_ip_int_buf_tbl,
>> + .dec_ip_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_ip_int_buf_tbl),
>> + .dec_op_int_buf_tbl = sm8550_dec_op_int_buf_tbl,
>> + .dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_op_int_buf_tbl),
>> +
>> + .enc_ip_int_buf_tbl = sm8550_enc_ip_int_buf_tbl,
>> + .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_ip_int_buf_tbl),
>> + .enc_op_int_buf_tbl = sm8550_enc_op_int_buf_tbl,
>> + .enc_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_op_int_buf_tbl),
>> +};
>> +
>> const struct iris_platform_data sm8550_data = {
>> .get_instance = iris_hfi_gen2_get_instance,
>> .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_glymur.c b/drivers/media/platform/qcom/iris/iris_platform_glymur.c
>> new file mode 100644
>> index 000000000000..64b150db9f73
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_glymur.c
>> @@ -0,0 +1,93 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include <dt-bindings/media/qcom,glymur-iris.h>
>> +#include "iris_core.h"
>> +#include "iris_platform_common.h"
>> +#include "iris_platform_glymur.h"
>> +
>> +#define VIDEO_REGION_SECURE_FW_REGION_ID 0
>> +#define VIDEO_REGION_VM0_SECURE_NP_ID 1
>> +#define VIDEO_REGION_VM0_NONSECURE_NP_ID 5
> These are not glymur-specific, are they?
It's common for upcoming platforms as well. I'll move this to common
platform header.
>> +
>> +const struct platform_clk_data glymur_clk_table[] = {
>> + {IRIS_AXI_VCODEC_CLK, "iface" },
>> + {IRIS_CTRL_CLK, "core" },
>> + {IRIS_VCODEC_CLK, "vcodec0_core" },
>> + {IRIS_AXI_CTRL_CLK, "iface_ctrl" },
>> + {IRIS_CTRL_FREERUN_CLK, "core_freerun" },
>> + {IRIS_VCODEC_FREERUN_CLK, "vcodec0_core_freerun" },
>> + {IRIS_AXI_VCODEC1_CLK, "iface1" },
>> + {IRIS_VCODEC1_CLK, "vcodec1_core" },
>> + {IRIS_VCODEC1_FREERUN_CLK, "vcodec1_core_freerun" },
>> +};
>> +
>> +const char * const glymur_clk_reset_table[] = {
>> + "bus0",
>> + "bus_ctrl",
>> + "core",
>> + "vcodec0_core",
>> + "bus1",
>> + "vcodec1_core",
>> +};
>> +
>> +const char * const glymur_opp_clk_table[] = {
>> + "vcodec0_core",
>> + "vcodec1_core",
>> + "core",
>> + NULL,
>> +};
>> +
>> +const char * const glymur_pmdomain_table[] = {
>> + "venus",
>> + "vcodec0",
>> + "vcodec1",
>> +};
>> +
>> +const struct tz_cp_config tz_cp_config_glymur[] = {
>> + {
>> + .cp_start = VIDEO_REGION_SECURE_FW_REGION_ID,
>> + .cp_size = 0,
>> + .cp_nonpixel_start = 0,
>> + .cp_nonpixel_size = 0x1000000,
>> + },
>> + {
>> + .cp_start = VIDEO_REGION_VM0_SECURE_NP_ID,
>> + .cp_size = 0,
>> + .cp_nonpixel_start = 0x1000000,
>> + .cp_nonpixel_size = 0x24800000,
>> + },
>> + {
>> + .cp_start = VIDEO_REGION_VM0_NONSECURE_NP_ID,
>> + .cp_size = 0,
>> + .cp_nonpixel_start = 0x25800000,
>> + .cp_nonpixel_size = 0xda600000,
>> + },
>> +};
>> +
>> +int glymur_init_cb_devs(struct iris_core *core)
>> +{
>> + const u32 f_id = IRIS_FIRMWARE;
>> + struct device *dev;
>> +
>> + dev = iris_create_cb_dev(core, "iris_firmware", &f_id);
>> + if (IS_ERR(dev))
>> + return PTR_ERR(dev);
>> +
>> + if (device_iommu_mapped(dev))
>> + core->dev_fw = dev;
>> + else
>> + device_unregister(dev);
>> +
>> + return 0;
>> +}
>> +
>> +void glymur_deinit_cb_devs(struct iris_core *core)
>> +{
>> + if (core->dev_fw)
>> + device_unregister(core->dev_fw);
>> +
>> + core->dev_fw = NULL;
> Why do you need to set it to NULL?
Not needed, I'll drop it.
Thanks,
Vishnu Reddy.
>> +}
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_glymur.h b/drivers/media/platform/qcom/iris/iris_platform_glymur.h
>> new file mode 100644
>> index 000000000000..03c83922f0d9
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_glymur.h
>> @@ -0,0 +1,17 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#ifndef __IRIS_PLATFORM_GLYMUR_H__
>> +#define __IRIS_PLATFORM_GLYMUR_H__
>> +
>> +extern const struct platform_clk_data glymur_clk_table[9];
>> +extern const char * const glymur_clk_reset_table[6];
>> +extern const char * const glymur_opp_clk_table[4];
>> +extern const char * const glymur_pmdomain_table[3];
>> +extern const struct tz_cp_config tz_cp_config_glymur[3];
>> +int glymur_init_cb_devs(struct iris_core *core);
>> +void glymur_deinit_cb_devs(struct iris_core *core);
>> +
>> +#endif
>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
>> index 34751912f871..53869d9113d5 100644
>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>> @@ -369,6 +369,10 @@ static const struct dev_pm_ops iris_pm_ops = {
>> };
>>
>> static const struct of_device_id iris_dt_match[] = {
>> + {
>> + .compatible = "qcom,glymur-iris",
>> + .data = &glymur_data,
>> + },
>> {
>> .compatible = "qcom,qcs8300-iris",
>> .data = &qcs8300_data,
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 09/11] media: iris: Add support to select core for dual core platforms
From: Vishnu Reddy @ 2026-04-17 15:36 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu
In-Reply-To: <d1834575-768e-4805-9e21-50a796690bda@oss.qualcomm.com>
On 4/14/2026 3:21 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> Select the hardware core (vcodec) for a session, based on load when the
>> platform supports dual vcodec cores. Assign the session to vcodec if its
>> MBPF/MBPS capacity allows it, otherwise assign to vcodec1. Communicate
>> the selected vcodec core to firmware using new HFI_PROP_CORE_ID property.
>>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
> [...]
>
>> + if (core_mbpf[0] + new_mbpf <= max_core_mbpf)
>> + inst->core_id = BIT(0);
>> + else if (dual_core && core_mbpf[1] + new_mbpf <= max_core_mbpf)
>> + inst->core_id = BIT(1);
> Let's store the core ID as an index and only wrap it in BIT() where
> necessary to pass into the firmware
For the current instance, I'm marking the inst->core_id = 0 at initial
to skip that current inst
for the calculation of current load. If we store index in core_id, then
need to pass the current
inst to iris_get_core_load() and additional check required in that
function for proper core load.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 15:29 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu, stable
In-Reply-To: <otikvdonnfakykra57z4fingdyfm7xebw2h3lmykzk6sbk7emq@xptiwpx5lvjl>
On 4/14/2026 8:50 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:30:02AM +0530, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
> Does this apply to Glymur only or to other platforms too?
Only Glymur firmware is currently reading this register and other
platform firmwares are
ignoring this.
Thanks,
Vishnu Reddy.
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
>>
>> Fixes: abf5bac63f68a ("media: iris: implement the boot sequence of the firmware")
>> Cc:stable@vger.kernel.org
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/iris_vpu_common.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> index 548e5f1727fd..bfd1e762c38e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> @@ -78,7 +78,6 @@ int iris_vpu_boot_firmware(struct iris_core *core)
>> iris_vpu_setup_ucregion_memory_map(core);
>>
>> writel(ctrl_init, core->reg_base + CTRL_INIT);
>> - writel(0x1, core->reg_base + CPU_CS_SCIACMDARG3);
>>
>> while (!ctrl_status && count < max_tries) {
>> ctrl_status = readl(core->reg_base + CTRL_STATUS);
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 15:28 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu, stable
In-Reply-To: <20260414063325.f3yag6gnmaysddkp@hu-mojha-hyd.qualcomm.com>
On 4/14/2026 12:03 PM, Mukesh Ojha wrote:
> On Tue, Apr 14, 2026 at 10:30:02AM +0530, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
>>
>> Fixes: abf5bac63f68a ("media: iris: implement the boot sequence of the firmware")
>> Cc:stable@vger.kernel.org
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
> If this is a fix, should be the first patch in the series., so that it
> can be applied independently.
Ack, I'll move it accordingly.
>> ---
>> drivers/media/platform/qcom/iris/iris_vpu_common.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> index 548e5f1727fd..bfd1e762c38e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> @@ -78,7 +78,6 @@ int iris_vpu_boot_firmware(struct iris_core *core)
>> iris_vpu_setup_ucregion_memory_map(core);
>>
>> writel(ctrl_init, core->reg_base + CTRL_INIT);
>> - writel(0x1, core->reg_base + CPU_CS_SCIACMDARG3);
>>
>> while (!ctrl_status && count < max_tries) {
>> ctrl_status = readl(core->reg_base + CTRL_STATUS);
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 05/11] media: iris: Enable Secure PAS support with IOMMU managed by Linux
From: Vishnu Reddy @ 2026-04-17 15:27 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu,
Mukesh Ojha
In-Reply-To: <809e2ad6-258c-49ac-9f3b-4ced32807203@oss.qualcomm.com>
On 4/14/2026 7:39 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> From: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
>>
>> Most Qualcomm platforms feature a proprietary hypervisor (such as Gunyah
>> or QHEE), which typically handles IOMMU configuration. This includes
>> mapping memory regions and device memory resources for remote processors
>> by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are
>> later removed during teardown. Additionally, SHM bridge setup is required
>> to enable memory protection for both remoteproc metadata and its memory
>> regions.
>>
>> When the hypervisor is absent, the operating system must perform these
>> configurations instead.
>>
>> Support for handling IOMMU and SHM setup in the absence of a hypervisor
>> is now in place. Extend the Iris driver to enable this functionality on
>> platforms where IOMMU is managed by Linux (i.e., non-Gunyah, non-QHEE).
>>
>> Additionally, the Iris driver must map the firmware and its required
>> resources to the firmware SID, which is now specified via iommu-map in
>> the device tree.
>>
>> Co-developed-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
> [...]
>
>> static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> {
>> + struct device *dev = core->dev_fw ? core->dev_fw : core->dev;
> Maybe:
>
> struct device *fw_dev = core->dev_fw ?: core->dev;
>
> and preserve *dev to be the main Iris device?
That's better, ack.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: iio: dac: mcp47feb02: Fix maxItems value for reg property
From: David Lechner @ 2026-04-17 15:26 UTC (permalink / raw)
To: Ariana Lazar, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Conor Dooley, Jonathan Cameron, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260417-mcp47feb02-fix5-v2-1-6592ea499cce@microchip.com>
On 4/17/26 8:38 AM, Ariana Lazar wrote:
> Change maxItems value from 8 to 1 for the channel number reg property.
The commit message needs to explain why this is the correct thing to do.
>
> Fixes: 4ba12d304175 ("dt-bindings: iio: dac: adding support for Microchip MCP47FEB02")
> Link: https://lore.kernel.org/all/20260403-speed-childless-1360de358229@spud/
> Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
> ---
> Changes in v2:
> - keep just maxItems value update in this patch
> - remove Reported-by from commit message
> - Link to v1: https://lore.kernel.org/r/20260416-mcp47feb02-fix5-v1-1-9656c2fed6d2@microchip.com
> ---
> Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> index d2466aa6bda2106a8b695347a0edf38462294d03..f2efa0ccbaa32482dcdc69d98c1565518538793f 100644
> --- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> @@ -161,8 +161,7 @@ patternProperties:
> properties:
> reg:
> description: The channel number.
> - minItems: 1
> - maxItems: 8
> + maxItems: 1
>
> label:
> description: Unique name to identify which channel this is.
>
> ---
> base-commit: d2a4ec19d2a2e54c23b5180e939994d3da4a6b91
> change-id: 20260416-mcp47feb02-fix5-26994c5b428c
>
> Best regards,
^ permalink raw reply
* Re: [PATCH 02/16] dt-bindings: interrupt-controller: Describe EIP-201 AIC
From: Aleksander Jan Bajkowski @ 2026-04-17 15:22 UTC (permalink / raw)
To: Miquel Raynal
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc
In-Reply-To: <87tstac9fn.fsf@bootlin.com>
Hi Miquel,
On 17/04/2026 09:50, Miquel Raynal wrote:
> Hi Aleksander,
>
> On 16/04/2026 at 20:04:03 +02, Aleksander Jan Bajkowski <olek2@wp.pl> wrote:
>
>> Hi Miquel,
>>
>> On 27/03/2026 21:09, Miquel Raynal (Schneider Electric) wrote:
>>> diff --git
>>> a/include/dt-bindings/interrupt-controller/inside-secure,safexcel-eip201.h
>>> b/include/dt-bindings/interrupt-controller/inside-secure,safexcel-eip201.h
>>> new file mode 100644
>>> index 000000000000..ead73bd96296
>>> --- /dev/null
>>> +++ b/include/dt-bindings/interrupt-controller/inside-secure,safexcel-eip201.h
>>> @@ -0,0 +1,14 @@
>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
>>> +
>>> +#ifndef _DT_BINDINGS_IRQ_SAFEXCEL_EIP201_AIC_H
>>> +#define _DT_BINDINGS_IRQ_SAFEXCEL_EIP201_AIC_H
>>> +
>>> +#define AIC_PKA_INT0 0
>>> +#define AIC_PKA_INT1 1
>>> +#define AIC_PKA_INT2 2
>>> +#define AIC_TRNG_INT 3
>>> +#define AIC_RESERVED 4
>>> +#define AIC_SL_ERR_INT 5
>>> +#define AIC_PROTECTION_INT 6
>>> +
>>> +#endif
>> This interrupt mapping is specific to the EIP-150. The EIP-201 is also
>> integrated
>> into other accelerators, such as the EIP-97, EIP-196, and EIP-197, and the
>> interrupt mapping is likely different there. Maybe it would be better to use
>> eip150 name instead of eip201?
> Thanks a lot for the heads up, I didn't had that information, I will
> adapt the naming to make it more accurate future proof.
>
>> As for EIP-28, it is also part of EIP-94. EIP-94 is supported by the
>> amcc driver.
>> EIP-94 consists of four components:
>> * crypto accelerator (unnamed?),
>> * PRNG (EIP-73d),
>> * TRNG (unnamed?),
>> * PKA (EIP-28).
>> Only the first three components are supported by the amcc driver.
> Is this driver upstream? I didn't find it. Anyhow, thanks for the
> feedback, I will update with this knowledge in mind.
You can find the driver in the drivers/crypto/amcc directory. It contains
no references to EIP-94. It’s likely that when it was added, it wasn’t
clear that it was a generic IP core.
A while ago, I was looking for information about the PRNGs built into
Rambus crypto accelerators. I found out that all these accelerators are
made up of blocks and have some common components.
EIP-93:
* PE (various IP cores),
* PRNG (EIP-73a),
* Interrupt controller (unnamed?)
EIP-94:
* PE (various IP cores),
* PRNG (EIP-73d),
* TRNG (unnamed?),
* PKA (EIP-28),
* Interrupt Controller (unnamed?).
EIP-97:
* PE (EIP-96)
* AIC (EIP-201),
* PRNG (EIP-73d),
* HIA (EIP-202),
* PP (EIP-206).
EIP-196:
* PE (EIP-96)
* AIC (EIP-201),
* PRNG (EIP-73d),
* HIA (EIP-202),
* PP (EIP-206).
EIP-197:
* PE (EIP-96)
* AIC (EIP-201),
* PRNG (EIP-74),
* HIA (EIP-202),
* PP (EIP-206),
* ICE/OCE (EIP-207),
* Buffers (EIP-208).
You can find some documentation online:
* EIP-93:
https://www.analog.com/media/en/dsp-documentation/processor-manuals/BF70x_BlackfinProcessorHardwareReference.pdf
* EIP-94:
https://www.scribd.com/document/734250956/Safexcel-Ip-94-Plb-Sas-v1-5
* EIP-96:
https://www.scribd.com/document/665924605/Security-IP-96-HW4-6-Hardware-Reference-and-Programmer-Manual-RevB
* EIP-197:
https://www.scribd.com/document/665924595/Security-IP-197-HW3-4-Hardware-Reference-Manual-RevA
Best regards,
Aleksander
^ permalink raw reply
* Re: [PATCH 05/11] media: iris: Enable Secure PAS support with IOMMU managed by Linux
From: Vishnu Reddy @ 2026-04-17 15:20 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <20260414063128.6ass64wfi7nmtzti@hu-mojha-hyd.qualcomm.com>
On 4/14/2026 12:01 PM, Mukesh Ojha wrote:
> On Tue, Apr 14, 2026 at 10:30:01AM +0530, Vishnu Reddy wrote:
>> From: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
>>
>> Most Qualcomm platforms feature a proprietary hypervisor (such as Gunyah
>> or QHEE), which typically handles IOMMU configuration. This includes
>> mapping memory regions and device memory resources for remote processors
>> by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are
>> later removed during teardown. Additionally, SHM bridge setup is required
>> to enable memory protection for both remoteproc metadata and its memory
>> regions.
>>
>> When the hypervisor is absent, the operating system must perform these
>> configurations instead.
>>
>> Support for handling IOMMU and SHM setup in the absence of a hypervisor
>> is now in place. Extend the Iris driver to enable this functionality on
>> platforms where IOMMU is managed by Linux (i.e., non-Gunyah, non-QHEE).
>>
>> Additionally, the Iris driver must map the firmware and its required
>> resources to the firmware SID, which is now specified via iommu-map in
>> the device tree.
>>
>> Co-developed-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/iris_core.h | 4 ++
>> drivers/media/platform/qcom/iris/iris_firmware.c | 71 +++++++++++++++++++++---
>> 2 files changed, 66 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_core.h b/drivers/media/platform/qcom/iris/iris_core.h
>> index fb194c967ad4..aa7abef6f0e0 100644
>> --- a/drivers/media/platform/qcom/iris/iris_core.h
>> +++ b/drivers/media/platform/qcom/iris/iris_core.h
>> @@ -34,6 +34,8 @@ enum domain_type {
>> * struct iris_core - holds core parameters valid for all instances
>> *
>> * @dev: reference to device structure
>> + * @dev_fw: reference to the context bank device used for firmware load
>> + * @ctx_fw: SCM PAS context for authenticated firmware load and shutdown
>> * @reg_base: IO memory base address
>> * @irq: iris irq
>> * @v4l2_dev: a holder for v4l2 device structure
>> @@ -77,6 +79,8 @@ enum domain_type {
>>
>> struct iris_core {
>> struct device *dev;
>> + struct device *dev_fw;
>> + struct qcom_scm_pas_context *ctx_fw;
> fw_dev suits better and ctx_fw is always for firmware, maybe pas_ctx is
> better.
Ack
>> void __iomem *reg_base;
>> int irq;
>> struct v4l2_device v4l2_dev;
>> diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
>> index 5f408024e967..93d77996c83f 100644
>> --- a/drivers/media/platform/qcom/iris/iris_firmware.c
>> +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
>> @@ -5,6 +5,7 @@
>>
>> #include <linux/firmware.h>
>> #include <linux/firmware/qcom/qcom_scm.h>
>> +#include <linux/iommu.h>
>> #include <linux/of_address.h>
>> #include <linux/of_reserved_mem.h>
>> #include <linux/soc/qcom/mdt_loader.h>
>> @@ -13,12 +14,15 @@
>> #include "iris_firmware.h"
>>
>> #define MAX_FIRMWARE_NAME_SIZE 128
>> +#define IRIS_FW_START_ADDR 0
>>
>> static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> {
>> + struct device *dev = core->dev_fw ? core->dev_fw : core->dev;
>> u32 pas_id = core->iris_platform_data->pas_id;
>> const struct firmware *firmware = NULL;
>> - struct device *dev = core->dev;
>> + struct qcom_scm_pas_context *ctx_fw;
>> + struct iommu_domain *domain;
>> struct resource res;
>> phys_addr_t mem_phys;
>> size_t res_size;
>> @@ -29,13 +33,17 @@ static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> if (strlen(fw_name) >= MAX_FIRMWARE_NAME_SIZE - 4)
>> return -EINVAL;
>>
>> - ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
>> + ret = of_reserved_mem_region_to_resource(core->dev->of_node, 0, &res);
>> if (ret)
>> return ret;
>>
>> mem_phys = res.start;
>> res_size = resource_size(&res);
>>
>> + ctx_fw = devm_qcom_scm_pas_context_alloc(dev, pas_id, mem_phys, res_size);
>> + if (IS_ERR(ctx_fw))
>> + return PTR_ERR(ctx_fw);
>> +
>> ret = request_firmware(&firmware, fw_name, dev);
>> if (ret)
>> return ret;
>> @@ -52,9 +60,27 @@ static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> goto err_release_fw;
>> }
>>
>> - ret = qcom_mdt_load(dev, firmware, fw_name,
>> - pas_id, mem_virt, mem_phys, res_size, NULL);
>> + ctx_fw->use_tzmem = !!core->dev_fw;
>> + ret = qcom_mdt_pas_load(ctx_fw, firmware, fw_name, mem_virt, NULL);
>> + if (ret)
>> + goto err_mem_unmap;
>> +
>> + if (ctx_fw->use_tzmem) {
>> + domain = iommu_get_domain_for_dev(core->dev_fw);
>> + if (!domain) {
>> + ret = -ENODEV;
>> + goto err_mem_unmap;
>> + }
>> +
>> + ret = iommu_map(domain, IRIS_FW_START_ADDR, mem_phys, res_size,
>> + IOMMU_READ | IOMMU_WRITE | IOMMU_PRIV, GFP_KERNEL);
>> + if (ret)
>> + goto err_mem_unmap;
>> + }
>>
>> + core->ctx_fw = ctx_fw;
>> +
>> +err_mem_unmap:
>> memunmap(mem_virt);
>> err_release_fw:
>> release_firmware(firmware);
>> @@ -62,6 +88,19 @@ static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> return ret;
>> }
>>
>> +static void iris_fw_iommu_unmap(struct iris_core *core)
>> +{
>> + bool use_tzmem = core->ctx_fw->use_tzmem;
>> + struct iommu_domain *domain;
>> +
>> + if (!use_tzmem)
>> + return;
>> +
>> + domain = iommu_get_domain_for_dev(core->dev_fw);
>> + if (domain)
>> + iommu_unmap(domain, IRIS_FW_START_ADDR, core->ctx_fw->mem_size);
>> +}
>> +
>> int iris_fw_load(struct iris_core *core)
>> {
>> const struct tz_cp_config *cp_config;
>> @@ -79,10 +118,10 @@ int iris_fw_load(struct iris_core *core)
>> return -ENOMEM;
>> }
>>
>> - ret = qcom_scm_pas_auth_and_reset(core->iris_platform_data->pas_id);
>> + ret = qcom_scm_pas_prepare_and_auth_reset(core->ctx_fw);
>> if (ret) {
>> dev_err(core->dev, "auth and reset failed: %d\n", ret);
>> - return ret;
>> + goto err_unmap;
>> }
>>
>> for (i = 0; i < core->iris_platform_data->tz_cp_config_data_size; i++) {
>> @@ -93,17 +132,31 @@ int iris_fw_load(struct iris_core *core)
>> cp_config->cp_nonpixel_size);
>> if (ret) {
>> dev_err(core->dev, "qcom_scm_mem_protect_video_var failed: %d\n", ret);
>> - qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
>> - return ret;
>> + goto err_pas_shutdown;
>> }
>> }
>>
>> + return 0;
>> +
>> +err_pas_shutdown:
>> + qcom_scm_pas_shutdown(core->ctx_fw->pas_id);
>> +err_unmap:
>> + iris_fw_iommu_unmap(core);
>> +
>> return ret;
>> }
>>
>> int iris_fw_unload(struct iris_core *core)
>> {
>> - return qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
>> + int ret;
>> +
>> + ret = qcom_scm_pas_shutdown(core->ctx_fw->pas_id);
>> + if (ret)
>> + return ret;
>> +
>> + iris_fw_iommu_unmap(core);
>> +
>> + return ret;
>> }
>>
>> int iris_set_hw_state(struct iris_core *core, bool resume)
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* [PATCH] arm64: dts: qcom: monaco-evk: Enable primary USB controller in host mode
From: Swati Agarwal @ 2026-04-17 15:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Swati Agarwal
Enable primary USB controller in host mode on monaco EVK Platform.
Primary USB controller is connected to a Genesys Logic USB HUB GL3590
having 4 ports. The ports of hub that are present on lemans EVK standalone
board are used as follows:-
1) port-1 is connected to HD3SS3220 Type-C port controller.
2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART
for Bluetooth. This port is to be used only if user optionally replaces the
WiFi card with the NFA765 chip which uses USB for Bluetooth.
Remaining 2 ports will become functional when the interface plus mezzanine
board is stacked on top of corekit:
3) port-2 is connected to another hub which is present on the mezz through
which 4 type-A ports are connected.
4) port-3 is used for the M.2 B key for a 5G card when the mezz is
connected.
Primary USB Controller
↓
GL3590 USB Hub (4 ports)
|
|-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
|
|-- Port 2 → Mezzanine USB Hub (when mezz attached)
|
|-- Port 3 → M.2 B‑Key Slot (when mezz attached)
|
|-- Port 4 → M.2 E‑Key Slot
(Default: BT via UART;
USB only if NFA765 module is installed)
Mark the primary USB controller as host only capable and add the HD3SS3220
Type-C port controller along with Type-c connector for controlling vbus
supply.
In hardware, there are dip switches provided to operate between USB1 port 0
and port 1 for primary Type-C USB controller. By default, switches will be
off operating at USB0 port. After bootup to HLOS, it will be operated in
USB1 port. Added support in the software for both HS and SS switches as
usb1_hs_sel_switch and usb1_ss_sel_switch to avoid manually changing the
dip switch position for USB1 port to function. Also, added usb1_hub_reset
pin for USB1 hub to get detected after bootup as USB1 hub will be in
inactive state before bootup.
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
---
.../boot/dts/qcom/monaco-evk-common.dtsi | 173 +++++++++++++++++-
1 file changed, 172 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi b/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
index 12c847c03757..6316a8270f57 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
@@ -23,6 +23,37 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ connector-1 {
+ compatible = "usb-c-connector";
+ label = "USB1-Type-C";
+ data-role = "host";
+ power-role = "source";
+
+ vbus-supply = <&usb1_vbus>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb1_con_hs_ep: endpoint {
+ remote-endpoint = <&usb_hub_2_1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb1_con_ss_ep: endpoint {
+ remote-endpoint = <&hd3ss3220_1_in_ep>;
+ };
+
+ };
+ };
+ };
+
connector-2 {
compatible = "gpio-usb-b-connector", "usb-b-connector";
label = "micro-USB";
@@ -77,6 +108,15 @@ dp1_connector_in: endpoint {
};
};
+ usb1_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb1_vbus";
+ gpio = <&expander1 3 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ };
+
usb2_vbus: regulator-usb2-vbus {
compatible = "regulator-fixed";
regulator-name = "usb2_vbus";
@@ -445,6 +485,39 @@ lt8713sx_dp1_out: endpoint {
};
};
};
+
+ usb-typec@47 {
+ compatible = "ti,hd3ss3220";
+ reg = <0x47>;
+
+ interrupts-extended = <&tlmm 45 IRQ_TYPE_EDGE_FALLING>;
+
+ id-gpios = <&tlmm 13 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&usb1_id>, <&usb1_intr>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hd3ss3220_1_in_ep: endpoint {
+ remote-endpoint = <&usb1_con_ss_ep>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ hd3ss3220_1_out_ep: endpoint {
+ remote-endpoint = <&usb_hub_3_1>;
+ };
+ };
+ };
+ };
};
&i2c1 {
@@ -556,6 +629,13 @@ expander5: gpio@3d {
interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
pinctrl-0 = <&expander5_int>;
pinctrl-names = "default";
+
+ gpio5-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "usb1_ss_sel_switch";
+ };
};
expander6: gpio@3e {
@@ -742,6 +822,28 @@ expander5_int: expander5-int-state {
bias-pull-up;
};
+ usb1_hub_reset: usb1-hub-reset-state {
+ pins = "gpio7";
+ function = "gpio";
+ output-enable;
+ output-high;
+ bias-disable;
+ };
+
+ usb1_id: usb1-id-state {
+ pins = "gpio13";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ usb1_hs_sel_switch: usb1-hs-sel-switch-state {
+ pins = "gpio14";
+ function = "gpio";
+ output-enable;
+ output-high;
+ bias-disable;
+ };
+
expander1_int: expander1-int-state {
pins = "gpio16";
function = "gpio";
@@ -784,6 +886,12 @@ expander3_int: expander3-int-state {
bias-pull-up;
};
+ usb1_intr: usb1-intr-state {
+ pins = "gpio45";
+ function = "gpio";
+ bias-pull-up;
+ };
+
expander6_int: expander6-int-state {
pins = "gpio52";
function = "gpio";
@@ -863,9 +971,72 @@ &ufs_mem_phy {
};
&usb_1 {
- dr_mode = "peripheral";
+ dr_mode = "host";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_hub_reset &usb1_hs_sel_switch>;
status = "okay";
+
+ usb_hub_2_x: hub@1 {
+ compatible = "usb5e3,610";
+ reg = <1>;
+
+ peer-hub = <&usb_hub_3_x>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb_hub_2_1: endpoint {
+ remote-endpoint = <&usb1_con_hs_ep>;
+ };
+ };
+
+ /*
+ * Port-4 is connected to M.2 E key connector on corekit.
+ */
+ port@4 {
+ reg = <4>;
+
+ usb_hub_2_4: endpoint {
+ };
+ };
+ };
+ };
+
+ usb_hub_3_x: hub@2 {
+ compatible = "usb5e3,625";
+ reg = <2>;
+
+ peer-hub = <&usb_hub_2_x>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb_hub_3_1: endpoint {
+ remote-endpoint = <&hd3ss3220_1_out_ep>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ usb_hub_3_4: endpoint {
+ };
+ };
+ };
+ };
};
&usb_1_hsphy {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 04/11] media: iris: Add helper to create a context bank device on iris vpu bus
From: Vishnu Reddy @ 2026-04-17 15:19 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <ie6dad3xewm25gdrqqne2fsroopu3jwgrqmu54sfzjliis6mo5@6qsgagvyynwx>
On 4/14/2026 8:48 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:30:00AM +0530, Vishnu Reddy wrote:
>> From: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>
>> Add a helper function to allocate and register context bank (CB) device
>> on the iris vpu bus. The function ID associated with the CB is specified
>> from the platform data, allowing the bus dma_configure callback to apply
>> correct stream ID mapping when device is registered.
>>
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/iris_resources.c | 33 +++++++++++++++++++++++
>> drivers/media/platform/qcom/iris/iris_resources.h | 1 +
>> 2 files changed, 34 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
>> index 773f6548370a..a25e0f2e9d26 100644
>> --- a/drivers/media/platform/qcom/iris/iris_resources.c
>> +++ b/drivers/media/platform/qcom/iris/iris_resources.c
>> @@ -6,6 +6,7 @@
>> #include <linux/clk.h>
>> #include <linux/devfreq.h>
>> #include <linux/interconnect.h>
>> +#include <linux/iris_vpu_bus.h>
>> #include <linux/pm_domain.h>
>> #include <linux/pm_opp.h>
>> #include <linux/pm_runtime.h>
>> @@ -141,3 +142,35 @@ int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type
>>
>> return 0;
>> }
>> +
>> +static void iris_release_cb_dev(struct device *dev)
>> +{
>> + kfree(dev);
>> +}
>> +
>> +struct device *iris_create_cb_dev(struct iris_core *core, const char *name, const u32 *f_id)
> Please move into the bus code and make it generic enough.
Do you suggest to add a wrapper to pass the varying inputs to the
generic bus, something like this
struct device* create_and_register_device(dma_mask, parent_dev,
*release, dev_name,...)
>> +{
>> + struct device *dev;
>> + int ret;
>> +
>> + dev = kzalloc_obj(*dev);
>> + if (!dev)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + dev->release = iris_release_cb_dev;
>> + dev->bus = &iris_vpu_bus_type;
>> + dev->parent = core->dev;
>> + dev->coherent_dma_mask = core->iris_platform_data->dma_mask;
>> + dev->dma_mask = &dev->coherent_dma_mask;
> Would you also need to set the of_node? See
> device_set_of_node_from_dev()
It might be needed for FastRPC as they are following sub node approach,
Iris does not need.
>> +
>> + dev_set_name(dev, "%s", name);
>> + dev_set_drvdata(dev, (void *)f_id);
>> +
>> + ret = device_register(dev);
>> + if (ret) {
>> + put_device(dev);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + return dev;
>> +}
>> diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
>> index 6bfbd2dc6db0..4a494627ff23 100644
>> --- a/drivers/media/platform/qcom/iris/iris_resources.h
>> +++ b/drivers/media/platform/qcom/iris/iris_resources.h
>> @@ -15,5 +15,6 @@ int iris_unset_icc_bw(struct iris_core *core);
>> int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw);
>> int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type clk_type);
>> int iris_prepare_enable_clock(struct iris_core *core, enum platform_clk_type clk_type);
>> +struct device *iris_create_cb_dev(struct iris_core *core, const char *name, const u32 *f_id);
>>
>> #endif
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly
From: Ekansh Gupta @ 2026-04-17 15:15 UTC (permalink / raw)
To: Konrad Dybcio, Nickolay Goppen, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <70d4dbe7-0e5b-4065-858e-b5a57bbf45e3@oss.qualcomm.com>
On 15-04-2026 15:22, Konrad Dybcio wrote:
> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>> Downstream [1] this region is marked as shared and reusable so
>> describe it that way.
>>
>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>
>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>> ---
>
> +Ekansh some insight, please?
>
> We're giving away that memory via qcom_scm_assign_mem() anyway
> and I would assume that making it not-"no-map" could introduce issues
> when the OS tries to access that region
>
With the current version and the upcoming planned enhancements, I don't
see any major benefits of making this as not-"no-map".
With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
entire memory-region to lpass VMIDs. and un-assign it only during
fastrpc_rpmsg_remove(). There have been implementation in downstream
where this memory is dumped in case of SSR or audio PDR using minidump,
so marking it `reusable` might make sense there, but that dump logic is
not added upstream.
Upon checking the DT, I see a bigger problem here, this memory-region
looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
Please correct me if I am wrong about this point.
[1]
https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
//Ekansh
> Konrad
>
>
>> arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> index 4b47efdb57b2..13094b5e9339 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>> };
>>
>> adsp_mem: adsp-region@f6000000 {
>> + compatible = "shared-dma-pool";
>> reg = <0x0 0xf6000000 0x0 0x800000>;
>> - no-map;
>> + reusable;
>> };
>>
>> qseecom_mem: qseecom-region@f6800000 {
>>
^ permalink raw reply
* Re: Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Conor Dooley @ 2026-04-17 15:13 UTC (permalink / raw)
To: Xuyang Dong
Cc: Krzysztof Kozlowski, ukleinek, robh, krzk+dt, conor+dt, ben-linux,
ben.dooks, p.zabel, linux-pwm, devicetree, linux-kernel, ningyu,
linmin, xuxiang, wangguosheng, pinkesh.vaghela
In-Reply-To: <3b2e80d5.55a5.19d996c6821.Coremail.dongxuyang@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
On Fri, Apr 17, 2026 at 11:11:51AM +0800, Xuyang Dong wrote:
> > > > > >
> > > > > > The DesignWare PWM includes separate reset signals dedicated to each clock
> > > > > > domain:
> > > > > > The presetn signal resets logic in pclk domain.
> > > > > > The timer_N_resetn signal resets logic in the timer_N_clk domain.
> > > > > > The resets are active-low.
> > > > > >
> > > > > > Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> > > > >
> > > > > This commit implies that your hardware differs from existing devices,
> > > > > I think you should add a device-specific compatible.
> > > > >
> > >
> > > Hi Conor and Krzysztof,
> > >
> > > The DesignWare PWM Databook for 2.13a says: "The DW_apb_timers includes
> > > separate reset signals dedicated to each clock domain". They are:
> > > The presetn signal resets logic in pclk domain (i.e., the bus clock in DT).
> > > The timer_N_resetn signal resets logic in the timer_N_clk domain (i.e.,
> > > the timer clock in DT).
> > >
> > > These reset signals are optional; it is up to the designer's
> > > implementation.
> >
> > Right, and it's that "designer's implementation" that warrants a
> > device-specific compatible.
> >
>
> Hi Conor,
>
> The YAML update for the new device-specific compatible is as follows:
>
> properties:
> compatible:
> oneOf:
> - const: snps,dw-apb-timers-pwm2
> - items:
> - enum:
> - snps,dw-apb-timers-pwm-2.13a
This is not a device-specific compatible.
Hint: device-specific means it needs to start with "eswin,eic7700" (and
probably end with "-pwm".
> - const: snps,dw-apb-timers-pwm2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH RFC 4/4] clk: rockchip: rk3576: add ROUND_CLOSEST to dclk_vp1_src divider
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
Without CLK_DIVIDER_ROUND_CLOSEST, the divider's _is_best_div() only
considers candidates where now <= target, rejecting any rate above the
target even when it is closer. Combined with the PLL round-nearest fix,
this causes the divider to still pick a suboptimal rate: with PLL
round-nearest alone, div=8 produces 249.0 MHz (0.048% over) but is
rejected because it exceeds the target, and div=3/248.0 MHz wins
(-0.354% error).
Add CLK_DIVIDER_ROUND_CLOSEST to dclk_vp1_src's div_flags so the
divider picks the rate closest to the target regardless of direction.
Together with the PLL round-nearest change, this yields:
VPLL 1992 MHz / 8 = 249.0 MHz (+0.048% error)
instead of the previous:
VPLL 1488 MHz / 6 = 248.0 MHz (-0.354% error)
This small difference appears to enable more monitors to lock to the VP1
clock when driving output at 2560x1440@60Hz via DisplayPort.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-rk3576.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3576.c b/drivers/clk/rockchip/clk-rk3576.c
index 28eb5a802e83..9fc3264ef322 100644
--- a/drivers/clk/rockchip/clk-rk3576.c
+++ b/drivers/clk/rockchip/clk-rk3576.c
@@ -1106,7 +1106,7 @@ static struct rockchip_clk_branch rk3576_clk_branches[] __initdata = {
RK3576_CLKSEL_CON(145), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 10, GFLAGS),
COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
- RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS,
+ RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS | CLK_DIVIDER_ROUND_CLOSEST,
RK3576_CLKGATE_CON(61), 11, GFLAGS),
COMPOSITE(DCLK_VP2_SRC, "dclk_vp2_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
RK3576_CLKSEL_CON(147), 8, 3, MFLAGS, 0, 8, DFLAGS,
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 3/4] clk: rockchip: rk3576: allow dclk_vp1_src to propagate rate to parent PLL
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
dclk_vp1_src feeds the display clock for Video Port 1. When parented to
the default GPLL (1188 MHz), the 8-bit divider cannot synthesize the
248.88 MHz pixel clock required for 2560x1440@60 which VP1 supports:
1188 / 5 = 237.6 MHz (-4.53% error). This exceeds DisplayPort's +/-0.5%
tolerance and causes black screens on strict sinks.
Add CLK_SET_RATE_PARENT so that when dclk_vp1_src is reparented to a
programmable PLL (e.g. VPLL via assigned-clock-parents), the CCF divider
can ask the PLL to retune. For example, VPLL at 1992 MHz / 8 = 249 MHz
(0.048% error).
This flag relies on reparenting the VP1 source clock to VPLL at DT level
to ensure no consumer calls clk_set_rate on dclk_vp1 while its parent is
set to the boot-time default of GPLL.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-rk3576.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3576.c b/drivers/clk/rockchip/clk-rk3576.c
index 2557358e0b9d..28eb5a802e83 100644
--- a/drivers/clk/rockchip/clk-rk3576.c
+++ b/drivers/clk/rockchip/clk-rk3576.c
@@ -1105,7 +1105,7 @@ static struct rockchip_clk_branch rk3576_clk_branches[] __initdata = {
COMPOSITE(DCLK_VP0_SRC, "dclk_vp0_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
RK3576_CLKSEL_CON(145), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 10, GFLAGS),
- COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
+ COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 11, GFLAGS),
COMPOSITE(DCLK_VP2_SRC, "dclk_vp2_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 2/4] clk: rockchip: pll: use round-nearest in determine_rate
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
rockchip_pll_determine_rate() walks the rate table in descending order
and picks the first entry <= the requested rate. This floor-rounding
interacts poorly with consumers that use CLK_SET_RATE_PARENT: a divider
iterating candidates asks the PLL for rate*div, and a tiny undershoot
causes the PLL to snap to a much lower entry.
For example, requesting 1991.04 MHz (248.88 MHz * 8) causes the PLL to
return 1968 MHz instead of 1992 MHz — a 24 MHz table gap that produces
a 1.2% pixel clock error when divided back down.
Change to round-to-nearest: for each table entry compute the absolute
distance from the request, and pick the entry with the smallest delta.
The CCF's divider and composite logic handle over/undershoot preferences
via their own ROUND_CLOSEST flags.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-pll.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6b853800cb6b..c142f2c4fd99 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -66,19 +66,19 @@ static int rockchip_pll_determine_rate(struct clk_hw *hw,
{
struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
const struct rockchip_pll_rate_table *rate_table = pll->rate_table;
+ unsigned long best = 0;
int i;
- /* Assuming rate_table is in descending order */
for (i = 0; i < pll->rate_count; i++) {
- if (req->rate >= rate_table[i].rate) {
- req->rate = rate_table[i].rate;
-
- return 0;
- }
+ if (abs((long)req->rate - (long)rate_table[i].rate) <
+ abs((long)req->rate - (long)best))
+ best = rate_table[i].rate;
}
- /* return minimum supported value */
- req->rate = rate_table[i - 1].rate;
+ if (best)
+ req->rate = best;
+ else
+ req->rate = rate_table[pll->rate_count - 1].rate;
return 0;
}
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 1/4] arm64: dts: rockchip: rk3576: assign dclk_vp1_src to VPLL
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
Reparent dclk_vp1_src from GPLL to VPLL at the SoC level. VPLL is a
programmable PLL with no other consumers, allowing the CRU to synthesize
accurate pixel clocks for VP1's output with arbitrary display modes.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
index e12a2a0cfb89..2b05900c6c1c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
@@ -1338,6 +1338,8 @@ vop: vop@27d00000 {
"dclk_vp1",
"dclk_vp2",
"pll_hdmiphy0";
+ assigned-clocks = <&cru DCLK_VP1_SRC>;
+ assigned-clock-parents = <&cru PLL_VPLL>;
iommus = <&vop_mmu>;
power-domains = <&power RK3576_PD_VOP>;
rockchip,grf = <&sys_grf>;
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 0/4] arm64: rockchip: The hunt for exact pixel clocks on RK3576
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
Dear all,
Need the help of the collective wisdom of the community.
The problem I'm trying to solve is reliably obtaining the exact pixel
clock for arbitrary display modes supported by the RK3576 SoC.
Rockchip RK3576 has three display output processors VP0~VP2, each
supporting different ranges of display modes, roughly as follows:
- VP0: 4K 120Hz
- VP1: 2.5k 60Hz
- VP2: 1080p 60Hz
Each one obviously needs a pixel clock. The required frequencies for the
pixel clocks vary greatly depending on the display mode, and need to be
matched within a tight tolerance, or else many displays will refuse to
work. E.g. the preferred (maximum) display mode out of VP1 is particularly
awkward, because it requires a pixel clock of 248.88 MHz, which cannot
be obtained using integer dividers from its default clock source (GPLL
at 1188 MHz), and the nearest approximation is 237.6 MHz, which is well
outside the tolerance of e.g. DP specification, resulting in a blank
screen on most displays by default.
The clock sources are of course configurable, in particular there are muxes
connected to each VP for selecting the source of the pixel clock:
- Each VP can take the clock either from the (single!) HDMI PHY or from
its dedicated dclk_vpX_src mux
- The dclk_vpX_src mux can select the clock from a number of system PLLs
(GPLL, CPLL, VPLL, BPLL, LPLL)
While the system PLLs can be configured to output a wide range of
frequencies, they are shared between many system components. E.g. on the
current mainline kernel on one of my RK3576 boards I've got the following:
GPLL: 1188 MHz, enable count 20
CPLL: 1000 MHz, enable count 17
VPLL: 594 MHz, enable count 0 (yaay!)
BPLL, LPLL: 816 MHz, enable count 0 (but these last ones don't have
predividers, so are less flexible)
So ultimately there is exactly one free fractional PLL (VPLL) which can be
used to generate arbitrary pixel clocks, but we have up to three consumers
trying to drive different display modes from it (e.g. HDMI on VP0, DP on
VP1 and MIPI DSI on VP2). We also want to be able to adjust the PLL output
frequency on the fly to satisfy the requirements of the selected display
mode.
And this is where I'm stuck. Trying to satisfy the requirements of up to
three consumers while changing the PLL frequency on the fly sounds like
a poorly tractable mathematical problem (is it 3-SAT?). We can take the
HDMI output out of the equation, because it can be driven from the HDMI
PHY (which is capable of arbitrary rates) instead of the mux, but that
makes the decision of which dclk source to use for a VP block dependent on
which downstream consumer is connected to it (HDMI vs. something else).
Even then we somehow need two devices to cooperate in picking a PLL
frequency that satisfies the requirements of both of them, and change to it
without display corruption. I'm not even sure if the CCF has mechanisms
for that?..
What follows is a brief set of patches which illustrate a partial solution
for the case of "I just need 2.5k60Hz on VP1 via DP and don't care about
the rest". It switches the VP1 unconditionally to use VPLL as the source
for its dclk mux, allows changing the VPLL frequency on the fly, and also
changes the frequency calculation logic to allow for nearest-match
frequencies which are not necessarily rounded down. These are not meant
to be merged as-is, as I see the following issues:
- The flag allowing the PLL to change rate is in the clock driver, while
the reparenting to an unused PLL is in the device tree. If these go out
of sync, we might end up trying to change the frequency of a PLL which
is used by other consumers (I presume that could be dangerous)
- If VP0 happens to be driving DP output, it won't be able to produce the
2560x1440@60Hz mode for the same reasons as VP1 - then it must also be
reparented to VPLL and allowed to change its frequency on the fly
It does bring me from a state of "always blank screen on DP output until
the mode is switched to something magically working" to a state of
"most monitors work at the default preferred mode" though.
It is tempting to just reparent both VP0 and VP1 to VPLL and allow both of
them to change its frequency, while leaving VP2 on the default (fixed)
GPLL and relying on the fact that 148.5 MHz (the required frequency for
its maximum supported mode of 1920x1080@60Hz) is conveniently 1188/8 MHz -
just what GPLL can provide. Then also force whichever VP is driving HDMI
output to use the HDMI PHY as its clock source. But we still have the
problem of DT vs. driver coordination, and I'm not sure how to define
the policy for "if you've got HDMI connected, you must use the HDMI PHY
clock for the respective VP, whichever VP that is".
I would very much appreciate any thoughts on how to approach this.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Alexey Charkov (4):
arm64: dts: rockchip: rk3576: assign dclk_vp1_src to VPLL
clk: rockchip: pll: use round-nearest in determine_rate
clk: rockchip: rk3576: allow dclk_vp1_src to propagate rate to parent PLL
clk: rockchip: rk3576: add ROUND_CLOSEST to dclk_vp1_src divider
arch/arm64/boot/dts/rockchip/rk3576.dtsi | 2 ++
drivers/clk/rockchip/clk-pll.c | 16 ++++++++--------
drivers/clk/rockchip/clk-rk3576.c | 4 ++--
3 files changed, 12 insertions(+), 10 deletions(-)
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20260417-rk3576-dclk-4c95bbb67581
Best regards,
--
Alexey Charkov <alchark@flipper.net>
^ permalink raw reply
* Re: [PATCH 03/11] media: iris: Add context bank hooks for platform specific initialization
From: Vishnu Reddy @ 2026-04-17 15:03 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <3vuensoscjzsjuh7c5e3jff5cej66iwboiau7vhnpvtmqevexf@ouox5cize3fn>
On 4/14/2026 8:46 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:29:59AM +0530, Vishnu Reddy wrote:
>> Add init and deinit hooks in the platform data for context bank setup.
>> These hooks allow platform specific code to initialize and tear down
>> context banks.
>>
>> The Glymur platform requires a dedicated firmware context bank device
>> which is mapped to the firmware stream ID to load the firmware.
> Change the order of paragraphs. You should start with the definition of
> the problem rather than putting the cart before the horse and starting
> from the solution.
Ack.
Thanks,
Vishnu Reddy.
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> .../platform/qcom/iris/iris_platform_common.h | 2 ++
>> drivers/media/platform/qcom/iris/iris_probe.c | 23 +++++++++++++++++++++-
>> 2 files changed, 24 insertions(+), 1 deletion(-)
>>
^ permalink raw reply
* Re: [PATCH 02/11] media: iris: Add iris vpu bus support and register it with iommu_buses
From: Vishnu Reddy @ 2026-04-17 14:59 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <5dee6da0-9170-d9e0-5ff7-f8436331c6a9@oss.qualcomm.com>
apologies for re-sending (earlier responses was rejected due to HTML format)
On 4/17/2026 8:22 PM, Vishnu Reddy wrote:
> On 4/14/2026 8:44 PM, Dmitry Baryshkov wrote:
>> On Tue, Apr 14, 2026 at 10:29:58AM +0530, Vishnu Reddy wrote:
>>> From: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>>
>>> Add a dedicated iris VPU bus type and register it into the iommu_buses
>>> list. Iris devices require their own bus so that each device can run its
>>> own dma_configure() logic.
>> This really tells nothing, unless one has full context about the Iris
>> needs. Start by describing the issue (that the device needs to have
>> multiple devices talking to describe IOMMUs / VAs for several hardware
>> functions), then continue by describing what is needed from the IOMMU
>> subsys.
>
> This series handles firmware device which do not require multiple
> devices part.
> given this device need for specific IOMMU configuration, I'll update
> the description
> accordingly.
>
>>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>>> ---
>>> drivers/iommu/iommu.c | 4 ++++
>>> drivers/media/platform/qcom/iris/Makefile | 4 ++++
>>> drivers/media/platform/qcom/iris/iris_vpu_bus.c | 32 +++++++++++++++++++++++++
>>> include/linux/iris_vpu_bus.h | 13 ++++++++++
>> How are you supposed to merge this? Through IOMMU tree? Through venus
>> tree? Can we add one single bus to the IOMMU code and use it for Iris,
>> Venus, FastRPC, host1x and all other device drivers which require
>> per-device DMA configuration?
>
> Separating out the bus definition and the Iris driver handling would
> provide a
> cleaner merge path.
>
>> Your colleagues from the FastRPC team posted a very similar code few
>> weeks ago and got exactly the same feedback. Is there a reason why your
>> teams don't sync on the IOMMU parts at all?
>
> I would admit that I missed to review that, thank you for bringing
> that discussion.
> FastRPC patches generalizes the handling for host1x, FastRPC and the
> same can be
> extended for Iris. I have left few comments there.
>
>>> 4 files changed, 53 insertions(+)
>>>
>>> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
>>> index 61c12ba78206..d8ed6ef70ecd 100644
>>> --- a/drivers/iommu/iommu.c
>>> +++ b/drivers/iommu/iommu.c
>>> @@ -13,6 +13,7 @@
>>> #include <linux/bug.h>
>>> #include <linux/types.h>
>>> #include <linux/init.h>
>>> +#include <linux/iris_vpu_bus.h>
>>> #include <linux/export.h>
>>> #include <linux/slab.h>
>>> #include <linux/errno.h>
>>> @@ -179,6 +180,9 @@ static const struct bus_type * const iommu_buses[] = {
>>> #ifdef CONFIG_CDX_BUS
>>> &cdx_bus_type,
>>> #endif
>>> +#if IS_ENABLED(CONFIG_VIDEO_QCOM_IRIS)
>>> + &iris_vpu_bus_type,
>>> +#endif
>>> };
>>>
>>> /*
>>> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
>>> index 2abbd3aeb4af..6f4052b98491 100644
>>> --- a/drivers/media/platform/qcom/iris/Makefile
>>> +++ b/drivers/media/platform/qcom/iris/Makefile
>>> @@ -31,3 +31,7 @@ qcom-iris-objs += iris_platform_gen1.o
>>> endif
>>>
>>> obj-$(CONFIG_VIDEO_QCOM_IRIS) += qcom-iris.o
>>> +
>>> +ifdef CONFIG_VIDEO_QCOM_IRIS
>>> +obj-y += iris_vpu_bus.o
>>> +endif
>>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_bus.c b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
>>> new file mode 100644
>>> index 000000000000..b51bb4b82b0e
>>> --- /dev/null
>>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_bus.c
>>> @@ -0,0 +1,32 @@
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>>> + */
>>> +
>>> +#include <linux/device.h>
>>> +#include <linux/of_device.h>
>>> +
>>> +#include "iris_platform_common.h"
>>> +
>>> +static int iris_vpu_bus_dma_configure(struct device *dev)
>>> +{
>>> + const u32 *f_id = dev_get_drvdata(dev);
>>> +
>>> + if (!f_id)
>>> + return -ENODEV;
>>> +
>>> + return of_dma_configure_id(dev, dev->parent->of_node, true, f_id);
>> I think it was discussed that this is not enough. Some of devices need
>> multiple function IDs.
>
> In this glymur series we are following the legacy way of handling
> IOMMUs and does not
> require multi map.
>
> Thanks,
> Vishnu Reddy.
>
>>> +}
>>> +
>>> +const struct bus_type iris_vpu_bus_type = {
>>> + .name = "iris-vpu-bus",
>>> + .dma_configure = iris_vpu_bus_dma_configure,
>>> +};
>>> +EXPORT_SYMBOL_GPL(iris_vpu_bus_type);
>>> +
>>> +static int __init iris_vpu_bus_init(void)
>>> +{
>>> + return bus_register(&iris_vpu_bus_type);
>>> +}
>>> +
>>> +postcore_initcall(iris_vpu_bus_init);
>>> diff --git a/include/linux/iris_vpu_bus.h b/include/linux/iris_vpu_bus.h
>>> new file mode 100644
>>> index 000000000000..5704b226f7d6
>>> --- /dev/null
>>> +++ b/include/linux/iris_vpu_bus.h
>>> @@ -0,0 +1,13 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>>> + */
>>> +
>>> +#ifndef __IRIS_VPU_BUS_H__
>>> +#define __IRIS_VPU_BUS_H__
>>> +
>>> +#if IS_ENABLED(CONFIG_VIDEO_QCOM_IRIS)
>>> +extern const struct bus_type iris_vpu_bus_type;
>>> +#endif
>>> +
>>> +#endif /* __IRIS_VPU_BUS_H__ */
>>>
>>> --
>>> 2.34.1
>>>
^ permalink raw reply
* Re: [net-next v2 1/5] dt-bindings: net: starfive,jh7110-dwmac: Remove JH8100
From: Andrew Lunn @ 2026-04-17 14:54 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260417024523.107786-2-minda.chen@starfivetech.com>
On Fri, Apr 17, 2026 at 10:45:19AM +0800, Minda Chen wrote:
> Remove JH8100 dt-bindings because do not support it now.
> StarFive have stopped JH8100 developing and will release it
> outside.
Is there a missing "not" in that sentence?
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v3 6/6] riscv: dts: microchip: add pinctrl nodes for mpfs/icicle kit
From: Conor Dooley @ 2026-04-17 14:51 UTC (permalink / raw)
To: linusw
Cc: Conor Dooley, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
linux-kernel, linux-gpio, devicetree, Valentina.FernandezAlanis
In-Reply-To: <20260119-natural-buddy-acb391bcd9f6@spud>
[-- Attachment #1: Type: text/plain, Size: 3003 bytes --]
On Mon, Jan 19, 2026 at 11:03:57AM +0000, Conor Dooley wrote:
> +
> +&i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_fabric>;
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_fabric>;
> +};
Seemingly, I have run into an erratum here. What I noticed that this
didn't match the schematic and changed it when I applied. Turns out,
this is actually correct on engineering sample silicon but not on
production. Something like
diff --git a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi
index 2d14e92f068d5..9078e5b1e49c1 100644
--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi
+++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-fabric.dtsi
@@ -101,16 +101,6 @@ &ccc_nw {
status = "okay";
};
-&i2c0 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_fabric>;
-};
-
-&i2c1 {
- pinctrl-names = "default";
- pinctrl-0 = <&i2c1_mssio>;
-};
-
&mmuart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_fabric>;
diff --git a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-prod.dts b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-prod.dts
index 8afedece89d1f..636493f6584d2 100644
--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-prod.dts
+++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit-prod.dts
@@ -14,6 +14,16 @@ / {
"microchip,mpfs";
};
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_fabric>;
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_mssio>;
+};
+
&syscontroller {
microchip,bitstream-flash = <&sys_ctrl_flash>;
};
diff --git a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
index 556aa9638282e..6fadce815c9a2 100644
--- a/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
+++ b/arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dts
@@ -11,3 +11,22 @@ / {
"microchip,mpfs-icicle-kit",
"microchip,mpfs";
};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_fabric>;
+};
+
+/*
+ * Due to silicon errata, routing via MSS IOs doesn't work on ES devices.
+ * Instead, i2c1, appearing on B1/C1, which are normally MSS IOs, is routed
+ * via the fabric and back to B1/C1 via "fabric-test" functionality.
+ * This is done silently by Libero, so the iomux0 setting for i2c1 has to
+ * be fabric IO, despite tooling etc saying that MSS IOs are used.
+ *
+ * See Section 3.3 of https://ww1.microchip.com/downloads/aemDocuments/documents/FPGA/ProductDocuments/Errata/polarfiresoc/microsemi_polarfire_soc_fpga_egineering_samples_errata_er0219_v1.pdf
+ */
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_fabric>;
+};
is needed to restore functionality and a further change is required to
"document" in code the extent of the hack required to make it work.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* Re: [PATCH v2 6/6] ASoC: dt-bindings: renesas,fsi: add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-17 14:44 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Krzysztof Kozlowski, kuninori.morimoto.gx, broonie, lgirdwood,
robh, krzk+dt, conor+dt, geert+renesas, magnus.damm, perex, tiwai,
linux-sound, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <CAMuHMdXie1HR6XzkHXAtonh2oemNxH2UZE3uSUjW3xoOmhRjYQ@mail.gmail.com>
Hi Geert,
> It is the main clock that needs to be enabled to make the device
> function. This is independent from the notion of it being a
> "Module Stop Clock" or not, and became sort of a convention.
> Correct. On most (all?) Renesas SoCs, devices are part of a clock
> domain, and their functional clocks are managed by Runtime PM.
> It is not strictly needed to be the first clock, and mostly a relic of the past,
> when clocks weren't accessed by name, but by index.
> Also, many devices have only a single clock, so don't need a name.
Thank you for the clarification. It was very helpful and cleared up my
confusion about the clock naming and ordering.
I really appreciate your support.
Best regards,
Phuc
^ permalink raw reply
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 14:35 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu,
stable
In-Reply-To: <fe1e2ef2-dece-4864-a89b-a311b3ddbfcc@oss.qualcomm.com>
On 4/14/2026 2:59 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
> Should we write a zero there, then?
zero being the reset value for that register, I would prefer avoiding to
write unless needed.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: johannes.goede @ 2026-04-17 14:30 UTC (permalink / raw)
To: Harshal Dev, Konrad Dybcio, Thara Gopinath, Herbert Xu,
David S. Miller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <0d5bf2bd-b90c-4814-bd2e-126a9bcb82ce@oss.qualcomm.com>
Hi,
On 17-Apr-26 15:38, Harshal Dev wrote:
>
>
> On 4/17/2026 4:36 PM, Konrad Dybcio wrote:
>> On 4/17/26 11:22 AM, Harshal Dev wrote:
>>> Hi,
>>>
>>> On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
>>>> On 4/16/26 3:07 PM, Harshal Dev wrote:
>>>>> On Glymur, there is a crypto engine IP block similar to the ones found on
>>>>> SM8x50 platforms.
>>>>>
>>>>> Describe the crypto engine and its BAM.
>>>>>
>>>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>>>>> 1 file changed, 26 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> index f23cf81ddb77..e8c796f2c572 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>>>>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>>>>> status = "disabled";
>>>>> };
>>>>>
>>>>> + cryptobam: dma-controller@1dc4000 {
>>>>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>>>>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>>>>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>>>>> + #dma-cells = <1>;
>>>>> + iommus = <&apps_smmu 0x480 0x0>,
>>>>> + <&apps_smmu 0x481 0x0>;
>>>>
>>>> It seems like these aren't the right SIDs on this platform.. Have you
>>>> tested this patch on hw?
>>>
>>> Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
>>> (I hope I don't need to pad them?)
>>
>> No, you don't
>
> Ack.
>
>>
>>>
>>> Unfortunately, I could only validate driver probe on my limited ramdisk environment:
>>>
>>> [ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
>>>
>>> I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
>>> SIDs and wait for a Tested-by from him.
>>
>> Thanks
>>
>> I think you should be able to get some life out of the crypto engine
>> via CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y (which btw +Hans
>> mentioned reports a failure on Hamoa)
>
> Sure, I'll try this, could you also point me to the bug report?
No bug report yet, I was asking around internally who I should
talk to about his.
I'm seeing 7.0-rc# QCE crypto selftest failures on a Lenovo ThinkPad
T14s gen 6 (Hamoa x1e78100):
[ 1.357020] alg: skcipher: xts-aes-qce setkey failed on test vector 0; expected_error=0, actual_error=-126, flags=0x1
[ 1.369951] alg: skcipher: ctr-aes-qce encryption test failed (wrong output IV) on test vector 4, cfg="in-place (one sglist)"
[ 1.443143] alg: aead: rfc4309-ccm-aes-qce decryption failed on test vector 1; expected_error=0, actual_error=-6, cfg="misaligned splits crossing pages, inplace"
This is with manually compiled 7.0-rc# using Fedora's default kernel
config which includes: CONFIG_EXPERT=y && CONFIG_CRYPTO_SELFTESTS=y
with the latter being hidden behind CONFIG_EXPERT for some reason.
This is a regression compared to 6.19.y where CONFIG_CRYPTO_SELFTESTS=y
is also enabled by Fedora and it works fine.
I've not looked further into this yet, other then a message to fellow
OSTT team arm64-laptop users asking for tips / whom to report this to.
I would be happy to send create a kernel.bugzilla.org bug-report
about this to, or report to email somewhere, or ...
Please let met know where you want a bug-report to be filed and
also what information to add on top of the above info ?
E.g. these failures trigger a WARN() and thus log a backtrace,
do you want those backtraces and if yes I presume I should run
them through addr2line ?
Regards,
Hans
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox