* [PATCH v3 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
Add the T7 SOC compatible which fallback to AXG compatible.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
index c4cc8af182807..7b59b60b62e5b 100644
--- a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
@@ -16,10 +16,15 @@ allOf:
properties:
compatible:
- enum:
- - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
- - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
- - amlogic,meson-axg-i2c # AXG and compatible SoCs
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,t7-i2c
+ - const: amlogic,meson-axg-i2c
+ - enum:
+ - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
+ - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
+ - amlogic,meson-axg-i2c # AXG and compatible SoCs
reg:
maxItems: 1
--
2.49.0
^ permalink raw reply related
* [PATCH v3 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
In-Reply-To: <20260417-add-mcu-fan-khadas-vim4-v3-0-a6a7f570b11b@aliel.fr>
The Khadas VIM4 MCU register is slightly different
from previous boards' MCU.
This board also features a switchable power source for its fan.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
index 084960fd5a1fd..a80718f7595ce 100644
--- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
+++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
@@ -18,6 +18,7 @@ properties:
compatible:
enum:
- khadas,mcu # MCU revision is discoverable
+ - khadas,vim4-mcu # Different MCU variant, not discoverable
"#cooling-cells": # Only needed for boards having FAN control feature
const: 2
@@ -25,6 +26,10 @@ properties:
reg:
maxItems: 1
+ fan-supply:
+ description: Phandle to the regulator that powers the fan.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
required:
- compatible
- reg
--
2.49.0
^ permalink raw reply related
* [PATCH v3 0/8] Add VIM4 MCU/FAN support
From: Ronald Claveau @ 2026-04-17 16:27 UTC (permalink / raw)
To: Neil Armstrong, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andi Shyti, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Beniamino Galvani, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Liam Girdwood, Mark Brown
Cc: linux-amlogic, devicetree, linux-kernel, linux-i2c,
linux-arm-kernel, linux-pm, Ronald Claveau
The Khadas VIM4 board features a different MCU variant compared to
previous VIM boards.
While it shares the same I2C-based communication model,
it differs in some ways:
- A distinct register map with its own volatile/writeable register set
- A fan control with 0–100 levels instead of the 0–3 levels previously
- A fan power supply gated through a regulator
This series adds support for this new variant by:
1. Refactoring the khadas-mcu MFD driver to use per-variant data
structures (regmap config, cells, fan platform data),
and adding the khadas,vim4-mcu compatible string.
2. Extending the fan thermal driver to retrieve the fan register
and maximum level from platform_data,
and to optionally manage a power regulator for the fan supply.
3. Adding the corresponding DTS node for the VIM4, wiring the MCU to
the I2C AO_A bus and exposing it as a thermal cooling device.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Changes in v3:
- PATCH 1: adding comment on vim4 compatible saying it is not discoverable,
thanks to Rob's and Neil's feedback.
- Link to v2: https://lore.kernel.org/r/20260403-add-mcu-fan-khadas-vim4-v2-0-70536b22439a@aliel.fr
Changes in v2:
- PATCH 5: Add regulator_disable on suspend thanks to Neil's feedback.
- Link to v1: https://lore.kernel.org/r/20260402-add-mcu-fan-khadas-vim4-v1-0-2b12eb4ac7b0@aliel.fr
---
Ronald Claveau (8):
dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
dt-bindings: i2c: amlogic: Add compatible for T7 SOC
mfd: khadas-mcu: Add per-variant configuration infrastructure and VIM4 support
mfd: khadas-mcu: Add support for VIM4 MCU variant
thermal: khadas-mcu-fan: Add fan config from platform data Add regulator support
arm64: dts: amlogic: t7: Add i2c pinctrl node
arm64: dts: amlogic: t7: Add i2c controller node
arm64: dts: amlogic: t7: khadas-vim4: Add i2c MCU fan node
.../bindings/i2c/amlogic,meson6-i2c.yaml | 13 ++-
.../devicetree/bindings/mfd/khadas,mcu.yaml | 5 +
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 13 +++
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 20 ++++
drivers/mfd/khadas-mcu.c | 106 ++++++++++++++++++---
drivers/thermal/khadas_mcu_fan.c | 49 ++++++++--
include/linux/mfd/khadas-mcu.h | 39 +++++++-
7 files changed, 222 insertions(+), 23 deletions(-)
---
base-commit: f7b64ed948718290209074a50bb0df17e5944873
change-id: 20260402-add-mcu-fan-khadas-vim4-ac1cbe553c9b
prerequisite-message-id: <20260326092645.1053261-1-jian.hu@amlogic.com>
prerequisite-patch-id: f03a086b4137158412b2d47b3de793b858de8dde
prerequisite-patch-id: 123970c9b29c2090440f2fd71c85d3c6fd8e36de
prerequisite-patch-id: 3e2e56b0926ba327b520f935df4ced5089bbe503
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-change-id: 20260326-add-bcm43752-compatible-e264a4f7973a:v2
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-change-id: 20260330-fix-invalid-property-bbe54d933f71:v2
prerequisite-patch-id: 8d675e7a239985c762843515b241f0a2f45f9c92
prerequisite-change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4:v1
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
prerequisite-patch-id: 9debd88fa60febed9cd7208f86603b4c2d270520
prerequisite-patch-id: 314ef9ff0c4d1d15dab1dea9d92aa065f1eac3e9
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Cristian Ciocaltea @ 2026-04-17 16:34 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <2000470.6tgchFWduM@phil>
Hi Heiko,
On 4/17/26 2:32 PM, Heiko Stuebner wrote:
> Hi Cristian,
>
> the comments below apply sort of to all patches in that series.
>
> Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> The board exposes the GPIO4_C6 line to control the voltage bias on the
>> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
>> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
>>
>> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
>> property and drop the line from the vcc_5v0_hdmi regulator to allow
>> adjusting the bias when transitioning between TMDS and FRL operating
>> modes.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> index 749f0a54b478..93ae37699366 100644
>> --- a/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> +++ b/arch/arm64/boot/dts/rockchip/rk3576-luckfox-core3576.dtsi
>> @@ -140,10 +140,7 @@ regulator-state-mem {
>>
>> vcc_5v0_hdmi: regulator-vcc-5v0-hdmi {
>> compatible = "regulator-fixed";
>> - enable-active-high;
>> - gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_HIGH>;
>> - pinctrl-names = "default";
>> - pinctrl-0 = <&hdmi_con_en>;
>> + regulator-always-on;
>> regulator-min-microvolt = <5000000>;
>> regulator-max-microvolt = <5000000>;
>> regulator-name = "vcc_5v0_hdmi";
>
> I think this regulator was sort of a complete hack, to set that
> gpio to some sort of default state, by declaring it as hdmi-pwr-supply.
>
> Only 2 rk3576 boards seem, to use that hack, so I think as that "regulator"
> is completely functionless now, the whole thing could be removed?
Ack, let's just drop it.
>
>
>> @@ -231,6 +228,8 @@ &gpu {
>> };
>>
>> &hdmi {
>> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
>> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
>
> this should be sorted the other way around I think.
>
> Also please provide a pinctrl-names property too. If for whatever reason
> the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
> board DTs are staying in the "old" compatible mode until they are adapted.
Just to make sure I fully understand, the convention is that
pinctrl-names = "default";
should be always provided, even when the node overrides an existing pinctrl-0
property?
E.g. in rk3576.dtsi we have:
hdmi: hdmi@27da0000 {
...
pinctrl-names = "default";
pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
...
}
Hence I omitted pinctrl-names which doesn't change and just appended
&hdmi_frl_en to pinctrl-0's original value.
>
>
>> status = "okay";
>> };
>>
>> @@ -655,7 +654,7 @@ &pcie0 {
>>
>> &pinctrl {
>> hdmi {
>> - hdmi_con_en: hdmi-con-en {
>> + hdmi_frl_en: hdmi-frl-en {
>
> pinctrl names should ideally match the naming in schematics, for example the
> "HDMI0_TX_ON_H" for jaguar and tiger. This makes it way easier to> go from DT
> to schematics and back.
I opted for a more descriptive name that could be used consistently across all
boards, given that not all schematics are publicly available.
You make a fair point though, we should probably stick with the pretty terrible
hdmi[N]_tx_on_h naming instead.
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: hwmon: pmbus: add max20830
From: Conor Dooley @ 2026-04-17 16:24 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Shuah Khan, linux-hwmon, devicetree,
linux-kernel, linux-doc
In-Reply-To: <20260417-dev_max20830-v3-1-0cb8d56067aa@analog.com>
[-- Attachment #1: Type: text/plain, Size: 490 bytes --]
On Fri, Apr 17, 2026 at 04:27:13PM +0800, Alexis Czezar Torreno wrote:
> Add device tree documentation for MAX20830 step-down DC-DC switching
> regulator with PMBus interface.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
In the future, please relax a bit with new revisions, particularly
during the merge window when nothing is gonna get applied and there's no
urgency.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Conor Dooley @ 2026-04-17 16:22 UTC (permalink / raw)
To: Jianhua Lin
Cc: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel, linux-media,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu
In-Reply-To: <20260417100519.1043-2-jianhua.lin@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 3203 bytes --]
On Fri, Apr 17, 2026 at 06:05:17PM +0800, Jianhua Lin wrote:
> Add the compatible string for the JPEG decoder block found in the
> MediaTek MT8189 SoC.
>
> Compared to previous generation ICs, the MT8189 JPEG decoder requires
> 34-bit IOVA address space support and only needs a single clock
> ("jpgdec") instead of two. Therefore, it is added as a standalone
> compatible string without falling back to older SoCs.
>
> Update the binding schema to include the new compatible string and add
> an `allOf` block with conditional checks. This enforces the single clock
> requirement for MT8189 while preserving the two-clock requirement
> ("jpgdec-smi", "jpgdec") for older SoCs.
>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
> 1 file changed, 40 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> index a4aacd3eb189..fd895688a038 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> @@ -15,10 +15,10 @@ description: |-
> properties:
> compatible:
> oneOf:
> - - items:
> - - enum:
> - - mediatek,mt8173-jpgdec
> - - mediatek,mt2701-jpgdec
> + - enum:
> + - mediatek,mt2701-jpgdec
> + - mediatek,mt8173-jpgdec
> + - mediatek,mt8189-jpgdec
> - items:
> - enum:
> - mediatek,mt7623-jpgdec
> @@ -32,13 +32,20 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> maxItems: 2
> - minItems: 2
>
> clock-names:
> - items:
> - - const: jpgdec-smi
> - - const: jpgdec
> + oneOf:
> + - items:
> + - const: jpgdec
> + - items:
> + - const: jpgdec-smi
> + - const: jpgdec
> +
> + mediatek,larb:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: a phandle to the smi_larb node.
This should be restricted to only the new platform.
>
> power-domains:
> maxItems: 1
> @@ -60,6 +67,31 @@ required:
> - power-domains
> - iommus
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: mediatek,mt8189-jpgdec
> + then:
> + properties:
> + clocks:
> + minItems: 1
> + maxItems: 1
Constraints that duplicate the outtermost ones don't need to
be/shouldn't be repeated here. You only need the maxItems here and the
minItems in the else.
pw-bot: changes-requested
Cheers,
COnor.
> + clock-names:
> + minItems: 1
> + maxItems: 1
> + required:
> + - mediatek,larb
> + else:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 2
> + clock-names:
> + minItems: 2
> + maxItems: 2
> +
> additionalProperties: false
>
> examples:
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: display: panel: Add compatibles for Zhunyi Z40046
From: Conor Dooley @ 2026-04-17 16:19 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: dri-devel, Jagan Teki, Neil Armstrong, Jessica Zhang,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Marek Vasut, Kael D'Alcamo, Lad Prabhakar,
devicetree, linux-kernel
In-Reply-To: <20260417104740.259689-2-l.scorcia@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]
On Fri, Apr 17, 2026 at 11:46:30AM +0100, Luca Leonardo Scorcia wrote:
> The Zhunyi Z40046 is a 480x800 24-bit WVGA DSI panel based on the
> Fitipower JD9161Z DSI controller found in the Xiaomi Mi Smart Clock
> x04g, apparently in two different variants.
>
> The Fitipower JD9161Z LCD driver IC is very similar to the Jadard
> JD9365DA-H3, it just uses a different initialization sequence.
>
> Since this is the first supported device from this vendor, document its
> name to the vendor-prefixes.yaml file as well.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
> ---
> .../devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml | 2 ++
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> index e39efb44ed42..158388a284d9 100644
> --- a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
> @@ -24,6 +24,8 @@ properties:
> - radxa,display-10hd-ad001
> - radxa,display-8hd-ad002
> - taiguanck,xti05101-01a
> + - zhunyikeji,z40046-ctc
> + - zhunyikeji,z40046-boe
> - const: jadard,jd9365da-h3
>
> reg:
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 6339988e3805..debaec59e9a0 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1923,6 +1923,8 @@ patternProperties:
> description: Zealz
> "^zeitec,.*":
> description: ZEITEC Semiconductor Co., LTD.
> + "^zhunyikeji,.*":
> + description: Shenzhen Zhunyi Technology Co., Ltd.
> "^zidoo,.*":
> description: Shenzhen Zidoo Technology Co., Ltd.
> "^zii,.*":
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: timer: econet: Update EN751627 for multi-IRQ
From: Conor Dooley @ 2026-04-17 16:17 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-mips, naseefkm, daniel.lezcano, tglx, robh, krzk+dt,
conor+dt, linux-kernel, devicetree
In-Reply-To: <20260416175101.958073-2-cjd@cjdns.fr>
[-- Attachment #1: Type: text/plain, Size: 2853 bytes --]
On Thu, Apr 16, 2026 at 05:51:00PM +0000, Caleb James DeLisle wrote:
> From conception, this driver supported EN751627 as it is the same
> hardware that is used in EN751221. However, it was expected that
> EN751627 would use a percpu IRQ as does EN751221, this is how it
> works in vendor code. However upon finding that the "mti,gic" intc
> works on EN751627 with no modification - but it provides a unique
> interrupt per-timer, it is deemed best to make this driver use
> multiple IRQs when on the EN751627 platform.
Please drop mention of drivers here, bindings are about hardware,
whether or not the driver uses 1 or 4 interrupts doesn't matter, the
binding should have 4 because the hardware has 4.
pw-bot: changes-requested
Otherwise, this looks fine, so with that stuff culled
Acked-by: Conor Dooley <conor.dooley@microchip.com>
>
> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
> ---
> .../bindings/timer/econet,en751221-timer.yaml | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml b/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
> index c1e7c2b6afde..f338739e039c 100644
> --- a/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
> +++ b/Documentation/devicetree/bindings/timer/econet,en751221-timer.yaml
> @@ -28,8 +28,8 @@ properties:
> maxItems: 2
>
> interrupts:
> - maxItems: 1
> - description: A percpu-devid timer interrupt shared across CPUs.
> + minItems: 1
> + maxItems: 4
>
> clocks:
> maxItems: 1
> @@ -52,21 +52,31 @@ allOf:
> items:
> - description: VPE timers 0 and 1
> - description: VPE timers 2 and 3
> + interrupts:
> + description: An interrupt for each timer (one per VPE)
> + minItems: 4
> else:
> properties:
> reg:
> items:
> - description: VPE timers 0 and 1
> + interrupts:
> + description: A percpu-devid timer interrupt shared across timers
> + maxItems: 1
>
> additionalProperties: false
>
> examples:
> - |
> + #include <dt-bindings/interrupt-controller/mips-gic.h>
> timer@1fbf0400 {
> compatible = "econet,en751627-timer", "econet,en751221-timer";
> reg = <0x1fbf0400 0x100>, <0x1fbe0000 0x100>;
> interrupt-parent = <&intc>;
> - interrupts = <30>;
> + interrupts = <GIC_SHARED 30 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SHARED 29 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SHARED 37 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SHARED 36 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&hpt_clock>;
> };
> - |
> --
> 2.39.5
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: counter: add gpio-quadrature-encoder binding
From: Conor Dooley @ 2026-04-17 16:13 UTC (permalink / raw)
To: Wadim Mueller
Cc: wbg, robh, krzk+dt, conor+dt, linux-iio, devicetree, linux-kernel
In-Reply-To: <1663eb2f4bf4c826cd190fa9974fb55c321e7073.1776372319.git.wafgo01@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]
On Thu, Apr 16, 2026 at 10:48:17PM +0200, Wadim Mueller wrote:
> Add devicetree binding documentation for the GPIO-based quadrature
> encoder counter driver. The driver reads A/B quadrature signals and
> an optional index pulse via edge-triggered GPIO interrupts, supporting
> X1, X2, X4 quadrature decoding and pulse-direction mode.
>
> This is useful on SoCs that lack a dedicated hardware quadrature
> decoder or where the encoder is wired to generic GPIO pins.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> ---
> .../counter/gpio-quadrature-encoder.yaml | 69 +++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/counter/gpio-quadrature-encoder.yaml
>
> diff --git a/Documentation/devicetree/bindings/counter/gpio-quadrature-encoder.yaml b/Documentation/devicetree/bindings/counter/gpio-quadrature-encoder.yaml
> new file mode 100644
> index 000000000..a52deaab6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/counter/gpio-quadrature-encoder.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/counter/gpio-quadrature-encoder.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GPIO-based Quadrature Encoder
> +
> +maintainers:
> + - Wadim Mueller <wadim.mueller@cmblu.de>
> +
> +description: |
> + A generic GPIO-based quadrature encoder counter. Reads A/B quadrature
> + signals and an optional index pulse via edge-triggered GPIO interrupts.
> + Supports X1, X2, X4 quadrature decoding and pulse-direction mode.
> +
> + This driver is useful on SoCs that lack a dedicated hardware quadrature
> + decoder (eQEP, QEI, etc.) or where the encoder is wired to generic GPIO
> + pins rather than to a dedicated peripheral.
Idea seems okay to me. Please rephrase this section to avoid talking
about drivers...
> +
> +properties:
> + compatible:
> + const: gpio-quadrature-encoder
> +
> + encoder-a-gpios:
> + maxItems: 1
> + description:
> + GPIO connected to the encoder's A (phase A) output.
> +
> + encoder-b-gpios:
> + maxItems: 1
> + description:
> + GPIO connected to the encoder's B (phase B) output.
> +
> + encoder-index-gpios:
> + maxItems: 1
> + description:
> + Optional GPIO connected to the encoder's index (Z) output.
> + When the index input is enabled via sysfs, the count resets
> + to zero on each index pulse.
...and this to stop talking about sysfs and driver behaviour though.
Bindings are about hardware.
pw-bot: changes-requested
> +
> +required:
> + - compatible
> + - encoder-a-gpios
> + - encoder-b-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + quadrature-encoder-0 {
> + compatible = "gpio-quadrature-encoder";
> + encoder-a-gpios = <&gpio0 10 GPIO_ACTIVE_HIGH>;
> + encoder-b-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>;
> + };
> +
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> +
> + quadrature-encoder-1 {
> + compatible = "gpio-quadrature-encoder";
> + encoder-a-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
> + encoder-b-gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;
> + encoder-index-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
> + };
I think this example alone is sufficient btw.
Cheers,
Conor.
> +
> +...
> --
> 2.52.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: reserved-memory: Change maintainer for BPMP SHMEM
From: Conor Dooley @ 2026-04-17 16:09 UTC (permalink / raw)
To: Thierry Reding
Cc: Aaro Koskinen, Geert Uytterhoeven, linux-tegra, linux-arm-kernel,
linux-pm, linux-omap, linux-m68k, devicetree, linux-kernel
In-Reply-To: <20260417131549.3154534-3-thierry.reding@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
On Fri, Apr 17, 2026 at 03:15:48PM +0200, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> Peter sadly passed away a while ago, so change the maintainers for BPMP
> SHMEM to Jon and myself.
>
> Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: iio: dac: mcp47feb02: Fix maxItems value for reg property
From: Conor Dooley @ 2026-04-17 16:08 UTC (permalink / raw)
To: David Lechner
Cc: Ariana Lazar, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Conor Dooley,
Jonathan Cameron, linux-iio, devicetree, linux-kernel
In-Reply-To: <120a34be-bc0d-4202-9996-c5da8cf15963@baylibre.com>
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
On Fri, Apr 17, 2026 at 10:26:42AM -0500, David Lechner wrote:
> On 4/17/26 8:38 AM, Ariana Lazar wrote:
> > Change maxItems value from 8 to 1 for the channel number reg property.
>
> The commit message needs to explain why this is the correct thing to do.
With that,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: changes-requested
>
> >
> > Fixes: 4ba12d304175 ("dt-bindings: iio: dac: adding support for Microchip MCP47FEB02")
> > Link: https://lore.kernel.org/all/20260403-speed-childless-1360de358229@spud/
> > Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
> > ---
> > Changes in v2:
> > - keep just maxItems value update in this patch
> > - remove Reported-by from commit message
> > - Link to v1: https://lore.kernel.org/r/20260416-mcp47feb02-fix5-v1-1-9656c2fed6d2@microchip.com
> > ---
> > Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> > index d2466aa6bda2106a8b695347a0edf38462294d03..f2efa0ccbaa32482dcdc69d98c1565518538793f 100644
> > --- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> > +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> > @@ -161,8 +161,7 @@ patternProperties:
> > properties:
> > reg:
> > description: The channel number.
> > - minItems: 1
> > - maxItems: 8
> > + maxItems: 1
> >
> > label:
> > description: Unique name to identify which channel this is.
> >
> > ---
> > base-commit: d2a4ec19d2a2e54c23b5180e939994d3da4a6b91
> > change-id: 20260416-mcp47feb02-fix5-26994c5b428c
> >
> > Best regards,
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Conor Dooley @ 2026-04-17 16:06 UTC (permalink / raw)
To: Billy Tsai
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <OSQPR06MB7252EB0C2A1A3313DE49406B8B202@OSQPR06MB7252.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]
On Fri, Apr 17, 2026 at 02:20:25AM +0000, Billy Tsai wrote:
> > > + properties:
> > > + function:
> > > + enum:
> > > + - EMMC
> > > + - JTAGDDR
> > > + - JTAGM0
> > > + - JTAGPCIEA
> > > + - JTAGPCIEB
> > > + - JTAGPSP
> > > + - JTAGSSP
> > > + - JTAGTSP
> > > + - JTAGUSB3A
> > > + - JTAGUSB3B
> > > + - PCIERC0PERST
> > > + - PCIERC1PERST
> > > + - TSPRSTN
> > > + - UFSCLKI
> > > + - USB2AD0
> > > + - USB2AD1
> > > + - USB2AH
> > > + - USB2AHP
> > > + - USB2AHPD0
> > > + - USB2AXH
> > > + - USB2AXH2B
> > > + - USB2AXHD1
> > > + - USB2AXHP
> > > + - USB2AXHP2B
> > > + - USB2AXHPD1
> > > + - USB2BD0
> > > + - USB2BD1
> > > + - USB2BH
> > > + - USB2BHP
> > > + - USB2BHPD0
> > > + - USB2BXH
> > > + - USB2BXH2A
> > > + - USB2BXHD1
> > > + - USB2BXHP
> > > + - USB2BXHP2A
> > > + - USB2BXHPD1
> > > + - USB3AXH
> > > + - USB3AXH2B
> > > + - USB3AXHD
> > > + - USB3AXHP
> > > + - USB3AXHP2B
> > > + - USB3AXHPD
> > > + - USB3BXH
> > > + - USB3BXH2A
> > > + - USB3BXHD
> > > + - USB3BXHP
> > > + - USB3BXHP2A
> > > + - USB3BXHPD
> > > + - VB
> > > + - VGADDC
> > > +
> > > + groups:
> > > + enum:
> > > + - EMMCCDN
> > > + - EMMCG1
> > > + - EMMCG4
> > > + - EMMCG8
> > > + - EMMCWPN
> > > + - JTAG0
> > > + - PCIERC0PERST
> > > + - PCIERC1PERST
> > > + - TSPRSTN
> > > + - UFSCLKI
> > > + - USB2A
> > > + - USB2AAP
> > > + - USB2ABP
> > > + - USB2ADAP
> > > + - USB2AH
> > > + - USB2AHAP
> > > + - USB2B
> > > + - USB2BAP
> > > + - USB2BBP
> > > + - USB2BDBP
> > > + - USB2BH
> > > + - USB2BHBP
> > > + - USB3A
> > > + - USB3AAP
> > > + - USB3ABP
> > > + - USB3B
> > > + - USB3BAP
> > > + - USB3BBP
> > > + - VB0
> > > + - VB1
> > > + - VGADDC
> > > + pins:
> > > + enum:
> > > + - AB13
> > > + - AB14
> > > + - AC13
> > > + - AC14
> > > + - AD13
> > > + - AD14
> > > + - AE13
> > > + - AE14
> > > + - AE15
> > > + - AF13
> > > + - AF14
> > > + - AF15
>
> > Why do you have groups and pins?
>
> > Is it valid in your device to have groups and pins in the same node?
>
> The intent is to support both group-based mux selection and
> configuration, as well as per-pin configuration.
>
> In our hardware:
>
> - `function` + `groups` are used for pinmux selection.
> - `pins` is used for per-pin configuration (e.g. drive strength,
> bias settings).
> - `groups` may also be used for group-level configuration.
>
> As a result, both `groups` and `pins` may appear in the same node,
> but they serve different purposes and do not conflict:
>
> - `groups` selects the mux function and may apply configuration to
> the entire group.
> - `pins` allows overriding or specifying configuration for individual
> pins.
>
> In most cases, only one of them is needed, but both are allowed when
> both group-level and per-pin configuration are required.
To be honest, that sounds like your groups are not sufficiently
granular and should be reduced such that you can use them for pin
settings.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 08/11] media: iris: Add power sequence for Glymur
From: Vishnu Reddy @ 2026-04-17 16:04 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu
In-Reply-To: <1de1a366-a325-428e-9dcc-1333bb85ed82@oss.qualcomm.com>
On 4/14/2026 3:19 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> Add power sequence hooks for controller, vcodec and vcodec1. reuse the
>> existing code where ever is possible. add vcodec1 power on and off code
>> separately which has different power domains and clocks.
>>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> .../platform/qcom/iris/iris_platform_common.h | 9 ++
>> drivers/media/platform/qcom/iris/iris_vpu3x.c | 123 +++++++++++++++++++++
>> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
>> .../platform/qcom/iris/iris_vpu_register_defines.h | 7 ++
>> 4 files changed, 140 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> index 30e9d4d288c6..e3c1aff770dd 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> @@ -61,6 +61,9 @@ enum platform_clk_type {
>> IRIS_VPP0_HW_CLK,
>> IRIS_VPP1_HW_CLK,
>> IRIS_APV_HW_CLK,
>> + IRIS_AXI_VCODEC1_CLK,
>> + IRIS_VCODEC1_CLK,
>> + IRIS_VCODEC1_FREERUN_CLK,
>> };
>>
>> struct platform_clk_data {
>> @@ -208,6 +211,12 @@ enum platform_pm_domain_type {
>> IRIS_CTRL_POWER_DOMAIN,
>> IRIS_VCODEC_POWER_DOMAIN,
>> IRIS_VPP0_HW_POWER_DOMAIN,
>> + /*
>> + * On Glymur, vcodec1 power domain is at the same index in pd_devs[]
>> + * as IRIS_VPP0_HW_POWER_DOMAIN. Alias it so that the Glymur power
>> + * domain table is indexed correctly.
>> + */
>> + IRIS_VCODEC1_POWER_DOMAIN = IRIS_VPP0_HW_POWER_DOMAIN,
> This feels really fragile..
I'm thinking to add wrapper and use the power domain name to find the
index from the
platform data instead of using the enum values. I'll try this if that works.
> [...]
>
>> +static bool iris_vpu36_hw1_power_collapsed(struct iris_core *core)
>> +{
>> + u32 value, pwr_status;
>> +
>> + value = readl(core->reg_base + WRAPPER_CORE_POWER_STATUS);
>> + pwr_status = value & BIT(4);
>> +
>> + return pwr_status ? false : true;
> return !pwr_status
Ack.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH 10/11] media: iris: Add platform data for glymur
From: Vishnu Reddy @ 2026-04-17 15:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <zieokmtef7z4sqle7dgy4rv7t3egcgzji5fwrogc7pz4sz4msa@gthghxow3gkf>
On 4/14/2026 9:35 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:30:06AM +0530, Vishnu Reddy wrote:
>> Add glymur platform data by reusing most of the SM8550 definitions.
>> Move configuration that differs in a per-SoC platform specific data.
>>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/Makefile | 1 +
>> .../platform/qcom/iris/iris_platform_common.h | 1 +
>> .../media/platform/qcom/iris/iris_platform_gen2.c | 100 +++++++++++++++++++++
>> .../platform/qcom/iris/iris_platform_glymur.c | 93 +++++++++++++++++++
>> .../platform/qcom/iris/iris_platform_glymur.h | 17 ++++
>> drivers/media/platform/qcom/iris/iris_probe.c | 4 +
>> 6 files changed, 216 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/iris/Makefile b/drivers/media/platform/qcom/iris/Makefile
>> index 6f4052b98491..677513c7c045 100644
>> --- a/drivers/media/platform/qcom/iris/Makefile
>> +++ b/drivers/media/platform/qcom/iris/Makefile
>> @@ -11,6 +11,7 @@ qcom-iris-objs += iris_buffer.o \
>> iris_hfi_gen2_response.o \
>> iris_hfi_queue.o \
>> iris_platform_gen2.o \
>> + iris_platform_glymur.o \
>> iris_power.o \
>> iris_probe.o \
>> iris_resources.o \
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_common.h b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> index aeb70f54be10..a279ea462ee6 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_common.h
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_common.h
>> @@ -41,6 +41,7 @@ enum pipe_type {
>> PIPE_4 = 4,
>> };
>>
>> +extern const struct iris_platform_data glymur_data;
>> extern const struct iris_platform_data qcs8300_data;
>> extern const struct iris_platform_data sc7280_data;
>> extern const struct iris_platform_data sm8250_data;
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_gen2.c b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> index 47c6b650f0b4..fa2115092be8 100644
>> --- a/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_gen2.c
>> @@ -12,6 +12,7 @@
>> #include "iris_vpu_buffer.h"
>> #include "iris_vpu_common.h"
>>
>> +#include "iris_platform_glymur.h"
>> #include "iris_platform_qcs8300.h"
>> #include "iris_platform_sm8650.h"
>> #include "iris_platform_sm8750.h"
>> @@ -921,6 +922,105 @@ static const u32 sm8550_enc_op_int_buf_tbl[] = {
>> BUF_SCRATCH_2,
>> };
>>
>> +const struct iris_platform_data glymur_data = {
> If you add a platform-specific file, then move the data to the file too.
glymur_data reusing the most of the sm8550 definitions which is in this
source file.
one option is to introduce gen2 header file and extern all the glymur
required definitions
in that. glymur source can include that gen2 header.
> Also, please use iris_something prefix for all your visible symbols.
Ack, I'll add iris prefix.
>> + .get_instance = iris_hfi_gen2_get_instance,
>> + .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>> + .init_hfi_response_ops = iris_hfi_gen2_response_ops_init,
>> + .get_vpu_buffer_size = iris_vpu_buf_size,
>> + .vpu_ops = &iris_vpu36_ops,
>> + .set_preset_registers = iris_set_sm8550_preset_registers,
>> + .init_cb_devs = glymur_init_cb_devs,
>> + .deinit_cb_devs = glymur_deinit_cb_devs,
>> + .icc_tbl = sm8550_icc_table,
>> + .icc_tbl_size = ARRAY_SIZE(sm8550_icc_table),
>> + .clk_rst_tbl = glymur_clk_reset_table,
>> + .clk_rst_tbl_size = ARRAY_SIZE(glymur_clk_reset_table),
>> + .bw_tbl_dec = sm8550_bw_table_dec,
>> + .bw_tbl_dec_size = ARRAY_SIZE(sm8550_bw_table_dec),
>> + .pmdomain_tbl = glymur_pmdomain_table,
>> + .pmdomain_tbl_size = ARRAY_SIZE(glymur_pmdomain_table),
>> + .opp_pd_tbl = sm8550_opp_pd_table,
>> + .opp_pd_tbl_size = ARRAY_SIZE(sm8550_opp_pd_table),
>> + .clk_tbl = glymur_clk_table,
>> + .clk_tbl_size = ARRAY_SIZE(glymur_clk_table),
>> + .opp_clk_tbl = glymur_opp_clk_table,
>> + /* Upper bound of DMA address range */
>> + .dma_mask = 0xffe00000 - 1,
>> + .fwname = "qcom/vpu/vpu36_p4_s7.mbn",
>> + .pas_id = IRIS_PAS_ID,
>> + .dual_core = true,
>> + .inst_iris_fmts = platform_fmts_sm8550_dec,
>> + .inst_iris_fmts_size = ARRAY_SIZE(platform_fmts_sm8550_dec),
>> + .inst_caps = &platform_inst_cap_sm8550,
>> + .inst_fw_caps_dec = inst_fw_cap_sm8550_dec,
>> + .inst_fw_caps_dec_size = ARRAY_SIZE(inst_fw_cap_sm8550_dec),
>> + .inst_fw_caps_enc = inst_fw_cap_sm8550_enc,
>> + .inst_fw_caps_enc_size = ARRAY_SIZE(inst_fw_cap_sm8550_enc),
>> + .tz_cp_config_data = tz_cp_config_glymur,
>> + .tz_cp_config_data_size = ARRAY_SIZE(tz_cp_config_glymur),
>> + .core_arch = VIDEO_ARCH_LX,
>> + .hw_response_timeout = HW_RESPONSE_TIMEOUT_VALUE,
>> + .ubwc_config = &ubwc_config_sm8550,
>> + .num_vpp_pipe = 4,
>> + .max_session_count = 16,
>> + .max_core_mbpf = NUM_MBS_8K * 2,
>> + .max_core_mbps = ((8192 * 4320) / 256) * 60,
>> + .dec_input_config_params_default =
>> + sm8550_vdec_input_config_params_default,
>> + .dec_input_config_params_default_size =
>> + ARRAY_SIZE(sm8550_vdec_input_config_params_default),
>> + .dec_input_config_params_hevc =
>> + sm8550_vdec_input_config_param_hevc,
>> + .dec_input_config_params_hevc_size =
>> + ARRAY_SIZE(sm8550_vdec_input_config_param_hevc),
>> + .dec_input_config_params_vp9 =
>> + sm8550_vdec_input_config_param_vp9,
>> + .dec_input_config_params_vp9_size =
>> + ARRAY_SIZE(sm8550_vdec_input_config_param_vp9),
>> + .dec_input_config_params_av1 =
>> + sm8550_vdec_input_config_param_av1,
>> + .dec_input_config_params_av1_size =
>> + ARRAY_SIZE(sm8550_vdec_input_config_param_av1),
>> + .dec_output_config_params =
>> + sm8550_vdec_output_config_params,
>> + .dec_output_config_params_size =
>> + ARRAY_SIZE(sm8550_vdec_output_config_params),
>> +
>> + .enc_input_config_params =
>> + sm8550_venc_input_config_params,
>> + .enc_input_config_params_size =
>> + ARRAY_SIZE(sm8550_venc_input_config_params),
>> + .enc_output_config_params =
>> + sm8550_venc_output_config_params,
>> + .enc_output_config_params_size =
>> + ARRAY_SIZE(sm8550_venc_output_config_params),
>> +
>> + .dec_input_prop = sm8550_vdec_subscribe_input_properties,
>> + .dec_input_prop_size = ARRAY_SIZE(sm8550_vdec_subscribe_input_properties),
>> + .dec_output_prop_avc = sm8550_vdec_subscribe_output_properties_avc,
>> + .dec_output_prop_avc_size =
>> + ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_avc),
>> + .dec_output_prop_hevc = sm8550_vdec_subscribe_output_properties_hevc,
>> + .dec_output_prop_hevc_size =
>> + ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_hevc),
>> + .dec_output_prop_vp9 = sm8550_vdec_subscribe_output_properties_vp9,
>> + .dec_output_prop_vp9_size =
>> + ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_vp9),
>> + .dec_output_prop_av1 = sm8550_vdec_subscribe_output_properties_av1,
>> + .dec_output_prop_av1_size =
>> + ARRAY_SIZE(sm8550_vdec_subscribe_output_properties_av1),
>> +
>> + .dec_ip_int_buf_tbl = sm8550_dec_ip_int_buf_tbl,
>> + .dec_ip_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_ip_int_buf_tbl),
>> + .dec_op_int_buf_tbl = sm8550_dec_op_int_buf_tbl,
>> + .dec_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_dec_op_int_buf_tbl),
>> +
>> + .enc_ip_int_buf_tbl = sm8550_enc_ip_int_buf_tbl,
>> + .enc_ip_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_ip_int_buf_tbl),
>> + .enc_op_int_buf_tbl = sm8550_enc_op_int_buf_tbl,
>> + .enc_op_int_buf_tbl_size = ARRAY_SIZE(sm8550_enc_op_int_buf_tbl),
>> +};
>> +
>> const struct iris_platform_data sm8550_data = {
>> .get_instance = iris_hfi_gen2_get_instance,
>> .init_hfi_command_ops = iris_hfi_gen2_command_ops_init,
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_glymur.c b/drivers/media/platform/qcom/iris/iris_platform_glymur.c
>> new file mode 100644
>> index 000000000000..64b150db9f73
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_glymur.c
>> @@ -0,0 +1,93 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#include <dt-bindings/media/qcom,glymur-iris.h>
>> +#include "iris_core.h"
>> +#include "iris_platform_common.h"
>> +#include "iris_platform_glymur.h"
>> +
>> +#define VIDEO_REGION_SECURE_FW_REGION_ID 0
>> +#define VIDEO_REGION_VM0_SECURE_NP_ID 1
>> +#define VIDEO_REGION_VM0_NONSECURE_NP_ID 5
> These are not glymur-specific, are they?
It's common for upcoming platforms as well. I'll move this to common
platform header.
>> +
>> +const struct platform_clk_data glymur_clk_table[] = {
>> + {IRIS_AXI_VCODEC_CLK, "iface" },
>> + {IRIS_CTRL_CLK, "core" },
>> + {IRIS_VCODEC_CLK, "vcodec0_core" },
>> + {IRIS_AXI_CTRL_CLK, "iface_ctrl" },
>> + {IRIS_CTRL_FREERUN_CLK, "core_freerun" },
>> + {IRIS_VCODEC_FREERUN_CLK, "vcodec0_core_freerun" },
>> + {IRIS_AXI_VCODEC1_CLK, "iface1" },
>> + {IRIS_VCODEC1_CLK, "vcodec1_core" },
>> + {IRIS_VCODEC1_FREERUN_CLK, "vcodec1_core_freerun" },
>> +};
>> +
>> +const char * const glymur_clk_reset_table[] = {
>> + "bus0",
>> + "bus_ctrl",
>> + "core",
>> + "vcodec0_core",
>> + "bus1",
>> + "vcodec1_core",
>> +};
>> +
>> +const char * const glymur_opp_clk_table[] = {
>> + "vcodec0_core",
>> + "vcodec1_core",
>> + "core",
>> + NULL,
>> +};
>> +
>> +const char * const glymur_pmdomain_table[] = {
>> + "venus",
>> + "vcodec0",
>> + "vcodec1",
>> +};
>> +
>> +const struct tz_cp_config tz_cp_config_glymur[] = {
>> + {
>> + .cp_start = VIDEO_REGION_SECURE_FW_REGION_ID,
>> + .cp_size = 0,
>> + .cp_nonpixel_start = 0,
>> + .cp_nonpixel_size = 0x1000000,
>> + },
>> + {
>> + .cp_start = VIDEO_REGION_VM0_SECURE_NP_ID,
>> + .cp_size = 0,
>> + .cp_nonpixel_start = 0x1000000,
>> + .cp_nonpixel_size = 0x24800000,
>> + },
>> + {
>> + .cp_start = VIDEO_REGION_VM0_NONSECURE_NP_ID,
>> + .cp_size = 0,
>> + .cp_nonpixel_start = 0x25800000,
>> + .cp_nonpixel_size = 0xda600000,
>> + },
>> +};
>> +
>> +int glymur_init_cb_devs(struct iris_core *core)
>> +{
>> + const u32 f_id = IRIS_FIRMWARE;
>> + struct device *dev;
>> +
>> + dev = iris_create_cb_dev(core, "iris_firmware", &f_id);
>> + if (IS_ERR(dev))
>> + return PTR_ERR(dev);
>> +
>> + if (device_iommu_mapped(dev))
>> + core->dev_fw = dev;
>> + else
>> + device_unregister(dev);
>> +
>> + return 0;
>> +}
>> +
>> +void glymur_deinit_cb_devs(struct iris_core *core)
>> +{
>> + if (core->dev_fw)
>> + device_unregister(core->dev_fw);
>> +
>> + core->dev_fw = NULL;
> Why do you need to set it to NULL?
Not needed, I'll drop it.
Thanks,
Vishnu Reddy.
>> +}
>> diff --git a/drivers/media/platform/qcom/iris/iris_platform_glymur.h b/drivers/media/platform/qcom/iris/iris_platform_glymur.h
>> new file mode 100644
>> index 000000000000..03c83922f0d9
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/iris/iris_platform_glymur.h
>> @@ -0,0 +1,17 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (c) Qualcomm Innovation Center, Inc. All rights reserved.
>> + */
>> +
>> +#ifndef __IRIS_PLATFORM_GLYMUR_H__
>> +#define __IRIS_PLATFORM_GLYMUR_H__
>> +
>> +extern const struct platform_clk_data glymur_clk_table[9];
>> +extern const char * const glymur_clk_reset_table[6];
>> +extern const char * const glymur_opp_clk_table[4];
>> +extern const char * const glymur_pmdomain_table[3];
>> +extern const struct tz_cp_config tz_cp_config_glymur[3];
>> +int glymur_init_cb_devs(struct iris_core *core);
>> +void glymur_deinit_cb_devs(struct iris_core *core);
>> +
>> +#endif
>> diff --git a/drivers/media/platform/qcom/iris/iris_probe.c b/drivers/media/platform/qcom/iris/iris_probe.c
>> index 34751912f871..53869d9113d5 100644
>> --- a/drivers/media/platform/qcom/iris/iris_probe.c
>> +++ b/drivers/media/platform/qcom/iris/iris_probe.c
>> @@ -369,6 +369,10 @@ static const struct dev_pm_ops iris_pm_ops = {
>> };
>>
>> static const struct of_device_id iris_dt_match[] = {
>> + {
>> + .compatible = "qcom,glymur-iris",
>> + .data = &glymur_data,
>> + },
>> {
>> .compatible = "qcom,qcs8300-iris",
>> .data = &qcs8300_data,
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 09/11] media: iris: Add support to select core for dual core platforms
From: Vishnu Reddy @ 2026-04-17 15:36 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu
In-Reply-To: <d1834575-768e-4805-9e21-50a796690bda@oss.qualcomm.com>
On 4/14/2026 3:21 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> Select the hardware core (vcodec) for a session, based on load when the
>> platform supports dual vcodec cores. Assign the session to vcodec if its
>> MBPF/MBPS capacity allows it, otherwise assign to vcodec1. Communicate
>> the selected vcodec core to firmware using new HFI_PROP_CORE_ID property.
>>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
> [...]
>
>> + if (core_mbpf[0] + new_mbpf <= max_core_mbpf)
>> + inst->core_id = BIT(0);
>> + else if (dual_core && core_mbpf[1] + new_mbpf <= max_core_mbpf)
>> + inst->core_id = BIT(1);
> Let's store the core ID as an index and only wrap it in BIT() where
> necessary to pass into the firmware
For the current instance, I'm marking the inst->core_id = 0 at initial
to skip that current inst
for the calculation of current load. If we store index in core_id, then
need to pass the current
inst to iris_get_core_load() and additional check required in that
function for proper core load.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 15:29 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu, stable
In-Reply-To: <otikvdonnfakykra57z4fingdyfm7xebw2h3lmykzk6sbk7emq@xptiwpx5lvjl>
On 4/14/2026 8:50 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:30:02AM +0530, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
> Does this apply to Glymur only or to other platforms too?
Only Glymur firmware is currently reading this register and other
platform firmwares are
ignoring this.
Thanks,
Vishnu Reddy.
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
>>
>> Fixes: abf5bac63f68a ("media: iris: implement the boot sequence of the firmware")
>> Cc:stable@vger.kernel.org
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/iris_vpu_common.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> index 548e5f1727fd..bfd1e762c38e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> @@ -78,7 +78,6 @@ int iris_vpu_boot_firmware(struct iris_core *core)
>> iris_vpu_setup_ucregion_memory_map(core);
>>
>> writel(ctrl_init, core->reg_base + CTRL_INIT);
>> - writel(0x1, core->reg_base + CPU_CS_SCIACMDARG3);
>>
>> while (!ctrl_status && count < max_tries) {
>> ctrl_status = readl(core->reg_base + CTRL_STATUS);
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 06/11] media: iris: Fix VM count passed to firmware
From: Vishnu Reddy @ 2026-04-17 15:28 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu, stable
In-Reply-To: <20260414063325.f3yag6gnmaysddkp@hu-mojha-hyd.qualcomm.com>
On 4/14/2026 12:03 PM, Mukesh Ojha wrote:
> On Tue, Apr 14, 2026 at 10:30:02AM +0530, Vishnu Reddy wrote:
>> On Glymur, firmware interprets the value written to CPU_CS_SCIACMDARG3 as
>> the number of virtual machines (VMs) and internally adds 1 to it. Writing
>> 1 causes firmware to treat it as 2 VMs. Since only one VM is required,
>> remove this write to leave the register at its reset value of 0. This does
>> not affect other platforms as only Glymur firmware uses this register,
>> earlier platform firmwares ignore it.
>>
>> Fixes: abf5bac63f68a ("media: iris: implement the boot sequence of the firmware")
>> Cc:stable@vger.kernel.org
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
> If this is a fix, should be the first patch in the series., so that it
> can be applied independently.
Ack, I'll move it accordingly.
>> ---
>> drivers/media/platform/qcom/iris/iris_vpu_common.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> index 548e5f1727fd..bfd1e762c38e 100644
>> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
>> @@ -78,7 +78,6 @@ int iris_vpu_boot_firmware(struct iris_core *core)
>> iris_vpu_setup_ucregion_memory_map(core);
>>
>> writel(ctrl_init, core->reg_base + CTRL_INIT);
>> - writel(0x1, core->reg_base + CPU_CS_SCIACMDARG3);
>>
>> while (!ctrl_status && count < max_tries) {
>> ctrl_status = readl(core->reg_base + CTRL_STATUS);
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 05/11] media: iris: Enable Secure PAS support with IOMMU managed by Linux
From: Vishnu Reddy @ 2026-04-17 15:27 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Vikash Garodia,
Dikshita Agarwal, Abhinav Kumar, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joerg Roedel,
Will Deacon, Robin Murphy, Bjorn Andersson, Konrad Dybcio,
Stefan Schmidt, Hans Verkuil
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel, iommu,
Mukesh Ojha
In-Reply-To: <809e2ad6-258c-49ac-9f3b-4ced32807203@oss.qualcomm.com>
On 4/14/2026 7:39 PM, Konrad Dybcio wrote:
> On 4/14/26 7:00 AM, Vishnu Reddy wrote:
>> From: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
>>
>> Most Qualcomm platforms feature a proprietary hypervisor (such as Gunyah
>> or QHEE), which typically handles IOMMU configuration. This includes
>> mapping memory regions and device memory resources for remote processors
>> by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are
>> later removed during teardown. Additionally, SHM bridge setup is required
>> to enable memory protection for both remoteproc metadata and its memory
>> regions.
>>
>> When the hypervisor is absent, the operating system must perform these
>> configurations instead.
>>
>> Support for handling IOMMU and SHM setup in the absence of a hypervisor
>> is now in place. Extend the Iris driver to enable this functionality on
>> platforms where IOMMU is managed by Linux (i.e., non-Gunyah, non-QHEE).
>>
>> Additionally, the Iris driver must map the firmware and its required
>> resources to the firmware SID, which is now specified via iommu-map in
>> the device tree.
>>
>> Co-developed-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
> [...]
>
>> static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> {
>> + struct device *dev = core->dev_fw ? core->dev_fw : core->dev;
> Maybe:
>
> struct device *fw_dev = core->dev_fw ?: core->dev;
>
> and preserve *dev to be the main Iris device?
That's better, ack.
Thanks,
Vishnu Reddy.
> Konrad
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: iio: dac: mcp47feb02: Fix maxItems value for reg property
From: David Lechner @ 2026-04-17 15:26 UTC (permalink / raw)
To: Ariana Lazar, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Conor Dooley, Jonathan Cameron, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260417-mcp47feb02-fix5-v2-1-6592ea499cce@microchip.com>
On 4/17/26 8:38 AM, Ariana Lazar wrote:
> Change maxItems value from 8 to 1 for the channel number reg property.
The commit message needs to explain why this is the correct thing to do.
>
> Fixes: 4ba12d304175 ("dt-bindings: iio: dac: adding support for Microchip MCP47FEB02")
> Link: https://lore.kernel.org/all/20260403-speed-childless-1360de358229@spud/
> Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
> ---
> Changes in v2:
> - keep just maxItems value update in this patch
> - remove Reported-by from commit message
> - Link to v1: https://lore.kernel.org/r/20260416-mcp47feb02-fix5-v1-1-9656c2fed6d2@microchip.com
> ---
> Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> index d2466aa6bda2106a8b695347a0edf38462294d03..f2efa0ccbaa32482dcdc69d98c1565518538793f 100644
> --- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> @@ -161,8 +161,7 @@ patternProperties:
> properties:
> reg:
> description: The channel number.
> - minItems: 1
> - maxItems: 8
> + maxItems: 1
>
> label:
> description: Unique name to identify which channel this is.
>
> ---
> base-commit: d2a4ec19d2a2e54c23b5180e939994d3da4a6b91
> change-id: 20260416-mcp47feb02-fix5-26994c5b428c
>
> Best regards,
^ permalink raw reply
* Re: [PATCH 02/16] dt-bindings: interrupt-controller: Describe EIP-201 AIC
From: Aleksander Jan Bajkowski @ 2026-04-17 15:22 UTC (permalink / raw)
To: Miquel Raynal
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc
In-Reply-To: <87tstac9fn.fsf@bootlin.com>
Hi Miquel,
On 17/04/2026 09:50, Miquel Raynal wrote:
> Hi Aleksander,
>
> On 16/04/2026 at 20:04:03 +02, Aleksander Jan Bajkowski <olek2@wp.pl> wrote:
>
>> Hi Miquel,
>>
>> On 27/03/2026 21:09, Miquel Raynal (Schneider Electric) wrote:
>>> diff --git
>>> a/include/dt-bindings/interrupt-controller/inside-secure,safexcel-eip201.h
>>> b/include/dt-bindings/interrupt-controller/inside-secure,safexcel-eip201.h
>>> new file mode 100644
>>> index 000000000000..ead73bd96296
>>> --- /dev/null
>>> +++ b/include/dt-bindings/interrupt-controller/inside-secure,safexcel-eip201.h
>>> @@ -0,0 +1,14 @@
>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
>>> +
>>> +#ifndef _DT_BINDINGS_IRQ_SAFEXCEL_EIP201_AIC_H
>>> +#define _DT_BINDINGS_IRQ_SAFEXCEL_EIP201_AIC_H
>>> +
>>> +#define AIC_PKA_INT0 0
>>> +#define AIC_PKA_INT1 1
>>> +#define AIC_PKA_INT2 2
>>> +#define AIC_TRNG_INT 3
>>> +#define AIC_RESERVED 4
>>> +#define AIC_SL_ERR_INT 5
>>> +#define AIC_PROTECTION_INT 6
>>> +
>>> +#endif
>> This interrupt mapping is specific to the EIP-150. The EIP-201 is also
>> integrated
>> into other accelerators, such as the EIP-97, EIP-196, and EIP-197, and the
>> interrupt mapping is likely different there. Maybe it would be better to use
>> eip150 name instead of eip201?
> Thanks a lot for the heads up, I didn't had that information, I will
> adapt the naming to make it more accurate future proof.
>
>> As for EIP-28, it is also part of EIP-94. EIP-94 is supported by the
>> amcc driver.
>> EIP-94 consists of four components:
>> * crypto accelerator (unnamed?),
>> * PRNG (EIP-73d),
>> * TRNG (unnamed?),
>> * PKA (EIP-28).
>> Only the first three components are supported by the amcc driver.
> Is this driver upstream? I didn't find it. Anyhow, thanks for the
> feedback, I will update with this knowledge in mind.
You can find the driver in the drivers/crypto/amcc directory. It contains
no references to EIP-94. It’s likely that when it was added, it wasn’t
clear that it was a generic IP core.
A while ago, I was looking for information about the PRNGs built into
Rambus crypto accelerators. I found out that all these accelerators are
made up of blocks and have some common components.
EIP-93:
* PE (various IP cores),
* PRNG (EIP-73a),
* Interrupt controller (unnamed?)
EIP-94:
* PE (various IP cores),
* PRNG (EIP-73d),
* TRNG (unnamed?),
* PKA (EIP-28),
* Interrupt Controller (unnamed?).
EIP-97:
* PE (EIP-96)
* AIC (EIP-201),
* PRNG (EIP-73d),
* HIA (EIP-202),
* PP (EIP-206).
EIP-196:
* PE (EIP-96)
* AIC (EIP-201),
* PRNG (EIP-73d),
* HIA (EIP-202),
* PP (EIP-206).
EIP-197:
* PE (EIP-96)
* AIC (EIP-201),
* PRNG (EIP-74),
* HIA (EIP-202),
* PP (EIP-206),
* ICE/OCE (EIP-207),
* Buffers (EIP-208).
You can find some documentation online:
* EIP-93:
https://www.analog.com/media/en/dsp-documentation/processor-manuals/BF70x_BlackfinProcessorHardwareReference.pdf
* EIP-94:
https://www.scribd.com/document/734250956/Safexcel-Ip-94-Plb-Sas-v1-5
* EIP-96:
https://www.scribd.com/document/665924605/Security-IP-96-HW4-6-Hardware-Reference-and-Programmer-Manual-RevB
* EIP-197:
https://www.scribd.com/document/665924595/Security-IP-197-HW3-4-Hardware-Reference-Manual-RevA
Best regards,
Aleksander
^ permalink raw reply
* Re: [PATCH 05/11] media: iris: Enable Secure PAS support with IOMMU managed by Linux
From: Vishnu Reddy @ 2026-04-17 15:20 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <20260414063128.6ass64wfi7nmtzti@hu-mojha-hyd.qualcomm.com>
On 4/14/2026 12:01 PM, Mukesh Ojha wrote:
> On Tue, Apr 14, 2026 at 10:30:01AM +0530, Vishnu Reddy wrote:
>> From: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
>>
>> Most Qualcomm platforms feature a proprietary hypervisor (such as Gunyah
>> or QHEE), which typically handles IOMMU configuration. This includes
>> mapping memory regions and device memory resources for remote processors
>> by intercepting qcom_scm_pas_auth_and_reset() calls. These mappings are
>> later removed during teardown. Additionally, SHM bridge setup is required
>> to enable memory protection for both remoteproc metadata and its memory
>> regions.
>>
>> When the hypervisor is absent, the operating system must perform these
>> configurations instead.
>>
>> Support for handling IOMMU and SHM setup in the absence of a hypervisor
>> is now in place. Extend the Iris driver to enable this functionality on
>> platforms where IOMMU is managed by Linux (i.e., non-Gunyah, non-QHEE).
>>
>> Additionally, the Iris driver must map the firmware and its required
>> resources to the firmware SID, which is now specified via iommu-map in
>> the device tree.
>>
>> Co-developed-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Mukesh Ojha<mukesh.ojha@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/iris_core.h | 4 ++
>> drivers/media/platform/qcom/iris/iris_firmware.c | 71 +++++++++++++++++++++---
>> 2 files changed, 66 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_core.h b/drivers/media/platform/qcom/iris/iris_core.h
>> index fb194c967ad4..aa7abef6f0e0 100644
>> --- a/drivers/media/platform/qcom/iris/iris_core.h
>> +++ b/drivers/media/platform/qcom/iris/iris_core.h
>> @@ -34,6 +34,8 @@ enum domain_type {
>> * struct iris_core - holds core parameters valid for all instances
>> *
>> * @dev: reference to device structure
>> + * @dev_fw: reference to the context bank device used for firmware load
>> + * @ctx_fw: SCM PAS context for authenticated firmware load and shutdown
>> * @reg_base: IO memory base address
>> * @irq: iris irq
>> * @v4l2_dev: a holder for v4l2 device structure
>> @@ -77,6 +79,8 @@ enum domain_type {
>>
>> struct iris_core {
>> struct device *dev;
>> + struct device *dev_fw;
>> + struct qcom_scm_pas_context *ctx_fw;
> fw_dev suits better and ctx_fw is always for firmware, maybe pas_ctx is
> better.
Ack
>> void __iomem *reg_base;
>> int irq;
>> struct v4l2_device v4l2_dev;
>> diff --git a/drivers/media/platform/qcom/iris/iris_firmware.c b/drivers/media/platform/qcom/iris/iris_firmware.c
>> index 5f408024e967..93d77996c83f 100644
>> --- a/drivers/media/platform/qcom/iris/iris_firmware.c
>> +++ b/drivers/media/platform/qcom/iris/iris_firmware.c
>> @@ -5,6 +5,7 @@
>>
>> #include <linux/firmware.h>
>> #include <linux/firmware/qcom/qcom_scm.h>
>> +#include <linux/iommu.h>
>> #include <linux/of_address.h>
>> #include <linux/of_reserved_mem.h>
>> #include <linux/soc/qcom/mdt_loader.h>
>> @@ -13,12 +14,15 @@
>> #include "iris_firmware.h"
>>
>> #define MAX_FIRMWARE_NAME_SIZE 128
>> +#define IRIS_FW_START_ADDR 0
>>
>> static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> {
>> + struct device *dev = core->dev_fw ? core->dev_fw : core->dev;
>> u32 pas_id = core->iris_platform_data->pas_id;
>> const struct firmware *firmware = NULL;
>> - struct device *dev = core->dev;
>> + struct qcom_scm_pas_context *ctx_fw;
>> + struct iommu_domain *domain;
>> struct resource res;
>> phys_addr_t mem_phys;
>> size_t res_size;
>> @@ -29,13 +33,17 @@ static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> if (strlen(fw_name) >= MAX_FIRMWARE_NAME_SIZE - 4)
>> return -EINVAL;
>>
>> - ret = of_reserved_mem_region_to_resource(dev->of_node, 0, &res);
>> + ret = of_reserved_mem_region_to_resource(core->dev->of_node, 0, &res);
>> if (ret)
>> return ret;
>>
>> mem_phys = res.start;
>> res_size = resource_size(&res);
>>
>> + ctx_fw = devm_qcom_scm_pas_context_alloc(dev, pas_id, mem_phys, res_size);
>> + if (IS_ERR(ctx_fw))
>> + return PTR_ERR(ctx_fw);
>> +
>> ret = request_firmware(&firmware, fw_name, dev);
>> if (ret)
>> return ret;
>> @@ -52,9 +60,27 @@ static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> goto err_release_fw;
>> }
>>
>> - ret = qcom_mdt_load(dev, firmware, fw_name,
>> - pas_id, mem_virt, mem_phys, res_size, NULL);
>> + ctx_fw->use_tzmem = !!core->dev_fw;
>> + ret = qcom_mdt_pas_load(ctx_fw, firmware, fw_name, mem_virt, NULL);
>> + if (ret)
>> + goto err_mem_unmap;
>> +
>> + if (ctx_fw->use_tzmem) {
>> + domain = iommu_get_domain_for_dev(core->dev_fw);
>> + if (!domain) {
>> + ret = -ENODEV;
>> + goto err_mem_unmap;
>> + }
>> +
>> + ret = iommu_map(domain, IRIS_FW_START_ADDR, mem_phys, res_size,
>> + IOMMU_READ | IOMMU_WRITE | IOMMU_PRIV, GFP_KERNEL);
>> + if (ret)
>> + goto err_mem_unmap;
>> + }
>>
>> + core->ctx_fw = ctx_fw;
>> +
>> +err_mem_unmap:
>> memunmap(mem_virt);
>> err_release_fw:
>> release_firmware(firmware);
>> @@ -62,6 +88,19 @@ static int iris_load_fw_to_memory(struct iris_core *core, const char *fw_name)
>> return ret;
>> }
>>
>> +static void iris_fw_iommu_unmap(struct iris_core *core)
>> +{
>> + bool use_tzmem = core->ctx_fw->use_tzmem;
>> + struct iommu_domain *domain;
>> +
>> + if (!use_tzmem)
>> + return;
>> +
>> + domain = iommu_get_domain_for_dev(core->dev_fw);
>> + if (domain)
>> + iommu_unmap(domain, IRIS_FW_START_ADDR, core->ctx_fw->mem_size);
>> +}
>> +
>> int iris_fw_load(struct iris_core *core)
>> {
>> const struct tz_cp_config *cp_config;
>> @@ -79,10 +118,10 @@ int iris_fw_load(struct iris_core *core)
>> return -ENOMEM;
>> }
>>
>> - ret = qcom_scm_pas_auth_and_reset(core->iris_platform_data->pas_id);
>> + ret = qcom_scm_pas_prepare_and_auth_reset(core->ctx_fw);
>> if (ret) {
>> dev_err(core->dev, "auth and reset failed: %d\n", ret);
>> - return ret;
>> + goto err_unmap;
>> }
>>
>> for (i = 0; i < core->iris_platform_data->tz_cp_config_data_size; i++) {
>> @@ -93,17 +132,31 @@ int iris_fw_load(struct iris_core *core)
>> cp_config->cp_nonpixel_size);
>> if (ret) {
>> dev_err(core->dev, "qcom_scm_mem_protect_video_var failed: %d\n", ret);
>> - qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
>> - return ret;
>> + goto err_pas_shutdown;
>> }
>> }
>>
>> + return 0;
>> +
>> +err_pas_shutdown:
>> + qcom_scm_pas_shutdown(core->ctx_fw->pas_id);
>> +err_unmap:
>> + iris_fw_iommu_unmap(core);
>> +
>> return ret;
>> }
>>
>> int iris_fw_unload(struct iris_core *core)
>> {
>> - return qcom_scm_pas_shutdown(core->iris_platform_data->pas_id);
>> + int ret;
>> +
>> + ret = qcom_scm_pas_shutdown(core->ctx_fw->pas_id);
>> + if (ret)
>> + return ret;
>> +
>> + iris_fw_iommu_unmap(core);
>> +
>> + return ret;
>> }
>>
>> int iris_set_hw_state(struct iris_core *core, bool resume)
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* [PATCH] arm64: dts: qcom: monaco-evk: Enable primary USB controller in host mode
From: Swati Agarwal @ 2026-04-17 15:20 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Swati Agarwal
Enable primary USB controller in host mode on monaco EVK Platform.
Primary USB controller is connected to a Genesys Logic USB HUB GL3590
having 4 ports. The ports of hub that are present on lemans EVK standalone
board are used as follows:-
1) port-1 is connected to HD3SS3220 Type-C port controller.
2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART
for Bluetooth. This port is to be used only if user optionally replaces the
WiFi card with the NFA765 chip which uses USB for Bluetooth.
Remaining 2 ports will become functional when the interface plus mezzanine
board is stacked on top of corekit:
3) port-2 is connected to another hub which is present on the mezz through
which 4 type-A ports are connected.
4) port-3 is used for the M.2 B key for a 5G card when the mezz is
connected.
Primary USB Controller
↓
GL3590 USB Hub (4 ports)
|
|-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
|
|-- Port 2 → Mezzanine USB Hub (when mezz attached)
|
|-- Port 3 → M.2 B‑Key Slot (when mezz attached)
|
|-- Port 4 → M.2 E‑Key Slot
(Default: BT via UART;
USB only if NFA765 module is installed)
Mark the primary USB controller as host only capable and add the HD3SS3220
Type-C port controller along with Type-c connector for controlling vbus
supply.
In hardware, there are dip switches provided to operate between USB1 port 0
and port 1 for primary Type-C USB controller. By default, switches will be
off operating at USB0 port. After bootup to HLOS, it will be operated in
USB1 port. Added support in the software for both HS and SS switches as
usb1_hs_sel_switch and usb1_ss_sel_switch to avoid manually changing the
dip switch position for USB1 port to function. Also, added usb1_hub_reset
pin for USB1 hub to get detected after bootup as USB1 hub will be in
inactive state before bootup.
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
---
.../boot/dts/qcom/monaco-evk-common.dtsi | 173 +++++++++++++++++-
1 file changed, 172 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi b/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
index 12c847c03757..6316a8270f57 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco-evk-common.dtsi
@@ -23,6 +23,37 @@ chosen {
stdout-path = "serial0:115200n8";
};
+ connector-1 {
+ compatible = "usb-c-connector";
+ label = "USB1-Type-C";
+ data-role = "host";
+ power-role = "source";
+
+ vbus-supply = <&usb1_vbus>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb1_con_hs_ep: endpoint {
+ remote-endpoint = <&usb_hub_2_1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb1_con_ss_ep: endpoint {
+ remote-endpoint = <&hd3ss3220_1_in_ep>;
+ };
+
+ };
+ };
+ };
+
connector-2 {
compatible = "gpio-usb-b-connector", "usb-b-connector";
label = "micro-USB";
@@ -77,6 +108,15 @@ dp1_connector_in: endpoint {
};
};
+ usb1_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb1_vbus";
+ gpio = <&expander1 3 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ };
+
usb2_vbus: regulator-usb2-vbus {
compatible = "regulator-fixed";
regulator-name = "usb2_vbus";
@@ -445,6 +485,39 @@ lt8713sx_dp1_out: endpoint {
};
};
};
+
+ usb-typec@47 {
+ compatible = "ti,hd3ss3220";
+ reg = <0x47>;
+
+ interrupts-extended = <&tlmm 45 IRQ_TYPE_EDGE_FALLING>;
+
+ id-gpios = <&tlmm 13 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&usb1_id>, <&usb1_intr>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hd3ss3220_1_in_ep: endpoint {
+ remote-endpoint = <&usb1_con_ss_ep>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ hd3ss3220_1_out_ep: endpoint {
+ remote-endpoint = <&usb_hub_3_1>;
+ };
+ };
+ };
+ };
};
&i2c1 {
@@ -556,6 +629,13 @@ expander5: gpio@3d {
interrupts-extended = <&tlmm 3 IRQ_TYPE_LEVEL_LOW>;
pinctrl-0 = <&expander5_int>;
pinctrl-names = "default";
+
+ gpio5-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "usb1_ss_sel_switch";
+ };
};
expander6: gpio@3e {
@@ -742,6 +822,28 @@ expander5_int: expander5-int-state {
bias-pull-up;
};
+ usb1_hub_reset: usb1-hub-reset-state {
+ pins = "gpio7";
+ function = "gpio";
+ output-enable;
+ output-high;
+ bias-disable;
+ };
+
+ usb1_id: usb1-id-state {
+ pins = "gpio13";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ usb1_hs_sel_switch: usb1-hs-sel-switch-state {
+ pins = "gpio14";
+ function = "gpio";
+ output-enable;
+ output-high;
+ bias-disable;
+ };
+
expander1_int: expander1-int-state {
pins = "gpio16";
function = "gpio";
@@ -784,6 +886,12 @@ expander3_int: expander3-int-state {
bias-pull-up;
};
+ usb1_intr: usb1-intr-state {
+ pins = "gpio45";
+ function = "gpio";
+ bias-pull-up;
+ };
+
expander6_int: expander6-int-state {
pins = "gpio52";
function = "gpio";
@@ -863,9 +971,72 @@ &ufs_mem_phy {
};
&usb_1 {
- dr_mode = "peripheral";
+ dr_mode = "host";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_hub_reset &usb1_hs_sel_switch>;
status = "okay";
+
+ usb_hub_2_x: hub@1 {
+ compatible = "usb5e3,610";
+ reg = <1>;
+
+ peer-hub = <&usb_hub_3_x>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb_hub_2_1: endpoint {
+ remote-endpoint = <&usb1_con_hs_ep>;
+ };
+ };
+
+ /*
+ * Port-4 is connected to M.2 E key connector on corekit.
+ */
+ port@4 {
+ reg = <4>;
+
+ usb_hub_2_4: endpoint {
+ };
+ };
+ };
+ };
+
+ usb_hub_3_x: hub@2 {
+ compatible = "usb5e3,625";
+ reg = <2>;
+
+ peer-hub = <&usb_hub_2_x>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb_hub_3_1: endpoint {
+ remote-endpoint = <&hd3ss3220_1_out_ep>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ usb_hub_3_4: endpoint {
+ };
+ };
+ };
+ };
};
&usb_1_hsphy {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 04/11] media: iris: Add helper to create a context bank device on iris vpu bus
From: Vishnu Reddy @ 2026-04-17 15:19 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joerg Roedel, Will Deacon,
Robin Murphy, Bjorn Andersson, Konrad Dybcio, Stefan Schmidt,
Hans Verkuil, linux-media, linux-arm-msm, devicetree,
linux-kernel, iommu
In-Reply-To: <ie6dad3xewm25gdrqqne2fsroopu3jwgrqmu54sfzjliis6mo5@6qsgagvyynwx>
On 4/14/2026 8:48 PM, Dmitry Baryshkov wrote:
> On Tue, Apr 14, 2026 at 10:30:00AM +0530, Vishnu Reddy wrote:
>> From: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>>
>> Add a helper function to allocate and register context bank (CB) device
>> on the iris vpu bus. The function ID associated with the CB is specified
>> from the platform data, allowing the bus dma_configure callback to apply
>> correct stream ID mapping when device is registered.
>>
>> Signed-off-by: Vikash Garodia<vikash.garodia@oss.qualcomm.com>
>> Signed-off-by: Vishnu Reddy<busanna.reddy@oss.qualcomm.com>
>> ---
>> drivers/media/platform/qcom/iris/iris_resources.c | 33 +++++++++++++++++++++++
>> drivers/media/platform/qcom/iris/iris_resources.h | 1 +
>> 2 files changed, 34 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_resources.c b/drivers/media/platform/qcom/iris/iris_resources.c
>> index 773f6548370a..a25e0f2e9d26 100644
>> --- a/drivers/media/platform/qcom/iris/iris_resources.c
>> +++ b/drivers/media/platform/qcom/iris/iris_resources.c
>> @@ -6,6 +6,7 @@
>> #include <linux/clk.h>
>> #include <linux/devfreq.h>
>> #include <linux/interconnect.h>
>> +#include <linux/iris_vpu_bus.h>
>> #include <linux/pm_domain.h>
>> #include <linux/pm_opp.h>
>> #include <linux/pm_runtime.h>
>> @@ -141,3 +142,35 @@ int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type
>>
>> return 0;
>> }
>> +
>> +static void iris_release_cb_dev(struct device *dev)
>> +{
>> + kfree(dev);
>> +}
>> +
>> +struct device *iris_create_cb_dev(struct iris_core *core, const char *name, const u32 *f_id)
> Please move into the bus code and make it generic enough.
Do you suggest to add a wrapper to pass the varying inputs to the
generic bus, something like this
struct device* create_and_register_device(dma_mask, parent_dev,
*release, dev_name,...)
>> +{
>> + struct device *dev;
>> + int ret;
>> +
>> + dev = kzalloc_obj(*dev);
>> + if (!dev)
>> + return ERR_PTR(-ENOMEM);
>> +
>> + dev->release = iris_release_cb_dev;
>> + dev->bus = &iris_vpu_bus_type;
>> + dev->parent = core->dev;
>> + dev->coherent_dma_mask = core->iris_platform_data->dma_mask;
>> + dev->dma_mask = &dev->coherent_dma_mask;
> Would you also need to set the of_node? See
> device_set_of_node_from_dev()
It might be needed for FastRPC as they are following sub node approach,
Iris does not need.
>> +
>> + dev_set_name(dev, "%s", name);
>> + dev_set_drvdata(dev, (void *)f_id);
>> +
>> + ret = device_register(dev);
>> + if (ret) {
>> + put_device(dev);
>> + return ERR_PTR(ret);
>> + }
>> +
>> + return dev;
>> +}
>> diff --git a/drivers/media/platform/qcom/iris/iris_resources.h b/drivers/media/platform/qcom/iris/iris_resources.h
>> index 6bfbd2dc6db0..4a494627ff23 100644
>> --- a/drivers/media/platform/qcom/iris/iris_resources.h
>> +++ b/drivers/media/platform/qcom/iris/iris_resources.h
>> @@ -15,5 +15,6 @@ int iris_unset_icc_bw(struct iris_core *core);
>> int iris_set_icc_bw(struct iris_core *core, unsigned long icc_bw);
>> int iris_disable_unprepare_clock(struct iris_core *core, enum platform_clk_type clk_type);
>> int iris_prepare_enable_clock(struct iris_core *core, enum platform_clk_type clk_type);
>> +struct device *iris_create_cb_dev(struct iris_core *core, const char *name, const u32 *f_id);
>>
>> #endif
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm630: describe adsp_mem region properly
From: Ekansh Gupta @ 2026-04-17 15:15 UTC (permalink / raw)
To: Konrad Dybcio, Nickolay Goppen, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel,
~postmarketos/upstreaming
In-Reply-To: <70d4dbe7-0e5b-4065-858e-b5a57bbf45e3@oss.qualcomm.com>
On 15-04-2026 15:22, Konrad Dybcio wrote:
> On 4/15/26 11:40 AM, Nickolay Goppen wrote:
>> Downstream [1] this region is marked as shared and reusable so
>> describe it that way.
>>
>> [1]: https://github.com/xiaomi-sdm660/android_kernel_xiaomi_sdm660/blob/11-EAS/arch/arm/boot/dts/qcom/sdm660.dtsi#L448
>>
>> Signed-off-by: Nickolay Goppen <setotau@mainlining.org>
>> ---
>
> +Ekansh some insight, please?
>
> We're giving away that memory via qcom_scm_assign_mem() anyway
> and I would assume that making it not-"no-map" could introduce issues
> when the OS tries to access that region
>
With the current version and the upcoming planned enhancements, I don't
see any major benefits of making this as not-"no-map".
With posted enhancements[1], the plan is to qcom_scm_assign_mem() the
entire memory-region to lpass VMIDs. and un-assign it only during
fastrpc_rpmsg_remove(). There have been implementation in downstream
where this memory is dumped in case of SSR or audio PDR using minidump,
so marking it `reusable` might make sense there, but that dump logic is
not added upstream.
Upon checking the DT, I see a bigger problem here, this memory-region
looks to me unused, it's not added under fastrpc adsp node(ref. [2]).
Please correct me if I am wrong about this point.
[1]
https://lore.kernel.org/all/20260409062617.1182-1-jianping.li@oss.qualcomm.com/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/lemans.dtsi#n7500
//Ekansh
> Konrad
>
>
>> arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> index 4b47efdb57b2..13094b5e9339 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
>> @@ -495,8 +495,9 @@ venus_region: venus@9f800000 {
>> };
>>
>> adsp_mem: adsp-region@f6000000 {
>> + compatible = "shared-dma-pool";
>> reg = <0x0 0xf6000000 0x0 0x800000>;
>> - no-map;
>> + reusable;
>> };
>>
>> qseecom_mem: qseecom-region@f6800000 {
>>
^ permalink raw reply
* Re: Re: Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Conor Dooley @ 2026-04-17 15:13 UTC (permalink / raw)
To: Xuyang Dong
Cc: Krzysztof Kozlowski, ukleinek, robh, krzk+dt, conor+dt, ben-linux,
ben.dooks, p.zabel, linux-pwm, devicetree, linux-kernel, ningyu,
linmin, xuxiang, wangguosheng, pinkesh.vaghela
In-Reply-To: <3b2e80d5.55a5.19d996c6821.Coremail.dongxuyang@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
On Fri, Apr 17, 2026 at 11:11:51AM +0800, Xuyang Dong wrote:
> > > > > >
> > > > > > The DesignWare PWM includes separate reset signals dedicated to each clock
> > > > > > domain:
> > > > > > The presetn signal resets logic in pclk domain.
> > > > > > The timer_N_resetn signal resets logic in the timer_N_clk domain.
> > > > > > The resets are active-low.
> > > > > >
> > > > > > Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
> > > > >
> > > > > This commit implies that your hardware differs from existing devices,
> > > > > I think you should add a device-specific compatible.
> > > > >
> > >
> > > Hi Conor and Krzysztof,
> > >
> > > The DesignWare PWM Databook for 2.13a says: "The DW_apb_timers includes
> > > separate reset signals dedicated to each clock domain". They are:
> > > The presetn signal resets logic in pclk domain (i.e., the bus clock in DT).
> > > The timer_N_resetn signal resets logic in the timer_N_clk domain (i.e.,
> > > the timer clock in DT).
> > >
> > > These reset signals are optional; it is up to the designer's
> > > implementation.
> >
> > Right, and it's that "designer's implementation" that warrants a
> > device-specific compatible.
> >
>
> Hi Conor,
>
> The YAML update for the new device-specific compatible is as follows:
>
> properties:
> compatible:
> oneOf:
> - const: snps,dw-apb-timers-pwm2
> - items:
> - enum:
> - snps,dw-apb-timers-pwm-2.13a
This is not a device-specific compatible.
Hint: device-specific means it needs to start with "eswin,eic7700" (and
probably end with "-pwm".
> - const: snps,dw-apb-timers-pwm2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
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