From: Frank Li <Frank.li@oss.nxp.com>
To: Marek Vasut <marex@nabladev.com>
Cc: sashiko-reviews@lists.linux.dev, Frank.Li@kernel.org,
imx@lists.linux.dev, robh@kernel.org, conor+dt@kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v7 7/7] arm64: dts: imx8mm: imx8mp: Add FIO1-Audio DTOs for Data Modul i.MX8M Mini and Plus eDM SBC
Date: Fri, 31 Jul 2026 10:23:20 -0500 [thread overview]
Message-ID: <amy96HmlzdtBz4nl@SMW015318> (raw)
In-Reply-To: <e4f9ef42-d752-4563-a86b-4c62f47e43ac@nabladev.com>
On Thu, Jul 30, 2026 at 09:34:43PM +0200, Marek Vasut wrote:
> On 7/30/26 5:17 PM, Frank Li wrote:
>
> Hello Frank,
>
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-data-modul-edm-sbc-overlay-edm-mod-imx8mm-fio1-audio.dtsi
> > > [ ... ]
> > > > + gpio_feature: io-expander@20 {
> > > > + compatible = "nxp,pca9554";
> > > > + reg = <0x20>;
> > > > + #gpio-cells = <2>;
> > > > + gpio-controller;
> > > > + #interrupt-cells = <2>;
> > > > + interrupt-controller;
> > > > + interrupt-parent = <&gpio5>;
> > > > + interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
> > >
> > > [Severity: High]
> > > Does this interrupt routing conflict on the i.MX8MP baseboard?
> > >
> > > The shared overlay hardcodes the PCA9554 interrupt to GPIO5_IO04, which is
> > > correct for i.MX8MM. However, on i.MX8MP, this pad (SPDIF_RX) is physically
> > > routed and configured for CAN1_RX.
> > >
> > > Could this cause the GPIO expander interrupts to fail and CAN traffic to
> > > trigger spurious GPIO interrupts when loaded on the i.MX8MP? Would it be
> > > better to override this interrupt in the i.MX8MP overlay?
> >
> > Yes, I check flexcan1 use this pad at i.MX8MP. you need disable flexcan1
> > at i.mx8mp's dtso file.
>
> I'll fix that in V8.
>
> [...]
>
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-data-modul-edm-sbc-overlay-edm-mod-imx8mm-fio1-audio.dtso
> > > [ ... ]
> > > > + sai5clk: clock-controller@30050000 { /* SAI5 */
> > > > + compatible = "fsl,imx8mm-sai-clock", "fsl,imx8mq-sai-clock";
> > > > + reg = <0x30050000 0x10000>;
> > >
> > > [Severity: High]
> > > Can this cause a devres memory region conflict during driver probe?
> > >
> > > This overlay adds a new clock-controller node with the exact same unit address
> > > and register range as the existing sai@30050000 audio node.
> > >
> > > Since both drivers will use devm_platform_ioremap_resource() to request the
> > > region exclusively, whichever probes second might receive -EBUSY and fail.
> >
> > at imx8mm.dts, 30050000 is SAI5, here you change to to use clock-controller
> >
> > Suppose address here is wrong.
> This is correct and we already discussed this in V4, the SAI here is not
> used as an audio controller (not using sound/soc/fsl/fsl_sai.c driver), but
> as a clock controller (yes using drivers/clk/clk-fsl-sai.c driver), the
> bindings differ, hence this node.
Thanks, I forget it. Now, may not allow this method. The same hardware
have to use one compatible string.
Frank
next prev parent reply other threads:[~2026-07-31 15:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 21:47 [PATCH v7 1/7] arm64: dts: imx8mp: Add DT label to SPBA5 bus Marek Vasut
2026-07-29 21:47 ` [PATCH v7 2/7] arm64: dts: imx8mm: imx8mp: Add LVDS DTOs for Data Modul i.MX8M Mini and Plus eDM SBC Marek Vasut
2026-07-29 22:06 ` sashiko-bot
2026-07-30 15:31 ` Frank Li
2026-07-30 19:14 ` Marek Vasut
2026-07-29 21:47 ` [PATCH v7 3/7] arm64: dts: imx8mm: imx8mp: Add legacy board " Marek Vasut
2026-07-29 21:47 ` [PATCH v7 4/7] arm64: dts: imx8mm: imx8mp: Add HDMI " Marek Vasut
2026-07-29 21:47 ` [PATCH v7 5/7] arm64: dts: imx8mm: imx8mp: Add CM " Marek Vasut
2026-07-29 21:47 ` [PATCH v7 6/7] arm64: dts: imx8mm: imx8mp: Add FIO1 " Marek Vasut
2026-07-29 21:47 ` [PATCH v7 7/7] arm64: dts: imx8mm: imx8mp: Add FIO1-Audio " Marek Vasut
2026-07-29 22:10 ` sashiko-bot
2026-07-30 15:17 ` Frank Li
2026-07-30 19:34 ` Marek Vasut
2026-07-31 15:23 ` Frank Li [this message]
2026-07-31 15:56 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amy96HmlzdtBz4nl@SMW015318 \
--to=frank.li@oss.nxp.com \
--cc=Frank.Li@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=imx@lists.linux.dev \
--cc=marex@nabladev.com \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.