* RE: [EXT] Re: [PATCH 4/5] arm64: dts: imx93: Cortex-A Core remoteproc device node
From: Jiafei Pan @ 2026-04-30 6:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, andersson@kernel.org,
mathieu.poirier@linaro.org, Peng Fan, Frank Li,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Z.Q. Hou, Mingkai Hu, Jiafei Pan
In-Reply-To: <b7e93b01-39aa-4a9f-9927-6c634a6c727c@kernel.org>
> On 28/04/2026 11:08, Jiafei Pan wrote:
> > + init-on-array = <IMX93_CLK_LPUART2_GATE>; };
> > diff --git a/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
> > b/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
> > new file mode 100644
> > index 000000000000..9d9a60404d2b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
>
> Heh? A DTSI file for one device node?
>
> This looks a lot like downstream approach.
Use a dtsi file which could be leveraged by multiple boards, otherwise what's your suggestion? Thanks.
Jiafei.
>
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2024-2026 NXP
> > + */
> > +
> > +/ {
> > + ca55_1: remoteproc-ca55-1 {
> > + compatible = "fsl,imx-rproc-psci";
>
> Also, you cannot have non-SoC compatibles for SoC component. Nothing here,
> nor in the binding patch, explains that.
>
> >
> Best regards,
> Krzysztof
Actually it is CPU Core related dts nodes, so I put it in SoC.
Jiafei.
^ permalink raw reply
* Re: Re: [PATCH net-next v7 4/4] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
From: 李志 @ 2026-04-30 7:05 UTC (permalink / raw)
To: Andrew Lunn
Cc: devicetree, andrew+netdev, davem, edumazet, kuba, robh, krzk+dt,
conor+dt, netdev, pabeni, mcoquelin.stm32, alexandre.torgue,
rmk+kernel, pjw, palmer, aou, alex, linux-riscv, linux-stm32,
linux-arm-kernel, linux-kernel, maxime.chevallier, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms
In-Reply-To: <d662fa07-cd0f-48c4-a6e4-03c5fd390e92@lunn.ch>
> -----原始邮件-----
> 发件人: "Andrew Lunn" <andrew@lunn.ch>
> 发送时间:2026-04-29 09:41:53 (星期三)
> 收件人: lizhi2@eswincomputing.com
> 抄送: devicetree@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, linux-riscv@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, maxime.chevallier@bootlin.com, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com, pritesh.patel@einfochips.com, weishangjuan@eswincomputing.com, horms@kernel.org
> 主题: Re: [PATCH net-next v7 4/4] riscv: dts: eswin: eic7700-hifive-premier-p550: enable Ethernet controller
>
> > +&gmac1 {
> > + phy-handle = <&gmac1_phy0>;
> > + /*
> > + * For the TX path of gmac1, there is a skew between the TX clock
> > + * and data on the MAC controller inside the silicon. This skew happens
> > + * to be approximately 2 ns. Therefore, it can be considered that the
> > + * 2 ns delay of TX is provided by the MAC.
> > + * No delay configuration for tx is needed in software via PHY driver.
> > + */
> > + phy-mode = "rgmii-rxid";
>
> This is wrong. Take a read of
>
> https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
>
> phy-mode describes the board. If the board provides the 2ns delay, you
> use rgmii. If the MAC/PHY pair needs to provide the delay, you using
> rgmii-id.
>
> If rgmii-id is used, it is up to the MAC/PHY to decide which will add
> the delay. If the MAC adds the delay, it needs to mask the value of
> phy-mode it passes to the PHY so it does not also add the delay.
>
> Your broken hardware means you cannot support 'rgmii' or 'rgmii-rx',
> since you cannot turn off this 2ns delay, so you end up with double
> delays if anybody designs a board with 2ns TX delay on the board
> itself. So please validate the PHY modes and return -EINVAL if these
> modes are used.
>
Thanks for the detailed explanation.
You are right that phy-mode should describe the board-level
configuration and should not be modified in the DT to reflect
MAC-internal behavior.
For this hardware, the MAC unconditionally introduces an ~2 ns
TX delay which cannot be disabled. This means the configuration
effectively matches rgmii-id at the board level, where TX delay
is provided by the MAC and RX delay by the PHY.
I will therefore:
- Keep the DT using phy-mode = "rgmii-id" to correctly describe
the board-level timing.
- In the driver, mask the phy_interface passed to the PHY so that
it does not add TX delay, avoiding double delay.
- Explicitly reject unsupported modes such as "rgmii" and
"rgmii-rxid", since the MAC TX delay cannot be disabled and
these configurations would lead to incorrect timing.
Regarding the tx-internal-delay-ps property, it represents the
total effective TX delay on the line, including the inherent
~2 ns skew introduced by the MAC silicon. The driver subtracts
this inherent skew and programs only the remaining delay.
As a result, for the clk-inversion variant, the valid range is
[2000, 4540], which matches the updated binding constraints.
I will clarify in the binding description that this property
represents the total TX delay (MAC + programmable), to avoid
ambiguity.
Thanks for pointing this out.
^ permalink raw reply
* Re: [PATCH v2 0/4] ARM: pxa: attach software nodes to the GPIO controllers
From: Bartosz Golaszewski @ 2026-04-30 7:14 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartosz Golaszewski, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Russell King, Dmitry Torokhov, Linus Walleij, linux-arm-kernel,
open list:GPIO SUBSYSTEM, linux-kernel
In-Reply-To: <CAMRc=Mf9M_eoPzsqBdmnXLd8Eqw_cPcnXWN9xjC-+x5ZA5Qb_Q@mail.gmail.com>
On Mon, Apr 27, 2026 at 1:01 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
>
> On Mon, Apr 27, 2026 at 12:50 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > On Mon, Apr 27, 2026, at 12:14, Bartosz Golaszewski wrote:
> > > Convert GPIO controllers and their consumers on the PXA platform to using
> > > "attached" software nodes. Since everything happens in a bord-file, it's
> > > quite straightforward. We technically now have a way of passing an
> > > unregistered software node to platform_device_register_full() but that
> > > requires using struct platform_device_info and since the existing
> > > platform devices are either referenced from other places or defined in a
> > > different compilation unit, I wanted to reduce the impact of the changes
> > > I can't test and went with the older method.
> > >
> > > Signed-off-by: Bartosz Golaszewski
> > > <bartosz.golaszewski@oss.qualcomm.com>
> > > ---
> >
> > Hi Bartosz,
> >
> > These patches are individually all fine, but I was hoping to
> > finally get around to removing the pxa board files completely,
> > sorry it's been taking me so long to rebase my series for
> > that.
> >
>
> If that'll be queued for v7.2, then I'm fine with dropping this
> series. Otherwise, I'd like to see it applied as I want to get all the
> changes required to remove the software node name matching from
> GPIOLIB into v7.2 and then finally remove it in v7.3.
>
Hi Arnd!
Before I address Russell's comment in v2, can you please let me know
if pxa will be removed in v7.2?
Bart
^ permalink raw reply
* Re: [PATCH] drm/ipv3: add CONFIG_OF dependency for DRM_OF_DISPLAY_MODE_BRIDGE
From: Luca Ceresoli @ 2026-04-30 7:17 UTC (permalink / raw)
To: Arnd Bergmann, Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Damon Ding
Cc: Arnd Bergmann, Pengutronix Kernel Team, Fabio Estevam, dri-devel,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260429140024.192432-1-arnd@kernel.org>
On Wed Apr 29, 2026 at 4:00 PM CEST, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Without this, not all dependencies are met here.
>
> Depends on [n]: HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=n]
> Selected by [y]:
> - DRM_IMX_PARALLEL_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_IMX [=y]
> - DRM_IMX_LDB [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_IMX [=y] && COMMON_CLK [=y]
>
> Fixes: ba2db93cf3d5 ("drm/bridge: Move legacy bridge driver out of imx directory for multi-platform use")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RESEND,v2 1/2] dt-bindings: memory-controllers: mtk-smi: Add support for mt8189
From: Zhengnan Chen (陈征南) @ 2026-04-30 7:22 UTC (permalink / raw)
To: krzk@kernel.org
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, Yong Wu (吴勇),
conor+dt@kernel.org, robh@kernel.org,
Project_Global_Chrome_Upstream_Group,
linux-arm-kernel@lists.infradead.org, matthias.bgg@gmail.com,
AngeloGioacchino Del Regno
In-Reply-To: <20260428-topaz-turtle-of-support-f5b9ec@quoll>
On Tue, 2026-04-28 at 08:26 +0200, Krzysztof Kozlowski wrote:
> On Mon, Apr 27, 2026 at 03:04:28PM +0800, mtk20898 wrote:
> > properties:
> > compatible:
> > oneOf:
> > @@ -40,6 +55,8 @@ properties:
> > - mediatek,mt8186-smi-common
> > - mediatek,mt8188-smi-common-vdo
> > - mediatek,mt8188-smi-common-vpp
> > + - mediatek,mt8189-smi-common
> > + - mediatek,mt8189-smi-sub-common
> > - mediatek,mt8192-smi-common
> > - mediatek,mt8195-smi-common-vdo
> > - mediatek,mt8195-smi-common-vpp
> > @@ -108,19 +125,23 @@ allOf:
> > compatible:
> > contains:
> > enum:
> > + - mediatek,mt8189-smi-sub-common
> > - mediatek,mt8195-smi-sub-common
> > then:
> > required:
> > - mediatek,smi
> > properties:
> > clocks:
> > - minItems: 3
> > + minItems: 2
>
> Same problem as v2 before resend.
>
> Please explain me how mt8195 requires three clocks. You can prove it
> by
> trying a malformed DTS (past here the snippet/diff) and pasting here
> the
> validation error.
>
>
> Best regards,
> Krzysztof
>
The mt8195 smi-sub-comm has a three-clock configuration, for example:
smi_sub_common_cam_7x1: smi@16005000 {
compatible = "mediatek,mt8195-smi-sub-common";
reg = <0 0x16005000 0 0x1000>;
clocks = <&camsys CLK_CAM_LARB14>,
<&camsys CLK_CAM_CAM2MM1_GALS>,
<&vppsys0 CLK_VPP0_GALS_IMGSYS_CAMSYS>;
clock-names = "apb", "smi", "gals0";
mediatek,smi = <&smi_common_vpp>;
power-domains = <&spm MT8195_POWER_DOMAIN_CAM>;
};
but mt8189 smi-sub-comm only requires 2 clock cycles,
there is no case where three clock cycles are needed, for example:
smi_cam_3x1_sub_comm: smi@1a00c000 {
compatible = "mediatek,mt8189-smi-sub-common";
reg = <0 0x1a00c000 0 0x1000>;
clocks = <&camsys_main_clk CLK_CAM_M_CAM2MM_GALS>,
<&camsys_main_clk CLK_CAM_M_CAM2MM_GALS>;
clock-names = "apb", "smi";
power-domains = <&spm MT8189_POWER_DOMAIN_CAM_MAIN>;
mediatek,smi = <&smi_disp_common>;
};
Our current approach is rather lenient.
If stricter restrictions are needed, it should be revised.
We want to change it to a format similar to the following:
allOf:
# Generic rule: only sub-common nodes can have mediatek,smi
- if:
properties:
compatible:
contains:
pattern: "^mediatek,mt[0-9]+-smi-sub-common$"
then:
required:
- mediatek,smi
else:
properties:
mediatek,smi: false
# Group A: sub-common SoCs with exactly 2 clocks
- if:
properties:
compatible:
contains:
enum:
- mediatek,mt8189-smi-sub-common
then:
properties:
clocks:
minItems: 2
maxItems: 2
clock-names:
minItems: 2
maxItems: 2
items:
- const: apb
- const: smi
# Group B: sub-common SoCs with exactly 3 clocks
- if:
properties:
compatible:
contains:
enum:
- mediatek,mt8195-smi-sub-common
then:
properties:
clocks:
minItems: 3
maxItems: 3
clock-names:
minItems: 3
maxItems: 3
items:
- const: apb
- const: smi
- const: gals0
Is this writing okay?
^ permalink raw reply
* Re: [PATCH v6 13/19] dt-bindings: dma: ti: Add K3 BCDMA V2
From: Krzysztof Kozlowski @ 2026-04-30 7:29 UTC (permalink / raw)
To: Sai Sree Kartheek Adivi
Cc: peter.ujfalusi, vkoul, robh, krzk+dt, conor+dt, nm, ssantosh,
dmaengine, devicetree, linux-kernel, linux-arm-kernel, vigneshr,
Frank.li, r-sharma3, gehariprasath
In-Reply-To: <20260428085202.1724548-14-s-adivi@ti.com>
On Tue, Apr 28, 2026 at 02:21:42PM +0530, Sai Sree Kartheek Adivi wrote:
> New binding document for
I don't see improvements.
> Texas Instruments K3 Block Copy DMA (BCDMA) V2.
>
> BCDMA V2 is introduced as part of AM62L.
>
> Signed-off-by: Sai Sree Kartheek Adivi <s-adivi@ti.com>
> ---
> .../bindings/dma/ti/ti,am62l-dmss-bcdma.yaml | 121 ++++++++++++++++++
> 1 file changed, 121 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/ti/ti,am62l-dmss-bcdma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/ti/ti,am62l-dmss-bcdma.yaml b/Documentation/devicetree/bindings/dma/ti/ti,am62l-dmss-bcdma.yaml
> new file mode 100644
> index 0000000000000..28dcfce5633ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ti/ti,am62l-dmss-bcdma.yaml
> @@ -0,0 +1,121 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2024-25 Texas Instruments Incorporated
> +# Author: Sai Sree Kartheek Adivi <s-adivi@ti.com>
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/ti/ti,am62l-dmss-bcdma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments K3 DMSS BCDMA V2
> +
> +maintainers:
> + - Sai Sree Kartheek Adivi <s-adivi@ti.com>
> +
> +description:
> + The BCDMA V2 is intended to perform similar functions as the TR
> + mode channels of K3 UDMA-P.
> + BCDMA V2 includes block copy channels and Split channels.
> +
> + Block copy channels mainly used for memory to memory transfers, but with
> + optional triggers a block copy channel can service peripherals by accessing
> + directly to memory mapped registers or area.
> +
> + Split channels can be used to service PSI-L based peripherals.
> + The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
> + with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and the
> + legacy peripheral.
> +
> +allOf:
> + - $ref: /schemas/dma/dma-controller.yaml#
> +
> +properties:
> + compatible:
> + const: ti,am62l-dmss-bcdma
> +
> + reg:
> + items:
> + - description: BCDMA Control & Status Registers region
> + - description: Block Copy Channel Realtime Registers region
> + - description: Channel Realtime Registers region
> + - description: Ring Realtime Registers region
> +
> + reg-names:
> + items:
> + - const: gcfg
> + - const: bchanrt
> + - const: chanrt
> + - const: ringrt
> +
> + "#address-cells":
> + const: 0
Why do you need address-cells?
> +
> + "#dma-cells":
> + const: 4
> + description: |
> + cell 1: Trigger type for the channel
> + 0 - disable / no trigger
> + 1 - internal channel event
> + 2 - external signal
> + 3 - timer manager event
> +
> + cell 2: parameter for the trigger:
> + if cell 1 is 0 (disable / no trigger):
> + Unused, ignored
> + if cell 1 is 1 (internal channel event):
> + channel number whose TR event should trigger the current channel.
> + if cell 1 is 2 or 3 (external signal or timer manager event):
> + index of global interfaces that come into the DMA.
> +
> + Please refer to the device documentation for global interface indexes.
> +
> + cell 3: Channel number for the peripheral
> +
> + Please refer to the device documentation for the channel map.
> +
> + cell 4: ASEL value for the channel
> +
> + interrupts:
> + minItems: 1
> + maxItems: 144
> + description:
> + Interrupts for DMA channels.
And interrupts are flexible because?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v7 1/3] ARM: omap1: drop unused variable from omap16xx_gpio_init()
From: Bartosz Golaszewski @ 2026-04-30 7:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
In-Reply-To: <20260430-nokia770-gpio-swnodes-v7-0-c88f74c90dd6@oss.qualcomm.com>
The pdata variable is set but not used. Remove it.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-omap1/gpio16xx.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 55acec22fef4e73f20935473602ef6cb2f4f379c..e8dbe173bd33fae72c7c884f930a530f78096839 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -212,7 +212,6 @@ static int __init omap16xx_gpio_init(void)
void __iomem *base;
struct resource *res;
struct platform_device *pdev;
- struct omap_gpio_platform_data *pdata;
if (!cpu_is_omap16xx())
return -EINVAL;
@@ -226,7 +225,6 @@ static int __init omap16xx_gpio_init(void)
for (i = 0; i < ARRAY_SIZE(omap16xx_gpio_dev); i++) {
pdev = omap16xx_gpio_dev[i];
- pdata = pdev->dev.platform_data;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (unlikely(!res)) {
--
2.47.3
^ permalink raw reply related
* [PATCH v7 0/3] ARM: omap1: use real firmware node lookup for GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-04-30 7:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
This converts Nokia 770 to using real firmware node lookup for GPIOs by
attaching the software nodes describing GPIO controllers to their target
devices.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v7:
- Drop ADS7846_PENDOWN_GPIO define from patch 3/3, move the value to the
property entry
- Convert the second dev_err() to pr_err()
- Add the device name.id in the pr_err() output
- Collect tags
- Link to v6: https://patch.msgid.link/20260427-nokia770-gpio-swnodes-v6-0-b693296c1985@oss.qualcomm.com
Changes in v6:
- Switch to using platform_device_register_full() and pass the software
node via the swnode field of struct platform_device_info
- Drop driver-core prerequisites from the series
- Rebase on top of v7.1-rc1
- Add patch dropping an unused variable
- Link to v5: https://patch.msgid.link/20260402-nokia770-gpio-swnodes-v5-0-d730db3dd299@oss.qualcomm.com
Changes in v5:
- Put ksysfs_init() in a separate new header
- Remove software_node_exit() in a separate patch
- Link to v4: https://patch.msgid.link/20260330-nokia770-gpio-swnodes-v4-0-b68592e977d0@oss.qualcomm.com
Changes in v4:
- Add patches making software nodes available earlier
- Remove stray newline
- Link to v3: https://lore.kernel.org/all/20260212112508.73500-1-bartosz.golaszewski@oss.qualcomm.com/
Changes in v3:
- fix references to the MPU node
Changes in v2:
- fix build with CONFIG_I2C_CBUS_GPIO
- only export the two symbols that are actually required by the nokia
board file
---
Bartosz Golaszewski (3):
ARM: omap1: drop unused variable from omap16xx_gpio_init()
ARM: omap1: use platform_device_register_full() for GPIO devices on OMAP 16xx
ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
arch/arm/mach-omap1/board-nokia770.c | 33 +++------------
arch/arm/mach-omap1/common.h | 3 ++
arch/arm/mach-omap1/gpio16xx.c | 80 ++++++++++++++++++------------------
3 files changed, 48 insertions(+), 68 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260330-nokia770-gpio-swnodes-5da8ba35946e
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v7 3/3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Bartosz Golaszewski @ 2026-04-30 7:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
In-Reply-To: <20260430-nokia770-gpio-swnodes-v7-0-c88f74c90dd6@oss.qualcomm.com>
Currently the board file for Nokia 770 creates dummy software nodes not
attached in any way to the actual GPIO controller devices and uses the
fact that GPIOLIB matching swnode's name to the GPIO chip's label during
software node lookup. This behavior is wrong and we want to remove it.
To that end, we need to first convert all existing users to creating
actual fwnode links.
Create real software nodes for GPIO controllers on OMAP16xx and
reference them from the software nodes in the nokia board file.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Janusz Krzysztofik <jmkrzyszt@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-omap1/board-nokia770.c | 33 +++++----------------------------
arch/arm/mach-omap1/common.h | 3 +++
arch/arm/mach-omap1/gpio16xx.c | 7 +++++++
3 files changed, 15 insertions(+), 28 deletions(-)
diff --git a/arch/arm/mach-omap1/board-nokia770.c b/arch/arm/mach-omap1/board-nokia770.c
index a5bf5554800fe17b430e84ae421ffa8da2bb11a0..72d9e92a1071743cef0020fce750288382fcb0a0 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -36,27 +36,6 @@
#include "clock.h"
#include "mmc.h"
-static const struct software_node nokia770_mpuio_gpiochip_node = {
- .name = "mpuio",
-};
-
-static const struct software_node nokia770_gpiochip1_node = {
- .name = "gpio-0-15",
-};
-
-static const struct software_node nokia770_gpiochip2_node = {
- .name = "gpio-16-31",
-};
-
-static const struct software_node *nokia770_gpiochip_nodes[] = {
- &nokia770_mpuio_gpiochip_node,
- &nokia770_gpiochip1_node,
- &nokia770_gpiochip2_node,
- NULL
-};
-
-#define ADS7846_PENDOWN_GPIO 15
-
static const unsigned int nokia770_keymap[] = {
KEY(1, 0, GROUP_0 | KEY_UP),
KEY(2, 0, GROUP_1 | KEY_F5),
@@ -112,7 +91,7 @@ static const struct omap_lcd_config nokia770_lcd_config __initconst = {
};
static const struct property_entry nokia770_mipid_props[] = {
- PROPERTY_ENTRY_GPIO("reset-gpios", &nokia770_gpiochip1_node,
+ PROPERTY_ENTRY_GPIO("reset-gpios", &omap16xx_gpio1_swnode,
13, GPIO_ACTIVE_LOW),
{ }
};
@@ -138,8 +117,7 @@ static const struct property_entry nokia770_ads7846_props[] = {
PROPERTY_ENTRY_U16("ti,x-plate-ohms", 180),
PROPERTY_ENTRY_U16("ti,debounce-tol", 3),
PROPERTY_ENTRY_U16("ti,debounce-rep", 1),
- PROPERTY_ENTRY_GPIO("pendown-gpios", &nokia770_gpiochip1_node,
- ADS7846_PENDOWN_GPIO, GPIO_ACTIVE_LOW),
+ PROPERTY_ENTRY_GPIO("pendown-gpios", &omap16xx_gpio1_swnode, 15, GPIO_ACTIVE_LOW),
{ }
};
@@ -225,9 +203,9 @@ static inline void nokia770_mmc_init(void)
#if IS_ENABLED(CONFIG_I2C_CBUS_GPIO)
static const struct software_node_ref_args nokia770_cbus_gpio_refs[] = {
- SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 9, 0),
- SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 10, 0),
- SOFTWARE_NODE_REFERENCE(&nokia770_mpuio_gpiochip_node, 11, 0),
+ SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 9, 0),
+ SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 10, 0),
+ SOFTWARE_NODE_REFERENCE(&omap16xx_mpu_gpio_swnode, 11, 0),
};
static const struct property_entry nokia770_cbus_props[] = {
@@ -318,7 +296,6 @@ static void __init omap_nokia770_init(void)
/* Unmask SleepX signal */
omap_writew((omap_readw(0xfffb5004) & ~2), 0xfffb5004);
- software_node_register_node_group(nokia770_gpiochip_nodes);
platform_add_devices(nokia770_devices, ARRAY_SIZE(nokia770_devices));
gpiod_add_lookup_table(&nokia770_irq_gpio_table);
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index 7a7c3d9eb84a06c18fbc70e7c94a161b487cd002..c0f6e231fdb4422c5d2c1aa3e33dd6dd99d2710e 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -35,6 +35,9 @@
#include "soc.h"
#include "i2c.h"
+extern const struct software_node omap16xx_mpu_gpio_swnode;
+extern const struct software_node omap16xx_gpio1_swnode;
+
#ifdef CONFIG_OMAP_SERIAL_WAKE
int omap_serial_wakeup_init(void);
#else
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index 9cca29f860544ddbec3734cec9b3246ce468543c..0f97972fd248d29fcfc1ed2a8ddb76a6d89f1e7f 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -9,6 +9,7 @@
*/
#include <linux/platform_data/gpio-omap.h>
+#include <linux/property.h>
#include <linux/soc/ti/omap1-io.h>
#include "hardware.h"
@@ -55,6 +56,8 @@ static struct omap_gpio_platform_data omap16xx_mpu_gpio_config = {
.regs = &omap16xx_mpuio_regs,
};
+const struct software_node omap16xx_mpu_gpio_swnode = { };
+
static const struct platform_device_info omap16xx_mpu_gpio = {
.name = "omap_gpio",
.id = 0,
@@ -62,6 +65,7 @@ static const struct platform_device_info omap16xx_mpu_gpio = {
.size_data = sizeof(omap16xx_mpu_gpio_config),
.num_res = ARRAY_SIZE(omap16xx_mpu_gpio_resources),
.res = omap16xx_mpu_gpio_resources,
+ .swnode = &omap16xx_mpu_gpio_swnode,
};
/* gpio1 */
@@ -98,6 +102,8 @@ static struct omap_gpio_platform_data omap16xx_gpio1_config = {
.regs = &omap16xx_gpio_regs,
};
+const struct software_node omap16xx_gpio1_swnode = { };
+
static const struct platform_device_info omap16xx_gpio1 = {
.name = "omap_gpio",
.id = 1,
@@ -105,6 +111,7 @@ static const struct platform_device_info omap16xx_gpio1 = {
.size_data = sizeof(omap16xx_gpio1_config),
.num_res = ARRAY_SIZE(omap16xx_gpio1_resources),
.res = omap16xx_gpio1_resources,
+ .swnode = &omap16xx_gpio1_swnode,
};
/* gpio2 */
--
2.47.3
^ permalink raw reply related
* [PATCH v7 2/3] ARM: omap1: use platform_device_register_full() for GPIO devices on OMAP 16xx
From: Bartosz Golaszewski @ 2026-04-30 7:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Aaro Koskinen, Janusz Krzysztofik, Tony Lindgren, Russell King,
Dmitry Torokhov, Kevin Hilman, Arnd Bergmann
Cc: brgl, driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
linux-omap, Bartosz Golaszewski
In-Reply-To: <20260430-nokia770-gpio-swnodes-v7-0-c88f74c90dd6@oss.qualcomm.com>
Ahead of changes attaching GPIO controller's software nodes referenced
from the Nokia 770 board files to their target devices, switch the
method for registering the platform devices to the
platform_device_register_full() variant. This is done to leverage the
new swnode field of struct platform_device_info which automate the
software node's registration and assignment.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-omap1/gpio16xx.c | 71 ++++++++++++++++++++----------------------
1 file changed, 33 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c
index e8dbe173bd33fae72c7c884f930a530f78096839..9cca29f860544ddbec3734cec9b3246ce468543c 100644
--- a/arch/arm/mach-omap1/gpio16xx.c
+++ b/arch/arm/mach-omap1/gpio16xx.c
@@ -55,14 +55,13 @@ static struct omap_gpio_platform_data omap16xx_mpu_gpio_config = {
.regs = &omap16xx_mpuio_regs,
};
-static struct platform_device omap16xx_mpu_gpio = {
+static const struct platform_device_info omap16xx_mpu_gpio = {
.name = "omap_gpio",
.id = 0,
- .dev = {
- .platform_data = &omap16xx_mpu_gpio_config,
- },
- .num_resources = ARRAY_SIZE(omap16xx_mpu_gpio_resources),
- .resource = omap16xx_mpu_gpio_resources,
+ .data = &omap16xx_mpu_gpio_config,
+ .size_data = sizeof(omap16xx_mpu_gpio_config),
+ .num_res = ARRAY_SIZE(omap16xx_mpu_gpio_resources),
+ .res = omap16xx_mpu_gpio_resources,
};
/* gpio1 */
@@ -99,14 +98,13 @@ static struct omap_gpio_platform_data omap16xx_gpio1_config = {
.regs = &omap16xx_gpio_regs,
};
-static struct platform_device omap16xx_gpio1 = {
+static const struct platform_device_info omap16xx_gpio1 = {
.name = "omap_gpio",
.id = 1,
- .dev = {
- .platform_data = &omap16xx_gpio1_config,
- },
- .num_resources = ARRAY_SIZE(omap16xx_gpio1_resources),
- .resource = omap16xx_gpio1_resources,
+ .data = &omap16xx_gpio1_config,
+ .size_data = sizeof(omap16xx_gpio1_config),
+ .num_res = ARRAY_SIZE(omap16xx_gpio1_resources),
+ .res = omap16xx_gpio1_resources,
};
/* gpio2 */
@@ -127,14 +125,13 @@ static struct omap_gpio_platform_data omap16xx_gpio2_config = {
.regs = &omap16xx_gpio_regs,
};
-static struct platform_device omap16xx_gpio2 = {
+static const struct platform_device_info omap16xx_gpio2 = {
.name = "omap_gpio",
.id = 2,
- .dev = {
- .platform_data = &omap16xx_gpio2_config,
- },
- .num_resources = ARRAY_SIZE(omap16xx_gpio2_resources),
- .resource = omap16xx_gpio2_resources,
+ .data = &omap16xx_gpio2_config,
+ .size_data = sizeof(omap16xx_gpio2_config),
+ .num_res = ARRAY_SIZE(omap16xx_gpio2_resources),
+ .res = omap16xx_gpio2_resources,
};
/* gpio3 */
@@ -155,14 +152,13 @@ static struct omap_gpio_platform_data omap16xx_gpio3_config = {
.regs = &omap16xx_gpio_regs,
};
-static struct platform_device omap16xx_gpio3 = {
+static const struct platform_device_info omap16xx_gpio3 = {
.name = "omap_gpio",
.id = 3,
- .dev = {
- .platform_data = &omap16xx_gpio3_config,
- },
- .num_resources = ARRAY_SIZE(omap16xx_gpio3_resources),
- .resource = omap16xx_gpio3_resources,
+ .data = &omap16xx_gpio3_config,
+ .size_data = sizeof(omap16xx_gpio3_config),
+ .num_res = ARRAY_SIZE(omap16xx_gpio3_resources),
+ .res = omap16xx_gpio3_resources,
};
/* gpio4 */
@@ -183,17 +179,16 @@ static struct omap_gpio_platform_data omap16xx_gpio4_config = {
.regs = &omap16xx_gpio_regs,
};
-static struct platform_device omap16xx_gpio4 = {
+static const struct platform_device_info omap16xx_gpio4 = {
.name = "omap_gpio",
.id = 4,
- .dev = {
- .platform_data = &omap16xx_gpio4_config,
- },
- .num_resources = ARRAY_SIZE(omap16xx_gpio4_resources),
- .resource = omap16xx_gpio4_resources,
+ .data = &omap16xx_gpio4_config,
+ .size_data = sizeof(omap16xx_gpio4_config),
+ .num_res = ARRAY_SIZE(omap16xx_gpio4_resources),
+ .res = omap16xx_gpio4_resources,
};
-static struct platform_device *omap16xx_gpio_dev[] __initdata = {
+static const struct platform_device_info *omap16xx_gpio_dev[] __initconst = {
&omap16xx_mpu_gpio,
&omap16xx_gpio1,
&omap16xx_gpio2,
@@ -210,8 +205,8 @@ static int __init omap16xx_gpio_init(void)
{
int i;
void __iomem *base;
- struct resource *res;
- struct platform_device *pdev;
+ const struct resource *res;
+ const struct platform_device_info *pdevinfo;
if (!cpu_is_omap16xx())
return -EINVAL;
@@ -224,24 +219,24 @@ static int __init omap16xx_gpio_init(void)
ULPD_CAM_CLK_CTRL);
for (i = 0; i < ARRAY_SIZE(omap16xx_gpio_dev); i++) {
- pdev = omap16xx_gpio_dev[i];
+ pdevinfo = omap16xx_gpio_dev[i];
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res = &pdevinfo->res[0];
if (unlikely(!res)) {
- dev_err(&pdev->dev, "Invalid mem resource.\n");
+ pr_err("%s.%d: Invalid mem resource.\n", pdevinfo->name, pdevinfo->id);
return -ENODEV;
}
base = ioremap(res->start, resource_size(res));
if (unlikely(!base)) {
- dev_err(&pdev->dev, "ioremap failed.\n");
+ pr_err("%s.%d: ioremap failed.\n", pdevinfo->name, pdevinfo->id);
return -ENOMEM;
}
__raw_writel(SYSCONFIG_WORD, base + OMAP1610_GPIO_SYSCONFIG);
iounmap(base);
- platform_device_register(omap16xx_gpio_dev[i]);
+ platform_device_register_full(omap16xx_gpio_dev[i]);
}
return 0;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Robby Cai @ 2026-04-30 7:34 UTC (permalink / raw)
To: Sebastian Krzyszkowiak
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <5956186.LvFx2qVVIh@pliszka>
On Sat, Apr 18, 2026 at 03:12:24AM +0200, Sebastian Krzyszkowiak wrote:
> On piątek, 17 kwietnia 2026 13:01:59 czas środkowoeuropejski letni Robby Cai
> wrote:
> > CSI capture may intermittently fail due to mismatched clock rates. The
> > previous configuration violated the timing requirement stated in the
> > i.MX8MQ Reference Manual:
> >
> > "The frequency of clk must be exactly equal to or greater than the RX
> > byte clock coming from the RX DPHY."
> >
> > Update the clock configuration to ensure that the CSI core clock rate is
> > equal to or greater than the incoming DPHY byte clock. The updated clock
> > ratios are consistent with those used in NXP's downstream BSP.
>
> I believe this is a misreading of the docs.
>
> IMX8MQ_CLK_CSIX_PHY_REF refers to the UI pixel clock (clk_ui), not the RX DPHY
> byte clock. All this change would do is to break streaming with more than 100
> Mpixels per second / 1064 Mbps per MIPI lane.
>
> As mentioned in the reference manual:
>
> "The frequency of clk_ui must be such that the data received on the data_out
> output is greater than or equal to the total bandwidth of the physical MIPI
> interface. Clk_ui has no relationship requirement with regards to ‘clk’ other
> than the bandwidth requirement mentioned previously."
>
You are right — thank you for the detailed clarification.
Given this, the commit message and the rationale behind this change are
incorrect, and the current patch could indeed break higher-bandwidth streaming
use cases. Thank you for catching this.
I will revisit the clock assumptions and drop or rework this change based
strictly on the documented bandwidth requirements in the next revision.
Regards,
Robby
[...]
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Arnaud POULIQUEN @ 2026-04-30 7:35 UTC (permalink / raw)
To: Mathieu Poirier, Padhi, Beleswar
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <CANLsYkzt9xUczxSU28u-TfZAAjr0ufZKXAj8Eqfq=45gufXW3w@mail.gmail.com>
Hello,
On 4/29/26 21:20, Mathieu Poirier wrote:
> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>
>> Hi Mathieu,
>>
>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>> <brgl@bgdev.pl>
>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>> GPIO driver
>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>> __u8 status;
>>>>>>>>> __u8 value;
>>>>>>>>> };
>>>>>>>> It is the same message format. Please see the message definition
>>>>>>> (GET_DIRECTION) below:
>>>>>>>
>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>
>>>>>> Some changes to the message format are necessary.
>>>>>>
>>>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>>>> replies, and a second one for events.
>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>> type field is required to distinguish between different kinds of messages.
>>>>>>
>>>>>> Since rpmsg replies and events share the same message format, an additional
>>>>> line is introduced to handle both cases.
>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>>>> uniquely identify the target controller.
>>>>>
>>>>> I have commented on this before - RPMSG is already providing multiplexing
>>>>> capability by way of endpoints. There is no need for a port field. One endpoint,
>>>>> one GPIO controller.
>>>>>
>>>> You still need a way to let the remote side know which port the endpoint maps to, either
>>>> by embedding the port information in the message (the current way), or by sending it
>>>> separately.
>>>>
>>> An endpoint is created with every namespace request. There should be
>>> one namespace request for every GPIO controller, which yields a unique
>>> endpoint for each controller and eliminates the need for an extra
>>> field to identify them.
>>
>>
>> Right, but this can still be done by just having one namespace request.
>> We can create new endpoints bound to an existing namespace/channel by
>> invoking rpmsg_create_ept(). This is what I suggested here too:
>> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>>
>
> I will look at your suggestion (i.e link above) later this week or next week.
>
>> My mental model looks like this for the complete picture:
>>
>> 1. namespace/channel#1 = rpmsg-io
>> a. ept1 -> gpio-controller@1
>> b. ept2 -> gpio-controller@2
>>
>
> I've asked for one endpoint per GPIO controller since the very
> beginning. I don't yet have a strong opinion on whether to use one
> namespace request per GPIO controller or a single request that spins
> off multiple endpoints. I'll have to look at your link and reflect on
> that. Regardless of how we proceed on that front, multiplexing needs
> to happen at the endpoint level rather than the packet level. This is
> the only way this work can move forward.
>
I would be more in favor of Mathieu’s proposal: “An endpoint is created
with every namespace request.”
If the endpoint is created only on the Linux side, how do we match the
Linux endpoint address with the local port field on the remote side?
With a multi-namespace approach, the namespace could be rpmsg-io-[addr],
where [addr] corresponds to the GPIO controller address in the DT. This
would:
- match the RPMsg probe with the DT,
- provide a simple mapping between the port and the endpoint on both sides,
- allow multiple endpoints on the remote side,
- provide a simple discovery mechanism for remote capabilities.
Regards,
Arnaud
>> 2. namespace/channel#2 = rpmsg-i2c
>> a. ept1 -> i2c@1
>> b. ept2 -> i2c@2
>> c. ept3 -> i2c@3
>>
>> etc...
>>
>> This way device groups are isolated with each channel/namespace, and
>> instances within each device groups are also respected with specific
>> endpoints.
>>
>> Thanks,
>> Beleswar
>>
>
^ permalink raw reply
* Re: [PATCH] arm64/mm: Rename ptdesc_t
From: Mike Rapoport @ 2026-04-30 7:51 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, David Hildenbrand,
linux-efi, linux-kernel
In-Reply-To: <20260430034933.541634-1-anshuman.khandual@arm.com>
Hi Anshuman,
On Thu, Apr 30, 2026 at 04:49:33AM +0100, Anshuman Khandual wrote:
> ptdesc_t sounds very similar to the core MM struct ptdesc which is actually
> the memory descriptor for page table allocations. Hence rename this typedef
> element as pxxval_t instead for better clarity and separation.
Maybe we should keep the "pt" prefix and make it "ptval_t"?
No really strong feelings, so
Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Mike Rapoport <rppt@kernel.org>
> Cc: linux-efi@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
> This patch applies on v7.1-rc1
>
> Took the liberty in including David's tag from an internal discussion.
>
> arch/arm64/include/asm/io.h | 2 +-
> arch/arm64/include/asm/pgtable-types.h | 14 +++++++-------
> arch/arm64/include/asm/ptdump.h | 8 ++++----
> arch/arm64/include/asm/tlbflush.h | 4 ++--
> arch/arm64/kernel/efi.c | 4 ++--
> arch/arm64/kernel/pi/map_kernel.c | 2 +-
> arch/arm64/kernel/pi/map_range.c | 4 ++--
> arch/arm64/kernel/pi/pi.h | 2 +-
> arch/arm64/mm/mmap.c | 4 ++--
> arch/arm64/mm/pageattr.c | 2 +-
> arch/arm64/mm/ptdump.c | 2 +-
> 11 files changed, 24 insertions(+), 24 deletions(-)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Robby Cai @ 2026-04-30 7:58 UTC (permalink / raw)
To: Frank Li
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam, shawnguo,
martin.kepplinger, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <aeIX-YbSwhmuJwst@lizhi-Precision-Tower-5810>
On Fri, Apr 17, 2026 at 07:22:33AM -0400, Frank Li wrote:
> On Fri, Apr 17, 2026 at 07:01:59PM +0800, Robby Cai wrote:
> > CSI capture may intermittently fail due to mismatched clock rates. The
> > previous configuration violated the timing requirement stated in the
> > i.MX8MQ Reference Manual:
> >
> > "The frequency of clk must be exactly equal to or greater than the RX
> > byte clock coming from the RX DPHY."
> >
> > Update the clock configuration to ensure that the CSI core clock rate is
> > equal to or greater than the incoming DPHY byte clock.
>
> You reduce clock, how to make sure it >= ?
This is a mistake in the commit message. IMX8MQ_CLK_CSIX_PHY_REF refers to the
UI clock (clk_ui), not the RX DPHY byte clock. There is no direct >= relationship
with the CSI core clock other than the documented bandwidth requirement.
>
> > The updated clock
> > ratios are consistent with those used in NXP's downstream BSP.
>
> "downstream BSP" is not solidate reference for clock rate, it'd better
> refer to date sheet, dose datasheet require such frequecy
>
> Frank
I will revisit the clock assumptions in the next revision.
Regards,
Robby
> >
> > Fixes: bcadd5f66c2a ("arm64: dts: imx8mq: add mipi csi phy and csi bridge descriptions")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Robby Cai <robby.cai@nxp.com>
> > ---
[...]
^ permalink raw reply
* Re: [PATCH] arch: arm64: fix KERNEL_SEGMENT_COUNT error
From: Ard Biesheuvel @ 2026-04-30 7:59 UTC (permalink / raw)
To: Zhaoyang Huang
Cc: zhaoyang.huang, Catalin Marinas, Will Deacon, linux-arm-kernel,
linux-kernel, steve.kang
In-Reply-To: <CAGWkznHXAyr05NrwD3TqY_jMO6_AieE8KUZRpqF++icrbB=HEA@mail.gmail.com>
On Thu, 30 Apr 2026, at 03:56, Zhaoyang Huang wrote:
> On Thu, Apr 30, 2026 at 9:29 AM Zhaoyang Huang <huangzhaoyang@gmail.com> wrote:
>>
>> On Wed, Apr 29, 2026 at 5:28 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>> >
>> > Hello Zhaoyang,
>> >
>> > On Wed, 29 Apr 2026, at 08:17, zhaoyang.huang wrote:
>> > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>> > >
>> > > During debug of a kernel panic, we find that the pte_t of the final
>> > > part of [data, end] segment got overflow to the next page of
>> > > init_pg_end[1] which is the gap page before early_init_stack[2].
>> > > This should be introduced by the KERNEL_SEGMENT_COUNT's value is 5
>> > > which should be 6 as map_segment are called 6 times for the segments
>> > > of (text, stext, rodata, inittext, initdata, data+bss)
>> > >
>> > > [1]
>> > > crash_arm64_v9.0.1> vtop ffffffed00601000
>> > > VIRTUAL PHYSICAL
>> > > ffffffed00601000 83401000
>> > >
>> > > PAGE DIRECTORY: ffffffecffd62000
>> > > PGD: ffffffecffd62da0 => 10000000833fb003
>> > > PMD: ffffff80033fb018 => 10000000833fe003
>> > > PTE: ffffff80033fe008 => 68000083401f03
>> > > PAGE: 83401000
>> > >
>> > > PTE PHYSICAL FLAGS
>> > > 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)
>> > >
>> > > PAGE PHYSICAL MAPPING INDEX CNT FLAGS
>> > > fffffffec00d0040 83401000 0 0 1 4000 reserved
>> > >
>> > > [2]
>> > > ffffffed002c8000 (r) __pi__data
>> > > ffffffed0054e000 (d) __pi___bss_start
>> > > ffffffed005f5000 (b) __pi_init_pg_dir
>> > > ffffffed005fe000 (b) __pi_init_pg_end
>> > > ffffffed005ff000 (B) early_init_stack
>> > > ffffffed00608000 (b) __pi__end
>> > >
>> > > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
>> > > ---
>> > > arch/arm64/include/asm/kernel-pgtable.h | 4 ++--
>> > > 1 file changed, 2 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/arch/arm64/include/asm/kernel-pgtable.h
>> > > b/arch/arm64/include/asm/kernel-pgtable.h
>> > > index 74a4f738c5f5..14dd1c52552a 100644
>> > > --- a/arch/arm64/include/asm/kernel-pgtable.h
>> > > +++ b/arch/arm64/include/asm/kernel-pgtable.h
>> > > @@ -64,8 +64,8 @@
>> > > #define INIT_IDMAP_FDT_PAGES (EARLY_PAGES(INIT_IDMAP_PGTABLE_LEVELS,
>> > > 0UL, UL(MAX_FDT_SIZE), 1) - 1)
>> > > #define INIT_IDMAP_FDT_SIZE ((INIT_IDMAP_FDT_PAGES +
>> > > EARLY_IDMAP_EXTRA_FDT_PAGES) * PAGE_SIZE)
>> > >
>> > > -/* The number of segments in the kernel image (text, rodata, inittext,
>> > > initdata, data+bss) */
>> > > -#define KERNEL_SEGMENT_COUNT 5
>> > > +/* The number of segments in the kernel image (text, stext, rodata,
>> > > inittext, initdata, data+bss) */
>> > > +#define KERNEL_SEGMENT_COUNT 6
>> > >
>> > > #if SWAPPER_BLOCK_SIZE > SEGMENT_ALIGN
>> > > #define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 1)
>> >
>> > I think the better fix would be
>> >
>> > --- a/arch/arm64/include/asm/kernel-pgtable.h
>> > +++ b/arch/arm64/include/asm/kernel-pgtable.h
>> > @@ -68,7 +68,7 @@
>> > #define KERNEL_SEGMENT_COUNT 5
>> >
>> > #if SWAPPER_BLOCK_SIZE > SEGMENT_ALIGN
>> > -#define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 1)
>> > +#define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 2)
>> Thanks for the comment. This makes sense since KERNEL_SEGMENT_COUNT is
>> also used for defining vmlinux_seg[] in declare_kernel_vmas.
> Is the following fix more reasonable, since it makes both map_segment
> and declare_kernel_vmas compatible with the value 6?
>
No, please fix this as I suggested.
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme interrupts
From: Krzysztof Kozlowski @ 2026-04-30 8:04 UTC (permalink / raw)
To: Richard Zhu
Cc: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam, linux-pci,
linux-arm-kernel, devicetree, imx, linux-kernel
In-Reply-To: <20260430050954.3467984-2-hongxing.zhu@nxp.com>
On Thu, Apr 30, 2026 at 01:09:52PM +0800, Richard Zhu wrote:
> Add 'intr', 'aer', and 'pme' interrupt entries to the i.MX6Q PCIe binding
> to support PCIe event-based interrupts for general controller events,
> Advanced Error Reporting, and Power Management Events respectively.
>
> These interrupts are optional for existing variants (imx6q, imx6sx, imx6qp,
> imx7d, imx8mq, imx8mm, imx8mp) to maintain backward compatibility with
> existing device trees.
>
> For fsl,imx95-pcie, all 5 interrupts (msi, dma, intr, aer, pme) are
> mandatory due to hardware requirements.
>
> This introduces an ABI requirement for fsl,imx95-pcie. The i.MX95 hardware
> requires dedicated interrupt lines for AER, PME, and general controller
> events due to its redesigned interrupt architecture. i.MX95 cannot
> function correctly without explicit interrupt routing for error handling,
> power management and link event detection.
fsl,imx95-pcie was added more than two years ago, so how it cannot
function correctly? Are you saying that for two years you had here
completely broken code?
If this wasn't tested for two years, how can we believe anything is
tested now?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: imx95: Add dma, intr, aer and pme interrupters for pcie{0,1}
From: Krzysztof Kozlowski @ 2026-04-30 8:04 UTC (permalink / raw)
To: Richard Zhu
Cc: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam, linux-pci,
linux-arm-kernel, devicetree, imx, linux-kernel
In-Reply-To: <20260430050954.3467984-3-hongxing.zhu@nxp.com>
On Thu, Apr 30, 2026 at 01:09:53PM +0800, Richard Zhu wrote:
> Add dma, intr, aer and pme interrupters for pcie{0,1}.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx95.dtsi | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
> index 71394871d8dd0..6896d9c15bf53 100644
> --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
> @@ -1861,8 +1861,12 @@ pcie0: pcie@4c300000 {
> bus-range = <0x00 0xff>;
> num-lanes = <1>;
> num-viewport = <8>;
> - interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
> - interrupt-names = "msi";
Why there is no fixes tag if this is here for two years and you claim
that IT CANNOT work without these interrupts?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] drm/ipv3: add CONFIG_OF dependency for DRM_OF_DISPLAY_MODE_BRIDGE
From: Damon Ding @ 2026-04-30 8:07 UTC (permalink / raw)
To: Luca Ceresoli, Arnd Bergmann, Philipp Zabel, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer
Cc: Arnd Bergmann, Pengutronix Kernel Team, Fabio Estevam, dri-devel,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <DI6B0UNV68LI.3PYKFFB0F1DH6@bootlin.com>
On 4/30/2026 3:17 PM, Luca Ceresoli wrote:
> On Wed Apr 29, 2026 at 4:00 PM CEST, Arnd Bergmann wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> Without this, not all dependencies are met here.
>>
>> Depends on [n]: HAS_IOMEM [=y] && DRM [=y] && DRM_BRIDGE [=y] && OF [=n]
>> Selected by [y]:
>> - DRM_IMX_PARALLEL_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_IMX [=y]
>> - DRM_IMX_LDB [=y] && HAS_IOMEM [=y] && DRM [=y] && DRM_IMX [=y] && COMMON_CLK [=y]
>>
>> Fixes: ba2db93cf3d5 ("drm/bridge: Move legacy bridge driver out of imx directory for multi-platform use")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
>
Reviewed-by: Damon Ding <damon.ding@rock-chips.com>
Best regards,
Damon
^ permalink raw reply
* [PATCH v4 0/3] wireless: p54 devicetree conversion
From: Arnd Bergmann @ 2026-04-30 8:12 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, devicetree, linux-kernel, linux-arm-kernel,
linux-gpio, linux-omap
From: Arnd Bergmann <arnd@arndb.de>
This is an older patch of mine that I lost track of. We already decided
a while ago that the OMAP2 platform should probably be removed entirely,
and this is the only known user, but it's probably a good idea to still
get the driver changes in, in case there are other out-of-tree users.
We probably don't have to worry about bisectability any more though,
so the devicetree and driver changes can just get merged independently
through the OMAP and wireless trees, respectively.
Arnd
v3 Link: https://lore.kernel.org/all/20260427142355.2532714-1-arnd@kernel.org/
v2 Link: https://lore.kernel.org/all/20230404082401.1087835-1-arnd@kernel.org/
Cc: "Aaro Koskinen" <aaro.koskinen@iki.fi>
Cc: "Andreas Kemnade" <andreas@kemnade.info>
Cc: "Arnd Bergmann" <arnd@arndb.de>
Cc: "Bartosz Golaszewski" <brgl@kernel.org>
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
Cc: "Eric Dumazet" <edumazet@google.com>
Cc: "Felipe Balbi" <balbi@kernel.org>
Cc: "Jakub Kicinski" <kuba@kernel.org>
Cc: "Johannes Berg" <johannes@sipsolutions.net>
Cc: "Kevin Hilman" <khilman@baylibre.com>
Cc: "Krzysztof Kozlowski" <krzk+dt@kernel.org>
Cc: "Linus Walleij" <linusw@kernel.org>
Cc: "Paolo Abeni" <pabeni@redhat.com>
Cc: "Rob Herring" <robh+dt@kernel.org>
Cc: "Roger Quadros" <rogerq@kernel.org>
Cc: "Tony Lindgren" <tony@atomide.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-gpio@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Arnd Bergmann (3):
[net-next][v4] dt-bindings: net: add st,stlc4560/p54spi binding
[net-next][v4] p54spi: convert to devicetree
[omap][v4] ARM: dts: omap2: add stlc4560 spi-wireless node
.../bindings/net/wireless/st,stlc4560.yaml | 61 +++++++++++++++++
MAINTAINERS | 1 +
arch/arm/boot/dts/ti/omap/omap2.dtsi | 4 ++
.../dts/ti/omap/omap2420-n8x0-common.dtsi | 12 ++++
arch/arm/mach-omap2/board-n8x0.c | 18 -----
drivers/net/wireless/intersil/p54/p54spi.c | 66 +++++++------------
drivers/net/wireless/intersil/p54/p54spi.h | 3 +
7 files changed, 103 insertions(+), 62 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
--
2.39.5
^ permalink raw reply
* [PATCH v4 1/3 net-next] dt-bindings: net: add st,stlc4560/p54spi binding
From: Arnd Bergmann @ 2026-04-30 8:12 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, devicetree, linux-kernel, linux-arm-kernel,
linux-gpio, linux-omap, Christian Lamparter
In-Reply-To: <20260430081242.3686993-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
The SPI version of Prism54 was sold under a couple of different
names and supported by the Linux p54spi driver, but there was
never a DT binding for it.
Document the four known names of this device and the properties
that are sufficient for its use on the Nokia N8x0 tablet.
As I don't have this hardware or documentation for it, this is
purely based on existing usage in the driver.
Link: https://lore.kernel.org/all/e8dc9acb-6f85-e0a9-a145-d101ca6da201@gmail.com/
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v4: renamed file to st,stlc4560, matching the primary compatible string
require st,stlc4560 string
---
.../bindings/net/wireless/st,stlc4560.yaml | 61 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
diff --git a/Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml b/Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
new file mode 100644
index 000000000000..979c8d7d859a
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/wireless/st,stlc45xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ST/Intersil/Conexant stlc45xx/p54spi/cx3110x SPI wireless device
+
+maintainers:
+ - Christian Lamparter <chunkeey@gmail.com>
+
+description:
+ The SPI variant of the Intersil Prism54 wireless device was sold
+ under a variety of names, including Conexant CX3110x and
+ ST Microelectronics STLC5460.
+
+allOf:
+ - $ref: ieee80211.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+ oneOf:
+ - const: st,stlc4560
+ - items:
+ - enum:
+ - cnxt,3110x
+ - isil,p54spi
+ - st,stlc4550
+ - const: st,stlc4560
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ powerdown-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wifi@0 {
+ compatible = "st,stlc4560";
+ reg = <0>;
+ spi-max-frequency = <48000000>;
+ interrupts-extended = <&gpio 23>;
+ powerdown-gpios = <&gpio 1>;
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 86ca9297edab..67cf5ae5b652 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20093,6 +20093,7 @@ M: Christian Lamparter <chunkeey@googlemail.com>
L: linux-wireless@vger.kernel.org
S: Maintained
W: https://wireless.wiki.kernel.org/en/users/Drivers/p54
+F: Documentation/devicetree/bindings/net/wireless/st,stlc45xx.yaml
F: drivers/net/wireless/intersil/
PACKET SOCKETS
--
2.39.5
^ permalink raw reply related
* [PATCH v4 2/3 net-next] p54spi: convert to devicetree
From: Arnd Bergmann @ 2026-04-30 8:12 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, devicetree, linux-kernel, linux-arm-kernel,
linux-gpio, linux-omap, Christian Lamparter
In-Reply-To: <20260430081242.3686993-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
The Prism54 SPI driver hardcodes GPIO numbers and expects users to
pass them as module parameters, apparently a relic from its life as a
staging driver. This works because there is only one user, the Nokia
N8x0 tablet.
Convert this to the gpio descriptor interface and DT based probing
to improve this and simplify the code at the same time.
Acked-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v4:
- make gpio line optional again
- fix EPROBE_DEFER handling
- match only st,stlc4560 compatible value, with binding change
v3:
- rebase an older patch
---
arch/arm/mach-omap2/board-n8x0.c | 18 ------
drivers/net/wireless/intersil/p54/p54spi.c | 66 ++++++++--------------
drivers/net/wireless/intersil/p54/p54spi.h | 3 +
3 files changed, 25 insertions(+), 62 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index 969265d5d5c6..d9acd32c5457 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -20,7 +20,6 @@
#include <linux/spi/spi.h>
#include <linux/usb/musb.h>
#include <linux/mmc/host.h>
-#include <linux/platform_data/spi-omap2-mcspi.h>
#include <linux/platform_data/mmc-omap.h>
#include <linux/mfd/menelaus.h>
@@ -106,21 +105,6 @@ static void __init n8x0_usb_init(void) {}
#endif /*CONFIG_USB_MUSB_TUSB6010 */
-
-static struct omap2_mcspi_device_config p54spi_mcspi_config = {
- .turbo_mode = 0,
-};
-
-static struct spi_board_info n800_spi_board_info[] __initdata = {
- {
- .modalias = "p54spi",
- .bus_num = 2,
- .chip_select = 0,
- .max_speed_hz = 48000000,
- .controller_data = &p54spi_mcspi_config,
- },
-};
-
#if defined(CONFIG_MENELAUS) && IS_ENABLED(CONFIG_MMC_OMAP)
/*
@@ -524,7 +508,5 @@ omap_late_initcall(n8x0_late_initcall);
void * __init n8x0_legacy_init(void)
{
board_check_revision();
- spi_register_board_info(n800_spi_board_info,
- ARRAY_SIZE(n800_spi_board_info));
return &mmc1_data;
}
diff --git a/drivers/net/wireless/intersil/p54/p54spi.c b/drivers/net/wireless/intersil/p54/p54spi.c
index 9d66dcae54e0..806761580759 100644
--- a/drivers/net/wireless/intersil/p54/p54spi.c
+++ b/drivers/net/wireless/intersil/p54/p54spi.c
@@ -8,6 +8,7 @@
*/
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/platform_device.h>
#include <linux/interrupt.h>
#include <linux/firmware.h>
@@ -15,7 +16,7 @@
#include <linux/irq.h>
#include <linux/spi/spi.h>
#include <linux/etherdevice.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/slab.h>
#include "p54spi.h"
@@ -30,19 +31,6 @@
MODULE_FIRMWARE("3826.arm");
MODULE_FIRMWARE("3826.eeprom");
-/* gpios should be handled in board files and provided via platform data,
- * but because it's currently impossible for p54spi to have a header file
- * in include/linux, let's use module parameters for now
- */
-
-static int p54spi_gpio_power = 97;
-module_param(p54spi_gpio_power, int, 0444);
-MODULE_PARM_DESC(p54spi_gpio_power, "gpio number for power line");
-
-static int p54spi_gpio_irq = 87;
-module_param(p54spi_gpio_irq, int, 0444);
-MODULE_PARM_DESC(p54spi_gpio_irq, "gpio number for irq line");
-
static void p54spi_spi_read(struct p54s_priv *priv, u8 address,
void *buf, size_t len)
{
@@ -262,14 +250,14 @@ static int p54spi_upload_firmware(struct ieee80211_hw *dev)
static void p54spi_power_off(struct p54s_priv *priv)
{
- disable_irq(gpio_to_irq(p54spi_gpio_irq));
- gpio_set_value(p54spi_gpio_power, 0);
+ disable_irq(priv->irq);
+ gpiod_set_value(priv->gpio_powerdown, 1);
}
static void p54spi_power_on(struct p54s_priv *priv)
{
- gpio_set_value(p54spi_gpio_power, 1);
- enable_irq(gpio_to_irq(p54spi_gpio_irq));
+ gpiod_set_value(priv->gpio_powerdown, 0);
+ enable_irq(priv->irq);
/* need to wait a while before device can be accessed, the length
* is just a guess
@@ -608,31 +596,19 @@ static int p54spi_probe(struct spi_device *spi)
goto err_free;
}
- ret = gpio_request(p54spi_gpio_power, "p54spi power");
- if (ret < 0) {
- dev_err(&priv->spi->dev, "power GPIO request failed: %d", ret);
+ priv->gpio_powerdown = gpiod_get_optional(&spi->dev, "powerdown", GPIOD_OUT_HIGH);
+ if (IS_ERR(priv->gpio_powerdown)) {
+ ret = dev_err_probe(&priv->spi->dev, PTR_ERR(priv->gpio_powerdown),
+ "powerdown GPIO request failed\n");
goto err_free;
}
- ret = gpio_request(p54spi_gpio_irq, "p54spi irq");
- if (ret < 0) {
- dev_err(&priv->spi->dev, "irq GPIO request failed: %d", ret);
- goto err_free_gpio_power;
- }
-
- gpio_direction_output(p54spi_gpio_power, 0);
- gpio_direction_input(p54spi_gpio_irq);
-
- ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
- p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi",
- priv->spi);
+ ret = request_irq(spi->irq, p54spi_interrupt, IRQF_NO_AUTOEN, "p54spi", priv->spi);
if (ret < 0) {
dev_err(&priv->spi->dev, "request_irq() failed");
- goto err_free_gpio_irq;
+ goto err_free_gpio_power;
}
- irq_set_irq_type(gpio_to_irq(p54spi_gpio_irq), IRQ_TYPE_EDGE_RISING);
-
INIT_WORK(&priv->work, p54spi_work);
init_completion(&priv->fw_comp);
INIT_LIST_HEAD(&priv->tx_pending);
@@ -659,11 +635,9 @@ static int p54spi_probe(struct spi_device *spi)
err_free_common:
release_firmware(priv->firmware);
- free_irq(gpio_to_irq(p54spi_gpio_irq), spi);
-err_free_gpio_irq:
- gpio_free(p54spi_gpio_irq);
+ free_irq(priv->irq, spi);
err_free_gpio_power:
- gpio_free(p54spi_gpio_power);
+ gpiod_put(priv->gpio_powerdown);
err_free:
p54_free_common(priv->hw);
return ret;
@@ -675,10 +649,8 @@ static void p54spi_remove(struct spi_device *spi)
p54_unregister_common(priv->hw);
- free_irq(gpio_to_irq(p54spi_gpio_irq), spi);
-
- gpio_free(p54spi_gpio_power);
- gpio_free(p54spi_gpio_irq);
+ free_irq(priv->irq, spi);
+ gpiod_put(priv->gpio_powerdown);
release_firmware(priv->firmware);
mutex_destroy(&priv->mutex);
@@ -686,10 +658,16 @@ static void p54spi_remove(struct spi_device *spi)
p54_free_common(priv->hw);
}
+static const struct of_device_id p54spi_of_ids[] = {
+ { .compatible = "st,stlc4560", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, p54spi_of_ids);
static struct spi_driver p54spi_driver = {
.driver = {
.name = "p54spi",
+ .of_match_table = p54spi_of_ids,
},
.probe = p54spi_probe,
diff --git a/drivers/net/wireless/intersil/p54/p54spi.h b/drivers/net/wireless/intersil/p54/p54spi.h
index e5619a13fd61..118785cc635a 100644
--- a/drivers/net/wireless/intersil/p54/p54spi.h
+++ b/drivers/net/wireless/intersil/p54/p54spi.h
@@ -107,6 +107,9 @@ struct p54s_priv {
enum fw_state fw_state;
const struct firmware *firmware;
+
+ struct gpio_desc *gpio_powerdown;
+ int irq;
};
#endif /* P54SPI_H */
--
2.39.5
^ permalink raw reply related
* [PATCH v4 3/3 omap] ARM: dts: omap2: add stlc4560 spi-wireless node
From: Arnd Bergmann @ 2026-04-30 8:12 UTC (permalink / raw)
To: netdev
Cc: Arnd Bergmann, Aaro Koskinen, Andreas Kemnade,
Bartosz Golaszewski, Benoît Cousson, David S. Miller,
Dmitry Torokhov, Eric Dumazet, Felipe Balbi, Jakub Kicinski,
Johannes Berg, Kevin Hilman, Krzysztof Kozlowski, Linus Walleij,
Paolo Abeni, Rob Herring, Roger Quadros, Tony Lindgren,
linux-wireless, devicetree, linux-kernel, linux-arm-kernel,
linux-gpio, linux-omap, Krzysztof Kozlowski
In-Reply-To: <20260430081242.3686993-1-arnd@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
Converted from the platform_device creation in board-n8x0.c.
Link: https://lore.kernel.org/all/20230314163201.955689-1-arnd@kernel.org/
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/boot/dts/ti/omap/omap2.dtsi | 4 ++++
arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi | 12 ++++++++++++
2 files changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/omap2.dtsi b/arch/arm/boot/dts/ti/omap/omap2.dtsi
index afabb36a8ac1..fdc1790adf43 100644
--- a/arch/arm/boot/dts/ti/omap/omap2.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap2.dtsi
@@ -129,6 +129,8 @@ i2c2: i2c@48072000 {
};
mcspi1: spi@48098000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "ti,omap2-mcspi";
ti,hwmods = "mcspi1";
reg = <0x48098000 0x100>;
@@ -140,6 +142,8 @@ mcspi1: spi@48098000 {
};
mcspi2: spi@4809a000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "ti,omap2-mcspi";
ti,hwmods = "mcspi2";
reg = <0x4809a000 0x100>;
diff --git a/arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi b/arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi
index 63b0b4921e4e..fe9dd8bbfc85 100644
--- a/arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap2420-n8x0-common.dtsi
@@ -109,3 +109,15 @@ partition@5 {
};
};
};
+
+&mcspi2 {
+ status = "okay";
+
+ wifi@0 {
+ reg = <0>;
+ compatible = "st,stlc4560";
+ spi-max-frequency = <48000000>;
+ interrupts-extended = <&gpio3 23 IRQ_TYPE_EDGE_RISING>;
+ powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_LOW>; /* gpio 97 */
+ };
+};
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v3 1/2] media: verisilicon: Simplify motion vectors and rfc buffers allocation
From: Benjamin Gaignard @ 2026-04-30 8:20 UTC (permalink / raw)
To: Nicolas Dufresne, Frank Li
Cc: p.zabel, mchehab, s.hauer, kernel, festevam, heiko,
mcoquelin.stm32, alexandre.torgue, wens, jernej.skrabec, samuel,
linux-kernel, linux-media, linux-rockchip, imx, linux-arm-kernel,
linux-stm32, linux-sunxi, kernel
In-Reply-To: <4064d0168c3409a1e15f9c92da56cea93956b31e.camel@collabora.com>
Le 29/04/2026 à 20:11, Nicolas Dufresne a écrit :
> Hi Benjamin,
>
> Le vendredi 17 avril 2026 à 06:54 -0400, Frank Li a écrit :
>> On Wed, Apr 15, 2026 at 04:04:19PM +0200, Benjamin Gaignard wrote:
>>> Until now we reserve the space needed for motion vectors and reference
>>> frame compression at the end of the frame buffer.
>>> Disentanglement mv and rfc from frame buffers by allocating
>>> distinct buffers for each purpose.
>>> That simplify the code by removing lot of offset computation.
>> Can you try split to more small and straight forward patches, for example
>>
>> for example create patch just move hantro_h264_mv_size() to header file,
> Marking this has Change Requested, as I completely agree with Frank that a split
> of this giant will help proper review.
I will cut the series in two: one clean up series (which will come after av1 lib series been merged)
and buffer simplification patch after that.
Benjamin
>
> Nicolas
>
>> ...
>>> +++ b/drivers/media/platform/verisilicon/hantro_hevc.c
>>> @@ -44,30 +44,49 @@ dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx,
>>> int i;
>>>
>>> /* Find the reference buffer in already known ones */
>>> - for (i = 0; i < NUM_REF_PICTURES; i++) {
>>> + for (i = 0; i < NUM_REF_PICTURES; i++) {
>>> if (hevc_dec->ref_bufs_poc[i] == poc) {
>>> hevc_dec->ref_bufs_used |= 1 << i;
>>> return hevc_dec->ref_bufs[i].dma;
>>> }
>>> }
>>> -
>>> return 0;
>> Move this code style change to new patches.
>>
>> Frank
^ permalink raw reply
* Re: [PATCH] media: verisilicon: Stop allocate mv and rfc buffers inside frame buffers
From: Benjamin Gaignard @ 2026-04-30 8:27 UTC (permalink / raw)
To: Nicolas Dufresne, p.zabel, mchehab, heiko
Cc: linux-media, linux-rockchip, linux-kernel, linux-arm-kernel,
kernel
In-Reply-To: <4f5af7ff2f8e9be44f8f8c488fdf4edc0dd0c0a4.camel@collabora.com>
Le 29/04/2026 à 20:13, Nicolas Dufresne a écrit :
> Le lundi 16 mars 2026 à 11:37 -0400, Nicolas Dufresne a écrit :
>> Hi,
>>
>> Le jeudi 12 mars 2026 à 18:35 +0100, Benjamin Gaignard a écrit :
>>> Until now we reserve the space needed for motion vectors and reference
>>> frame compression at the end of the frame buffer.
>>> This method was convenient but won't fit when we will introduce secure
>>> data path because we will want to protect YUV data but not motion vectors
>>> or compression data.
>>>
>>> This patch disentanglement mv and rfc from frame buffers by allocating
>>> distinct buffers for each purpose.
>>>
>>> Tested on imx8mq for VP8, VP9, H264 and H265 codecs.
>> What did you test exactly ? When I check the RDC knobs on imx8mq, there is no
>> subdivision of the domain. So when you run in policy 2 (using the RDC and set
>> the VPU domain as secure read/write) these buffers effectively need to be inside
>> the secure ranges, and this is what I have running downstream at the moment (not
>> ready for upstreaming yet). To be more flexibly, and subdivides the rules within
>> an IP, policy 1 is needed, meaning you need to protect the IP register range,
>> and clearly we don't have that upstream since that imply passing the register
>> data over to the TEE. So with that justification, this change seems like a bit
>> early.
>>
>> The separation seems wanted in the more general case, but your implementation
>> does not take advantage of it. Notably, this driver allocates the same number of
>> reference as there is capture buffers. Both allocation pool endup too big due to
>> V4L2 limitations, but if you look at MTK, you can see they made the effort to
>> limit the number of auxiliary buffers. Perhaps leveraging the separation would
>> make this patch a bit more acceptable to me.
>
> I haven't received any feedback on this. Are we going to try and limit the
> number of auxiliary buffer to the number of reference (or per codec maximum) ?
For sure not is this patch but that could be done after.
Benjamin
>
> Nicolas
>
>> regards,
>> Nicolas
>>
>>> Tested on rk3588 for AV1.
>>> All fluster scores are remain the sames.
>>>
>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
>>> ---
>>> Note: This patch depends on "media: verisilicon: Create AV1 helper library"
>>> version 2
>>>
>>> drivers/media/platform/verisilicon/hantro.h | 28 +-
>>> .../media/platform/verisilicon/hantro_av1.c | 7 -
>>> .../media/platform/verisilicon/hantro_av1.h | 1 -
>>> .../media/platform/verisilicon/hantro_g2.c | 36 --
>>> .../platform/verisilicon/hantro_g2_hevc_dec.c | 65 ++--
>>> .../platform/verisilicon/hantro_g2_vp9_dec.c | 12 +-
>>> .../media/platform/verisilicon/hantro_hevc.c | 38 ++-
>>> .../media/platform/verisilicon/hantro_hw.h | 103 +-----
>>> .../platform/verisilicon/hantro_postproc.c | 29 +-
>>> .../media/platform/verisilicon/hantro_v4l2.c | 314 ++++++++++++++++--
>>> .../verisilicon/rockchip_vpu981_hw_av1_dec.c | 16 +-
>>> 11 files changed, 388 insertions(+), 261 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/verisilicon/hantro.h
>>> b/drivers/media/platform/verisilicon/hantro.h
>>> index 0353de154a1e..daee5b95480c 100644
>>> --- a/drivers/media/platform/verisilicon/hantro.h
>>> +++ b/drivers/media/platform/verisilicon/hantro.h
>>> @@ -31,6 +31,9 @@ struct hantro_ctx;
>>> struct hantro_codec_ops;
>>> struct hantro_postproc_ops;
>>>
>>> +#define MAX_MV_BUFFERS MAX_POSTPROC_BUFFERS
>>> +#define MAX_RFC_BUFFERS MAX_POSTPROC_BUFFERS
>>> +
>>> #define HANTRO_JPEG_ENCODER BIT(0)
>>> #define HANTRO_ENCODERS 0x0000ffff
>>> #define HANTRO_MPEG2_DECODER BIT(16)
>>> @@ -237,6 +240,9 @@ struct hantro_dev {
>>> * @need_postproc: Set to true if the bitstream features require to
>>> * use the post-processor.
>>> *
>>> + * @dec_mv: motion vectors buffers for the context.
>>> + * @dec_rfc: reference frame compression buffers for the context.
>>> + *
>>> * @codec_ops: Set of operations related to codec mode.
>>> * @postproc: Post-processing context.
>>> * @h264_dec: H.264-decoding context.
>>> @@ -264,6 +270,9 @@ struct hantro_ctx {
>>> int jpeg_quality;
>>> int bit_depth;
>>>
>>> + struct hantro_aux_buf dec_mv[MAX_MV_BUFFERS];
>>> + struct hantro_aux_buf dec_rfc[MAX_RFC_BUFFERS];
>>> +
>>> const struct hantro_codec_ops *codec_ops;
>>> struct hantro_postproc_ctx postproc;
>>> bool need_postproc;
>>> @@ -329,19 +338,29 @@ struct hantro_postproc_regs {
>>> struct hantro_reg input_height_ext;
>>> };
>>>
>>> +struct hantro_hevc_decoded_buffer_info {
>>> + /* Info needed when the decoded frame serves as a reference frame. */
>>> + s32 poc;
>>> + dma_addr_t luma_addr;
>>> + dma_addr_t chroma_addr;
>>> + dma_addr_t mv_addr;
>>> + dma_addr_t rfc_luma_addr;
>>> + dma_addr_t rfc_chroma_addr;
>>> +};
>>> +
>>> struct hantro_vp9_decoded_buffer_info {
>>> /* Info needed when the decoded frame serves as a reference frame. */
>>> unsigned short width;
>>> unsigned short height;
>>> size_t chroma_offset;
>>> - size_t mv_offset;
>>> + dma_addr_t mv_addr;
>>> u32 bit_depth : 4;
>>> };
>>>
>>> struct hantro_av1_decoded_buffer_info {
>>> /* Info needed when the decoded frame serves as a reference frame. */
>>> size_t chroma_offset;
>>> - size_t mv_offset;
>>> + dma_addr_t mv_addr;
>>> };
>>>
>>> struct hantro_decoded_buffer {
>>> @@ -351,6 +370,7 @@ struct hantro_decoded_buffer {
>>> union {
>>> struct hantro_vp9_decoded_buffer_info vp9;
>>> struct hantro_av1_decoded_buffer_info av1;
>>> + struct hantro_hevc_decoded_buffer_info hevc;
>>> };
>>> };
>>>
>>> @@ -507,4 +527,8 @@ void hantro_postproc_free(struct hantro_ctx *ctx);
>>> int hanto_postproc_enum_framesizes(struct hantro_ctx *ctx,
>>> struct v4l2_frmsizeenum *fsize);
>>>
>>> +dma_addr_t hantro_mv_get_buf_addr(struct hantro_ctx *ctx, int index);
>>> +dma_addr_t hantro_rfc_get_luma_buf_addr(struct hantro_ctx *ctx, int index);
>>> +dma_addr_t hantro_rfc_get_chroma_buf_addr(struct hantro_ctx *ctx, int index);
>>> +
>>> #endif /* HANTRO_H_ */
>>> diff --git a/drivers/media/platform/verisilicon/hantro_av1.c
>>> b/drivers/media/platform/verisilicon/hantro_av1.c
>>> index 5a51ac877c9c..3a80a7994f67 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_av1.c
>>> +++ b/drivers/media/platform/verisilicon/hantro_av1.c
>>> @@ -222,13 +222,6 @@ size_t hantro_av1_luma_size(struct hantro_ctx *ctx)
>>> return ctx->ref_fmt.plane_fmt[0].bytesperline * ctx->ref_fmt.height;
>>> }
>>>
>>> -size_t hantro_av1_chroma_size(struct hantro_ctx *ctx)
>>> -{
>>> - size_t cr_offset = hantro_av1_luma_size(ctx);
>>> -
>>> - return ALIGN((cr_offset * 3) / 2, 64);
>>> -}
>>> -
>>> static void hantro_av1_tiles_free(struct hantro_ctx *ctx)
>>> {
>>> struct hantro_dev *vpu = ctx->dev;
>>> diff --git a/drivers/media/platform/verisilicon/hantro_av1.h
>>> b/drivers/media/platform/verisilicon/hantro_av1.h
>>> index 4e2122b95cdd..330f7938d097 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_av1.h
>>> +++ b/drivers/media/platform/verisilicon/hantro_av1.h
>>> @@ -41,7 +41,6 @@ int hantro_av1_get_order_hint(struct hantro_ctx *ctx, int
>>> ref);
>>> int hantro_av1_frame_ref(struct hantro_ctx *ctx, u64 timestamp);
>>> void hantro_av1_clean_refs(struct hantro_ctx *ctx);
>>> size_t hantro_av1_luma_size(struct hantro_ctx *ctx);
>>> -size_t hantro_av1_chroma_size(struct hantro_ctx *ctx);
>>> void hantro_av1_exit(struct hantro_ctx *ctx);
>>> int hantro_av1_init(struct hantro_ctx *ctx);
>>> int hantro_av1_prepare_run(struct hantro_ctx *ctx);
>>> diff --git a/drivers/media/platform/verisilicon/hantro_g2.c
>>> b/drivers/media/platform/verisilicon/hantro_g2.c
>>> index 318673b66da8..4ae7df53dcb1 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_g2.c
>>> +++ b/drivers/media/platform/verisilicon/hantro_g2.c
>>> @@ -99,39 +99,3 @@ size_t hantro_g2_chroma_offset(struct hantro_ctx *ctx)
>>> {
>>> return ctx->ref_fmt.plane_fmt[0].bytesperline * ctx-
>>>> ref_fmt.height;
>>> }
>>> -
>>> -size_t hantro_g2_motion_vectors_offset(struct hantro_ctx *ctx)
>>> -{
>>> - size_t cr_offset = hantro_g2_chroma_offset(ctx);
>>> -
>>> - return ALIGN((cr_offset * 3) / 2, G2_ALIGN);
>>> -}
>>> -
>>> -static size_t hantro_g2_mv_size(struct hantro_ctx *ctx)
>>> -{
>>> - const struct hantro_hevc_dec_ctrls *ctrls = &ctx->hevc_dec.ctrls;
>>> - const struct v4l2_ctrl_hevc_sps *sps = ctrls->sps;
>>> - unsigned int pic_width_in_ctbs, pic_height_in_ctbs;
>>> - unsigned int max_log2_ctb_size;
>>> -
>>> - max_log2_ctb_size = sps->log2_min_luma_coding_block_size_minus3 + 3 +
>>> - sps->log2_diff_max_min_luma_coding_block_size;
>>> - pic_width_in_ctbs = (sps->pic_width_in_luma_samples +
>>> - (1 << max_log2_ctb_size) - 1) >>
>>> max_log2_ctb_size;
>>> - pic_height_in_ctbs = (sps->pic_height_in_luma_samples + (1 <<
>>> max_log2_ctb_size) - 1)
>>> - >> max_log2_ctb_size;
>>> -
>>> - return pic_width_in_ctbs * pic_height_in_ctbs * (1 << (2 *
>>> (max_log2_ctb_size - 4))) * 16;
>>> -}
>>> -
>>> -size_t hantro_g2_luma_compress_offset(struct hantro_ctx *ctx)
>>> -{
>>> - return hantro_g2_motion_vectors_offset(ctx) +
>>> - hantro_g2_mv_size(ctx);
>>> -}
>>> -
>>> -size_t hantro_g2_chroma_compress_offset(struct hantro_ctx *ctx)
>>> -{
>>> - return hantro_g2_luma_compress_offset(ctx) +
>>> - hantro_hevc_luma_compressed_size(ctx->dst_fmt.width, ctx-
>>>> dst_fmt.height);
>>> -}
>>> diff --git a/drivers/media/platform/verisilicon/hantro_g2_hevc_dec.c
>>> b/drivers/media/platform/verisilicon/hantro_g2_hevc_dec.c
>>> index e8c2e83379de..5240cf9b5f58 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_g2_hevc_dec.c
>>> +++ b/drivers/media/platform/verisilicon/hantro_g2_hevc_dec.c
>>> @@ -377,15 +377,9 @@ static int set_ref(struct hantro_ctx *ctx)
>>> const struct v4l2_ctrl_hevc_pps *pps = ctrls->pps;
>>> const struct v4l2_ctrl_hevc_decode_params *decode_params = ctrls-
>>>> decode_params;
>>> const struct v4l2_hevc_dpb_entry *dpb = decode_params->dpb;
>>> - dma_addr_t luma_addr, chroma_addr, mv_addr = 0;
>>> - dma_addr_t compress_luma_addr, compress_chroma_addr = 0;
>>> struct hantro_dev *vpu = ctx->dev;
>>> struct vb2_v4l2_buffer *vb2_dst;
>>> - struct hantro_decoded_buffer *dst;
>>> - size_t cr_offset = hantro_g2_chroma_offset(ctx);
>>> - size_t mv_offset = hantro_g2_motion_vectors_offset(ctx);
>>> - size_t compress_luma_offset = hantro_g2_luma_compress_offset(ctx);
>>> - size_t compress_chroma_offset =
>>> hantro_g2_chroma_compress_offset(ctx);
>>> + struct hantro_decoded_buffer *ref;
>>> u32 max_ref_frames;
>>> u16 dpb_longterm_e;
>>> static const struct hantro_reg cur_poc[] = {
>>> @@ -453,50 +447,37 @@ static int set_ref(struct hantro_ctx *ctx)
>>> dpb_longterm_e = 0;
>>> for (i = 0; i < decode_params->num_active_dpb_entries &&
>>> i < (V4L2_HEVC_DPB_ENTRIES_NUM_MAX - 1); i++) {
>>> - luma_addr = hantro_hevc_get_ref_buf(ctx,
>>> dpb[i].pic_order_cnt_val);
>>> - if (!luma_addr)
>>> + vb2_dst = hantro_hevc_get_ref_buf(ctx,
>>> dpb[i].pic_order_cnt_val);
>>> + if (!vb2_dst)
>>> return -ENOMEM;
>>>
>>> - chroma_addr = luma_addr + cr_offset;
>>> - mv_addr = luma_addr + mv_offset;
>>> - compress_luma_addr = luma_addr + compress_luma_offset;
>>> - compress_chroma_addr = luma_addr + compress_chroma_offset;
>>> -
>>> if (dpb[i].flags & V4L2_HEVC_DPB_ENTRY_LONG_TERM_REFERENCE)
>>> dpb_longterm_e |= BIT(V4L2_HEVC_DPB_ENTRIES_NUM_MAX -
>>> 1 - i);
>>>
>>> - hantro_write_addr(vpu, G2_REF_LUMA_ADDR(i), luma_addr);
>>> - hantro_write_addr(vpu, G2_REF_CHROMA_ADDR(i), chroma_addr);
>>> - hantro_write_addr(vpu, G2_REF_MV_ADDR(i), mv_addr);
>>> - hantro_write_addr(vpu, G2_REF_COMP_LUMA_ADDR(i),
>>> compress_luma_addr);
>>> - hantro_write_addr(vpu, G2_REF_COMP_CHROMA_ADDR(i),
>>> compress_chroma_addr);
>>> + ref = vb2_to_hantro_decoded_buf(&vb2_dst->vb2_buf);
>>> + hantro_write_addr(vpu, G2_REF_LUMA_ADDR(i), ref-
>>>> hevc.luma_addr);
>>> + hantro_write_addr(vpu, G2_REF_CHROMA_ADDR(i), ref-
>>>> hevc.chroma_addr);
>>> + hantro_write_addr(vpu, G2_REF_MV_ADDR(i), ref->hevc.mv_addr);
>>> + hantro_write_addr(vpu, G2_REF_COMP_LUMA_ADDR(i), ref-
>>>> hevc.rfc_luma_addr);
>>> + hantro_write_addr(vpu, G2_REF_COMP_CHROMA_ADDR(i), ref-
>>>> hevc.rfc_chroma_addr);
>>> }
>>>
>>> - vb2_dst = hantro_get_dst_buf(ctx);
>>> - dst = vb2_to_hantro_decoded_buf(&vb2_dst->vb2_buf);
>>> - luma_addr = hantro_get_dec_buf_addr(ctx, &dst->base.vb.vb2_buf);
>>> - if (!luma_addr)
>>> - return -ENOMEM;
>>> -
>>> - if (hantro_hevc_add_ref_buf(ctx, decode_params->pic_order_cnt_val,
>>> luma_addr))
>>> + vb2_dst = hantro_hevc_add_ref_buf(ctx, decode_params-
>>>> pic_order_cnt_val);
>>> + if (!vb2_dst)
>>> return -EINVAL;
>>>
>>> - chroma_addr = luma_addr + cr_offset;
>>> - mv_addr = luma_addr + mv_offset;
>>> - compress_luma_addr = luma_addr + compress_luma_offset;
>>> - compress_chroma_addr = luma_addr + compress_chroma_offset;
>>> -
>>> - hantro_write_addr(vpu, G2_REF_LUMA_ADDR(i), luma_addr);
>>> - hantro_write_addr(vpu, G2_REF_CHROMA_ADDR(i), chroma_addr);
>>> - hantro_write_addr(vpu, G2_REF_MV_ADDR(i), mv_addr);
>>> - hantro_write_addr(vpu, G2_REF_COMP_LUMA_ADDR(i), compress_luma_addr);
>>> - hantro_write_addr(vpu, G2_REF_COMP_CHROMA_ADDR(i++),
>>> compress_chroma_addr);
>>> -
>>> - hantro_write_addr(vpu, G2_OUT_LUMA_ADDR, luma_addr);
>>> - hantro_write_addr(vpu, G2_OUT_CHROMA_ADDR, chroma_addr);
>>> - hantro_write_addr(vpu, G2_OUT_MV_ADDR, mv_addr);
>>> - hantro_write_addr(vpu, G2_OUT_COMP_LUMA_ADDR, compress_luma_addr);
>>> - hantro_write_addr(vpu, G2_OUT_COMP_CHROMA_ADDR,
>>> compress_chroma_addr);
>>> + ref = vb2_to_hantro_decoded_buf(&vb2_dst->vb2_buf);
>>> + hantro_write_addr(vpu, G2_REF_LUMA_ADDR(i), ref->hevc.luma_addr);
>>> + hantro_write_addr(vpu, G2_REF_CHROMA_ADDR(i), ref->hevc.chroma_addr);
>>> + hantro_write_addr(vpu, G2_REF_MV_ADDR(i), ref->hevc.mv_addr);
>>> + hantro_write_addr(vpu, G2_REF_COMP_LUMA_ADDR(i), ref-
>>>> hevc.rfc_luma_addr);
>>> + hantro_write_addr(vpu, G2_REF_COMP_CHROMA_ADDR(i++), ref-
>>>> hevc.rfc_chroma_addr);
>>> +
>>> + hantro_write_addr(vpu, G2_OUT_LUMA_ADDR, ref->hevc.luma_addr);
>>> + hantro_write_addr(vpu, G2_OUT_CHROMA_ADDR, ref->hevc.chroma_addr);
>>> + hantro_write_addr(vpu, G2_OUT_MV_ADDR, ref->hevc.mv_addr);
>>> + hantro_write_addr(vpu, G2_OUT_COMP_LUMA_ADDR, ref-
>>>> hevc.rfc_luma_addr);
>>> + hantro_write_addr(vpu, G2_OUT_COMP_CHROMA_ADDR, ref-
>>>> hevc.rfc_chroma_addr);
>>>
>>> for (; i < V4L2_HEVC_DPB_ENTRIES_NUM_MAX; i++) {
>>> hantro_write_addr(vpu, G2_REF_LUMA_ADDR(i), 0);
>>> diff --git a/drivers/media/platform/verisilicon/hantro_g2_vp9_dec.c
>>> b/drivers/media/platform/verisilicon/hantro_g2_vp9_dec.c
>>> index 56c79e339030..1e96d0fce72a 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_g2_vp9_dec.c
>>> +++ b/drivers/media/platform/verisilicon/hantro_g2_vp9_dec.c
>>> @@ -129,7 +129,7 @@ static void config_output(struct hantro_ctx *ctx,
>>> struct hantro_decoded_buffer *dst,
>>> const struct v4l2_ctrl_vp9_frame *dec_params)
>>> {
>>> - dma_addr_t luma_addr, chroma_addr, mv_addr;
>>> + dma_addr_t luma_addr, chroma_addr;
>>>
>>> hantro_reg_write(ctx->dev, &g2_out_dis, 0);
>>> if (!ctx->dev->variant->legacy_regs)
>>> @@ -142,9 +142,8 @@ static void config_output(struct hantro_ctx *ctx,
>>> hantro_write_addr(ctx->dev, G2_OUT_CHROMA_ADDR, chroma_addr);
>>> dst->vp9.chroma_offset = hantro_g2_chroma_offset(ctx);
>>>
>>> - mv_addr = luma_addr + hantro_g2_motion_vectors_offset(ctx);
>>> - hantro_write_addr(ctx->dev, G2_OUT_MV_ADDR, mv_addr);
>>> - dst->vp9.mv_offset = hantro_g2_motion_vectors_offset(ctx);
>>> + dst->vp9.mv_addr = hantro_mv_get_buf_addr(ctx, dst-
>>>> base.vb.vb2_buf.index);
>>> + hantro_write_addr(ctx->dev, G2_OUT_MV_ADDR, dst->vp9.mv_addr);
>>> }
>>>
>>> struct hantro_vp9_ref_reg {
>>> @@ -215,15 +214,12 @@ static void config_ref_registers(struct hantro_ctx *ctx,
>>> .c_base = G2_REF_CHROMA_ADDR(5),
>>> },
>>> };
>>> - dma_addr_t mv_addr;
>>>
>>> config_ref(ctx, dst, &ref_regs[0], dec_params, dec_params-
>>>> last_frame_ts);
>>> config_ref(ctx, dst, &ref_regs[1], dec_params, dec_params-
>>>> golden_frame_ts);
>>> config_ref(ctx, dst, &ref_regs[2], dec_params, dec_params-
>>>> alt_frame_ts);
>>>
>>> - mv_addr = hantro_get_dec_buf_addr(ctx, &mv_ref->base.vb.vb2_buf) +
>>> - mv_ref->vp9.mv_offset;
>>> - hantro_write_addr(ctx->dev, G2_REF_MV_ADDR(0), mv_addr);
>>> + hantro_write_addr(ctx->dev, G2_REF_MV_ADDR(0), mv_ref->vp9.mv_addr);
>>>
>>> hantro_reg_write(ctx->dev, &vp9_last_sign_bias,
>>> dec_params->ref_frame_sign_bias &
>>> V4L2_VP9_SIGN_BIAS_LAST ? 1 : 0);
>>> diff --git a/drivers/media/platform/verisilicon/hantro_hevc.c
>>> b/drivers/media/platform/verisilicon/hantro_hevc.c
>>> index 83cd12b0ddd6..7ea1dc57a639 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_hevc.c
>>> +++ b/drivers/media/platform/verisilicon/hantro_hevc.c
>>> @@ -37,39 +37,57 @@ void hantro_hevc_ref_init(struct hantro_ctx *ctx)
>>> hevc_dec->ref_bufs_used = 0;
>>> }
>>>
>>> -dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx,
>>> - s32 poc)
>>> +struct vb2_v4l2_buffer *hantro_hevc_get_ref_buf(struct hantro_ctx *ctx, s32
>>> poc)
>>> {
>>> struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
>>> + struct hantro_decoded_buffer *ref;
>>> int i;
>>>
>>> /* Find the reference buffer in already known ones */
>>> for (i = 0; i < NUM_REF_PICTURES; i++) {
>>> - if (hevc_dec->ref_bufs_poc[i] == poc) {
>>> + ref = vb2_to_hantro_decoded_buf(&hevc_dec->vb2_ref[i]-
>>>> vb2_buf);
>>> + if (ref->hevc.poc == poc) {
>>> hevc_dec->ref_bufs_used |= 1 << i;
>>> - return hevc_dec->ref_bufs[i].dma;
>>> + return hevc_dec->vb2_ref[i];
>>> }
>>> }
>>>
>>> - return 0;
>>> + return NULL;
>>> }
>>>
>>> -int hantro_hevc_add_ref_buf(struct hantro_ctx *ctx, int poc, dma_addr_t addr)
>>> +struct vb2_v4l2_buffer *hantro_hevc_add_ref_buf(struct hantro_ctx *ctx, int
>>> poc)
>>> {
>>> struct hantro_hevc_dec_hw_ctx *hevc_dec = &ctx->hevc_dec;
>>> + struct hantro_decoded_buffer *dst;
>>> int i;
>>>
>>> /* Add a new reference buffer */
>>> for (i = 0; i < NUM_REF_PICTURES; i++) {
>>> if (!(hevc_dec->ref_bufs_used & 1 << i)) {
>>> hevc_dec->ref_bufs_used |= 1 << i;
>>> - hevc_dec->ref_bufs_poc[i] = poc;
>>> - hevc_dec->ref_bufs[i].dma = addr;
>>> - return 0;
>>> + hevc_dec->vb2_ref[i] = hantro_get_dst_buf(ctx);
>>> + dst = vb2_to_hantro_decoded_buf(&hevc_dec-
>>>> vb2_ref[i]->vb2_buf);
>>> + dst->hevc.poc = poc;
>>> + dst->hevc.luma_addr = hantro_get_dec_buf_addr(ctx,
>>> &dst->base.vb.vb2_buf);
>>> + dst->hevc.chroma_addr = dst->hevc.luma_addr +
>>> hantro_g2_chroma_offset(ctx);
>>> + dst->hevc.mv_addr = hantro_mv_get_buf_addr(ctx, dst-
>>>> base.vb.vb2_buf.index);
>>> + if (ctx->hevc_dec.use_compression) {
>>> + dst->hevc.rfc_luma_addr =
>>> + hantro_rfc_get_luma_buf_addr(ctx,
>>> + dst-
>>>> base.vb.vb2_buf.index);
>>> + dst->hevc.rfc_chroma_addr =
>>> + hantro_rfc_get_chroma_buf_addr(ctx,
>>> + dst-
>>>> base.vb.vb2_buf.index);
>>> + } else {
>>> + dst->hevc.rfc_luma_addr = 0;
>>> + dst->hevc.rfc_chroma_addr = 0;
>>> + }
>>> +
>>> + return hevc_dec->vb2_ref[i];
>>> }
>>> }
>>>
>>> - return -EINVAL;
>>> + return NULL;
>>> }
>>>
>>> static int tile_buffer_reallocate(struct hantro_ctx *ctx)
>>> diff --git a/drivers/media/platform/verisilicon/hantro_hw.h
>>> b/drivers/media/platform/verisilicon/hantro_hw.h
>>> index f0e4bca4b2b2..74e20fc82630 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_hw.h
>>> +++ b/drivers/media/platform/verisilicon/hantro_hw.h
>>> @@ -147,8 +147,8 @@ struct hantro_hevc_dec_ctrls {
>>> * @tile_bsd: Tile BSD control buffer
>>> * @ref_bufs: Internal reference buffers
>>> * @scaling_lists: Scaling lists buffer
>>> - * @ref_bufs_poc: Internal reference buffers picture order count
>>> * @ref_bufs_used: Bitfield of used reference buffers
>>> + * @vb2_ref: Reference buffers
>>> * @ctrls: V4L2 controls attached to a run
>>> * @num_tile_cols_allocated: number of allocated tiles
>>> * @use_compression: use reference buffer compression
>>> @@ -158,10 +158,9 @@ struct hantro_hevc_dec_hw_ctx {
>>> struct hantro_aux_buf tile_filter;
>>> struct hantro_aux_buf tile_sao;
>>> struct hantro_aux_buf tile_bsd;
>>> - struct hantro_aux_buf ref_bufs[NUM_REF_PICTURES];
>>> struct hantro_aux_buf scaling_lists;
>>> - s32 ref_bufs_poc[NUM_REF_PICTURES];
>>> u32 ref_bufs_used;
>>> + struct vb2_v4l2_buffer *vb2_ref[NUM_REF_PICTURES];
>>> struct hantro_hevc_dec_ctrls ctrls;
>>> unsigned int num_tile_cols_allocated;
>>> bool use_compression;
>>> @@ -456,8 +455,9 @@ void hantro_hevc_dec_exit(struct hantro_ctx *ctx);
>>> int hantro_g2_hevc_dec_run(struct hantro_ctx *ctx);
>>> int hantro_hevc_dec_prepare_run(struct hantro_ctx *ctx);
>>> void hantro_hevc_ref_init(struct hantro_ctx *ctx);
>>> -dma_addr_t hantro_hevc_get_ref_buf(struct hantro_ctx *ctx, s32 poc);
>>> -int hantro_hevc_add_ref_buf(struct hantro_ctx *ctx, int poc, dma_addr_t
>>> addr);
>>> +struct vb2_v4l2_buffer *hantro_hevc_get_ref_buf(struct hantro_ctx *ctx, s32
>>> poc);
>>> +struct vb2_v4l2_buffer *hantro_hevc_add_ref_buf(struct hantro_ctx *ctx, int
>>> poc);
>>> +int hantro_hevc_get_ref_buf_index(struct hantro_ctx *ctx, s32 poc);
>>>
>>> int rockchip_vpu981_av1_dec_init(struct hantro_ctx *ctx);
>>> void rockchip_vpu981_av1_dec_exit(struct hantro_ctx *ctx);
>>> @@ -469,100 +469,7 @@ static inline unsigned short hantro_vp9_num_sbs(unsigned
>>> short dimension)
>>> return (dimension + 63) / 64;
>>> }
>>>
>>> -static inline size_t
>>> -hantro_vp9_mv_size(unsigned int width, unsigned int height)
>>> -{
>>> - int num_ctbs;
>>> -
>>> - /*
>>> - * There can be up to (CTBs x 64) number of blocks,
>>> - * and the motion vector for each block needs 16 bytes.
>>> - */
>>> - num_ctbs = hantro_vp9_num_sbs(width) * hantro_vp9_num_sbs(height);
>>> - return (num_ctbs * 64) * 16;
>>> -}
>>> -
>>> -static inline size_t
>>> -hantro_h264_mv_size(unsigned int width, unsigned int height)
>>> -{
>>> - /*
>>> - * A decoded 8-bit 4:2:0 NV12 frame may need memory for up to
>>> - * 448 bytes per macroblock with additional 32 bytes on
>>> - * multi-core variants.
>>> - *
>>> - * The H264 decoder needs extra space on the output buffers
>>> - * to store motion vectors. This is needed for reference
>>> - * frames and only if the format is non-post-processed NV12.
>>> - *
>>> - * Memory layout is as follow:
>>> - *
>>> - * +---------------------------+
>>> - * | Y-plane 256 bytes x MBs |
>>> - * +---------------------------+
>>> - * | UV-plane 128 bytes x MBs |
>>> - * +---------------------------+
>>> - * | MV buffer 64 bytes x MBs |
>>> - * +---------------------------+
>>> - * | MC sync 32 bytes |
>>> - * +---------------------------+
>>> - */
>>> - return 64 * MB_WIDTH(width) * MB_WIDTH(height) + 32;
>>> -}
>>> -
>>> -static inline size_t
>>> -hantro_hevc_mv_size(unsigned int width, unsigned int height)
>>> -{
>>> - /*
>>> - * A CTB can be 64x64, 32x32 or 16x16.
>>> - * Allocated memory for the "worse" case: 16x16
>>> - */
>>> - return width * height / 16;
>>> -}
>>> -
>>> -static inline size_t
>>> -hantro_hevc_luma_compressed_size(unsigned int width, unsigned int height)
>>> -{
>>> - u32 pic_width_in_cbsy =
>>> - round_up((width + CBS_LUMA - 1) / CBS_LUMA, CBS_SIZE);
>>> - u32 pic_height_in_cbsy = (height + CBS_LUMA - 1) / CBS_LUMA;
>>> -
>>> - return round_up(pic_width_in_cbsy * pic_height_in_cbsy, CBS_SIZE);
>>> -}
>>> -
>>> -static inline size_t
>>> -hantro_hevc_chroma_compressed_size(unsigned int width, unsigned int height)
>>> -{
>>> - u32 pic_width_in_cbsc =
>>> - round_up((width + CBS_CHROMA_W - 1) / CBS_CHROMA_W,
>>> CBS_SIZE);
>>> - u32 pic_height_in_cbsc = (height / 2 + CBS_CHROMA_H - 1) /
>>> CBS_CHROMA_H;
>>> -
>>> - return round_up(pic_width_in_cbsc * pic_height_in_cbsc, CBS_SIZE);
>>> -}
>>> -
>>> -static inline size_t
>>> -hantro_hevc_compressed_size(unsigned int width, unsigned int height)
>>> -{
>>> - return hantro_hevc_luma_compressed_size(width, height) +
>>> - hantro_hevc_chroma_compressed_size(width, height);
>>> -}
>>> -
>>> -static inline unsigned short hantro_av1_num_sbs(unsigned short dimension)
>>> -{
>>> - return DIV_ROUND_UP(dimension, 64);
>>> -}
>>> -
>>> -static inline size_t
>>> -hantro_av1_mv_size(unsigned int width, unsigned int height)
>>> -{
>>> - size_t num_sbs = hantro_av1_num_sbs(width) *
>>> hantro_av1_num_sbs(height);
>>> -
>>> - return ALIGN(num_sbs * 384, 16) * 2 + 512;
>>> -}
>>> -
>>> size_t hantro_g2_chroma_offset(struct hantro_ctx *ctx);
>>> -size_t hantro_g2_motion_vectors_offset(struct hantro_ctx *ctx);
>>> -size_t hantro_g2_luma_compress_offset(struct hantro_ctx *ctx);
>>> -size_t hantro_g2_chroma_compress_offset(struct hantro_ctx *ctx);
>>>
>>> int hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx);
>>> int rockchip_vpu2_mpeg2_dec_run(struct hantro_ctx *ctx);
>>> diff --git a/drivers/media/platform/verisilicon/hantro_postproc.c
>>> b/drivers/media/platform/verisilicon/hantro_postproc.c
>>> index e94d1ba5ef10..2409353c16e4 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_postproc.c
>>> +++ b/drivers/media/platform/verisilicon/hantro_postproc.c
>>> @@ -196,36 +196,11 @@ void hantro_postproc_free(struct hantro_ctx *ctx)
>>> }
>>> }
>>>
>>> -static unsigned int hantro_postproc_buffer_size(struct hantro_ctx *ctx)
>>> -{
>>> - unsigned int buf_size;
>>> -
>>> - buf_size = ctx->ref_fmt.plane_fmt[0].sizeimage;
>>> - if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE)
>>> - buf_size += hantro_h264_mv_size(ctx->ref_fmt.width,
>>> - ctx->ref_fmt.height);
>>> - else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_VP9_FRAME)
>>> - buf_size += hantro_vp9_mv_size(ctx->ref_fmt.width,
>>> - ctx->ref_fmt.height);
>>> - else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_HEVC_SLICE) {
>>> - buf_size += hantro_hevc_mv_size(ctx->ref_fmt.width,
>>> - ctx->ref_fmt.height);
>>> - if (ctx->hevc_dec.use_compression)
>>> - buf_size += hantro_hevc_compressed_size(ctx-
>>>> ref_fmt.width,
>>> - ctx-
>>>> ref_fmt.height);
>>> - }
>>> - else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_AV1_FRAME)
>>> - buf_size += hantro_av1_mv_size(ctx->ref_fmt.width,
>>> - ctx->ref_fmt.height);
>>> -
>>> - return buf_size;
>>> -}
>>> -
>>> static int hantro_postproc_alloc(struct hantro_ctx *ctx, int index)
>>> {
>>> struct hantro_dev *vpu = ctx->dev;
>>> struct hantro_aux_buf *priv = &ctx->postproc.dec_q[index];
>>> - unsigned int buf_size = hantro_postproc_buffer_size(ctx);
>>> + unsigned int buf_size = ctx->ref_fmt.plane_fmt[0].sizeimage;
>>>
>>> if (!buf_size)
>>> return -EINVAL;
>>> @@ -267,7 +242,7 @@ dma_addr_t
>>> hantro_postproc_get_dec_buf_addr(struct hantro_ctx *ctx, int index)
>>> {
>>> struct hantro_aux_buf *priv = &ctx->postproc.dec_q[index];
>>> - unsigned int buf_size = hantro_postproc_buffer_size(ctx);
>>> + unsigned int buf_size = ctx->ref_fmt.plane_fmt[0].sizeimage;
>>> struct hantro_dev *vpu = ctx->dev;
>>> int ret;
>>>
>>> diff --git a/drivers/media/platform/verisilicon/hantro_v4l2.c
>>> b/drivers/media/platform/verisilicon/hantro_v4l2.c
>>> index fcf3bd9bcda2..6a876142c224 100644
>>> --- a/drivers/media/platform/verisilicon/hantro_v4l2.c
>>> +++ b/drivers/media/platform/verisilicon/hantro_v4l2.c
>>> @@ -36,6 +36,9 @@ static int hantro_set_fmt_out(struct hantro_ctx *ctx,
>>> static int hantro_set_fmt_cap(struct hantro_ctx *ctx,
>>> struct v4l2_pix_format_mplane *pix_mp);
>>>
>>> +static void hantro_mv_free(struct hantro_ctx *ctx);
>>> +static void hantro_rfc_free(struct hantro_ctx *ctx);
>>> +
>>> static const struct hantro_fmt *
>>> hantro_get_formats(const struct hantro_ctx *ctx, unsigned int *num_fmts, bool
>>> need_postproc)
>>> {
>>> @@ -362,26 +365,6 @@ static int hantro_try_fmt(const struct hantro_ctx *ctx,
>>> /* Fill remaining fields */
>>> v4l2_fill_pixfmt_mp(pix_mp, fmt->fourcc, pix_mp->width,
>>> pix_mp->height);
>>> - if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE &&
>>> - !hantro_needs_postproc(ctx, fmt))
>>> - pix_mp->plane_fmt[0].sizeimage +=
>>> - hantro_h264_mv_size(pix_mp->width,
>>> - pix_mp->height);
>>> - else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_VP9_FRAME
>>> &&
>>> - !hantro_needs_postproc(ctx, fmt))
>>> - pix_mp->plane_fmt[0].sizeimage +=
>>> - hantro_vp9_mv_size(pix_mp->width,
>>> - pix_mp->height);
>>> - else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_HEVC_SLICE
>>> &&
>>> - !hantro_needs_postproc(ctx, fmt))
>>> - pix_mp->plane_fmt[0].sizeimage +=
>>> - hantro_hevc_mv_size(pix_mp->width,
>>> - pix_mp->height);
>>> - else if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_AV1_FRAME
>>> &&
>>> - !hantro_needs_postproc(ctx, fmt))
>>> - pix_mp->plane_fmt[0].sizeimage +=
>>> - hantro_av1_mv_size(pix_mp->width,
>>> - pix_mp->height);
>>> } else if (!pix_mp->plane_fmt[0].sizeimage) {
>>> /*
>>> * For coded formats the application can specify
>>> @@ -999,6 +982,9 @@ static void hantro_stop_streaming(struct vb2_queue *q)
>>> if (V4L2_TYPE_IS_OUTPUT(q->type) &&
>>> v4l2_m2m_has_stopped(ctx->fh.m2m_ctx))
>>> v4l2_event_queue_fh(&ctx->fh, &hantro_eos_event);
>>> +
>>> + hantro_mv_free(ctx);
>>> + hantro_rfc_free(ctx);
>>> }
>>>
>>> static void hantro_buf_request_complete(struct vb2_buffer *vb)
>>> @@ -1025,3 +1011,291 @@ const struct vb2_ops hantro_queue_ops = {
>>> .start_streaming = hantro_start_streaming,
>>> .stop_streaming = hantro_stop_streaming,
>>> };
>>> +
>>> +static size_t
>>> +hantro_vp9_mv_size(unsigned int width, unsigned int height)
>>> +{
>>> + int num_ctbs;
>>> +
>>> + /*
>>> + * There can be up to (CTBs x 64) number of blocks,
>>> + * and the motion vector for each block needs 16 bytes.
>>> + */
>>> + num_ctbs = hantro_vp9_num_sbs(width) * hantro_vp9_num_sbs(height);
>>> + return (num_ctbs * 64) * 16;
>>> +}
>>> +
>>> +static size_t
>>> +hantro_h264_mv_size(unsigned int width, unsigned int height)
>>> +{
>>> + /*
>>> + * A decoded 8-bit 4:2:0 NV12 frame may need memory for up to
>>> + * 448 bytes per macroblock with additional 32 bytes on
>>> + * multi-core variants.
>>> + *
>>> + * The H264 decoder needs extra space on the output buffers
>>> + * to store motion vectors. This is needed for reference
>>> + * frames and only if the format is non-post-processed NV12.
>>> + *
>>> + * Memory layout is as follow:
>>> + *
>>> + * +---------------------------+
>>> + * | Y-plane 256 bytes x MBs |
>>> + * +---------------------------+
>>> + * | UV-plane 128 bytes x MBs |
>>> + * +---------------------------+
>>> + * | MV buffer 64 bytes x MBs |
>>> + * +---------------------------+
>>> + * | MC sync 32 bytes |
>>> + * +---------------------------+
>>> + */
>>> + return 64 * MB_WIDTH(width) * MB_WIDTH(height) + 32;
>>> +}
>>> +
>>> +static size_t
>>> +hantro_hevc_mv_size(unsigned int width, unsigned int height, int depth)
>>> +{
>>> + /*
>>> + * A CTB can be 64x64, 32x32 or 16x16.
>>> + * Allocated memory for the "worse" case: 16x16
>>> + */
>>> + return DIV_ROUND_UP(width * height * depth / 8, 16);
>>> +}
>>> +
>>> +static inline unsigned short hantro_av1_num_sbs(unsigned short dimension)
>>> +{
>>> + return DIV_ROUND_UP(dimension, 64);
>>> +}
>>> +
>>> +static size_t
>>> +hantro_av1_mv_size(unsigned int width, unsigned int height)
>>> +{
>>> + size_t num_sbs = hantro_av1_num_sbs(width) *
>>> hantro_av1_num_sbs(height);
>>> +
>>> + return ALIGN(num_sbs * 384, 16) * 2 + 512;
>>> +}
>>> +
>>> +static void hantro_mv_free(struct hantro_ctx *ctx)
>>> +{
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + int i;
>>> +
>>> + for (i = 0; i < MAX_MV_BUFFERS; i++) {
>>> + struct hantro_aux_buf *mv = &ctx->dec_mv[i];
>>> +
>>> + if (!mv->cpu)
>>> + continue;
>>> +
>>> + dma_free_attrs(vpu->dev, mv->size, mv->cpu,
>>> + mv->dma, mv->attrs);
>>> + mv->cpu = NULL;
>>> + }
>>> +}
>>> +
>>> +static unsigned int hantro_mv_buffer_size(struct hantro_ctx *ctx)
>>> +{
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + int fourcc = ctx->vpu_src_fmt->fourcc;
>>> + int width = ctx->ref_fmt.width;
>>> + int height = ctx->ref_fmt.height;
>>> +
>>> + switch (fourcc) {
>>> + case V4L2_PIX_FMT_H264_SLICE:
>>> + return hantro_h264_mv_size(width, height);
>>> + case V4L2_PIX_FMT_VP9_FRAME:
>>> + return hantro_vp9_mv_size(width, height);
>>> + case V4L2_PIX_FMT_HEVC_SLICE:
>>> + return hantro_hevc_mv_size(width, height, ctx->bit_depth);
>>> + case V4L2_PIX_FMT_AV1_FRAME:
>>> + return hantro_av1_mv_size(width, height);
>>> + }
>>> +
>>> + /* Should not happen */
>>> + dev_warn(vpu->dev, "Invalid motion vectors size\n");
>>> + return 0;
>>> +}
>>> +
>>> +static int hantro_mv_buffer_alloc(struct hantro_ctx *ctx, int index)
>>> +{
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + struct hantro_aux_buf *mv = &ctx->dec_mv[index];
>>> + unsigned int buf_size = hantro_mv_buffer_size(ctx);
>>> +
>>> + if (!buf_size)
>>> + return -EINVAL;
>>> +
>>> + /*
>>> + * Motion vectors buffers are only read and write by the
>>> + * hardware so no mapping is needed.
>>> + */
>>> + mv->attrs = DMA_ATTR_NO_KERNEL_MAPPING;
>>> + mv->cpu = dma_alloc_attrs(vpu->dev, buf_size, &mv->dma,
>>> + GFP_KERNEL, mv->attrs);
>>> + if (!mv->cpu)
>>> + return -ENOMEM;
>>> + mv->size = buf_size;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +dma_addr_t
>>> +hantro_mv_get_buf_addr(struct hantro_ctx *ctx, int index)
>>> +{
>>> + struct hantro_aux_buf *mv = &ctx->dec_mv[index];
>>> + unsigned int buf_size = hantro_mv_buffer_size(ctx);
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + int ret;
>>> +
>>> + if (mv->size < buf_size && mv->cpu) {
>>> + /* buffer is too small, release it */
>>> + dma_free_attrs(vpu->dev, mv->size, mv->cpu,
>>> + mv->dma, mv->attrs);
>>> + mv->cpu = NULL;
>>> + }
>>> +
>>> + if (!mv->cpu) {
>>> + /* buffer not already allocated, try getting a new one */
>>> + ret = hantro_mv_buffer_alloc(ctx, index);
>>> + if (ret)
>>> + return 0;
>>> + }
>>> +
>>> + if (!mv->cpu)
>>> + return 0;
>>> +
>>> + return mv->dma;
>>> +}
>>> +
>>> +static inline size_t
>>> +hantro_hevc_luma_compressed_size(unsigned int width, unsigned int height)
>>> +{
>>> + u32 pic_width_in_cbsy =
>>> + round_up((width + CBS_LUMA - 1) / CBS_LUMA, CBS_SIZE);
>>> + u32 pic_height_in_cbsy = (height + CBS_LUMA - 1) / CBS_LUMA;
>>> +
>>> + return round_up(pic_width_in_cbsy * pic_height_in_cbsy, CBS_SIZE);
>>> +}
>>> +
>>> +static inline size_t
>>> +hantro_hevc_chroma_compressed_size(unsigned int width, unsigned int height)
>>> +{
>>> + u32 pic_width_in_cbsc =
>>> + round_up((width + CBS_CHROMA_W - 1) / CBS_CHROMA_W,
>>> CBS_SIZE);
>>> + u32 pic_height_in_cbsc = (height / 2 + CBS_CHROMA_H - 1) /
>>> CBS_CHROMA_H;
>>> +
>>> + return round_up(pic_width_in_cbsc * pic_height_in_cbsc, CBS_SIZE);
>>> +}
>>> +
>>> +static inline size_t
>>> +hantro_hevc_compressed_size(unsigned int width, unsigned int height)
>>> +{
>>> + return hantro_hevc_luma_compressed_size(width, height) +
>>> + hantro_hevc_chroma_compressed_size(width, height);
>>> +}
>>> +
>>> +static void hantro_rfc_free(struct hantro_ctx *ctx)
>>> +{
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + int i;
>>> +
>>> + for (i = 0; i < MAX_MV_BUFFERS; i++) {
>>> + struct hantro_aux_buf *rfc = &ctx->dec_rfc[i];
>>> +
>>> + if (!rfc->cpu)
>>> + continue;
>>> +
>>> + dma_free_attrs(vpu->dev, rfc->size, rfc->cpu,
>>> + rfc->dma, rfc->attrs);
>>> + rfc->cpu = NULL;
>>> + }
>>> +}
>>> +
>>> +static unsigned int hantro_rfc_buffer_size(struct hantro_ctx *ctx)
>>> +{
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + int fourcc = ctx->vpu_src_fmt->fourcc;
>>> + int width = ctx->ref_fmt.width;
>>> + int height = ctx->ref_fmt.height;
>>> +
>>> + switch (fourcc) {
>>> + case V4L2_PIX_FMT_HEVC_SLICE:
>>> + return hantro_hevc_compressed_size(width, height);
>>> + }
>>> +
>>> + /* Should not happen */
>>> + dev_warn(vpu->dev, "Invalid rfc size\n");
>>> + return 0;
>>> +}
>>> +
>>> +static int hantro_rfc_buffer_alloc(struct hantro_ctx *ctx, int index)
>>> +{
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + struct hantro_aux_buf *rfc = &ctx->dec_rfc[index];
>>> + unsigned int buf_size = hantro_rfc_buffer_size(ctx);
>>> +
>>> + if (!buf_size)
>>> + return -EINVAL;
>>> +
>>> + /*
>>> + * RFC buffers are only read and write by the
>>> + * hardware so no mapping is needed.
>>> + */
>>> + rfc->attrs = DMA_ATTR_NO_KERNEL_MAPPING;
>>> + rfc->cpu = dma_alloc_attrs(vpu->dev, buf_size, &rfc->dma,
>>> + GFP_KERNEL, rfc->attrs);
>>> + if (!rfc->cpu)
>>> + return -ENOMEM;
>>> + rfc->size = buf_size;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +dma_addr_t
>>> +hantro_rfc_get_luma_buf_addr(struct hantro_ctx *ctx, int index)
>>> +{
>>> + struct hantro_aux_buf *rfc = &ctx->dec_rfc[index];
>>> + unsigned int buf_size = hantro_rfc_buffer_size(ctx);
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + int ret;
>>> +
>>> + if (rfc->size < buf_size && rfc->cpu) {
>>> + /* buffer is too small, release it */
>>> + dma_free_attrs(vpu->dev, rfc->size, rfc->cpu,
>>> + rfc->dma, rfc->attrs);
>>> + rfc->cpu = NULL;
>>> + }
>>> +
>>> + if (!rfc->cpu) {
>>> + /* buffer not already allocated, try getting a new one */
>>> + ret = hantro_rfc_buffer_alloc(ctx, index);
>>> + if (ret)
>>> + return 0;
>>> + }
>>> +
>>> + if (!rfc->cpu)
>>> + return 0;
>>> +
>>> + return rfc->dma;
>>> +}
>>> +
>>> +dma_addr_t
>>> +hantro_rfc_get_chroma_buf_addr(struct hantro_ctx *ctx, int index)
>>> +{
>>> + dma_addr_t luma_addr = hantro_rfc_get_luma_buf_addr(ctx, index);
>>> + struct hantro_dev *vpu = ctx->dev;
>>> + int fourcc = ctx->vpu_src_fmt->fourcc;
>>> + int width = ctx->ref_fmt.width;
>>> + int height = ctx->ref_fmt.height;
>>> +
>>> + if (!luma_addr)
>>> + return -EINVAL;
>>> +
>>> + switch (fourcc) {
>>> + case V4L2_PIX_FMT_HEVC_SLICE:
>>> + return luma_addr + hantro_hevc_luma_compressed_size(width,
>>> height);
>>> + }
>>> +
>>> + /* Should not happen */
>>> + dev_warn(vpu->dev, "Invalid rfc chroma address\n");
>>> + return 0;
>>> +}
>>> diff --git a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c
>>> b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c
>>> index c1ada14df4c3..21da8ddfc4b3 100644
>>> --- a/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c
>>> +++ b/drivers/media/platform/verisilicon/rockchip_vpu981_hw_av1_dec.c
>>> @@ -62,7 +62,7 @@ rockchip_vpu981_av1_dec_set_ref(struct hantro_ctx *ctx, int
>>> ref, int idx,
>>> const struct v4l2_ctrl_av1_frame *frame = ctrls->frame;
>>> struct hantro_dev *vpu = ctx->dev;
>>> struct hantro_decoded_buffer *dst;
>>> - dma_addr_t luma_addr, chroma_addr, mv_addr = 0;
>>> + dma_addr_t luma_addr, chroma_addr = 0;
>>> int cur_width = frame->frame_width_minus_1 + 1;
>>> int cur_height = frame->frame_height_minus_1 + 1;
>>> int scale_width =
>>> @@ -120,11 +120,10 @@ rockchip_vpu981_av1_dec_set_ref(struct hantro_ctx *ctx,
>>> int ref, int idx,
>>> dst = vb2_to_hantro_decoded_buf(&av1_dec->frame_refs[idx].vb2_ref-
>>>> vb2_buf);
>>> luma_addr = hantro_get_dec_buf_addr(ctx, &dst->base.vb.vb2_buf);
>>> chroma_addr = luma_addr + dst->av1.chroma_offset;
>>> - mv_addr = luma_addr + dst->av1.mv_offset;
>>>
>>> hantro_write_addr(vpu, AV1_REFERENCE_Y(ref), luma_addr);
>>> hantro_write_addr(vpu, AV1_REFERENCE_CB(ref), chroma_addr);
>>> - hantro_write_addr(vpu, AV1_REFERENCE_MV(ref), mv_addr);
>>> + hantro_write_addr(vpu, AV1_REFERENCE_MV(ref), dst->av1.mv_addr);
>>>
>>> return (scale_width != (1 << AV1_REF_SCALE_SHIFT)) ||
>>> (scale_height != (1 << AV1_REF_SCALE_SHIFT));
>>> @@ -180,11 +179,10 @@ static void
>>> rockchip_vpu981_av1_dec_set_segmentation(struct hantro_ctx *ctx)
>>> if (idx >= 0) {
>>> dma_addr_t luma_addr, mv_addr = 0;
>>> struct hantro_decoded_buffer *seg;
>>> - size_t mv_offset = hantro_av1_chroma_size(ctx);
>>>
>>> seg = vb2_to_hantro_decoded_buf(&av1_dec-
>>>> frame_refs[idx].vb2_ref->vb2_buf);
>>> luma_addr = hantro_get_dec_buf_addr(ctx, &seg-
>>>> base.vb.vb2_buf);
>>> - mv_addr = luma_addr + mv_offset;
>>> + mv_addr = hantro_mv_get_buf_addr(ctx, seg-
>>>> base.vb.vb2_buf.index);
>>>
>>> hantro_write_addr(vpu, AV1_SEGMENTATION, mv_addr);
>>> hantro_reg_write(vpu, &av1_use_temporal3_mvs, 1);
>>> @@ -1350,22 +1348,20 @@ rockchip_vpu981_av1_dec_set_output_buffer(struct
>>> hantro_ctx *ctx)
>>> struct hantro_dev *vpu = ctx->dev;
>>> struct hantro_decoded_buffer *dst;
>>> struct vb2_v4l2_buffer *vb2_dst;
>>> - dma_addr_t luma_addr, chroma_addr, mv_addr = 0;
>>> + dma_addr_t luma_addr, chroma_addr = 0;
>>> size_t cr_offset = hantro_av1_luma_size(ctx);
>>> - size_t mv_offset = hantro_av1_chroma_size(ctx);
>>>
>>> vb2_dst = av1_dec->frame_refs[av1_dec->current_frame_index].vb2_ref;
>>> dst = vb2_to_hantro_decoded_buf(&vb2_dst->vb2_buf);
>>> luma_addr = hantro_get_dec_buf_addr(ctx, &dst->base.vb.vb2_buf);
>>> chroma_addr = luma_addr + cr_offset;
>>> - mv_addr = luma_addr + mv_offset;
>>>
>>> dst->av1.chroma_offset = cr_offset;
>>> - dst->av1.mv_offset = mv_offset;
>>> + dst->av1.mv_addr = hantro_mv_get_buf_addr(ctx, dst-
>>>> base.vb.vb2_buf.index);
>>>
>>> hantro_write_addr(vpu, AV1_TILE_OUT_LU, luma_addr);
>>> hantro_write_addr(vpu, AV1_TILE_OUT_CH, chroma_addr);
>>> - hantro_write_addr(vpu, AV1_TILE_OUT_MV, mv_addr);
>>> + hantro_write_addr(vpu, AV1_TILE_OUT_MV, dst->av1.mv_addr);
>>> }
>>>
>>> int rockchip_vpu981_av1_dec_run(struct hantro_ctx *ctx)
^ permalink raw reply
* Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
From: Sudeep Holla @ 2026-04-30 8:35 UTC (permalink / raw)
To: Andre Przywara
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J . Wysocki, Len Brown, James Morse,
Ben Horgan, Reinette Chatre, Fenghua Yu, Jonathan Cameron,
linux-acpi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260429141339.3171205-6-andre.przywara@arm.com>
On Wed, Apr 29, 2026 at 04:13:39PM +0200, Andre Przywara wrote:
> The Arm MPAM-Fb specification [1] describes a protocol to access MSC
> registers through a firmware interface. This requires a shared memory
> region to hold the message, and a mailbox to trigger the access.
> For ACPI this is wrapped as a PCC channel, described using existing
> ACPI abstractions.
>
> Add code to parse those PCC table descriptions associated with an MSC,
> and store the parsed information in the MSC struct.
> This will be used by the MPAM-Fb access wrapper code.
>
> [1] https://developer.arm.com/documentation/den0144/latest
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> drivers/acpi/arm64/mpam.c | 2 ++
> drivers/resctrl/mpam_devices.c | 46 +++++++++++++++++++++++++++++++---
> 2 files changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
> index 99c2bdbb3314..edb4d10e8dc3 100644
> --- a/drivers/acpi/arm64/mpam.c
> +++ b/drivers/acpi/arm64/mpam.c
> @@ -341,6 +341,8 @@ static struct platform_device * __init acpi_mpam_parse_msc(struct acpi_mpam_msc_
> } else if (iface == MPAM_IFACE_PCC) {
> props[next_prop++] = PROPERTY_ENTRY_U32("pcc-channel",
> tbl_msc->base_address);
> + props[next_prop++] = PROPERTY_ENTRY_U32("msc-id",
> + tbl_msc->identifier);
I may be looking at the wrong documents, but neither DEN0065 nor DEN0144 carry
any definitions of pcc-channel and msc-id for the device with HID
"“ARMHAA5C". Since "pcc-channel" is already merged, I think I am looking at
wrong documents, please point me to the right one.
--
Regards,
Sudeep
^ 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