* Re: [PATCH v1 1/4] dt-bindings: lcdif: Add interface pixel format
From: sashiko-bot @ 2026-07-17 12:28 UTC (permalink / raw)
To: Francesco Dolcini; +Cc: devicetree, robh, dri-devel, Frank.Li, conor+dt, imx
In-Reply-To: <20260717121847.488148-2-francesco@dolcini.it>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Introduction of the legacy, non-standard `interface-pix-fmt` property for a standard hardware concept (parallel bus width), violating modern DT principles.
--
--- Patch [1]: [PATCH v1 1/4] dt-bindings: lcdif: Add interface pixel format ---
commit 7225ea545d2ff50540972dd75d375b8ecea4f315
Author: Francesco Dolcini <francesco.dolcini@toradex.com>
dt-bindings: lcdif: Add interface pixel format
This commit updates the fsl,lcdif device tree binding to support the
interface-pix-fmt property. The property is used to describe the hardware's
parallel data bus transfer width to match board wiring and prevent shifted
colors.
> diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> index 2dd0411ec6516..209ee5a96e393 100644
> --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
> @@ -58,6 +58,13 @@ properties:
> items:
> - const: rx
>
> + interface-pix-fmt:
> + $ref: /schemas/types.yaml#/definitions/string
> + enum:
> + - rgb24
> + - rgb565
> + - rgb666
[Severity: Low]
Is this introducing a legacy, non-standard property into the new schema ABI?
Standard devicetree guidelines usually prefer endpoint properties like
bus-width (defined in video-interfaces.yaml) to describe physical parallel
data line configurations, such as setting bus-width = <18> for RGB666.
If a custom property is strictly necessary here rather than using the standard
endpoint properties, does this require a vendor prefix like
fsl,interface-pix-fmt to comply with modern devicetree naming conventions?
> +
> interrupts:
> items:
> - description: LCDIF DMA interrupt
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717121847.488148-1-francesco@dolcini.it?part=1
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: vga-connector: Allow hardcoding EDID
From: Laurent Pinchart @ 2026-07-17 12:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: dri-devel, devicetree, Thuan Nguyen, Maarten Lankhorst,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Andrzej Hajda, Neil Armstrong,
Robert Foss, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
linux-renesas-soc
In-Reply-To: <20260707080143.GA211515@killaraus.ideasonboard.com>
Hi Maxime,
On Tue, Jul 07, 2026 at 11:01:43AM +0300, Laurent Pinchart wrote:
> On Tue, Jul 07, 2026 at 09:46:52AM +0200, Maxime Ripard wrote:
> > On Mon, Jul 06, 2026 at 07:02:43PM +0300, Laurent Pinchart wrote:
> > > On Mon, Jul 06, 2026 at 05:40:30PM +0200, Maxime Ripard wrote:
> > > > On Mon, Jul 06, 2026 at 12:45:22PM +0300, Laurent Pinchart wrote:
> > > > > On Mon, Jul 06, 2026 at 10:52:32AM +0200, Maxime Ripard wrote:
> > > > > > On Mon, Jul 06, 2026 at 12:35:39AM +0300, Laurent Pinchart wrote:
> > > > > > > Since DDC version 2, introduced in 1996, VGA monitors have exposed EDID
> > > > > > > data over an I2C bus. The bus is also used to detect the presence of a
> > > > > > > connected monitor by trying to read the EDID data.
> > > > > > >
> > > > > > > Some devices where the VGA display is integrated in the device and
> > > > > > > always connected do not connect the DDC pins. Some development boards,
> > > > > > > such as the Renesas M3N Salvator-XS, also do not connect the DDC pins.
> > > > > > >
> > > > > > > To support those, add the ability to provide hardcoded EDID data in the
> > > > > > > device tree. This is mutually exclusive with specifying a DDC bus, and
> > > > > > > can only be done when the VGA display is guaranteed to be always
> > > > > > > connected.
> > > > > > >
> > > > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > > > >
> > > > > > This feels redundant with the EDID firmware loading mechanism we have in
> > > > > > KMS already. It should at least be mentioned why we would need to set it
> > > > > > in the device tree at all.
> > > > >
> > > > > Very good question.
> > > > >
> > > > > I assume you're talking about CONFIG_DRM_LOAD_EDID_FIRMWARE, as the
> > > > > debugfs override_edid feature isn't meant for production. If there are
> > > > > other relevant mechanisms I'm not aware of, please let me know.
> > > >
> > > > No, that's indeed what I meant.
> > > >
> > > > > In the use case at hand, the VGA display is an integral part of the
> > > > > device, the same way an LVDS or DSI panel would be. Using
> > > > > CONFIG_DRM_LOAD_EDID_FIRMWARE, the manufacturer would need to set the
> > > > > drm.edid_firmware command line parameter, and provide EDID as a file in
> > > > > /lib/firmware/ (possibly in an initramfs). Beside the complexity, and
> > > > > the fact it won't be very friendly to people who run a different
> > > > > userspace on the device, I think EDID counts in this case as system
> > > > > description, the same way we support specifying panel timings in device
> > > > > tree.
> > > >
> > > > It's *some* hardware description, but you have no idea whether it's
> > > > actually the hardware you're running from. What would be in that EDID
> > > > anyway?
> > >
> > > It would be the EDID corresponding to the connected display :-) I see it
> > > as identical to how a user of the simple panel driver is responsible for
> > > listing the timings corresponding to the hardware in the device tree.
> >
> > What's the expected user-experience for someone with that board
> > unplugging a display and plugging another then? Update the device tree,
> > rebuild it, rebuild the firmware and / or resign it and reboot?
>
> The whole point is that they can't easily unplug the display. This patch
> series is meant to support devices where the display is an integral part
> of the device. The user experience is expected to be the same as for a
> user who will take a phone, remove the display panel, and plug a
> different one. It's certainly possible, and they would have to update
> the DT indeed.
>
> > That doesn't sound very practical, and even impossible in some cases.
> >
> > > > There's another alternative we've used several times already, in
> > > > simple-bridge for example: just register any VESA mode up to a given
> > > > resolution:
> > > > https://elixir.bootlin.com/linux/v7.1.2/source/drivers/gpu/drm/bridge/simple-bridge.c#L66
> > >
> > > I don't see how that would help. The goal is to provide the kernel with
> > > the data corresponding to the display integrated in the device.
> >
> > How is that not helping? Your problem is that you have a display you
> > can't get the supported resolutions from. What I'm suggesting allows you
> > to create all the possible resolutions for that display, allowing the
> > user to use the display, which is what we did for multiple drivers with
> > the same problem.
>
> How would the possible resolutions be provided to the kernel ? Isn't it
> the whole point of EDID ?
>
> > You seem to be set on providing the EDID to the kernel, but it's a
> > terrible idea to begin with, so I'd rather discuss alternatives.
>
> Could you elaborate on why it is a terrible idea ?
I'd be happy to continue this discussion when you'll have time.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 01/11] arm64: dts: lx2160a: explicitly enable serdes_1 node
From: sashiko-bot @ 2026-07-17 12:22 UTC (permalink / raw)
To: Ioana Ciornei; +Cc: Frank.Li, imx, robh, conor+dt, devicetree
In-Reply-To: <20260717120635.2118610-2-ioana.ciornei@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Incomplete device tree update: the patch claims to explicitly enable the `serdes_1` node in "all board DT files" to prepare for an SoC default change, but misses several LX2160A and LX2162A board files.
--
--- Patch [1]: [PATCH v3 01/11] arm64: dts: lx2160a: explicitly enable serdes_1 node ---
commit d3826fcfc7d054169418a33dbec45e352c709bff
Author: Ioana Ciornei <ioana.ciornei@nxp.com>
arm64: dts: lx2160a: explicitly enable serdes_1 node
This commit enables the serdes_1 node in board-specific device tree files.
This change prepares for a subsequent update that will set the default
status of the serdes_1 node to disabled in the main SoC device tree.
> Explicitly enable the serdes_1 node in all board DT files. This is
> needed in order to be able to change the default status of the node to
> "disabled" from the SoC DT file.
[Severity: High]
Does this commit miss updating several other lx2160a and lx2162a board
files?
If the default status in the SoC device tree file is changed to disabled,
it appears boards that rely on serdes_1 for high-speed IO (PCIe,
networking, SATA) might be left without functional interfaces.
Could the following board files also need the serdes_1 node enabled:
- arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
- arch/arm64/boot/dts/freescale/fsl-lx2160a-qds.dts
- arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
- arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
Is there a reason these files were omitted from this patch?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717120635.2118610-1-ioana.ciornei@nxp.com?part=1
^ permalink raw reply
* Re: [PATCH] dma-iommu: Introduce API to reserve IOVA regions for dynamically created devices
From: Robin Murphy @ 2026-07-17 12:21 UTC (permalink / raw)
To: Konrad Dybcio, Jason Gunthorpe, Krzysztof Kozlowski
Cc: Vishnu Reddy, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, Vikash Garodia, joro, will, m.szyprowski, iommu,
linux-kernel, dikshita.agarwal, Bjorn Andersson, Dmitry Baryshkov,
Robin Clark, Akhil P Oommen, Srinivas Kandagatla, Ekansh Gupta,
Loic Poulain
In-Reply-To: <dba037fa-0f21-4a50-8727-076a3b177c47@gmail.com>
On 17/07/2026 11:44 am, Konrad Dybcio wrote:
> On 6/18/26 5:17 PM, Jason Gunthorpe wrote:
>> On Thu, Jun 18, 2026 at 01:57:40PM +0200, Krzysztof Kozlowski wrote:
>
> [...]
>
>> So, if we are going to do a hack in DT to accomodate Linux, I argue to
>> choose explicit child devices so VPU does not need to create a special
>> bus, call of_dma_configue, or hack in new DMA API things that only it
>> will ever use.
>
> Bit late to the party, but I'll chime in with some more "amazing news"..
>
> All of the multimedia HW on QC platforms (camera, display, GPU, video
> and their specialized variations) has at least part of the same problems:
>
> * Multiple SID groups that need to be accommodated for different purposes
> (normal vs secure buffers provided by the same device, different
> "logical functions" generally speaking) apply to all of them
>
> * Different IOVA limitations per SID group seems to also concern at
> least the camera uC ("ICP") (but not all of camera hw)
>
> * Remoteprocs (and therefore also the audio stack) expose a number of
> subfunctions, some of which we currently model as subnodes (although
> many arguably only exist as such because someone decided it was
> convenient to express them this way). This, for example led to the
> representation of each SID group associated with the remoteproc
> (fastrpc/"run compute on rproc") as a separate node:
>
> -- qcom/hamoa.dtsi
> remoteproc_adsp: remoteproc@6800000 {
> [...]
>
> // no iommus OR iommus used for another purpose (fw loading)
>
> fastrpc {
> // no iommus
>
> compute-cb@3 {
> compatible = "qcom,fastrpc-compute-cb";
> reg = <3>;
> iommus = <&apps_smmu 0x1003 0x80>,
> <&apps_smmu 0x1063 0x0>;
> dma-coherent;
> };
>
> compute-cb@4 {
> compatible = "qcom,fastrpc-compute-cb";
> reg = <4>;
> iommus = <&apps_smmu 0x1004 0x80>,
> <&apps_smmu 0x1064 0x0>;
> dma-coherent;
> };
>
> [...] (there's a lot of them)
> };
> };
>
> There may be more hiding in plain sight, but those are the ones I'm
> aware of.
>
>
> I was kinda hoping there would be more buy-in to follow what PCIe
> does, but to my understanding you're opposed to it because "vpu_bus"
> is not dynamically discoverable. PCIe generally obviously is, but
> we already have prior art regarding hardwired/onboard devices - many
> qcom DTs carry per-board iommu-map overrides to please the allocator
> with known-in-advance BDF values (because the HW has only so many
> SIDs):
It's not really about dynamic discoverability, it's more the fact that
PCI requester IDs are a real and well-defined thing.
> -- qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
> iommu-map = <0x0 &apps_smmu 0x1c00 0x1>,
> <0x100 &apps_smmu 0x1c01 0x1>,
> <0x208 &apps_smmu 0x1c04 0x1>,
> <0x210 &apps_smmu 0x1c05 0x1>,
> <0x218 &apps_smmu 0x1c06 0x1>,
> <0x300 &apps_smmu 0x1c07 0x1>,
> <0x400 &apps_smmu 0x1c08 0x1>,
> <0x500 &apps_smmu 0x1c09 0x1>,
> <0x501 &apps_smmu 0x1c10 0x1>;
>
> Although it seems to me that it's more of a hack than anything else..
No, that is describing a genuine mapping of physical PCIe requester ID
values to physical SMMU StreamID values which exists in the system, and
which any OS needs to understand in order to be able to configure the
SMMU correctly at all. Sure, that mapping probably is programmed in a
lookup table in the root complex by the bootloader in a board-specific
manner (like I know the NXP Layerscape platforms do, for instance) but
it's still a real description of the system configuration, and it's
perfectly fine if StreamIDs and/or LUT entries are limited to only
configure BDFs known to be present at boot (if there's no SR-IOV or
hotplug to worry about), since it's a reasonable expectation that an OS
won't go arbitrarily renumbering buses just for fun.
It's another thing entirely to have a bunch of distinct logical devices
whose only physical identifier is already an SMMU StreamID, then invent
a fake mapping of made-up numbers to StreamIDs in order to pretend they
can use common infrastructure, except still needing invasive hacks at
almost every level of said common infrastructure in order to even try to
make it actually work.
How anyone can read, let alone write "This creates a limitation when
child requires a different iommu-address range than its parent, as
device tree cannot express the reservation per child." and not
immediately conclude that the Devicetree binding must be wrong because
it is unable to adequately describe the properties and requirements of
the hardware, frankly I struggle to imagine...
Thanks,
Robin.
>
>
> With that in mind, do you still prefer that this is handled through
> separate nodes, presumably for all of the aforementioned cases?
>
> Konrad
^ permalink raw reply
* [PATCH v1 4/4] ARM: dts: imx7-colibri: Set LCDIF format
From: Francesco Dolcini @ 2026-07-17 12:18 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, dri-devel, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260717121847.488148-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
The lcd DPI interface on colibri imx6ull uses a 18-bit width bus, set
the interface-pix-fmt accordingly.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi b/arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi
index 8666dcd7fe97..f820a613109a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi
@@ -533,6 +533,7 @@ &lcdif {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcdif_dat
&pinctrl_lcdif_ctrl>;
+ interface-pix-fmt = "rgb666";
status = "disabled";
port {
--
2.47.3
^ permalink raw reply related
* [PATCH v1 3/4] ARM: dts: imx6ull-colibri: Set LCDIF format
From: Francesco Dolcini @ 2026-07-17 12:18 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, dri-devel, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260717121847.488148-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
The lcd DPI interface on colibri imx6ull uses a 18-bit width bus, set
the interface-pix-fmt accordingly.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
index ec3c1e7301f4..e126fade2304 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi
@@ -225,6 +225,7 @@ &lcdif {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lcdif_dat
&pinctrl_lcdif_ctrl>;
+ interface-pix-fmt = "rgb666";
status = "disabled";
port {
--
2.47.3
^ permalink raw reply related
* [PATCH v1 2/4] drm: mxsfb: Allow optional LCDIF interface format override
From: Francesco Dolcini @ 2026-07-17 12:18 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, dri-devel, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260717121847.488148-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
LCDIF programs LCD_DATABUS_WIDTH from the selected media bus format. The
format reported by the downstream panel or bridge describes the display
input, but it does not describe how the LCDIF data pins are physically
wired on the board.
These can differ. For example, a 16-bit LCDIF bus can be connected to a
24-bit display by wiring the available color bits to the corresponding
display inputs. In that case, using the display's 24-bit format to
configure LCDIF selects the wrong data-bus mode and changes the assignment
of color bits on the LCD_DATA pins.
Read the optional interface-pix-fmt property from the LCDIF node and use
it to select the media bus format used to configure LCDIF. This allows
the LCDIF bus mode to describe the physical interface independently of
the downstream display format.
When the optional property is absent, continue using the format reported
by the downstream display device, preserving the existing behavior.
This follows the same approach already implemented in
drivers/gpu/drm/imx/ipuv3/parallel-display.c.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 16 ++++++++++++++++
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 ++
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 ++++++++
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 9b8fbda85d28..edf347968fd2 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -12,7 +12,9 @@
#include <linux/clk.h>
#include <linux/dma-mapping.h>
#include <linux/io.h>
+#include <linux/media-bus-format.h>
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/property.h>
#include <linux/pm_runtime.h>
@@ -209,7 +211,10 @@ static int mxsfb_load(struct drm_device *drm,
const struct mxsfb_devdata *devdata)
{
struct platform_device *pdev = to_platform_device(drm->dev);
+ struct device_node *np = pdev->dev.of_node;
struct mxsfb_drm_private *mxsfb;
+ u32 bus_format = 0;
+ const char *fmt;
int ret;
mxsfb = devm_kzalloc(&pdev->dev, sizeof(*mxsfb), GFP_KERNEL);
@@ -236,6 +241,17 @@ static int mxsfb_load(struct drm_device *drm,
if (IS_ERR(mxsfb->clk_disp_axi))
mxsfb->clk_disp_axi = NULL;
+ ret = of_property_read_string(np, "interface-pix-fmt", &fmt);
+ if (!ret) {
+ if (!strcmp(fmt, "rgb24"))
+ bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ else if (!strcmp(fmt, "rgb565"))
+ bus_format = MEDIA_BUS_FMT_RGB565_1X16;
+ else if (!strcmp(fmt, "rgb666"))
+ bus_format = MEDIA_BUS_FMT_RGB666_1X18;
+ }
+ mxsfb->bus_format = bus_format;
+
ret = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
if (ret)
return ret;
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index d160d921b25f..f64800f06a69 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -46,6 +46,8 @@ struct mxsfb_drm_private {
struct drm_connector *connector;
struct drm_bridge *bridge;
+ u32 bus_format;
+
bool crc_active;
};
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index d8ebebc5314b..8b482727aed5 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -386,6 +386,14 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
if (!bus_format)
bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+ /*
+ * Prefer bus format set via optional "interface-pix-fmt" DT property,
+ * over panel or next bridge bus format. This is necessary to support
+ * 24bit DPI panels connected to a 18bit interface, for example.
+ */
+ if (mxsfb->bus_format)
+ bus_format = mxsfb->bus_format;
+
mxsfb_crtc_mode_set_nofb(mxsfb, bridge_state, bus_format);
/* Write cur_buf as well to avoid an initial corrupt frame */
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/4] drm: mxsfb: Support LCDIF interface pixel format
From: Francesco Dolcini @ 2026-07-17 12:18 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, dri-devel, devicetree, linux-kernel, imx,
linux-arm-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
The LCDIF data bus format describes how color component bits are assigned
to the physical LCD_DATA pins. This is a property of the LCDIF-to-display
wiring and can differ from the input format advertised by the downstream
panel or bridge.
Such a distinction is required when a narrower LCDIF bus is connected to
a wider display interface. For example, an 18-bit or 16-bit LCDIF bus can
drive a 24-bit display by wiring the available color bits to the
appropriate display inputs. Configuring LCDIF from the display's 24-bit
format in this case selects the wrong LCD_DATABUS_WIDTH mode, changing the
color-bit assignment on the LCD_DATA pins and resulting in incorrect
colors.
Add the optional interface-pix-fmt property to the LCDIF binding and make
the mxsfb driver use it in preference to the format reported by the
downstream display. When the property is absent, the existing behavior is
preserved.
This follows the approach already used by the i.MX IPUv3 parallel display
driver in drivers/gpu/drm/imx/ipuv3/parallel-display.c.
Set the interface format for the Colibri iMX6ULL and Colibri iMX7 boards,
which route an 18-bit LCD interface.
Francesco Dolcini (4):
dt-bindings: lcdif: Add interface pixel format
drm: mxsfb: Allow optional LCDIF interface format override
ARM: dts: imx6ull-colibri: Set LCDIF format
ARM: dts: imx7-colibri: Set LCDIF format
.../devicetree/bindings/display/fsl,lcdif.yaml | 7 +++++++
arch/arm/boot/dts/nxp/imx/imx6ull-colibri.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx7-colibri.dtsi | 1 +
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 16 ++++++++++++++++
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 2 ++
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 ++++++++
6 files changed, 35 insertions(+)
--
2.47.3
^ permalink raw reply
* [PATCH v1 1/4] dt-bindings: lcdif: Add interface pixel format
From: Francesco Dolcini @ 2026-07-17 12:18 UTC (permalink / raw)
To: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: Francesco Dolcini, dri-devel, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260717121847.488148-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
LCDIF has a hardware-configurable LCD_DATABUS_WIDTH field which selects
the parallel data bus transfer width. The selected mode changes how color
component bits are assigned to the LCD_DATA pins.
This must match the board wiring. On Colibri iMX6ULL, for example, only
18 LCD data lines are routed. A 24-bit panel can still be connected by
wiring the available LCD_DATA signals to the appropriate panel inputs.
Without describing the resulting interface format, LCDIF may assign the
color components to different data lines, causing shifted colors.
Add interface-pix-fmt so the binding can describe the configured LCDIF
bus format. The same property is already used by
display/imx/fsl,imx-parallel-display.yaml.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
index 2dd0411ec651..209ee5a96e39 100644
--- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
+++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml
@@ -58,6 +58,13 @@ properties:
items:
- const: rx
+ interface-pix-fmt:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - rgb24
+ - rgb565
+ - rgb666
+
interrupts:
items:
- description: LCDIF DMA interrupt
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 3/4] drm/rockchip: lvds: add RK3568 support
From: sashiko-bot @ 2026-07-17 12:16 UTC (permalink / raw)
To: Rok Markovic; +Cc: devicetree, conor+dt, dri-devel, robh
In-Reply-To: <20260717120005.2087386-4-rok@kanardia.eu>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Unbalanced phy_power_off() in disable path permanently corrupts PHY state after a transient enable error.
- [Low] Silently ignored regmap_write() error in rk3568_lvds_grf_config().
--
--- Patch [3]: [PATCH 3/4] drm/rockchip: lvds: add RK3568 support ---
commit 42ee5aa3ee6adfe018b6f3294b12a2e7ab2076e3
Author: Rok Markovic <rok@kanardia.eu>
Date: Fri Jul 17 12:00:04 2026 +0000
drm/rockchip: lvds: add RK3568 support
This commit adds support for the RK3568 LVDS transmitter to the rockchip_lvds
driver. It configures the MIPI DSI0 D-PHY in PHY_MODE_LVDS and powers the
D-PHY from the encoder enable path instead of probe.
Link: https://lore.kernel.org/all/20230119184807.171132-1-a1ba.omarov@gmail.com/
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index 150299c12298a..cc56ca2580a66 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
[ ... ]
> @@ -435,6 +435,133 @@ static void px30_lvds_encoder_disable(struct drm_encoder *encoder)
> +static int rk3568_lvds_grf_config(struct drm_encoder *encoder,
> + struct drm_display_mode *mode)
> +{
[ ... ]
> + /*
> + * The LVDS block has its own dclk inversion select, separate from the
> + * VOP's pin polarity. Both have to agree with what the panel samples on.
> + */
> + regmap_write(lvds->grf, RK3568_GRF_VO_CON2,
> + RK3568_LVDS0_DCLK_INV_SEL(negedge));
> +
[Severity: Low]
Does this code silently ignore a potential error from regmap_write()?
If this first regmap_write() to RK3568_GRF_VO_CON2 fails, the DCLK inversion
configuration is not applied, but the function proceeds and only returns the
result of the second regmap_write() below.
> + /* Set format */
> + return regmap_write(lvds->grf, RK3568_GRF_VO_CON0,
> + RK3568_LVDS0_SELECT(lvds->format) |
> + RK3568_LVDS0_MSBSEL(1));
> +}
> +
> +static void rk3568_lvds_encoder_enable(struct drm_encoder *encoder)
> +{
[ ... ]
> + ret = rk3568_lvds_poweron(lvds);
> + if (ret) {
> + DRM_DEV_ERROR(lvds->dev, "failed to power on LVDS: %d\n", ret);
> + drm_panel_unprepare(lvds->panel);
> + return;
> + }
> +
> + ret = rk3568_lvds_grf_config(encoder, mode);
> + if (ret) {
> + DRM_DEV_ERROR(lvds->dev, "failed to configure LVDS: %d\n", ret);
> + drm_panel_unprepare(lvds->panel);
> + return;
> + }
> +
> + /*
> + * Only now bring the D-PHY up. phy_power_on() runs the whole
> + * inno_dsidphy_lvds_mode_enable() sequence - PLL and bandgap power-on,
[ ... ]
> + ret = phy_set_mode(lvds->dphy, PHY_MODE_LVDS);
> + if (ret) {
> + DRM_DEV_ERROR(lvds->dev, "failed to set phy mode: %d\n", ret);
> + drm_panel_unprepare(lvds->panel);
> + return;
> + }
> +
[Severity: High]
Can an early return here lead to an unbalanced phy_power_off() later?
If rk3568_lvds_encoder_enable() encounters an error and returns early before
calling phy_power_on(), the DRM core still treats the encoder as active since
the enable callback returns void.
When the display pipeline is subsequently disabled, the DRM core unconditionally
calls rk3568_lvds_encoder_disable(), which does this:
static void rk3568_lvds_encoder_disable(...)
{
...
phy_power_off(lvds->dphy);
...
}
This would decrement the PHY's power_count from 0 to -1. Future calls to
phy_power_on() will see a negative count, skip the actual hardware power-on
routine, and just increment the counter to 0, which leaves the PHY permanently
broken until reboot.
> + ret = phy_power_on(lvds->dphy);
> + if (ret) {
> + DRM_DEV_ERROR(lvds->dev, "failed to power on phy: %d\n", ret);
> + drm_panel_unprepare(lvds->panel);
> + return;
> + }
> +
> + drm_panel_enable(lvds->panel);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717120005.2087386-1-rok@kanardia.eu?part=3
^ permalink raw reply
* Re: [PATCH 1/4] drm/rockchip: lvds: propagate bus_flags to the CRTC state
From: sashiko-bot @ 2026-07-17 12:16 UTC (permalink / raw)
To: Rok Markovic; +Cc: devicetree, conor+dt, robh, dri-devel
In-Reply-To: <20260717120005.2087386-2-rok@kanardia.eu>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The newly introduced bus_flags assignment bypasses DRM bridge state negotiation by reading flags directly from the final connector instead of the adjacent bridge.
Pre-existing issues:
- [High] The driver unconditionally overwrites the function pointers and private data of external bridge objects, causing type confusion and completely breaking external bridge support.
--
--- Patch [1]: [PATCH 1/4] drm/rockchip: lvds: propagate bus_flags to the CRTC state ---
commit e03a59004874598201254d64c0f6e0e88de3ff1a
Author: Rok Markovic <rok@kanardia.eu>
drm/rockchip: lvds: propagate bus_flags to the CRTC state
This commit updates the Rockchip LVDS encoder's atomic_check function to
propagate bus_flags from the connector's display_info to the CRTC state.
This ensures that the VOP can correctly set the pixel clock polarity based
on the panel's requirements.
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index 7a0c4fa29f2f0..150299c12298a 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> @@ -129,7 +129,15 @@ rockchip_lvds_encoder_atomic_check(struct drm_encoder *encoder,
> struct drm_connector_state *conn_state)
> {
> struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
> -
> + struct drm_connector *connector = conn_state->connector;
> +
> + /*
> + * The VOP derives the pixel clock polarity from this. Without it a
> + * panel that declares pixelclk-active = <0> is clocked on the wrong
> + * edge. panel-lvds fills the connector's bus_flags in from the DT
> + * display timing.
> + */
> + s->bus_flags = connector->display_info.bus_flags;
[Severity: Medium]
Does this bypass DRM bridge state negotiation by reading flags directly from
the final connector instead of the adjacent bridge?
By reading from connector->display_info.bus_flags in
rockchip_lvds_encoder_atomic_check(), the VOP pixel clock polarity is
configured based on the final sink (e.g., an HDMI monitor) rather than the
LVDS bridge's input requirements.
This causes incorrect pixel clock polarity for external bridge setups, as it
violates DRM bridge chaining contracts which expect the state to be retrieved
via drm_atomic_get_new_bridge_state().
> s->output_mode = ROCKCHIP_OUT_MODE_P888;
> s->output_type = DRM_MODE_CONNECTOR_LVDS;
[Severity: High]
This isn't a bug introduced by this patch, but does the driver unconditionally
overwrite the function pointers and private data of external bridge objects in
rockchip_lvds_bind()?
When a valid external bridge is present, the initialization path overwrites
the bridge data:
rockchip_lvds_bind() {
...
if (lvds->bridge) {
lvds->bridge->driver_private = lvds;
lvds->bridge->ops = DRM_BRIDGE_OP_MODES;
lvds->bridge->funcs = &rockchip_lvds_bridge_funcs;
...
}
Does this hijack the external bridge by replacing its callbacks and private
data with LVDS-specific values?
This causes type confusion and prevents external bridges from ever being
enabled, since their callbacks are replaced by the LVDS functions. It also
seems likely to cause panics if the external bridge driver attempts to access
its original driver_private data.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717120005.2087386-1-rok@kanardia.eu?part=1
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: Add Glymur QCB
From: sashiko-bot @ 2026-07-17 12:15 UTC (permalink / raw)
To: Gopikrishna Garmidi; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260717-glymur-qcb-v1-4-aaf1cff84aab@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The device tree references a non-existent label `&remoteproc_soccp`, leading to a dtc compilation failure.
--
--- Patch [4]: [PATCH 4/4] arm64: dts: qcom: Add Glymur QCB ---
commit f3dbd3b60969af3a7e9b8324ba3c25e8c04a5c79
Author: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
arm64: dts: qcom: Add Glymur QCB
This commit adds the device tree for the Glymur QCB (Qualcomm Compute Board).
It enables various board components such as clocks, keys, PMIC regulators,
PCIe controllers, WiFi/BT, an embedded controller, and remote processors.
> diff --git a/arch/arm64/boot/dts/qcom/glymur-qcb.dts b/arch/arm64/boot/dts/qcom/glymur-qcb.dts
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/glymur-qcb.dts
[ ... ]
> +&remoteproc_cdsp {
> + firmware-name = "qcom/glymur/cdsp.mbn",
> + "qcom/glymur/cdsp_dtb.mbn";
> +
> + status = "okay";
> +};
> +
> +&remoteproc_soccp {
[Severity: Low]
Does this reference an undefined label? The remoteproc_soccp label does not
appear to be defined in glymur.dtsi or any of the included PMIC files, which
would cause a dtc compilation failure.
> + firmware-name = "qcom/glymur/soccp.mbn",
> + "qcom/glymur/soccp_dtb.mbn";
> +};
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717-glymur-qcb-v1-0-aaf1cff84aab@oss.qualcomm.com?part=4
^ permalink raw reply
* [PATCH 0/4] drm/rockchip: add RK3568 LVDS support
From: Rok Markovic @ 2026-07-17 12:00 UTC (permalink / raw)
To: Heiko Stuebner, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Alibek Omarov, Rok Markovic
RK3568 has a native LVDS transmitter that mainline does not support:
rockchip_lvds.c only binds rk3288 and px30. This series adds it.
The transmitter has no register block of its own. It is programmed
entirely through the GRF and re-uses the MIPI DSI0 D-PHY in
PHY_MODE_LVDS, which phy-rockchip-inno-dsidphy already supports. So the
DT node is reg-less and carries a phy reference, like px30, but unlike
px30 it also takes a pclk (PCLK_DSITX_0, borrowed from the DSI
controller the D-PHY belongs to).
Patch 1 is an independent fix: rockchip_lvds_encoder_atomic_check()
never copied the connector's bus_flags into the CRTC state, so a panel's
pixelclk-active could not reach the hardware at all. It is a no-op for
the SoCs supported today - rk3288 and px30 pair with the VOP1 driver,
which never reads bus_flags; only VOP2 consumes it - and becomes live
with patch 3.
Patches 2-4 add the binding, the driver and the SoC DT node. No existing
code paths are modified: patch 3 only adds rk3568 functions, and every
rk3288/px30 function is left byte-identical.
The driver work is based on Alibek Omarov's 2023 posting [1], which was
never merged. The changes on top of it are described in patch 3's
changelog. The important one: phy_power_on() must be called from the
encoder enable path, not from probe. Called at probe it runs the phy's
LVDS bring-up - PLL power-on, settle, mode select, serializer reset
pulse, lane enables - while the GRF has not yet switched the block to
LVDS mode and the VOP is not driving dclk. The serializer is clocked
from dclk and latches dead coming out of that reset. The failure mode is
nasty: every register in the phy, the GRF and the VOP reads back
byte-identical to a working system while the lanes sit at common mode
and never toggle.
[1] https://lore.kernel.org/all/20230119184807.171132-1-a1ba.omarov@gmail.com/
Not covered: LVDS1 / dual-channel. The GRF bits exist (VO_CON3) but I
have no hardware for it, so only LVDS0 is wired up.
One integration note for anyone using this: VOP2 spreads its windows
only over video ports that have a connected endpoint, and writes
cumulative layer boundaries into OVL_PORT_SEL. If LVDS is put on vp2
while vp1 has no endpoint, the boundaries come out non-monotonic
(PORT0=2, PORT1=8, PORT2=5) and no window ever reaches vp2. Putting LVDS
on vp1 avoids it. That looks like a separate VOP2 bug and is not
addressed here.
Testing
-------
Tested on two RK3568 boards:
- MYIR MYD-LR3568X eval board, 1024x600 LVDS panel at 59.4 MHz
- Kanardia Nesis V (custom board, MYIR MY3568 SOM), 1280x800 at 72 MHz
Both light up and scan out correctly; VOP2 reports the programmed mode
with real_clk matching the requested pixel clock.
What has *not* been tested:
- The boot testing above was done on 6.19.5, and with an earlier
revision of patch 3 that used regmap_update_bits() and powered the
phy from a shared helper. This series is rebased onto 7.1.3 and the
GRF accesses were reworked to regmap_write() after review; it is
compile-tested and the DTB builds, but this exact code has not been
booted. The register writes are equivalent by inspection.
- Patch 1 has not been tested on rk3288 or px30 hardware. The argument
that it cannot regress them is by inspection - VOP1 has no reader of
bus_flags - not by measurement. Review of that claim is welcome.
- Dual-channel/LVDS1 is untested (not implemented).
- Suspend/resume and DPMS cycling are untested. The P2S_EN re-assert
in patch 3 is what should make a second enable work; it is reasoned
from the poweroff path clearing it, not from a measured DPMS cycle.
dt_binding_check passes on patch 2. dtbs_check on the board DTB reports
no issues against the new lvds schema.
Tooling disclosure
------------------
Per Documentation/process/coding-assistants.rst and
generated-content.rst: this series was produced with the help of Claude
(claude-opus-4-8), used interactively across a long debugging session
rather than from a single prompt. The assistant read the vendor BSP
driver and the phy/VOP2 sources, identified the phy-ordering bug that
patch 3 fixes, and wrote the patch text and changelogs. All hardware
testing, every oscilloscope measurement and register dump, and the two
decisive debugging ideas - diffing register state against a working
vendor board, and using MIPI DSI on the shared D-PHY to prove the lanes
were good - were mine. I have reviewed every line and can defend it.
The Signed-off-by is mine alone.
No coccinelle/sparse/smatch runs were involved.
Rok Markovic (4):
drm/rockchip: lvds: propagate bus_flags to the CRTC state
dt-bindings: display: rockchip,lvds: add RK3568
drm/rockchip: lvds: add RK3568 support
arm64: dts: rockchip: rk356x: add LVDS node
.../display/rockchip/rockchip,lvds.yaml | 22 +++
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 25 +++
drivers/gpu/drm/rockchip/rockchip_lvds.c | 171 +++++++++++++++++-
drivers/gpu/drm/rockchip/rockchip_lvds.h | 10 +
4 files changed, 227 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: rockchip: rk356x: add LVDS node
From: sashiko-bot @ 2026-07-17 12:13 UTC (permalink / raw)
To: Rok Markovic; +Cc: conor+dt, robh, dri-devel, devicetree
In-Reply-To: <20260717120005.2087386-5-rok@kanardia.eu>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing Hardware Clock Initialization for RK3568 LVDS
- [Medium] Unbalanced Hardware Resource Teardown in Error Paths
--
--- Patch [4]: [PATCH 4/4] arm64: dts: rockchip: rk356x: add LVDS node ---
commit bfe12cef9ca639b004d58e050ef9175743345f7b
Author: Rok Markovic <rok@kanardia.eu>
arm64: dts: rockchip: rk356x: add LVDS node
This commit adds the LVDS transmitter node for the RK356x SoC, assigning
its clock, physical interface, and power domains. It is left disabled by
default, to be enabled by specific board files.
> diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> index a5832895bd392..2b3beab5507b1 100644
> --- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
> @@ -879,6 +879,31 @@ hdmi_out: port@1 {
> };
> };
>
> + lvds: lvds {
> + compatible = "rockchip,rk3568-lvds";
> + clocks = <&cru PCLK_DSITX_0>;
> + clock-names = "pclk_lvds";
[Severity: High]
Does the driver actually use this clock?
Looking at rk3568_lvds_probe() in drivers/gpu/drm/rockchip/rockchip_lvds.c,
it seems to completely omit fetching the required pclk_lvds clock from the
device tree:
drivers/gpu/drm/rockchip/rockchip_lvds.c:rk3568_lvds_probe() {
...
lvds->dphy = devm_phy_get(&pdev->dev, "dphy");
if (IS_ERR(lvds->dphy))
return PTR_ERR(lvds->dphy);
return phy_init(lvds->dphy);
}
Because lvds->pclk is left NULL, the clk_enable() call in
rk3568_lvds_poweron() acts as a no-op:
drivers/gpu/drm/rockchip/rockchip_lvds.c:rk3568_lvds_poweron() {
...
ret = clk_enable(lvds->pclk);
if (ret < 0) {
...
}
Will this cause hardware registers to be accessed without a running clock,
potentially leading to system hangs on device probe or modeset?
> + phys = <&dsi_dphy0>;
> + phy-names = "dphy";
> + power-domains = <&power RK3568_PD_VO>;
> + rockchip,grf = <&grf>;
> + rockchip,output = "lvds";
> + status = "disabled";
> +
> + ports {
[Severity: Medium]
Will enabling this hardware expose an unbalanced resource teardown in the
driver's error paths?
If intermediate steps like phy_set_mode() fail in
rk3568_lvds_encoder_enable(), the function returns early without rolling
back earlier successful calls:
drivers/gpu/drm/rockchip/rockchip_lvds.c:rk3568_lvds_encoder_enable() {
...
ret = phy_set_mode(lvds->dphy, PHY_MODE_LVDS);
if (ret) {
DRM_DEV_ERROR(lvds->dev, "failed to set phy mode: %d\n", ret);
drm_panel_unprepare(lvds->panel);
return;
}
...
}
Because .enable() returns void, the DRM core assumes it succeeded and will
later call .disable(). The rk3568_lvds_encoder_disable() function
unconditionally tears down all resources:
drivers/gpu/drm/rockchip/rockchip_lvds.c:rk3568_lvds_encoder_disable() {
struct rockchip_lvds *lvds = encoder_to_lvds(encoder);
drm_panel_disable(lvds->panel);
phy_power_off(lvds->dphy);
rk3568_lvds_poweroff(lvds);
drm_panel_unprepare(lvds->panel);
}
Could this cause refcount underflows for PHY, PM runtime, and clocks,
resulting in kernel warnings if they were never successfully enabled?
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + lvds_in: port@0 {
> + reg = <0>;
> + };
> +
> + lvds_out: port@1 {
> + reg = <1>;
> + };
> + };
> + };
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717120005.2087386-1-rok@kanardia.eu?part=4
^ permalink raw reply
* [PATCH v3 11/11] arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS1088A SoC. The nodes are left disabled at the SoC level; board
DTs will enable them once there are consumers.
Note that the SerDes block #2 is non-networking, meaning that it will
not get probed by the Lynx10G SerDes PHY driver and it's only added for
a complete hardware description.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- None
Changes in v2:
- Change the size of the region to 0x2000
---
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index 99016768b73f..e02f34329988 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -239,6 +239,64 @@ reset: syscon@1e60000 {
reg = <0x0 0x1e60000 0x0 0x10000>;
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls1088a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls1088a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
isc: syscon@1f70000 {
compatible = "fsl,ls1088a-isc", "syscon";
reg = <0x0 0x1f70000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* [PATCH v3 10/11] arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS208xA SoC. The nodes are left disabled at the SoC level; board
DTs will enable them once there are consumers.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- None
Changes in v2:
- Change the size of the region to 0x2000
---
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 +++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index 6073e426774a..cc1a64e63ed5 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -280,6 +280,104 @@ sfp: efuse@1e80000 {
clock-names = "sfp";
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls2088a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls2088a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
isc: syscon@1f70000 {
compatible = "fsl,ls2080a-isc", "syscon";
reg = <0x0 0x1f70000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* [PATCH v3 09/11] arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the two Lynx 10G SerDes blocks and their associated lanes found
on the LS1046A SoC. The nodes are left disabled at the SoC level; board
DTs will be expected to enable them once the consumer Ethernet nodes
appear.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- None
Changes in v2:
- Change the size of the region to 0x2000
---
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 +++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 6fefe837f434..270a97711a69 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -424,6 +424,66 @@ sfp: efuse@1e80000 {
clock-names = "sfp";
};
+ serdes1: phy@1ea0000 {
+ compatible = "fsl,ls1046a-serdes1";
+ reg = <0x00 0x1ea0000 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ big-endian;
+ status = "disabled";
+
+ serdes1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes2: phy@1eb0000 {
+ compatible = "fsl,ls1046a-serdes2";
+ reg = <0x00 0x1eb0000 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ big-endian;
+ status = "disabled";
+
+ serdes2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
dcfg: dcfg@1ee0000 {
compatible = "fsl,ls1046a-dcfg", "syscon";
reg = <0x0 0x1ee0000 0x0 0x1000>;
--
2.25.1
^ permalink raw reply related
* [PATCH v3 08/11] arm64: dts: ls1028a: describe the Lynx 10G SerDes
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Describe the Lynx 10G SerDes block and its 4 SerDes lanes found on the
LS1028A SoC. The node is left disabled at the SoC level; board DTs will
be expected to enable it once the consumer Ethernet nodes use it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- None
Changes in v2:
- Change the size of the region to 0x2000
---
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 +++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index f4ba3d16ab86..ef62968590fa 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -250,6 +250,35 @@ ls1028a_uid: unique-id@1c {
};
};
+ serdes: phy@1ea0000 {
+ compatible = "fsl,ls1028a-serdes";
+ reg = <0x00 0x1ea0000 0x0 0x2000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+ };
+
scfg: syscon@1fc0000 {
compatible = "fsl,ls1028a-scfg", "syscon";
reg = <0x0 0x1fc0000 0x0 0x10000>;
--
2.25.1
^ permalink raw reply related
* [PATCH v3 07/11] arm64: dts: lx2162a: transition to device-specific SerDes compatible strings
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
Align to the modern fsl,lynx-28g.yaml binding for the LX2162A SoC, where
the SoC and SerDes instance is present in the compatible string, to
allow reliable per-lane capability detection and per-lane customization
of electrical properties.
Since one of the major differences between LX2162A and LX2160A is the
SerDes, add the necessary nodes to its own fsl-lx2162a-serdes.dtsi file.
Also mark the serdes_1 node as disabled by default since any dts using
it enables it explicitly now.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- New patch
---
.../dts/freescale/fsl-lx2162a-serdes.dtsi | 69 ++++++++++++++++++-
1 file changed, 67 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
index 23f05a138eac..1ab18f0c67c2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
@@ -7,15 +7,80 @@
&soc {
serdes_1: phy@1ea0000 {
- compatible = "fsl,lynx-28g";
+ compatible = "fsl,lx2162a-serdes1", "fsl,lynx-28g";
reg = <0x0 0x1ea0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#phy-cells = <1>;
+ status = "disabled";
+
+ serdes_1_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
};
serdes_2: phy@1eb0000 {
- compatible = "fsl,lynx-28g";
+ compatible = "fsl,lx2162a-serdes2", "fsl,lynx-28g";
reg = <0x0 0x1eb0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#phy-cells = <1>;
status = "disabled";
+
+ serdes_2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
};
};
--
2.25.1
^ permalink raw reply related
* [PATCH v3 06/11] arm64: dts: lx2160a: transition to device-specific SerDes compatible strings
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
Align to the modern fsl,lynx-28g.yaml binding, where the SoC and SerDes
instance is present in the compatible string, to allow reliable per-lane
capability detection and per-lane customization of electrical properties.
The modern bindings are backward-incompatible with old kernels, due
to the consumer phandles being either in one form or in another, as
explained here:
https://lore.kernel.org/lkml/20250930140735.mvo3jii7wgmzh2bs@skbuf/
Also mark the serdes_1 node as disabled by default since any dts using
it enables it explicitly now.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- Split the enabling of serdes_1 into a separate patch
- Split the LX2162A changes to another patch
- Move the status property to be the last for serdes_3
- Move the changes to the new fsl-lx2160a-serdes.dtsi file
Changes in v2:
- Enable serdes_1 on all board DTs that has consumers for it.
- Use the proper name for serdes_3 in fsl-lx2162a.dtsi.
- Remove paragraph from commit message which mentioned some consumer
changes that are no longer needed nor part of the commit.
---
.../dts/freescale/fsl-lx2160a-serdes.dtsi | 150 +++++++++++++++++-
1 file changed, 148 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
index 307824eda6d6..d482920f4d17 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
@@ -6,16 +6,162 @@
// Copyright 2026 NXP
&soc {
+ /* Note on the interpretation of SerDes lane numbering from
+ * LX2160ARM lane mappings for RCW[SRDS_PRTCL_S1]:
+ * The letters (A-H) correspond to logical lane numbers in the
+ * SerDes register map (lane A's registers start with LNAGCR0),
+ * while the numbers (0-7) correspond to physical lanes as
+ * routed to pins. SerDes block #1 is flipped in the LX2160A
+ * floorplan (logical lane A goes to physical lane 7's pins),
+ * while SerDes blocks #2 and #3 are not. The lanes below are
+ * listed right to left when looking at that table.
+ * Both the numbers and the letters are according to the logical
+ * numbering scheme, and do not account for the flipping.
+ */
serdes_1: phy@1ea0000 {
- compatible = "fsl,lynx-28g";
+ compatible = "fsl,lx2160a-serdes1", "fsl,lynx-28g";
reg = <0x0 0x1ea0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#phy-cells = <1>;
+ status = "disabled";
+
+ serdes_1_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_1_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
};
serdes_2: phy@1eb0000 {
- compatible = "fsl,lynx-28g";
+ compatible = "fsl,lx2160a-serdes2", "fsl,lynx-28g";
reg = <0x0 0x1eb0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
#phy-cells = <1>;
status = "disabled";
+
+ serdes_2_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_2_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
+ };
+
+ serdes_3: phy@1ec0000 {
+ compatible = "fsl,lx2160a-serdes3";
+ reg = <0x0 0x1ec0000 0x0 0x1e30>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+
+ serdes_3_lane_a: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_b: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_c: phy@2 {
+ reg = <2>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_d: phy@3 {
+ reg = <3>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_e: phy@4 {
+ reg = <4>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_f: phy@5 {
+ reg = <5>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_g: phy@6 {
+ reg = <6>;
+ #phy-cells = <0>;
+ };
+
+ serdes_3_lane_h: phy@7 {
+ reg = <7>;
+ #phy-cells = <0>;
+ };
};
};
--
2.25.1
^ permalink raw reply related
* [PATCH v3 05/11] arm64: dts: lx2160a: split the dtsi to avoid delete-property
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
This patch reorganizes the LX216XA related dts/dtsi files with the
intent to avoid any delete-property usage.
Taken into consideration the differences between the LX2160A Rev1,
LX2160A Rev2 and LX2162A SoCs, the following structure is created:
fsl-lx216x.dtsi ---> fsl-lx2160a-rev1.dtsi (PCIe gen4, 3 SerDes blocks)
(no PCIe, no SerDes) ---> fsl-lx2160a-rev2.dtsi (PCIe gen3, 3 SerDes blocks)
---> fsl-lx2162a.dtsi (PCIe gen3, 2 SerDes blocks)
Each PCIe integration or SerDes block instantiation has its own dtsi
file which gets to be included only by the necessary SoC level dtsi
file.
The dtsi file describing the PCIe controllers found on LX2160A Rev2 is
also changed so that it does not work on a already defined node but
rather it describes it entirely.
In order to decouple the LX2162A from LX2160A, a new dtsi
fsl-lx2162a-serdes.dtsi file is added which, for the moment, only
duplicates the SerDes related nodes found already for LX2160A.
Any dts which previously included fsl-lx2160a.dtsi now includes the
-rev1 version and any dts which is clearly intended for LX2162A based
board now includes the fsl-lx2162a.dtsi. This patch does not intent any
changes into the final dtbs.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- New patch
- The only changes in the final dtbs are phandle related ones.
---
.../dts/freescale/fsl-lx2160a-bluebox3.dts | 2 +-
.../dts/freescale/fsl-lx2160a-clearfog-cx.dts | 2 +-
.../dts/freescale/fsl-lx2160a-honeycomb.dts | 2 +-
.../boot/dts/freescale/fsl-lx2160a-rev1.dtsi | 9 +
.../boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 3 +-
.../dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 2 +-
.../dts/freescale/fsl-lx2162a-clearfog.dts | 2 +-
.../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
.../dts/freescale/fsl-lx2162a-serdes.dtsi | 21 ++
.../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 9 +
.../{fsl-lx2160a.dtsi => fsl-lx216x.dtsi} | 3 -
.../dts/freescale/fsl-lx216xa-pcie-gen3.dtsi | 304 +++++++++++-------
12 files changed, 234 insertions(+), 127 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-rev1.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
rename arch/arm64/boot/dts/freescale/{fsl-lx2160a.dtsi => fsl-lx216x.dtsi} (99%)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
index 042c486bdda2..e035e4456867 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
@@ -6,7 +6,7 @@
/dts-v1/;
-#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-rev1.dtsi"
/ {
model = "NXP Layerscape LX2160ABLUEBOX3";
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
index 802d7611c647..4e47bb389af6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-cx.dts
@@ -6,7 +6,7 @@
/dts-v1/;
-#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-rev1.dtsi"
#include "fsl-lx2160a-cex7.dtsi"
#include "fsl-lx2160a-clearfog-itx.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
index 2b1e13053422..1a603decd034 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
@@ -6,7 +6,7 @@
/dts-v1/;
-#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-rev1.dtsi"
#include "fsl-lx2160a-cex7.dtsi"
#include "fsl-lx2160a-clearfog-itx.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev1.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev1.dtsi
new file mode 100644
index 000000000000..7538dbdc8093
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev1.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree Include file for Layerscape-LX2160A Rev1 SoC.
+//
+// Copyright 2026 NXP
+
+#include "fsl-lx216x.dtsi"
+#include "fsl-lx2160a-pcie-mbvl.dtsi"
+#include "fsl-lx2160a-serdes.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
index c2a18cfd8efc..47a42347c230 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
@@ -6,5 +6,6 @@
/dts-v1/;
-#include "fsl-lx2160a.dtsi"
+#include "fsl-lx216x.dtsi"
#include "fsl-lx216xa-pcie-gen3.dtsi"
+#include "fsl-lx2160a-serdes.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
index 89a4765737b4..cc6b6427ec8a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
@@ -5,7 +5,7 @@
* Author: Gregor Herburger
*/
-#include "fsl-lx2160a.dtsi"
+#include "fsl-lx2160a-rev1.dtsi"
/ {
reg_vcc3v3: regulator-vcc3v3 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index df2568ec7f1a..63f161610caa 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -8,7 +8,7 @@
#include <dt-bindings/leds/common.h>
-#include "fsl-lx2160a-rev2.dtsi"
+#include "fsl-lx2162a.dtsi"
#include "fsl-lx2162a-sr-som.dtsi"
/ {
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
index 7a595fddc027..0ba56b9819ac 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-qds.dts
@@ -6,7 +6,7 @@
/dts-v1/;
-#include "fsl-lx2160a-rev2.dtsi"
+#include "fsl-lx2162a.dtsi"
/ {
model = "NXP Layerscape LX2162AQDS";
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
new file mode 100644
index 000000000000..23f05a138eac
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree file describing the Lynx 28G SerDes blocks found on the LX2162A
+// SoC
+//
+// Copyright 2026 NXP
+
+&soc {
+ serdes_1: phy@1ea0000 {
+ compatible = "fsl,lynx-28g";
+ reg = <0x0 0x1ea0000 0x0 0x1e30>;
+ #phy-cells = <1>;
+ };
+
+ serdes_2: phy@1eb0000 {
+ compatible = "fsl,lynx-28g";
+ reg = <0x0 0x1eb0000 0x0 0x1e30>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
new file mode 100644
index 000000000000..b710f6a8eb48
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree file for LX2162 SoC
+//
+// Copyright 2026 NXP
+
+#include "fsl-lx216x.dtsi"
+#include "fsl-lx216xa-pcie-gen3.dtsi"
+#include "fsl-lx2162a-serdes.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx216x.dtsi
similarity index 99%
rename from arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
rename to arch/arm64/boot/dts/freescale/fsl-lx216x.dtsi
index da139e7fa30c..ae6e37870c5e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx216x.dtsi
@@ -1840,6 +1840,3 @@ optee: optee {
};
};
};
-
-#include "fsl-lx2160a-pcie-mbvl.dtsi"
-#include "fsl-lx2160a-serdes.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
index f405b21e68fc..068fbf9bf04f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
@@ -4,127 +4,39 @@
//
// Copyright 2026 NXP
-&pcie1 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
- 0x80 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie2 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
- 0x88 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0x88 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0x88 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0x8c 0x00000000 0x8c 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie3 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
- 0x90 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0x90 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0x90 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0x94 0x00000000 0x94 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie4 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03700000 0x0 0x00100000 /* controller registers */
- 0x98 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0x98 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0x98 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0x9c 0x00000000 0x9c 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie5 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03800000 0x0 0x00100000 /* controller registers */
- 0xa0 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0xa0 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0xa0 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0xa4 0x00000000 0xa4 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie6 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03900000 0x0 0x00100000 /* controller registers */
- 0xa8 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
+&soc {
+ pcie1: pcie@3400000 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
+ 0x80 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0xa8 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0xa8 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0xac 0x00000000 0xac 0x00000000 0x04 0x00000000>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ bus-range = <0x0 0xff>;
- interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>;
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
-&soc {
pcie_ep1: pcie-ep@3400000 {
compatible = "fsl,lx2160ar2-pcie-ep";
reg = <0x00 0x03400000 0x0 0x00100000
@@ -135,6 +47,37 @@ pcie_ep1: pcie-ep@3400000 {
status = "disabled";
};
+ pcie2: pcie@3500000 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
+ 0x88 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ bus-range = <0x0 0xff>;
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0x88 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0x88 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0x8c 0x00000000 0x8c 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
pcie_ep2: pcie-ep@3500000 {
compatible = "fsl,lx2160ar2-pcie-ep";
reg = <0x00 0x03500000 0x0 0x00100000
@@ -145,6 +88,38 @@ pcie_ep2: pcie-ep@3500000 {
status = "disabled";
};
+ pcie3: pcie@3600000 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
+ 0x90 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ bus-range = <0x0 0xff>;
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0x90 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0x90 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0x94 0x00000000 0x94 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
pcie_ep3: pcie-ep@3600000 {
compatible = "fsl,lx2160ar2-pcie-ep";
reg = <0x00 0x03600000 0x0 0x00100000
@@ -155,6 +130,37 @@ pcie_ep3: pcie-ep@3600000 {
status = "disabled";
};
+ pcie4: pcie@3700000 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03700000 0x0 0x00100000 /* controller registers */
+ 0x98 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ bus-range = <0x0 0xff>;
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0x98 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0x98 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0x9c 0x00000000 0x9c 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
pcie_ep4: pcie-ep@3700000 {
compatible = "fsl,lx2160ar2-pcie-ep";
reg = <0x00 0x03700000 0x0 0x00100000
@@ -165,6 +171,38 @@ pcie_ep4: pcie-ep@3700000 {
status = "disabled";
};
+ pcie5: pcie@3800000 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03800000 0x0 0x00100000 /* controller registers */
+ 0xa0 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ bus-range = <0x0 0xff>;
+
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0xa0 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0xa0 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0xa4 0x00000000 0xa4 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
pcie_ep5: pcie-ep@3800000 {
compatible = "fsl,lx2160ar2-pcie-ep";
reg = <0x00 0x03800000 0x0 0x00100000
@@ -175,6 +213,38 @@ pcie_ep5: pcie-ep@3800000 {
status = "disabled";
};
+ pcie6: pcie@3900000 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03900000 0x0 0x00100000 /* controller registers */
+ 0xa8 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ bus-range = <0x0 0xff>;
+
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0xa8 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0xa8 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0xac 0x00000000 0xac 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
pcie_ep6: pcie-ep@3900000 {
compatible = "fsl,lx2160ar2-pcie-ep";
reg = <0x00 0x03900000 0x0 0x00100000
--
2.25.1
^ permalink raw reply related
* [PATCH v3 04/11] arm64: dts: lx2160a: extract the PCIe from LX2160A Rev2 into a separate file
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
The LX2160A Rev2 SoC changed the PCIe controllers used. This difference
is reflected in the fsl-lx2160a-rev2.dtsi file which modifies the
relevant dt nodes so that they match the actual HW.
Extract these modifications into a separate dtsi file as a first step
into a complete overhaul of the LX216xA related dts files with the
intent to not use delete-node or delete-property. No final dtb changes
are expected with this patch.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- New patch
---
.../boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 185 +----------------
.../dts/freescale/fsl-lx216xa-pcie-gen3.dtsi | 187 ++++++++++++++++++
2 files changed, 188 insertions(+), 184 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
index 3d2637fee2d3..c2a18cfd8efc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
@@ -7,187 +7,4 @@
/dts-v1/;
#include "fsl-lx2160a.dtsi"
-
-&pcie1 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
- 0x80 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie2 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
- 0x88 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0x88 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0x88 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0x8c 0x00000000 0x8c 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie3 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
- 0x90 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0x90 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0x90 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0x94 0x00000000 0x94 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-
-&pcie4 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03700000 0x0 0x00100000 /* controller registers */
- 0x98 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0x98 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0x98 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0x9c 0x00000000 0x9c 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie5 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03800000 0x0 0x00100000 /* controller registers */
- 0xa0 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0xa0 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0xa0 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0xa4 0x00000000 0xa4 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&pcie6 {
- compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
- reg = <0x00 0x03900000 0x0 0x00100000 /* controller registers */
- 0xa8 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "regs", "config";
-
- ranges = /* 16-Bit IO Window */
- <0x81000000 0x00 0x00000000 0xa8 0x00010000 0x00 0x00010000>,
- /* 32-Bit - non-prefetchable */
- <0x82000000 0x00 0x40000000 0xa8 0x40000000 0x00 0x40000000>,
- /* 64-Bit - prefetchable - 16GB */
- <0xC3000000 0xac 0x00000000 0xac 0x00000000 0x04 0x00000000>;
-
- interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "intr";
-
- /delete-property/ apio-wins;
- /delete-property/ ppio-wins;
-};
-
-&soc {
- pcie_ep1: pcie-ep@3400000 {
- compatible = "fsl,lx2160ar2-pcie-ep";
- reg = <0x00 0x03400000 0x0 0x00100000
- 0x80 0x00000000 0x8 0x00000000>;
- reg-names = "regs", "addr_space";
- num-ob-windows = <8>;
- num-ib-windows = <8>;
- status = "disabled";
- };
-
- pcie_ep2: pcie-ep@3500000 {
- compatible = "fsl,lx2160ar2-pcie-ep";
- reg = <0x00 0x03500000 0x0 0x00100000
- 0x88 0x00000000 0x8 0x00000000>;
- reg-names = "regs", "addr_space";
- num-ob-windows = <8>;
- num-ib-windows = <8>;
- status = "disabled";
- };
-
- pcie_ep3: pcie-ep@3600000 {
- compatible = "fsl,lx2160ar2-pcie-ep";
- reg = <0x00 0x03600000 0x0 0x00100000
- 0x90 0x00000000 0x8 0x00000000>;
- reg-names = "regs", "addr_space";
- num-ob-windows = <256>;
- num-ib-windows = <24>;
- status = "disabled";
- };
-
- pcie_ep4: pcie-ep@3700000 {
- compatible = "fsl,lx2160ar2-pcie-ep";
- reg = <0x00 0x03700000 0x0 0x00100000
- 0x98 0x00000000 0x8 0x00000000>;
- reg-names = "regs", "addr_space";
- num-ob-windows = <8>;
- num-ib-windows = <8>;
- status = "disabled";
- };
-
-
- pcie_ep5: pcie-ep@3800000 {
- compatible = "fsl,lx2160ar2-pcie-ep";
- reg = <0x00 0x03800000 0x0 0x00100000
- 0xa0 0x00000000 0x8 0x00000000>;
- reg-names = "regs", "addr_space";
- num-ob-windows = <256>;
- num-ib-windows = <24>;
- status = "disabled";
- };
-
- pcie_ep6: pcie-ep@3900000 {
- compatible = "fsl,lx2160ar2-pcie-ep";
- reg = <0x00 0x03900000 0x0 0x00100000
- 0xa8 0x00000000 0x8 0x00000000>;
- reg-names = "regs", "addr_space";
- num-ob-windows = <8>;
- num-ib-windows = <8>;
- status = "disabled";
- };
-};
+#include "fsl-lx216xa-pcie-gen3.dtsi"
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
new file mode 100644
index 000000000000..f405b21e68fc
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
@@ -0,0 +1,187 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree file describing the PCIe IPs found on the LX2160A Rev2 and LX2162A SoCs
+//
+// Copyright 2026 NXP
+
+&pcie1 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03400000 0x0 0x00100000 /* controller registers */
+ 0x80 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+
+ /delete-property/ apio-wins;
+ /delete-property/ ppio-wins;
+};
+
+&pcie2 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03500000 0x0 0x00100000 /* controller registers */
+ 0x88 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0x88 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0x88 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0x8c 0x00000000 0x8c 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+
+ /delete-property/ apio-wins;
+ /delete-property/ ppio-wins;
+};
+
+&pcie3 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03600000 0x0 0x00100000 /* controller registers */
+ 0x90 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0x90 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0x90 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0x94 0x00000000 0x94 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+
+ /delete-property/ apio-wins;
+ /delete-property/ ppio-wins;
+};
+
+&pcie4 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03700000 0x0 0x00100000 /* controller registers */
+ 0x98 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0x98 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0x98 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0x9c 0x00000000 0x9c 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+
+ /delete-property/ apio-wins;
+ /delete-property/ ppio-wins;
+};
+
+&pcie5 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03800000 0x0 0x00100000 /* controller registers */
+ 0xa0 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0xa0 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0xa0 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0xa4 0x00000000 0xa4 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+
+ /delete-property/ apio-wins;
+ /delete-property/ ppio-wins;
+};
+
+&pcie6 {
+ compatible = "fsl,lx2160ar2-pcie", "fsl,ls2088a-pcie";
+ reg = <0x00 0x03900000 0x0 0x00100000 /* controller registers */
+ 0xa8 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "regs", "config";
+
+ ranges = /* 16-Bit IO Window */
+ <0x81000000 0x00 0x00000000 0xa8 0x00010000 0x00 0x00010000>,
+ /* 32-Bit - non-prefetchable */
+ <0x82000000 0x00 0x40000000 0xa8 0x40000000 0x00 0x40000000>,
+ /* 64-Bit - prefetchable - 16GB */
+ <0xC3000000 0xac 0x00000000 0xac 0x00000000 0x04 0x00000000>;
+
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "intr";
+
+ /delete-property/ apio-wins;
+ /delete-property/ ppio-wins;
+};
+
+&soc {
+ pcie_ep1: pcie-ep@3400000 {
+ compatible = "fsl,lx2160ar2-pcie-ep";
+ reg = <0x00 0x03400000 0x0 0x00100000
+ 0x80 0x00000000 0x8 0x00000000>;
+ reg-names = "regs", "addr_space";
+ num-ob-windows = <8>;
+ num-ib-windows = <8>;
+ status = "disabled";
+ };
+
+ pcie_ep2: pcie-ep@3500000 {
+ compatible = "fsl,lx2160ar2-pcie-ep";
+ reg = <0x00 0x03500000 0x0 0x00100000
+ 0x88 0x00000000 0x8 0x00000000>;
+ reg-names = "regs", "addr_space";
+ num-ob-windows = <8>;
+ num-ib-windows = <8>;
+ status = "disabled";
+ };
+
+ pcie_ep3: pcie-ep@3600000 {
+ compatible = "fsl,lx2160ar2-pcie-ep";
+ reg = <0x00 0x03600000 0x0 0x00100000
+ 0x90 0x00000000 0x8 0x00000000>;
+ reg-names = "regs", "addr_space";
+ num-ob-windows = <256>;
+ num-ib-windows = <24>;
+ status = "disabled";
+ };
+
+ pcie_ep4: pcie-ep@3700000 {
+ compatible = "fsl,lx2160ar2-pcie-ep";
+ reg = <0x00 0x03700000 0x0 0x00100000
+ 0x98 0x00000000 0x8 0x00000000>;
+ reg-names = "regs", "addr_space";
+ num-ob-windows = <8>;
+ num-ib-windows = <8>;
+ status = "disabled";
+ };
+
+ pcie_ep5: pcie-ep@3800000 {
+ compatible = "fsl,lx2160ar2-pcie-ep";
+ reg = <0x00 0x03800000 0x0 0x00100000
+ 0xa0 0x00000000 0x8 0x00000000>;
+ reg-names = "regs", "addr_space";
+ num-ob-windows = <256>;
+ num-ib-windows = <24>;
+ status = "disabled";
+ };
+
+ pcie_ep6: pcie-ep@3900000 {
+ compatible = "fsl,lx2160ar2-pcie-ep";
+ reg = <0x00 0x03900000 0x0 0x00100000
+ 0xa8 0x00000000 0x8 0x00000000>;
+ reg-names = "regs", "addr_space";
+ num-ob-windows = <8>;
+ num-ib-windows = <8>;
+ status = "disabled";
+ };
+};
--
2.25.1
^ permalink raw reply related
* [PATCH v3 03/11] arm64: dts: lx2160a: extract the SerDes nodes into a separate dtsi
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
In terms of its SerDes blocks, the LX2162A is not properly described
since it just inherits the LX2160A SerDes nodes, which is not correct.
In order to fix this but also avoid the usage of delete-node, we need to
first extract the SerDes nodes currently found in fsl-lx2160a.dtsi into a
separate dtsi.
This patch does not intend to do any actual changes in the final dtb
files, only a dt node move.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- New patch
---
.../dts/freescale/fsl-lx2160a-serdes.dtsi | 21 +++++++++++++++++++
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 14 +------------
2 files changed, 22 insertions(+), 13 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
new file mode 100644
index 000000000000..307824eda6d6
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree file describing the Lynx 28G SerDes blocks found on the LX2160A
+// Rev1 and Rev2
+//
+// Copyright 2026 NXP
+
+&soc {
+ serdes_1: phy@1ea0000 {
+ compatible = "fsl,lynx-28g";
+ reg = <0x0 0x1ea0000 0x0 0x1e30>;
+ #phy-cells = <1>;
+ };
+
+ serdes_2: phy@1eb0000 {
+ compatible = "fsl,lynx-28g";
+ reg = <0x0 0x1eb0000 0x0 0x1e30>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 387cd677cdc7..da139e7fa30c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -621,19 +621,6 @@ soc: soc {
ranges;
dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
- serdes_1: phy@1ea0000 {
- compatible = "fsl,lynx-28g";
- reg = <0x0 0x1ea0000 0x0 0x1e30>;
- #phy-cells = <1>;
- };
-
- serdes_2: phy@1eb0000 {
- compatible = "fsl,lynx-28g";
- reg = <0x0 0x1eb0000 0x0 0x1e30>;
- #phy-cells = <1>;
- status = "disabled";
- };
-
crypto: crypto@8000000 {
compatible = "fsl,sec-v5.0", "fsl,sec-v4.0";
fsl,sec-era = <10>;
@@ -1855,3 +1842,4 @@ optee: optee {
};
#include "fsl-lx2160a-pcie-mbvl.dtsi"
+#include "fsl-lx2160a-serdes.dtsi"
--
2.25.1
^ permalink raw reply related
* [PATCH v3 02/11] arm64: dts: lx2160a: extract the PCIe nodes into a separate dtsi
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
One of the major differences between LX2160A Rev1 and Rev2 is the PCIe
controller used. With the final goal of removing any usage of
delete-node or delete-property from the current LX2160A related dts
files, move the PCIe nodes found on the LX2160A Rev1 into a separate
dtsi file. This will make it easier to include the appropriate dtsi
file describing the PCIe controller depending on the SoC revision in a
follow-up patch.
No actual change in the DT nodes found in the final DTBs is intended.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- New patch
---
.../dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi | 176 ++++++++++++++++++
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 170 +----------------
2 files changed, 178 insertions(+), 168 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi
new file mode 100644
index 000000000000..871f5d5d8f75
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi
@@ -0,0 +1,176 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+//
+// Device Tree file describing the PCIe Mobiveil's GPEX 4.0 IP
+// found on LX2160A Rev1
+//
+// Copyright 2026 NXP
+
+&soc {
+ pcie1: pcie@3400000 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */
+ <0x80 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
+ pcie2: pcie@3500000 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x03500000 0x0 0x00100000>, /* controller registers */
+ <0x88 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
+ pcie3: pcie@3600000 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x03600000 0x0 0x00100000>, /* controller registers */
+ <0x90 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <256>;
+ ppio-wins = <24>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x82000000 0x0 0x40000000 0x90 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
+ pcie4: pcie@3700000 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x03700000 0x0 0x00100000>, /* controller registers */
+ <0x98 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x82000000 0x0 0x40000000 0x98 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
+ pcie5: pcie@3800000 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x03800000 0x0 0x00100000>, /* controller registers */
+ <0xa0 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
+ <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <256>;
+ ppio-wins = <24>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x82000000 0x0 0x40000000 0xa0 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+
+ pcie6: pcie@3900000 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x03900000 0x0 0x00100000>, /* controller registers */
+ <0xa8 0x00000000 0x0 0x00002000>; /* configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
+ <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x82000000 0x0 0x40000000 0xa8 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
+ msi-parent = <&its 0>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 2 &gic 0 0 GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 3 &gic 0 0 GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+ <0000 0 0 4 &gic 0 0 GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+ iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
+ status = "disabled";
+ };
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 1d73abffa6b7..387cd677cdc7 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -1177,174 +1177,6 @@ sata3: sata@3230000 {
status = "disabled";
};
- pcie1: pcie@3400000 {
- compatible = "fsl,lx2160a-pcie";
- reg = <0x00 0x03400000 0x0 0x00100000>, /* controller registers */
- <0x80 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "csr_axi_slave", "config_axi_slave";
- interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
- <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
- <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "aer", "pme", "intr";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- dma-coherent;
- apio-wins = <8>;
- ppio-wins = <8>;
- bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&its 0>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 2 &gic 0 0 GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 3 &gic 0 0 GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 4 &gic 0 0 GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
- iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
- status = "disabled";
- };
-
- pcie2: pcie@3500000 {
- compatible = "fsl,lx2160a-pcie";
- reg = <0x00 0x03500000 0x0 0x00100000>, /* controller registers */
- <0x88 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "csr_axi_slave", "config_axi_slave";
- interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
- <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
- <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "aer", "pme", "intr";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- dma-coherent;
- apio-wins = <8>;
- ppio-wins = <8>;
- bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x88 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&its 0>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 2 &gic 0 0 GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 3 &gic 0 0 GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 4 &gic 0 0 GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>;
- iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
- status = "disabled";
- };
-
- pcie3: pcie@3600000 {
- compatible = "fsl,lx2160a-pcie";
- reg = <0x00 0x03600000 0x0 0x00100000>, /* controller registers */
- <0x90 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "csr_axi_slave", "config_axi_slave";
- interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
- <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
- <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "aer", "pme", "intr";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- dma-coherent;
- apio-wins = <256>;
- ppio-wins = <24>;
- bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x90 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&its 0>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 2 &gic 0 0 GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 3 &gic 0 0 GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 4 &gic 0 0 GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
- iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
- status = "disabled";
- };
-
- pcie4: pcie@3700000 {
- compatible = "fsl,lx2160a-pcie";
- reg = <0x00 0x03700000 0x0 0x00100000>, /* controller registers */
- <0x98 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "csr_axi_slave", "config_axi_slave";
- interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
- <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
- <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "aer", "pme", "intr";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- dma-coherent;
- apio-wins = <8>;
- ppio-wins = <8>;
- bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0x98 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&its 0>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 2 &gic 0 0 GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 3 &gic 0 0 GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 4 &gic 0 0 GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
- iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
- status = "disabled";
- };
-
- pcie5: pcie@3800000 {
- compatible = "fsl,lx2160a-pcie";
- reg = <0x00 0x03800000 0x0 0x00100000>, /* controller registers */
- <0xa0 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "csr_axi_slave", "config_axi_slave";
- interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
- <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
- <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "aer", "pme", "intr";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- dma-coherent;
- apio-wins = <256>;
- ppio-wins = <24>;
- bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0xa0 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&its 0>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 2 &gic 0 0 GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 3 &gic 0 0 GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 4 &gic 0 0 GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
- iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
- status = "disabled";
- };
-
- pcie6: pcie@3900000 {
- compatible = "fsl,lx2160a-pcie";
- reg = <0x00 0x03900000 0x0 0x00100000>, /* controller registers */
- <0xa8 0x00000000 0x0 0x00002000>; /* configuration space */
- reg-names = "csr_axi_slave", "config_axi_slave";
- interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
- <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
- <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
- interrupt-names = "aer", "pme", "intr";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- dma-coherent;
- apio-wins = <8>;
- ppio-wins = <8>;
- bus-range = <0x0 0xff>;
- ranges = <0x82000000 0x0 0x40000000 0xa8 0x40000000 0x0 0x40000000>; /* non-prefetchable memory */
- msi-parent = <&its 0>;
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0000 0 0 1 &gic 0 0 GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 2 &gic 0 0 GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 3 &gic 0 0 GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
- <0000 0 0 4 &gic 0 0 GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
- iommu-map = <0 &smmu 0 1>; /* Fixed-up by bootloader */
- status = "disabled";
- };
-
smmu: iommu@5000000 {
compatible = "arm,mmu-500";
reg = <0 0x5000000 0 0x800000>;
@@ -2021,3 +1853,5 @@ optee: optee {
};
};
};
+
+#include "fsl-lx2160a-pcie-mbvl.dtsi"
--
2.25.1
^ permalink raw reply related
* [PATCH v3 01/11] arm64: dts: lx2160a: explicitly enable serdes_1 node
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
Explicitly enable the serdes_1 node in all board DT files. This is
needed in order to be able to change the default status of the node to
"disabled" from the SoC DT file.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- new patch
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 ++++
arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts | 4 ++++
4 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 4bc151d721dd..1f946d3a4ec0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -135,6 +135,10 @@ &sata3 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
index d16e27307275..954b9955b1b3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
@@ -805,6 +805,10 @@ &rgmii_phy1 {
status = "disabled";
};
+&serdes_1 {
+ status = "okay";
+};
+
&serdes_2 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 935f421475ac..39b2b04be532 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -325,6 +325,10 @@ &sata3 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index 99ee2b1c0f13..df2568ec7f1a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -367,6 +367,10 @@ &pcs_mdio18 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&serdes_2 {
status = "okay";
};
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox