* [PATCH V3] dmaengine: imx-sdma: Fix SPBA bus detection on multi-SPBA platforms
From: Shengjiu Wang @ 2026-04-20 10:08 UTC (permalink / raw)
To: vkoul, Frank.Li, s.hauer, kernel, festevam, dmaengine, imx,
linux-arm-kernel, linux-kernel
i.MX8M platforms have multiple SPBA buses under different AIPS buses.
The current code searches the entire device tree and returns the first
SPBA bus found, which may not be under the same AIPS bus as the SDMA
controller.
This breaks SDMA P2P transfers because the SDMA script needs to know
if peripherals are on SPBA or AIPS to configure watermark levels
correctly. Using the wrong SPBA bus causes DMA timeouts and transfer
failures.
Fix by searching for the SPBA bus under the SDMA's parent node (AIPS)
first, then falling back to a global search for backward compatibility.
Example device tree showing the issue:
aips1 {
spba1 { sai@...; }; /* Correct SPBA for sdma1 */
sdma1@...;
};
aips2 {
spba2 { uart@...; }; /* Wrong SPBA - found first by old code */
};
Fixes: 8391ecf465ec ("dmaengine: imx-sdma: Add device to device support")
Cc: stable@vger.kernel.org
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
changs in v3:
- add fallback to a global search for backward compatibility, which is
to address comments from sashiko.dev
- update commit subject and commit message
- add comments in code.
- add Cc stable tag
- Don't add Frank's RB on v2 as there are several other changes.
changes in v2:
- add fixes tag
- use __free(device_node) for auto release.
drivers/dma/imx-sdma.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 3d527883776b..592705af2319 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -2364,7 +2364,18 @@ static int sdma_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, ret,
"failed to register controller\n");
- spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
+ /*
+ * On i.MX8M platforms with multiple SPBA buses, we need to find
+ * the SPBA bus that's under the same AIPS bus as this SDMA controller.
+ * First check the SDMA's parent (AIPS bus) for a child SPBA bus.
+ * If not found, fall back to searching the entire device tree for
+ * backward compatibility with older platforms.
+ */
+ struct device_node *sdma_parent_np __free(device_node) = of_get_parent(np);
+
+ spba_bus = of_get_compatible_child(sdma_parent_np, "fsl,spba-bus");
+ if (!spba_bus)
+ spba_bus = of_find_compatible_node(NULL, NULL, "fsl,spba-bus");
ret = of_address_to_resource(spba_bus, 0, &spba_res);
if (!ret) {
sdma->spba_start_addr = spba_res.start;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: mani @ 2026-04-20 9:35 UTC (permalink / raw)
To: Sherry Sun
Cc: Bjorn Helgaas, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114304913B6AACF6A206E10922F2@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Mon, Apr 20, 2026 at 08:24:57AM +0000, Sherry Sun wrote:
[...]
> > Even if there are PERST# GPIOs from the host, connected to downstream
> > ports of a PCIe switch, they could be stored in the Root Port's (pci_host_port)
> > struct as a list of PERST#. This is what pcie-qcom driver does.
> >
> > It is too clumsy to handle PERST# individually for each device. We tried it
> > before with pwrctrl, but it always ended up biting us on who gets to control
> > the PERST#. We can't let pwrctrl handle PERST# for a switch port and host
> > controller driver handle it for RP. And we cannot let pwrctrl handle PERST# for
> > all ports, because, host controller drivers also need to control them for RC
> > initialization.
> >
> > That's why it was decided to handle PERST# for all ports in the host controller
> > drivers. So following that pattern, this helper could also be extended to parse
> > the PERST# from all ports defined in DT and store them in the same Root Port
> > struct.
> >
> > It should be trivial to implement this logic in the current helper. @Sherry:
> > Could you please implement this logic?
>
> Hi Mani, do you mean the similar logic in this patch?
> https://lore.kernel.org/all/20251216-pci-pwrctrl-rework-v2-1-745a563b9be6@oss.qualcomm.com/
> If yes, of cause I can do this for current helper functions in pci-host-common.c.
>
Yes!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* RE: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-20 8:24 UTC (permalink / raw)
To: mani@kernel.org, Bjorn Helgaas
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <viggqsxczf5d5hok4qpqhknalwb46xapsgdxbbgbqhruhyn2hn@wtck4yajmuw7>
> On Fri, Apr 17, 2026 at 02:55:33PM -0500, Bjorn Helgaas wrote:
> > On Fri, Apr 17, 2026 at 03:17:16AM +0000, Sherry Sun wrote:
> > > > On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > > > > Introduce generic helper functions to parse Root Port device
> > > > > tree nodes and extract common properties like reset GPIOs. This
> > > > > allows multiple PCI host controller drivers to share the same
> > > > > parsing logic.
> > > > >
> > > > > Define struct pci_host_port to hold common Root Port properties
> > > > > (currently only reset GPIO descriptor) and add
> > > > > pci_host_common_parse_ports() to parse Root Port nodes from
> > > > > device tree.
> > > >
> > > > Are the Root Port and the RC the only possible places for 'reset'
> > > > GPIO descriptions in DT? I think PERST# routing is outside the
> > > > PCIe spec, so it seems like a system could provide a PERST# GPIO
> > > > routed to any Switch Upstream Port or Endpoint (I assume a PERST#
> > > > connected to a switch would apply to both the upstream port and
> > > > the downstream ports).
> > >
> > > Thanks for the feedback. You're right that PERST# routing could
> > > theoretically be connected to any device in the hierarchy. However,
> > > for this patch series, I've focused on the most common use case in
> > > practice: use Root Port level PERST# instead of the legacy Root
> > > Complex level PERST#.
> > >
> > > Root Port level PERST# - This is the primary target, where each Root
> > > Port has individual control over devices connected to it. RC level
> > > PERST# - Legacy binding support, where a single GPIO controls all
> > > ports.
> > >
> > > We can extend this framework later if real hardware emerges that
> > > needs Switch or EP-level PERST# control. I can add a comment
> > > documenting this limitation if needed.
> > >
> > > BTW, Mani and Rob had some great discussions in dt-schema about
> > > PERST# and WAKE# sideband signals settings.
> >
> > > You can check here:
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Fdevicetree-org%2Fdt-
> schema%2Fissues%2F168&data=05%7C02%7C
> > >
> sherry.sun%40nxp.com%7C232644f8bbe64279f77908de9ea20b09%7C686ea1
> d3bc
> > >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C639122615977862858%7CUnknown
> %7CTWFp
> > >
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIs
> > >
> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=r7szCLCsGFN2
> 1ULZ
> > > ibH7Ga%2FH0e6VyIdqznKCJ6yIGM4%3D&reserved=0
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Fdevicetree-org%2Fdt-
> schema%2Fpull%2F126&data=05%7C02%7Csh
> > >
> erry.sun%40nxp.com%7C232644f8bbe64279f77908de9ea20b09%7C686ea1d
> 3bc2b
> > >
> 4c6fa92cd99c5c301635%7C0%7C0%7C639122615977892044%7CUnknown%7
> CTWFpbG
> > >
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIk
> > >
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=o3RIy1SfvTGfkX
> 9rm8
> > > dNH2or5SZ7v5bYF%2Fl1XGaf8aA%3D&reserved=0
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Fdevicetree-org%2Fdt-
> schema%2Fpull%2F170&data=05%7C02%7Csh
> > >
> erry.sun%40nxp.com%7C232644f8bbe64279f77908de9ea20b09%7C686ea1d
> 3bc2b
> > >
> 4c6fa92cd99c5c301635%7C0%7C0%7C639122615977910169%7CUnknown%7
> CTWFpbG
> > >
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI
> sIk
> > >
> FOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=d8SBGcqKcjYe1i
> iqs9
> > > %2F%2Bg1o%2FbECHYtnEULg7hTXyKmY%3D&reserved=0
> >
> > The upshot of all those conversations is that WAKE# and PERST# can be
> > routed to arbitrary devices independent of the PCI topology.
> >
> > I think extending host-generic to look for 'reset' in Root Port nodes
> > is the right thing. My concern is more about where we store it. This
> > patch saves it in a new "pci_host_port" struct, but someday we'll want
> > a place to save the PERST# GPIOs for several slots behind a switch.
> > Then we'll have two different ways to save the same information.
> >
>
> Even if there are PERST# GPIOs from the host, connected to downstream
> ports of a PCIe switch, they could be stored in the Root Port's (pci_host_port)
> struct as a list of PERST#. This is what pcie-qcom driver does.
>
> It is too clumsy to handle PERST# individually for each device. We tried it
> before with pwrctrl, but it always ended up biting us on who gets to control
> the PERST#. We can't let pwrctrl handle PERST# for a switch port and host
> controller driver handle it for RP. And we cannot let pwrctrl handle PERST# for
> all ports, because, host controller drivers also need to control them for RC
> initialization.
>
> That's why it was decided to handle PERST# for all ports in the host controller
> drivers. So following that pattern, this helper could also be extended to parse
> the PERST# from all ports defined in DT and store them in the same Root Port
> struct.
>
> It should be trivial to implement this logic in the current helper. @Sherry:
> Could you please implement this logic?
Hi Mani, do you mean the similar logic in this patch?
https://lore.kernel.org/all/20251216-pci-pwrctrl-rework-v2-1-745a563b9be6@oss.qualcomm.com/
If yes, of cause I can do this for current helper functions in pci-host-common.c.
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH] drm/bridge: imx8qxp-pxl2dpi: avoid of_node_put() on ERR_PTR()
From: Liu Ying @ 2026-04-20 6:53 UTC (permalink / raw)
To: Guangshuo Li, Frank Li
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Luca Ceresoli, dri-devel,
imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <CANUHTR8FaXLX+Nbeb7+sWRF9jQ5SoBgWc2y_LVD38KE7TqsxeQ@mail.gmail.com>
On Mon, Apr 20, 2026 at 10:19:35AM +0800, Guangshuo Li wrote:
> [You don't often get email from lgs201920130244@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Frank,
>
> Thanks for the review.
>
> On Mon, 20 Apr 2026 at 09:56, Frank Li <Frank.li@nxp.com> wrote:
>>
>>
>> Please fix
>> DEFINE_FREE(device_node, struct device_node *, if (_T) of_node_put(_T))
>>
>> If (!IS_ERR(_T))
>>
>
> You're right, fixing DEFINE_FREE(device_node, ...) is the proper way
> to handle this:
> if (_T && !IS_ERR(_T)) of_node_put(_T)
This would be intrusive because it effectively changes the cleanup action.
A similar case[1] was handled by ensuring only NULL pointer was returned
on error. And, this is actually what i2c_of_probe_get_i2c_node()[2] does
now.
[1] https://lore.kernel.org/all/Zw-VkQ3di5nFHiXB@smile.fi.intel.com/
[2] https://elixir.bootlin.com/linux/v7.0/source/drivers/i2c/i2c-core-of-prober.c#L38-L58
BTW, even if the cleanup action needs to be changed, the 'if' condition
should be '!IS_ERR_OR_NULL(_T)'.
>
> This is a better fix than handling it only in this driver.
>
> I'll rework the patch based on your suggestion and send v2 later.
>
> Thanks,
> Guangshuo
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: mani @ 2026-04-20 5:59 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Sherry Sun, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260417195533.GA92707@bhelgaas>
On Fri, Apr 17, 2026 at 02:55:33PM -0500, Bjorn Helgaas wrote:
> On Fri, Apr 17, 2026 at 03:17:16AM +0000, Sherry Sun wrote:
> > > On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > > > Introduce generic helper functions to parse Root Port device
> > > > tree nodes and extract common properties like reset GPIOs. This
> > > > allows multiple PCI host controller drivers to share the same
> > > > parsing logic.
> > > >
> > > > Define struct pci_host_port to hold common Root Port properties
> > > > (currently only reset GPIO descriptor) and add
> > > > pci_host_common_parse_ports() to parse Root Port nodes from
> > > > device tree.
> > >
> > > Are the Root Port and the RC the only possible places for 'reset'
> > > GPIO descriptions in DT? I think PERST# routing is outside the
> > > PCIe spec, so it seems like a system could provide a PERST# GPIO
> > > routed to any Switch Upstream Port or Endpoint (I assume a PERST#
> > > connected to a switch would apply to both the upstream port and
> > > the downstream ports).
> >
> > Thanks for the feedback. You're right that PERST# routing could
> > theoretically be connected to any device in the hierarchy. However,
> > for this patch series, I've focused on the most common use case in
> > practice: use Root Port level PERST# instead of the legacy Root
> > Complex level PERST#.
> >
> > Root Port level PERST# - This is the primary target, where each Root
> > Port has individual control over devices connected to it. RC level
> > PERST# - Legacy binding support, where a single GPIO controls all
> > ports.
> >
> > We can extend this framework later if real hardware emerges that
> > needs Switch or EP-level PERST# control. I can add a comment
> > documenting this limitation if needed.
> >
> > BTW, Mani and Rob had some great discussions in dt-schema about
> > PERST# and WAKE# sideband signals settings.
>
> > You can check here:
> > https://github.com/devicetree-org/dt-schema/issues/168
> > https://github.com/devicetree-org/dt-schema/pull/126
> > https://github.com/devicetree-org/dt-schema/pull/170
>
> The upshot of all those conversations is that WAKE# and PERST# can be
> routed to arbitrary devices independent of the PCI topology.
>
> I think extending host-generic to look for 'reset' in Root Port nodes
> is the right thing. My concern is more about where we store it. This
> patch saves it in a new "pci_host_port" struct, but someday we'll want
> a place to save the PERST# GPIOs for several slots behind a switch.
> Then we'll have two different ways to save the same information.
>
Even if there are PERST# GPIOs from the host, connected to downstream ports of a
PCIe switch, they could be stored in the Root Port's (pci_host_port) struct as a
list of PERST#. This is what pcie-qcom driver does.
It is too clumsy to handle PERST# individually for each device. We tried it
before with pwrctrl, but it always ended up biting us on who gets to control the
PERST#. We can't let pwrctrl handle PERST# for a switch port and host controller
driver handle it for RP. And we cannot let pwrctrl handle PERST# for all ports,
because, host controller drivers also need to control them for RC
initialization.
That's why it was decided to handle PERST# for all ports in the host controller
drivers. So following that pattern, this helper could also be extended to parse
the PERST# from all ports defined in DT and store them in the same Root Port
struct.
It should be trivial to implement this logic in the current helper. @Sherry:
Could you please implement this logic?
> WAKE# signals might be more pertinent -- we definitely need to support
> multiple WAKE# signals below a single Root Port, and it seems like
> PERST# and WAKE# GPIOs should be saved the same place.
>
> I'm wondering if both should go in the pci_dev itself. I guess the
> implication is that a pci_dev->reset GPIO would describe a PERST#
> connected to the device *below* the pci_dev, at least for Downstream
> Ports.
>
Problem is, PERST# needs to be controlled even before 'pci_dev' gets created. We
create 'pci_dev' only when a device get's detected. But the PERST# assertion and
deassertion happens even before the pci_host_probe() call, which is the starting
point for enumeration. That's why storing it as a list in 'pci_host_bridge'
makes it accessible by the host controller drivers.
> I don't know about WAKE# signals. When it's in a connector, there's
> probably only a single possible WAKE# per Downstream Port. But is it
> possible have multiple WAKE# signals from a multi-function device
> that's on the motherboard? Saving the WAKE# GPIO in the Downstream
> Port wouldn't accommodate that case.
AFAIK, a single device can have only one WAKE# irrespective of how many function
it exposes. PCIe base spec doesn't indicate whether it is per-device or
per-function, but the form factor specfications like CEM, Mini-CEM define it as
a per-device signal.
Moreover, unlike PERST#, WAKE# is not driven by the host system. Host just needs
to register an IRQ handler to service the interrupts raised by the device. So it
can be parsed *after* enumerating a device and stored in 'pci_dev' as done in
Krishna's series:
https://lore.kernel.org/linux-pci/20260403-wakeirq_support-v9-0-1cbecf3b58d7@oss.qualcomm.com/
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 2/5] media: synopsys: Add support for multiple streams
From: Frank Li @ 2026-04-20 5:42 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-2-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:53AM +0800, Guoniu Zhou wrote:
> The current driver only supports single stream operation. Add support
> for multiple concurrent streams by tracking enabled streams with a
> bitmask and only initializing the hardware once for the first stream.
>
> This enables use cases such as surround view systems where multiple
> camera streams need to be processed simultaneously through the same
> CSI-2 receiver interface.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 45 ++++++++++++++----------
> 1 file changed, 27 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> index 46e2a4315ac2..85a2a95bf080 100644
> --- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> +++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> @@ -113,6 +113,7 @@ struct dw_mipi_csi2rx_device {
>
> enum v4l2_mbus_type bus_type;
> u32 lanes_num;
> + u64 enabled_streams;
>
> const struct dw_mipi_csi2rx_drvdata *drvdata;
> };
> @@ -528,28 +529,31 @@ static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
> DW_MIPI_CSI2RX_PAD_SRC,
> &streams_mask);
>
It maybe simpler
u64 enabled_streams = csi2->enabled_streams;
csi2->enabled_streams |= streams_mask;
if (!enabled_stream)
return 0;
....
err:
si2->enabled_streams &= ~streams_mask;
Frank
> - ret = pm_runtime_resume_and_get(dev);
> - if (ret)
> - goto err;
> + if (!csi2->enabled_streams) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
>
> - ret = dw_mipi_csi2rx_start(csi2);
> - if (ret) {
> - dev_err(dev, "failed to enable CSI hardware\n");
> - goto err_pm_runtime_put;
> + ret = dw_mipi_csi2rx_start(csi2);
> + if (ret) {
> + pm_runtime_put(dev);
> + dev_err(dev, "failed to enable CSI hardware\n");
> + return ret;
> + }
> }
>
> ret = v4l2_subdev_enable_streams(remote_sd, remote_pad->index, mask);
> - if (ret)
> - goto err_csi_stop;
> + if (ret) {
> + if (!csi2->enabled_streams) {
> + dw_mipi_csi2rx_stop(csi2);
> + pm_runtime_put(dev);
> + }
> + return ret;
> + }
>
> - return 0;
> + csi2->enabled_streams |= streams_mask;
>
> -err_csi_stop:
> - dw_mipi_csi2rx_stop(csi2);
> -err_pm_runtime_put:
> - pm_runtime_put(dev);
> -err:
> - return ret;
> + return 0;
> }
>
> static int dw_mipi_csi2rx_disable_streams(struct v4l2_subdev *sd,
> @@ -572,10 +576,15 @@ static int dw_mipi_csi2rx_disable_streams(struct v4l2_subdev *sd,
> &streams_mask);
>
> ret = v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
> + if (ret)
> + dev_err(dev, "failed to disable streams on remote subdev: %d\n", ret);
>
> - dw_mipi_csi2rx_stop(csi2);
> + csi2->enabled_streams &= ~streams_mask;
>
> - pm_runtime_put(dev);
> + if (!csi2->enabled_streams) {
> + dw_mipi_csi2rx_stop(csi2);
> + pm_runtime_put(dev);
> + }
>
> return ret;
> }
>
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH] usb: typec: tcpm: fix debug accessory mode detection for sink ports
From: Xu Yang @ 2026-04-20 3:03 UTC (permalink / raw)
To: badhri, heikki.krogerus, gregkh, m.grzeschik
Cc: linux-usb, linux-kernel, imx, jun.li
The port in debug accessory mode can be either a source or sink. The
previous tcpm_port_is_debug() function only checked for source port.
Commit 8db73e6a42b6 ("usb: typec: tcpm: allow sink (ufp) to toggle into
accessory mode debug") changed the detection logic to support both roles,
but left some logic in _tcpm_cc_change() unchanged, This causes the state
machine to transition to an incorrect state when operating as a sink in
debug accessory mode. Log as below:
[ 978.637541] CC1: 0 -> 5, CC2: 0 -> 5 [state TOGGLING, polarity 0, connected]
[ 978.637567] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS]
[ 978.637596] pending state change SRC_ATTACH_WAIT -> DEBUG_ACC_ATTACHED @ 180 ms [rev1 NONE_AMS]
[ 978.647098] CC1: 5 -> 0, CC2: 5 -> 5 [state SRC_ATTACH_WAIT, polarity 0, connected]
[ 978.647115] state change SRC_ATTACH_WAIT -> SRC_ATTACH_WAIT [rev1 NONE_AMS]
It should go to SNK_ATTACH_WAIT instead of SRC_ATTACH_WAIT state.
To fix this, add tcpm_port_is_debug_source() and tcpm_port_is_debug_sink()
helper to explicitly identify the power mode in debug accessory mode.
Update the state transition logic in _tcpm_cc_change() to ensure the state
machine transitions comply with Type-C specification.
Fixes: 8db73e6a42b6 ("usb: typec: tcpm: allow sink (ufp) to toggle into accessory mode debug")
Cc: stable@vger.kernel.org
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
drivers/usb/typec/tcpm/tcpm.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index dfbb94ddc98a..1ee00025de56 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -732,9 +732,14 @@ static const char * const pd_rev[] = {
(tcpm_cc_is_source((port)->cc2) && \
!tcpm_cc_is_source((port)->cc1)))
+#define tcpm_port_is_debug_source(port) \
+ (tcpm_cc_is_source((port)->cc1) && tcpm_cc_is_source((port)->cc2))
+
+#define tcpm_port_is_debug_sink(port) \
+ (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2))
+
#define tcpm_port_is_debug(port) \
- ((tcpm_cc_is_source((port)->cc1) && tcpm_cc_is_source((port)->cc2)) || \
- (tcpm_cc_is_sink((port)->cc1) && tcpm_cc_is_sink((port)->cc2)))
+ (tcpm_port_is_debug_source(port) || tcpm_port_is_debug_sink(port))
#define tcpm_port_is_audio(port) \
(tcpm_cc_is_audio((port)->cc1) && tcpm_cc_is_audio((port)->cc2))
@@ -6360,10 +6365,10 @@ static void _tcpm_cc_change(struct tcpm_port *port, enum typec_cc_status cc1,
switch (port->state) {
case TOGGLING:
- if (tcpm_port_is_debug(port) || tcpm_port_is_audio(port) ||
+ if (tcpm_port_is_debug_source(port) || tcpm_port_is_audio(port) ||
tcpm_port_is_source(port))
tcpm_set_state(port, SRC_ATTACH_WAIT, 0);
- else if (tcpm_port_is_sink(port))
+ else if (tcpm_port_is_debug_sink(port) || tcpm_port_is_sink(port))
tcpm_set_state(port, SNK_ATTACH_WAIT, 0);
break;
case CHECK_CONTAMINANT:
@@ -6371,9 +6376,11 @@ static void _tcpm_cc_change(struct tcpm_port *port, enum typec_cc_status cc1,
break;
case SRC_UNATTACHED:
case ACC_UNATTACHED:
- if (tcpm_port_is_debug(port) || tcpm_port_is_audio(port) ||
+ if (tcpm_port_is_debug_source(port) || tcpm_port_is_audio(port) ||
tcpm_port_is_source(port))
tcpm_set_state(port, SRC_ATTACH_WAIT, 0);
+ else if (tcpm_port_is_debug_sink(port))
+ tcpm_set_state(port, SNK_ATTACH_WAIT, 0);
break;
case SRC_ATTACH_WAIT:
if (tcpm_port_is_disconnected(port) ||
@@ -6395,7 +6402,7 @@ static void _tcpm_cc_change(struct tcpm_port *port, enum typec_cc_status cc1,
}
break;
case SNK_UNATTACHED:
- if (tcpm_port_is_debug(port) || tcpm_port_is_audio(port) ||
+ if (tcpm_port_is_debug_sink(port) || tcpm_port_is_audio(port) ||
tcpm_port_is_sink(port))
tcpm_set_state(port, SNK_ATTACH_WAIT, 0);
break;
--
2.34.1
^ permalink raw reply related
* RE: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-20 2:59 UTC (permalink / raw)
To: Bjorn Helgaas, mani@kernel.org
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260417195533.GA92707@bhelgaas>
> On Fri, Apr 17, 2026 at 03:17:16AM +0000, Sherry Sun wrote:
> > > On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > > > Introduce generic helper functions to parse Root Port device tree
> > > > nodes and extract common properties like reset GPIOs. This allows
> > > > multiple PCI host controller drivers to share the same parsing
> > > > logic.
> > > >
> > > > Define struct pci_host_port to hold common Root Port properties
> > > > (currently only reset GPIO descriptor) and add
> > > > pci_host_common_parse_ports() to parse Root Port nodes from device
> > > > tree.
> > >
> > > Are the Root Port and the RC the only possible places for 'reset'
> > > GPIO descriptions in DT? I think PERST# routing is outside the PCIe
> > > spec, so it seems like a system could provide a PERST# GPIO routed
> > > to any Switch Upstream Port or Endpoint (I assume a PERST# connected
> > > to a switch would apply to both the upstream port and the downstream
> > > ports).
> >
> > Thanks for the feedback. You're right that PERST# routing could
> > theoretically be connected to any device in the hierarchy. However,
> > for this patch series, I've focused on the most common use case in
> > practice: use Root Port level PERST# instead of the legacy Root
> > Complex level PERST#.
> >
> > Root Port level PERST# - This is the primary target, where each Root
> > Port has individual control over devices connected to it. RC level
> > PERST# - Legacy binding support, where a single GPIO controls all
> > ports.
> >
> > We can extend this framework later if real hardware emerges that needs
> > Switch or EP-level PERST# control. I can add a comment documenting
> > this limitation if needed.
> >
> > BTW, Mani and Rob had some great discussions in dt-schema about PERST#
> > and WAKE# sideband signals settings.
>
> > You can check here:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fdevicetree-org%2Fdt-
> schema%2Fissues%2F168&data=05%7C02%7Csher
> >
> ry.sun%40nxp.com%7Cd68515fdc0f842ac82d708de9cbb4b2e%7C686ea1d3bc
> 2b4c6f
> >
> a92cd99c5c301635%7C0%7C0%7C639120525411363026%7CUnknown%7CTW
> FpbGZsb3d8
> >
> eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj
> oiTW
> >
> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ISzWCMSwqYBdw5w%2
> BDB5ERK51Dr
> > Tf2jzGtGh3wKNCMZ8%3D&reserved=0
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fdevicetree-org%2Fdt-
> schema%2Fpull%2F126&data=05%7C02%7Csherry
> > .sun%40nxp.com%7Cd68515fdc0f842ac82d708de9cbb4b2e%7C686ea1d3bc
> 2b4c6fa9
> >
> 2cd99c5c301635%7C0%7C0%7C639120525411380537%7CUnknown%7CTWFp
> bGZsb3d8ey
> >
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
> WFp
> >
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5cohkQIgl0CDlrOmD0dDIbj
> Q3%2BVg
> > VOhiOMDRQD1iwLM%3D&reserved=0
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fdevicetree-org%2Fdt-
> schema%2Fpull%2F170&data=05%7C02%7Csherry
> > .sun%40nxp.com%7Cd68515fdc0f842ac82d708de9cbb4b2e%7C686ea1d3bc
> 2b4c6fa9
> >
> 2cd99c5c301635%7C0%7C0%7C639120525411391138%7CUnknown%7CTWFp
> bGZsb3d8ey
> >
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
> WFp
> >
> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WtjyGdvt4s84HynGc3%2F0
> K3UfkZii
> > naNAW1ypEd%2B11RY%3D&reserved=0
>
> The upshot of all those conversations is that WAKE# and PERST# can be
> routed to arbitrary devices independent of the PCI topology.
>
> I think extending host-generic to look for 'reset' in Root Port nodes is the right
> thing. My concern is more about where we store it. This patch saves it in a
> new "pci_host_port" struct, but someday we'll want a place to save the
> PERST# GPIOs for several slots behind a switch.
> Then we'll have two different ways to save the same information.
>
> WAKE# signals might be more pertinent -- we definitely need to support
> multiple WAKE# signals below a single Root Port, and it seems like PERST#
> and WAKE# GPIOs should be saved the same place.
>
> I'm wondering if both should go in the pci_dev itself. I guess the implication
> is that a pci_dev->reset GPIO would describe a PERST# connected to the
> device *below* the pci_dev, at least for Downstream Ports.
Hi Bjorn,
Ok, understand your concern, currently I've defined the struct pci_host_port to
store the common Root Port properties and added the list of 'ports' to struct
pci_host_bridge.
I will let @mani to comment and see if this is the appropriate place to store
these info, or if we should store them in struct pci_dev. Mani, can you please help?
But for now, the motivation for this patch is that many PCI host controller drivers
currently share the same requirement: extracting common Root Port properties like
reset GPIOs (at least currently in many drivers, perst is placed in the root port). We
introduce generic helper functions to parse the Root Port t device tree nodes and extract
these properties so that multiple PCI drivers can share the same parsing logic. I'm not
sure if we should take a step forward here anyway?
Best Regards
Sherry
>
> I don't know about WAKE# signals. When it's in a connector, there's probably
> only a single possible WAKE# per Downstream Port. But is it possible have
> multiple WAKE# signals from a multi-function device that's on the
> motherboard? Saving the WAKE# GPIO in the Downstream Port wouldn't
> accommodate that case.
^ permalink raw reply
* RE: [EXT] Re: [PATCH v2] pmdomain: imx: Make IMX8M/IMX9 BLK_CTRL tristate
From: Zhipeng Wang @ 2026-04-20 2:26 UTC (permalink / raw)
To: Daniel Baluta (OSS), Marco Felsch
Cc: ulfh@kernel.org, Frank Li, s.hauer@pengutronix.de,
imx@lists.linux.dev, linux-pm@vger.kernel.org, Xuegang Liu,
Jindong Yue, linux-kernel@vger.kernel.org, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <d44a60ff-c8a3-4347-9199-def61e855066@oss.nxp.com>
> -----Original Message-----
> From: Daniel Baluta (OSS) <daniel.baluta@oss.nxp.com>
> Sent: 2026年4月16日 14:04
> To: Zhipeng Wang <zhipeng.wang_1@nxp.com>; Marco Felsch
> <m.felsch@pengutronix.de>
> Cc: ulfh@kernel.org; Frank Li <frank.li@nxp.com>; s.hauer@pengutronix.de;
> imx@lists.linux.dev; linux-pm@vger.kernel.org; Xuegang Liu
> <xuegang.liu@nxp.com>; Jindong Yue <jindong.yue@nxp.com>;
> linux-kernel@vger.kernel.org; kernel@pengutronix.de; festevam@gmail.com;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [EXT] Re: [PATCH v2] pmdomain: imx: Make IMX8M/IMX9
> BLK_CTRL tristate
>
> On 4/14/26 04:59, Zhipeng Wang wrote:
> > > On 26-04-13, Zhipeng Wang wrote:
> >>> Convert IMX8M_BLK_CTRL and IMX9_BLK_CTRL from bool to tristate to
> >>> allow building as loadable modules.
> >> Out of curiosity, why do you want to have a PM driver to be buildable
> >> as module?
> >>
> >> Regards,
> >> Marco
> >>
> > Hi Marco,
> >
> > Thank you for your question.
> >
> > The primary motivation is to support Google's GKI (Generic Kernel
> > Image) requirement for Android devices.
> >
> > GKI separates the kernel into two parts:
> > 1. A unified kernel image (GKI) that is common across all Android
> > devices 2. Vendor-specific drivers that must be built as loadable
> > modules
> >
> > Under the GKI architecture, SoC-specific drivers like IMX8M/IMX9
> > BLK_CTRL cannot be built into the core kernel image. Instead, they
> > must be loadable modules that vendors can ship separately. This allows:
> >
> > - A single kernel binary to support multiple hardware platforms
> > - Vendors to update their drivers independently without rebuilding the
> > entire kernel
> > - Better compliance with Android's kernel update and security policies
> >
> Can you please add the below line in the commit message?
Hi Daniel,
Thank you! V4 sent.
BRs,
Zhipeng
> > For i.MX8M/i.MX9 devices running Android with GKI kernels, the
> > BLK_CTRL drivers need to be loaded as modules during boot. Without
> > tristate support, these devices cannot properly initialize their power
> > domains, making them non-functional under GKI.
>
^ permalink raw reply
* [PATCH v4] pmdomain: imx: Make IMX8M/IMX9 BLK_CTRL tristate
From: Zhipeng Wang @ 2026-04-20 2:22 UTC (permalink / raw)
To: ulfh, Frank.Li, s.hauer
Cc: kernel, festevam, linux-pm, imx, linux-arm-kernel, linux-kernel,
xuegang.liu, jindong.yue
Convert IMX8M_BLK_CTRL and IMX9_BLK_CTRL from bool to tristate
to allow building as loadable modules.
This change is required to support Android devices using Generic Kernel
Image (GKI) kernels, where SoC-specific drivers must be built as loadable
modules rather than built into the core kernel image.
For i.MX8M and i.MX9 devices running Android with GKI kernels, the
BLK_CTRL drivers therefore need to be loadable. Without tristate
support, power domains cannot be initialized correctly, making these
systems non-functional under GKI.
Add prompt strings to make these options visible and configurable
in menuconfig, keeping them enabled by default on appropriate platforms.
Also remove the IMX_GPCV2_PM_DOMAINS dependency from IMX9_BLK_CTRL.
This dependency was incorrect from the beginning because i.MX93 uses a
different power domain architecture compared to i.MX8M series:
- i.MX8M uses GPCv2 (General Power Controller v2) for power domain
management, hence IMX8M_BLK_CTRL correctly depends on it.
- i.MX93 uses BLK_CTRL directly without GPCv2. The hardware doesn't
have GPCv2 at all.
Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v4:
- No functional changes
- Added detailed explanation about GKI (Generic Kernel Image) requirement
in the commit message to clarify why tristate support is needed for
Android devices
Changes in v3:
- No functional changes
- Fixed typo reported by Frank
- Added Reviewed-by tag from Frank Li
Changes in v2:
- No functional changes
- Expanded commit message to explain the architectural differences between
i.MX8M and i.MX93 power domain management
- Clarified why IMX_GPCV2_PM_DOMAINS dependency removal is correct for
i.MX93
---
drivers/pmdomain/imx/Kconfig | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/pmdomain/imx/Kconfig b/drivers/pmdomain/imx/Kconfig
index 00203615c65e..9168d183b0c5 100644
--- a/drivers/pmdomain/imx/Kconfig
+++ b/drivers/pmdomain/imx/Kconfig
@@ -10,15 +10,18 @@ config IMX_GPCV2_PM_DOMAINS
default y if SOC_IMX7D
config IMX8M_BLK_CTRL
- bool
- default SOC_IMX8M && IMX_GPCV2_PM_DOMAINS
+ tristate "i.MX8M BLK CTRL driver"
+ depends on SOC_IMX8M
+ depends on IMX_GPCV2_PM_DOMAINS
depends on PM_GENERIC_DOMAINS
depends on COMMON_CLK
+ default y
config IMX9_BLK_CTRL
- bool
- default SOC_IMX9 && IMX_GPCV2_PM_DOMAINS
+ tristate "i.MX93 BLK CTRL driver"
+ depends on SOC_IMX9
depends on PM_GENERIC_DOMAINS
+ default y
config IMX_SCU_PD
bool "IMX SCU Power Domain driver"
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] drm/bridge: imx8qxp-pxl2dpi: avoid of_node_put() on ERR_PTR()
From: Guangshuo Li @ 2026-04-20 2:19 UTC (permalink / raw)
To: Frank Li
Cc: Liu Ying, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Luca Ceresoli, dri-devel, imx, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <aeWHyhp43ZbgXwFe@lizhi-Precision-Tower-5810>
Hi Frank,
Thanks for the review.
On Mon, 20 Apr 2026 at 09:56, Frank Li <Frank.li@nxp.com> wrote:
>
>
> Please fix
> DEFINE_FREE(device_node, struct device_node *, if (_T) of_node_put(_T))
>
> If (!IS_ERR(_T))
>
You're right, fixing DEFINE_FREE(device_node, ...) is the proper way
to handle this:
if (_T && !IS_ERR(_T)) of_node_put(_T)
This is a better fix than handling it only in this driver.
I'll rework the patch based on your suggestion and send v2 later.
Thanks,
Guangshuo
^ permalink raw reply
* Re: [PATCH] Input: imx_keypad - Fix spelling mistake "Colums" -> "Columns"
From: Frank Li @ 2026-04-20 1:57 UTC (permalink / raw)
To: Ethan Carter Edwards
Cc: Dmitry Torokhov, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-input, imx, linux-arm-kernel, linux-kernel,
kernel-janitors
In-Reply-To: <20260418-imx-typo-v1-1-2a15e54ad4e7@ethancedwards.com>
On Sat, Apr 18, 2026 at 08:58:32PM -0400, Ethan Carter Edwards wrote:
> There is a spelling mistake in a two comments. Fix them.
>
> Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/input/keyboard/imx_keypad.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
> index 069c1d6376e1..ccde60cd6bb3 100644
> --- a/drivers/input/keyboard/imx_keypad.c
> +++ b/drivers/input/keyboard/imx_keypad.c
> @@ -324,7 +324,7 @@ static void imx_keypad_config(struct imx_keypad *keypad)
> reg_val |= (keypad->cols_en_mask & 0xff) << 8; /* cols */
> writew(reg_val, keypad->mmio_base + KPCR);
>
> - /* Write 0's to KPDR[15:8] (Colums) */
> + /* Write 0's to KPDR[15:8] (Columns) */
> reg_val = readw(keypad->mmio_base + KPDR);
> reg_val &= 0x00ff;
> writew(reg_val, keypad->mmio_base + KPDR);
> @@ -357,7 +357,7 @@ static void imx_keypad_inhibit(struct imx_keypad *keypad)
> reg_val |= KBD_STAT_KPKR | KBD_STAT_KPKD;
> writew(reg_val, keypad->mmio_base + KPSR);
>
> - /* Colums as open drain and disable all rows */
> + /* Columns as open drain and disable all rows */
> reg_val = (keypad->cols_en_mask & 0xff) << 8;
> writew(reg_val, keypad->mmio_base + KPCR);
> }
>
> ---
> base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
> change-id: 20260418-imx-typo-14370bd2ce47
>
> Best regards,
> --
> Ethan Carter Edwards <ethan@ethancedwards.com>
>
^ permalink raw reply
* Re: [PATCH] drm/bridge: imx8qxp-pxl2dpi: avoid of_node_put() on ERR_PTR()
From: Frank Li @ 2026-04-20 1:56 UTC (permalink / raw)
To: Guangshuo Li
Cc: Liu Ying, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Luca Ceresoli, dri-devel, imx, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <20260419122134.97529-1-lgs201920130244@gmail.com>
On Sun, Apr 19, 2026 at 08:21:34PM +0800, Guangshuo Li wrote:
> imx8qxp_pxl2dpi_get_available_ep_from_port() may return ERR_PTR(-ENODEV)
> or ERR_PTR(-EINVAL). imx8qxp_pxl2dpi_find_next_bridge() stores that
> value in a __free(device_node) variable and then immediately checks
> IS_ERR(ep).
>
> On the error path, returning from the function triggers the cleanup
> handler for __free(device_node). Since the device_node cleanup helper
> only checks for NULL before calling of_node_put(), this results in
> of_node_put(ERR_PTR(...)), which may lead to an invalid kobject_put()
Please fix
DEFINE_FREE(device_node, struct device_node *, if (_T) of_node_put(_T))
If (!IS_ERR(_T))
Frank
> dereference and crash the kernel.
>
> Fix it by avoiding __free(device_node) for the endpoint pointer and
> releasing it explicitly after obtaining the remote port parent.
>
> This issue was found by a custom static analysis tool.
>
> Fixes: ceea3f7806a10 ("drm/bridge: imx8qxp-pxl2dpi: simplify put of device_node pointers")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
> ---
> drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> index 441fd32dc91c..3610ca94a8e6 100644
> --- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> +++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
> @@ -264,12 +264,15 @@ imx8qxp_pxl2dpi_get_available_ep_from_port(struct imx8qxp_pxl2dpi *p2d,
>
> static int imx8qxp_pxl2dpi_find_next_bridge(struct imx8qxp_pxl2dpi *p2d)
> {
> - struct device_node *ep __free(device_node) =
> - imx8qxp_pxl2dpi_get_available_ep_from_port(p2d, 1);
> + struct device_node *ep;
> +
> + ep = imx8qxp_pxl2dpi_get_available_ep_from_port(p2d, 1);
> if (IS_ERR(ep))
> return PTR_ERR(ep);
>
> struct device_node *remote __free(device_node) = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> +
> if (!remote || !of_device_is_available(remote)) {
> DRM_DEV_ERROR(p2d->dev, "no available remote\n");
> return -ENODEV;
> --
> 2.43.0
>
^ permalink raw reply
* RE: [PATCH 2/5] media: synopsys: Add support for multiple streams
From: G.N. Zhou (OSS) @ 2026-04-20 1:51 UTC (permalink / raw)
To: Frank Li, G.N. Zhou (OSS)
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
In-Reply-To: <aeHxeCOn_Lo6XgzJ@lizhi-Precision-Tower-5810>
Hi Frank,
Thanks for your review.
> -----Original Message-----
> From: Frank Li <frank.li@nxp.com>
> Sent: Friday, April 17, 2026 4:38 PM
> To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> Cc: Michael Riesch <michael.riesch@collabora.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Heiko Stuebner
> <heiko@sntech.de>; Laurent Pinchart <laurent.pinchart@ideasonboard.com>;
> linux-media@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> kernel@lists.infradead.org; linux-rockchip@lists.infradead.org
> Subject: Re: [PATCH 2/5] media: synopsys: Add support for multiple streams
>
> On Wed, Apr 15, 2026 at 11:46:53AM +0800, Guoniu Zhou wrote:
> > The current driver only supports single stream operation. Add support
> > for multiple concurrent streams by tracking enabled streams with a
> > bitmask and only initializing the hardware once for the first stream.
> >
> > This enables use cases such as surround view systems where multiple
> > camera streams need to be processed simultaneously through the same
> > CSI-2 receiver interface.
>
> Look like this driver only one sink and one source pad, how to implement
> multiple stream.
Yes, you're correct that this driver has one sink pad and one source pad. The
multiple stream support is implemented using the V4L2 stream API, which
allows multiple logical streams to be multiplexed on a single pad.
In MIPI CSI-2, this corresponds to Virtual Channels (VC) and/or Data Types,
where multiple data streams can be transmitted over the same physical CSI-2
link. Each stream is identified by pad_index/stream_index (e.g., 0/0, 0/1, etc.).
>
> Frank
> >
> > Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> > ---
> > 2.34.1
> >
^ permalink raw reply
* [PATCH] drm/bridge: imx8qxp-pxl2dpi: avoid of_node_put() on ERR_PTR()
From: Guangshuo Li @ 2026-04-19 12:21 UTC (permalink / raw)
To: Liu Ying, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Luca Ceresoli, dri-devel, imx, linux-arm-kernel,
linux-kernel
Cc: Guangshuo Li, stable
imx8qxp_pxl2dpi_get_available_ep_from_port() may return ERR_PTR(-ENODEV)
or ERR_PTR(-EINVAL). imx8qxp_pxl2dpi_find_next_bridge() stores that
value in a __free(device_node) variable and then immediately checks
IS_ERR(ep).
On the error path, returning from the function triggers the cleanup
handler for __free(device_node). Since the device_node cleanup helper
only checks for NULL before calling of_node_put(), this results in
of_node_put(ERR_PTR(...)), which may lead to an invalid kobject_put()
dereference and crash the kernel.
Fix it by avoiding __free(device_node) for the endpoint pointer and
releasing it explicitly after obtaining the remote port parent.
This issue was found by a custom static analysis tool.
Fixes: ceea3f7806a10 ("drm/bridge: imx8qxp-pxl2dpi: simplify put of device_node pointers")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
index 441fd32dc91c..3610ca94a8e6 100644
--- a/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
+++ b/drivers/gpu/drm/bridge/imx/imx8qxp-pxl2dpi.c
@@ -264,12 +264,15 @@ imx8qxp_pxl2dpi_get_available_ep_from_port(struct imx8qxp_pxl2dpi *p2d,
static int imx8qxp_pxl2dpi_find_next_bridge(struct imx8qxp_pxl2dpi *p2d)
{
- struct device_node *ep __free(device_node) =
- imx8qxp_pxl2dpi_get_available_ep_from_port(p2d, 1);
+ struct device_node *ep;
+
+ ep = imx8qxp_pxl2dpi_get_available_ep_from_port(p2d, 1);
if (IS_ERR(ep))
return PTR_ERR(ep);
struct device_node *remote __free(device_node) = of_graph_get_remote_port_parent(ep);
+ of_node_put(ep);
+
if (!remote || !of_device_is_available(remote)) {
DRM_DEV_ERROR(p2d->dev, "no available remote\n");
return -ENODEV;
--
2.43.0
^ permalink raw reply related
* [PATCH] Input: imx_keypad - Fix spelling mistake "Colums" -> "Columns"
From: Ethan Carter Edwards @ 2026-04-19 0:58 UTC (permalink / raw)
To: Dmitry Torokhov, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: linux-input, imx, linux-arm-kernel, linux-kernel, kernel-janitors,
Ethan Carter Edwards
There is a spelling mistake in a two comments. Fix them.
Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com>
---
drivers/input/keyboard/imx_keypad.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/imx_keypad.c b/drivers/input/keyboard/imx_keypad.c
index 069c1d6376e1..ccde60cd6bb3 100644
--- a/drivers/input/keyboard/imx_keypad.c
+++ b/drivers/input/keyboard/imx_keypad.c
@@ -324,7 +324,7 @@ static void imx_keypad_config(struct imx_keypad *keypad)
reg_val |= (keypad->cols_en_mask & 0xff) << 8; /* cols */
writew(reg_val, keypad->mmio_base + KPCR);
- /* Write 0's to KPDR[15:8] (Colums) */
+ /* Write 0's to KPDR[15:8] (Columns) */
reg_val = readw(keypad->mmio_base + KPDR);
reg_val &= 0x00ff;
writew(reg_val, keypad->mmio_base + KPDR);
@@ -357,7 +357,7 @@ static void imx_keypad_inhibit(struct imx_keypad *keypad)
reg_val |= KBD_STAT_KPKR | KBD_STAT_KPKD;
writew(reg_val, keypad->mmio_base + KPSR);
- /* Colums as open drain and disable all rows */
+ /* Columns as open drain and disable all rows */
reg_val = (keypad->cols_en_mask & 0xff) << 8;
writew(reg_val, keypad->mmio_base + KPCR);
}
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20260418-imx-typo-14370bd2ce47
Best regards,
--
Ethan Carter Edwards <ethan@ethancedwards.com>
^ permalink raw reply related
* Re: [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Sebastian Krzyszkowiak @ 2026-04-18 1:12 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger, Robby Cai
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260417110200.753678-2-robby.cai@nxp.com>
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."
> 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>
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mq.dtsi index
> 6a25e219832c..165716d08e64 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -1377,7 +1377,7 @@ mipi_csi1: csi@30a70000 {
> assigned-clocks = <&clk
IMX8MQ_CLK_CSI1_CORE>,
> <&clk
IMX8MQ_CLK_CSI1_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI1_ESC>;
> - assigned-clock-rates =
<266000000>, <333000000>, <66000000>;
> + assigned-clock-rates =
<133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk
IMX8MQ_SYS1_PLL_266M>,
> <&clk
IMX8MQ_SYS2_PLL_1000M>,
> <&clk
IMX8MQ_SYS1_PLL_800M>;
> @@ -1429,7 +1429,7 @@ mipi_csi2: csi@30b60000 {
> assigned-clocks = <&clk
IMX8MQ_CLK_CSI2_CORE>,
> <&clk
IMX8MQ_CLK_CSI2_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI2_ESC>;
> - assigned-clock-rates =
<266000000>, <333000000>, <66000000>;
> + assigned-clock-rates =
<133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk
IMX8MQ_SYS1_PLL_266M>,
> <&clk
IMX8MQ_SYS2_PLL_1000M>,
> <&clk
IMX8MQ_SYS1_PLL_800M>;
^ permalink raw reply
* Re: [PATCH v6 3/3] dts: s32g: Add GPR syscon region
From: Jared Kangas @ 2026-04-17 21:36 UTC (permalink / raw)
To: Dan Carpenter
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
NXP S32 Linux Team, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, imx,
devicetree, linux-kernel, linaro-s32, netdev
In-Reply-To: <0e922537c02d1c47734142090f98eb78e921ed34.1769764941.git.dan.carpenter@linaro.org>
Hi Dan,
On Fri, Jan 30, 2026 at 04:19:52PM +0300, Dan Carpenter wrote:
> Add the GPR syscon region for the s32 chipset.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
>
> [snip]
>
> diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> index e314f3c7d61d..be03db737384 100644
> --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> @@ -383,6 +383,11 @@ usdhc0-200mhz-grp4 {
> };
> };
>
> + gpr: syscon@4007c000 {
> + compatible = "nxp,s32g3-gpr", "syscon";
> + reg = <0x4007c000 0x3000>;
> + };
> +
> ocotp: nvmem@400a4000 {
> compatible = "nxp,s32g3-ocotp", "nxp,s32g2-ocotp";
> reg = <0x400a4000 0x400>;
> @@ -808,6 +813,7 @@ gmac0: ethernet@4033c000 {
> compatible = "nxp,s32g2-dwmac";
> reg = <0x4033c000 0x2000>, /* gmac IP */
> <0x4007c004 0x4>; /* GMAC_0_CTRL_STS */
> + nxp,phy-sel = <&gpr 0x4>;
> interrupt-parent = <&gic>;
> interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "macirq";
I gave this a test on an S32G-VNP-RDB3 and didn't see any issues on the
dwmac-s32 side, but this appears to trigger a panic when reading the new
debugfs regmap/*/registers file for the syscon node:
# grep 4007c000 /proc/vmallocinfo
0xffff800083da8000-0xffff800083dac000 16384 ioremap_prot+0x74/0xe0 phys=0x000000004007c000 ioremap
# cat /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers
Internal error: synchronous external abort: 0000000096000210 [#1] SMP
[...]
CPU: 0 UID: 0 PID: 4344 Comm: cat Tainted: G M E X ------ --- 6.12.0+ #226 PREEMPT_RT
Tainted: [M]=MACHINE_CHECK, [E]=UNSIGNED_MODULE, [X]=AUX
[...]
pc : regmap_mmio_read32le+0x44/0xa0
lr : regmap_mmio_read32le+0x44/0xa0
[...]
x23: ffff00080c080000 x22: ffff000802ac4c00 x21: ffff800087b13c9c
x20: ffff800080a46494 x19: ffff800083da810c x18: 0000000000000004
[...]
x5 : ffff800080a46448 x4 : ffff800083da8000 x3 : ffff800080a46494
x2 : ffff800080a47230 x1 : ffff800083da810c x0 : 0000000000000020
Call trace:
regmap_mmio_read32le+0x44/0xa0 (P)
regmap_mmio_read+0x4c/0x80
[...]
Code: 52800400 8b214093 aa1303e1 97f4caf0 (b9400275)
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: synchronous external abort: Fatal exception
Running this through decodecode gives:
All code
========
0: 52800400 mov w0, #0x20 // #32
4: 8b214093 add x19, x4, w1, uxtw
8: aa1303e1 mov x1, x19
c: 97f4caf0 bl 0xffffffffffd32bcc
10:* b9400275 ldr w21, [x19] <-- trapping instruction
Code starting with the faulting instruction
===========================================
0: b9400275 ldr w21, [x19]
x19's offset from the base address in /proc/vmallocinfo is 0x10c, which
points to a bad read at physical address 0x4007c10c; I also confirmed
that the preceding memory reads back without issues:
# head -c 990 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
0104: 00000000
# head -c 1005 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
0108: 00000000
# head -c 1020 /sys/kernel/debug/regmap/dummy-syscon@0x000000004007c000/registers | tail -1
<panic>
Best,
Jared
^ permalink raw reply
* Re: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Bjorn Helgaas @ 2026-04-17 19:55 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB1211449884AC3BC8E3711F1AB92202@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Fri, Apr 17, 2026 at 03:17:16AM +0000, Sherry Sun wrote:
> > On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > > Introduce generic helper functions to parse Root Port device
> > > tree nodes and extract common properties like reset GPIOs. This
> > > allows multiple PCI host controller drivers to share the same
> > > parsing logic.
> > >
> > > Define struct pci_host_port to hold common Root Port properties
> > > (currently only reset GPIO descriptor) and add
> > > pci_host_common_parse_ports() to parse Root Port nodes from
> > > device tree.
> >
> > Are the Root Port and the RC the only possible places for 'reset'
> > GPIO descriptions in DT? I think PERST# routing is outside the
> > PCIe spec, so it seems like a system could provide a PERST# GPIO
> > routed to any Switch Upstream Port or Endpoint (I assume a PERST#
> > connected to a switch would apply to both the upstream port and
> > the downstream ports).
>
> Thanks for the feedback. You're right that PERST# routing could
> theoretically be connected to any device in the hierarchy. However,
> for this patch series, I've focused on the most common use case in
> practice: use Root Port level PERST# instead of the legacy Root
> Complex level PERST#.
>
> Root Port level PERST# - This is the primary target, where each Root
> Port has individual control over devices connected to it. RC level
> PERST# - Legacy binding support, where a single GPIO controls all
> ports.
>
> We can extend this framework later if real hardware emerges that
> needs Switch or EP-level PERST# control. I can add a comment
> documenting this limitation if needed.
>
> BTW, Mani and Rob had some great discussions in dt-schema about
> PERST# and WAKE# sideband signals settings.
> You can check here:
> https://github.com/devicetree-org/dt-schema/issues/168
> https://github.com/devicetree-org/dt-schema/pull/126
> https://github.com/devicetree-org/dt-schema/pull/170
The upshot of all those conversations is that WAKE# and PERST# can be
routed to arbitrary devices independent of the PCI topology.
I think extending host-generic to look for 'reset' in Root Port nodes
is the right thing. My concern is more about where we store it. This
patch saves it in a new "pci_host_port" struct, but someday we'll want
a place to save the PERST# GPIOs for several slots behind a switch.
Then we'll have two different ways to save the same information.
WAKE# signals might be more pertinent -- we definitely need to support
multiple WAKE# signals below a single Root Port, and it seems like
PERST# and WAKE# GPIOs should be saved the same place.
I'm wondering if both should go in the pci_dev itself. I guess the
implication is that a pci_dev->reset GPIO would describe a PERST#
connected to the device *below* the pci_dev, at least for Downstream
Ports.
I don't know about WAKE# signals. When it's in a connector, there's
probably only a single possible WAKE# per Downstream Port. But is it
possible have multiple WAKE# signals from a multi-function device
that's on the motherboard? Saving the WAKE# GPIO in the Downstream
Port wouldn't accommodate that case.
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Frank Li @ 2026-04-17 11:22 UTC (permalink / raw)
To: Robby Cai
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam, shawnguo,
martin.kepplinger, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260417110200.753678-2-robby.cai@nxp.com>
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 >= ?
> 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
>
> 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>
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> index 6a25e219832c..165716d08e64 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> @@ -1377,7 +1377,7 @@ mipi_csi1: csi@30a70000 {
> assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>,
> <&clk IMX8MQ_CLK_CSI1_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI1_ESC>;
> - assigned-clock-rates = <266000000>, <333000000>, <66000000>;
> + assigned-clock-rates = <133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
> <&clk IMX8MQ_SYS2_PLL_1000M>,
> <&clk IMX8MQ_SYS1_PLL_800M>;
> @@ -1429,7 +1429,7 @@ mipi_csi2: csi@30b60000 {
> assigned-clocks = <&clk IMX8MQ_CLK_CSI2_CORE>,
> <&clk IMX8MQ_CLK_CSI2_PHY_REF>,
> <&clk IMX8MQ_CLK_CSI2_ESC>;
> - assigned-clock-rates = <266000000>, <333000000>, <66000000>;
> + assigned-clock-rates = <133000000>, <100000000>, <66000000>;
> assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
> <&clk IMX8MQ_SYS2_PLL_1000M>,
> <&clk IMX8MQ_SYS1_PLL_800M>;
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH v2 2/3] ASoC: soc-core: Add core support for ignoring suspend on selected DAPM widgets
From: Frank Li @ 2026-04-17 11:14 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, s.hauer, kernel, shumingf, rander.wang,
pierre-louis.bossart, linux-sound, linux-kernel, linuxppc-dev,
imx, linux-arm-kernel
In-Reply-To: <20260415081942.4183108-3-chancel.liu@nxp.com>
On Wed, Apr 15, 2026 at 05:19:41PM +0900, Chancel Liu wrote:
> Some audio systems require specific DAPM widgets to remain powered
> during system suspend. Introduce a generic and reusable mechanism in
> the ASoC core to mark selected DAPM widgets as ignore_suspend.
>
> The unified mechanism consists of two parts:
> 1. Parse and store the name list of widgets to ignore suspend in
> struct snd_soc_card
>
> The list of widgets can be provided either by the machine driver or
> parsed from Device Tree. Different machines have different routing and
> power requirements. Each machine can specify its own widgets to ignore
> suspend through DT property. It enables flexible policy without hard
> code. A new helper, snd_soc_of_parse_ignore_suspend_widgets() is added
> for this purpose.
>
> 2. Apply ignore_suspend flags during snd_soc_bind_card()
>
> After all components have been probed and all DAPM widgets have been
> registered, snd_soc_bind_card() performs a unified lookup of the
> configured widget names across all DAPM contexts of the card and marks
> the matching widgets with ignore_suspend = 1.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
...
> @@ -3294,6 +3298,45 @@ int snd_soc_of_parse_aux_devs(struct snd_soc_card *card, const char *propname)
> }
> EXPORT_SYMBOL_GPL(snd_soc_of_parse_aux_devs);
>
> +int snd_soc_of_parse_ignore_suspend_widgets(struct snd_soc_card *card,
> + const char *propname)
propname is fixed value "ignore-suspend-widgets"，needn't this agument.
you funciton include "ignore_suspend_widgets", suppose only parse property.
ignore_suspend_widgets
Frank
^ permalink raw reply
* Re: [PATCH v2 1/3] ASoC: dapm: Fix widget lookup with prefixed names across DAPM contexts
From: Frank Li @ 2026-04-17 11:03 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, perex, tiwai, shengjiu.wang, Xiubo.Lee,
festevam, nicoleotsuka, s.hauer, kernel, shumingf, rander.wang,
pierre-louis.bossart, linux-sound, linux-kernel, linuxppc-dev,
imx, linux-arm-kernel
In-Reply-To: <20260415081942.4183108-2-chancel.liu@nxp.com>
On Wed, Apr 15, 2026 at 05:19:40PM +0900, Chancel Liu wrote:
subject suggest change to
ASoC: dapm: Use snd_soc_dapm_widget_name_cmp() to fix widget lookup failures
Frank
> Currently dapm_find_widget() manually constructs a prefixed widget name
> based on the provided DAPM context and compares it using strcmp(). This
> happens to work in most cases because callers usually know which DAPM
> context the target widget belongs to and pass in the matching DAPM
> context.
>
> However, this assumption breaks when search_other_contexts is enabled.
> In such cases, callers may intentionally pass a different DAPM context,
> while searching for a widget that actually belongs to another DAPM
> context.
>
> For example, when searching for a "DAC" widget, the widget belongs to
> the codec DAPM and be registered with a codec prefix, while the caller
> passes card->dapm and intends to search across all DAPM contexts. The
> current implementation incorrectly applies the caller card DAPM causing
> the lookup to fail even though the widget exists on the card.
>
> Use snd_soc_dapm_widget_name_cmp() instead, which compares widget names
> using the widget's own DAPM context and prefix. It fixes widget lookup
> failures when searching across different DAPM contexts on the card.
>
> Fixes: ae4fc532244b ("ASoC: dapm: use component prefix when checking widget names")
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> Assisted-by: Cody:Claude-3.5-Sonnet
> ---
> sound/soc/soc-dapm.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
> index d6192204e613..c5b80d9ed64b 100644
> --- a/sound/soc/soc-dapm.c
> +++ b/sound/soc/soc-dapm.c
> @@ -2906,20 +2906,9 @@ static struct snd_soc_dapm_widget *dapm_find_widget(
> {
> struct snd_soc_dapm_widget *w;
> struct snd_soc_dapm_widget *fallback = NULL;
> - char prefixed_pin[80];
> - const char *pin_name;
> - const char *prefix = dapm_prefix(dapm);
> -
> - if (prefix) {
> - snprintf(prefixed_pin, sizeof(prefixed_pin), "%s %s",
> - prefix, pin);
> - pin_name = prefixed_pin;
> - } else {
> - pin_name = pin;
> - }
>
> for_each_card_widgets(dapm->card, w) {
> - if (!strcmp(w->name, pin_name)) {
> + if (!snd_soc_dapm_widget_name_cmp(w, pin)) {
> if (w->dapm == dapm)
> return w;
> else
> --
> 2.50.1
>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
From: Robby Cai @ 2026-04-17 11:02 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260417110200.753678-1-robby.cai@nxp.com>
Enable CSI1/CSI2 bridges and the MIPI-CSI host interfaces, and add
two OV5640 MIPI camera sensor nodes on I2C1 and I2C2.
The resulting camera pipelines are as follows:
- OV5640 on I2C2 -> MIPI CSI1 -> CSI1
- OV5640 on I2C1 -> MIPI CSI2 -> CSI2
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
Tested with following commands:
On CSI1:
media-ctl -d 0 -l "'ov5640 1-003c':0 -> 'imx8mq-mipi-csi2 30a70000.csi':0 [1]"
media-ctl -d 0 -V "'ov5640 1-003c':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 0 -V "'imx8mq-mipi-csi2 30a70000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 0 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
v4l2-ctl -d 0 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap
On CSI2:
media-ctl -d 1 -l "'ov5640 0-003c':0 -> 'imx8mq-mipi-csi2 30b60000.csi':0 [1]"
media-ctl -d 1 -V "'ov5640 0-003c':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 1 -V "'imx8mq-mipi-csi2 30b60000.csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
media-ctl -d 1 -V "'csi':0 [fmt:YUYV8_1X16/640x480 field:none]"
v4l2-ctl -d 1 --set-fmt-video=width=640,height=480,pixelformat=YUYV --stream-mmap
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 149 +++++++++++++++++++
1 file changed, 149 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index d48f901487d4..8bdfbfebfcc9 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -6,6 +6,8 @@
/dts-v1/;
+#include <dt-bindings/media/video-interfaces.h>
+
#include "imx8mq.dtsi"
/ {
@@ -50,6 +52,20 @@ reg_usdhc2_vmmc: regulator-vsd-3v3 {
enable-active-high;
};
+ reg_1v5: regulator-1v5 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_1V5";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ };
+
+ reg_2v8: regulator-2v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_2V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
buck2_reg: regulator-buck2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_buck2>;
@@ -172,6 +188,14 @@ &A53_3 {
cpu-supply = <&buck2_reg>;
};
+&csi1 {
+ status = "okay";
+};
+
+&csi2 {
+ status = "okay";
+};
+
&ddrc {
operating-points-v2 = <&ddrc_opp_table>;
status = "okay";
@@ -330,12 +354,101 @@ vgen6_reg: vgen6 {
};
};
};
+
+ camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera2_pwdn>;
+ clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+ assigned-clock-rates = <20000000>;
+ powerdown-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ DOVDD-supply = <&sw4_reg>;
+ AVDD-supply = <®_2v8>;
+ DVDD-supply = <®_1v5>;
+ status = "okay";
+
+ port {
+ camera2_ep: endpoint {
+ remote-endpoint = <&mipi_csi2_in_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera1_pwdn>, <&pinctrl_camera_rst>;
+ clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ clock-names = "xclk";
+ assigned-clocks = <&clk IMX8MQ_CLK_CLKO2>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS2_PLL_200M>;
+ assigned-clock-rates = <20000000>;
+ powerdown-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>;
+ DOVDD-supply = <&sw4_reg>;
+ AVDD-supply = <®_2v8>;
+ DVDD-supply = <®_1v5>;
+ status = "okay";
+
+ port {
+ camera1_ep: endpoint {
+ remote-endpoint = <&mipi_csi1_in_ep>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
};
&lcdif {
status = "okay";
};
+&mipi_csi1 {
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi1_in_ep: endpoint {
+ remote-endpoint = <&camera1_ep>;
+ data-lanes = <1 2>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ };
+ };
+ };
+};
+
+&mipi_csi2 {
+ status = "okay";
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi2_in_ep: endpoint {
+ remote-endpoint = <&camera2_ep>;
+ data-lanes = <1 2>;
+ bus-type = <4>;
+ };
+ };
+ };
+};
+
&mipi_dsi {
#address-cells = <1>;
#size-cells = <0>;
@@ -532,12 +645,41 @@ &wdog1 {
};
&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* MCLK for cameras on both CSI1 and CSI2 */
+ MX8MQ_IOMUXC_GPIO1_IO15_CCMSRCGPCMIX_CLKO2 0x59
+ >;
+ };
+
pinctrl_buck2: vddarmgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x19
>;
};
+ pinctrl_camera1_pwdn: camera1pwdngrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x19
+ >;
+ };
+
+ pinctrl_camera2_pwdn: camera2pwdngrp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x19
+ >;
+ };
+
+ pinctrl_camera_rst: camerarstgrp {
+ fsl,pins = <
+ /* Reset PIN for cameras on both CSI1 and CSI2 */
+ MX8MQ_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x19
+ >;
+ };
+
pinctrl_fec1: fec1grp {
fsl,pins = <
MX8MQ_IOMUXC_ENET_MDC_ENET1_MDC 0x3
@@ -565,6 +707,13 @@ MX8MQ_IOMUXC_I2C1_SDA_I2C1_SDA 0x4000007f
>;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_I2C2_SCL_I2C2_SCL 0x4000007f
+ MX8MQ_IOMUXC_I2C2_SDA_I2C2_SDA 0x4000007f
+ >;
+ };
+
pinctrl_ir: irgrp {
fsl,pins = <
MX8MQ_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x4f
--
2.37.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: imx8mq: Correct MIPI CSI clocks
From: Robby Cai @ 2026-04-17 11:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260417110200.753678-1-robby.cai@nxp.com>
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.
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>
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 6a25e219832c..165716d08e64 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1377,7 +1377,7 @@ mipi_csi1: csi@30a70000 {
assigned-clocks = <&clk IMX8MQ_CLK_CSI1_CORE>,
<&clk IMX8MQ_CLK_CSI1_PHY_REF>,
<&clk IMX8MQ_CLK_CSI1_ESC>;
- assigned-clock-rates = <266000000>, <333000000>, <66000000>;
+ assigned-clock-rates = <133000000>, <100000000>, <66000000>;
assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
<&clk IMX8MQ_SYS2_PLL_1000M>,
<&clk IMX8MQ_SYS1_PLL_800M>;
@@ -1429,7 +1429,7 @@ mipi_csi2: csi@30b60000 {
assigned-clocks = <&clk IMX8MQ_CLK_CSI2_CORE>,
<&clk IMX8MQ_CLK_CSI2_PHY_REF>,
<&clk IMX8MQ_CLK_CSI2_ESC>;
- assigned-clock-rates = <266000000>, <333000000>, <66000000>;
+ assigned-clock-rates = <133000000>, <100000000>, <66000000>;
assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_266M>,
<&clk IMX8MQ_SYS2_PLL_1000M>,
<&clk IMX8MQ_SYS1_PLL_800M>;
--
2.37.1
^ permalink raw reply related
* [PATCH 0/2] Enable dual OV5640 cameras on i.MX8MQ EVK board
From: Robby Cai @ 2026-04-17 11:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, shawnguo,
martin.kepplinger
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel
This series adds dual-camera support for the i.MX8MQ EVK board.
Patch 1 fixes the MIPI CSI clock configuration in the i.MX8MQ device tree.
The previous configuration violated a timing constraint defined 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."
This mismatch could lead to unstable operation, observed as intermittent
capture failures. The updated clock ratios align with those used in NXP��s
downstream BSP and were verified to resolve the issue.
Patch 2 enables full MIPI CSI support and dual OV5640 camera operation on
the i.MX8MQ EVK. This includes enabling both CSI controllers and their
corresponding MIPI CSI-2 host interfaces, as well as adding two OV5640
sensor nodes on I2C1 and I2C2.
Note:
This series depends on patch [1] currently under review, as well as commit
6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly release reset").
[1] https://lore.kernel.org/imx/20260417080851.489303-1-robby.cai@nxp.com/
Robby Cai (2):
arm64: dts: imx8mq: Correct MIPI CSI clocks
arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 149 +++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 4 +-
2 files changed, 151 insertions(+), 2 deletions(-)
--
2.37.1
^ 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