* [PATCH v7 0/2] Add support for AD5706R DAC
From: Alexis Czezar Torreno @ 2026-04-10 6:48 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio, devicetree, linux-kernel, Alexis Czezar Torreno,
Krzysztof Kozlowski, Andy Shevchenko
This series adds support for the Analog Devices AD5706R, a 4-channel
16-bit current output digital-to-analog converter with SPI interface.
The AD5706R features:
- 4 independent current output DAC channels
- Configurable output ranges (50mA, 150mA, 200mA, 300mA)
- Hardware and software LDAC trigger with configurable edge selection
- Toggle and dither modes per channel
- Internal or external voltage reference selection
- PWM-controlled LDAC
- Dynamic change SPI speed
The driver exposes standard IIO raw/scale/offset channel attributes for
DAC output control, sampling frequency for PWM-based LDAC timing, and
extended attributes for device configuration including output range
selection, trigger mode, and multiplexer output.
This driver is developed and tested on the Cora Z7S platform using
the AXI SPI Engine and AXI CLKGEN IP cores. The 'clocks' property
enables dynamic SPI clock rate management via the CLKGEN.
Datasheet: https://www.analog.com/en/products/ad5706r.html
Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
---
Changes in v7:
- driver:
- Moved/added size validation before data access in write()/read()
- Link to v6: https://lore.kernel.org/r/20260410-dev_ad5706r-v6-0-f3fda5921fe4@analog.com
Changes in v6:
- driver:
- Added size validation in regmap_write()
- Used &st->tx_buf[0] consistently in _be32/be16 calls
- Added missing indent in AD5706R_CHAN
- Link to v5: https://lore.kernel.org/r/20260407-dev_ad5706r-v5-0-a4c7737b6ae9@analog.com
Changes in v5:
- dt-bindings:
- Changed out-en-gpios to enable-gpios
- driver:
- Kconfig: Added select REGMAP_SPI
- Headers: Removed device.h, errno.h, string.h; added dev_printk.h
- Use IIO_DMA_MINALIGN instead of ARCH_DMA_MINALIGN
- Replaced memcpy/memset with put_unaligned_be* for consistency
- Added struct device *dev shorthand in probe()
- other minor style edits
- Link to v4: https://lore.kernel.org/r/20260401-dev_ad5706r-v4-0-a785184a8d53@analog.com
Changes in v4:
- dt-bindings:
- Reverted pwm and gpio entries.
- Added missing power supply properties
- Clocks not added back as they were driver specific, not device
properties
- driver:
- Added missing includes
- Converted to use regmap with custom SPI bus implementation.
spi_write_then_read not applied as suggested, prevents future
need to change SPI speed
- removed driver speciifc mutex/guards in favor of regmap internal
locking
- Minor style cleanups
- Link to v3: https://lore.kernel.org/r/20260318-dev_ad5706r-v3-0-5d078f41e988@analog.com
Changes in v3:
- Added MAINTAINERS entry, files added on each patch
- dt-bindings:
- Added allOf and ref to spi-peripheral-props.yaml
- Changed additionalProperties to unevaluatedProperties
- Added avdd-supply property and added it to required
- driver:
- Removed redundant includes, added respective includes of APIs used
- Simplified bit manipulation in SPI read/write, used feedback from v2
- Fixed inconsistent trailing commas in device ID tables
- Removed zero initialization in spi_device_id
- Link to v2: https://lore.kernel.org/r/20260311-dev_ad5706r-v2-0-f367063dbd1b@analog.com
Changes in v2:
- Stripped driver down to basic DAC functionality (read/write raw,
read-only scale) as suggested.
- Removed PWM (LDAC), GPIO (reset/shutdown), clock generator,
SPI engine frequency switching, debugfs streaming, and all
custom ext_info sysfs attributes
- Removed regmap, IIO_BUFFER, and iio/sysfs.h dependencies
- Simplified SPI read/write to use standard spi_sync_transfer
without clock mode logic
- Scale reports default 50mA range as read-only using
IIO_VAL_FRACTIONAL_LOG2; writable range selection deferred
to future follow-up series
- Simplified DT binding to only require compatible, reg, and
spi-max-frequency
- Link to v1: https://lore.kernel.org/r/20260220-dev_ad5706r-v1-0-7253bbd74889@analog.com
---
Alexis Czezar Torreno (2):
dt-bindings: iio: dac: Add ADI AD5706R
iio: dac: ad5706r: Add support for AD5706R DAC
.../devicetree/bindings/iio/dac/adi,ad5706r.yaml | 105 +++++++++
MAINTAINERS | 8 +
drivers/iio/dac/Kconfig | 11 +
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ad5706r.c | 253 +++++++++++++++++++++
5 files changed, 378 insertions(+)
---
base-commit: 3674f3ca92730d9a07b42b311f1337d83c4d5605
change-id: 20260220-dev_ad5706r-2105e1dd29ab
Best regards,
--
Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Krzysztof Kozlowski @ 2026-04-10 6:42 UTC (permalink / raw)
To: Hongliang Wang
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <0f560e80-3fbb-c24f-51f9-b4425db17867@loongson.cn>
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.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Krzysztof Kozlowski @ 2026-04-10 6:39 UTC (permalink / raw)
To: Akhil R, Alexandre Belloni, Frank Li, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J . Wysocki,
Robert Moore, Len Brown, Guenter Roeck, Philipp Zabel,
Eric Biggers, Sakari Ailus, Wolfram Sang, Miquel Raynal,
linux-i3c, devicetree, linux-kernel, linux-acpi, acpica-devel,
linux-hwmon
In-Reply-To: <20260409105747.48158-14-akhilrajeev@nvidia.com>
On 09/04/2026 12:57, Akhil R wrote:
> Add I3C subsystem support, DesignWare I3C master controller, and
> SPD5118 hwmon sensor as modules to the defconfig and therefore
> enable the support for SPD5118 sensor on SOCAMM found in NVIDIA
> Vera platforms.
git grep for "Vera" gave me zero results. Are you sure this is an
upstream platform? Please point the DTS using this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/6] arm64: defconfig: make Tegra238 and Tegra264 Pinctrl a loadable module
From: Krzysztof Kozlowski @ 2026-04-10 6:37 UTC (permalink / raw)
To: pshete, linux-gpio, devicetree, linux-tegra, linux-kernel, arnd,
bjorn.andersson, conor+dt, dmitry.baryshkov, ebiggers, geert,
jonathanh, krzk+dt, kuninori.morimoto.gx, linusw, luca.weiss,
michal.simek, prabhakar.mahadev-lad.rj, robh, rosenp, sven,
thierry.reding, webgeek1234
In-Reply-To: <20260409131340.168556-7-pshete@nvidia.com>
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.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Krzysztof Kozlowski @ 2026-04-10 6:27 UTC (permalink / raw)
To: Karthik S, 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: <1c203ea9-c674-43b6-a2e5-87054a9e3b83@oss.qualcomm.com>
On 10/04/2026 07:38, Karthik S wrote:
>>>
>>> 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.
Still driver stuff. But another point is that kernel handles well always
on rails, so this property is completely redundant.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-10 6:27 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <adfQ6Tvst3Vd1Mxe@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
Hello Andrea,
On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > +{
> > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > + u32 value;
> > > +
> > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > + value &= ~PWM_MODE_MASK;
> > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > +
> > > + rp1_pwm_apply_config(chip, pwm);
> >
> > What is the purpose of this call?
>
> To update the configuration on the next PWM strobe in order to avoid
> glitches. I'll add a short comment in the code.
.pwm_free() should not touch the hardware configuration. Changing the
pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
somewhat a grey area. If that saves energy, that's okish. Otherwise
not interfering with the operation of the PWM (e.g. to keep a display on
during kexec or so) is preferred.
> > > +static int rp1_pwm_resume(struct device *dev)
> > > +{
> > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > +
> > > + return clk_prepare_enable(rp1->clk);
> >
> > Hmm, if this fails and then the driver is unbound, the clk operations
> > are not balanced.
>
> I'll add some flags to check if the clock is really enabled or not.
To be honest, I guess that is a problem of several drivers, not only in
drivers/pwm. If this complicates the driver, I guess addressing this
isn't very critical.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 09/13] i3c: dw-i3c-master: Add a quirk to skip clock and reset
From: Akhil R @ 2026-04-10 6:07 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: <adhkNYQW73yQ728h@lizhi-Precision-Tower-5810>
On Thu, 9 Apr 2026 22:45:09 -0400, Frank Li wrote:
> On Thu, Apr 09, 2026 at 04:27:39PM +0530, Akhil R wrote:
>> Some ACPI-enumerated devices like Tegra410 do not have clock and reset
>> resources exposed via the clk/reset frameworks. Add a match data for
>
> why not export fix clock at ACPI?
>
>> such devices to skip acquiring clock and reset controls during probe.
>>
>> Move match data parsing before clock/reset acquisition so the quirk is
>> available early enough. When the quirk is set, fall back to reading
>> the clock rate from the "clock-frequency" device property instead.
>
> "clock-frequency" is legacy proptery.
The document ACPI on ARMv8 Servers [1] suggests not to use clock or reset
framework at all. I also could not find any proper way to export the clock
to the kernel from the ACPI table. The same document suggests to use only
_DSD properties, if to pass any data to the kernel.
I can rename the property to 'default-clock-rate' if that sounds good.
Please let me know your suggestion.
[1]: https://www.kernel.org/doc/html/v6.1/arm64/arm-acpi.html#programmable-power-control-resources
Best Regards,
Akhil
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Anushka Badhe @ 2026-04-10 5:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: linux-sound, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Anushka Badhe
Convert the rockchip,rk3399-gru-sound.txt DT binding to DT Schema
format.
Update rockchip,cpu from a single I2S controller phandle to a
phandle-array. Add an optional second entry for the SPDIF controller,
as seen in rk3399-gru.dtsi, required by boards with DisplayPort audio.
Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
---
Changes in v2:
- Fix subject and body: "YAML Schema" -> "DT Schema"
- Fix title: "ROCKCHIP" -> "Rockchip"
- List items for rockchip,cpu with I2S and SPDIF descriptions
- List items for rockchip,codec
- Update descriptions for rockchip,cpu, rockchip,codec and
dmic-wakeup-delay-ms
.../sound/rockchip,rk3399-gru-sound.txt | 22 -------
.../sound/rockchip,rk3399-gru-sound.yaml | 60 +++++++++++++++++++
2 files changed, 60 insertions(+), 22 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
create mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
deleted file mode 100644
index 72d3cf4c2606..000000000000
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
-
-Required properties:
-- compatible: "rockchip,rk3399-gru-sound"
-- rockchip,cpu: The phandle of the Rockchip I2S controller that's
- connected to the codecs
-- rockchip,codec: The phandle of the audio codecs
-
-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
- If this option is specified, which means it's required dmic need
- delay for DMIC to ready so that rt5514 can avoid recording before
- DMIC send valid data
-
-Example:
-
-sound {
- compatible = "rockchip,rk3399-gru-sound";
- rockchip,cpu = <&i2s0>;
- rockchip,codec = <&max98357a &rt5514 &da7219>;
- dmic-wakeup-delay-ms = <20>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
new file mode 100644
index 000000000000..e9d13695cc77
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3399-gru-sound.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip with MAX98357A/RT5514/DA7219 codecs on GRU boards
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-gru-sound
+
+ rockchip,cpu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ List of phandles to the Rockchip CPU DAI controllers connected to codecs
+ minItems: 1
+ items:
+ - items:
+ - description: Phandle to the Rockchip I2S controllers
+ - items:
+ - description: |
+ Phandle to the Rockchip SPDIF controller. Required when a
+ DisplayPort audio codec is referenced in rockchip,codec
+
+ rockchip,codec:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ The phandles of the audio codecs connected to the Rockchip CPU DAI
+ controllers
+ minItems: 1
+ maxItems: 6
+ items:
+ maxItems: 1
+
+ dmic-wakeup-delay-ms:
+ description: |
+ specify delay time (ms) for DMIC ready.
+ If this option is specified, a delay is required for DMIC to get ready
+ so that rt5514 can avoid recording before DMIC sends valid data
+
+required:
+ - compatible
+ - rockchip,cpu
+ - rockchip,codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "rockchip,rk3399-gru-sound";
+ rockchip,cpu = <&i2s0 &spdif>;
+ rockchip,codec = <&max98357a &rt5514 &da7219 &cdn_dp>;
+ dmic-wakeup-delay-ms = <20>;
+ };
+
--
2.43.0
^ permalink raw reply related
* 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
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