* 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
* [PATCH RFC 4/4] clk: rockchip: rk3576: add ROUND_CLOSEST to dclk_vp1_src divider
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
Without CLK_DIVIDER_ROUND_CLOSEST, the divider's _is_best_div() only
considers candidates where now <= target, rejecting any rate above the
target even when it is closer. Combined with the PLL round-nearest fix,
this causes the divider to still pick a suboptimal rate: with PLL
round-nearest alone, div=8 produces 249.0 MHz (0.048% over) but is
rejected because it exceeds the target, and div=3/248.0 MHz wins
(-0.354% error).
Add CLK_DIVIDER_ROUND_CLOSEST to dclk_vp1_src's div_flags so the
divider picks the rate closest to the target regardless of direction.
Together with the PLL round-nearest change, this yields:
VPLL 1992 MHz / 8 = 249.0 MHz (+0.048% error)
instead of the previous:
VPLL 1488 MHz / 6 = 248.0 MHz (-0.354% error)
This small difference appears to enable more monitors to lock to the VP1
clock when driving output at 2560x1440@60Hz via DisplayPort.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-rk3576.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3576.c b/drivers/clk/rockchip/clk-rk3576.c
index 28eb5a802e83..9fc3264ef322 100644
--- a/drivers/clk/rockchip/clk-rk3576.c
+++ b/drivers/clk/rockchip/clk-rk3576.c
@@ -1106,7 +1106,7 @@ static struct rockchip_clk_branch rk3576_clk_branches[] __initdata = {
RK3576_CLKSEL_CON(145), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 10, GFLAGS),
COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
- RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS,
+ RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS | CLK_DIVIDER_ROUND_CLOSEST,
RK3576_CLKGATE_CON(61), 11, GFLAGS),
COMPOSITE(DCLK_VP2_SRC, "dclk_vp2_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
RK3576_CLKSEL_CON(147), 8, 3, MFLAGS, 0, 8, DFLAGS,
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 3/4] clk: rockchip: rk3576: allow dclk_vp1_src to propagate rate to parent PLL
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
dclk_vp1_src feeds the display clock for Video Port 1. When parented to
the default GPLL (1188 MHz), the 8-bit divider cannot synthesize the
248.88 MHz pixel clock required for 2560x1440@60 which VP1 supports:
1188 / 5 = 237.6 MHz (-4.53% error). This exceeds DisplayPort's +/-0.5%
tolerance and causes black screens on strict sinks.
Add CLK_SET_RATE_PARENT so that when dclk_vp1_src is reparented to a
programmable PLL (e.g. VPLL via assigned-clock-parents), the CCF divider
can ask the PLL to retune. For example, VPLL at 1992 MHz / 8 = 249 MHz
(0.048% error).
This flag relies on reparenting the VP1 source clock to VPLL at DT level
to ensure no consumer calls clk_set_rate on dclk_vp1 while its parent is
set to the boot-time default of GPLL.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-rk3576.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3576.c b/drivers/clk/rockchip/clk-rk3576.c
index 2557358e0b9d..28eb5a802e83 100644
--- a/drivers/clk/rockchip/clk-rk3576.c
+++ b/drivers/clk/rockchip/clk-rk3576.c
@@ -1105,7 +1105,7 @@ static struct rockchip_clk_branch rk3576_clk_branches[] __initdata = {
COMPOSITE(DCLK_VP0_SRC, "dclk_vp0_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
RK3576_CLKSEL_CON(145), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 10, GFLAGS),
- COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
+ COMPOSITE(DCLK_VP1_SRC, "dclk_vp1_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT | CLK_SET_RATE_PARENT,
RK3576_CLKSEL_CON(146), 8, 3, MFLAGS, 0, 8, DFLAGS,
RK3576_CLKGATE_CON(61), 11, GFLAGS),
COMPOSITE(DCLK_VP2_SRC, "dclk_vp2_src", gpll_cpll_vpll_bpll_lpll_p, CLK_SET_RATE_NO_REPARENT,
--
2.52.0
^ permalink raw reply related
* [PATCH RFC 2/4] clk: rockchip: pll: use round-nearest in determine_rate
From: Alexey Charkov @ 2026-04-17 15:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Michael Turquette, Stephen Boyd
Cc: Pavel Zhovner, Sebastian Reichel, Andy Yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, linux-clk,
Alexey Charkov
In-Reply-To: <20260417-rk3576-dclk-v1-0-26a9d0dcb2de@flipper.net>
rockchip_pll_determine_rate() walks the rate table in descending order
and picks the first entry <= the requested rate. This floor-rounding
interacts poorly with consumers that use CLK_SET_RATE_PARENT: a divider
iterating candidates asks the PLL for rate*div, and a tiny undershoot
causes the PLL to snap to a much lower entry.
For example, requesting 1991.04 MHz (248.88 MHz * 8) causes the PLL to
return 1968 MHz instead of 1992 MHz — a 24 MHz table gap that produces
a 1.2% pixel clock error when divided back down.
Change to round-to-nearest: for each table entry compute the absolute
distance from the request, and pick the entry with the smallest delta.
The CCF's divider and composite logic handle over/undershoot preferences
via their own ROUND_CLOSEST flags.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
drivers/clk/rockchip/clk-pll.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c
index 6b853800cb6b..c142f2c4fd99 100644
--- a/drivers/clk/rockchip/clk-pll.c
+++ b/drivers/clk/rockchip/clk-pll.c
@@ -66,19 +66,19 @@ static int rockchip_pll_determine_rate(struct clk_hw *hw,
{
struct rockchip_clk_pll *pll = to_rockchip_clk_pll(hw);
const struct rockchip_pll_rate_table *rate_table = pll->rate_table;
+ unsigned long best = 0;
int i;
- /* Assuming rate_table is in descending order */
for (i = 0; i < pll->rate_count; i++) {
- if (req->rate >= rate_table[i].rate) {
- req->rate = rate_table[i].rate;
-
- return 0;
- }
+ if (abs((long)req->rate - (long)rate_table[i].rate) <
+ abs((long)req->rate - (long)best))
+ best = rate_table[i].rate;
}
- /* return minimum supported value */
- req->rate = rate_table[i - 1].rate;
+ if (best)
+ req->rate = best;
+ else
+ req->rate = rate_table[pll->rate_count - 1].rate;
return 0;
}
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox