* Re: [PATCH v2 4/8] clk: qcom: videocc: Add video clock controller driver for Eliza
From: Taniya Das @ 2026-04-10 5:46 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Konrad Dybcio
In-Reply-To: <c7706c41-d855-4ed4-92c4-dca43c8f6d2a@oss.qualcomm.com>
On 4/10/2026 10:18 AM, Jie Gan wrote:
>> + depends on ARM64 || COMPILE_TEST
>> + select CLK_GLYMUR_GCC
>
> Hi,
>
> My bot found a [BUG] here, please ignore it if it's a false positive issue.
>
> CLK_ELIZA_VIDEOCC selects CLK_GLYMUR_GCC instead of CLK_ELIZA_GCC
>
> - select CLK_GLYMUR_GCC pulls in gcc-glymur.c instead of gcc-eliza.c
> - On an Eliza system, gcc-glymur.c will never probe (no matching DTS
> node), so GCC_VIDEO_AHB_CLK from the Eliza GCC will never be available
> to videocc
> - The videocc driver's clocks = <&gcc GCC_VIDEO_AHB_CLK> will fail to
> resolve at runtime
> - The correct fix is select CLK_ELIZA_GCC, consistent with all other
> Eliza clock controllers
>
Thanks, Jie for pointing out, will fix this.
GCC of ELIZA is already 'y' and Video driver probes as this
GCC_VIDEO_AHB_CLK is kept enabled/critical.
Please find the 'clk_summary' from device.
bi-tcxo-div2-clk 1 1 0 19200000
0 0 50000 Y deviceless
no_connection_id
video_cc_xo_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
video_cc_mvs0_shift_clk 0 0 0 19200000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0c_shift_clk 0 0 0 19200000
0 0 50000 N deviceless
no_connection_id
video_cc_pll0 0 0 0 576000000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
video_cc_mvs0c_div2_div_clk_src 0 0 0
9600000 0 0 50000 Y deviceless
no_connection_id
video_cc_mvs0c_clk 0 0 0 9600000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0_div_clk_src 0 0 0 6400000
0 0 50000 Y deviceless
no_connection_id
video_cc_mvs0_clk 0 0 0 6400000
0 0 50000 N deviceless
no_connection_id
video_cc_ahb_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v2] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Karthik S @ 2026-04-10 5:40 UTC (permalink / raw)
To: Mark Brown
Cc: Srinivas Kandagatla, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
linux-sound, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <fea78031-e570-4348-a4b3-d113b5749fec@sirena.org.uk>
Hi @Mark ,
On the indus mezz skew, The codec rails are distributed through fixed
Vdd (3.3V supply). These rails are Board‑controlled , not switched by
the codec and not power‑cycled dynamically. There is no per‑codec
enable/disable control exposed to software.The codec is wired to rails
that are always powered when the board is powered. Hence this justifies
it being handled as a board dt property.
On 4/2/2026 4:53 PM, Mark Brown wrote:
> On Thu, Apr 02, 2026 at 12:52:56PM +0530, karthik.s wrote:
>> Add has_always_on_supplies for managing regulators. Indicates that the
>> codec power supplies are provided by the board as always-on rails and
>> are not switchable by the codec or its associated regulators. This implies
>> that the codec supply regulators are always enabled by the system and
>> must not be requested or enabled by the codec driver.
> Same issue, why would we want this?
Thanks and regards,
Karthik S
^ permalink raw reply
* Re: [PATCH v1] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Karthik S @ 2026-04-10 5:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <4d08f16e-856a-46ae-8a41-334ec4d32952@kernel.org>
Hi @Krzysztof,
On 4/2/2026 12:43 PM, Krzysztof Kozlowski wrote:
> On 02/04/2026 09:08, karthik.s wrote:
>> Add has_always_on_supplies for managing regulators. Indicates that
>> the codec supply regulators are always enabled by the system and
>> must not be requested or enabled by the codec driver.
>>
>> Signed-off-by: karthik.s<karthik.s@oss.qualcomm.com>
> Please configure your Git.
>
I have configured Git as you suggested :
user.name = Karthik S
user.email = karthik.s@oss.qualcomm.com
>> ---
>> .../devicetree/bindings/sound/qcom,wcd937x.yaml | 6 ++++++
>> sound/soc/codecs/wcd937x.c | 13 +++++++++----
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
>
I have run the scripts/checkpatch.pl and fixed all warnings/errors
indicated.
>> 2 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
>> index f94203798f24..d89fff1f7171 100644
>> --- a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
>> +++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
>> @@ -28,6 +28,12 @@ properties:
>> vdd-px-supply:
>> description: A reference to the 1.8V I/O supply
>>
>> + qcom,always-on-supply:
> You described the desired Linux feature or behavior, not the actual
> hardware. The bindings are about the latter, so instead you need to
> rephrase the property and its description to match actual hardware
> capabilities/features/configuration etc.
Current description in dt-binding:
Indicates that the codec supply regulators are always enabled by the
system and must not be requested or enabled by the codec driver.
new description in dt-binding:
implies that the codec supply Vdd is on always on rails off the
board/hardware and must not be requested or enabled by the codec driver.
please let us know if you are okay with above changes
Thanks and Regards,
Karthik S
^ permalink raw reply
* Re: [PATCH v2 04/13] i3c: master: Support ACPI enumeration of child devices
From: Akhil R @ 2026-04-10 5:31 UTC (permalink / raw)
To: frank.li
Cc: acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robh, sakari.ailus, wsa+renesas
In-Reply-To: <adhdsn6u4RAIL9wC@lizhi-Precision-Tower-5810>
On Thu, 9 Apr 2026 22:17:22 -0400, Frank Li wrote:
> On Thu, Apr 09, 2026 at 04:27:34PM +0530, Akhil R wrote:
>> Although the existing subsystem allows host controllers to register
>> through the ACPI table, it was not possible to describe I3C or I2C
>> devices when using ACPI. This is because the driver relied on reg
>> property to retrieve the PID, static address etc whereas ACPI uses
>> _ADR or serial resources to describe such devices.
>>
>> Read _ADR and LVR from the ACPI resources and extract the data as per the
>> ACPI specification for an I3C bus. Also read mipi-i3c-static-address as
>> per the MIPI DISCO specifications [1] to get the static address to be
>> used. Hence enable describing the I3C or I2C devices in the ACPI
>> table, which is required if the device is using a static address or if it
>> needs some specific properties to be attached to it.
>
> Please wrap your commit message at 75 char.
Ack. Will do.
>
>>
>> [1] https://www.mipi.org/mipi-disco-for-i3c-download
>>
>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> ---
>> drivers/i3c/master.c | 140 ++++++++++++++++++++++++++++++++++++++++---
>> 1 file changed, 132 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
>> index 5e0e926f61f3..08d0fcabd6f1 100644
>> --- a/drivers/i3c/master.c
>> +++ b/drivers/i3c/master.c
>> @@ -5,6 +5,7 @@
>> * Author: Boris Brezillon <boris.brezillon@bootlin.com>
>> */
>>
>> +#include <linux/acpi.h>
>> #include <linux/atomic.h>
>> #include <linux/bug.h>
>> #include <linux/device.h>
>> @@ -2403,6 +2404,53 @@ EXPORT_SYMBOL_GPL(i3c_master_add_i3c_dev_locked);
>>
>> #define OF_I3C_REG1_IS_I2C_DEV BIT(31)
>>
>> +#ifdef CONFIG_ACPI
> ...
>
>> +#ifdef CONFIG_ACPI
>> +static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
>> + struct fwnode_handle *fwnode)
>
>
> Can you move this and below function to previous #ifdef CONFIG_ACPI block.
Ack. I will update, but there are some cross-dependencies. We may have to
add a few function prototypes with the headers if we have to move these
under the same block. Hope that is fine.
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v2 3/4] staging: iio: magnetometer: Add QST QMC5883P driver
From: Greg Kroah-Hartman @ 2026-04-10 5:28 UTC (permalink / raw)
To: Hardik Phalet
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brigham Campbell,
Shuah Khan, linux-iio, devicetree, linux-kernel, linux-staging
In-Reply-To: <20260409210639.3197576-4-hardik.phalet@pm.me>
On Thu, Apr 09, 2026 at 09:07:41PM +0000, Hardik Phalet wrote:
> Add an IIO driver for the QST QMC5883P, a 3-axis anisotropic
> magneto-resistive (AMR) magnetometer with a 16-bit ADC, communicating
> over I2C. There is no existing upstream driver for this device.
Sorry, but no new iio drivers should be added to staging. Take the time
to do it right and put it into drivers/iio/ from the beginning.
Otherwise this will just take more time and effort to get it into that
location in the end (i.e. doing it right is simpler/faster.)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Kuldeep Singh @ 2026-04-10 5:21 UTC (permalink / raw)
To: Harshal Dev, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Abel Vesa, Manivannan Sadhasivam, cros-qcom-dts-watchers,
Eric Biggers, Dmitry Baryshkov, Jingyi Wang, Tengfei Fan,
Bartosz Golaszewski, David Wronek, Luca Weiss, Neil Armstrong,
Melody Olvera, Alexander Koskovich, Rob Herring
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <36b4fead-81fe-4b98-9de5-4d524f199569@oss.qualcomm.com>
On 4/7/2026 10:28 AM, Kuldeep Singh wrote:
>>> Hi Krzysztof,
>>>
>>> As motive here is to enforce 2 clocks for upcoming targets and keep
>>> minItems as 1 for already merged ones for ensuring backward
>>> compatibility. Can we do like below?
>>>
>>> allOf:
>>> - if:
>>> not:
>>> properties:
>>> compatible:
>>> contains:
>>> enum:
>>> - qcom,kaanapali-inline-crypto-engine
>>> - qcom,qcs8300-inline-crypto-engine
>>> - qcom,sa8775p-inline-crypto-engine
>>> - qcom,sc7180-inline-crypto-engine
>>> - qcom,sc7280-inline-crypto-engine
>>> - qcom,sm8450-inline-crypto-engine
>>> - qcom,sm8550-inline-crypto-engine
>>> - qcom,sm8650-inline-crypto-engine
>>> - qcom,sm8750-inline-crypto-engine
>>>
>>> then:
>>> required:
>>> - power-domains
>>> - clock-names
>>> properties:
>>> clocks:
>>> minItems: 2
>>> clock-names:
>>> minItems: 2
>>>
>>> This will ensure for every new target addition, default clock count is
>>> enforced as 2 default.
>>> Please share your thoughts as well.
>
> Hi Rob/Krzysztof,
>
> Were you able to review this suggestion?
> Please let me know if need to update patch on top of this one to
> initiate discussion.
>
> One advantage i see with suggested approach:
> For new target addition, just need to document new compatible string and
> no need to update another list everytime.
> It's easy to miss adding entry alongside eliza/milos and might make
> wrong assumption to authors/dt-checker that 1 clock is still allowed.
>
Hi Krzysztof/Rob,
Kind reminder!
Could you please share your thoughts.
--
Regards
Kuldeep
^ permalink raw reply
* RE: [PATCH v6 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Torreno, Alexis Czezar @ 2026-04-10 4:59 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, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <adh_c1GG17zCbBdu@ashevche-desk.local>
>
> On Fri, Apr 10, 2026 at 09:33:56AM +0800, Alexis Czezar Torreno wrote:
> > Add support for the Analog Devices AD5706R, a 4-channel 16-bit current
> > output digital-to-analog converter with SPI interface.
> >
> > Features:
> > - 4 independent DAC channels
> > - Hardware and software LDAC trigger
> > - Configurable output range
> > - PWM-based LDAC control
> > - Dither and toggle modes
> > - Dynamically configurable SPI speed
>
> Still the same issue...
> After addressing it in full feel free to add
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
>
> ...
>
> > +static int ad5706r_regmap_write(void *context, const void *data,
> > +size_t count) {
> > + struct ad5706r_state *st = context;
> > + unsigned int num_bytes, val;
> > + u16 reg;
>
> > + reg = get_unaligned_be16(data);
>
> But this has the similar issue... Validation has to be done before the access.
> (also theoretically possible to have count 0, so even for byte access we have to
> validate the input, strictly speaking)
>
Will move the validation before the "reg = get_unaligned_be16(data);"
I'll also add the validation to regmap_read for the same reason it accesses
void* reg_buf
will send a v7 with your review tag, thanks!
^ permalink raw reply
* Re: [PATCH v2 4/8] clk: qcom: videocc: Add video clock controller driver for Eliza
From: Jie Gan @ 2026-04-10 4:48 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Konrad Dybcio
In-Reply-To: <20260409-eliza_mm_cc_v2-v2-4-bc0c6dd77bc5@oss.qualcomm.com>
On 4/10/2026 2:10 AM, Taniya Das wrote:
> Add support for the video clock controller for video clients to be able
> to request for videocc clocks on Eliza platform.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 9 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/videocc-eliza.c | 403 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 413 insertions(+)
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 22eb80be60ad3bde897f2c507ac9897951fbb8fe..4b0d40a38a6328fe9c41ebb15ae6821012223920 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -45,6 +45,15 @@ config CLK_ELIZA_TCSRCC
> Support for the TCSR clock controller on Eliza devices.
> Say Y if you want to use peripheral devices such as USB/PCIe/UFS.
>
> +config CLK_ELIZA_VIDEOCC
> + tristate "Eliza Video Clock Controller"
> + depends on ARM64 || COMPILE_TEST
> + select CLK_GLYMUR_GCC
Hi,
My bot found a [BUG] here, please ignore it if it's a false positive issue.
CLK_ELIZA_VIDEOCC selects CLK_GLYMUR_GCC instead of CLK_ELIZA_GCC
- select CLK_GLYMUR_GCC pulls in gcc-glymur.c instead of gcc-eliza.c
- On an Eliza system, gcc-glymur.c will never probe (no matching DTS
node), so GCC_VIDEO_AHB_CLK from the Eliza GCC will never be available
to videocc
- The videocc driver's clocks = <&gcc GCC_VIDEO_AHB_CLK> will fail to
resolve at runtime
- The correct fix is select CLK_ELIZA_GCC, consistent with all other
Eliza clock controllers
Thanks,
Jie
> + help
> + Support for the video clock controller on Eliza devices.
> + Say Y if you want to support video devices and functionality such as
> + video encode and decode.
> +
> config CLK_GLYMUR_DISPCC
> tristate "Glymur Display Clock Controller"
> depends on ARM64 || COMPILE_TEST
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index b818fd5af8bfb85a51ee90fdc3baa93af30dc39a..e7e239c5a0d088b2e78354bf421d871a4e4e6d9d 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
> obj-$(CONFIG_CLK_ELIZA_DISPCC) += dispcc-eliza.o
> obj-$(CONFIG_CLK_ELIZA_GCC) += gcc-eliza.o
> obj-$(CONFIG_CLK_ELIZA_TCSRCC) += tcsrcc-eliza.o
> +obj-$(CONFIG_CLK_ELIZA_VIDEOCC) += videocc-eliza.o
> obj-$(CONFIG_CLK_GFM_LPASS_SM8250) += lpass-gfm-sm8250.o
> obj-$(CONFIG_CLK_GLYMUR_DISPCC) += dispcc-glymur.o
> obj-$(CONFIG_CLK_GLYMUR_GCC) += gcc-glymur.o
> diff --git a/drivers/clk/qcom/videocc-eliza.c b/drivers/clk/qcom/videocc-eliza.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..cb541cfec50c12761251a822e32094e763922cdb
> --- /dev/null
> +++ b/drivers/clk/qcom/videocc-eliza.c
> @@ -0,0 +1,403 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +#include <dt-bindings/clock/qcom,eliza-videocc.h>
> +
> +#include "clk-alpha-pll.h"
> +#include "clk-branch.h"
> +#include "clk-pll.h"
> +#include "clk-rcg.h"
> +#include "clk-regmap.h"
> +#include "clk-regmap-divider.h"
> +#include "clk-regmap-mux.h"
> +#include "common.h"
> +#include "gdsc.h"
> +#include "reset.h"
> +
> +enum {
> + DT_BI_TCXO,
> + DT_SLEEP_CLK,
> + DT_AHB_CLK,
> +};
> +
> +enum {
> + P_BI_TCXO,
> + P_SLEEP_CLK,
> + P_VIDEO_CC_PLL0_OUT_MAIN,
> +};
> +
> +static const struct pll_vco lucid_ole_vco[] = {
> + { 249600000, 2300000000, 0 },
> +};
> +
> +/* 576.0 MHz Configuration */
> +static const struct alpha_pll_config video_cc_pll0_config = {
> + .l = 0x1e,
> + .alpha = 0x0,
> + .config_ctl_val = 0x20485699,
> + .config_ctl_hi_val = 0x00182261,
> + .config_ctl_hi1_val = 0x82aa299c,
> + .test_ctl_val = 0x00000000,
> + .test_ctl_hi_val = 0x00000003,
> + .test_ctl_hi1_val = 0x00009000,
> + .test_ctl_hi2_val = 0x00000034,
> + .user_ctl_val = 0x00000000,
> + .user_ctl_hi_val = 0x00000005,
> +};
> +
> +static struct clk_alpha_pll video_cc_pll0 = {
> + .offset = 0x0,
> + .config = &video_cc_pll0_config,
> + .vco_table = lucid_ole_vco,
> + .num_vco = ARRAY_SIZE(lucid_ole_vco),
> + .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID_OLE],
> + .clkr = {
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_pll0",
> + .parent_data = &(const struct clk_parent_data) {
> + .index = DT_BI_TCXO,
> + },
> + .num_parents = 1,
> + .ops = &clk_alpha_pll_lucid_evo_ops,
> + },
> + },
> +};
> +
> +static const struct parent_map video_cc_parent_map_0[] = {
> + { P_BI_TCXO, 0 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_0[] = {
> + { .index = DT_BI_TCXO },
> +};
> +
> +static const struct parent_map video_cc_parent_map_1[] = {
> + { P_BI_TCXO, 0 },
> + { P_VIDEO_CC_PLL0_OUT_MAIN, 1 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_1[] = {
> + { .index = DT_BI_TCXO },
> + { .hw = &video_cc_pll0.clkr.hw },
> +};
> +
> +static const struct parent_map video_cc_parent_map_2[] = {
> + { P_SLEEP_CLK, 0 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_2[] = {
> + { .index = DT_SLEEP_CLK },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_ahb_clk_src[] = {
> + F(19200000, P_BI_TCXO, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_ahb_clk_src = {
> + .cmd_rcgr = 0x8018,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_0,
> + .freq_tbl = ftbl_video_cc_ahb_clk_src,
> + .hw_clk_ctrl = true,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_ahb_clk_src",
> + .parent_data = video_cc_parent_data_0,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_0),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_mvs0_clk_src[] = {
> + F(576000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(633000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(720000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1014000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1098000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1113000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1332000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1600000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_mvs0_clk_src = {
> + .cmd_rcgr = 0x8000,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_1,
> + .freq_tbl = ftbl_video_cc_mvs0_clk_src,
> + .hw_clk_ctrl = true,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_clk_src",
> + .parent_data = video_cc_parent_data_1,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_1),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_sleep_clk_src[] = {
> + F(32000, P_SLEEP_CLK, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_sleep_clk_src = {
> + .cmd_rcgr = 0x8110,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_2,
> + .freq_tbl = ftbl_video_cc_sleep_clk_src,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_sleep_clk_src",
> + .parent_data = video_cc_parent_data_2,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_2),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static struct clk_rcg2 video_cc_xo_clk_src = {
> + .cmd_rcgr = 0x80f4,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_0,
> + .freq_tbl = ftbl_video_cc_ahb_clk_src,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_xo_clk_src",
> + .parent_data = video_cc_parent_data_0,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_0),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static struct clk_regmap_div video_cc_mvs0_div_clk_src = {
> + .reg = 0x80ac,
> + .shift = 0,
> + .width = 4,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_div_clk_src",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_regmap_div_ro_ops,
> + },
> +};
> +
> +static struct clk_regmap_div video_cc_mvs0c_div2_div_clk_src = {
> + .reg = 0x8058,
> + .shift = 0,
> + .width = 4,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_div2_div_clk_src",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_regmap_div_ro_ops,
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0_clk = {
> + .halt_reg = 0x80a0,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x80a0,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x80a0,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_div_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0_shift_clk = {
> + .halt_reg = 0x8144,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x8144,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x8144,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_shift_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_xo_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0c_clk = {
> + .halt_reg = 0x804c,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x804c,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0c_div2_div_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0c_shift_clk = {
> + .halt_reg = 0x8148,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x8148,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x8148,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_shift_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_xo_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct gdsc video_cc_mvs0c_gdsc = {
> + .gdscr = 0x8034,
> + .en_rest_wait_val = 0x2,
> + .en_few_wait_val = 0x2,
> + .clk_dis_wait_val = 0x6,
> + .pd = {
> + .name = "video_cc_mvs0c_gdsc",
> + },
> + .pwrsts = PWRSTS_OFF_ON,
> + .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE,
> +};
> +
> +static struct gdsc video_cc_mvs0_gdsc = {
> + .gdscr = 0x808c,
> + .en_rest_wait_val = 0x2,
> + .en_few_wait_val = 0x2,
> + .clk_dis_wait_val = 0x6,
> + .pd = {
> + .name = "video_cc_mvs0_gdsc",
> + },
> + .pwrsts = PWRSTS_OFF_ON,
> + .parent = &video_cc_mvs0c_gdsc.pd,
> + .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL_TRIGGER,
> +};
> +
> +static struct clk_regmap *video_cc_eliza_clocks[] = {
> + [VIDEO_CC_AHB_CLK_SRC] = &video_cc_ahb_clk_src.clkr,
> + [VIDEO_CC_MVS0_CLK] = &video_cc_mvs0_clk.clkr,
> + [VIDEO_CC_MVS0_CLK_SRC] = &video_cc_mvs0_clk_src.clkr,
> + [VIDEO_CC_MVS0_DIV_CLK_SRC] = &video_cc_mvs0_div_clk_src.clkr,
> + [VIDEO_CC_MVS0_SHIFT_CLK] = &video_cc_mvs0_shift_clk.clkr,
> + [VIDEO_CC_MVS0C_CLK] = &video_cc_mvs0c_clk.clkr,
> + [VIDEO_CC_MVS0C_DIV2_DIV_CLK_SRC] = &video_cc_mvs0c_div2_div_clk_src.clkr,
> + [VIDEO_CC_MVS0C_SHIFT_CLK] = &video_cc_mvs0c_shift_clk.clkr,
> + [VIDEO_CC_PLL0] = &video_cc_pll0.clkr,
> + [VIDEO_CC_SLEEP_CLK_SRC] = &video_cc_sleep_clk_src.clkr,
> + [VIDEO_CC_XO_CLK_SRC] = &video_cc_xo_clk_src.clkr,
> +};
> +
> +static struct gdsc *video_cc_eliza_gdscs[] = {
> + [VIDEO_CC_MVS0_GDSC] = &video_cc_mvs0_gdsc,
> + [VIDEO_CC_MVS0C_GDSC] = &video_cc_mvs0c_gdsc,
> +};
> +
> +static const struct qcom_reset_map video_cc_eliza_resets[] = {
> + [VIDEO_CC_INTERFACE_BCR] = { 0x80d8 },
> + [VIDEO_CC_MVS0_CLK_ARES] = { 0x80a0, 2 },
> + [VIDEO_CC_MVS0_BCR] = { 0x8088 },
> + [VIDEO_CC_MVS0C_CLK_ARES] = { 0x804c, 2 },
> + [VIDEO_CC_MVS0C_BCR] = { 0x8030 },
> + [VIDEO_CC_XO_CLK_ARES] = { 0x810c, 2 },
> +};
> +
> +static struct clk_alpha_pll *video_cc_eliza_plls[] = {
> + &video_cc_pll0,
> +};
> +
> +static u32 video_cc_eliza_critical_cbcrs[] = {
> + 0x80dc, /* VIDEO_CC_AHB_CLK */
> + 0x8128, /* VIDEO_CC_SLEEP_CLK */
> + 0x810c, /* VIDEO_CC_XO_CLK */
> +};
> +
> +static const struct regmap_config video_cc_eliza_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .max_register = 0x9f50,
> + .fast_io = true,
> +};
> +
> +static struct qcom_cc_driver_data video_cc_eliza_driver_data = {
> + .alpha_plls = video_cc_eliza_plls,
> + .num_alpha_plls = ARRAY_SIZE(video_cc_eliza_plls),
> + .clk_cbcrs = video_cc_eliza_critical_cbcrs,
> + .num_clk_cbcrs = ARRAY_SIZE(video_cc_eliza_critical_cbcrs),
> +};
> +
> +static const struct qcom_cc_desc video_cc_eliza_desc = {
> + .config = &video_cc_eliza_regmap_config,
> + .clks = video_cc_eliza_clocks,
> + .num_clks = ARRAY_SIZE(video_cc_eliza_clocks),
> + .resets = video_cc_eliza_resets,
> + .num_resets = ARRAY_SIZE(video_cc_eliza_resets),
> + .gdscs = video_cc_eliza_gdscs,
> + .num_gdscs = ARRAY_SIZE(video_cc_eliza_gdscs),
> + .driver_data = &video_cc_eliza_driver_data,
> +};
> +
> +static const struct of_device_id video_cc_eliza_match_table[] = {
> + { .compatible = "qcom,eliza-videocc" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, video_cc_eliza_match_table);
> +
> +static int video_cc_eliza_probe(struct platform_device *pdev)
> +{
> + return qcom_cc_probe(pdev, &video_cc_eliza_desc);
> +}
> +
> +static struct platform_driver video_cc_eliza_driver = {
> + .probe = video_cc_eliza_probe,
> + .driver = {
> + .name = "videocc-eliza",
> + .of_match_table = video_cc_eliza_match_table,
> + },
> +};
> +
> +module_platform_driver(video_cc_eliza_driver);
> +
> +MODULE_DESCRIPTION("QTI VIDEOCC Eliza Driver");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [PATCH v2 02/13] ACPICA: Read LVR from the I2C resource descriptor
From: Akhil R @ 2026-04-10 4:45 UTC (permalink / raw)
To: frank.li
Cc: acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robh, sakari.ailus, wsa+renesas
In-Reply-To: <adhalQxfbMsL3V0T@lizhi-Precision-Tower-5810>
On Thu, 9 Apr 2026 22:04:05 -0400, Frank Li wrote:
> On Thu, Apr 09, 2026 at 04:27:32PM +0530, Akhil R wrote:
>> ACPI 6.3 specifies byte 8 of I2C Serial Bus Connection descriptor to be
>> used for Legacy Virtual Register (LVR) data as specified in the MIPI
>> I3C Specification for an I2C device connected to an I3C Host Controller.
>> LVR will be read by I3C host controller drivers and it provides details
>> about the specific speed and 50ns spike filter capabilities of I2C
>> devices.
>>
>> Update the rsconvert_info to include this field. For I2C devices on an
>> I2C bus, this field is Reserved and unused.
>>
>> This commit is the result of squashing the following:
>> ACPICA commit 70082dc8fc847673ac7f4bbb1541776730f0b63e
>> ACPICA commit e62e74baf7e08cf059ec82049aeccd565b24d661
>> ACPICA commit c404118235108012cad396c834b5aabe2dd1b51a
>> ACPICA commit 7650d4a889ea7907060bfce89f4f780ce83e7b28
>> ACPICA commit 014fa9f2dbcc6b1bd42a4a4a6f6705d9cf7d460b
>
> These commit number is not existed at linus official tree. Please remove it.
These are commits from ACPI-CA github. The files in the acpica folder is
a mirror of that repo. I suppose the commits in this folder are expected
to be structured like this. The process is also described here -
https://docs.kernel.org/driver-api/acpi/linuxized-acpica.html
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v6 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Andy Shevchenko @ 2026-04-10 4:41 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260410-dev_ad5706r-v6-2-f3fda5921fe4@analog.com>
On Fri, Apr 10, 2026 at 09:33:56AM +0800, Alexis Czezar Torreno wrote:
> Add support for the Analog Devices AD5706R, a 4-channel 16-bit
> current output digital-to-analog converter with SPI interface.
>
> Features:
> - 4 independent DAC channels
> - Hardware and software LDAC trigger
> - Configurable output range
> - PWM-based LDAC control
> - Dither and toggle modes
> - Dynamically configurable SPI speed
Still the same issue...
After addressing it in full feel free to add
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
...
> +static int ad5706r_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct ad5706r_state *st = context;
> + unsigned int num_bytes, val;
> + u16 reg;
> + reg = get_unaligned_be16(data);
But this has the similar issue... Validation has to be done before the access.
(also theoretically possible to have count 0, so even for byte access we have
to validate the input, strictly speaking)
> + num_bytes = ad5706r_reg_len(reg);
> +
> + struct spi_transfer xfer = {
> + .tx_buf = st->tx_buf,
> + .len = num_bytes + 2,
> + };
> +
> + if (count != 4)
> + return -EINVAL;
> +
> + val = get_unaligned_be32(data);
> + put_unaligned_be32(val, &st->tx_buf[0]);
> +
> + /* For single byte, copy the data to the correct position */
> + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> + st->tx_buf[2] = st->tx_buf[3];
> +
> + return spi_sync_transfer(st->spi, &xfer, 1);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 0/4] Add QST QMC5883P magnetometer driver
From: Andy Shevchenko @ 2026-04-10 4:36 UTC (permalink / raw)
To: Hardik Phalet
Cc: Greg Kroah-Hartman, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brigham Campbell, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-staging
In-Reply-To: <20260409210639.3197576-1-hardik.phalet@pm.me>
On Thu, Apr 09, 2026 at 09:07:11PM +0000, Hardik Phalet wrote:
> This series adds initial Linux support for the QST QMC5883P, a 3-axis
> anisotropic magneto-resistive (AMR) magnetometer with a 16-bit ADC that
> communicates over I2C. To my knowledge there is no existing upstream
> driver for this device.
>
> The driver supports:
> - Raw magnetic field readings on X, Y, and Z axes
> - Four selectable full-scale ranges (±2 G, ±8 G, ±12 G, ±30 G)
> - Configurable output data rate (10, 50, 100, 200 Hz)
> - Configurable oversampling ratio (1, 2, 4, 8)
> - Configurable downsampling ratio (1, 2, 4, 8) via a custom sysfs
> attribute
> - Runtime PM with a 2 s autosuspend delay
> - System suspend/resume via pm_runtime_force_suspend/resume
>
> Regmap with an rbtree cache is used throughout. CTRL_1 and CTRL_2
> bit fields are accessed via regmap_field to avoid read-modify-write
> races. The STATUS register is marked precious so regmap never reads
> it speculatively and clears the DRDY/OVFL bits unexpectedly.
>
> The init sequence on probe is: soft reset → wait 1 ms → deassert
> reset → configure SET/RESET control → apply default ODR/OSR/DSR/RNG
> → enter normal mode. This ordering was determined empirically on
> hardware to produce reliable, non-zero axis readings.
>
> The driver is placed under drivers/staging/iio/magnetometer/ with a
> TODO file tracking the remaining work before it can graduate:
> - Triggered buffer support (iio_triggered_buffer_setup)
> - DRDY interrupt support
> - Self-test implementation
>
> Patches:
> 1/4 - dt-bindings: vendor-prefixes: Add 'qst' for QST Corporation
> 2/4 - dt-bindings: iio: magnetometer: Add binding for QST QMC5883P
> 3/4 - staging: iio: magnetometer: Add QST QMC5883P driver
> 4/4 - MAINTAINERS: Add entry for QST QMC5883P magnetometer driver
>
> Testing
> -------
> Tested on a Raspberry Pi 4B running a mainline kernel (aarch64) with a
> GY-271 HM-246 board connected via I2C bus 1. The chip was confirmed to
> enumerate at address 0x2C via i2cdetect.
>
> The driver was cross-compiled from Fedora (x86_64) targeting aarch64
> and loaded as a module (qmc5883p.ko) with the Device Tree overlay
> pointing at i2c1:0x2c.
>
> Verification steps performed:
> - Chip ID register (0x00) reads back 0x80 on probe, confirming the
> correct device is present
> - All three axes (in_magn_x_raw, in_magn_y_raw, in_magn_z_raw) return
> non-zero, stable values when the board is held still and change
> appropriately when the board is rotated
> - in_magn_x_scale (and Y, Z) returns the expected fractional value for
> the default ±8 G range (1/37500000)
> - in_magn_sampling_frequency / _available, in_magn_oversampling_ratio /
> _available, and downsampling_ratio / downsampling_ratio_available all
> read and write correctly; the chip responds without error to each
> valid setting
> - Runtime PM: after 2 s of inactivity the device enters suspend mode
> (MODE = 0x00 confirmed via i2cdump); the next sysfs read correctly
> resumes the device and returns valid data
> - System suspend/resume (echo mem > /sys/power/state) leaves the
> driver in a consistent state; readings remain valid after resume
> - dt_binding_check passes for patch 2/4
> - Kernel builds cleanly with W=1 and no new warnings
This driver is rather huge. There are mistakes you made in the process, though:
- never send a new version for such a code (amount and complexity) earlier than
a week; give others a chance to review
- do not put driver to staging, why?
- the investigation is rather poor about existence of the driver — make sure
there is no compatible (by register layout) driver in IIO or even outside it
(for ADCs it might appear as HWMON [drivers/hwmon] or INPUT [drivers/input]
in some cases)
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 01/13] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Akhil R @ 2026-04-10 4:30 UTC (permalink / raw)
To: frank.li
Cc: acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robert.moore, robh, sakari.ailus, wsa+renesas
In-Reply-To: <adhZnNozqpW0DaXF@lizhi-Precision-Tower-5810>
On Thu, 9 Apr 2026 22:00:39 -0400, Frank Li wrote:
> On Thu, Apr 09, 2026 at 04:27:31PM +0530, Akhil R wrote:
>> Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
>> Discovery and Configuration Specification [1] to specify which discovery
>> method an I3C device supports during bus initialization. The property is
>> a bitmap, where a bit value of 1 indicates support for that method, and 0
>> indicates lack of support.
>> Bit 0: SETDASA CCC (Direct)
>> Bit 1: SETAASA CCC (Broadcast)
>> Bit 2: Other CCC (vendor / standards extension)
>> All other bits are reserved.
>>
>> It is specifically needed when an I3C device requires SETAASA for the
>> address assignment. SETDASA will be supported by default if this property
>> is absent, which means for now the property just serves as a flag to
>> enable SETAASA, but keep the property as a bitmap to align with the
>> specifications.
>>
>> [1] https://www.mipi.org/mipi-disco-for-i3c-download
>>
>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> ---
>> .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
>> 1 file changed, 26 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> index e25fa72fd785..1705d90d4d79 100644
>> --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
>> +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
>> @@ -31,10 +31,12 @@ properties:
>> described in the device tree, which in turn means we have to describe
>> I3C devices.
>>
>> - Another use case for describing an I3C device in the device tree is when
>> - this I3C device has a static I2C address and we want to assign it a
>> - specific I3C dynamic address before the DAA takes place (so that other
>> - devices on the bus can't take this dynamic address).
>> + Other use-cases for describing an I3C device in the device tree are:
>> + - When the I3C device has a static I2C address and we want to assign
>> + it a specific I3C dynamic address before the DAA takes place (so
>> + that other devices on the bus can't take this dynamic address).
>> + - When the I3C device requires SETAASA for its discovery and uses a
>> + pre-defined static address.
>>
>> "#size-cells":
>> const: 0
>> @@ -147,6 +149,26 @@ patternProperties:
>> through SETDASA. If static address is not present, this address is assigned
>> through SETNEWDA after assigning a temporary address via ENTDAA.
>>
>> + mipi-i3c-static-method:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + minimum: 0x1
>> + maximum: 0xff
>> + default: 1
>> + description: |
>> + Bitmap describing which methods of Dynamic Address Assignment from a
>> + static address are supported by this I3C Target. A bit value of 1
>> + indicates support for that method, and 0 indicates lack of support.
>> + Bit 0: SETDASA CCC (Direct)
>> + Bit 1: SETAASA CCC (Broadcast)
>> + Bit 2: Other CCC (vendor / standards extension)
>
> You need define at include/dt-bindings/i3c/i3c.h
Ack. Will add these as macros.
>
> Or direct use string arrray
> anyOf
> - setdasa
> - setaasa
> - vendor
The below thread suggested to keep bitmap since this property comes from
a MIPI specification.
https://lore.kernel.org/linux-i3c/20260318172820.13771-1-akhilrajeev@nvidia.com/T/#m8a6c56cff2bde07b84ebfb403a6ac152da24982e
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v3 4/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Vignesh Raghavendra @ 2026-04-10 4:30 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI), Bjorn Andersson, Mathieu Poirier,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Suman Anna,
Nishanth Menon, Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-4-c41473cb23c3@baylibre.com>
Hi Markus
On 18/03/26 20:43, Markus Schneider-Pargmann (TI) wrote:
> Split the firmware memory region in more specific parts so it is better
> described where to find which information. Specifically the LPM metadata
> region is important as bootloader software like U-Boot has to know where
> that data is to be able to read that data.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 40 +++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..c381cc33064ec427751a9ac5bcdff745a9559a89 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> @@ -59,9 +59,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
> no-map;
> };
>
> - wkup_r5fss0_core0_memory_region: memory@9c900000 {
> + wkup_r5fss0_core0_ipc_region: memory@9c900000 {
There are still references to wkup_r5fss0_core0_memory_region in
k3-am62a-ti-ipc-firmware.dtsi (same comment applies to next 2 patches as
well)
Dont those need to be updated too?
> compatible = "shared-dma-pool";
> - reg = <0x00 0x9c900000 0x00 0xf00000>;
> + reg = <0x00 0x9c900000 0x00 0x100000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_fs_stub_region: memory@9ca00000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca00000 0x00 0x8000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_metadata_region: memory@9ca08000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca08000 0x00 0x1000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_rest_region: memory@9ca09000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca09000 0x00 0x97000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_dm_region: memory@9caa0000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9caa0000 0x00 0xd60000>;
> no-map;
> };
>
> @@ -922,3 +946,15 @@ &mcu_uart0 {
> };
>
> #include "k3-am62a-ti-ipc-firmware.dtsi"
> +
> +&wkup_r5fss0_core0 {
> + memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> + <&wkup_r5fss0_core0_ipc_region>,
> + <&wkup_r5fss0_core0_lpm_fs_stub_region>,
> + <&wkup_r5fss0_core0_lpm_metadata_region>,
> + <&wkup_r5fss0_core0_lpm_rest_region>,
> + <&wkup_r5fss0_core0_dm_region>;
> + memory-region-names = "dma", "ipc", "lpm-stub",
> + "lpm-metadata", "lpm-context",
> + "dm-firmware";
> +};
>
--
Regards
Vignesh
https://ti.com/opensource
^ permalink raw reply
* [PATCH 4/4] arm64: dts: qcom: purwa-iot-evk: Add camss node
From: Wenmeng Liu @ 2026-04-10 4:25 UTC (permalink / raw)
To: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wenmeng Liu
In-Reply-To: <20260410-purwa_camss-v1-0-eedcf6d9d8ee@oss.qualcomm.com>
nable camss node for purwa iot evk board camss tpg support.
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
index ad503beec1d3d8c671d3564942a74c484de762d0..eef03f1eb2a950c06294159be3f97169fb487265 100644
--- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
+++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
@@ -734,6 +734,10 @@ retimer_ss2_con_sbu_out: endpoint {
};
};
+&camss {
+ status = "okay";
+};
+
&i2c3 {
clock-frequency = <400000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 3/4] arm64: dts: qcom: purwa: Add camss node
From: Wenmeng Liu @ 2026-04-10 4:25 UTC (permalink / raw)
To: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wenmeng Liu
In-Reply-To: <20260410-purwa_camss-v1-0-eedcf6d9d8ee@oss.qualcomm.com>
Add node for the X1P42100 camera subsystem.
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/purwa.dtsi | 158 ++++++++++++++++++++++++++++++++++++
1 file changed, 158 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/purwa.dtsi b/arch/arm64/boot/dts/qcom/purwa.dtsi
index ea65b8448836ead83f837e973ed536e8ea0ed8ef..ff7b0dd781e9fdea2cec5a918772e4b2ff6f53a7 100644
--- a/arch/arm64/boot/dts/qcom/purwa.dtsi
+++ b/arch/arm64/boot/dts/qcom/purwa.dtsi
@@ -19,6 +19,8 @@
/delete-node/ &cpu_pd9;
/delete-node/ &cpu_pd10;
/delete-node/ &cpu_pd11;
+/delete-node/ &csiphy1;
+/delete-node/ &csiphy2;
/delete-node/ &gpu_opp_table;
/delete-node/ &gpu_speed_bin;
/delete-node/ &pcie3_phy;
@@ -38,6 +40,162 @@
/delete-node/ &thermal_gpuss_6;
/delete-node/ &thermal_gpuss_7;
+&camss {
+ compatible = "qcom,x1p42100-camss";
+
+ reg = <0 0x0acb7000 0 0x2000>,
+ <0 0x0acb9000 0 0x2000>,
+ <0 0x0acbb000 0 0x2000>,
+ <0 0x0acc6000 0 0x1000>,
+ <0 0x0acca000 0 0x1000>,
+ <0 0x0acb6000 0 0x1000>,
+ <0 0x0ace4000 0 0x1000>,
+ <0 0x0acec000 0 0x4000>,
+ <0 0x0acf6000 0 0x1000>,
+ <0 0x0acf7000 0 0x1000>,
+ <0 0x0acf8000 0 0x1000>,
+ <0 0x0ac62000 0 0x4000>,
+ <0 0x0acc7000 0 0x2000>,
+ <0 0x0accb000 0 0x2000>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_wrapper",
+ "csiphy0",
+ "csiphy4",
+ "csitpg0",
+ "csitpg1",
+ "csitpg2",
+ "vfe0",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy4",
+ "vfe0",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_NRT_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPHY_RX_CLK_SRC>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe_lite",
+ "cphy_rx_clk_src",
+ "csid",
+ "csid_csiphy_rx",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "ahb",
+ "hf_mnoc",
+ "sf_mnoc",
+ "sf_icp_mnoc";
+
+ iommus = <&apps_smmu 0x800 0x60>,
+ <&apps_smmu 0x860 0x60>,
+ <&apps_smmu 0x1860 0x60>,
+ <&apps_smmu 0x18e0 0x00>,
+ <&apps_smmu 0x19a0 0x20>;
+
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+ power-domain-names = "ife0",
+ "top";
+
+ phys = <&csiphy0 PHY_TYPE_DPHY>,
+ <&csiphy4 PHY_TYPE_DPHY>;
+ phy-names = "csiphy0",
+ "csiphy4";
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ camss_csiphy0_inep0: endpoint@0 {
+ reg = <0>;
+ };
+ };
+
+ port@3 {
+ reg = <3>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ camss_csiphy4_inep0: endpoint@0 {
+ reg = <0>;
+ };
+ };
+ };
+};
+
&camcc {
compatible = "qcom,x1p42100-camcc";
};
--
2.34.1
^ permalink raw reply related
* [PATCH 2/4] media: qcom: camss: add support for X1P42100 camss
From: Wenmeng Liu @ 2026-04-10 4:25 UTC (permalink / raw)
To: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wenmeng Liu
In-Reply-To: <20260410-purwa_camss-v1-0-eedcf6d9d8ee@oss.qualcomm.com>
The Purwa camera subsystem is a cut-down variant of the Hamoa CAMSS.
Compared to Hamoa, Purwa provides only two CSIPHY instances and does
not include the VFE1.
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
.../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 2 +
drivers/media/platform/qcom/camss/camss-vfe.c | 2 +
drivers/media/platform/qcom/camss/camss.c | 109 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
4 files changed, 114 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 4154832745525972a663809c947a9e9aeca9f944..d37f71de0f42c394b0918a22de2a18836cbfec75 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -1020,6 +1020,7 @@ static bool csiphy_is_gen2(u32 version)
case CAMSS_8650:
case CAMSS_8775P:
case CAMSS_X1E80100:
+ case CAMSS_X1P42100:
ret = true;
break;
}
@@ -1115,6 +1116,7 @@ static int csiphy_init(struct csiphy_device *csiphy)
regs->lane_array_size = ARRAY_SIZE(lane_regs_sc8280xp);
break;
case CAMSS_X1E80100:
+ case CAMSS_X1P42100:
regs->lane_regs = &lane_regs_x1e80100[0];
regs->lane_array_size = ARRAY_SIZE(lane_regs_x1e80100);
regs->offset = 0x1000;
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 5baf0e3d4bc461df28d8dcf97a98dec04fa17ceb..b48dfad5a8a73f81254086e5fc8f5bbc3a45aef3 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -353,6 +353,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
case CAMSS_8650:
case CAMSS_8775P:
case CAMSS_X1E80100:
+ case CAMSS_X1P42100:
switch (sink_code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
{
@@ -2012,6 +2013,7 @@ static int vfe_bpl_align(struct vfe_device *vfe)
case CAMSS_8650:
case CAMSS_8775P:
case CAMSS_X1E80100:
+ case CAMSS_X1P42100:
ret = 16;
break;
default:
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 3b092560b5df54513a5d0253dded1527769fcfbe..d2221f968251fc2c1ab7996ff54b087667a8108c 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -4158,6 +4158,98 @@ static const struct resources_wrapper csid_wrapper_res_x1e80100 = {
.reg = "csid_wrapper",
};
+static const struct camss_subdev_resources csiphy_res_x1p42100[] = {
+ /* CSIPHY0 */
+ {
+ .csiphy = {
+ .id = 0,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+ /* CSIPHY4 */
+ {
+ .csiphy = {
+ .id = 4,
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ },
+ },
+};
+
+static const struct camss_subdev_resources vfe_res_x1p42100[] = {
+ /* IFE0 */
+ {
+ .regulators = {},
+ .clock = {"camnoc_rt_axi", "camnoc_nrt_axi", "cpas_ahb",
+ "cpas_fast_ahb", "cpas_vfe0", "vfe0_fast_ahb",
+ "vfe0" },
+ .clock_rate = { { 400000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 345600000, 432000000, 594000000, 675000000,
+ 727000000 }, },
+ .reg = { "vfe0" },
+ .interrupt = { "vfe0" },
+ .vfe = {
+ .line_num = 4,
+ .pd_name = "ife0",
+ .hw_ops = &vfe_ops_680,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ },
+ },
+ /* IFE_LITE_0 */
+ {
+ .regulators = {},
+ .clock = { "camnoc_rt_axi", "camnoc_nrt_axi", "cpas_ahb",
+ "vfe_lite_ahb", "cpas_vfe_lite", "vfe_lite",
+ "vfe_lite_csid" },
+ .clock_rate = { { 400000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 266666667, 400000000, 480000000 }, },
+ .reg = { "vfe_lite0" },
+ .interrupt = { "vfe_lite0" },
+ .vfe = {
+ .is_lite = true,
+ .line_num = 4,
+ .hw_ops = &vfe_ops_680,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ },
+ },
+ /* IFE_LITE_1 */
+ {
+ .regulators = {},
+ .clock = { "camnoc_rt_axi", "camnoc_nrt_axi", "cpas_ahb",
+ "vfe_lite_ahb", "cpas_vfe_lite", "vfe_lite",
+ "vfe_lite_csid" },
+ .clock_rate = { { 400000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 266666667, 400000000, 480000000 },
+ { 266666667, 400000000, 480000000 }, },
+ .reg = { "vfe_lite1" },
+ .interrupt = { "vfe_lite1" },
+ .vfe = {
+ .is_lite = true,
+ .line_num = 4,
+ .hw_ops = &vfe_ops_680,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ },
+ },
+};
+
/*
* camss_add_clock_margin - Add margin to clock frequency rate
* @rate: Clock frequency rate
@@ -5340,6 +5432,22 @@ static const struct camss_resources x1e80100_resources = {
.vfe_num = ARRAY_SIZE(vfe_res_x1e80100),
};
+static const struct camss_resources x1p42100_resources = {
+ .version = CAMSS_X1P42100,
+ .pd_name = "top",
+ .csiphy_res = csiphy_res_x1p42100,
+ .tpg_res = tpg_res_x1e80100,
+ .csid_res = csid_res_x1e80100,
+ .vfe_res = vfe_res_x1p42100,
+ .csid_wrapper_res = &csid_wrapper_res_x1e80100,
+ .icc_res = icc_res_x1e80100,
+ .icc_path_num = ARRAY_SIZE(icc_res_x1e80100),
+ .csiphy_num = ARRAY_SIZE(csiphy_res_x1p42100),
+ .tpg_num = ARRAY_SIZE(tpg_res_x1e80100),
+ .csid_num = ARRAY_SIZE(csid_res_x1e80100),
+ .vfe_num = ARRAY_SIZE(vfe_res_x1p42100),
+};
+
static const struct of_device_id camss_dt_match[] = {
{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
{ .compatible = "qcom,msm8939-camss", .data = &msm8939_resources },
@@ -5358,6 +5466,7 @@ static const struct of_device_id camss_dt_match[] = {
{ .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
{ .compatible = "qcom,sm8650-camss", .data = &sm8650_resources },
{ .compatible = "qcom,x1e80100-camss", .data = &x1e80100_resources },
+ { .compatible = "qcom,x1p42100-camss", .data = &x1p42100_resources },
{ }
};
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 24ec3ad7990e7c582b06a2c112361128b2358630..c1374033f0b2036458ae6fe31034f183d3041a09 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -94,6 +94,7 @@ enum camss_version {
CAMSS_8650,
CAMSS_8775P,
CAMSS_X1E80100,
+ CAMSS_X1P42100,
};
enum icc_count {
--
2.34.1
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: media: Add bindings for qcom,x1p42100-camss
From: Wenmeng Liu @ 2026-04-10 4:25 UTC (permalink / raw)
To: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wenmeng Liu
In-Reply-To: <20260410-purwa_camss-v1-0-eedcf6d9d8ee@oss.qualcomm.com>
Add bindings for the Camera Subsystem for X1P42100.
The X1P42100 platform provides:
- 2 x CSIPHY
- 3 x TPG
- 3 x CSID
- 2 x CSID Lite
- 1 x IFE
- 2 x IFE Lite
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
.../bindings/media/qcom,x1p42100-camss.yaml | 424 +++++++++++++++++++++
1 file changed, 424 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..8bfa7e616c3b6b91adc8e21ebfbbe6fb579484f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml
@@ -0,0 +1,424 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,x1p42100-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1P42100 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,x1p42100-camss
+
+ reg:
+ maxItems: 14
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_wrapper
+ - const: csiphy0
+ - const: csiphy4
+ - const: csitpg0
+ - const: csitpg1
+ - const: csitpg2
+ - const: vfe0
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 2
+
+ ranges: true
+
+ clocks:
+ maxItems: 22
+
+ clock-names:
+ items:
+ - const: camnoc_nrt_axi
+ - const: camnoc_rt_axi
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: cpas_fast_ahb
+ - const: cpas_vfe0
+ - const: cpas_vfe_lite
+ - const: cphy_rx_clk_src
+ - const: csid
+ - const: csid_csiphy_rx
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: gcc_axi_hf
+ - const: gcc_axi_sf
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+
+ interrupts:
+ maxItems: 10
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy4
+ - const: vfe0
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_mnoc
+ - const: sf_mnoc
+ - const: sf_icp_mnoc
+
+ iommus:
+ oneOf:
+ - items:
+ - description: S1 HLOS IFE and IFE_LITE non-protected read
+ - description: S1 HLOS IFE and IFE_LITE non-protected write
+ - description: S1 HLOS SFE non-protected read
+ - description: S1 HLOS SFE non-protected write
+ - description: S1 HLOS CDM IFE non-protected
+ - description: Legacy slot 0 - do not use
+ - description: Legacy slot 1 - do not use
+ - description: Legacy slot 2 - do not use
+ - items:
+ - description: S1 HLOS IFE and IFE_LITE non-protected read
+ - description: S1 HLOS IFE and IFE_LITE non-protected write
+ - description: S1 HLOS SFE non-protected read
+ - description: S1 HLOS SFE non-protected write
+ - description: S1 HLOS CDM IFE non-protected
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: top
+
+ vdd-csiphy-0p8-supply:
+ description:
+ 0.8V supply to a PHY.
+
+ vdd-csiphy-1p2-supply:
+ description:
+ 1.2V supply to a PHY.
+
+ phys:
+ maxItems: 2
+
+ phy-names:
+ items:
+ - const: csiphy0
+ - const: csiphy4
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports. Supports either standard single sensor mode or
+ Qualcomm's combo mode with one sensor in 2x1 + 1x1 data-lane, clock-lane mode.
+
+ patternProperties:
+ "^port@[0-3]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint@0:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ description:
+ Endpoint for receiving a single sensor input (or first leg of combo).
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4 # Base max allows 4 (for D-PHY)
+
+ clock-lanes:
+ maxItems: 1
+
+ bus-type:
+ enum:
+ - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ endpoint@1:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ description:
+ Endpoint for receiving the second leg of a combo sensor input.
+
+ properties:
+ data-lanes:
+ maxItems: 1
+
+ clock-lanes:
+ maxItems: 1
+
+ bus-type:
+ const: 4 # Combo is D-PHY specific
+
+ required:
+ - data-lanes
+
+ allOf:
+ # Case 1: Combo Mode (endpoint@1 is present)
+ # If endpoint@1 exists, we restrict endpoint@0 to 2 lanes (D-PHY split)
+ - if:
+ required:
+ - endpoint@1
+ then:
+ properties:
+ endpoint@0:
+ properties:
+ data-lanes:
+ minItems: 2
+ maxItems: 2
+ bus-type:
+ const: 4
+ endpoint@1:
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 1
+ bus-type:
+ const: 4
+
+ # Case 2: Single Mode (endpoint@1 is missing)
+ # We explicitly allow up to 4 lanes here to cover the D-PHY use case.
+ - if:
+ not:
+ required:
+ - endpoint@1
+ then:
+ properties:
+ endpoint@0:
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+patternProperties:
+ "^phy@[0-9a-f]+$":
+ $ref: /schemas/phy/qcom,x1e80100-csi2-phy.yaml
+ unevaluatedProperties: false
+
+ "^opp-table(-.*)?$":
+ type: object
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
+ #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,x1e80100-rpmh.h>
+ #include <dt-bindings/phy/phy.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: isp@acb7000 {
+ compatible = "qcom,x1p42100-camss";
+
+ reg = <0 0x0acb7000 0 0x2000>,
+ <0 0x0acb9000 0 0x2000>,
+ <0 0x0acbb000 0 0x2000>,
+ <0 0x0acc6000 0 0x1000>,
+ <0 0x0acca000 0 0x1000>,
+ <0 0x0acb6000 0 0x1000>,
+ <0 0x0ace4000 0 0x1000>,
+ <0 0x0acec000 0 0x4000>,
+ <0 0x0acf6000 0 0x1000>,
+ <0 0x0acf7000 0 0x1000>,
+ <0 0x0acf8000 0 0x1000>,
+ <0 0x0ac62000 0 0x4000>,
+ <0 0x0acc7000 0 0x2000>,
+ <0 0x0accb000 0 0x2000>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_wrapper",
+ "csiphy0",
+ "csiphy4",
+ "csitpg0",
+ "csitpg1",
+ "csitpg2",
+ "vfe0",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_NRT_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPHY_RX_CLK_SRC>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
+
+ clock-names = "camnoc_nrt_axi",
+ "camnoc_rt_axi",
+ "core_ahb",
+ "cpas_ahb",
+ "cpas_fast_ahb",
+ "cpas_vfe0",
+ "cpas_vfe_lite",
+ "cphy_rx_clk_src",
+ "csid",
+ "csid_csiphy_rx",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "gcc_axi_hf",
+ "gcc_axi_sf",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid";
+
+ interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy4",
+ "vfe0",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+
+ interconnect-names = "ahb",
+ "hf_mnoc",
+ "sf_mnoc",
+ "sf_icp_mnoc";
+
+ iommus = <&apps_smmu 0x800 0x60>,
+ <&apps_smmu 0x820 0x60>,
+ <&apps_smmu 0x840 0x60>,
+ <&apps_smmu 0x860 0x60>,
+ <&apps_smmu 0x18a0 0x0>;
+
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ power-domain-names = "ife0",
+ "top";
+
+ vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>;
+ vdd-csiphy-1p2-supply = <&csiphy_1p2_supply>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ csiphy_ep0: endpoint {
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 0/4] media: camss: add support for purwa platform
From: Wenmeng Liu @ 2026-04-10 4:25 UTC (permalink / raw)
To: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, Wenmeng Liu
This series adds camss support for purwa platform and enables TPG for
purwa-iot-evk board.
Have tested with following commands:
- media-ctl -d /dev/media0 --reset
- media-ctl -V '"msm_tpg0":0[fmt:SRGGB10/4608x2592 field:none]'
- media-ctl -V '"msm_csid0":0[fmt:SRGGB10/4608x2592 field:none]'
- media-ctl -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4608x2592 field:none]'
- media-ctl -l '"msm_tpg0":0->"msm_csid0":0[1]'
- media-ctl -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
- v4l2-ctl -d /dev/v4l-subdev0 -c test_pattern=9
- yavta -B capture-mplane -n 5 -f SRGGB10P -s 4608x2592 -F /dev/video0 --capture=5
This patch series depends on patch series:
https://lore.kernel.org/all/20260409-purwa-videocc-camcc-v4-0-5a8e5f2dd4b2@oss.qualcomm.com/
https://lore.kernel.org/all/20260326-x1e-camss-csi2-phy-dtsi-v3-0-1d5a9306116a@linaro.org/
https://lore.kernel.org/all/20260317-camss_tpg-v10-0-b4cfa85c2e1b@oss.qualcomm.com/
Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
---
Wenmeng Liu (4):
dt-bindings: media: Add bindings for qcom,x1p42100-camss
media: qcom: camss: add support for X1P42100 camss
arm64: dts: qcom: purwa: Add camss node
arm64: dts: qcom: purwa-iot-evk: Add camss node
.../bindings/media/qcom,x1p42100-camss.yaml | 424 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 4 +
arch/arm64/boot/dts/qcom/purwa.dtsi | 158 ++++++++
.../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 2 +
drivers/media/platform/qcom/camss/camss-vfe.c | 2 +
drivers/media/platform/qcom/camss/camss.c | 109 ++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
7 files changed, 700 insertions(+)
---
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
change-id: 20260409-purwa_camss-475787b87e14
prerequisite-change-id: 20260331-purwa-videocc-camcc-d9700d0f797d:v4
prerequisite-patch-id: 61bdb45446193b72dd8a4b093e4ab2f78db2f066
prerequisite-patch-id: b5be9dcbb612a14108f890b2782860847edfcbe4
prerequisite-patch-id: 2f4d4c5c118e057c76e6d2785479df01d5bc1c7b
prerequisite-patch-id: 026db5dd71d5b0472225ba72c8ba2781334143a9
prerequisite-patch-id: 615e6f38e528de35dc206f1c7f3eaf78ff04afe2
prerequisite-patch-id: 66096b909debe4d942eee972948d5a138a5be427
prerequisite-patch-id: ee26e00cdde21ddb070af713230082ad3454422c
prerequisite-change-id: 20260325-dphy-params-extension-5fcd9ba8af61:v1
prerequisite-patch-id: 471e9403130bb3e65cea1d2365d75ef664662306
prerequisite-patch-id: 075fa72fba3c4f51138b88972e6a5e240038d90c
prerequisite-patch-id: 4edca361ad7d370a338641d1ebb5ca65b114a244
prerequisite-patch-id: 32dd1b55ba678d00088b376e33e12d9da6241aca
prerequisite-change-id: 20250710-x1e-csi2-phy-f6434b651d3a:v5
prerequisite-patch-id: 5c8b5c0011e54921bcfb64b07f0468977f44290b
prerequisite-patch-id: 22e71ff566976c8333537b09b2721116acd267e1
prerequisite-change-id: 20250313-b4-linux-next-25-03-13-dtsi-x1e80100-camss-1506f74bbd3a:v11
prerequisite-patch-id: 6e8e67cd3ab96a602971bbeeb7dfdeaf3f1426a2
prerequisite-patch-id: bbf431fcabc17c30fa5e804eb4accb8275198b37
prerequisite-patch-id: a7fbea14628b62a8de096dea420473b283010aba
prerequisite-patch-id: b6b6c4e7a5818e1b93fe2758902bd32d2be48509
prerequisite-patch-id: 4f11e3d079a484008a03ce750952d6e2933c0253
prerequisite-patch-id: 5f5504fd7b5eee72c3fb8c045fa57219fd2f0456
prerequisite-patch-id: 570b65b326f4c684d813f6ebeda152378dc2a47f
prerequisite-patch-id: bc5b9321c124abd961ae1f60610dc46701dc80ac
prerequisite-patch-id: 6d36feaa3a210039f87ea47aa74423a670260fb6
prerequisite-change-id: 20251226-camss_tpg-b23a398bb65a:v10
prerequisite-patch-id: 520491f0d518f3463d429e77444e231fa6016dd9
prerequisite-patch-id: 459fda84ad92fcd4a497d00ce1690cd19f2cbacb
prerequisite-patch-id: 82330aed01b91c49acbd577ba75bb73bcae6ac90
Best regards,
--
Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Taniya Das @ 2026-04-10 3:55 UTC (permalink / raw)
To: Bryan O'Donoghue, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <cb5a40e8-e2e3-4ed9-a9c6-0daa9f408710@nxsw.ie>
On 4/10/2026 12:10 AM, Bryan O'Donoghue wrote:
> On 09/04/2026 19:10, Taniya Das wrote:
>> + videocc: clock-controller@aaf0000 {
>> + compatible = "qcom,eliza-videocc";
>> + reg = <0x0 0xaaf0000 0x0 0x10000>;
>> +
>> + clocks = <&bi_tcxo_div2>,
>> + <&sleep_clk>,
>> + <&gcc GCC_VIDEO_AHB_CLK>;
>> +
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + #power-domain-cells = <1>;
>> + };
>> +
>> + camcc: clock-controller@ade0000 {
>> + compatible = "qcom,eliza-camcc";
>> + reg = <0x0 0x0ade0000 0x0 0x20000>;
>> +
>> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
>> + <&bi_tcxo_div2>,
>> + <&sleep_clk>;
>> +
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + };
>
> This looks odd.
>
> Why do these two controllers have no power-domains ?
Bryan, on Eliza the videocc and camcc are connected on CX and MXA.
--
Thanks,
Taniya Das
^ permalink raw reply
* [PATCH v3 2/2] arm64: defconfig: Enable Qualcomm Glymur clock controllers
From: Taniya Das @ 2026-04-10 3:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
devicetree, linux-kernel, Taniya Das, Dmitry Baryshkov
In-Reply-To: <20260410-glymur_mmcc_dt_config_v2-v3-0-acce9d106e72@oss.qualcomm.com>
Enable the Glymur video and gpu clock controller for their respective
functionalities on the Qualcomm Glymur CRD boards.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 4ed70ab7ee854038fa7a756d8b650a609258bdb3..a607bf49c1563d22550c4b81a237d46fe4ea41ce 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1457,7 +1457,9 @@ CONFIG_COMMON_CLK_MT8192_VENCSYS=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_CLK_GLYMUR_DISPCC=m
CONFIG_CLK_GLYMUR_GCC=y
+CONFIG_CLK_GLYMUR_GPUCC=m
CONFIG_CLK_GLYMUR_TCSRCC=m
+CONFIG_CLK_GLYMUR_VIDEOCC=m
CONFIG_CLK_KAANAPALI_GCC=y
CONFIG_CLK_KAANAPALI_TCSRCC=m
CONFIG_CLK_X1E80100_CAMCC=m
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/2] arm64: dts: qcom: Add support for MM clock controllers for Glymur
From: Taniya Das @ 2026-04-10 3:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
devicetree, linux-kernel, Taniya Das, Konrad Dybcio
In-Reply-To: <20260410-glymur_mmcc_dt_config_v2-v3-0-acce9d106e72@oss.qualcomm.com>
Add the device nodes for the multimedia clock controllers videocc, gpucc
and gxclkctl.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 47 ++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index e269cec7942c85447892c0661f83171eded94f3b..882b8fe025e78ec7a9916226ea3b9c9c9e5c03f3 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -5,7 +5,10 @@
#include <dt-bindings/clock/qcom,glymur-dispcc.h>
#include <dt-bindings/clock/qcom,glymur-gcc.h>
+#include <dt-bindings/clock/qcom,glymur-gpucc.h>
#include <dt-bindings/clock/qcom,glymur-tcsr.h>
+#include <dt-bindings/clock/qcom,glymur-videocc.h>
+#include <dt-bindings/clock/qcom,kaanapali-gxclkctl.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/gpio/gpio.h>
@@ -3335,6 +3338,34 @@ hsc_noc: interconnect@2000000 {
#interconnect-cells = <2>;
};
+ gxclkctl: clock-controller@3d64000 {
+ compatible = "qcom,glymur-gxclkctl";
+ reg = <0x0 0x03d64000 0x0 0x6000>;
+
+ power-domains = <&rpmhpd RPMHPD_GFX>,
+ <&rpmhpd RPMHPD_GMXC>,
+ <&gpucc GPU_CC_CX_GDSC>;
+
+ #power-domain-cells = <1>;
+ };
+
+ gpucc: clock-controller@3d90000 {
+ compatible = "qcom,glymur-gpucc";
+ reg = <0x0 0x03d90000 0x0 0x9800>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&gcc GCC_GPU_GPLL0_CLK_SRC>,
+ <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
+
+ power-domains = <&rpmhpd RPMHPD_MX>,
+ <&rpmhpd RPMHPD_CX>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
ipcc: mailbox@3e04000 {
compatible = "qcom,glymur-ipcc", "qcom,ipcc";
reg = <0x0 0x03e04000 0x0 0x1000>;
@@ -3367,6 +3398,22 @@ lpass_ag_noc: interconnect@7e40000 {
#interconnect-cells = <2>;
};
+ videocc: clock-controller@aaf0000 {
+ compatible = "qcom,glymur-videocc";
+ reg = <0x0 0x0aaf0000 0x0 0x10000>;
+ clocks = <&rpmhcc RPMH_CXO_CLK>,
+ <&rpmhcc RPMH_CXO_CLK_A>;
+
+ power-domains = <&rpmhpd RPMHPD_MMCX>,
+ <&rpmhpd RPMHPD_MXC>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ #power-domain-cells = <1>;
+ };
+
dispcc: clock-controller@af00000 {
compatible = "qcom,glymur-dispcc";
reg = <0x0 0x0af00000 0x0 0x20000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/2] clk: qcom: Add clock controller device nodes and enable clocks for Glymur
From: Taniya Das @ 2026-04-10 3:49 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
devicetree, linux-kernel, Taniya Das, Konrad Dybcio,
Dmitry Baryshkov
Add the Video clock controller and GPU/GX clock controllers for Glymur.
Enable the clock controllers for Glymur CRD boards.
Changes in v3:
- Update the GPUCC node with the required power-domain and the
require-opps [Akhil].
- Add RB-by tag [Dmitry] for defconfig.
- Link to v2: https://lore.kernel.org/r/20260303-glymur_mmcc_dt_config_v2-v2-0-da9ded08c26f@oss.qualcomm.com
Changes in v2:
- Add RB-by [Konrad].
- Cleaning up stray 0, and add 0x0 for regs.
- Add "Qualcomm" for defconfig commit subject.
- Update the subject for the Cover Letter [Dmitry]
- Link to v1: https://lore.kernel.org/r/20260220-glymur_mmcc_dt_config-v1-0-e0e2f43a32af@oss.qualcomm.com
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
Taniya Das (2):
arm64: dts: qcom: Add support for MM clock controllers for Glymur
arm64: defconfig: Enable Qualcomm Glymur clock controllers
arch/arm64/boot/dts/qcom/glymur.dtsi | 47 ++++++++++++++++++++++++++++++++++++
arch/arm64/configs/defconfig | 2 ++
2 files changed, 49 insertions(+)
---
base-commit: d517cb8cea012f43b069617fc8179b45404f8018
change-id: 20260303-glymur_mmcc_dt_config_v2-ac59220c73d1
Best regards,
--
Taniya Das <taniya.das@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4 3/3] riscv: dts: spacemit: Add thermal sensor for K1 SoC
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-0-12c87dd063c3@mailbox.org>
Include the Thermal Sensor node in the SpacemiT K1 dtsi
with definitions for registers, clocks, and interrupts.
Additionally, configure thermal zones for the soc, package, gpu, and
clusters to enable temperature monitoring via the thermal framework.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Tested-by: Gong Shuai <gsh517025@gmail.com>
---
Changes in v2:
- Update compatible to "spacemit,k1-tsensor"
---
arch/riscv/boot/dts/spacemit/k1.dtsi | 101 +++++++++++++++++++++++++++++++++++
1 file changed, 101 insertions(+)
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index 529ec68e9c23..e9952204224e 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -339,6 +339,96 @@ osc_32k: clock-32k {
};
};
+ thermal-zones {
+ soc-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 0>;
+
+ trips {
+ soc-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ package-thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 1>;
+
+ trips {
+ package-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ gpu-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 2>;
+
+ trips {
+ gpu-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ gpu-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster0-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 3>;
+
+ trips {
+ cluster0-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cluster0-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+
+ cluster1-thermal {
+ polling-delay-passive = <100>;
+ polling-delay = <0>;
+ thermal-sensors = <&thermal 4>;
+
+ trips {
+ cluster1-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ cluster1-crit {
+ temperature = <115000>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+ };
+ };
+
soc {
compatible = "simple-bus";
interrupt-parent = <&plic>;
@@ -494,6 +584,17 @@ syscon_apbc: system-controller@d4015000 {
#reset-cells = <1>;
};
+ thermal: thermal@d4018000 {
+ compatible = "spacemit,k1-tsensor";
+ reg = <0x0 0xd4018000 0x0 0x100>;
+ clocks = <&syscon_apbc CLK_TSEN>,
+ <&syscon_apbc CLK_TSEN_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <61>;
+ resets = <&syscon_apbc RESET_TSEN>;
+ #thermal-sensor-cells = <1>;
+ };
+
i2c6: i2c@d4018800 {
compatible = "spacemit,k1-i2c";
reg = <0x0 0xd4018800 0x0 0x38>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/3] thermal: spacemit: k1: Add thermal sensor support
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Anand Moon, Troy Mitchell, Yao Zi, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-0-12c87dd063c3@mailbox.org>
The thermal sensor on K1 supports monitoring five temperature zones.
The driver registers these sensors with the thermal framework
and supports standard operations:
- Reading temperature (millidegree Celsius)
- Setting high/low thresholds for interrupts
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Reviewed-by: Yao Zi <me@ziyao.cc>
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Tested-by: Gong Shuai <gsh517025@gmail.com>
---
Changes in v4:
- Add 'depends on THERMAL_OF' in drivers/thermal/spacemit/Kconfig
Changes in v3:
- Align multi-line assignments as suggested by reviewer
- Remove unnecessary variable definitions
Changes in v2:
- Rename k1_thermal.c to k1_tsensor.c for better hardware alignment
- Move driver to drivers/thermal/spacemit/
- Add Kconfig/Makefile for spacemit and update top-level build files
- Refactor names, style, code alignment, and comments
- Simplify probe and error handling
---
drivers/thermal/Kconfig | 2 +
drivers/thermal/Makefile | 1 +
drivers/thermal/spacemit/Kconfig | 19 +++
drivers/thermal/spacemit/Makefile | 3 +
drivers/thermal/spacemit/k1_tsensor.c | 281 ++++++++++++++++++++++++++++++++++
5 files changed, 306 insertions(+)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index b10080d61860..1c4a5cd5a23e 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -472,6 +472,8 @@ endmenu
source "drivers/thermal/renesas/Kconfig"
+source "drivers/thermal/spacemit/Kconfig"
+
source "drivers/thermal/tegra/Kconfig"
config GENERIC_ADC_THERMAL
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index bb21e7ea7fc6..3b249195c088 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -65,6 +65,7 @@ obj-y += mediatek/
obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
+obj-y += spacemit/
obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
obj-$(CONFIG_LOONGSON2_THERMAL) += loongson2_thermal.o
diff --git a/drivers/thermal/spacemit/Kconfig b/drivers/thermal/spacemit/Kconfig
new file mode 100644
index 000000000000..de7b5ece5af2
--- /dev/null
+++ b/drivers/thermal/spacemit/Kconfig
@@ -0,0 +1,19 @@
+# SPDX-License-Identifier: GPL-2.0-only
+menu "SpacemiT thermal drivers"
+depends on ARCH_SPACEMIT || COMPILE_TEST
+
+config SPACEMIT_K1_TSENSOR
+ tristate "SpacemiT K1 thermal sensor driver"
+ depends on THERMAL_OF
+ help
+ This driver provides support for the thermal sensor
+ integrated in the SpacemiT K1 SoC.
+
+ The thermal sensor monitors temperatures for five thermal zones:
+ soc, package, gpu, cluster0, and cluster1. It supports reporting
+ temperature values and handling high/low threshold interrupts.
+
+ Say Y here if you want to enable thermal monitoring on SpacemiT K1.
+ If compiled as a module, it will be called k1_tsensor.
+
+endmenu
diff --git a/drivers/thermal/spacemit/Makefile b/drivers/thermal/spacemit/Makefile
new file mode 100644
index 000000000000..82b30741e4ec
--- /dev/null
+++ b/drivers/thermal/spacemit/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_SPACEMIT_K1_TSENSOR) += k1_tsensor.o
diff --git a/drivers/thermal/spacemit/k1_tsensor.c b/drivers/thermal/spacemit/k1_tsensor.c
new file mode 100644
index 000000000000..b742739e9019
--- /dev/null
+++ b/drivers/thermal/spacemit/k1_tsensor.c
@@ -0,0 +1,281 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Thermal sensor driver for SpacemiT K1 SoC
+ *
+ * Copyright (C) 2026 Shuwei Wu <shuwei.wu@mailbox.org>
+ */
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+#include <linux/thermal.h>
+
+#include "../thermal_hwmon.h"
+
+#define K1_TSENSOR_PCTRL_REG 0x00
+#define K1_TSENSOR_PCTRL_ENABLE BIT(0)
+#define K1_TSENSOR_PCTRL_TEMP_MODE BIT(3)
+#define K1_TSENSOR_PCTRL_RAW_SEL BIT(7)
+
+#define K1_TSENSOR_PCTRL_CTUNE GENMASK(11, 8)
+#define K1_TSENSOR_PCTRL_SW_CTRL GENMASK(21, 18)
+#define K1_TSENSOR_PCTRL_HW_AUTO_MODE BIT(23)
+
+#define K1_TSENSOR_EN_REG 0x08
+#define K1_TSENSOR_EN_ALL GENMASK(MAX_SENSOR_NUMBER - 1, 0)
+
+#define K1_TSENSOR_TIME_REG 0x0C
+#define K1_TSENSOR_TIME_WAIT_REF_CNT GENMASK(3, 0)
+#define K1_TSENSOR_TIME_ADC_CNT_RST GENMASK(7, 4)
+#define K1_TSENSOR_TIME_FILTER_PERIOD GENMASK(21, 20)
+#define K1_TSENSOR_TIME_MASK GENMASK(23, 0)
+
+#define K1_TSENSOR_INT_CLR_REG 0x10
+#define K1_TSENSOR_INT_EN_REG 0x14
+#define K1_TSENSOR_INT_STA_REG 0x18
+
+#define K1_TSENSOR_INT_EN_MASK BIT(0)
+#define K1_TSENSOR_INT_MASK(x) (GENMASK(2, 1) << ((x) * 2))
+
+#define K1_TSENSOR_DATA_BASE_REG 0x20
+#define K1_TSENSOR_DATA_REG(x) (K1_TSENSOR_DATA_BASE_REG + ((x) / 2) * 4)
+#define K1_TSENSOR_DATA_LOW_MASK GENMASK(15, 0)
+#define K1_TSENSOR_DATA_HIGH_MASK GENMASK(31, 16)
+
+#define K1_TSENSOR_THRSH_BASE_REG 0x40
+#define K1_TSENSOR_THRSH_REG(x) (K1_TSENSOR_THRSH_BASE_REG + ((x) * 4))
+#define K1_TSENSOR_THRSH_LOW_MASK GENMASK(15, 0)
+#define K1_TSENSOR_THRSH_HIGH_MASK GENMASK(31, 16)
+
+#define MAX_SENSOR_NUMBER 5
+
+/* Hardware offset value required for temperature calculation */
+#define TEMPERATURE_OFFSET 278
+
+struct k1_tsensor_channel {
+ struct k1_tsensor *ts;
+ struct thermal_zone_device *tzd;
+ int id;
+};
+
+struct k1_tsensor {
+ void __iomem *base;
+ struct k1_tsensor_channel ch[MAX_SENSOR_NUMBER];
+};
+
+static void k1_tsensor_init(struct k1_tsensor *ts)
+{
+ u32 val;
+
+ /* Disable all the interrupts */
+ writel(0xffffffff, ts->base + K1_TSENSOR_INT_EN_REG);
+
+ /* Configure ADC sampling time and filter period */
+ val = readl(ts->base + K1_TSENSOR_TIME_REG);
+ val &= ~K1_TSENSOR_TIME_MASK;
+ val |= K1_TSENSOR_TIME_FILTER_PERIOD |
+ K1_TSENSOR_TIME_ADC_CNT_RST |
+ K1_TSENSOR_TIME_WAIT_REF_CNT;
+ writel(val, ts->base + K1_TSENSOR_TIME_REG);
+
+ /*
+ * Enable all sensors' auto mode, enable dither control,
+ * consecutive mode, and power up sensor.
+ */
+ val = readl(ts->base + K1_TSENSOR_PCTRL_REG);
+ val &= ~K1_TSENSOR_PCTRL_SW_CTRL;
+ val &= ~K1_TSENSOR_PCTRL_CTUNE;
+ val |= K1_TSENSOR_PCTRL_RAW_SEL |
+ K1_TSENSOR_PCTRL_TEMP_MODE |
+ K1_TSENSOR_PCTRL_HW_AUTO_MODE |
+ K1_TSENSOR_PCTRL_ENABLE;
+ writel(val, ts->base + K1_TSENSOR_PCTRL_REG);
+
+ /* Enable thermal interrupt */
+ val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
+ val |= K1_TSENSOR_INT_EN_MASK;
+ writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
+
+ /* Enable each sensor */
+ val = readl(ts->base + K1_TSENSOR_EN_REG);
+ val |= K1_TSENSOR_EN_ALL;
+ writel(val, ts->base + K1_TSENSOR_EN_REG);
+}
+
+static void k1_tsensor_enable_irq(struct k1_tsensor_channel *ch)
+{
+ struct k1_tsensor *ts = ch->ts;
+ u32 val;
+
+ val = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
+ val |= K1_TSENSOR_INT_MASK(ch->id);
+ writel(val, ts->base + K1_TSENSOR_INT_CLR_REG);
+
+ val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
+ val &= ~K1_TSENSOR_INT_MASK(ch->id);
+ writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
+}
+
+/*
+ * The conversion formula used is:
+ * T(m°C) = (((raw_value & mask) >> shift) - TEMPERATURE_OFFSET) * 1000
+ */
+static int k1_tsensor_get_temp(struct thermal_zone_device *tz, int *temp)
+{
+ struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
+ struct k1_tsensor *ts = ch->ts;
+ u32 val;
+
+ val = readl(ts->base + K1_TSENSOR_DATA_REG(ch->id));
+ if (ch->id % 2)
+ *temp = FIELD_GET(K1_TSENSOR_DATA_HIGH_MASK, val);
+ else
+ *temp = FIELD_GET(K1_TSENSOR_DATA_LOW_MASK, val);
+
+ *temp -= TEMPERATURE_OFFSET;
+ *temp *= 1000;
+
+ return 0;
+}
+
+/*
+ * For each sensor, the hardware threshold register is 32 bits:
+ * - Lower 16 bits [15:0] configure the low threshold temperature.
+ * - Upper 16 bits [31:16] configure the high threshold temperature.
+ */
+static int k1_tsensor_set_trips(struct thermal_zone_device *tz, int low, int high)
+{
+ struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
+ struct k1_tsensor *ts = ch->ts;
+ u32 val;
+
+ if (low >= high)
+ return -EINVAL;
+
+ if (low < 0)
+ low = 0;
+
+ high = high / 1000 + TEMPERATURE_OFFSET;
+ low = low / 1000 + TEMPERATURE_OFFSET;
+
+ val = readl(ts->base + K1_TSENSOR_THRSH_REG(ch->id));
+ val &= ~K1_TSENSOR_THRSH_HIGH_MASK;
+ val |= FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, high);
+
+ val &= ~K1_TSENSOR_THRSH_LOW_MASK;
+ val |= FIELD_PREP(K1_TSENSOR_THRSH_LOW_MASK, low);
+ writel(val, ts->base + K1_TSENSOR_THRSH_REG(ch->id));
+
+ return 0;
+}
+
+static const struct thermal_zone_device_ops k1_tsensor_ops = {
+ .get_temp = k1_tsensor_get_temp,
+ .set_trips = k1_tsensor_set_trips,
+};
+
+static irqreturn_t k1_tsensor_irq_thread(int irq, void *data)
+{
+ struct k1_tsensor *ts = (struct k1_tsensor *)data;
+ int mask, status, i;
+
+ status = readl(ts->base + K1_TSENSOR_INT_STA_REG);
+
+ for (i = 0; i < MAX_SENSOR_NUMBER; i++) {
+ if (status & K1_TSENSOR_INT_MASK(i)) {
+ mask = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
+ mask |= K1_TSENSOR_INT_MASK(i);
+ writel(mask, ts->base + K1_TSENSOR_INT_CLR_REG);
+ thermal_zone_device_update(ts->ch[i].tzd, THERMAL_EVENT_UNSPECIFIED);
+ }
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int k1_tsensor_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct k1_tsensor *ts;
+ struct reset_control *reset;
+ struct clk *clk;
+ int i, irq, ret;
+
+ ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
+ if (!ts)
+ return -ENOMEM;
+
+ ts->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(ts->base))
+ return dev_err_probe(dev, PTR_ERR(ts->base), "Failed to get reg\n");
+
+ reset = devm_reset_control_get_exclusive_deasserted(dev, NULL);
+ if (IS_ERR(reset))
+ return dev_err_probe(dev, PTR_ERR(reset), "Failed to get/deassert reset control\n");
+
+ clk = devm_clk_get_enabled(dev, "core");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk), "Failed to get core clock\n");
+
+ clk = devm_clk_get_enabled(dev, "bus");
+ if (IS_ERR(clk))
+ return dev_err_probe(dev, PTR_ERR(clk), "Failed to get bus clock\n");
+
+ k1_tsensor_init(ts);
+
+ for (i = 0; i < MAX_SENSOR_NUMBER; ++i) {
+ ts->ch[i].id = i;
+ ts->ch[i].ts = ts;
+ ts->ch[i].tzd = devm_thermal_of_zone_register(dev, i, ts->ch + i, &k1_tsensor_ops);
+ if (IS_ERR(ts->ch[i].tzd))
+ return PTR_ERR(ts->ch[i].tzd);
+
+ /* Attach sysfs hwmon attributes for userspace monitoring */
+ ret = devm_thermal_add_hwmon_sysfs(dev, ts->ch[i].tzd);
+ if (ret)
+ dev_warn(dev, "Failed to add hwmon sysfs attributes\n");
+
+ k1_tsensor_enable_irq(ts->ch + i);
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0)
+ return irq;
+
+ ret = devm_request_threaded_irq(dev, irq, NULL,
+ k1_tsensor_irq_thread,
+ IRQF_ONESHOT, "k1_tsensor", ts);
+ if (ret < 0)
+ return ret;
+
+ platform_set_drvdata(pdev, ts);
+
+ return 0;
+}
+
+static const struct of_device_id k1_tsensor_dt_ids[] = {
+ { .compatible = "spacemit,k1-tsensor" },
+ { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(of, k1_tsensor_dt_ids);
+
+static struct platform_driver k1_tsensor_driver = {
+ .driver = {
+ .name = "k1_tsensor",
+ .of_match_table = k1_tsensor_dt_ids,
+ },
+ .probe = k1_tsensor_probe,
+};
+module_platform_driver(k1_tsensor_driver);
+
+MODULE_DESCRIPTION("SpacemiT K1 Thermal Sensor Driver");
+MODULE_AUTHOR("Shuwei Wu <shuwei.wu@mailbox.org>");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v4 1/3] dt-bindings: thermal: Add SpacemiT K1 thermal sensor
From: Shuwei Wu @ 2026-04-10 3:31 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Shuwei Wu, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Krzysztof Kozlowski, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-k1-thermal-v1-0-12c87dd063c3@mailbox.org>
Document the SpacemiT K1 Thermal Sensor, which supports
monitoring temperatures for five zones: soc, package, gpu, cluster0,
and cluster1.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Tested-by: Gong Shuai <gsh517025@gmail.com>
---
Changes in v2:
- Rename binding file to spacemit,k1-tsensor.yaml and update compatible
---
.../bindings/thermal/spacemit,k1-tsensor.yaml | 76 ++++++++++++++++++++++
1 file changed, 76 insertions(+)
diff --git a/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml b/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml
new file mode 100644
index 000000000000..6dad76a7dd36
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/spacemit,k1-tsensor.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/spacemit,k1-tsensor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SpacemiT K1 Thermal Sensor
+
+description:
+ The SpacemiT K1 Thermal Sensor monitors the temperature of the SoC
+ using multiple internal sensors (e.g., soc, package, gpu, clusters).
+
+maintainers:
+ - Shuwei Wu <shuwei.wu@mailbox.org>
+
+$ref: thermal-sensor.yaml#
+
+properties:
+ compatible:
+ const: spacemit,k1-tsensor
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Core clock for thermal sensor
+ - description: Bus clock for thermal sensor
+
+ clock-names:
+ items:
+ - const: core
+ - const: bus
+
+ interrupts:
+ maxItems: 1
+
+ resets:
+ items:
+ - description: Reset for the thermal sensor
+
+ "#thermal-sensor-cells":
+ const: 1
+ description:
+ The first cell indicates the sensor ID.
+ 0 = soc
+ 1 = package
+ 2 = gpu
+ 3 = cluster0
+ 4 = cluster1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - interrupts
+ - resets
+ - "#thermal-sensor-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/spacemit,k1-syscon.h>
+
+ thermal@d4018000 {
+ compatible = "spacemit,k1-tsensor";
+ reg = <0xd4018000 0x100>;
+ clocks = <&syscon_apbc CLK_TSEN>,
+ <&syscon_apbc CLK_TSEN_BUS>;
+ clock-names = "core", "bus";
+ interrupts = <61>;
+ resets = <&syscon_apbc RESET_TSEN>;
+ #thermal-sensor-cells = <1>;
+ };
--
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