* RE: [PATCH v6 04/10] clk: realtek: Add support for phase locked loops (PLLs)
From: Yu-Chun Lin [林祐君] @ 2026-04-10 7:43 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <ac_QBGY8VxcvuVlY@redhat.com>
Hi Brian,
> Hi Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:51PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Provide a full set of PLL operations for programmable PLLs and a
> > read-only variant for fixed or hardware-managed PLLs.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Add the headers used in c file to follow the "Include What You Use"
> principle.
> > - Move to_clk_pll() from clk-pll.h to clk-pll.c to limit its scope.
> > ---
> > drivers/clk/realtek/Makefile | 2 +
> > drivers/clk/realtek/clk-pll.c | 164
> +++++++++++++++++++++++++++++++
> > drivers/clk/realtek/clk-pll.h | 42 ++++++++
> > drivers/clk/realtek/freq_table.c | 36 +++++++
> > drivers/clk/realtek/freq_table.h | 21 ++++
> > 5 files changed, 265 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-pll.c create mode 100644
> > drivers/clk/realtek/clk-pll.h create mode 100644
> > drivers/clk/realtek/freq_table.c create mode 100644
> > drivers/clk/realtek/freq_table.h
> >
> > diff --git a/drivers/clk/realtek/Makefile
> > b/drivers/clk/realtek/Makefile index 377ec776ee47..a89ad77993e9 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -2,3 +2,5 @@
> > obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
> >
> > clk-rtk-y += common.o
> > +clk-rtk-y += clk-pll.o
> > +clk-rtk-y += freq_table.o
> > diff --git a/drivers/clk/realtek/clk-pll.c
> > b/drivers/clk/realtek/clk-pll.c new file mode 100644 index
> > 000000000000..44730b22a94c
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-pll.c
> > @@ -0,0 +1,164 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2024 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include <linux/regmap.h>
> > +#include "clk-pll.h"
> > +
> > +#define TIMEOUT 2000
> > +
> > +static inline struct clk_pll *to_clk_pll(struct clk_hw *hw) {
> > + struct clk_regmap *clkr = to_clk_regmap(hw);
> > +
> > + return container_of(clkr, struct clk_pll, clkr); }
> > +
> > +static int wait_freq_ready(struct clk_pll *clkp) {
> > + u32 pollval;
> > +
> > + if (!clkp->freq_ready_valid)
> > + return 0;
> > +
> > + return regmap_read_poll_timeout_atomic(clkp->clkr.regmap,
> clkp->freq_ready_reg, pollval,
> > + (pollval &
> clkp->freq_ready_mask)
> > + ==
> clkp->freq_ready_val,
> > + 0, TIMEOUT);
>
> I would put the "(pollval & clkp->freq_ready_mask) == clkp->freq_ready_val"
> on the same line to improve readability. You can go out to 100 characters.
>
> Also should the delay be greater than 0 to avoid tons of constant retries?
>
Since aligning with the open parenthesis would exceed the 100-character limit,
I will use an extra tab for the continuation line.
Also, I have increased the delay_us parameter to 1 to avoid constant retries.
The code will look like this:
return regmap_read_poll_timeout_atomic(clkp->clkr.regmap, clkp->freq_ready_reg, pollval,
(pollval & clkp->freq_ready_mask) == clkp->freq_ready_val, 1, TIMEOUT);
> > +}
> > +
> > +static bool is_power_on(struct clk_pll *clkp) {
> > + u32 val;
> > +
> > + if (!clkp->power_reg)
> > + return true;
> > +
> > + if (regmap_read(clkp->clkr.regmap, clkp->power_reg, &val))
> > + return true;
>
> Is the intention if there is an error, then it marks it as success?
>
Returning true here is a conservative design choice. When reading the power
status fails, returning true prevents unconditionally turning off the clock.
> > +
> > + return (val & clkp->power_mask) == clkp->power_val_on; }
> > +
> > +static void clk_pll_disable(struct clk_hw *hw) {
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > +
> > + if (!clkp->seq_power_off)
> > + return;
> > +
> > + regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_power_off,
> > + clkp->num_seq_power_off); }
> > +
> > +static int clk_pll_is_enabled(struct clk_hw *hw) {
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > +
> > + return is_power_on(clkp);
> > +}
> > +
> > +static int clk_pll_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req) {
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > + const struct freq_table *ftblv = NULL;
> > +
> > + ftblv = ftbl_find_by_rate(clkp->freq_tbl, req->rate);
> > + if (!ftblv)
> > + return -EINVAL;
> > +
> > + req->rate = ftblv->rate;
> > + return 0;
>
> Add newline before return.
>
Ack.
> > +}
> > +
> > +static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
> > + unsigned long parent_rate) {
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > + const struct freq_table *fv;
> > + u32 freq_val;
> > +
> > + if (regmap_read(clkp->clkr.regmap, clkp->freq_reg, &freq_val))
> > + return 0;
> > +
> > + freq_val &= clkp->freq_mask;
> > +
> > + fv = ftbl_find_by_val_with_mask(clkp->freq_tbl, clkp->freq_mask,
> > + freq_val);
> > + return fv ? fv->rate : 0;
>
> Add newline before return.
>
Ack.
> > +}
> > +
(snip)
> > index 000000000000..272a10e75a54
> > --- /dev/null
> > +++ b/drivers/clk/realtek/freq_table.c
> > @@ -0,0 +1,36 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +
> > +#include <linux/bitops.h>
> > +#include "freq_table.h"
> > +
> > +const struct freq_table *ftbl_find_by_rate(const struct freq_table *ftbl,
> > + unsigned long rate) {
> > + unsigned long best_rate = 0;
> > + const struct freq_table *best = NULL;
>
> Put variables in reverse Christmas tree order.
Ack
>
> > +
> > + for (; !IS_FREQ_TABLE_END(ftbl); ftbl++) {
> > + if (ftbl->rate == rate)
> > + return ftbl;
> > +
> > + if (ftbl->rate > rate)
> > + continue;
> > +
> > + if (ftbl->rate > best_rate) {
> > + best_rate = ftbl->rate;
> > + best = ftbl;
> > + }
> > + }
> > +
> > + return best;
> > +}
> > +
> > +const struct freq_table *
> > +ftbl_find_by_val_with_mask(const struct freq_table *ftbl, u32 mask,
> > +u32 value) {
> > + for (; !IS_FREQ_TABLE_END(ftbl); ftbl++) {
> > + if ((ftbl->val & mask) == (value & mask))
> > + return ftbl;
> > + }
> > + return NULL;
> > +};
> > diff --git a/drivers/clk/realtek/freq_table.h
> > b/drivers/clk/realtek/freq_table.h
> > new file mode 100644
> > index 000000000000..6d9116651105
> > --- /dev/null
> > +++ b/drivers/clk/realtek/freq_table.h
> > @@ -0,0 +1,21 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +struct freq_table {
> > + u32 val;
> > + unsigned long rate;
> > +};
> > +
> > +/* ofs check */
> > +#define CLK_OFS_INVALID -1
> > +#define CLK_OFS_IS_VALID(_ofs) ((_ofs) != CLK_OFS_INVALID)
>
> Is this used anywhere?
I will drop them.
Best Regards,
Yu-Chun
>
> Brian
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Krzysztof Kozlowski @ 2026-04-10 7:44 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Ajit Pandey, Imran Shaik, Jagadeesh Kona,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260409-eliza_mm_cc_v2-v2-8-bc0c6dd77bc5@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 11:40:49PM +0530, Taniya Das wrote:
> Add the device nodes for the multimedia clock controllers (cambistmclkcc,
> camcc, videocc, gpucc) for Qualcomm Eliza SoC.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 54 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
Note that this patch and drivers parches were likely not tested.
Please mark patches you wish others to test as RFT.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: clock: qcom: Add support for CAMCC for Eliza
From: Krzysztof Kozlowski @ 2026-04-10 7:47 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Ajit Pandey, Imran Shaik, Jagadeesh Kona,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260409-eliza_mm_cc_v2-v2-3-bc0c6dd77bc5@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 11:40:44PM +0530, Taniya Das wrote:
> Update the compatible and the bindings for CAMCC support on Eliza SoC.
I do not see any update here. Also, no improvements after v1 comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: vendor-prefixes: Add QST Corporation
From: Krzysztof Kozlowski @ 2026-04-10 7:52 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-2-hardik.phalet@pm.me>
On Thu, Apr 09, 2026 at 09:07:20PM +0000, Hardik Phalet wrote:
> Add the vendor prefix 'qst' for QST Corporation, a manufacturer of
> MEMS sensors.
>
> Signed-off-by: Hardik Phalet <hardik.phalet@pm.me>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 5d2a7a8d3ac6..71a1b9087c5e 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1244,6 +1244,8 @@ patternProperties:
> description: Shenzhen QiShenglong Industrialist Co., Ltd.
> "^qnap,.*":
> description: QNAP Systems, Inc.
> + "^qst,.*":
Website tells me qstcorp.com, so prefix is qstcorp. Unless it is
different company, but then just explain that in commit msg (e.g.
provide link to website).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Herve Codina @ 2026-04-10 7:52 UTC (permalink / raw)
To: Rob Herring
Cc: Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <CAL_JsqK4SHQS6MciQpLSrGWo2knqs7-eB3yoAv2J54bSfW-Lxg@mail.gmail.com>
Hi Rob, Mark,
On Thu, 9 Apr 2026 10:00:55 -0500
Rob Herring <robh@kernel.org> wrote:
...
>
> > > If not, then gain-range could be expressed using gain-points instead.
> >
> > Do you have in mind something like the following?
> > gain-range = <0 (-300)>, <3 600>;
> >
> > defining the range from -3dB to +6dB with GPIOs value 0 for -3dB and 3 for +6dB.
>
> Yes, but since you can have reserved values, that won't work.
In that case gpio-points can be used.
The other solution will be to allow multiple ranges:
gpios Gain
0b000 -> -6dB
0b001 -> -3dB
0b010 -> 0dB
0b011 -> Reserved
0b100 -> +3dB
0b101 -> +6dB
other -> Reserved
This could be described as
gain-ranges = <0 (-600)>, <2 0>,
<4 300>, <5 600>;
As a side note, this will probably add quite a lot of complexity to handle
multiple ranges in the driver. If too complex, the driver will handle only
one range and returns -ENOTSUPP if multiple ranges (more than one) are used.
Is that something acceptable?
...
> > > > + description: |
> > > > + List of the gain labels attached to the combination of GPIOs controlling
> > > > + the gain. The first label is related to the gain value 0, the second label
> > > > + is related to the gain value 1 and so on.
> > > > +
> > > > + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > > > + Assuming that gain value set the hardware according to the following
> > > > + table:
> > > > +
> > > > + GPIOs | Hardware
> > > > + value | amplification
> > > > + ------+--------------
> > > > + 0 | Low
> > > > + 1 | Middle
> > > > + 2 | High
> > > > + 3 | Max
> > > > + ------+--------------
> > > > +
> > > > + The description using gain labels can be:
> > > > + gain-labels = "Low", "Middle", "High", "Max";
> > >
> > > Do we need to allow these to be anything? It's going to get hard to come
> > > up with 2^32 names.
> >
> > Well, "Normal" / "Boost" can make sense on some hardware.
> >
> > I don't think we need to restrict labels to a list of known label here.
>
> As long as the names are meaningless to software.
>
> >
> > Of course 2^32 names is obviously a lot. What could be the limit?
>
> I would guess at 8 or more, it's just going to be gain1, gain2, etc.
> or something similar constructed from the gain values.
I suppose that gpio-points or gpio-ranges are going to be used instead
of labels at 8 or more.
With a lot number of GPIOs involved, I am not sure that using labels makes
sense even from the hardware point of view.
The 3 possible descriptions (gpio-points, gpio-range(s), gpio-labels) are
mutually exclusive. Depending on the hardware designed, one of them has to
be chosen.
Of course, you can describe 256 labels but does it make sense in that case
with alternative available ?
>
> > ...
> >
> > > > +
> > > > + /* A mutable amplifier without any gain control */
> > > > + amplifier4 {
> > > > + compatible = "audio-gpio-amp";
> > > > + vdd-supply = <®ulator>;
> > > > + mute-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
> > >
> > > This case is just simple-amplifier...
> >
> > No, simple-amplifier uses 'enable' and not 'mute'.
>
> Yes, I know...
>
> > We can have the amplifier enabled ('enable' GPIO active) as it is
> > used and a switch driven by an other GPIO to mute / un-mute the
> > amplifier output.
>
> But you have no 'enable' GPIO here. To me, enable just looks like
> inverted mute. If there's some electrical difference, I can't tell
> what that is from either binding.
A known physical component handle by simple-amplifier is the dio2125.
According to its datasheet:
Pop-free power up is ensured by keeping the EN (shutdown pin) low during
power down. The EN pin should be kept low EN pin high to achieve pop-less
power up
The 'enable' gpio should be used when power is established or remove.
The mute gpio handle an output switch:
+---------+ op-amp output
| dio2125 +-------------------o
| | o---- Amplifier feature output
enable ---+ | ,--o ^
| | | |
+---------+ v |
GND |
|
mute --------------------------------------'
The mute signal switches on/off the dio2125 output while the dio2125 is
active (powered uup) and so its enable pin is driven high.
I can add an 'enable' GPIO here to handle it in the same way as it is handled in the
simple-amplifier (dio2125 use case).
>
> I guess my point was that really we could deprecate simple-amplifier
> binding because this one can handle it and more. But I'm not
> suggesting we do that yet.
>
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: iio: magnetometer: Add binding for QST QMC5883P
From: Krzysztof Kozlowski @ 2026-04-10 7:55 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-3-hardik.phalet@pm.me>
On Thu, Apr 09, 2026 at 09:07:29PM +0000, Hardik Phalet wrote:
> Add the device tree binding document for the QST QMC5883P, a 3-axis
> anisotropic magneto-resistive (AMR) sensor with a 16-bit ADC that
> communicates over I2C. The binding exposes the required 'compatible'
> and 'reg' properties along with an optional 'vdd-supply' for the
> 2.5 V–3.6 V VDD rail.
Drop last sentence. We can read the diff.
...
> +properties:
> + compatible:
> + const: qst,qmc5883p
> +
> + reg:
> + maxItems: 1
> + description: I2C address of the device; the default address is 0x2c.
> +
> + vdd-supply:
> + description:
> + VDD power supply (2.5 V to 3.6 V). Powers all internal analog and
> + digital functional blocks.
Supply should be required. Devices need them to operate.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 04/10] clk: realtek: Add support for phase locked loops (PLLs)
From: Yu-Chun Lin @ 2026-04-10 7:53 UTC (permalink / raw)
To: bmasney
Cc: afaerber, conor+dt, cy.huang, cylee12, devicetree, eleanor.lin,
james.tai, jyanchou, krzk+dt, linux-arm-kernel, linux-clk,
linux-kernel, linux-realtek-soc, mturquette, p.zabel, robh, sboyd,
stanley_chang
In-Reply-To: <ac_SX1UJRqiBH2iM@redhat.com>
Hi Brian,
> Hi Cheng-Yu and Yu-Chun,
>
> On Thu, Apr 02, 2026 at 03:39:51PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Provide a full set of PLL operations for programmable PLLs and a read-only
> > variant for fixed or hardware-managed PLLs.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > +static int clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> > + unsigned long parent_rate)
> > +{
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > + const struct freq_table *fv;
> > + int ret;
> > +
> > + fv = ftbl_find_by_rate(clkp->freq_tbl, rate);
> > + if (!fv || fv->rate != rate)
> > + return -EINVAL;
> > +
> > + if (clkp->seq_pre_set_freq) {
> > + ret = regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_pre_set_freq,
> > + clkp->num_seq_pre_set_freq);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + ret = regmap_update_bits(clkp->clkr.regmap, clkp->freq_reg,
> > + clkp->freq_mask, fv->val);
> > + if (ret)
> > + return ret;
> > +
> > + if (clkp->seq_post_set_freq) {
> > + ret = regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_post_set_freq,
> > + clkp->num_seq_post_set_freq);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (is_power_on(clkp)) {
> > + ret = wait_freq_ready(clkp);
>
> I should have checked Sashiko before I hit send on my last review.
> https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> It suggested the following:
>
> In the Common Clock Framework, .set_rate executes under the prepare_lock
> mutex, while .enable and .disable execute under the enable_lock spinlock.
>
> Could an interleaved clk_pll_enable() corrupt the hardware state by running
> its seq_power_on sequence concurrently with these multi-step register
> updates?
>
> There also appears to be a potential race condition later in this function:
>
> if (is_power_on(clkp)) {
> ret = wait_freq_ready(clkp);
> ...
> }
>
> If .disable() powers off the PLL right before wait_freq_ready() is called,
> will wait_freq_ready() poll a disabled PLL and erroneously return
> -ETIMEDOUT? Is a private spinlock needed to serialize these operations?
>
> Brian
>
Agreed, I will add a private spinlock here.
Best Regards,
Yu-Chun
^ permalink raw reply
* [PATCH v2 0/2] cpufreq: spacemit: Add cpufreq support for K1 SoC
From: Shuwei Wu @ 2026-04-10 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
This series enables dynamic voltage and frequency scaling (DVFS) for
the SpacemiT K1 SoC using the generic cpufreq-dt driver.
Tested on Banana Pi BPI-F3, the execution time scales as expected
across different CPU frequencies:
~ # echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
~ # echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 1.07s
user 0m 1.07s
sys 0m 0.00s
~ # echo 1228800 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 1.40s
user 0m 1.40s
sys 0m 0.00s
~ # echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 1.72s
user 0m 1.72s
sys 0m 0.00s
~ # echo 819000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 2.10s
user 0m 2.10s
sys 0m 0.00s
~ # echo 614400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 2.80s
user 0m 2.80s
sys 0m 0.00s
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Changes in v2:
- Move OPP tables to dedicated k1-opp.dtsi
- Enable OPP only on BPI-F3 with cpu-supply present
- Link to v1: https://lore.kernel.org/r/20260308-shadow-deps-v1-0-0ceb5c7c07eb@mailbox.org
---
Shuwei Wu (2):
cpufreq: dt-platdev: Add SpacemiT K1 SoC to the allowlist
riscv: dts: spacemit: Add cpu scaling for K1 SoC
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
4 files changed, 148 insertions(+), 1 deletion(-)
---
base-commit: 5164e95565d3fd508ca8a95351323f5716dfb695
change-id: 20260307-shadow-deps-3582a78aa756
prerequisite-patch-id: 154bd4f720ce5065d58b988de8f273207b44572e
prerequisite-message-id: <20260206-spacemit-p1-v4-0-8f695d93811e@riscstar.com>
prerequisite-patch-id: 5da3e75b18291a5540d4f66d7a0600fb8975ef62
prerequisite-patch-id: bcf41917414ecef8cf743095d130f6004c32f6a5
prerequisite-patch-id: cfe3800f8c791ec4c63e070af9628e88e0fc31b9
prerequisite-message-id: <20260305-k1-clk-fix-v1-1-abca85d6e266@mailbox.org>
prerequisite-patch-id: 7c7fb9f87dba019ece4c97c45750349a7cd28f3a
Best regards,
--
Shuwei Wu <shuwei.wu@mailbox.org>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: media: Add bindings for qcom,x1p42100-camss
From: Bryan O'Donoghue @ 2026-04-10 7:59 UTC (permalink / raw)
To: Wenmeng Liu, Robert Foss, Todor Tomov, Vladimir Zapolskiy,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-1-eedcf6d9d8ee@oss.qualcomm.com>
On 10/04/2026 05:25, Wenmeng Liu wrote:
> 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>,
Is this the full extent of the VFE ? It looks like not to me.
For each register block please make sure you cover the _entire_ range of
the block not just the RDI part of it.
> + <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>,
_SRC clocks are generally not necessary, is this one ?
> + <&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>;
Please define which IOMMUs these are - I'd like to make sure the top
level node maps the IFE IOMMUs and not the ICP IOMMUs - as ICP should be
its own sub/separate node.
> +
> + 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>;
> + };
> + };
> + };
> + };
> + };
>
^ permalink raw reply
* [PATCH v2 1/2] cpufreq: dt-platdev: Add SpacemiT K1 SoC to the allowlist
From: Shuwei Wu @ 2026-04-10 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
In-Reply-To: <20260410-shadow-deps-v2-0-4e16b8c0f60e@mailbox.org>
The SpacemiT K1 SoC uses standard device tree based CPU frequency
scaling. Add it to the allowlist to instantiate the cpufreq-dt driver.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 25fd3b191b7e..31a64739df25 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -81,6 +81,7 @@ static const struct of_device_id allowlist[] __initconst = {
{ .have_governor_per_policy = true, },
},
+ { .compatible = "spacemit,k1", },
{ .compatible = "st-ericsson,u8500", },
{ .compatible = "st-ericsson,u8540", },
{ .compatible = "st-ericsson,u9500", },
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Shuwei Wu @ 2026-04-10 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
In-Reply-To: <20260410-shadow-deps-v2-0-4e16b8c0f60e@mailbox.org>
Add Operating Performance Points (OPP) tables and CPU clock properties
for the two clusters in the SpacemiT K1 SoC.
Also assign the CPU power supply (cpu-supply) for the Banana Pi BPI-F3
board to fully enable CPU DVFS.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Changes in v2:
- Add k1-opp.dtsi with OPP tables for both CPU clusters
- Assign CPU supplies and include OPP table for Banana Pi BPI-F3
---
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
3 files changed, 147 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 444c3b1e6f44..3780593f610d 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -5,6 +5,7 @@
#include "k1.dtsi"
#include "k1-pinctrl.dtsi"
+#include "k1-opp.dtsi"
/ {
model = "Banana Pi BPI-F3";
@@ -86,6 +87,38 @@ &combo_phy {
status = "okay";
};
+&cpu_0 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_1 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_2 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_3 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_4 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_5 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_6 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_7 {
+ cpu-supply = <&buck1_3v45>;
+};
+
&emmc {
bus-width = <8>;
mmc-hs400-1_8v;
@@ -201,7 +234,7 @@ pmic@41 {
dldoin2-supply = <&buck5>;
regulators {
- buck1 {
+ buck1_3v45: buck1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
new file mode 100644
index 000000000000..768ae390686d
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/ {
+ cluster0_opp_table: opp-table-cluster0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-819000000 {
+ opp-hz = /bits/ 64 <819000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1050000>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+ cluster1_opp_table: opp-table-cluster1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-819000000 {
+ opp-hz = /bits/ 64 <819000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1050000>;
+ clock-latency-ns = <200000>;
+ };
+ };
+};
+
+&cpu_0 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_1 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_2 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_3 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_4 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_5 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_6 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_7 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index 529ec68e9c23..bdd109b81730 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -54,6 +54,7 @@ cpu_0: cpu@0 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <0>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -84,6 +85,7 @@ cpu_1: cpu@1 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <1>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -114,6 +116,7 @@ cpu_2: cpu@2 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <2>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -144,6 +147,7 @@ cpu_3: cpu@3 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <3>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -174,6 +178,7 @@ cpu_4: cpu@4 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <4>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -204,6 +209,7 @@ cpu_5: cpu@5 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <5>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -234,6 +240,7 @@ cpu_6: cpu@6 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <6>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -264,6 +271,7 @@ cpu_7: cpu@7 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <7>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Herve Codina @ 2026-04-10 8:03 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Liam Girdwood, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <383635c6-0417-4333-aa9c-9056437d4a5f@sirena.org.uk>
Hi Mark, Rob,
On Thu, 9 Apr 2026 16:26:25 +0100
Mark Brown <broonie@kernel.org> wrote:
> > > I didn't want to set a particular limit related to the number of GPIOs
> > > used for thje gain value. Of course 2^32 is obviously a lot.
>
> > > What do you think about 16 for maxItems?
>
> > What is the most you are aware of? Take that and double it.
>
> > Seems to me 256 levels would be way more than a human ear could distinguish.
>
> There's plenty of gain controls with way more than 256 bits of
> resolution, though I'm not aware of any that are configured via GPIO.
> The step size and absolute values you want can vary dramatically
> depending on application, possibly in the same system (eg, a DAC that
> can be connected to both headphones or speakers) so you often end up
> making practical adjustments in a small subset of the available range
> but that subset can vary a lot for the same part.
Mark, do you think that max 16 GPIOs could be an acceptable limit?
IMHO, this value is large enough to be used as the limit.
>
> > I guess my point was that really we could deprecate simple-amplifier
> > binding because this one can handle it and more. But I'm not
> > suggesting we do that yet.
>
> That's my thinking.
Fine for me to, at the end, deprecate the simple-amplifier.
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: iio: magnetometer: Add binding for QST QMC5883P
From: Krzysztof Kozlowski @ 2026-04-10 8:06 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: <20260410-stimulating-happy-terrier-e82dcc@quoll>
On Fri, Apr 10, 2026 at 09:55:24AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Apr 09, 2026 at 09:07:29PM +0000, Hardik Phalet wrote:
> > Add the device tree binding document for the QST QMC5883P, a 3-axis
> > anisotropic magneto-resistive (AMR) sensor with a 16-bit ADC that
> > communicates over I2C. The binding exposes the required 'compatible'
> > and 'reg' properties along with an optional 'vdd-supply' for the
> > 2.5 V–3.6 V VDD rail.
>
> Drop last sentence. We can read the diff.
>
> ...
>
> > +properties:
> > + compatible:
> > + const: qst,qmc5883p
> > +
> > + reg:
> > + maxItems: 1
> > + description: I2C address of the device; the default address is 0x2c.
> > +
> > + vdd-supply:
> > + description:
> > + VDD power supply (2.5 V to 3.6 V). Powers all internal analog and
> > + digital functional blocks.
>
> Supply should be required. Devices need them to operate.
Ah, and since I expect new version, also:
A nit, subject: drop second/last, redundant "binding for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: media: Add bindings for qcom,x1p42100-camss
From: Bryan O'Donoghue @ 2026-04-10 8:06 UTC (permalink / raw)
To: Wenmeng Liu, Robert Foss, Todor Tomov, Vladimir Zapolskiy,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-1-eedcf6d9d8ee@oss.qualcomm.com>
On 10/04/2026 05:25, Wenmeng Liu wrote:
> + 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
> +
So if we still can't agree to get phys = in in the next kernel cycle,
then this scheme is acceptable but with the huge caveat that one
power-rail for each PHY is known to be wrong.
And I absolutely hate to continue to knowingly do the wrong thing...
---
bod
^ permalink raw reply
* Re: [PATCH v6 00/10] Add GPCDMA support in Tegra264
From: Jon Hunter @ 2026-04-10 8:09 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Laxman Dewangan, Philipp Zabel, dmaengine,
devicetree, linux-tegra, linux-kernel, Akhil R, Frank Li
In-Reply-To: <586052f6-d415-4603-accb-be15bad80db8@nvidia.com>
Hi Vinod,
On 31/03/2026 19:06, Jon Hunter wrote:
>
> On 31/03/2026 11:22, Akhil R wrote:
>> This series adds support for GPCDMA in Tegra264 with additional
>> support for separate stream ID for each channel. Tegra264 GPCDMA
>> controller has changes in the register offsets and uses 41-bit
>> addressing for memory. Add changes in the tegra186-gpc-dma driver
>> to support these.
>>
>> v5->v6:
>> - Replace dev_err() with dev_err_probe() in the probe function for fixed
>> return values also.
>> v4->v5:
>> - Use dev_err_probe() when returning error from the probe function.
>> - Remove tegra194 and tegra234 compatible from the reset 'if' condition
>> in the bindings as suggested in v2 (which I missed).
>> v3->v4:
>> - Split device tree changes to two patches.
>> - Reordered patches to have fixes first.
>> - Added fixes tag to dt-bindings and device tree changes.
>> v2->v3:
>> - Add description for iommu-map property and update commit descriptions.
>> - Use enum for compatible string instead of const.
>> - Remove unused registers from struct tegra_dma_channel_regs.
>> - Use devm_of_dma_controller_register() to register the DMA controller.
>> - Remove return value check for mask setting in the driver as the bitmask
>> value is always greater than 32.
>> v1->v2:
>> - Fix dt_bindings_check warnings
>> - Drop fallback compatible "nvidia,tegra186-gpcdma" from Tegra264 DT
>> - Use dma_addr_t for sg_req src/dst fields and drop separate high_add
>> variable and check for the addr_bits only when programming the
>> registers.
>> - Update address width to 39 bits for Tegra234 and before since the SMMU
>> supports only up to 39 bits till Tegra234.
>> - Add a patch to do managed DMA controller registration.
>> - Describe the second iteration in the probe.
>> - Update commit descriptions.
>>
>> Akhil R (10):
>> dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional
>> arm64: tegra: Remove fallback compatible for GPCDMA
>> dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property
>> dmaengine: tegra: Make reset control optional
>> dmaengine: tegra: Use struct for register offsets
>> dmaengine: tegra: Support address width > 39 bits
>> dmaengine: tegra: Use managed DMA controller registration
>> dmaengine: tegra: Use iommu-map for stream ID
>> dmaengine: tegra: Add Tegra264 support
>> arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
>>
>> .../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 32 +-
>> .../arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 4 +
>> arch/arm64/boot/dts/nvidia/tegra264.dtsi | 3 +-
>> drivers/dma/tegra186-gpc-dma.c | 429 +++++++++++-------
>> 4 files changed, 284 insertions(+), 184 deletions(-)
>>
>
> For the series ...
>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
I am not sure if it is too late to pick this up for v7.1, but we would
like to get this into -next if you are happy with it.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: purwa-iot-evk: Add camss node
From: Bryan O'Donoghue @ 2026-04-10 8:16 UTC (permalink / raw)
To: Wenmeng Liu, Robert Foss, Todor Tomov, Vladimir Zapolskiy,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-4-eedcf6d9d8ee@oss.qualcomm.com>
On 10/04/2026 05:25, Wenmeng Liu wrote:
> 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";
> +};
Hmm.
I don't agree with this. Enabling the CAMSS node with just the TPG is of
very low value to an end-user and doesn't "prove out" the CSIPHY, TPG
and RDI path - which is the minimum entry point in upstream right now.
I don't support less than a sensor at minimum.
You guys must have a sensor you've used with this board ?
---
bod
^ permalink raw reply
* [PATCH v2 0/2] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Konrad Dybcio, Dmitry Baryshkov
Add support for IPA v5.2 which can be found in the Milos SoC. And
finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
starts working.
Depends on:
* IPA v5.2 support
https://lore.kernel.org/linux-arm-msm/20260410-ipa-v5-2-v2-0-778422a05060@fairphone.com/T/
* Describe IMEM on Milos
https://lore.kernel.org/linux-arm-msm/20260410-milos-imem-v3-0-d215385fa5ab@fairphone.com/T/
I'd like to have specified these as b4 deps but somehow b4's behaving
quite weird with this series, adding many thousands of
prerequisite-patch-id, so I guess manually will need to be enough.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v2:
- Split net patches into a separate series
- Pick up tags
- Link to v1: https://patch.msgid.link/20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com
---
Luca Weiss (2):
arm64: dts: qcom: milos: Add IPA node
arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++
arch/arm64/boot/dts/qcom/milos.dtsi | 44 ++++++++++++++++++++++++
2 files changed, 53 insertions(+)
---
base-commit: 0190c2c6dae368aeb9bf59a449ebe23f24bfa059
change-id: 20260403-milos-ipa-e5705aa87245
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: qcom: milos: Add IPA node
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260410-milos-ipa-v2-0-c699b6b8cf27@fairphone.com>
Add the description of the IPA block in the Milos SoC.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos.dtsi | 44 +++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index a8536a873c69..9ef103d0e00c 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -1599,6 +1599,50 @@ adreno_smmu: iommu@3da0000 {
dma-coherent;
};
+ ipa: ipa@3f40000 {
+ compatible = "qcom,milos-ipa";
+
+ reg = <0x0 0x03f40000 0x0 0x10000>,
+ <0x0 0x03f50000 0x0 0x5000>,
+ <0x0 0x03e04000 0x0 0xfc000>;
+ reg-names = "ipa-reg",
+ "ipa-shared",
+ "gsi";
+
+ interrupts-extended = <&intc GIC_SPI 654 IRQ_TYPE_EDGE_RISING 0>,
+ <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH 0>,
+ <&smp2p_ipa_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&smp2p_ipa_in 1 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "ipa",
+ "gsi",
+ "ipa-clock-query",
+ "ipa-setup-ready";
+
+ clocks = <&rpmhcc RPMH_IPA_CLK>;
+ clock-names = "core";
+
+ interconnects = <&aggre2_noc MASTER_IPA QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &cnoc_main SLAVE_IPA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "memory",
+ "config";
+
+ iommus = <&apps_smmu 0x4a0 0x0>,
+ <&apps_smmu 0x4a2 0x0>;
+
+ qcom,qmp = <&aoss_qmp>;
+
+ qcom,smem-states = <&smp2p_ipa_out 0>,
+ <&smp2p_ipa_out 1>;
+ qcom,smem-state-names = "ipa-clock-enabled-valid",
+ "ipa-clock-enabled";
+
+ sram = <&ipa_modem_tables>;
+
+ status = "disabled";
+ };
+
remoteproc_mpss: remoteproc@4080000 {
compatible = "qcom,milos-mpss-pas";
reg = <0x0 0x04080000 0x0 0x10000>;
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss
In-Reply-To: <20260410-milos-ipa-v2-0-c699b6b8cf27@fairphone.com>
Configure and enable the node for IPA which enables mobile data on this
device.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
index c1899db46e71..31c6d6627619 100644
--- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
+++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
@@ -690,6 +690,15 @@ vreg_l7p: ldo7 {
/* AW86938FCR vibrator @ 0x5a */
};
+&ipa {
+ firmware-name = "qcom/milos/fairphone/fp6/ipa_fws.mbn";
+ memory-region = <&ipa_fw_mem>;
+
+ qcom,gsi-loader = "self";
+
+ status = "okay";
+};
+
&pm8550vs_c {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] arm64: dts: qcom: x1e80100-microsoft-romulus: add PM8010 camera regulators
From: Bryan O'Donoghue @ 2026-04-10 8:20 UTC (permalink / raw)
To: Oliver White, andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260409201717.108169-2-oliverjwhite07@gmail.com>
On 09/04/2026 21:17, Oliver White wrote:
> Add the PM8010 regulator outputs used by the front-facing OV02C10
> camera module on Microsoft Romulus.
>
> These rails provide the supplies referenced by the camera enablement patch.
>
> Signed-off-by: Oliver White <oliverjwhite07@gmail.com>
> ---
> .../dts/qcom/x1e80100-microsoft-romulus.dtsi | 52 +++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> index 14b5663a4d48..4427ecae423f 100644
> --- a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> +++ b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
> @@ -857,6 +857,57 @@ vreg_l3j: ldo3 {
> regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> };
> };
> +
> + regulators-8 {
> + compatible = "qcom,pm8010-rpmh-regulators";
> + qcom,pmic-id = "m";
> +
> + vdd-l1-l2-supply = <&vreg_s5j>;
> + vdd-l3-l4-supply = <&vreg_s4c>;
> + vdd-l7-supply = <&vreg_bob1>;
> +
> + vreg_l1m_1p2: ldo1 {
> + regulator-name = "vreg_l1m_1p2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1260000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l2m_1p2: ldo2 {
> + regulator-name = "vreg_l2m_1p2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1260000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l3m_1p8: ldo3 {
> + regulator-name = "vreg_l3m_1p8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l4m_1p8: ldo4 {
> + regulator-name = "vreg_l4m_1p8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l5m_2p8: ldo5 {
> + regulator-name = "vreg_l5m_2p8";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3072000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> +
> + vreg_l7m_2p8: ldo7 {
> + regulator-name = "vreg_l7m_2p8";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <3072000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
> + };
> + };
> };
>
> &gpu {
> @@ -867,6 +918,7 @@ &gpu_zap_shader {
> firmware-name = "qcom/x1e80100/microsoft/qcdxkmsuc8380.mbn";
> };
>
> +
> &i2c0 {
Dangling newline.
Can be fixed on application of the patch though.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
bod
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-04-10 8:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <3c57275e-0574-46e5-9893-053ae5cc22cb@kernel.org>
On 2026/4/10 下午2:42, Krzysztof Kozlowski wrote:
> On 10/04/2026 05:04, Hongliang Wang wrote:
>> Hi, Krzysztof
>>
>> On 2026/4/9 下午8:11, Krzysztof Kozlowski wrote:
>>> On 09/04/2026 14:03, Hongliang Wang wrote:
>>>> I have a question, the input clock of i2c controller can be described by
>>>> "clocks",
>>>> but there is no existing attribute can describe the divisor of the input
>>>> clock,
>>>> Can I define a new attribute named "clock-div" to describe it in DT
>>>> bindings?
>>>> or do you have any standard solutions for the divisor problem? Thank you.
>>>>
>>> You should determine/calculate the divisor in the driver code, depending
>>> on clocks and bus frequencies. You don't need a property for that, usually.
>> Not only clocks and bus frequencies, but also a third property is required.
>>
>> The frequency divison calculation formula of i2c is
>> Prcescale = clock_a/(clock_div*clock_s)-1
>>
>> There is three parameters in this formula:
>> clock_a represents the input clock, which is described by "clocks",
>> clock_s represents the i2c bus frequency, which is described by
>> "clock-frequency",
>> but there is no existing property to describe clock_div, which has
>> different value
>> on different platform (for example, it is 5 on 7a1000/7a2000, 4 on
>> 2K1000/2K2000,
>> 5.5 on 2K3000.), So I need a property to describe clock_div in this formula.
> So it is fixed per compatible? Then you do not need.
>
OK, I will fix the clock_div based on per compatible. thank you.
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH v6 05/10] clk: realtek: Add support for gate clock
From: Yu-Chun Lin @ 2026-04-10 8:19 UTC (permalink / raw)
To: bmasney
Cc: afaerber, conor+dt, cy.huang, cylee12, devicetree, eleanor.lin,
james.tai, jyanchou, krzk+dt, linux-arm-kernel, linux-clk,
linux-kernel, linux-realtek-soc, mturquette, p.zabel, robh, sboyd,
stanley_chang
In-Reply-To: <ac_RcGSpVBpt3S7C@redhat.com>
Hi Brian,
> Hi Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:52PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Introduce clk_regmap_gate_ops supporting enable, disable, is_enabled, and
> > disable_unused for standard regmap gate clocks.
>
> disable_unused is not implemented below.
>
Will remove it from commit message.
> >
> > Add clk_regmap_gate_ro_ops as a read-only variant exposing only is_enabled.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Add the headers used in c file to follow the "Include What You Use" principle.
> > ---
> > drivers/clk/realtek/Makefile | 2 +
> > drivers/clk/realtek/clk-regmap-gate.c | 69 +++++++++++++++++++++++++++
> > drivers/clk/realtek/clk-regmap-gate.h | 65 +++++++++++++++++++++++++
> > 3 files changed, 136 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-regmap-gate.c
> > create mode 100644 drivers/clk/realtek/clk-regmap-gate.h
> >
> > diff --git a/drivers/clk/realtek/Makefile b/drivers/clk/realtek/Makefile
> > index a89ad77993e9..74375f8127ac 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -2,5 +2,7 @@
> > obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
> >
> > clk-rtk-y += common.o
> > +
> > clk-rtk-y += clk-pll.o
> > +clk-rtk-y += clk-regmap-gate.o
> > clk-rtk-y += freq_table.o
> > diff --git a/drivers/clk/realtek/clk-regmap-gate.c b/drivers/clk/realtek/clk-regmap-gate.c
> > new file mode 100644
> > index 000000000000..8738d6c6f8dd
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-regmap-gate.c
> > @@ -0,0 +1,69 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2017 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com>
> > + */
> > +
> > +#include <linux/regmap.h>
> > +#include <linux/bits.h>
> > +#include "clk-regmap-gate.h"
> > +#include <linux/clk-provider.h>
>
> linux/clk-provider.h needs to be included before clk-regmap-gate.h.
>
Ack.
> Also Sashiko reports that linux/export.h should also be included.
https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> Brian
Ack.
Best Regards,
Yu-Chun.
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Jon Hunter @ 2026-04-10 8:25 UTC (permalink / raw)
To: Krzysztof Kozlowski, pshete, linux-gpio, devicetree, linux-tegra,
linux-kernel, arnd, bjorn.andersson, conor+dt, dmitry.baryshkov,
ebiggers, geert, krzk+dt, kuninori.morimoto.gx, linusw,
luca.weiss, michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp,
sven, thierry.reding, webgeek1234
In-Reply-To: <9408f231-7a12-425c-b8de-2990d3162bb3@kernel.org>
On 10/04/2026 07:37, Krzysztof Kozlowski wrote:
> On 09/04/2026 15:13, pshete@nvidia.com wrote:
>> From: Prathamesh Shete <pshete@nvidia.com>
>>
>> Building the Pinctrl driver into the kernel image increases its size.
>
> That's obvious.
>
>> These drivers are not required during early boot, build them as a loadable
>> module instead to reduce the kernel image size.
>
> So you replace built-in into module?
>>
>> Signed-off-by: Prathamesh Shete <pshete@nvidia.com>
>> ---
>> arch/arm64/configs/defconfig | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
>> index dd1ac01ee29b..f525670d3b84 100644
>> --- a/arch/arm64/configs/defconfig
>> +++ b/arch/arm64/configs/defconfig
>> @@ -711,6 +711,8 @@ CONFIG_PINCTRL_SC8280XP_LPASS_LPI=m
>> CONFIG_PINCTRL_SM8550_LPASS_LPI=m
>> CONFIG_PINCTRL_SM8650_LPASS_LPI=m
>> CONFIG_PINCTRL_SOPHGO_SG2000=y
>> +CONFIG_PINCTRL_TEGRA238=m
>> +CONFIG_PINCTRL_TEGRA264=m
>
> No, you just added as module. Why do we want them in upstream defconfig?
>
> Standard question, already asked Nvidia more than once.
Yes :-)
Prathamesh, what we need to do is ...
1. Add a patch to populate the pinctrl DT nodes for Tegra264 device.
2. In this patch, only enable pinctrl for Tegra264 because we are
lacking an upstream board for Tegra238 for that moment. In the commit
message we should add a comment to indicate with Tegra264 platform is
using this.
We can still merge the DT binding-doc changes and driver for Tegra238,
but no point to enable in the defconfig yet.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v4 2/3] thermal: spacemit: k1: Add thermal sensor support
From: Jie Gan @ 2026-04-10 8:25 UTC (permalink / raw)
To: Shuwei Wu, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, 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-2-12c87dd063c3@mailbox.org>
On 4/10/2026 11:31 AM, Shuwei Wu wrote:
> 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;
Consider passes high = INT_MAX here:
high = INT/1000 + TEMPERATURE_OFFSET == 2147761;
> + 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);
K1_TSENSOR_THRSH_HIGH_MASK is a 16-bit MASK:
FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, 2147761); <- overflow happened
the maximum value here will be changed to 50609 from 65536.
We should add a check here and limit the 'high' value here to avoid
overflow:
if (high > (int)((0xFFFF - TEMPERATURE_OFFSET) * 1000))
high = (0Xffff - TEMPERATURE_OFFSET) * 1000;
high = high / 1000 + TEMPERATURE_OFFSET;
...
> +
> + 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);
should call after the devm_request_threaded_irq succeeds;
Thanks,
Jie
> + }
> +
> + 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");
>
^ permalink raw reply
* RE: [PATCH v6 06/10] clk: realtek: Add support for mux clock
From: Yu-Chun Lin [林祐君] @ 2026-04-10 8:24 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <ac_UkRiqWb6fSc1I@redhat.com>
Hi Brian,
> Hi Yu-Chun and Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:53PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add a simple regmap-based clk_ops implementation for Realtek mux clocks.
> >
> > The implementation supports parent selection and rate determination
> > through regmap-backed register access.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Add the headers used in c file to follow the "Include What You Use"
> principle.
> > ---
> > drivers/clk/realtek/Makefile | 1 +
> > drivers/clk/realtek/clk-regmap-mux.c | 48
> > ++++++++++++++++++++++++++++ drivers/clk/realtek/clk-regmap-mux.h |
> > 43 +++++++++++++++++++++++++
> > 3 files changed, 92 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-regmap-mux.c
> > create mode 100644 drivers/clk/realtek/clk-regmap-mux.h
> >
> > diff --git a/drivers/clk/realtek/Makefile
> > b/drivers/clk/realtek/Makefile index 74375f8127ac..f90dc57fcfdb 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -5,4 +5,5 @@ clk-rtk-y += common.o
> >
> > clk-rtk-y += clk-pll.o
> > clk-rtk-y += clk-regmap-gate.o
> > +clk-rtk-y += clk-regmap-mux.o
> > clk-rtk-y += freq_table.o
> > diff --git a/drivers/clk/realtek/clk-regmap-mux.c
> > b/drivers/clk/realtek/clk-regmap-mux.c
> > new file mode 100644
> > index 000000000000..068b056d61f0
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-regmap-mux.c
> > @@ -0,0 +1,48 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2017 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include <linux/regmap.h>
> > +#include <linux/clk-provider.h>
>
> Sort the includes.
>
Ack.
> > +#include "clk-regmap-mux.h"
> > +
> > +static u8 clk_regmap_mux_get_parent(struct clk_hw *hw) {
> > + struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
> > + int num_parents = clk_hw_get_num_parents(hw);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(clkm->clkr.regmap, clkm->mux_ofs, &val);
> > + if (ret)
> > + return 0;
>
> This is another case where it'd be nice to get the get_parent declaration fixed.
> Stephen recently linked to some work of his from 2022 here.
>
> https://lore.kernel.org/linux-clk/177431305509.5403.15386021337517970667
> @lazor/
>
> There's nothing for you to do right now.
>
> > +
> > + val = val >> clkm->shift & clkm->mask;
>
> I know there's the order of operations, however for clarity I would just include
> some () here to make it clear the expected order.
Ack.
> > +
> > + if (val >= num_parents)
>
> Remove newline before if.
Ack.
>
> > + return 0;
> > +
> > + return val;
>
> Or you could just use a ternary operator:
>
> return val >= num_parents ? 0 : val;
>
Ack.
> > +}
> > +
> > +static int clk_regmap_mux_set_parent(struct clk_hw *hw, u8 index) {
> > + struct clk_regmap_mux *clkm = to_clk_regmap_mux(hw);
> > +
> > + return regmap_update_bits(clkm->clkr.regmap, clkm->mux_ofs,
> > + clkm->mask << clkm->shift, index <<
> > +clkm->shift); }
> > +
> > +const struct clk_ops rtk_clk_regmap_mux_ops = {
> > + .set_parent = clk_regmap_mux_set_parent,
> > + .get_parent = clk_regmap_mux_get_parent,
> > + .determine_rate = __clk_mux_determine_rate, };
> > +EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ops, "REALTEK_CLK");
> > +
> > +const struct clk_ops rtk_clk_regmap_mux_ro_ops = {
> > + .get_parent = clk_regmap_mux_get_parent, };
> > +EXPORT_SYMBOL_NS_GPL(rtk_clk_regmap_mux_ro_ops, "REALTEK_CLK");
>
> rtk_clk_regmap_mux_ro_ops is exported, however the declaration is not
> actually declared in any header files.
>
> Brian
Since it is currently unused, I will drop the 'rtk_clk_regmap_mux_ro_ops'
implementation.
Best Regards,
Yu-Chun.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox