* [PATCH v3 1/2] dt-bindings: display: panel: add Ilitek ILI7807S panel controller
From: Arpit Saini @ 2026-06-24 8:53 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: arpit.saini, linux-arm-msm, dri-devel, devicetree, linux-kernel,
ayushi.makhija, rajeevny, Krzysztof Kozlowski
In-Reply-To: <20260624-ili7807s-v3-0-ddf37052a289@oss.qualcomm.com>
ILI7807S is a DSI display controller used to drive MIPI-DSI panels.
The DLC DLC0697 1080x1920 LCD panel is based on this controller.
The panel requires a reset GPIO, I/O voltage supply (vddi), positive
LCD bias supply (avdd) and negative LCD bias supply (avee). The panel
operates in video burst mode with four data lanes using RGB888 pixel
format.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com>
---
.../bindings/display/panel/ilitek,ili7807s.yaml | 71 ++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili7807s.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili7807s.yaml
new file mode 100644
index 000000000000..ba8c5bbf8ffc
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili7807s.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ilitek,ili7807s.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI7807S-based DSI panels
+
+maintainers:
+ - Arpit Saini <arpit.saini@oss.qualcomm.com>
+
+allOf:
+ - $ref: panel-common.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - dlc,dlc0697
+ - const: ilitek,ili7807s
+
+ reg:
+ maxItems: 1
+ description: DSI virtual channel
+
+ vddi-supply:
+ description: I/O voltage supply (1.8V)
+
+ avdd-supply:
+ description: Positive LCD bias supply (AVDD), typically +5.5V
+ (range 4.5V to 6.3V)
+
+ avee-supply:
+ description: Negative LCD bias supply (AVEE), typically -5.5V
+ (range -6.3V to -4.5V)
+
+required:
+ - compatible
+ - reg
+ - reset-gpios
+ - vddi-supply
+ - avdd-supply
+ - avee-supply
+ - port
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "dlc,dlc0697", "ilitek,ili7807s";
+ reg = <0>;
+
+ reset-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
+ vddi-supply = <&pm4125_l15>;
+ avdd-supply = <&avdd>;
+ avee-supply = <&avee>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH 6/7] ARM: dts: rockchip: Add RV1126 I2C5
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
The controller is present in the SoC and can be used by boards for
external peripherals, such as an RTC on the Alientek DLRV1126 carrier
board.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 ++++++++++
arch/arm/boot/dts/rockchip/rv1126.dtsi | 15 +++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
index 35ef6732281f..1d883b80aed4 100644
--- a/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi
@@ -123,6 +123,16 @@ i2c3m2_xfer: i2c3m2-xfer {
<1 RK_PD7 3 &pcfg_pull_none>;
};
};
+ i2c5 {
+ /omit-if-no-ref/
+ i2c5m0_xfer: i2c5m0-xfer {
+ rockchip,pins =
+ /* i2c5_scl_m0 */
+ <2 RK_PA5 7 &pcfg_pull_none_drv_level_0_smt>,
+ /* i2c5_sda_m0 */
+ <2 RK_PB3 7 &pcfg_pull_none_drv_level_0_smt>;
+ };
+ };
i2s0 {
i2s0m0_lrck_tx: i2s0m0-lrck-tx {
rockchip,pins =
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index 5b1ee06dc035..483576de841e 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -23,6 +23,7 @@ aliases {
i2c0 = &i2c0;
i2c2 = &i2c2;
i2c3 = &i2c3;
+ i2c5 = &i2c5;
serial0 = &uart0;
serial1 = &uart1;
serial2 = &uart2;
@@ -400,6 +401,20 @@ i2c3: i2c@ff520000 {
status = "disabled";
};
+ i2c5: i2c@ff540000 {
+ compatible = "rockchip,rv1126-i2c", "rockchip,rk3399-i2c";
+ reg = <0xff540000 0x1000>;
+ interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cru CLK_I2C5>, <&cru PCLK_I2C5>;
+ clock-names = "i2c", "pclk";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5m0_xfer>;
+ rockchip,grf = <&pmugrf>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
pwm8: pwm@ff550000 {
compatible = "rockchip,rv1126-pwm", "rockchip,rk3328-pwm";
reg = <0xff550000 0x10>;
--
2.54.0
^ permalink raw reply related
* [PATCH 5/7] ARM: dts: rockchip: Add RV1126 GMAC refout clock
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
This clock can be routed to an external Ethernet PHY as its reference
clock. Boards using this clock need the clock to be described so the
dwmac-rk driver can acquire and keep it enabled.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
arch/arm/boot/dts/rockchip/rv1126.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rockchip/rv1126.dtsi b/arch/arm/boot/dts/rockchip/rv1126.dtsi
index d6e8b63daa42..5b1ee06dc035 100644
--- a/arch/arm/boot/dts/rockchip/rv1126.dtsi
+++ b/arch/arm/boot/dts/rockchip/rv1126.dtsi
@@ -624,10 +624,11 @@ gmac: ethernet@ffc40000 {
rockchip,grf = <&grf>;
clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
<&cru CLK_GMAC_TX_RX>, <&cru CLK_GMAC_REF>,
+ <&cru CLK_GMAC_ETHERNET_OUT>,
<&cru ACLK_GMAC>, <&cru PCLK_GMAC>,
<&cru CLK_GMAC_TX_RX>, <&cru CLK_GMAC_PTPREF>;
clock-names = "stmmaceth", "mac_clk_rx",
- "mac_clk_tx", "clk_mac_ref",
+ "mac_clk_tx", "clk_mac_ref", "clk_mac_refout",
"aclk_mac", "pclk_mac",
"clk_mac_speed", "ptp_ref";
resets = <&cru SRST_GMAC_A>;
--
2.54.0
^ permalink raw reply related
* [PATCH 4/7] net: stmmac: dwmac-rk: Enable refout clock for RGMII
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
Some Rockchip GMAC integrations use clk_mac_refout as an external PHY
reference clock even when the MAC is configured for RGMII.
RV1126 boards can route CLK_GMAC_ETHERNET_OUT to the external PHY as a
25 MHz reference clock. If the driver does not acquire and enable this
clock in RGMII mode, the common clock framework may disable it as unused
and the PHY can lose its reference clock.
Enable the refout clock handling for RGMII in addition to RMII.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
index 8d7042e68926..f6fdc0c5b475 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -1112,7 +1112,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
bsp_priv->clk_enabled = false;
bsp_priv->num_clks = ARRAY_SIZE(rk_clocks);
- if (phy_iface == PHY_INTERFACE_MODE_RMII)
+ if (phy_iface == PHY_INTERFACE_MODE_RMII ||
+ phy_iface == PHY_INTERFACE_MODE_RGMII)
bsp_priv->num_clks += ARRAY_SIZE(rk_rmii_clocks);
bsp_priv->clks = devm_kcalloc(dev, bsp_priv->num_clks,
@@ -1123,7 +1124,8 @@ static int rk_gmac_clk_init(struct plat_stmmacenet_data *plat)
for (i = 0; i < ARRAY_SIZE(rk_clocks); i++)
bsp_priv->clks[i].id = rk_clocks[i];
- if (phy_iface == PHY_INTERFACE_MODE_RMII) {
+ if (phy_iface == PHY_INTERFACE_MODE_RMII ||
+ phy_iface == PHY_INTERFACE_MODE_RGMII) {
for (j = 0; j < ARRAY_SIZE(rk_rmii_clocks); j++)
bsp_priv->clks[i++].id = rk_rmii_clocks[j];
}
--
2.54.0
^ permalink raw reply related
* [PATCH 3/7] dt-bindings: net: rockchip-dwmac: Allow 9 clocks
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
RV1126 has a separate GMAC Ethernet output clock used as the external
PHY reference clock. This clock is described in addition to the existing
GMAC clocks.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 80c252845349..86a7e83675ae 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -71,7 +71,7 @@ properties:
clocks:
minItems: 4
- maxItems: 8
+ maxItems: 9
clock-names:
contains:
--
2.54.0
^ permalink raw reply related
* [PATCH 2/7] dt-bindings: arm: rockchip: Add Alientek DLRV1126
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
The board consists of a DLRV1126 carrier board and a CLRV1126F core
module based on the Rockchip RV1126 SoC.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1a9dde18626d..9058f2a461d5 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -162,6 +162,13 @@ properties:
- const: coolpi,pi-4b
- const: rockchip,rk3588s
+ - description: Alientek CLRV1126F SoM based boards
+ items:
+ - enum:
+ - alientek,dlrv1126
+ - const: alientek,clrv1126f
+ - const: rockchip,rv1126
+
- description: Edgeble Neural Compute Module 2(Neu2) SoM based boards
items:
- const: edgeble,neural-compute-module-2-io # Edgeble Neural Compute Module 2 IO Board
--
2.54.0
^ permalink raw reply related
* [PATCH 1/7] dt-bindings: vendor-prefixes: add alientek
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
In-Reply-To: <20260624-rv1126-alientek-dlrv1126-v1-0-5aef608a3f64@gmail.com>
Add a vendor prefix for Alientek, a board and module vendor used by the
ATK-DLRV1126 board.
Link: https://en.alientek.com
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..a23508a61373 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -88,6 +88,8 @@ patternProperties:
description: ALFA Network Inc.
"^algoltek,.*":
description: AlgolTek, Inc.
+ "^alientek,.*":
+ description: Guangzhou Xingyi Intelligent Technology Co., Ltd.
"^allegro,.*":
description: Allegro DVT
"^allegromicro,.*":
--
2.54.0
^ permalink raw reply related
* [PATCH 0/7] ARM: rockchip: rv1126: Add support for Alientek ATK-DLRV1126
From: Yanan He @ 2026-06-24 8:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
netdev, linux-stm32, Yanan He
The ATK-DLRV1126 board consists of a CLRV1126F core module and a
DLRV1126 carrier board. The core module contains the Rockchip RV1126
SoC, eMMC and RK809 PMIC. The carrier board provides Gigabit Ethernet,
SD card, AP6212 WiFi and Bluetooth, PCF8563 RTC, ADC keys, GPIO LEDs and
audio connectors.
This series adds the Alientek vendor prefix and board compatible, updates
the Rockchip DWMAC binding and driver for the RV1126 GMAC reference
output clock, adds missing RV1126 SoC description pieces, and finally
adds the CLRV1126F core module and DLRV1126 carrier board device trees.
The board was tested with Ethernet/NFS boot, eMMC, SD card, SDIO WiFi
enumeration, Bluetooth LE scanning, RTC, ADC keys, GPIO LEDs and RK809
audio card registration.
Signed-off-by: Yanan He <grumpycat921013@gmail.com>
---
Yanan He (7):
dt-bindings: vendor-prefixes: add alientek
dt-bindings: arm: rockchip: Add Alientek DLRV1126
dt-bindings: net: rockchip-dwmac: Allow 9 clocks
net: stmmac: dwmac-rk: Enable refout clock for RGMII
ARM: dts: rockchip: Add RV1126 GMAC refout clock
ARM: dts: rockchip: Add RV1126 I2C5
ARM: dts: rockchip: Add Alientek DLRV1126
.../devicetree/bindings/arm/rockchip.yaml | 7 +
.../devicetree/bindings/net/rockchip-dwmac.yaml | 2 +-
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rv1126-alientek-clrv1126f.dtsi | 277 +++++++++++++++++++++
.../boot/dts/rockchip/rv1126-alientek-dlrv1126.dts | 258 +++++++++++++++++++
arch/arm/boot/dts/rockchip/rv1126-pinctrl.dtsi | 10 +
arch/arm/boot/dts/rockchip/rv1126.dtsi | 18 +-
drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 6 +-
9 files changed, 577 insertions(+), 4 deletions(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260618-rv1126-alientek-dlrv1126-d94abdcf8580
Best regards,
--
Yanan He <grumpycat921013@gmail.com>
^ permalink raw reply
* Re: [PATCH v22 04/13] firmware: psci: Introduce command-based resets
From: Shivendra Pratap @ 2026-06-24 8:34 UTC (permalink / raw)
To: Lorenzo Pieralisi, Arnd Bergmann, Sebastian Reichel, Mark Rutland,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Souvik Chakravarty, Bartosz Golaszewski, Sudeep Holla
Cc: krzk+dt, conor+dt, devicetree, robh, sashiko-reviews
In-Reply-To: <20260514212353.881AFC2BCB8@smtp.kernel.org>
On 15-05-2026 02:53, sashiko-bot@kernel.org wrote:
> - [High] The API illegally truncates the 64-bit PSCI SYSTEM_RESET2 cookie parameter to 32 bits, violating the ARM PSCI specification.
Hi Lorenzo,
Was going through this comment. The patch currently uses a 32 bit
cookie. The spec also talks about "SMC64 - uint64 - cookie". Can you
please suggest if we should add support for 64 bit cookie here?
This will require a re-design for supporting about up-to three 32-bit
numbers in reboot-mode framework.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH 1/2] iio: dac: dac8163: Add driver for DAC8163
From: Lukas @ 2026-06-24 8:30 UTC (permalink / raw)
To: Siratul Islam
Cc: andy, conor+dt, devicetree, dlechner, jic23, krzk+dt, linux-iio,
linux-kernel, nuno.sa, robh
In-Reply-To: <36ffe80feb5a521c28b1a6d10bf1338dc39ddef1.camel@linux.dev>
Thanks for the review. As i said this is my first time submitting a
patch. I have looked at already existing spi dac drivers for reference
but i seemed to have missed quite a lot. But the comments are greatly
appreciated.
On Wed, Jun 24, 2026 at 12:56:15AM +0600, Siratul Islam wrote:
> A link to the datasheet here would be nice.
I will try to add all the small suggestions i dont mention explicitly,
like style issues or using guard instead of manual lock/unlock to v2.
> > +
> > + if (st->internal_ref) {
> > + st->vref_uv = 2500000; /* 2.5V internal reference */
> A note on where this value came from or why this was chosen, or a reference to datasheet would be better.
I think i would add the suggestion from David Lechner to remove the
internal_ref property completly and add "the way of doing optional
voltage references". This includes using the macro
DAC8163_INTERNAL_REF_mV. Would this be acceptable?
> You have a CMD_SOFT_RST defined but not used. Should this be used to reset before doing any configuration?
Yes this is a command which isnt used at this point. But maybe it makes
sense to reset the DAC first when probing.
Best regards
Lukas
^ permalink raw reply
* Re: [PATCH v6 3/4] reset: cix: add sky1 audss auxiliary reset driver
From: Philipp Zabel @ 2026-06-24 8:30 UTC (permalink / raw)
To: joakim.zhang, mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt,
gary.yang
Cc: cix-kernel-upstream, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623070805.211019-4-joakim.zhang@cixtech.com>
On Di, 2026-06-23 at 15:08 +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> Add an auxiliary reset controller driver for the AUDSS CRU. Sixteen
> software reset lines for audio subsystem peripherals are controlled
> through one register in the CRU register map.
>
> The driver is created by the AUDSS clock platform driver and registers
> the reset controller on the CRU device node.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> drivers/reset/Kconfig | 14 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-sky1-audss.c | 192 +++++++++++++++++++++++++++++++
> 3 files changed, 207 insertions(+)
> create mode 100644 drivers/reset/reset-sky1-audss.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index d009eb0849a3..f74859b292ae 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -300,6 +300,20 @@ config RESET_SKY1
> help
> This enables the reset controller for Cix Sky1.
>
> +config RESET_SKY1_AUDSS
> + tristate "Cix Sky1 Audio Subsystem reset controller"
> + depends on ARCH_CIX || COMPILE_TEST
> + select AUXILIARY_BUS
> + select REGMAP_MMIO
> + default CLK_SKY1_AUDSS
> + help
> + Support for block-level software reset lines in the Cix Sky1
> + Audio Subsystem (AUDSS) Clock and Reset Unit. Sixteen reset
> + outputs for audio peripherals are controlled through the CRU
> + register map. The driver binds as an auxiliary device from
> + the AUDSS clock driver. Say M or Y here if you want to build
> + this driver.
> +
> config RESET_SOCFPGA
> bool "SoCFPGA Reset Driver" if COMPILE_TEST && (!ARM || !ARCH_INTEL_SOCFPGA)
> default ARM && ARCH_INTEL_SOCFPGA
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 3e52569bd276..e81407ea3e29 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_RESET_RZV2H_USB2PHY) += reset-rzv2h-usb2phy.o
> obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
> obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
> obj-$(CONFIG_RESET_SKY1) += reset-sky1.o
> +obj-$(CONFIG_RESET_SKY1_AUDSS) += reset-sky1-audss.o
> obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
> obj-$(CONFIG_RESET_SUNPLUS) += reset-sunplus.o
> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
> diff --git a/drivers/reset/reset-sky1-audss.c b/drivers/reset/reset-sky1-audss.c
> new file mode 100644
> index 000000000000..20870f37d7d7
> --- /dev/null
> +++ b/drivers/reset/reset-sky1-audss.c
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Cix Sky1 Audio Subsystem reset controller driver
> + *
> + * Copyright 2026 Cix Technology Group Co., Ltd.
> + */
> +
> +#include <dt-bindings/reset/cix,sky1-audss-cru.h>
> +
> +#include <linux/auxiliary_bus.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/regmap.h>
> +#include <linux/reset-controller.h>
> +
> +#define SKY1_RESET_SLEEP_MIN_US 50
> +#define SKY1_RESET_SLEEP_MAX_US 100
> +
> +#define AUDSS_SW_RST 0x78
> +
> +struct sky1_audss_reset_map {
> + unsigned int offset;
> + unsigned int mask;
> +};
> +
> +struct sky1_audss_reset {
> + struct reset_controller_dev rcdev;
> + struct regmap *regmap;
> + const struct sky1_audss_reset_map *map;
> +};
> +
> +static const struct sky1_audss_reset_map sky1_audss_reset_map[] = {
> + [AUDSS_I2S0_SW_RST] = { AUDSS_SW_RST, BIT(0) },
> + [AUDSS_I2S1_SW_RST] = { AUDSS_SW_RST, BIT(1) },
> + [AUDSS_I2S2_SW_RST] = { AUDSS_SW_RST, BIT(2) },
> + [AUDSS_I2S3_SW_RST] = { AUDSS_SW_RST, BIT(3) },
> + [AUDSS_I2S4_SW_RST] = { AUDSS_SW_RST, BIT(4) },
> + [AUDSS_I2S5_SW_RST] = { AUDSS_SW_RST, BIT(5) },
> + [AUDSS_I2S6_SW_RST] = { AUDSS_SW_RST, BIT(6) },
> + [AUDSS_I2S7_SW_RST] = { AUDSS_SW_RST, BIT(7) },
> + [AUDSS_I2S8_SW_RST] = { AUDSS_SW_RST, BIT(8) },
> + [AUDSS_I2S9_SW_RST] = { AUDSS_SW_RST, BIT(9) },
> + [AUDSS_WDT_SW_RST] = { AUDSS_SW_RST, BIT(10) },
> + [AUDSS_TIMER_SW_RST] = { AUDSS_SW_RST, BIT(11) },
> + [AUDSS_MB0_SW_RST] = { AUDSS_SW_RST, BIT(12) },
> + [AUDSS_MB1_SW_RST] = { AUDSS_SW_RST, BIT(13) },
> + [AUDSS_HDA_SW_RST] = { AUDSS_SW_RST, BIT(14) },
> + [AUDSS_DMAC_SW_RST] = { AUDSS_SW_RST, BIT(15) },
> +};
> +
> +static struct sky1_audss_reset *to_sky1_audss_reset(struct reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct sky1_audss_reset, rcdev);
> +}
> +
> +static int sky1_audss_reset_set(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> + const struct sky1_audss_reset_map *signal = &priv->map[id];
> + unsigned int value = assert ? 0 : signal->mask;
> +
> + return regmap_update_bits(priv->regmap, signal->offset, signal->mask, value);
Why does this propagate the return value ...
> +}
> +
> +static int sky1_audss_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_set(rcdev, id, true);
... only to be ignored? It'd be better to pass it on.
> + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
> + return 0;
> +}
> +
> +static int sky1_audss_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_set(rcdev, id, false);
> + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
> + return 0;
> +}
> +
> +static int sky1_audss_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_assert(rcdev, id);
> + sky1_audss_reset_deassert(rcdev, id);
> + return 0;
> +}
Will any AUDSS reset consumer use the reset_control_reset() API?
If not, no need to implement this.
> +
> +static int sky1_audss_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> + const struct sky1_audss_reset_map *signal = &priv->map[id];
> + unsigned int value;
> +
> + regmap_read(priv->regmap, signal->offset, &value);
> + return !!(value & signal->mask);
> +}
> +
> +static const struct reset_control_ops sky1_audss_reset_ops = {
> + .reset = sky1_audss_reset,
> + .assert = sky1_audss_reset_assert,
> + .deassert = sky1_audss_reset_deassert,
> + .status = sky1_audss_reset_status,
> +};
> +
> +static const struct regmap_config sky1_audss_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static void sky1_audss_reset_iounmap(void *data)
> +{
> + iounmap(data);
> +}
> +
> +static int sky1_audss_reset_get_regmap(struct sky1_audss_reset *priv)
> +{
> + struct device *dev = priv->rcdev.dev;
> + void __iomem *base;
> + int ret;
> +
> + priv->regmap = dev_get_regmap(dev->parent, NULL);
> + if (priv->regmap)
> + return 0;
> +
> + base = of_iomap(dev->parent->of_node, 0);
> + if (!base)
> + return dev_err_probe(dev, -ENOMEM, "failed to iomap address space\n");
> +
> + ret = devm_add_action_or_reset(dev, sky1_audss_reset_iounmap, base);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register iounmap action\n");
> +
> + priv->regmap = devm_regmap_init_mmio(dev, base, &sky1_audss_regmap_config);
> + if (IS_ERR(priv->regmap))
> + return dev_err_probe(dev, PTR_ERR(priv->regmap),
> + "failed to initialize regmap\n");
Why is there a fallback path? The clock driver creates the regmap
before creating the reset aux device, so dev_get_regmap() can never
fail.
> +
> + return 0;
> +}
> +
> +static int sky1_audss_reset_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
> + struct sky1_audss_reset *priv;
> + struct device *dev = &adev->dev;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->map = sky1_audss_reset_map;
> + priv->rcdev.owner = THIS_MODULE;
> + priv->rcdev.nr_resets = ARRAY_SIZE(sky1_audss_reset_map);
> + priv->rcdev.ops = &sky1_audss_reset_ops;
> + priv->rcdev.of_node = dev->parent->of_node;
auxiliary_device_create() uses device_set_of_node_from_dev() to inherit
the parent of_node, so you can use dev->of_node here.
> + priv->rcdev.dev = dev;
> + priv->rcdev.of_reset_n_cells = 1;
No need to set of_reset_n_cells.
> +
> + dev_set_drvdata(dev, priv);
This seems unnecessary as well.
> +
> + ret = sky1_audss_reset_get_regmap(priv);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to get regmap\n");
> +
> + return devm_reset_controller_register(dev, &priv->rcdev);
> +}
> +
> +static const struct auxiliary_device_id sky1_audss_reset_ids[] = {
> + { .name = "clk_sky1_audss.reset" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(auxiliary, sky1_audss_reset_ids);
> +
> +static struct auxiliary_driver sky1_audss_reset_driver = {
> + .probe = sky1_audss_reset_probe,
> + .id_table = sky1_audss_reset_ids,
> +};
> +
Drop this empty line.
> +module_auxiliary_driver(sky1_audss_reset_driver);
> +
> +MODULE_AUTHOR("Joakim Zhang <joakim.zhang@cixtech.com>");
> +MODULE_DESCRIPTION("Cix Sky1 Audio Subsystem reset driver");
> +MODULE_LICENSE("GPL");
regards
Philipp
^ permalink raw reply
* Re: [PATCH v1 2/8] arm64: dts: qcom: shikra: Add QAIF CPU node for audio
From: Konrad Dybcio @ 2026-06-24 8:20 UTC (permalink / raw)
To: Mohammad Rafi Shaik, Srinivas Kandagatla, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel,
Harendra Gautam
In-Reply-To: <20260616201315.2565115-3-mohammad.rafi.shaik@oss.qualcomm.com>
On 6/16/26 10:13 PM, Mohammad Rafi Shaik wrote:
> Add the QAIF CPU endpoint in shikra.dtsi so board files can connect LPASS
> front-end links to backend codecs.
>
> Describe the MMIO region, interrupt, IOMMU mapping and required clocks for
> the QAIF block. Keep the node disabled at SoC level; board dts files enable
> and consume it in subsequent patches.
>
> Co-developed-by: Harendra Gautam <harendra.gautam@oss.qualcomm.com>
> Signed-off-by: Harendra Gautam <harendra.gautam@oss.qualcomm.com>
> Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 46 ++++++++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index bc4ad2bcbbec..e58c87fc8cb0 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -2017,6 +2017,52 @@ dispcc: clock-controller@5f00000 {
> #power-domain-cells = <1>;
> };
>
> + qaif_cpu: audio@a000000 {
> + compatible = "qcom,shikra-qaif-cpu";
> + reg = <0x0 0x0a000000 0x0 0x20000>;
> +
> + interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH 0>;
> +
> + clocks = <&gcc GCC_LPASS_CONFIG_CLK>,
> + <&gcc GCC_LPASS_CORE_AXIM_CLK>,
Please align the <s and "s
Konrad
^ permalink raw reply
* Re: [PATCH v7 5/6] remoteproc: qcom: pas: Add late attach support for subsystems
From: Mukesh Ojha @ 2026-06-24 8:08 UTC (permalink / raw)
To: Jingyi Wang
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Manivannan Sadhasivam,
Luca Weiss, Bartosz Golaszewski, Kumar Patro, Komal Bajaj,
Konrad Dybcio, aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang,
linux-arm-msm, linux-remoteproc, devicetree, linux-kernel,
Gokul Krishna Krishnakumar, Shawn Guo
In-Reply-To: <20260623-knp-soccp-v7-5-1ec7bb5c9fec@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 03:05:21AM -0700, Jingyi Wang wrote:
> Subsystems can be brought out of reset by entities such as bootloaders.
> As the irq enablement could be later than subsystem bring up, the state
> of subsystem should be checked by reading SMP2P bits.
>
> A new qcom_pas_attach() function is introduced. if crash state is detected
> for the subsystem, rproc_report_crash() is called. If the ready state is
> detected meanwhile stop state is not detected, it will be marked as
> "attached", otherwise it could be the early boot feature is not supported
> by other entities or it has already been stopped. In above cases, the
> state will be marked as RPROC_OFFLINE so that the PAS driver can load the
> firmware and start the remoteproc.
>
> Co-developed-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> Signed-off-by: Gokul Krishna Krishnakumar <gokul.krishnakumar@oss.qualcomm.com>
> Tested-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_common.h | 6 ++++
> drivers/remoteproc/qcom_q6v5.c | 3 +-
> drivers/remoteproc/qcom_q6v5_pas.c | 68 ++++++++++++++++++++++++++++++++++++++
> drivers/remoteproc/qcom_sysmon.c | 19 +++++++++++
> 4 files changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/qcom_common.h b/drivers/remoteproc/qcom_common.h
> index b07fbaa091a0..b0e7e336d363 100644
> --- a/drivers/remoteproc/qcom_common.h
> +++ b/drivers/remoteproc/qcom_common.h
> @@ -68,6 +68,7 @@ struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
> int ssctl_instance);
> void qcom_remove_sysmon_subdev(struct qcom_sysmon *sysmon);
> bool qcom_sysmon_shutdown_acked(struct qcom_sysmon *sysmon);
> +bool qcom_sysmon_shutdown_irq_state(struct qcom_sysmon *sysmon);
> #else
> static inline struct qcom_sysmon *qcom_add_sysmon_subdev(struct rproc *rproc,
> const char *name,
> @@ -84,6 +85,11 @@ static inline bool qcom_sysmon_shutdown_acked(struct qcom_sysmon *sysmon)
> {
> return false;
> }
> +
> +static inline bool qcom_sysmon_shutdown_irq_state(struct qcom_sysmon *sysmon)
> +{
> + return false;
> +}
> #endif
>
> #endif
> diff --git a/drivers/remoteproc/qcom_q6v5.c b/drivers/remoteproc/qcom_q6v5.c
> index 58d5b85e58cd..a11d8ace554b 100644
> --- a/drivers/remoteproc/qcom_q6v5.c
> +++ b/drivers/remoteproc/qcom_q6v5.c
> @@ -202,7 +202,8 @@ int qcom_q6v5_request_stop(struct qcom_q6v5 *q6v5, struct qcom_sysmon *sysmon)
> q6v5->running = false;
>
> /* Don't perform SMP2P dance if remote isn't running */
> - if (q6v5->rproc->state != RPROC_RUNNING || qcom_sysmon_shutdown_acked(sysmon))
> + if ((q6v5->rproc->state != RPROC_RUNNING && q6v5->rproc->state != RPROC_ATTACHED) ||
> + qcom_sysmon_shutdown_acked(sysmon))
> return 0;
>
> qcom_smem_state_update_bits(q6v5->state,
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index 808e9609988d..8a0bb4b2e71c 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -60,6 +60,7 @@ struct qcom_pas_data {
> int region_assign_count;
> bool region_assign_shared;
> int region_assign_vmid;
> + bool early_boot;
> };
>
> struct qcom_pas {
> @@ -507,6 +508,67 @@ static unsigned long qcom_pas_panic(struct rproc *rproc)
> return qcom_q6v5_panic(&pas->q6v5);
> }
>
> +static int qcom_pas_attach(struct rproc *rproc)
> +{
> + struct qcom_pas *pas = rproc->priv;
> + bool ready_state;
> + bool crash_state;
> + bool stop_state;
> + int ret;
> +
> + pas->q6v5.handover_issued = true;
> + enable_irq(pas->q6v5.handover_irq);
> +
> + pas->q6v5.running = true;
> + ret = irq_get_irqchip_state(pas->q6v5.fatal_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &crash_state);
> + if (ret)
> + goto disable_running;
> +
> + if (crash_state) {
> + dev_err(pas->dev, "Subsystem has crashed before driver probe\n");
> + rproc_report_crash(rproc, RPROC_FATAL_ERROR);
> + ret = -EINVAL;
> + goto disable_running;
> + }
> +
> + ret = irq_get_irqchip_state(pas->q6v5.stop_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &stop_state);
> + if (ret)
> + goto disable_running;
> +
> + if (stop_state || qcom_sysmon_shutdown_irq_state(pas->sysmon)) {
> + dev_info(pas->dev, "Subsystem found stop state set. Falling back to start.\n");
> + goto unroll_attach;
> + }
> +
> + ret = irq_get_irqchip_state(pas->q6v5.ready_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &ready_state);
> + if (ret)
> + goto disable_running;
> +
> + if (unlikely(!ready_state)) {
> + /*
> + * The bootloader may not support early boot, mark the state as
> + * RPROC_OFFLINE so that the PAS driver can load the firmware and
> + * start the remoteproc.
> + */
> + dev_err(pas->dev, "Failed to get subsystem ready interrupt\n");
> + goto unroll_attach;
> + }
> +
> + return 0;
> +
> +unroll_attach:
> + pas->rproc->state = RPROC_OFFLINE;
> + ret = -EINVAL;
> +disable_running:
> + disable_irq(pas->q6v5.handover_irq);
> + pas->q6v5.running = false;
> +
> + return ret;
> +}
> +
> static const struct rproc_ops qcom_pas_ops = {
> .unprepare = qcom_pas_unprepare,
> .start = qcom_pas_start,
> @@ -515,6 +577,7 @@ static const struct rproc_ops qcom_pas_ops = {
> .parse_fw = qcom_pas_parse_firmware,
> .load = qcom_pas_load,
> .panic = qcom_pas_panic,
> + .attach = qcom_pas_attach,
> };
>
> static const struct rproc_ops qcom_pas_minidump_ops = {
> @@ -526,6 +589,7 @@ static const struct rproc_ops qcom_pas_minidump_ops = {
> .load = qcom_pas_load,
> .panic = qcom_pas_panic,
> .coredump = qcom_pas_minidump,
> + .attach = qcom_pas_attach,
> };
>
> static int qcom_pas_init_clock(struct qcom_pas *pas)
> @@ -852,6 +916,10 @@ static int qcom_pas_probe(struct platform_device *pdev)
>
> pas->pas_ctx->use_tzmem = rproc->has_iommu;
> pas->dtb_pas_ctx->use_tzmem = rproc->has_iommu;
> +
> + if (desc->early_boot)
> + pas->rproc->state = RPROC_DETACHED;
> +
> ret = rproc_add(rproc);
> if (ret)
> goto remove_ssr_sysmon;
> diff --git a/drivers/remoteproc/qcom_sysmon.c b/drivers/remoteproc/qcom_sysmon.c
> index 913e3b750a86..a0830a48b1f4 100644
> --- a/drivers/remoteproc/qcom_sysmon.c
> +++ b/drivers/remoteproc/qcom_sysmon.c
> @@ -736,6 +736,25 @@ bool qcom_sysmon_shutdown_acked(struct qcom_sysmon *sysmon)
> }
> EXPORT_SYMBOL_GPL(qcom_sysmon_shutdown_acked);
>
> +bool qcom_sysmon_shutdown_irq_state(struct qcom_sysmon *sysmon)
> +{
> + bool shutdown_state;
> + int ret;
> +
> + if (!sysmon)
> + return false;
> +
> + ret = irq_get_irqchip_state(sysmon->shutdown_irq,
> + IRQCHIP_STATE_LINE_LEVEL, &shutdown_state);
> + if (ret) {
> + dev_warn(sysmon->dev, "failed to get shutdown_state: %d\n", ret);
> + return false;
> + }
> +
> + return shutdown_state;
> +}
> +EXPORT_SYMBOL_GPL(qcom_sysmon_shutdown_irq_state);
> +
> /**
> * sysmon_probe() - probe sys_mon channel
> * @rpdev: rpmsg device handle
>
> --
> 2.34.1
>
I tested the series on Hawi., it works but unsure about newly introduced
stop and shutdown status checking why is it required ? I think, you are
checking this for sanity if it is left some random state by the boot
loader..
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v5 11/16] media: iris: update buffer requirements based on received info
From: Vikash Garodia @ 2026-06-24 8:07 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-11-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> Upon receiving data for HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS the
> driver should update buffer sizes and counts from the received data.
> Implement corresponding functionality updating buffers data. This will
> be used for upcoming support of AR50Lt platforms with Gen1 firmware.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> .../platform/qcom/iris/iris_hfi_gen1_response.c | 75 +++++++++++++++++++++-
> 1 file changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
> index 23fc7194b1e3..896953ea62ea 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
> @@ -533,6 +533,79 @@ static void iris_hfi_gen1_session_ftb_done(struct iris_inst *inst, void *packet)
> dev_err(core->dev, "error in ftb done\n");
> }
>
> +static enum iris_buffer_type iris_hfi_gen1_buf_type(struct iris_inst *inst, u32 type)
> +{
> + switch (type) {
> + case HFI_BUFFER_INPUT:
> + return BUF_INPUT;
> + case HFI_BUFFER_OUTPUT:
> + if (iris_split_mode_enabled(inst))
> + return BUF_DPB;
> + return BUF_OUTPUT;
> + case HFI_BUFFER_OUTPUT2:
> + if (iris_split_mode_enabled(inst))
> + return BUF_OUTPUT;
> + return BUF_DPB;
> + case HFI_BUFFER_INTERNAL_PERSIST_1:
> + return BUF_PERSIST;
> + case HFI_BUFFER_INTERNAL_SCRATCH:
> + return BUF_BIN;
> + case HFI_BUFFER_INTERNAL_SCRATCH_1:
> + return BUF_SCRATCH_1;
> + case HFI_BUFFER_INTERNAL_SCRATCH_2:
> + return BUF_SCRATCH_2;
> + case HFI_BUFFER_INTERNAL_PERSIST:
> + return BUF_ARP;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static void iris_hfi_gen1_session_buffer_requirements(struct iris_inst *inst,
> + void *data, size_t size)
> +{
> + struct hfi_buffer_requirements *req;
> +
> + if (!size || size % sizeof(*req))
> + return;
> +
> + for (req = data; size; size -= sizeof(*req), req++) {
> + enum iris_buffer_type type = iris_hfi_gen1_buf_type(inst, req->type);
> +
> + if (type == -EINVAL)
> + continue;
> +
> + /* on relevant platforms hold_count and min_count are swapped */
> + inst->buffers[type].min_count = req->hold_count;
> + inst->buffers[type].size = req->size;
> +
> + if (type == BUF_OUTPUT)
> + inst->fw_min_count = req->count_actual;
> + }
> +}
> +
> +static void iris_hfi_gen1_session_property_info(struct iris_inst *inst, void *packet)
> +{
> + struct hfi_msg_session_property_info_pkt *pkt = packet;
> +
> + if (!pkt->num_properties) {
> + dev_err(inst->core->dev, "error, no properties\n");
> + goto out;
> + }
> +
> + switch (pkt->property) {
> + case HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS:
If i check the venus message parsing logic, it loops through the packet
till it hits the case. Here, we are assuming the first packet type, in
the pkt to be the property "HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS".
There can be multiple properties in the packet, and if
"HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS" is not the first one, the
usecase would break with incorrect buffer sizes.
> + iris_hfi_gen1_session_buffer_requirements(inst, pkt->data,
> + pkt->shdr.hdr.size - sizeof(*pkt));
> + break;
> + default:
> + dev_warn(inst->core->dev, "unknown property id: %x\n", pkt->property);
> + }
> +
> +out:
> + complete(&inst->completion);
> +}
> +
> struct iris_hfi_gen1_response_pkt_info {
> u32 pkt;
> u32 pkt_sz;
> @@ -657,7 +730,7 @@ static void iris_hfi_gen1_handle_response(struct iris_core *core, void *response
> } else if (hdr->pkt_type == HFI_MSG_SESSION_FILL_BUFFER) {
> iris_hfi_gen1_session_ftb_done(inst, hdr);
> } else if (hdr->pkt_type == HFI_MSG_SESSION_PROPERTY_INFO) {
> - complete(&inst->completion);
> + iris_hfi_gen1_session_property_info(inst, hdr);
> } else {
> struct hfi_msg_session_hdr_pkt *shdr;
>
>
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: kodiak: Sort pinctrl subnodes by pins
From: Luca Weiss @ 2026-06-24 8:00 UTC (permalink / raw)
To: Konrad Dybcio, Luca Weiss, Vladimir Zapolskiy, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <99654e01-3a52-4a9e-b003-24230aa6a248@oss.qualcomm.com>
On Wed Jun 24, 2026 at 9:59 AM CEST, Konrad Dybcio wrote:
> On 6/22/26 9:05 AM, Luca Weiss wrote:
>> On Mon Jun 15, 2026 at 2:09 PM CEST, Konrad Dybcio wrote:
>>> On 6/12/26 3:46 PM, Luca Weiss wrote:
>>>> On Fri Jun 12, 2026 at 2:59 PM CEST, Vladimir Zapolskiy wrote:
>>>>> As documented in the "Devicetree Sources (DTS) Coding Style" document,
>>>>> pinctrl subnodes should be sorted by the pins property. Do this once for
>>>>> kodiak.dtsi so that future additions can be added at the right places.
>>>>>
>>>>> No functional change intended, verified with dtx_diff.
>>>>>
>>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>>> ---
>>>>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 1382 +++++++++++++++++-----------------
>>>>> 1 file changed, 691 insertions(+), 691 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>>> index fa540d8c2615..62daef726d32 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>>
>>>> <snip>
>>>>
>>>>> + qup_uart12_cts: qup-uart12-cts-state {
>>>>> + pins = "gpio48";
>>>>> + function = "qup14";
>>>>> + };
>>>>> +
>>>>> + qup_uart12_rts: qup-uart12-rts-state {
>>>>> + pins = "gpio49";
>>>>> + function = "qup14";
>>>>> + };
>>>>> +
>>>>> + qup_uart12_tx: qup-uart12-tx-state {
>>>>> + pins = "gpio50";
>>>>> + function = "qup14";
>>>>> + };
>>>>>
>>>>> I understand and support the intention to keep this change non-functional,
>>>>> but this pad "gpio50" is for qup16 also, right?
>>>>
>>>> According to my QCM6490 data sheet, GPIO_50 has these functions:
>>>> * UART for qup14 (OK)
>>>> * SPI for qup14 (OK)
>>>> * SPI for qup16 (no pinctrl)
>>>
>>> "no pinctrl" meaning "not defined in the upstream dt as of today"?
>>
>> Correct.
>>
>>>>> Similarly pads "gpio54"/"gpio55" for qup14 function, "gpio62"/"gpio63"
>>>>> for qup16 function, I find all of these are missing on the original list.
>>>>
>>>> GPIO_54:
>>>> * UART qup15 (OK)
>>>> * SPI qup15 (OK)
>>>> * SPI qup14 (no pinctrl)
>>>>
>>>> GPIO_55:
>>>> * UART qup15 (OK)
>>>> * SPI qup15 (OK)
>>>> * SPI qup14 (no pinctrl)
>>>>
>>>> GPIO_62:
>>>> * UART qup17 (OK)
>>>> * SPI qup17 (OK)
>>>> * SPI qup16 (no pinctrl)
>>>>
>>>> GPIO_63:
>>>> * UART qup16 (?)
>>>> * SPI qup16 (lane 3) (?)
>>>> * SPI qup16 (lane 5) (?)
>>>>
>>>> But the GPIO_63 looks weird, is the data sheet wrong?! Where would
>>>> UART_RX of QUP1 SE7 go? Maybe it should be UART qup17 and SPI qup17 and
>>>> then SPI qup16 ??
>>>
>>> GPIO63:
>>>
>>> QUP1_SE6 SPI_CS2
>>> QUP1_SE7 UART_RX/SPI_CS0
>>
>> That matches pinctrl driver and kodiak.dtsi at least. Still, the data
>> sheet is just wrong there. If you have any contact to relevant people
>> there, please let them know!
>
> Please share the 80-xxxx-xx number and I'll see what I can do
80-20659-1 Rev. AM
Regards
Luca
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: kodiak: Sort pinctrl subnodes by pins
From: Konrad Dybcio @ 2026-06-24 7:59 UTC (permalink / raw)
To: Luca Weiss, Vladimir Zapolskiy, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <DJFDYAS1AY8Z.3GD4A5UMWLAUC@fairphone.com>
On 6/22/26 9:05 AM, Luca Weiss wrote:
> On Mon Jun 15, 2026 at 2:09 PM CEST, Konrad Dybcio wrote:
>> On 6/12/26 3:46 PM, Luca Weiss wrote:
>>> On Fri Jun 12, 2026 at 2:59 PM CEST, Vladimir Zapolskiy wrote:
>>>> As documented in the "Devicetree Sources (DTS) Coding Style" document,
>>>> pinctrl subnodes should be sorted by the pins property. Do this once for
>>>> kodiak.dtsi so that future additions can be added at the right places.
>>>>
>>>> No functional change intended, verified with dtx_diff.
>>>>
>>>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 1382 +++++++++++++++++-----------------
>>>> 1 file changed, 691 insertions(+), 691 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> index fa540d8c2615..62daef726d32 100644
>>>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>>>
>>> <snip>
>>>
>>>> + qup_uart12_cts: qup-uart12-cts-state {
>>>> + pins = "gpio48";
>>>> + function = "qup14";
>>>> + };
>>>> +
>>>> + qup_uart12_rts: qup-uart12-rts-state {
>>>> + pins = "gpio49";
>>>> + function = "qup14";
>>>> + };
>>>> +
>>>> + qup_uart12_tx: qup-uart12-tx-state {
>>>> + pins = "gpio50";
>>>> + function = "qup14";
>>>> + };
>>>>
>>>> I understand and support the intention to keep this change non-functional,
>>>> but this pad "gpio50" is for qup16 also, right?
>>>
>>> According to my QCM6490 data sheet, GPIO_50 has these functions:
>>> * UART for qup14 (OK)
>>> * SPI for qup14 (OK)
>>> * SPI for qup16 (no pinctrl)
>>
>> "no pinctrl" meaning "not defined in the upstream dt as of today"?
>
> Correct.
>
>>>> Similarly pads "gpio54"/"gpio55" for qup14 function, "gpio62"/"gpio63"
>>>> for qup16 function, I find all of these are missing on the original list.
>>>
>>> GPIO_54:
>>> * UART qup15 (OK)
>>> * SPI qup15 (OK)
>>> * SPI qup14 (no pinctrl)
>>>
>>> GPIO_55:
>>> * UART qup15 (OK)
>>> * SPI qup15 (OK)
>>> * SPI qup14 (no pinctrl)
>>>
>>> GPIO_62:
>>> * UART qup17 (OK)
>>> * SPI qup17 (OK)
>>> * SPI qup16 (no pinctrl)
>>>
>>> GPIO_63:
>>> * UART qup16 (?)
>>> * SPI qup16 (lane 3) (?)
>>> * SPI qup16 (lane 5) (?)
>>>
>>> But the GPIO_63 looks weird, is the data sheet wrong?! Where would
>>> UART_RX of QUP1 SE7 go? Maybe it should be UART qup17 and SPI qup17 and
>>> then SPI qup16 ??
>>
>> GPIO63:
>>
>> QUP1_SE6 SPI_CS2
>> QUP1_SE7 UART_RX/SPI_CS0
>
> That matches pinctrl driver and kodiak.dtsi at least. Still, the data
> sheet is just wrong there. If you have any contact to relevant people
> there, please let them know!
Please share the 80-xxxx-xx number and I'll see what I can do
Konrad
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: qcom: lemans-evk: Describe the PCIe M.2 Key E connector
From: Konrad Dybcio @ 2026-06-24 7:59 UTC (permalink / raw)
To: Wei Deng, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, quic_chezhou,
cheng.jiang, shuai.zhang, jinwang.li, xiuzhuo.shang, mengshi.wu,
Dmitry Baryshkov, Manivannan Sadhasivam, Bartosz Golaszewski
In-Reply-To: <20260622-v3-lemans-split-v3-2-d26bb22594e3@oss.qualcomm.com>
On 6/22/26 8:41 AM, Wei Deng wrote:
> The lemans EVK has the PCIe M.2 Mechanical Key E connector to connect
> wireless connectivity cards over PCIe and UART interfaces. Hence,
> describe the connector node and link it with the PCIe 0 Root Port and
> UART17 nodes through graph port/endpoint.
>
> The M.2 Key E connector is powered by a 3.3V fixed regulator
> (vreg_wcn_3p3) which is sourced from the board's 12V DC input rail
> (vreg_dcin_12v). Both regulators are always-on and are required by the
> pcie-m2-e-connector binding.
>
> Also add the serial1 = &uart17 alias, which is required for the
> Bluetooth serdev device to be enumerated on the UART17 interface.
>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: mediatek: cec: Correct the compatibles for mt7623-mt8167
From: Krzysztof Kozlowski @ 2026-06-24 7:58 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, CK Hu, Jitao shi,
dri-devel, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260623135757.5111-1-l.scorcia@gmail.com>
On Tue, Jun 23, 2026 at 03:57:53PM +0200, Luca Leonardo Scorcia wrote:
> The HDMI CEC driver for both mt7623 and mt8167 is actually the same as
> mt8173-cec and the mt7623n.dtsi board include file already uses mt8173-cec
> compatible as a fallback, but the documentation lists them as separate
> entries. Correct the binding by adding the correct fallback.
>
> This change fixes a dtbs_check error.
which one? here you paste it (can be trimmed a bit)
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../bindings/display/mediatek/mediatek,cec.yaml | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
> index 080cf321209e..4d741ba415e8 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
> @@ -15,10 +15,13 @@ description: |
>
> properties:
> compatible:
> - enum:
> - - mediatek,mt7623-cec
> - - mediatek,mt8167-cec
> - - mediatek,mt8173-cec
> + oneOf:
> + - const: mediatek,mt8173-cec
> + - items:
> + - enum:
"This change fixes a dtbs_check error."
... and introduces new other errors, so error count stays the same. Not
great.
It does not look like you tested the bindings, at least after quick
look. Please run 'make dt_binding_check' (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint. Don't rely on
distro packages for dtschema and be sure you are using the latest
released dtschema.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: socfpga: agilex7-gen2: Add initial device tree
From: Krzysztof Kozlowski @ 2026-06-24 7:57 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260623111716.16690-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 23, 2026 at 04:17:16AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + intc: interrupt-controller@7000000 {
MMIO goes to MMIO, please read writing bindings and submitting patches docs in DT dir.
I think this also fails tests (W=1). If that is true, then review should
finish here, because instead of using machine to find issues you use
community.
> + compatible = "arm,gic-v3";
> + reg = <0x0 0x7000000 0x0 0x10000>,
> + <0x0 0x7080000 0x0 0x100000>;
> + ranges;
> + #interrupt-cells = <3>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + interrupt-controller;
> + #redistributor-regions = <1>;
> + redistributor-stride = <0x0 0x40000>;
> +
> + its: msi-controller@7040000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x0 0x7040000 0x0 0x20000>;
> + msi-controller;
> + #msi-cells = <1>;
> + };
> + };
> +
> + soc: soc@0 {
> + compatible = "simple-bus";
> + ranges = <0 0 0 0xffffffff>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + interrupt-parent = <&intc>;
> +
> + smmu: iommu@c100000 {
> + compatible = "arm,smmu-v3";
> + reg = <0x0c100000 0x30000>;
> + interrupts = <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "eventq", "gerror", "priq";
> + dma-coherent;
> + #iommu-cells = <1>;
> + };
> +
> + ocram: sram@0 {
> + compatible = "mmio-sram";
> + reg = <0x00000000 0x80000>;
> + ranges = <0 0 0x80000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
SoC without any interface, serial or storage or network, is close to
useless one.
I don't see a point in having it in mainline. Serial is usually ABSOLUTE
minimum.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: altera: Add Agilex7 Gen2 SoCFPGA compatible strings
From: Krzysztof Kozlowski @ 2026-06-24 7:55 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, robh, krzk+dt, conor+dt, devicetree, linux-kernel
In-Reply-To: <20260623111716.16690-2-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 23, 2026 at 04:17:15AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Add the SoC and board compatible strings for the Intel SoCFPGA
> Agilex7 Gen2 platform.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> Documentation/devicetree/bindings/arm/altera.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: clock: qcom: Document Nord display clock controller
From: Krzysztof Kozlowski @ 2026-06-24 7:53 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Shawn Guo, Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Konrad Dybcio, Ajit Pandey,
Imran Shaik, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-3-860c84539804@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 04:24:06PM +0530, Taniya Das wrote:
> Add Device Tree binding documentation for the display clock controller
> on the Qualcomm Nord SoC.
>
> The Nord platform contains two instances of the display clock controller,
> DISPCC_0 and DISPCC_1. Update the bindings to include compatible strings
> for both instances.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
...
> diff --git a/include/dt-bindings/clock/qcom,nord-dispcc.h b/include/dt-bindings/clock/qcom,nord-dispcc.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..9f6c9979e0f358678f28a992af6083b0ae6c97e1
> --- /dev/null
> +++ b/include/dt-bindings/clock/qcom,nord-dispcc.h
> @@ -0,0 +1,115 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _DT_BINDINGS_CLK_QCOM_DISP_CC_NORD_H
> +#define _DT_BINDINGS_CLK_QCOM_DISP_CC_NORD_H
> +
> +/* DISP_CC_0 clocks */
Where are clocks/resets/power domains for DISP_CC_1?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: mmc: Convert TI OMAP2420 MMC to DT schema
From: Krzysztof Kozlowski @ 2026-06-24 7:51 UTC (permalink / raw)
To: Eduard Bostina
Cc: daniel.baluta, simona.toaca, goledhruva, m-chawdhry, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mmc,
devicetree, linux-kernel
In-Reply-To: <20260623094336.4172741-1-egbostina@gmail.com>
On Tue, Jun 23, 2026 at 09:43:35AM +0000, Eduard Bostina wrote:
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + ti,hwmods:
> + description: |
> + Name of the hwmod associated to the MMC controller. Must be
> + "msdi<n>" where n is the controller instance starting from 1.
> + $ref: /schemas/types.yaml#/definitions/string-array
You should not use different type than already used and currently this
is a string (so also no items below).
> + items:
> + - pattern: "^msdi[0-9]+$"
"^msdi([1-9]|[1-9][0-9]+)$"
> +
> + dmas:
> + maxItems: 2
> +
> + dma-names:
> + items:
> + - const: tx
> + - const: rx
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 10/16] media: iris: add minimal GET_PROPERTY implementation
From: Vikash Garodia @ 2026-06-24 7:51 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-10-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> AR50Lt with the Gen1 firmware requires host to read
> HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS property, otherwise it doesn't
> update internal data and fails the HFI_CMD_SESSION_LOAD_RESOURCES
> command. Implement minimal support for querying the properties from the
> firmware.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_hfi_common.h | 1 +
> .../platform/qcom/iris/iris_hfi_gen1_command.c | 21 +++++++++++++++++++++
> .../platform/qcom/iris/iris_hfi_gen1_defines.h | 15 +++++++++++++++
> .../platform/qcom/iris/iris_hfi_gen1_response.c | 6 ++++++
> 4 files changed, 43 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_common.h b/drivers/media/platform/qcom/iris/iris_hfi_common.h
> index a27447eb2519..16099f9a25b6 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_common.h
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_common.h
> @@ -121,6 +121,7 @@ struct iris_hfi_session_ops {
> int (*session_set_property)(struct iris_inst *inst,
> u32 packet_type, u32 flag, u32 plane, u32 payload_type,
> void *payload, u32 payload_size);
> + int (*session_get_property)(struct iris_inst *inst, u32 packet_type);
> int (*session_open)(struct iris_inst *inst);
> int (*session_start)(struct iris_inst *inst, u32 plane);
> int (*session_queue_buf)(struct iris_inst *inst, struct iris_buffer *buffer);
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
> index 7674b47ad6c4..99e82e5510ab 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_command.c
> @@ -1117,10 +1117,31 @@ static int iris_hfi_gen1_session_set_config_params(struct iris_inst *inst, u32 p
> return 0;
> }
>
> +static int iris_hfi_gen1_session_get_property(struct iris_inst *inst, u32 packet_type)
> +{
> + struct hfi_session_get_property_pkt pkt;
> + int ret;
> +
> + pkt.shdr.hdr.size = sizeof(pkt);
> + pkt.shdr.hdr.pkt_type = HFI_CMD_SESSION_GET_PROPERTY;
> + pkt.shdr.session_id = inst->session_id;
> + pkt.num_properties = 1;
> + pkt.data = packet_type;
> +
> + reinit_completion(&inst->completion);
> +
> + ret = iris_hfi_queue_cmd_write(inst->core, &pkt, pkt.shdr.hdr.size);
> + if (ret)
> + return ret;
> +
> + return iris_wait_for_session_response(inst, false);
> +}
> +
> static const struct iris_hfi_session_ops iris_hfi_gen1_session_ops = {
> .session_open = iris_hfi_gen1_session_open,
> .session_set_config_params = iris_hfi_gen1_session_set_config_params,
> .session_set_property = iris_hfi_gen1_session_set_property,
> + .session_get_property = iris_hfi_gen1_session_get_property,
was looking for caller for this property, saw that in patch#12 to update
the size. Commit should have mentioned about it.
> .session_start = iris_hfi_gen1_session_start,
> .session_queue_buf = iris_hfi_gen1_session_queue_buffer,
> .session_release_buf = iris_hfi_gen1_session_unset_buffers,
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_defines.h b/drivers/media/platform/qcom/iris/iris_hfi_gen1_defines.h
> index 0e4dee192384..bb495a1d2623 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_defines.h
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_defines.h
> @@ -35,6 +35,7 @@
> #define HFI_CMD_SESSION_EMPTY_BUFFER 0x211004
> #define HFI_CMD_SESSION_FILL_BUFFER 0x211005
> #define HFI_CMD_SESSION_FLUSH 0x211008
> +#define HFI_CMD_SESSION_GET_PROPERTY 0x211009
> #define HFI_CMD_SESSION_RELEASE_BUFFERS 0x21100b
> #define HFI_CMD_SESSION_RELEASE_RESOURCES 0x21100c
> #define HFI_CMD_SESSION_CONTINUE 0x21100d
> @@ -113,6 +114,7 @@
> #define HFI_MSG_SESSION_FLUSH 0x221006
> #define HFI_MSG_SESSION_EMPTY_BUFFER 0x221007
> #define HFI_MSG_SESSION_FILL_BUFFER 0x221008
> +#define HFI_MSG_SESSION_PROPERTY_INFO 0x221009
> #define HFI_MSG_SESSION_RELEASE_RESOURCES 0x22100a
> #define HFI_MSG_SESSION_RELEASE_BUFFERS 0x22100c
>
> @@ -205,6 +207,12 @@ struct hfi_session_set_property_pkt {
> u32 data[];
> };
>
> +struct hfi_session_get_property_pkt {
> + struct hfi_session_hdr_pkt shdr;
> + u32 num_properties;
> + u32 data;
> +};
> +
> struct hfi_sys_pc_prep_pkt {
> struct hfi_pkt_hdr hdr;
> };
> @@ -574,6 +582,13 @@ struct hfi_msg_session_fbd_uncompressed_plane0_pkt {
> u32 data[];
> };
>
> +struct hfi_msg_session_property_info_pkt {
> + struct hfi_session_hdr_pkt shdr;
> + u32 num_properties;
> + u32 property;
> + u8 data[];
> +};
> +
> struct hfi_msg_session_release_buffers_done_pkt {
> struct hfi_msg_session_hdr_pkt shdr;
> u32 num_buffers;
> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
> index bfd7495bf44f..23fc7194b1e3 100644
> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen1_response.c
> @@ -591,6 +591,10 @@ static const struct iris_hfi_gen1_response_pkt_info pkt_infos[] = {
> .pkt = HFI_MSG_SESSION_RELEASE_BUFFERS,
> .pkt_sz = sizeof(struct hfi_msg_session_release_buffers_done_pkt),
> },
> + {
> + .pkt = HFI_MSG_SESSION_PROPERTY_INFO,
> + .pkt_sz = sizeof(struct hfi_msg_session_property_info_pkt),
> + },
> };
>
> static void iris_hfi_gen1_handle_response(struct iris_core *core, void *response)
> @@ -652,6 +656,8 @@ static void iris_hfi_gen1_handle_response(struct iris_core *core, void *response
> iris_hfi_gen1_session_etb_done(inst, hdr);
> } else if (hdr->pkt_type == HFI_MSG_SESSION_FILL_BUFFER) {
> iris_hfi_gen1_session_ftb_done(inst, hdr);
> + } else if (hdr->pkt_type == HFI_MSG_SESSION_PROPERTY_INFO) {
> + complete(&inst->completion);
> } else {
> struct hfi_msg_session_hdr_pkt *shdr;
>
>
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Krzysztof Kozlowski @ 2026-06-24 7:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: Krzysztof Kozlowski, Jie Luo, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lei Wei, Suruchi Agarwal, Pavithra R,
linux-kernel, linux-arm-msm, linux-clk, devicetree, netdev
In-Reply-To: <0c1be662-3c6a-41be-bc19-081d0299ceae@lunn.ch>
On Tue, Jun 23, 2026 at 01:33:05PM +0200, Andrew Lunn wrote:
> > If address did not work for half a year, I really doubt that you commit
> > to above.
>
> I tend to agree. Maybe we should set it to Orphaned, and then decide
> in 6 months time if it can be set back to Maintained?
That would be a bit stronger than I intended and actual responses from
Jie did happen, thus the driver actually might be maintained. I also
think that Qualcomm is committed to maintain it, I only doubt about
supported.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: chipcap2: Add label property
From: Krzysztof Kozlowski @ 2026-06-24 7:45 UTC (permalink / raw)
To: Flaviu Nistor
Cc: Guenter Roeck, Javier Carrasco, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, linux-hwmon,
linux-kernel, devicetree, linux-doc
In-Reply-To: <20260623192217.4804-1-flaviu.nistor@gmail.com>
On Tue, Jun 23, 2026 at 10:22:17PM +0300, Flaviu Nistor wrote:
> On 6/23/26 9:58 PM CET, Guenter Roeck wrote:
> >On 6/23/26 11:16, Flaviu Nistor wrote:
> >> On Mon Jun 22, 2026 at 7:29 PM CEST, Javier Carrasco wrote:
> >>> On Mon Jun 22, 2026 at 2:21 PM CEST, Flaviu Nistor wrote:
> >>>> Add support for an optional label property similar to other hwmon devices
> >>>> This allows, in case of boards with multiple CHIPCAP2 sensors, to assign
> >>>> distinct names to each instance.
> >>>>
> >>>> Signed-off-by: Flaviu Nistor <flaviu.nistor@gmail.com>
> >>>> ---
> >>>> .../devicetree/bindings/hwmon/amphenol,chipcap2.yaml | 5 +++++
> >>>> 1 file changed, 5 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.ya=
> >>> ml b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> >>>> index 17351fdbefce..f00b5a4b14dd 100644
> >>>> --- a/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> >>>> +++ b/Documentation/devicetree/bindings/hwmon/amphenol,chipcap2.yaml
> >>>> @@ -33,6 +33,10 @@ properties:
> >>>> reg:
> >>>> maxItems: 1
> >>>>
> >>>> + label:
> >>>> + description:
> >>>> + A descriptive name for this channel, like "ambient" or "psu".
> >>>> +
> >>>> interrupts:
> >>>> items:
> >>>> - description: measurement ready indicator
> >>>> @@ -72,6 +76,7 @@ examples:
> >>>> <5 IRQ_TYPE_EDGE_RISING>,
> >>>> <6 IRQ_TYPE_EDGE_RISING>;
> >>>> interrupt-names =3D "ready", "low", "high";
> >>>> + label =3D "somelabel";
> >>>> vdd-supply =3D <®_vdd>;
> >>>> };
> >>> };
> >>>
> >>> Hello Falviu, thank you for your patch.
> >>>
> >>
> >> Hello Javier, thanks for your reply.
> >>
> >>> Should we not add a reference to hwmon-common.yaml (with
> >>> unevelautedProperties instead of additionalProperties), as label is
> >>> defined there? I believe that Krzysztof Kozlowski did something similar
> >>> for the shunt-resistor-micro-ohms property. Could we follow suit here?
> >>>
> >>
> >> This is a good question and I am happy you asked. I also thought a lot
> >> about this and the reason I decided to go for this approach is that by using
> >> $ref: hwmon-common.yaml#, I would have to change additionalProperties: false
> >> to unevaluatedProperties: false, which will evaluate in case it is used, also
> >> shunt-resistor-micro-ohms property which does not apply to this sensor. At
> >> least this is my understanding, but of course I can be wrong (I see lm75 binding
> >> also uses $ref: hwmon-common.yaml# but shunt-resistor-micro-ohms does not apply).
> >>
> >
> >Where does the idea come from that shunt-resistor-micro-ohms would be mandatory ?
> >That would make hwmon-common.yaml unusable for most chips.
>
> I think this is a misunderstanding since I never had the intention to imply that
> shunt-resistor-micro-ohms would be mandatory, but rather I observed that if I used
> $ref: hwmon-common.yaml#, property shunt-resistor-micro-ohms can be added (no need to,
> but still possible) in the example section and the dt_binding_check will pass.
> Since hwmon-common.yaml is already there I will change the binding in a v2 and use it.
I propose to reference hwmon-common.yaml with:
label: true
additionalProperties: false
thus shunt-resistor won't be allowed but you still will reference common
schema for the definition of common properties.
Best regards,
Krzysztof
^ 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