* Re: [PATCH v7 2/3] ufs: host: Add ICE clock scaling during UFS clock changes
From: Harshal Dev @ 2026-03-30 14:39 UTC (permalink / raw)
To: Abhinaba Rakshit, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Neeraj Soni
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, linux-scsi
In-Reply-To: <20260302-enable-ufs-ice-clock-scaling-v7-2-669b96ecadd8@oss.qualcomm.com>
Hi Abhinaba,
On 3/2/2026 4:19 PM, Abhinaba Rakshit wrote:
> Implement ICE (Inline Crypto Engine) clock scaling in sync with
> UFS controller clock scaling. This ensures that the ICE operates at
> an appropriate frequency when the UFS clocks are scaled up or down,
> improving performance and maintaining stability for crypto operations.
>
> For scale_up operation ensure to pass ~round_ceil (round_floor)
> and vice-versa for scale_down operations.
>
> Incase of OPP scaling is not supported by ICE, ensure to not prevent
> devfreq for UFS, as ICE OPP-table is optional.
>
> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> drivers/ufs/host/ufs-qcom.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index 8d119b3223cbdaa3297d2beabced0962a1a847d5..776444f46fe5f00f947e4b0b4dfe6d64e2ad2150 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -305,6 +305,15 @@ static int ufs_qcom_ice_prepare_key(struct blk_crypto_profile *profile,
> return qcom_ice_prepare_key(host->ice, lt_key, lt_key_size, eph_key);
> }
>
> +static int ufs_qcom_ice_scale_clk(struct ufs_qcom_host *host, unsigned long target_freq,
> + bool round_ceil)
> +{
> + if (host->hba->caps & UFSHCD_CAP_CRYPTO)
> + return qcom_ice_scale_clk(host->ice, target_freq, round_ceil);
> +
> + return 0;
> +}
> +
> static const struct blk_crypto_ll_ops ufs_qcom_crypto_ops = {
> .keyslot_program = ufs_qcom_ice_keyslot_program,
> .keyslot_evict = ufs_qcom_ice_keyslot_evict,
> @@ -339,6 +348,12 @@ static void ufs_qcom_config_ice_allocator(struct ufs_qcom_host *host)
> {
> }
>
> +static int ufs_qcom_ice_scale_clk(struct ufs_qcom_host *host, unsigned long target_freq,
> + bool round_ceil)
> +{
> + return 0;
> +}
> +
> #endif
>
> static void ufs_qcom_disable_lane_clks(struct ufs_qcom_host *host)
> @@ -1646,8 +1661,10 @@ static int ufs_qcom_clk_scale_notify(struct ufs_hba *hba, bool scale_up,
> else
> err = ufs_qcom_clk_scale_down_post_change(hba, target_freq);
>
> + if (!err)
> + err = ufs_qcom_ice_scale_clk(host, target_freq, !scale_up);
>
> - if (err) {
> + if (err && err != -EOPNOTSUPP) {
Using -EOPNOTSUPP here works fine for now. But anyone touching any of the lower APIs called by
ufs_qcom_clk_scale_up/down_post_change() needs to ensure they don't return -EOPNOTSUPP, otherwise
hibernate exit will be skipped. So this carries a minor risk of breaking.
Since regardless of whether ufs_qcom_clk_scale_up/down_post_change() fails or ufs_qcom_ice_scale_clk()
fails, we exit from hibernate and return from this function, I suggest you handle the error for ice_scale
separately.
> ufshcd_uic_hibern8_exit(hba);
> return err;
> }
>
Add the call to ufs_qcom_ice_scale_clk() along with error handle here, and let the above error handle
remain untouched.
err = ufs_qcom_ice_scale_clk(host, target_freq, !scale_up);
if (err && err != -EOPNOTSUPP) {
ufshcd_uic_hibern8_exit(hba);
return err;
}
Regards,
Harshal
^ permalink raw reply
* Re: [PATCH v7 1/3] soc: qcom: ice: Add OPP-based clock scaling support for ICE
From: Harshal Dev @ 2026-03-30 14:39 UTC (permalink / raw)
To: Abhinaba Rakshit, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
Neeraj Soni
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel, linux-scsi
In-Reply-To: <20260302-enable-ufs-ice-clock-scaling-v7-1-669b96ecadd8@oss.qualcomm.com>
Hi Abhinaba,
On 3/2/2026 4:19 PM, Abhinaba Rakshit wrote:
> Register optional operation-points-v2 table for ICE device
> during device probe.
>
> Introduce clock scaling API qcom_ice_scale_clk which scale ICE
> core clock based on the target frequency provided and if a valid
> OPP-table is registered. Use round_ceil passed to decide on the
> rounding of the clock freq against OPP-table. Disable clock scaling
> if OPP-table is not registered.
>
> When an ICE-device specific OPP table is available, use the PM OPP
> framework to manage frequency scaling and maintain proper power-domain
> constraints.
>
> Also, ensure to drop the votes in suspend to prevent power/thermal
> retention. Subsequently restore the frequency in resume from
> core_clk_freq which stores the last ICE core clock operating frequency.
>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> ---
> drivers/soc/qcom/ice.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++--
> include/soc/qcom/ice.h | 2 ++
> 2 files changed, 81 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/soc/qcom/ice.c b/drivers/soc/qcom/ice.c
> index b203bc685cadd21d6f96eb1799963a13db4b2b72..7976a18d9a4cda1ad6b62b66ce011e244d0f6856 100644
> --- a/drivers/soc/qcom/ice.c
> +++ b/drivers/soc/qcom/ice.c
> @@ -16,6 +16,7 @@
> #include <linux/of.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_opp.h>
>
> #include <linux/firmware/qcom/qcom_scm.h>
>
> @@ -111,6 +112,8 @@ struct qcom_ice {
> bool use_hwkm;
> bool hwkm_init_complete;
> u8 hwkm_version;
> + unsigned long core_clk_freq;
> + bool has_opp;
> };
>
> static bool qcom_ice_check_supported(struct qcom_ice *ice)
> @@ -310,6 +313,10 @@ int qcom_ice_resume(struct qcom_ice *ice)
> struct device *dev = ice->dev;
> int err;
>
> + /* Restore the ICE core clk freq */
> + if (ice->has_opp && ice->core_clk_freq)
> + dev_pm_opp_set_rate(ice->dev, ice->core_clk_freq);
> +
> err = clk_prepare_enable(ice->core_clk);
> if (err) {
> dev_err(dev, "failed to enable core clock (%d)\n",
> @@ -324,6 +331,11 @@ EXPORT_SYMBOL_GPL(qcom_ice_resume);
> int qcom_ice_suspend(struct qcom_ice *ice)
> {
> clk_disable_unprepare(ice->core_clk);
> +
> + /* Drop the clock votes while suspend */
> + if (ice->has_opp)
> + dev_pm_opp_set_rate(ice->dev, 0);
> +
> ice->hwkm_init_complete = false;
>
> return 0;
> @@ -549,10 +561,54 @@ int qcom_ice_import_key(struct qcom_ice *ice,
> }
> EXPORT_SYMBOL_GPL(qcom_ice_import_key);
>
> +/**
> + * qcom_ice_scale_clk() - Scale ICE clock for DVFS-aware operations
> + * @ice: ICE driver data
> + * @target_freq: requested frequency in Hz
> + * @round_ceil: when true, selects nearest freq >= @target_freq;
> + * otherwise, selects nearest freq <= @target_freq
> + *
> + * Selects an OPP frequency based on @target_freq and the rounding direction
> + * specified by @round_ceil, then programs it using dev_pm_opp_set_rate(),
> + * including any voltage or power-domain transitions handled by the OPP
> + * framework. Updates ice->core_clk_freq on success.
> + *
> + * Return: 0 on success; -EOPNOTSUPP if no OPP table; -EINVAL in-case of
> + * incorrect flags; or error from dev_pm_opp_set_rate()/OPP lookup.
> + */
> +int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
> + bool round_ceil)
Any particular reason for choosing round_ceil? Using round_floor would have
saved the need for caller to pass negation of scale_up.
> +{
> + unsigned long ice_freq = target_freq;
> + struct dev_pm_opp *opp;
> + int ret;
> +
> + if (!ice->has_opp)
> + return -EOPNOTSUPP;
> +
> + if (round_ceil)
> + opp = dev_pm_opp_find_freq_ceil(ice->dev, &ice_freq);
> + else
> + opp = dev_pm_opp_find_freq_floor(ice->dev, &ice_freq);
> +
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
> + dev_pm_opp_put(opp);
> +
> + ret = dev_pm_opp_set_rate(ice->dev, ice_freq);
> + if (!ret)
> + ice->core_clk_freq = ice_freq;
Nit: Follow same error handling pattern everywhere in the driver.
if (ret) {
dev_err(dev, "error");
return ret;
}
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(qcom_ice_scale_clk);
> +
> static struct qcom_ice *qcom_ice_create(struct device *dev,
> - void __iomem *base)
> + void __iomem *base,
> + bool is_legacy_binding)
You don't need to introduce is_legacy_binding.
Since you only need to add the OPP table when this function gets called from ICE probe,
you should not touch this function. Instead, you should call devm_pm_opp_of_add_table()
in ICE probe before calling qcom_ice_create() then once qcom_ice_create() is success, you
can store the clk rate in the returned qcom_ice *engine ptr by calling clk_get_rate().
> {
> struct qcom_ice *engine;
> + int err;
>
> if (!qcom_scm_is_available())
> return ERR_PTR(-EPROBE_DEFER);
> @@ -584,6 +640,26 @@ static struct qcom_ice *qcom_ice_create(struct device *dev,
> if (IS_ERR(engine->core_clk))
> return ERR_CAST(engine->core_clk);
>
> + /*
> + * Register the OPP table only when ICE is described as a standalone
> + * device node. Older platforms place ICE inside the storage controller
> + * node, so they don't need an OPP table here, as they are handled in
> + * storage controller.
> + */
> + if (!is_legacy_binding) {
> + /* OPP table is optional */
> + err = devm_pm_opp_of_add_table(dev);
> + if (err && err != -ENODEV) {
> + dev_err(dev, "Invalid OPP table in Device tree\n");
> + return ERR_PTR(err);
> + }
> + engine->has_opp = (err == 0);
Let's keep it readable and simple. engine->has_opps = true; here and false in error handle above.
> +
> + if (!engine->has_opp)
> + dev_info(dev, "ICE OPP table is not registered, please update your DT\n");
Since OPP table is optional, I don't understand the reason for requesting the user to add one.
> + }
> +
> + engine->core_clk_freq = clk_get_rate(engine->core_clk);
> if (!qcom_ice_check_supported(engine))
> return ERR_PTR(-EOPNOTSUPP);
>
> @@ -628,7 +704,7 @@ static struct qcom_ice *of_qcom_ice_get(struct device *dev)
> return ERR_CAST(base);
>
> /* create ICE instance using consumer dev */
> - return qcom_ice_create(&pdev->dev, base);
> + return qcom_ice_create(&pdev->dev, base, true);
> }
>
> /*
> @@ -725,7 +801,7 @@ static int qcom_ice_probe(struct platform_device *pdev)
> return PTR_ERR(base);
> }
>
> - engine = qcom_ice_create(&pdev->dev, base);
> + engine = qcom_ice_create(&pdev->dev, base, false);
Change not needed as per above comment.
Regards,
Harshal
> if (IS_ERR(engine))
> return PTR_ERR(engine);
>
> diff --git a/include/soc/qcom/ice.h b/include/soc/qcom/ice.h
> index 4bee553f0a59d86ec6ce20f7c7b4bce28a706415..4eb58a264d416e71228ed4b13e7f53c549261fdc 100644
> --- a/include/soc/qcom/ice.h
> +++ b/include/soc/qcom/ice.h
> @@ -30,5 +30,7 @@ int qcom_ice_import_key(struct qcom_ice *ice,
> const u8 *raw_key, size_t raw_key_size,
> u8 lt_key[BLK_CRYPTO_MAX_HW_WRAPPED_KEY_SIZE]);
> struct qcom_ice *devm_of_qcom_ice_get(struct device *dev);
> +int qcom_ice_scale_clk(struct qcom_ice *ice, unsigned long target_freq,
> + bool round_ceil);
>
> #endif /* __QCOM_ICE_H__ */
>
^ permalink raw reply
* Re: [PATCH v2 2/7] pwm: tegra: Avoid hard-coded max clock frequency
From: kernel test robot @ 2026-03-30 14:36 UTC (permalink / raw)
To: Mikko Perttunen, Thierry Reding, Uwe Kleine-König,
Jonathan Hunter, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: oe-kbuild-all, linux-pwm, linux-tegra, linux-kernel, devicetree,
Yi-Wei Wang, Mikko Perttunen
In-Reply-To: <20260325-t264-pwm-v2-2-998d885984b3@nvidia.com>
Hi Mikko,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 11439c4635edd669ae435eec308f4ab8a0804808]
url: https://github.com/intel-lab-lkp/linux/commits/Mikko-Perttunen/dt-bindings-pwm-Document-Tegra194-and-Tegra264-controllers/20260329-233356
base: 11439c4635edd669ae435eec308f4ab8a0804808
patch link: https://lore.kernel.org/r/20260325-t264-pwm-v2-2-998d885984b3%40nvidia.com
patch subject: [PATCH v2 2/7] pwm: tegra: Avoid hard-coded max clock frequency
config: nios2-allmodconfig (https://download.01.org/0day-ci/archive/20260330/202603302259.NdAkuCVx-lkp@intel.com/config)
compiler: nios2-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260330/202603302259.NdAkuCVx-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603302259.NdAkuCVx-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/linux/kernel.h:17,
from include/linux/clk.h:13,
from drivers/pwm/pwm-tegra.c:39:
drivers/pwm/pwm-tegra.c: In function 'tegra_pwm_probe':
>> include/linux/limits.h:26:25: warning: unsigned conversion from 'long long int' to 'long unsigned int' changes value from '9223372036854775807' to '4294967295' [-Woverflow]
26 | #define S64_MAX ((s64)(U64_MAX >> 1))
| ^~~~~~~~~~~~~~~~~~~~~
drivers/pwm/pwm-tegra.c:303:47: note: in expansion of macro 'S64_MAX'
303 | ret = dev_pm_opp_set_rate(&pdev->dev, S64_MAX);
| ^~~~~~~
vim +26 include/linux/limits.h
3c9d017cc283df Andy Shevchenko 2023-08-04 14
54d50897d544c8 Masahiro Yamada 2019-03-07 15 #define U8_MAX ((u8)~0U)
54d50897d544c8 Masahiro Yamada 2019-03-07 16 #define S8_MAX ((s8)(U8_MAX >> 1))
54d50897d544c8 Masahiro Yamada 2019-03-07 17 #define S8_MIN ((s8)(-S8_MAX - 1))
54d50897d544c8 Masahiro Yamada 2019-03-07 18 #define U16_MAX ((u16)~0U)
54d50897d544c8 Masahiro Yamada 2019-03-07 19 #define S16_MAX ((s16)(U16_MAX >> 1))
54d50897d544c8 Masahiro Yamada 2019-03-07 20 #define S16_MIN ((s16)(-S16_MAX - 1))
54d50897d544c8 Masahiro Yamada 2019-03-07 21 #define U32_MAX ((u32)~0U)
3f50f132d8400e John Fastabend 2020-03-30 22 #define U32_MIN ((u32)0)
54d50897d544c8 Masahiro Yamada 2019-03-07 23 #define S32_MAX ((s32)(U32_MAX >> 1))
54d50897d544c8 Masahiro Yamada 2019-03-07 24 #define S32_MIN ((s32)(-S32_MAX - 1))
54d50897d544c8 Masahiro Yamada 2019-03-07 25 #define U64_MAX ((u64)~0ULL)
54d50897d544c8 Masahiro Yamada 2019-03-07 @26 #define S64_MAX ((s64)(U64_MAX >> 1))
54d50897d544c8 Masahiro Yamada 2019-03-07 27 #define S64_MIN ((s64)(-S64_MAX - 1))
54d50897d544c8 Masahiro Yamada 2019-03-07 28
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: qcom: sm8550: add cpu OPP table with DDR, LLCC & L3 bandwidths
From: Bjorn Andersson @ 2026-03-30 14:33 UTC (permalink / raw)
To: webgeek1234
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Georgi Djakov, Sibi Sankar, linux-arm-msm, devicetree,
linux-kernel, linux-pm, Neil Armstrong, Konrad Dybcio
In-Reply-To: <20260219-sm8550-ddr-bw-scaling-v3-2-75c19152e921@gmail.com>
On Thu, Feb 19, 2026 at 10:07:40PM -0600, Aaron Kling via B4 Relay wrote:
> From: Aaron Kling <webgeek1234@gmail.com>
>
> Add the OPP tables for each CPU clusters (cpu0-1-2, cpu3-4-5-6 & cpu7)
> to permit scaling the Last Level Cache Controller (LLCC), DDR and L3 cache
> frequency by aggregating bandwidth requests of all CPU core with referenc
> to the current OPP they are configured in by the LMH/EPSS hardware.
>
> The effect is a proper caches & DDR frequency scaling when CPU cores
> changes frequency.
>
> The OPP tables were built using the downstream memlat ddr, llcc & l3
> tables for each cluster types with the actual EPSS cpufreq LUT tables
> from running a QCS8550 device.
>
> Also add the OSC L3 Cache controller node.
>
> Also add the interconnect entry for each cpu, with 3 different paths:
> - CPU to Last Level Cache Controller (LLCC)
> - Last Level Cache Controller (LLCC) to DDR
> - L3 Cache from CPU to DDR interface
>
"8 out of 11 hunks FAILED", it seems things moved since you wrote this.
Can you please help me by rebasing this onto linux-next and resubmitting
it?
Regards,
Bjorn
> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-HDK
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
> arch/arm64/boot/dts/qcom/sm8550.dtsi | 367 +++++++++++++++++++++++++++++++++++
> 1 file changed, 367 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index e3f93f4f412ded9583a6bc9215185a0daf5f1b57..de4d43f7b8d2416997db70c98b0fc36d25f3c2a6 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -17,6 +17,7 @@
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/interconnect/qcom,icc.h>
> #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
> +#include <dt-bindings/interconnect/qcom,osm-l3.h>
> #include <dt-bindings/mailbox/qcom-ipcc.h>
> #include <dt-bindings/power/qcom-rpmpd.h>
> #include <dt-bindings/power/qcom,rpmhpd.h>
> @@ -78,6 +79,13 @@ cpu0: cpu@0 {
> qcom,freq-domain = <&cpufreq_hw 0>;
> capacity-dmips-mhz = <1024>;
> dynamic-power-coefficient = <100>;
> + operating-points-v2 = <&cpu0_opp_table>;
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&epss_l3 MASTER_EPSS_L3_APPS
> + &epss_l3 SLAVE_EPSS_L3_SHARED>;
> #cooling-cells = <2>;
> l2_0: l2-cache {
> compatible = "cache";
> @@ -104,6 +112,13 @@ cpu1: cpu@100 {
> qcom,freq-domain = <&cpufreq_hw 0>;
> capacity-dmips-mhz = <1024>;
> dynamic-power-coefficient = <100>;
> + operating-points-v2 = <&cpu0_opp_table>;
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&epss_l3 MASTER_EPSS_L3_APPS
> + &epss_l3 SLAVE_EPSS_L3_SHARED>;
> #cooling-cells = <2>;
> l2_100: l2-cache {
> compatible = "cache";
> @@ -125,6 +140,13 @@ cpu2: cpu@200 {
> qcom,freq-domain = <&cpufreq_hw 0>;
> capacity-dmips-mhz = <1024>;
> dynamic-power-coefficient = <100>;
> + operating-points-v2 = <&cpu0_opp_table>;
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&epss_l3 MASTER_EPSS_L3_APPS
> + &epss_l3 SLAVE_EPSS_L3_SHARED>;
> #cooling-cells = <2>;
> l2_200: l2-cache {
> compatible = "cache";
> @@ -146,6 +168,13 @@ cpu3: cpu@300 {
> qcom,freq-domain = <&cpufreq_hw 1>;
> capacity-dmips-mhz = <1792>;
> dynamic-power-coefficient = <270>;
> + operating-points-v2 = <&cpu3_opp_table>;
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&epss_l3 MASTER_EPSS_L3_APPS
> + &epss_l3 SLAVE_EPSS_L3_SHARED>;
> #cooling-cells = <2>;
> l2_300: l2-cache {
> compatible = "cache";
> @@ -167,6 +196,13 @@ cpu4: cpu@400 {
> qcom,freq-domain = <&cpufreq_hw 1>;
> capacity-dmips-mhz = <1792>;
> dynamic-power-coefficient = <270>;
> + operating-points-v2 = <&cpu3_opp_table>;
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&epss_l3 MASTER_EPSS_L3_APPS
> + &epss_l3 SLAVE_EPSS_L3_SHARED>;
> #cooling-cells = <2>;
> l2_400: l2-cache {
> compatible = "cache";
> @@ -188,6 +224,13 @@ cpu5: cpu@500 {
> qcom,freq-domain = <&cpufreq_hw 1>;
> capacity-dmips-mhz = <1792>;
> dynamic-power-coefficient = <270>;
> + operating-points-v2 = <&cpu3_opp_table>;
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&epss_l3 MASTER_EPSS_L3_APPS
> + &epss_l3 SLAVE_EPSS_L3_SHARED>;
> #cooling-cells = <2>;
> l2_500: l2-cache {
> compatible = "cache";
> @@ -209,6 +252,13 @@ cpu6: cpu@600 {
> qcom,freq-domain = <&cpufreq_hw 1>;
> capacity-dmips-mhz = <1792>;
> dynamic-power-coefficient = <270>;
> + operating-points-v2 = <&cpu3_opp_table>;
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&epss_l3 MASTER_EPSS_L3_APPS
> + &epss_l3 SLAVE_EPSS_L3_SHARED>;
> #cooling-cells = <2>;
> l2_600: l2-cache {
> compatible = "cache";
> @@ -230,6 +280,13 @@ cpu7: cpu@700 {
> qcom,freq-domain = <&cpufreq_hw 2>;
> capacity-dmips-mhz = <1894>;
> dynamic-power-coefficient = <588>;
> + operating-points-v2 = <&cpu7_opp_table>;
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &gem_noc SLAVE_LLCC QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mc_virt MASTER_LLCC QCOM_ICC_TAG_ACTIVE_ONLY
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&epss_l3 MASTER_EPSS_L3_APPS
> + &epss_l3 SLAVE_EPSS_L3_SHARED>;
> #cooling-cells = <2>;
> l2_700: l2-cache {
> compatible = "cache";
> @@ -397,6 +454,306 @@ memory@a0000000 {
> reg = <0 0xa0000000 0 0>;
> };
>
> + cpu0_opp_table: opp-table-cpu0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-307200000 {
> + opp-hz = /bits/ 64 <307200000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (307200 * 32)>;
> + };
> +
> + opp-441600000 {
> + opp-hz = /bits/ 64 <441600000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (384000 * 32)>;
> + };
> +
> + opp-556800000 {
> + opp-hz = /bits/ 64 <556800000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (499200 * 32)>;
> + };
> +
> + opp-672000000 {
> + opp-hz = /bits/ 64 <672000000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (499200 * 32)>;
> + };
> +
> + opp-787200000 {
> + opp-hz = /bits/ 64 <787200000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (729600 * 32)>;
> + };
> +
> + opp-902400000 {
> + opp-hz = /bits/ 64 <902400000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (844800 * 32)>;
> + };
> +
> + opp-1017600000 {
> + opp-hz = /bits/ 64 <1017600000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (940800 * 32)>;
> + };
> +
> + opp-1113600000 {
> + opp-hz = /bits/ 64 <1113600000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (1056000 * 32)>;
> + };
> +
> + opp-1228800000 {
> + opp-hz = /bits/ 64 <1228800000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (1152000 * 32)>;
> + };
> +
> + opp-1344000000 {
> + opp-hz = /bits/ 64 <1344000000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (1267200 * 32)>;
> + };
> +
> + opp-1459200000 {
> + opp-hz = /bits/ 64 <1459200000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (1267200 * 32)>;
> + };
> +
> + opp-1555200000 {
> + opp-hz = /bits/ 64 <1555200000>;
> + opp-peak-kBps = <(466000 * 16) (768000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-1670400000 {
> + opp-hz = /bits/ 64 <1670400000>;
> + opp-peak-kBps = <(466000 * 16) (768000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-1785600000 {
> + opp-hz = /bits/ 64 <1785600000>;
> + opp-peak-kBps = <(466000 * 16) (768000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-1900800000 {
> + opp-hz = /bits/ 64 <1900800000>;
> + opp-peak-kBps = <(466000 * 16) (768000 * 4) (1689600 * 32)>;
> + };
> +
> + opp-2016000000 {
> + opp-hz = /bits/ 64 <2016000000>;
> + opp-peak-kBps = <(600000 * 16) (1555000 * 4) (1804800 * 32)>;
> + };
> + };
> +
> + cpu3_opp_table: opp-table-cpu3 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-499200000 {
> + opp-hz = /bits/ 64 <499200000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (307200 * 32)>;
> + };
> +
> + opp-614400000 {
> + opp-hz = /bits/ 64 <614400000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (499200 * 32)>;
> + };
> +
> + opp-729600000 {
> + opp-hz = /bits/ 64 <729600000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (499200 * 32)>;
> + };
> +
> + opp-844800000 {
> + opp-hz = /bits/ 64 <844800000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (499200 * 32)>;
> + };
> +
> + opp-940800000 {
> + opp-hz = /bits/ 64 <940800000>;
> + opp-peak-kBps = <(300000 * 16) (768000 * 4) (729600 * 32)>;
> + };
> +
> + opp-1056000000 {
> + opp-hz = /bits/ 64 <1056000000>;
> + opp-peak-kBps = <(300000 * 16) (768000 * 4) (729600 * 32)>;
> + };
> +
> + opp-1171200000 {
> + opp-hz = /bits/ 64 <1171200000>;
> + opp-peak-kBps = <(466000 * 16) (1555000 * 4) (940800 * 32)>;
> + };
> +
> + opp-1286400000 {
> + opp-hz = /bits/ 64 <1286400000>;
> + opp-peak-kBps = <(466000 * 16) (1555000 * 4) (940800 * 32)>;
> + };
> +
> + opp-1401600000 {
> + opp-hz = /bits/ 64 <1401600000>;
> + opp-peak-kBps = <(600000 * 16) (1708000 * 4) (1056000 * 32)>;
> + };
> +
> + opp-1536000000 {
> + opp-hz = /bits/ 64 <1536000000>;
> + opp-peak-kBps = <(600000 * 16) (1708000 * 4) (1056000 * 32)>;
> + };
> +
> + opp-1651200000 {
> + opp-hz = /bits/ 64 <1651200000>;
> + opp-peak-kBps = <(600000 * 16) (1708000 * 4) (1267200 * 32)>;
> + };
> +
> + opp-1785600000 {
> + opp-hz = /bits/ 64 <1785600000>;
> + opp-peak-kBps = <(600000 * 16) (1708000 * 4) (1267200 * 32)>;
> + };
> +
> + opp-1920000000 {
> + opp-hz = /bits/ 64 <1920000000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1267200 * 32)>;
> + };
> +
> + opp-2054400000 {
> + opp-hz = /bits/ 64 <2054400000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2188800000 {
> + opp-hz = /bits/ 64 <2188800000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2323200000 {
> + opp-hz = /bits/ 64 <2323200000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2457600000 {
> + opp-hz = /bits/ 64 <2457600000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2592000000 {
> + opp-hz = /bits/ 64 <2592000000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2707200000 {
> + opp-hz = /bits/ 64 <2707200000>;
> + opp-peak-kBps = <(933000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2803200000 {
> + opp-hz = /bits/ 64 <2803200000>;
> + opp-peak-kBps = <(933000 * 16) (3686000 * 4) (1689600 * 32)>;
> + };
> + };
> +
> + cpu7_opp_table: opp-table-cpu7 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-595200000 {
> + opp-hz = /bits/ 64 <595200000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (307200 * 32)>;
> + };
> +
> + opp-729600000 {
> + opp-hz = /bits/ 64 <729600000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (499200 * 32)>;
> + };
> +
> + opp-864000000 {
> + opp-hz = /bits/ 64 <864000000>;
> + opp-peak-kBps = <(300000 * 16) (547000 * 4) (499200 * 32)>;
> + };
> +
> + opp-998400000 {
> + opp-hz = /bits/ 64 <998400000>;
> + opp-peak-kBps = <(300000 * 16) (768000 * 4) (729600 * 32)>;
> + };
> +
> + opp-1132800000 {
> + opp-hz = /bits/ 64 <1132800000>;
> + opp-peak-kBps = <(300000 * 16) (768000 * 4) (729600 * 32)>;
> + };
> +
> + opp-1248000000 {
> + opp-hz = /bits/ 64 <1248000000>;
> + opp-peak-kBps = <(466000 * 16) (1555000 * 4) (940800 * 32)>;
> + };
> +
> + opp-1363200000 {
> + opp-hz = /bits/ 64 <1363200000>;
> + opp-peak-kBps = <(466000 * 16) (1555000 * 4) (940800 * 32)>;
> + };
> +
> + opp-1478400000 {
> + opp-hz = /bits/ 64 <1478400000>;
> + opp-peak-kBps = <(600000 * 16) (1708000 * 4) (1056000 * 32)>;
> + };
> +
> + opp-1593600000 {
> + opp-hz = /bits/ 64 <1593600000>;
> + opp-peak-kBps = <(600000 * 16) (1708000 * 4) (1056000 * 32)>;
> + };
> +
> + opp-1708800000 {
> + opp-hz = /bits/ 64 <1708800000>;
> + opp-peak-kBps = <(600000 * 16) (1708000 * 4) (1267200 * 32)>;
> + };
> +
> + opp-1843200000 {
> + opp-hz = /bits/ 64 <1843200000>;
> + opp-peak-kBps = <(600000 * 16) (1708000 * 4) (1267200 * 32)>;
> + };
> +
> + opp-1977600000 {
> + opp-hz = /bits/ 64 <1977600000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1267200 * 32)>;
> + };
> +
> + opp-2092800000 {
> + opp-hz = /bits/ 64 <2092800000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2227200000 {
> + opp-hz = /bits/ 64 <2227200000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2342400000 {
> + opp-hz = /bits/ 64 <2342400000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2476800000 {
> + opp-hz = /bits/ 64 <2476800000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2592000000 {
> + opp-hz = /bits/ 64 <2592000000>;
> + opp-peak-kBps = <(806000 * 16) (2736000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2726400000 {
> + opp-hz = /bits/ 64 <2726400000>;
> + opp-peak-kBps = <(933000 * 16) (3686000 * 4) (1478400 * 32)>;
> + };
> +
> + opp-2841600000 {
> + opp-hz = /bits/ 64 <2841600000>;
> + opp-peak-kBps = <(933000 * 16) (3686000 * 4) (1689600 * 32)>;
> + };
> +
> + opp-2956800000 {
> + opp-hz = /bits/ 64 <2956800000>;
> + opp-peak-kBps = <(933000 * 16) (3686000 * 4) (1689600 * 32)>;
> + };
> +
> + opp-3187200000 {
> + opp-hz = /bits/ 64 <3187200000>;
> + opp-peak-kBps = <(933000 * 16) (3686000 * 4) (1689600 * 32)>;
> + };
> + };
> +
> pmu-a510 {
> compatible = "arm,cortex-a510-pmu";
> interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW &ppi_cluster0>;
> @@ -5437,6 +5794,16 @@ rpmhpd_opp_turbo_l1: opp-416 {
> };
> };
>
> + epss_l3: interconnect@17d90000 {
> + compatible = "qcom,sm8550-epss-l3", "qcom,epss-l3";
> + reg = <0 0x17d90000 0 0x1000>;
> +
> + clocks = <&bi_tcxo_div2>, <&gcc GCC_GPLL0>;
> + clock-names = "xo", "alternate";
> +
> + #interconnect-cells = <1>;
> + };
> +
> cpufreq_hw: cpufreq@17d91000 {
> compatible = "qcom,sm8550-cpufreq-epss", "qcom,cpufreq-epss";
> reg = <0 0x17d91000 0 0x1000>,
>
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Bryan O'Donoghue @ 2026-03-30 14:32 UTC (permalink / raw)
To: johannes.goede, Dmitry Baryshkov
Cc: Loic Poulain, vladimir.zapolskiy, laurent.pinchart,
kieran.bingham, robh, krzk+dt, andersson, konradybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel, mchehab
In-Reply-To: <2e4c4641-f631-48fa-b5dd-6efd70110dd6@oss.qualcomm.com>
On 30/03/2026 15:27, johannes.goede@oss.qualcomm.com wrote:
>> That's another reason I bring up CDM again and again. We probably don't want to fix to the wrong format for OPE, introduce the CDM and then find we have to map from one format to another for large and complex data over and over again for each frame or every N frames.
> CDM is a much lower-level API then what is expected from
> a media-controller centric V4L2 driver. Basically the OPE
> driver will export:
My concern is about wrappering one thing inside of another thing and
then stuffing it again back into CDM and doing the same on the way out.
There are already 50 MMIO writes in the OPE ISR, I don't believe it is
sustainable to keep adding MMIO into that.
I'm aware of a project in qcom that did something with making the CDM
format in libcamera and handed that off to kernel, recommend looking
into that.
---
bod
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: phy: qcom-edp: Add reference clock for sa8775p eDP PHY
From: Bjorn Andersson @ 2026-03-30 14:28 UTC (permalink / raw)
To: Ritesh Kumar
Cc: robin.clark, lumag, abhinav.kumar, sean, marijn.suijten,
maarten.lankhorst, mripard, tzimmermann, airlied, simona, robh,
krzk+dt, conor+dt, quic_mahap, konradybcio, mani, James.Bottomley,
martin.petersen, vkoul, kishon, cros-qcom-dts-watchers, linux-phy,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
linux-scsi, quic_vproddut
In-Reply-To: <c77ff64f-57d1-4495-bfbd-986644aad71d@quicinc.com>
On Wed, Mar 11, 2026 at 06:37:31PM +0530, Ritesh Kumar wrote:
>
> On 3/5/2026 12:27 AM, Bjorn Andersson wrote:
> > On Wed, Jan 28, 2026 at 05:18:49PM +0530, Ritesh Kumar wrote:
> > > The initial sa8775p eDP PHY binding contribution missed adding support for
> > > voting on the eDP reference clock. This went unnoticed because the UFS PHY
> > > driver happened to enable the same clock.
> > > > After commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor
> > phy_power_on/off
> > > calls"), the eDP reference clock is no longer kept enabled, which results
> > > in the following PHY power-on failure:
> > > > phy phy-aec2a00.phy.10: phy poweron failed --> -110
> > > > To fix this, explicit voting for the eDP reference clock is
> > required.
> > > This patch adds the eDP reference clock for sa8775p eDP PHY and updates
> > > the corresponding example node.
> > > > Signed-off-by: Ritesh Kumar <quic_riteshk@quicinc.com>
> >
> > Is there any reason why you didn't follow up on this patch Ritesh?
> > Looks like it's ready to be merged.
>
> I was waiting for patch to merge as there is no pending comments.
>
It's been two months now, if you want your patches to be merged please
show that - ask the maintainer for a status update, ask a colleague to
send a reviewed-by...
Perhaps the maintainer lost track of your change?
Perhaps it's not clear that the change "need" an Ack from e.g. Dmitry
and then it should be merged by Vinod? Because you're changing two
different subsystems but leave it up to the maintainers to figure out
how to deal with this...
Either way, show that you want this to be merged, don't just wait until
the situation resolves itself.
Regards,
Bjorn
> > Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> >
> > Regards,
> > Bjorn
> >
> > > ---
> > > .../devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml | 6 ++++--
> > > Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml | 1 +
> > > 2 files changed, 5 insertions(+), 2 deletions(-)
> > > > diff --git
> > a/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml
> > b/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml
> > > index e2730a2f25cf..6c827cf9692b 100644
> > > --- a/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml
> > > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sa8775p-mdss.yaml
> > > @@ -200,9 +200,11 @@ examples:
> > > <0x0aec2000 0x1c8>;
> > > > clocks = <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>,
> > > - <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>;
> > > + <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>,
> > > + <&gcc GCC_EDP_REF_CLKREF_EN>;
> > > clock-names = "aux",
> > > - "cfg_ahb";
> > > + "cfg_ahb",
> > > + "ref";
> > > > #clock-cells = <1>;
> > > #phy-cells = <0>;
> > > diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
> > > index 4a1daae3d8d4..0bf8bf4f66ac 100644
> > > --- a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml
> > > @@ -74,6 +74,7 @@ allOf:
> > > compatible:
> > > enum:
> > > - qcom,glymur-dp-phy
> > > + - qcom,sa8775p-edp-phy
> > > - qcom,x1e80100-dp-phy
> > > then:
> > > properties:
> > > -- > 2.34.1
> > >
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: johannes.goede @ 2026-03-30 14:27 UTC (permalink / raw)
To: Bryan O'Donoghue, Dmitry Baryshkov
Cc: Loic Poulain, vladimir.zapolskiy, laurent.pinchart,
kieran.bingham, robh, krzk+dt, andersson, konradybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel, mchehab
In-Reply-To: <0879e4c1-5381-4a70-9fb3-4af9b3bf6e48@kernel.org>
Hi,
On 30-Mar-26 16:11, Bryan O'Donoghue wrote:
> On 30/03/2026 14:46, johannes.goede@oss.qualcomm.com wrote:
>>>> And then your CCMv1 or CCMv2 helper will get called with
>>>> the matching parameter-data.
>>> This leads to userspace having to know exact format for each hardware
>>> version, which is not nice. At the very least it should be possible to
>>> accept CCMv1 buffers and covert them to CCMv2 when required.
>> Yes, but a new ISP may also have a different pipeline altogether
>> with e.g. more then one preview/viewfinder output vs one viewfinder
>> output for current hw, etc.
>
> My scoping on HFI shows that the IQ structures between Kona and later versions have pretty stable data-structures.
>
> It might be worthwhile for the non-HFI version to implement those structures.
Maybe, it depends on if they are really 100% the same
various IQ parameters are in various different fixed-point
formats. I don't think we want to be converting from
one precision fixed-point to another precision fixed-point
in the kernel.
> I keep mentioning CDM. Its also possible to construct the buffer in the format the CDM would require and hand that from user-space into the kernel.
I believe the CDM take register addresses + values to setup
the OPE for the next stripe to process ?
Directly exporting a format which takes register addresses
+ values to userspace does not sound like a good idea.
If you look at the current structure of the OPE driver
it already keeps tracks if per stripe settings, only atm
it programs those directly on the stripe completion IRQ
rather then setting up the CDM. Generating the CDM settings
from that data should be straight forward.
I really do not believe that such low-level details belong
in the userspace API in any way.
If anything whether we are using the CDM or directly doing
the next stripe programming from the IRQ handler should
be completely transparent to userspace.
>
> That would save alot of overhead translating from one format to another.
>
> That's another reason I bring up CDM again and again. We probably don't want to fix to the wrong format for OPE, introduce the CDM and then find we have to map from one format to another for large and complex data over and over again for each frame or every N frames.
CDM is a much lower-level API then what is expected from
a media-controller centric V4L2 driver. Basically the OPE
driver will export:
* media-controller node
* bunch of subdevs + routing between them
* /dev/video# videobuffer queue for raw input frames
* /dev/video# parameter queue for extensible generic v4l2 ISP parameters buffers (with qcom specific contents)
* /dev/video# videobuffer "video" output queue for processed frames
* /dev/video# videobuffer "viewfinder" output queue for "extra" downscaled processed frames
No statistics since these come from the CSI2 bits (VFE PIX)
on Agetti.
This is is basically the current consensus what a modern
hardware camera ISP driver should look like to userspace.
Anything lower level then this should be abstracted by
the kernel.
Note both output nodes can probably downscale, but
the viewfinder one can do an extra downscaling step
on top in case userspace wants 2 streams one higher res
to record and a lower-res to show on screen.
Regards,
Hans
^ permalink raw reply
* [PATCH] arm64: dts: qcom: glymur-crd: Enable DisplayPort support
From: Abel Vesa @ 2026-03-30 14:24 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
The two Type-C ports found on Glymur CRD are DisplayPort alternate mode
capable. Everything is in place already for the USB, but for DisplayPort
the controllers need to be enabled.
So enable the related DisplayPort controller for each of these two
ports. Also define the supported link frequencies for each output.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
---
SoCCP support is still missing, so DP altmode won't work until SoCCP
support is added.
---
arch/arm64/boot/dts/qcom/glymur-crd.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
index 51ea23a49b9e..35aaf09e4e2b 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
@@ -202,6 +202,22 @@ &mdss {
status = "okay";
};
+&mdss_dp0 {
+ status = "okay";
+};
+
+&mdss_dp0_out {
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
+&mdss_dp1 {
+ status = "okay";
+};
+
+&mdss_dp1_out {
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
+};
+
&mdss_dp3 {
/delete-property/ #sound-dai-cells;
---
base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
change-id: 20260330-glymur-enable-displayport-8e96854a35eb
Best regards,
--
Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply related
* RE: [PATCH v5 2/4] iio: adc: ad4691: add initial driver for AD4691 family
From: Sabau, Radu bogdan @ 2026-03-30 14:20 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lars-Peter Clausen, Hennerich, Michael, Jonathan Cameron,
David Lechner, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <acZrthJYQX-h_9p5@ashevche-desk.local>
> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko@intel.com>
> Sent: Friday, March 27, 2026 1:36 PM
> To: Sabau, Radu bogdan <Radu.Sabau@analog.com>
...
>
> > +#include <linux/bitfield.h>
> > +#include <linux/bitops.h>
> > +#include <linux/cleanup.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
>
> Hmm... Is it used? Or perhaps you need only
> dev_printk.h
> device/devres.h
> ?
Hi Andy,
I have checked this out and it seems device.h doesn't actually need
to be included anyway since spi.h directly includes device.h, and since
this is a SPI driver that's never going away, it's covered. Will drop it!
Thanks,
Radu
^ permalink raw reply
* Re: [PATCH] scripts/dtc: Remove unused dts_version in dtc-lexer.l
From: Nathan Chancellor @ 2026-03-30 14:16 UTC (permalink / raw)
To: Rob Herring
Cc: Saravana Kannan, Nick Desaulniers, Bill Wendling, Justin Stitt,
devicetree, linux-kernel, llvm, stable
In-Reply-To: <CAL_Jsq+r6DvXMoJ+qPOLJvosrgbyOVjw8nn453wUi7bXQOZNog@mail.gmail.com>
On Mon, Mar 30, 2026 at 07:19:16AM -0500, Rob Herring wrote:
> On Fri, Mar 27, 2026 at 4:39 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > A recent strengthening of -Wunused-but-set-variable (enabled with -Wall)
> > in clang under a new subwarning, -Wunused-but-set-global, points out an
> > unused static global variable in dtc-lexer.lex.c (compiled from
> > dtc-lexer.l):
> >
> > scripts/dtc/dtc-lexer.lex.c:641:12: warning: variable 'dts_version' set but not used [-Wunused-but-set-global]
> > 641 | static int dts_version = 1;
> > | ^
> >
> > This variable has been unused since commit 658f29a51e98 ("of/flattree:
> > Update dtc to current mainline."). Remove it to clear up the warning.
> >
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> > ---
> > This is commit 53373d1 ("dtc: Remove unused dts_version in dtc-lexer.l")
> > in upstream dtc. I sent it separately to make it easier to backport to
> > stable, along with updating the warning and hash to match the kernel's
> > version.
> > ---
> > scripts/dtc/dtc-lexer.l | 3 ---
> > 1 file changed, 3 deletions(-)
>
> We don't take changes to dtc as we just sync with the upstream copy. I
> saw you already submitted this upstream, so I will do a sync to pull
> this in.
Fair enough. As I mentioned in the fold, I will need this in stable so I
figured having a separate patch would make that easier while not
impacting a future sync (since it is already there). I can just wait to
send this to stable directly until the sync lands in Linus's tree.
Cheers,
Nathan
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Bryan O'Donoghue @ 2026-03-30 14:11 UTC (permalink / raw)
To: johannes.goede, Dmitry Baryshkov
Cc: Loic Poulain, vladimir.zapolskiy, laurent.pinchart,
kieran.bingham, robh, krzk+dt, andersson, konradybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel, mchehab
In-Reply-To: <0330f63f-7137-4484-954a-fc0776a9b052@oss.qualcomm.com>
On 30/03/2026 14:46, johannes.goede@oss.qualcomm.com wrote:
>>> And then your CCMv1 or CCMv2 helper will get called with
>>> the matching parameter-data.
>> This leads to userspace having to know exact format for each hardware
>> version, which is not nice. At the very least it should be possible to
>> accept CCMv1 buffers and covert them to CCMv2 when required.
> Yes, but a new ISP may also have a different pipeline altogether
> with e.g. more then one preview/viewfinder output vs one viewfinder
> output for current hw, etc.
My scoping on HFI shows that the IQ structures between Kona and later
versions have pretty stable data-structures.
It might be worthwhile for the non-HFI version to implement those
structures.
I keep mentioning CDM. Its also possible to construct the buffer in the
format the CDM would require and hand that from user-space into the kernel.
That would save alot of overhead translating from one format to another.
That's another reason I bring up CDM again and again. We probably don't
want to fix to the wrong format for OPE, introduce the CDM and then find
we have to map from one format to another for large and complex data
over and over again for each frame or every N frames.
TBH I think the CDM should happen for this system and in that vein is
there any reason not to pack the data in the order the CDM will want ?
So probably in fact IQ structs are not the right thing for OPE+IFE.
---
bod
^ permalink raw reply
* Re: [PATCH v7 0/5] Add driver for EC found on Qualcomm reference devices
From: Rob Clark @ 2026-03-30 14:08 UTC (permalink / raw)
To: Anvesh Jain P
Cc: Akhil P Oommen, linux-arm-msm, devicetree, linux-kernel,
platform-driver-x86, Maya Matuszczyk, Krzysztof Kozlowski,
Dmitry Baryshkov, Konrad Dybcio, Abel Vesa, Gaurav Kohli,
Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, Randy Dunlap
In-Reply-To: <dcc83729-295b-4fb2-beab-bbea1daec7a2@oss.qualcomm.com>
On Sun, Mar 29, 2026 at 11:57 PM Anvesh Jain P
<anvesh.p@oss.qualcomm.com> wrote:
>
>
>
> On 3/29/2026 7:52 PM, Akhil P Oommen wrote:
> > On 3/27/2026 3:38 PM, Anvesh Jain P wrote:
> >> From: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
> >>
> >> Add Embedded controller driver support for Hamoa/Purwa/Glymur Qualcomm
> >> reference boards. It handles fan control, temperature sensors, access
> >> to EC state changes and supports reporting suspend entry/exit to the EC.
> >
> > Just a question, is it possible to force fan to run at full speed
> > constantly? That would be helpful to keep the passive cooling minimal
> > and get a more consistent results while doing performance profiling.
> >
> > I see that you are registering a cooling device in this series. So I
> > suppose we just need to update the cooling sysfs nodes.
> >
> > -Akhil
> >
>
> Hi Akhil,
>
> Yes, that is possible. The cooling device registered by this driver
> exposes the standard thermal sysfs interface. You can force the fan
> to full speed by writing the maximum cooling state directly:
>
> # Find the max state
> cat /sys/class/thermal/cooling_deviceX/max_state
>
> # Set to max state (force full speed)
> echo <max_state> > /sys/class/thermal/cooling_deviceX/cur_state
>
> Where X is the index of the cooling device corresponding to the EC fan.
Getting a bit off topic, but is there a good way to associated cooling
devices and thermal sensors to the GPU device? I could see that being
useful for nvtop (which currently supports shows GPU load and memory
metrics, but thermal metrics are missing for us)
BR,
-R
> --
> Best Regards,
> Anvesh
>
>
^ permalink raw reply
* Re: [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Dmitry Baryshkov @ 2026-03-30 14:04 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Richard Acayan, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Thara Gopinath, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-pm, devicetree
In-Reply-To: <1fcecede-16f0-4ce1-b76c-32f569cb5e41@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 03:50:12PM +0200, Konrad Dybcio wrote:
> On 3/30/26 12:59 PM, Dmitry Baryshkov wrote:
> > On Mon, Mar 30, 2026 at 12:32:29PM +0200, Konrad Dybcio wrote:
> >> On 3/29/26 12:44 PM, Dmitry Baryshkov wrote:
> >>> On Fri, Mar 27, 2026 at 09:40:40PM -0400, Richard Acayan wrote:
> >>>> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
> >>>> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
> >>>> the first 6 CPUs are in the little cluster and the next 2 are in the big
> >>>> cluster. Define the clusters in the match data and define the different
> >>>> cluster configuration for SDM670.
> >>>>
> >>>> Currently, this only supports 8 CPUs and tolerates linking to any CPU in
> >>>> the cluster.
> >>>>
> >>>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> >>>> ---
> >>>> drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
> >>>> 1 file changed, 56 insertions(+), 13 deletions(-)
> >>>>
> >>>> +static const struct lmh_soc_data sdm670_lmh_data = {
> >>>> + .enable_algos = true,
> >>>> + .node_ids = {
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + },
> >>>> +};
> >>>> +
> >>>> +static const struct lmh_soc_data sdm845_lmh_data = {
> >>>> + .enable_algos = true,
> >>>> + .node_ids = {
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + },
> >>>> +};
> >>>
> >>> These tables made me wonder, can we determine this information from the
> >>> DT? For example, by reading the qcom,freq-domain property. But...
> >>>
> >>>> +
> >>>> +static const struct lmh_soc_data sm8150_lmh_data = {
> >>>> + .enable_algos = false,
> >>>> + .node_ids = {
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER0_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + LMH_CLUSTER1_NODE_ID,
> >>>> + },
> >>>> +};
> >>>
> >>> ... this might be problematic, unless this entry is broken. On SM8150 we
> >>> have three freq domains, but up to now we were programming two clustern
> >>> nodes. Of course it is possible to define that node_id is 0 for freq
> >>> domain 0 and 1 for domains 1 and 2.
> >>
> >> The third cluster situation on 8150 is not super good - we e.g. only have
> >> a single LMH irq that's shared between the big and prime cores. That
> >> was fixed with later SoCs (which is why it's not wired up in the DT today)
> >
> > Thanks!
> >
> > Anyway, from your point of view, would it be better to define mappings
> > in the driver (like it's done with this patch) or parse the DT?
>
> Well, we can spend a lot of time trying to be smart about it and handle
> the odd edge case, or add a simple comparison!
:-)
Then let's go with your suggestion of 'first core from second cluster'.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: media: renesas,vsp1: Document RZ/G3L VSPD
From: Laurent Pinchart @ 2026-03-30 14:02 UTC (permalink / raw)
To: Biju
Cc: Kieran Bingham, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Biju Das, linux-media, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar Mahadev Lad
In-Reply-To: <20260330105637.130189-1-biju.das.jz@bp.renesas.com>
Hi Biju,
Thank you for the patch.
On Mon, Mar 30, 2026 at 11:56:29AM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The VSPD block on the RZ/G3L SoC is identical to the one found on the
> RZ/G2L SoC. Document RZ/G3L VSPD.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/media/renesas,vsp1.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> index 07a97dd87a5b..5447b9b78930 100644
> --- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> +++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
> @@ -25,6 +25,7 @@ properties:
> - enum:
> - renesas,r9a07g043u-vsp2 # RZ/G2UL
> - renesas,r9a07g054-vsp2 # RZ/V2L
> + - renesas,r9a08g046-vsp2 # RZ/G3L
> - renesas,r9a09g056-vsp2 # RZ/V2N
> - renesas,r9a09g057-vsp2 # RZ/V2H(P)
> - const: renesas,r9a07g044-vsp2 # RZ/G2L fallback
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] media: dt-bindings: media: renesas,fcp: Document RZ/G3L FCPVD IP
From: Laurent Pinchart @ 2026-03-30 14:01 UTC (permalink / raw)
To: Biju
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Biju Das,
linux-media, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad
In-Reply-To: <20260330110012.131273-1-biju.das.jz@bp.renesas.com>
Hi Biju,
Thank you for the patch.
On Mon, Mar 30, 2026 at 12:00:10PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The FCPVD block on the RZ/G3L SoC is identical to the one found on the
> RZ/G2L SoC. Document RZ/G3L FCPVD IP.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/media/renesas,fcp.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.yaml b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> index b5eff6fec8a9..86b176a634e1 100644
> --- a/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.yaml
> @@ -30,6 +30,7 @@ properties:
> - renesas,r9a07g043u-fcpvd # RZ/G2UL
> - renesas,r9a07g044-fcpvd # RZ/G2{L,LC}
> - renesas,r9a07g054-fcpvd # RZ/V2L
> + - renesas,r9a08g046-fcpvd # RZ/G3L
> - renesas,r9a09g056-fcpvd # RZ/V2N
> - renesas,r9a09g057-fcpvd # RZ/V2H(P)
> - const: renesas,fcpv # Generic FCP for VSP fallback
> @@ -77,6 +78,7 @@ allOf:
> - renesas,r9a07g043u-fcpvd
> - renesas,r9a07g044-fcpvd
> - renesas,r9a07g054-fcpvd
> + - renesas,r9a08g046-fcpvd
> - renesas,r9a09g056-fcpvd
> - renesas,r9a09g057-fcpvd
> then:
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] Add support for PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-03-30 13:59 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Charles Perry, netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiner Kallweit, Russell King, devicetree, linux-kernel
In-Reply-To: <20260327165158.505855eb@kernel.org>
On Fri, Mar 27, 2026 at 04:51:58PM -0700, Jakub Kicinski wrote:
> On Fri, 27 Mar 2026 05:34:32 -0700 Charles Perry wrote:
> > On Thu, Mar 26, 2026 at 08:33:09PM -0700, Jakub Kicinski wrote:
> > > On Mon, 23 Mar 2026 15:02:52 -0700 Charles Perry wrote:
> > > > .../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++
> > > > drivers/net/mdio/Kconfig | 7 +
> > > > drivers/net/mdio/Makefile | 1 +
> > > > drivers/net/mdio/mdio-pic64hpsc.c | 192 ++++++++++++++++++
> > >
> > > Speaking under correction from PHY maintainers but I think we need
> > > a MAINTAINERS entry that will cover Microchip MDIO, or at least the
> > > files you're adding. Important read:
> > > https://docs.kernel.org/next/maintainer/feature-and-driver-maintainers.html
> >
> > Sure, I think this should go under "RISC-V MICROCHIP SUPPORT" or maybe a
> > new "MICROCHIP PIC64-HPSC/HX DRIVER" entry if the former was meant only for
> > Polarfire SoC.
> >
> > I'll add something in v3.
>
> Thanks! FWIW I'd prefer the latter - smaller entries make the
> responsibility clear. Under a big arch entry the maintainers are
> usually seeing too many random patches to act. You can add
> _both_ dedicated a entry and add the files to RISC-V MICROCHIP,
> if you prefer, too.
Ok, thank you for the suggestion.
I'll go with "MICROCHIP PIC64-HPSC/HX DRIVERS" for all the small SoC
drivers (MDIO, GPIO, timers, etc.) and a separate entry for the big things
like RDMA or FRER hw accelerator, if we ever get there.
I won't add anything to RISC-V MICROCHIP SUPPORT even if PIC64-HPSC is
indeed a RISC-V chip since this entry is all Polarfire.
Thanks,
Charles
^ permalink raw reply
* Re: [PATCH v4 1/2] arm64: dts: qcom: talos: Add GPR node, audio services, and MI2S1 TLMM pins
From: Bjorn Andersson @ 2026-03-30 13:57 UTC (permalink / raw)
To: Le Qi
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, kernel, Konrad Dybcio
In-Reply-To: <20260324060405.3098891-2-le.qi@oss.qualcomm.com>
On Tue, Mar 24, 2026 at 02:04:04PM +0800, Le Qi wrote:
> This patch adds the Generic Pack Router (GPR) node together with
Please avoid phrases such as "This patch". Start your commit message
with a description of the problem or purpose of the patch.
> Audio Process Manager (APM) and Proxy Resource Manager (PRM)
> audio service nodes to the Talos device tree description.
>
> It also introduces MI2S1 pinctrl states for data0, data1, sck,
> and ws lines, grouped into a single entry at the SoC-level DTSI
> for better reuse and clarity.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/talos.dtsi | 54 +++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
> index f69a40fb8e28..cd451a112573 100644
> --- a/arch/arm64/boot/dts/qcom/talos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/talos.dtsi
> @@ -19,6 +19,7 @@
> #include <dt-bindings/power/qcom-rpmpd.h>
> #include <dt-bindings/power/qcom,rpmhpd.h>
> #include <dt-bindings/soc/qcom,rpmh-rsc.h>
> +#include <dt-bindings/soc/qcom,gpr.h>
Keep includes sorted alphabetically.
Regards,
Bjorn
>
> / {
> interrupt-parent = <&intc>;
> @@ -1553,6 +1554,20 @@ tlmm: pinctrl@3100000 {
> #interrupt-cells = <2>;
> wakeup-parent = <&pdc>;
>
> + mi2s1_pins: mi2s1-state {
> + pins = "gpio108", "gpio109", "gpio110", "gpio111";
> + function = "mi2s_1";
> + drive-strength = <8>;
> + bias-disable;
> + };
> +
> + mi2s_mclk: mi2s-mclk-state {
> + pins = "gpio122";
> + function = "mclk2";
> + drive-strength = <8>;
> + bias-disable;
> + };
> +
> qup_i2c1_data_clk: qup-i2c1-data-clk-state {
> pins = "gpio4", "gpio5";
> function = "qup0";
> @@ -4696,6 +4711,45 @@ compute-cb@6 {
> dma-coherent;
> };
> };
> +
> + gpr: gpr {
> + compatible = "qcom,gpr";
> + qcom,glink-channels = "adsp_apps";
> + qcom,domain = <GPR_DOMAIN_ID_ADSP>;
> + qcom,intents = <512 20>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + q6apm: service@1 {
> + compatible = "qcom,q6apm";
> + reg = <GPR_APM_MODULE_IID>;
> + #sound-dai-cells = <0>;
> + qcom,protection-domain = "avs/audio",
> + "msm/adsp/audio_pd";
> +
> + q6apmbedai: bedais {
> + compatible = "qcom,q6apm-lpass-dais";
> + #sound-dai-cells = <1>;
> + };
> +
> + q6apmdai: dais {
> + compatible = "qcom,q6apm-dais";
> + iommus = <&apps_smmu 0x1721 0x0>;
> + };
> + };
> +
> + q6prm: service@2 {
> + compatible = "qcom,q6prm";
> + reg = <GPR_PRM_MODULE_IID>;
> + qcom,protection-domain = "avs/audio",
> + "msm/adsp/audio_pd";
> +
> + q6prmcc: clock-controller {
> + compatible = "qcom,q6prm-lpass-clocks";
> + #clock-cells = <2>;
> + };
> + };
> + };
> };
> };
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v4 2/2] arm64: dts: qcom: talos-evk: Add sound card support with DA7212 codec
From: Bjorn Andersson @ 2026-03-30 13:53 UTC (permalink / raw)
To: Le Qi
Cc: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, kernel, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260324060405.3098891-3-le.qi@oss.qualcomm.com>
On Tue, Mar 24, 2026 at 02:04:05PM +0800, Le Qi wrote:
> Add the sound card node for QCS615 Talos EVK with DA7212 codec
> connected over the Primary MI2S interface. The configuration enables
> headphone playback and headset microphone capture, both of which have
> been tested to work.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Le Qi <le.qi@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/talos-evk.dts | 65 ++++++++++++++++++++++++++
There's no such file in the upstream tree. Please test on upstream and
resubmit once this is ready to be merged.
Regards,
Bjorn
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/talos-evk.dts b/arch/arm64/boot/dts/qcom/talos-evk.dts
> index af100e22beee..6352d614e288 100644
> --- a/arch/arm64/boot/dts/qcom/talos-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/talos-evk.dts
> @@ -5,6 +5,7 @@
> /dts-v1/;
>
> #include "talos-evk-som.dtsi"
> +#include <dt-bindings/sound/qcom,q6afe.h>
>
> / {
> model = "Qualcomm QCS615 IQ 615 EVK";
> @@ -40,6 +41,46 @@ hdmi_con_out: endpoint {
> };
> };
>
> + sound {
> + compatible = "qcom,qcs615-sndcard";
> + model = "TALOS-EVK";
> +
> + pinctrl-0 = <&mi2s1_pins>, <&mi2s_mclk>;
> + pinctrl-names = "default";
> +
> + pri-mi2s-capture-dai-link {
> + link-name = "Primary MI2S Capture";
> +
> + codec {
> + sound-dai = <&codec_da7212>;
> + };
> +
> + cpu {
> + sound-dai = <&q6apmbedai PRIMARY_MI2S_TX>;
> + };
> +
> + platform {
> + sound-dai = <&q6apm>;
> + };
> + };
> +
> + pri-mi2s-playback-dai-link {
> + link-name = "Primary MI2S Playback";
> +
> + codec {
> + sound-dai = <&codec_da7212>;
> + };
> +
> + cpu {
> + sound-dai = <&q6apmbedai PRIMARY_MI2S_RX>;
> + };
> +
> + platform {
> + sound-dai = <&q6apm>;
> + };
> + };
> + };
> +
> vreg_v1p8_out: regulator-v1p8-out {
> compatible = "regulator-fixed";
> regulator-name = "vreg-v1p8-out";
> @@ -109,6 +150,19 @@ adv7535_out: endpoint {
> };
> };
>
> +&i2c5 {
> + status = "okay";
> +
> + codec_da7212: codec@1a {
> + compatible = "dlg,da7212";
> + reg = <0x1a>;
> + #sound-dai-cells = <0>;
> + VDDA-supply = <&vreg_v1p8_out>;
> + VDDIO-supply = <&vreg_v1p8_out>;
> + VDDMIC-supply = <&vreg_v3p3_out>;
> + };
> +};
> +
> &mdss_dsi0_out {
> remote-endpoint = <&adv7535_in>;
> data-lanes = <0 1 2 3>;
> @@ -124,6 +178,17 @@ &pon_resin {
> status = "okay";
> };
>
> +&q6apmbedai {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dai@17 {
> + reg = <PRIMARY_MI2S_TX>;
> + clocks = <&q6prmcc LPASS_CLK_ID_MCLK_2 LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
> + clock-names = "mclk";
> + };
> +};
> +
> &sdhc_2 {
> pinctrl-0 = <&sdc2_state_on>;
> pinctrl-1 = <&sdc2_state_off>;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Konrad Dybcio @ 2026-03-30 13:50 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Richard Acayan, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Thara Gopinath, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-pm, devicetree
In-Reply-To: <lnumerwlyvmbdkwum64js46tbnvpxjrdrouhq3vybuwto4st3g@7xzr52e3samd>
On 3/30/26 12:59 PM, Dmitry Baryshkov wrote:
> On Mon, Mar 30, 2026 at 12:32:29PM +0200, Konrad Dybcio wrote:
>> On 3/29/26 12:44 PM, Dmitry Baryshkov wrote:
>>> On Fri, Mar 27, 2026 at 09:40:40PM -0400, Richard Acayan wrote:
>>>> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
>>>> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
>>>> the first 6 CPUs are in the little cluster and the next 2 are in the big
>>>> cluster. Define the clusters in the match data and define the different
>>>> cluster configuration for SDM670.
>>>>
>>>> Currently, this only supports 8 CPUs and tolerates linking to any CPU in
>>>> the cluster.
>>>>
>>>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
>>>> ---
>>>> drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
>>>> 1 file changed, 56 insertions(+), 13 deletions(-)
>>>>
>>>> +static const struct lmh_soc_data sdm670_lmh_data = {
>>>> + .enable_algos = true,
>>>> + .node_ids = {
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + },
>>>> +};
>>>> +
>>>> +static const struct lmh_soc_data sdm845_lmh_data = {
>>>> + .enable_algos = true,
>>>> + .node_ids = {
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + },
>>>> +};
>>>
>>> These tables made me wonder, can we determine this information from the
>>> DT? For example, by reading the qcom,freq-domain property. But...
>>>
>>>> +
>>>> +static const struct lmh_soc_data sm8150_lmh_data = {
>>>> + .enable_algos = false,
>>>> + .node_ids = {
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER0_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + LMH_CLUSTER1_NODE_ID,
>>>> + },
>>>> +};
>>>
>>> ... this might be problematic, unless this entry is broken. On SM8150 we
>>> have three freq domains, but up to now we were programming two clustern
>>> nodes. Of course it is possible to define that node_id is 0 for freq
>>> domain 0 and 1 for domains 1 and 2.
>>
>> The third cluster situation on 8150 is not super good - we e.g. only have
>> a single LMH irq that's shared between the big and prime cores. That
>> was fixed with later SoCs (which is why it's not wired up in the DT today)
>
> Thanks!
>
> Anyway, from your point of view, would it be better to define mappings
> in the driver (like it's done with this patch) or parse the DT?
Well, we can spend a lot of time trying to be smart about it and handle
the odd edge case, or add a simple comparison!
Konrad
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: johannes.goede @ 2026-03-30 13:46 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Loic Poulain, vladimir.zapolskiy,
laurent.pinchart, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <qq43xl3lsv2nq4ngn2hojleddxjmkgwclb2ajek5gvdtgyjltl@3tqg5ydhsxia>
Hi,
On 30-Mar-26 13:37, Dmitry Baryshkov wrote:
> On Thu, Mar 26, 2026 at 01:06:59PM +0100, johannes.goede@oss.qualcomm.com wrote:
>> Hi Dmitry,
>>
>> On 24-Mar-26 22:27, Dmitry Baryshkov wrote:
>>> On Tue, Mar 24, 2026 at 11:00:21AM +0000, Bryan O'Donoghue wrote:
>>>> On 23/03/2026 15:31, Loic Poulain wrote:
>>
>> <snip>
>>
>>>>> As far as I understand, CDM could also be implemented in a generic way
>>>>> within CAMSS, since other CAMSS blocks make use of CDM as well.
>>>>> This is something we should discuss further.
>>>> My concern is even conservatively if each module adds another 10 ? writes by
>>>> the time we get to denoising, sharpening, lens shade correction, those
>>>> writes could easily look more like 100.
>>>>
>>>> What user-space should submit is well documented data-structures which then
>>>> get translated into CDM buffers by the OPE and IFE for the various bits of
>>>> the pipeline.
>>>
>>> I hope here you have accent on the well-documented (ideally some kind of
>>> the vendor-independent ABI).
>>
>> The plan is to use the new extensible generic v4l2 ISP parameters
>> API for this:
>>
>> https://docs.kernel.org/6.19/driver-api/media/v4l2-isp.html
>>
>> What this does is basically divide the parameter buffer (which
>> is just a mmap-able bunch of bytes) into variable sized packets/
>> blocks with each block having a small header, with a type field.
>>
>> And then we can have say CCMv1 type for the CCM on the OPE and
>> if with some future hardware the format of the CCM (say different
>> fixpoint format) ever changes we can simply define a new CCMv2
>> and then the parameter buffer can be filled with different
>> versions of different parameter blocks depending on the hw.
>>
>> And on the kernel side there are helpers to parse this, you
>> simply pass a list of the types the current hw supports
>> + per type data-callback functions.
>>
>> And then your CCMv1 or CCMv2 helper will get called with
>> the matching parameter-data.
>
> This leads to userspace having to know exact format for each hardware
> version, which is not nice. At the very least it should be possible to
> accept CCMv1 buffers and covert them to CCMv2 when required.
Yes, but a new ISP may also have a different pipeline altogether
with e.g. more then one preview/viewfinder output vs one viewfinder
output for current hw, etc.
Or the raw-bayer hw-statistics format may change, which would also
require libcamera updates.
Generally speaking the development model for MIPI cameras with
hardware ISP with libcamera is that enabling new hardware will
require both kernel updates as well as libcamera updates.
ISPs are simply so complex that it has been decided that having
a unified API where old userspace will "just work" with newer
hw as long as the kernel has support for the new hw is simply
not realistically doable. There are too many possible topologies
tweakable parameters, etc.
And even if such a thing were possible (1) it would lead to an API
mostly limited to supporting some sort of shared lowest common
denominator feature set which is not what we want.
The purpose of the extensible generic v4l2 ISP parameters API is
to allow having a single kernel driver + API for multiple generations
of hardware-ISP, without breaking the userspace API for the older
generations. As well as having a single set of support code
for that supporting multiple generations on the libcamera side.
But once the kernel driver grows support for a new ISP generation
then it is expected for the libcamera counter part to also need
at least some updates to support the new generation.
Regards,
Hans
1) It might be possible if you throw a whole lot of manpower at
it ...
^ permalink raw reply
* [PATCH v2 11/11] ARM: dts: ti: omap4: Add pbias regulator to the HS USB Host
From: Thomas Richard @ 2026-03-30 13:44 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
In-Reply-To: <20260330-omap4-fix-usb-support-v2-0-1c1e11b190dc@bootlin.com>
On OMAP4 add the pbias SIM regulator to the OMAP HS USB Host.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
index 6904a84a1700..c5e097f9cd17 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
@@ -301,6 +301,7 @@ usbhshost: usbhshost@0 {
clock-names = "refclk_60m_int",
"refclk_60m_ext_p1",
"refclk_60m_ext_p2";
+ pbias-supply = <&pbias_sim_reg>;
usbhsohci: usb@800 {
compatible = "ti,ohci-omap3";
--
2.53.0
^ permalink raw reply related
* [PATCH v2 10/11] mfd: omap-usb-host: Add pbias regulator support
From: Thomas Richard @ 2026-03-30 13:44 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
In-Reply-To: <20260330-omap4-fix-usb-support-v2-0-1c1e11b190dc@bootlin.com>
Add pbias regulator support to enable SIM_VDDS supply and unlock USB I/O
cell. Previously, this was handled by the bootloader, now the kernel can
take responsibility for managing the PBIAS regulator, ensuring correct
operation regardless of the bootloader.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
drivers/mfd/omap-usb-host.c | 55 ++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 17a54f0087c3..907fb614d464 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -15,6 +15,8 @@
#include <linux/pm_runtime.h>
#include <linux/of.h>
#include <linux/of_platform.h>
+#include <linux/regulator/consumer.h>
+#include <linux/string_choices.h>
#include "omap-usb.h"
@@ -95,6 +97,8 @@ struct usbhs_hcd_omap {
struct usbhs_omap_platform_data *pdata;
u32 usbhs_rev;
+
+ struct regulator *pbias;
};
/*-------------------------------------------------------------------------*/
@@ -334,26 +338,60 @@ static int usbhs_clocks_enable(struct device *dev, bool enable)
return r;
}
+static int omap_usbhs_set_pbias(struct device *dev, bool power_on)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ int ret;
+
+ if (!omap->pbias)
+ return 0;
+
+ if (power_on)
+ ret = regulator_enable(omap->pbias);
+ else
+ ret = regulator_disable(omap->pbias);
+
+ if (ret)
+ dev_err(dev, "pbias reg %s failed\n", str_enable_disable(power_on));
+
+ return ret;
+}
+
static int usbhs_runtime_resume(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap->pdata;
+ int ret;
omap_tll_enable(pdata);
- return usbhs_clocks_enable(dev, true);
+ ret = usbhs_clocks_enable(dev, true);
+ if (ret)
+ return ret;
+
+ return omap_usbhs_set_pbias(dev, true);
}
static int usbhs_runtime_suspend(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap->pdata;
+ int ret;
usbhs_clocks_enable(dev, false);
omap_tll_disable(pdata);
+ ret = omap_usbhs_set_pbias(dev, false);
+ if (ret)
+ goto err;
+
return 0;
+
+err:
+ omap_tll_enable(pdata);
+ usbhs_clocks_enable(dev, true);
+ return ret;
}
static unsigned omap_usbhs_rev1_hostconfig(struct usbhs_hcd_omap *omap,
@@ -562,6 +600,15 @@ static int usbhs_omap_probe(struct platform_device *pdev)
omap->pdata = pdata;
+ omap->pbias = devm_regulator_get_optional(dev, "pbias");
+ if (IS_ERR(omap->pbias)) {
+ if (PTR_ERR(omap->pbias) == -ENODEV)
+ omap->pbias = NULL;
+ else
+ return dev_err_probe(dev, PTR_ERR(omap->pbias),
+ "unable to get pbias regulator\n");
+ }
+
/* Initialize the TLL subsystem */
omap_tll_init(pdata);
@@ -757,6 +804,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
}
initialize:
+ ret = omap_usbhs_set_pbias(dev, true);
+ if (ret)
+ goto err_mem;
+
omap_usbhs_init(dev);
if (dev->of_node) {
@@ -804,6 +855,8 @@ static void usbhs_omap_remove(struct platform_device *pdev)
of_platform_depopulate(&pdev->dev);
else
device_for_each_child(&pdev->dev, NULL, usbhs_omap_remove_child);
+
+ omap_usbhs_set_pbias(&pdev->dev, false);
}
static const struct dev_pm_ops usbhsomap_dev_pm_ops = {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 09/11] dt-bindings: mfd: ti,omap-usb-host: Add 'pbias-supply' property
From: Thomas Richard @ 2026-03-30 13:44 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
In-Reply-To: <20260330-omap4-fix-usb-support-v2-0-1c1e11b190dc@bootlin.com>
Add the 'pbias-supply' property, it is used to specify the voltage
regulator that provides the bias voltage for USB cell.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
index 3b5b041f0321..d0a61dec4961 100644
--- a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
@@ -83,6 +83,12 @@ properties:
ranges: true
+ pbias-supply:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ It is used to specify the voltage regulator that provides the bias
+ voltage for certain analog or I/O pads.
+
patternProperties:
"^port[0-3]-mode$":
$ref: /schemas/types.yaml#/definitions/string
--
2.53.0
^ permalink raw reply related
* [PATCH v2 08/11] dt-bindings: mfd: ti,omap-usb-host: Convert to DT schema
From: Thomas Richard @ 2026-03-30 13:44 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
In-Reply-To: <20260330-omap4-fix-usb-support-v2-0-1c1e11b190dc@bootlin.com>
Convert OMAP HS USB Host binding to DT schema. The 'ti,hwmods' property is
not mandatory anymore as it is no longer required when the omap-usb-host
node is a child of a new interconnect target (ti,sysc).
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 103 -------------
.../devicetree/bindings/mfd/ti,omap-usb-host.yaml | 161 +++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 162 insertions(+), 103 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
deleted file mode 100644
index a0d8c30c2631..000000000000
--- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+++ /dev/null
@@ -1,103 +0,0 @@
-OMAP HS USB Host
-
-Required properties:
-
-- compatible: should be "ti,usbhs-host"
-- reg: should contain one register range i.e. start and length
-- ti,hwmods: must contain "usb_host_hs"
-
-Optional properties:
-
-- num-ports: number of USB ports. Usually this is automatically detected
- from the IP's revision register but can be overridden by specifying
- this property. A maximum of 3 ports are supported at the moment.
-
-- portN-mode: String specifying the port mode for port N, where N can be
- from 1 to 3. If the port mode is not specified, that port is treated
- as unused. When specified, it must be one of the following.
- "ehci-phy",
- "ehci-tll",
- "ehci-hsic",
- "ohci-phy-6pin-datse0",
- "ohci-phy-6pin-dpdm",
- "ohci-phy-3pin-datse0",
- "ohci-phy-4pin-dpdm",
- "ohci-tll-6pin-datse0",
- "ohci-tll-6pin-dpdm",
- "ohci-tll-3pin-datse0",
- "ohci-tll-4pin-dpdm",
- "ohci-tll-2pin-datse0",
- "ohci-tll-2pin-dpdm",
-
-- single-ulpi-bypass: Must be present if the controller contains a single
- ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
-
-- clocks: a list of phandles and clock-specifier pairs, one for each entry in
- clock-names.
-
-- clock-names: should include:
- For OMAP3
- * "usbhost_120m_fck" - 120MHz Functional clock.
-
- For OMAP4+
- * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux
- * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux.
- * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux
- * "utmi_p1_gfclk" - Port 1 UTMI clock mux.
- * "utmi_p2_gfclk" - Port 2 UTMI clock mux.
- * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate.
- * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate.
- * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate.
- * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate.
- * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate.
- * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate.
- * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate.
- * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate.
- * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate.
-
-Required properties if child node exists:
-
-- #address-cells: Must be 1
-- #size-cells: Must be 1
-- ranges: must be present
-
-Properties for children:
-
-The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
-See Documentation/devicetree/bindings/usb/generic-ehci.yaml and
-Documentation/devicetree/bindings/usb/generic-ohci.yaml.
-
-Example for OMAP4:
-
-usbhshost: usbhshost@4a064000 {
- compatible = "ti,usbhs-host";
- reg = <0x4a064000 0x800>;
- ti,hwmods = "usb_host_hs";
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3";
- reg = <0x4a064800 0x400>;
- interrupt-parent = <&gic>;
- interrupts = <0 76 0x4>;
- };
-
- usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap";
- reg = <0x4a064c00 0x400>;
- interrupt-parent = <&gic>;
- interrupts = <0 77 0x4>;
- };
-};
-
-&usbhshost {
- port1-mode = "ehci-phy";
- port2-mode = "ehci-tll";
- port3-mode = "ehci-phy";
-};
-
-&usbhsehci {
- phys = <&hsusb1_phy 0 &hsusb3_phy>;
-};
diff --git a/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
new file mode 100644
index 000000000000..3b5b041f0321
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
@@ -0,0 +1,161 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ti,omap-usb-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP HS USB Host
+
+maintainers:
+ - Thomas Richard <thomas.richard@bootlin.com>
+
+properties:
+ compatible:
+ const: ti,usbhs-host
+
+ reg:
+ maxItems: 1
+
+ ti,hwmods:
+ const: usb_host_hs
+
+ num-ports:
+ description:
+ number of USB ports. Usually this is automatically detected from the IP's
+ revision register but can be overridden by specifying this property. A
+ maximum of 3 ports are supported at the moment.
+ maximum: 3
+
+ single-ulpi-bypass:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Must be present if the controller contains a single ULPI bypass control
+ bit. e.g. OMAP3 silicon <= ES2.1ULPI bypass control bit.
+ e.g. OMAP3 silicon <= ES2.1.
+
+ clocks:
+ description: clock-specifier
+
+ clock-names:
+ oneOf:
+ - items:
+ - const: usbhost_120m_fck
+ - items:
+ - const: refclk_60m_int
+ - const: refclk_60m_ext_p1
+ - const: refclk_60m_ext_p2
+ - items:
+ - const: refclk_60m_int
+ - const: refclk_60m_ext_p1
+ - const: refclk_60m_ext_p2
+ - const: usb_host_hs_utmi_p1_clk
+ - const: usb_host_hs_hsic480m_p1_clk
+ - const: usb_host_hs_hsic60m_p1_clk
+ - items:
+ - const: refclk_60m_int
+ - const: refclk_60m_ext_p1
+ - const: refclk_60m_ext_p2
+ - const: usb_host_hs_utmi_p1_clk
+ - const: usb_host_hs_hsic480m_p1_clk
+ - const: usb_host_hs_hsic60m_p1_clk
+ - const: usb_host_hs_utmi_p2_clk
+ - const: usb_host_hs_hsic480m_p2_clk
+ - const: usb_host_hs_hsic60m_p2_clk
+ - items:
+ - const: refclk_60m_int
+ - const: refclk_60m_ext_p1
+ - const: refclk_60m_ext_p2
+ - const: usb_host_hs_utmi_p1_clk
+ - const: usb_host_hs_hsic480m_p1_clk
+ - const: usb_host_hs_hsic60m_p1_clk
+ - const: usb_host_hs_utmi_p2_clk
+ - const: usb_host_hs_hsic480m_p2_clk
+ - const: usb_host_hs_hsic60m_p2_clk
+ - const: usb_host_hs_utmi_p3_clk
+ - const: usb_host_hs_hsic480m_p3_clk
+ - const: usb_host_hs_hsic60m_p3_clk
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ ranges: true
+
+patternProperties:
+ "^port[0-3]-mode$":
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ String specifying the port mode for port N, where N can be from 1 to 3.
+ the port mode is not specified, that port is treated as unused. When
+ specified, it must be one of the following.
+ enum:
+ - ehci-phy
+ - ehci-tll
+ - ehci-hsic
+ - ohci-phy-6pin-datse0
+ - ohci-phy-6pin-dpdm
+ - ohci-phy-3pin-datse0
+ - ohci-phy-4pin-dpdm
+ - ohci-tll-6pin-datse0
+ - ohci-tll-6pin-dpdm
+ - ohci-tll-3pin-datse0
+ - ohci-tll-4pin-dpdm
+ - ohci-tll-2pin-datse0
+ - ohci-tll-2pin-dpdm
+
+ "^usb@":
+ type: object
+ oneOf:
+ - $ref: /schemas/usb/generic-ohci.yaml#
+ - $ref: /schemas/usb/generic-ehci.yaml#
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - if:
+ patternProperties:
+ "^usb@": true
+ then:
+ required:
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = "ti,usbhs-host";
+ reg = <0x4a064000 0x800>;
+ ti,hwmods = "usb_host_hs";
+ port1-mode = "ehci-phy";
+ port2-mode = "ehci-tll";
+ port3-mode = "ehci-phy";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ usbhsohci: usb@4a064800 {
+ compatible = "ti,ohci-omap3";
+ reg = <0x4a064800 0x400>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 76 0x4>;
+ };
+
+ usbhsehci: usb@4a064c00 {
+ compatible = "ti,ehci-omap";
+ reg = <0x4a064c00 0x400>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 77 0x4>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 15052c0f5377..d1dadba8ed0a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19406,6 +19406,7 @@ W: http://linux.omap.com/
Q: http://patchwork.kernel.org/project/linux-omap/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
F: Documentation/devicetree/bindings/arm/ti/omap.yaml
+F: Documentation/devicetree/bindings/mfd/ti,omap-usb-host.yaml
F: Documentation/devicetree/bindings/regulator/ti,pbias-regulator.yaml
F: arch/arm/configs/omap2plus_defconfig
F: arch/arm/mach-omap2/
--
2.53.0
^ permalink raw reply related
* [PATCH v2 07/11] mfd: omap-usb-host: Refactor suspend and resume callbacks
From: Thomas Richard @ 2026-03-30 13:44 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones
Cc: Thomas Petazzoni, linux-omap, linux-kernel, devicetree,
Thomas Richard
In-Reply-To: <20260330-omap4-fix-usb-support-v2-0-1c1e11b190dc@bootlin.com>
The clock handling logic in suspend and resume callbacks is very similar.
Create a new usbhs_clocks_enable() function to avoid code duplication.
Also remove ftrace-like debug messages.
Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
---
drivers/mfd/omap-usb-host.c | 94 ++++++++++++++++++++++-----------------------
1 file changed, 46 insertions(+), 48 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index ac974285be34..17a54f0087c3 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -270,48 +270,56 @@ static bool is_ohci_port(enum usbhs_omap_port_mode pmode)
}
}
-static int usbhs_runtime_resume(struct device *dev)
+static int usbhs_clocks_enable(struct device *dev, bool enable)
{
- struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = omap->pdata;
- int i, r;
-
- dev_dbg(dev, "usbhs_runtime_resume\n");
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ struct usbhs_omap_platform_data *pdata = omap->pdata;
+ int r = 0, i;
- omap_tll_enable(pdata);
-
- if (!IS_ERR(omap->ehci_logic_fck))
- clk_prepare_enable(omap->ehci_logic_fck);
+ if (!enable && !IS_ERR(omap->ehci_logic_fck))
+ clk_disable_unprepare(omap->ehci_logic_fck);
for (i = 0; i < omap->nports; i++) {
switch (pdata->port_mode[i]) {
case OMAP_EHCI_PORT_MODE_HSIC:
if (!IS_ERR(omap->hsic60m_clk[i])) {
- r = clk_prepare_enable(omap->hsic60m_clk[i]);
- if (r) {
- dev_err(dev,
- "Can't enable port %d hsic60m clk:%d\n",
- i, r);
+ if (enable) {
+ r = clk_prepare_enable(omap->hsic60m_clk[i]);
+ if (r) {
+ dev_err(dev,
+ "Can't enable port %d hsic60m clk:%d\n",
+ i, r);
+ }
+ } else {
+ clk_disable_unprepare(omap->hsic60m_clk[i]);
}
}
if (!IS_ERR(omap->hsic480m_clk[i])) {
- r = clk_prepare_enable(omap->hsic480m_clk[i]);
- if (r) {
- dev_err(dev,
- "Can't enable port %d hsic480m clk:%d\n",
- i, r);
+ if (enable) {
+ r = clk_prepare_enable(omap->hsic480m_clk[i]);
+ if (r) {
+ dev_err(dev,
+ "Can't enable port %d hsic480m clk:%d\n",
+ i, r);
+ }
+ } else {
+ clk_disable_unprepare(omap->hsic480m_clk[i]);
}
}
fallthrough; /* as HSIC mode needs utmi_clk */
case OMAP_EHCI_PORT_MODE_TLL:
if (!IS_ERR(omap->utmi_clk[i])) {
- r = clk_prepare_enable(omap->utmi_clk[i]);
- if (r) {
- dev_err(dev,
- "Can't enable port %d clk : %d\n",
- i, r);
+ if (enable) {
+ r = clk_prepare_enable(omap->utmi_clk[i]);
+ if (r) {
+ dev_err(dev,
+ "Can't enable port %d clk : %d\n",
+ i, r);
+ }
+ } else {
+ clk_disable_unprepare(omap->utmi_clk[i]);
}
}
break;
@@ -320,38 +328,28 @@ static int usbhs_runtime_resume(struct device *dev)
}
}
- return 0;
+ if (enable && !IS_ERR(omap->ehci_logic_fck))
+ r = clk_prepare_enable(omap->ehci_logic_fck);
+
+ return r;
}
-static int usbhs_runtime_suspend(struct device *dev)
+static int usbhs_runtime_resume(struct device *dev)
{
struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
struct usbhs_omap_platform_data *pdata = omap->pdata;
- int i;
- dev_dbg(dev, "usbhs_runtime_suspend\n");
-
- for (i = 0; i < omap->nports; i++) {
- switch (pdata->port_mode[i]) {
- case OMAP_EHCI_PORT_MODE_HSIC:
- if (!IS_ERR(omap->hsic60m_clk[i]))
- clk_disable_unprepare(omap->hsic60m_clk[i]);
+ omap_tll_enable(pdata);
- if (!IS_ERR(omap->hsic480m_clk[i]))
- clk_disable_unprepare(omap->hsic480m_clk[i]);
- fallthrough; /* as utmi_clks were used in HSIC mode */
+ return usbhs_clocks_enable(dev, true);
+}
- case OMAP_EHCI_PORT_MODE_TLL:
- if (!IS_ERR(omap->utmi_clk[i]))
- clk_disable_unprepare(omap->utmi_clk[i]);
- break;
- default:
- break;
- }
- }
+static int usbhs_runtime_suspend(struct device *dev)
+{
+ struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
+ struct usbhs_omap_platform_data *pdata = omap->pdata;
- if (!IS_ERR(omap->ehci_logic_fck))
- clk_disable_unprepare(omap->ehci_logic_fck);
+ usbhs_clocks_enable(dev, false);
omap_tll_disable(pdata);
--
2.53.0
^ permalink raw reply related
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