* [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
From: Stefano Radaelli @ 2026-06-08 9:24 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1780910435.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite DART-MX8MP SoM and Variscite
development carrier Board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 86876311ec59..11629b9eafc5 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1310,6 +1310,12 @@ properties:
- const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
- const: fsl,imx8mp
+ - description: Variscite DART-MX8M Plus based boards
+ items:
+ - const: variscite,var-dart-mx8mp-sonata # Variscite DART-MX8MP on Sonata Development Board
+ - const: variscite,var-dart-mx8mp # Variscite DART-MX8MP SOM
+ - const: fsl,imx8mp
+
- description: Variscite VAR-SOM-MX8M Plus based boards
items:
- const: variscite,var-som-mx8mp-symphony
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/3] Add support for Variscite DART-MX8M-PLUS and Sonata board
From: Stefano Radaelli @ 2026-06-08 9:24 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
This patch series adds support for the Variscite DART-MX8M-PLUS
system on module and the Sonata carrier board.
The series includes:
- SOM device tree with on-module peripherals
- Sonata carrier board device tree with board-specific features
The implementation follows the standard SOM + carrier board pattern
where the SOM dtsi contains only peripherals mounted on the module,
while carrier-specific interfaces are enabled in the board dts.
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite DART-MX8M PLUS Boards
arm64: dts: freescale: Add support for Variscite DART-MX8M-PLUS
arm64: dts: imx8mp-var-dart: Add support for Variscite Sonata board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8mp-var-dart-sonata.dts | 716 ++++++++++++++++++
.../boot/dts/freescale/imx8mp-var-dart.dtsi | 476 ++++++++++++
4 files changed, 1199 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-var-dart.dtsi
base-commit: be580423d3f84b84a2f549df91e66bc4f54eda02
--
2.47.3
^ permalink raw reply
* Re: [PATCH 2/2] drm/rockchip: dw_hdmi_qp: expose "overscan" property
From: Maxime Ripard @ 2026-06-08 9:17 UTC (permalink / raw)
To: Alexey Charkov
Cc: Sandy Huang, Heiko Stübner, Andy Yan, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter,
Cristian Ciocaltea, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <CAKTNdwE5uAOc9V+L1J7_QJfW45D-K-vTnpHuktxD2=x9e_4jOQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3772 bytes --]
Hi Alexey,
On Wed, Jun 03, 2026 at 12:15:04PM +0400, Alexey Charkov wrote:
> On Wed, Jun 3, 2026 at 11:55 AM Maxime Ripard <mripard@kernel.org> wrote:
> >
> > On Tue, Jun 02, 2026 at 09:00:40PM +0400, Alexey Charkov wrote:
> > > Expose the "overscan" connector property as recognized by KWin and the
> > > likes to compensate for TV overscan cropping.
> > >
> > > The CRTC will use the margin values derived from this overscan percentage
> > > in its post-composition scaler to add appropriate blank margins on all
> > > sides of the output image so that the TV doesn't eat up visible content.
> > >
> > > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> > > ---
> > > drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> > > index f35484715c2d..fae44d11dbef 100644
> > > --- a/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> > > +++ b/drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
> > > @@ -137,10 +137,18 @@ dw_hdmi_qp_rockchip_encoder_atomic_check(struct drm_encoder *encoder,
> > > struct drm_connector_state *conn_state)
> > > {
> > > struct rockchip_hdmi_qp *hdmi = to_rockchip_hdmi_qp(encoder);
> > > + const struct drm_display_mode *adj_mode = &crtc_state->adjusted_mode;
> > > struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
> > > union phy_configure_opts phy_cfg = {};
> > > + unsigned int overscan;
> > > int ret;
> > >
> > > + overscan = min(conn_state->tv.overscan, 100u);
> > > + s->tv_margins.left = adj_mode->hdisplay * overscan / 200;
> > > + s->tv_margins.right = s->tv_margins.left;
> > > + s->tv_margins.top = adj_mode->vdisplay * overscan / 200;
> > > + s->tv_margins.bottom = s->tv_margins.top;
> > > +
> > > if (hdmi->tmds_char_rate == conn_state->hdmi.tmds_char_rate &&
> > > s->output_bpc == conn_state->hdmi.output_bpc)
> > > return 0;
> > > @@ -603,6 +611,14 @@ static int dw_hdmi_qp_rockchip_bind(struct device *dev, struct device *master,
> > > return dev_err_probe(hdmi->dev, PTR_ERR(connector),
> > > "Failed to init bridge connector\n");
> > >
> > > + ret = drm_mode_create_tv_properties_legacy(drm, 0, NULL);
> > > + if (ret)
> > > + return dev_err_probe(dev, ret,
> > > + "Failed to create TV connector properties\n");
> > > +
> > > + drm_object_attach_property(&connector->base,
> > > + drm->mode_config.tv_overscan_property, 0);
> > > +
> >
> > As the name suggests, it's a legacy property only ever used for TV. You
> > should be using drm_mode_create_tv_margin_properties()
>
> Hi Maxime, I tried that one before going for the current solution but
> realized that the userspace tooling I care about (KWin in particular)
> doesn't recognize those properties, but it does recognize "overscan".
> Maybe there's a compat helper somewhere that I missed, which would
> translate between the two?
>
> It is for TVs. Turns out that having a proper right-sized digital
> input interface doesn't prevent them from doing weird stuff with the
> image data, i.e. overscanning and cropping it right where one would
> expect to see the system tray and panel.
When I said "TV", I meant old-school analog TV, not modern HDMI ones :)
I guess it's a Kwin issue then. To my knowledge, there's 0 HDMI driver
implementing the legacy tv properties, when VC4 implements the margin
ones for HDMI.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v3] drm/bridge: imx93-mipi-dsi: Fix mode validation
From: Liu Ying @ 2026-06-08 9:15 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Luca Ceresoli
Cc: Dmitry Baryshkov, dri-devel, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260515-imx93-mipi-dsi-fix-mode-validation-v3-1-91f7d22b2fe4@nxp.com>
On Fri, May 15, 2026 at 02:54:16PM +0800, Liu Ying wrote:
> i.MX93 MIPI DPHY PLL has limitation for matching with some pixel clock
> rates, e.g., the best DPHY PLL frequency is 445.333333MHz for a typical
> 1920x1080p@60Hz CEA/DMT display mode with a pixel clock rate running
> at 148.5MHz with 4 data lanes + RGB888 pixel in MIPI DSI sync pulse mode,
> while the expected PLL frequency is (148.5 * 24) / 4 / 2 MHz = 445.5MHz.
> Fortunately, VESA Display Monitor Timing Standard allows +/-0.5% pixel
> clock rate deviation for timings. So, for those display modes read
> from EDID through a bridge with DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_EDID
> operation bit masks set, pixel clock rate could be adjusted to match
> with the PLL frequency(for the above example, the pixel clock rate is
> adjusted to be 148.444444MHz with about -0.03% deviation from the 148.5MHz
> nominal rate so that the adjusted rate matches with the 445.333333MHz PLL
> frequency).
>
> Instead of checking the last bridge's operation bit masks against
> DRM_BRIDGE_OP_DETECT and DRM_BRIDGE_OP_EDID to determine if allowing
> +/-0.5% pixel clock rate deviation, check any bridge after this bridge,
> because the last bridge is usually a display connector bridge without
> any operation bit mask when the clock rate deviation is allowed.
>
> Fixes: ce62f8ea7e3f ("drm/bridge: imx: Add i.MX93 MIPI DSI support")
> Fixes: 5849eff7f067 ("drm/bridge: imx93-mipi-dsi: use drm_bridge_chain_get_last_bridge()")
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> Changes in v3:
> - Iterate over next bridges manually instead of calling
> drm_for_each_bridge_in_chain_from() to avoid deadlock issue. (sashiko bot)
> - Fix a typo in commit message - s/modes/mode/.
> - Link to v2: https://patch.msgid.link/20260512-imx93-mipi-dsi-fix-mode-validation-v2-1-7aec3be5da2c@nxp.com
>
> Changes in v2:
> - Collect Frank's R-b tag.
> - Add an explanation to commit message about the reason why mode validation
> checks bridge's operation bit masks. (Dmitry)
> - Copy Dmitry.
> - Link to v1: https://lore.kernel.org/r/20260227-imx93-mipi-dsi-fix-mode-validation-v1-1-a9cd67991280@nxp.com
>
> To: Liu Ying <victor.liu@nxp.com>
> To: Andrzej Hajda <andrzej.hajda@intel.com>
> To: Neil Armstrong <neil.armstrong@linaro.org>
> To: Robert Foss <rfoss@kernel.org>
> To: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
> To: Jonas Karlman <jonas@kwiboo.se>
> To: Jernej Skrabec <jernej.skrabec@gmail.com>
> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> To: Maxime Ripard <mripard@kernel.org>
> To: Thomas Zimmermann <tzimmermann@suse.de>
> To: David Airlie <airlied@gmail.com>
> To: Simona Vetter <simona@ffwll.ch>
> To: Frank Li <Frank.Li@nxp.com>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> To: Pengutronix Kernel Team <kernel@pengutronix.de>
> To: Fabio Estevam <festevam@gmail.com>
> To: Luca Ceresoli <luca.ceresoli@bootlin.com>
> Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c | 44 ++++++++++++++++++++---------
> 1 file changed, 31 insertions(+), 13 deletions(-)
If possible, can I get a R-b or A-b tag from a drm/drm-misc maintainer/committer
so that this can be picked up with good review?
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [RFC PATCH v3 0/9] accel: rocket: Add RK3568 NPU support
From: Midgy Balon @ 2026-06-08 9:14 UTC (permalink / raw)
To: Chaoyi Chen
Cc: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, joro, will,
robin.murphy, dri-devel, linux-rockchip, devicetree,
linux-arm-kernel, iommu, linux-kernel, Simon Xue, Finley Xiao
In-Reply-To: <CA+GS1Y3ysdWZ3qCq3ip_Pbw+v4LxHZd95aBo=jwB+orYaMBBNw@mail.gmail.com>
Hello Chaoyi,
Following up on the need_regulator suggestion -- I implemented and
tested it on the
board, and unfortunately it doesn't avoid the deadlock on RK3568; it
moves it from
boot to the NPU job submit.
What I did: gave the RK3568 NPU power domain a regulator (a DOMAIN_M_R
variant with
need_regulator = true), wired domain-supply = <&vdd_npu>, and dropped the
regulator-always-on workaround.
Boot is now clean and the NPU probes, but there is a warning during boot:
rockchip-pm-domain ...: Failed to create device link (0x180) with supplier
0-0020 for .../power-domain@6
(0-0020 is the rk809 PMIC that supplies vdd_npu.) Then on the first NPU job
submit the board hard-hangs with an RCU stall:
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 3-...!: (1 GPs behind) ...
rcu: rcu_preempt kthread starved for 5115 jiffies! ... RCU_GP_WAIT_FQS(5)
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected
My reading: vdd_npu is on the rk809 *I2C* PMIC, so when genpd
enables/disables the
regulator during the NPU's runtime-PM power transition, the I2C
transfer runs in a
context that starves RCU and the box freezes. (I suspect
need_regulator is fine on
the RK3588 NPU because its supply isn't behind an I2C PMIC.) The always-on
workaround avoids this precisely because genpd never touches the I2C
regulator in
that path.
So: for an NPU domain whose supply is an I2C PMIC, is there a
supported way to let
genpd own the regulator without performing the I2C op in the
power-transition path
(a deferred/async regulator enable, or a flag), or should RK3568 keep vdd_npu as
regulator-always-on? For v4 I'll keep always-on unless there's a cleaner path.
Thanks,
Midgy
Le lun. 8 juin 2026 à 10:05, Midgy Balon <midgy971@gmail.com> a écrit :
>
> Hello Chaoyi,
>
> Thanks -- this is exactly what I needed.
>
> - v2/DTE: will do. I'll keep building on Simon's per-device-ops series -- with
> that in place the NPU MMU can use the 32-bit-DTE ops (the per-ops GFP_DMA32
> that's already in mainline) without the global rk_ops conflict. I'll
> keep it as
> a stated dependency of the v4 cover letter.
>
> - vdd_npu: I'll switch the RK3568 NPU
> power domain to need_regulator + domain-supply = <&vdd_npu> and drop the
> regulator-always-on workaround. I suspect that's also the right fix for the
> power-off/on de-idle issue I described -- the always-on was really
> just papering
> over the domain not being modelled with a regulator. I'll confirm on
> the board.
>
> - AUTO_GATING: thanks for the commit references -- I'll keep the bit-31
> read-modify-write form with your Suggested-by and write the comment
> from those.
> For the record: on v7.1-rc6 the NPU MMU also completes translations
> on the reset
> value (I couldn't reproduce a page-walk stall without the write), so I'll note
> in the commit that it matches the vendor clock-gating handling rather than
> fixing a failure I can reproduce here -- happy to drop it if the iommu
> maintainers would prefer.
>
> - PVTPLL/NoC: I'll follow up with Finley. First I'll check whether the
> need_regulator change resolves the NoC re-power de-idle on its own;
> if it still
> I'll bring him the details (the genpd power-on de-idle ack and the
> BUS_IDLE_ST state).
>
> I'll send a v4 with these. Thanks again for the quick, detailed answers.
>
> Kind regards,
> Midgy
>
> Le lun. 8 juin 2026 à 03:40, Chaoyi Chen <chaoyi.chen@rock-chips.com> a écrit :
> >
> > Hi Midgy,
> >
> > On 6/8/2026 5:03 AM, Midgy Balon wrote:
> > > Hi Chaoyi,
> > >
> > > Thanks a lot for looking at this -- input from Rockchip is exactly what this
> > > series needs.
> > >
> > >> Hmmm. If I understand correctly, the NPU IOMMU should be v2 rather than v1,
> > >> implying it should support 40-bit PAs. Nevertheless, please note that the
> > >> upper limit for DTE is 32 bits.
> > >
> > > Understood, and that 32-bit-DTE note is the crux of the trouble I had, so let
> > > me lay out what I see and ask how you'd prefer to solve it.
> > >
> > > The mainline node is already v2 (rockchip,rk3568-iommu in rk356x-base.dtsi).
> > > The problem on this 8 GiB board: with the v2 ops the page-table allocations
> > > (gfp_flags == 0) can land above 4 GiB, so the DTE ends up > 32 bits and the
> > > NPU's first translation faults with DMA_READ_ERROR. To work around that I had
> > > switched the NPU MMU to the v1 compatible (rockchip,iommu), whose ops set
> > > GFP_DMA32 and keep the DTE sub-4 GiB. That works in isolation, but because the
> > > driver keeps a single global rk_ops, a v1 NPU MMU then trips
> > > WARN_ON(rk_ops != ops) against the SoC's v2 instances (VOP/VDEC), which is why
> > > I based the series on Simon's per-device-ops work.
> > >
> > > So my question: with per-device ops in place, what's the intended way to keep
> > > the NPU MMU on v2 *and* cap its DTE at 32 bits on boards with >4 GiB of RAM?
> > > A v2 ops variant carrying GFP_DMA32 for this device, or is there a register/
> > > config bit that constrains the DTE address? I'd rather follow the Rockchip
> > > intent here than carry the v1 workaround. (Simon, cc'd -- this is right next to
> > > your per-device-ops series.)
> > >
> >
> > If Simon's method works, please use it :)
> >
> > >> Can these operations not be completed via the pmdomain driver?
> > >> If some operations are controlled by TF-A, are you using open source TF-A?
> > >
> > > Most of it is in pmdomain already. Power-on and NoC de-idle are done by the
> > > RK3568 NPU power domain (genpd) at power-on -- the driver no longer pokes the
> > > PMU directly. Two things remain outside it:
> > >
> > > - vdd_npu: I mark it regulator-always-on in DT rather than wiring it as the
> > > domain's domain-supply, because as a domain-supply it created a device-link
> > > to the I2C PMIC (rk809) and genpd's power-off QoS-save path then hung
> > > reading the NPU QoS registers behind the (gated) NoC. If there's a clean way
> > > to let genpd own vdd_npu without that I2C ordering deadlock I'd much prefer
> > > that -- pointers welcome.
> > >
> >
> > Please refer to the patch below regarding the RK3588 NPU pmdomain.
> > In short, you need to set a "need_regulator" for the RK3568 NPU pmdomain.
> >
> > https://lore.kernel.org/all/20251216055247.13150-1-rmxpzlb@gmail.com/
> >
> > > - the NPU compute clock (PVTPLL): set from the driver via SCMI, and only
> > > needed for actual compute, not for bring-up.
> > >
> > > One more pmdomain observation from testing, possibly relevant to how the NPU
> > > domain should be modelled: the domain's power-off/on cycle doesn't reliably
> > > re-de-idle the NoC. If the NPU is probed after genpd has already powered the
> > > (unused) domain off, the power-on de-idle fails ("failed to set idle on domain
> > > 'npu'") and the NPU IOMMU then takes an external abort on its first MMIO access.
> > > Probing the NPU before the unused-domain power-off, or marking the domain
> > > always-on, both avoid it. Is the NoC de-idle expected to work on a genpd
> > > re-power here, or should this domain effectively stay on?
> > >
> >
> > Not quite sure what's going on with PVTPLL and NOC.
> > Maybe @Finley knows about this?
> >
> > > On TF-A: yes -- bl31 is built from upstream arm-trusted-firmware
> > > (github.com/ARM-software/arm-trusted-firmware, RK3568 platform), providing PSCI
> > > and the SCMI clock service. The only closed blob in the boot chain is Rockchip's
> > > DDR init (rkbin), which is the standard situation for mainline RK356x.
> >
> > --
> > Best,
> > Chaoyi
^ permalink raw reply
* Re: [PATCH 00/39] Add i.MX95 DPU/DSI/LVDS support
From: Piyush Patle @ 2026-06-08 9:09 UTC (permalink / raw)
To: Liu Ying
Cc: Marek Vasut, dri-devel, imx, linux-arm-kernel, linux-clk,
devicetree, Shawn Guo, Fabio Estevam, Peng Fan, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lucas Stach, Laurent Pinchart,
Thomas Zimmermann, Abel Vesa, Pengutronix Kernel Team
In-Reply-To: <aiZzxhljfyYQ68Gl@raspi>
On Mon, Jun 8, 2026 at 1:16 PM Liu Ying <victor.liu@nxp.com> wrote:
>
> On Fri, Jun 05, 2026 at 05:41:05PM +0530, Piyush Patle wrote:
> > Hi Marek, Liu Ying,
>
> Hi,
Hi Ying,
Thanks for the detailed update.
>
> >
> > I brought this series up on the i.MX95 15x15 FRDM (IT6263 LVDS-to-HDMI on
> > LVDS ch1). It mostly works, but I ran into a few issues around DI routing,
> > LVDS format handling, and DC enable sequencing which needed rework before
> > HDMI would come up reliably on the board.
> >
> > I don't see a v2 of the series and things seem to have been quiet since
> > November. Are you planning to post an updated version?
>
> My plan was to enable prefetch engine support[1] for i.MX8QXP display
> controller and add device tree for a whole i.MX8QXP LVDS display pipeline,
> before adding i.MX95 display controller support.
>
> Unfortunately, it seems that Marek is not a big fan of [1] and I'm busy
> with downstream development so the plan doesn't move forward well. I still
> think [1] makes sense(maybe I need to rebase it on latest drm-misc-next),
> so I'd like to see review comments on [1] and hopefully people think that
> the overall idea of [1] is ok.
>
> >
> > I've accumulated a fair amount of rework while getting this running on the
> > FRDM. If you're not planning a v2, I can clean things up and send one based
> > on the current series.
>
> I still think that i.MX95 display controller driver should be in a separate
> driver, rather than sharing the same driver with i.MX8QXP display controller
> like this patch series does, because the two display controllers are quite
> different as I mentioned in comments on this patch series and in discussion
> in [1]. Also, the common part between the two display controllers should
> be extracted to a common helper library as I mentioned there too.
>
I agree with your direction. A separate i.MX95 DC driver with the common pieces
factored into a shared helper library seems like a better long-term
approach than
extending the i.MX8QXP driver, given how different the two controllers are.
> >
> > Thanks,
> > Piyush
>
> [1] lore.kernel.org/all/20251027-imx8-dc-prefetch-v5-0-4ecb6c6d4941@nxp.com/
>
I've had the current series running on the i.MX95 15x15 FRDM (IT6263
LVDS-to-HDMI
on LVDS channel 1). HDMI now comes up reliably and remains stable. The mode
and timing are correct (1280x720@60), the LVDS/LDB pixel clock is at
74.25 MHz in
single-link mode, and the DC plane is scanning out a linear XRGB8888
buffer correctly
The one issue I'm still chasing is color. Timing and sync look
correct, but the colors on
screen are wrong. I've ruled out a few obvious causes and see the same
result with a
simple CPU-generated test pattern, so it doesn't appear to be GPU or
Mesa related.
I'm currently narrowing the root cause and will report back once I find it.
While bringing the series up on the FRDM, I ended up reworking three main areas:
- DI routing (display interface selection and pixel-link to LVDS channel wiring)
- LVDS bus-format handling
- DC enable sequencing
I have time available to help move this forward. I'm happy to continue
testing on the
FRDM and provide feedback on the reworks I've made.
On the other hand, if additional help would be useful, I'd be
interested in working on the
separate i.MX95 driver under your guidance and posting the resulting
series for review.
If that sounds reasonable, I'd be glad to coordinate with you on how
you'd like the work
structured.
I'll also take a look at the prefetch engine series! Thanks again.
> --
> Regards,
> Liu Ying
Thanks,
Piyush
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Suzuki K Poulose @ 2026-06-08 9:03 UTC (permalink / raw)
To: Aneesh Kumar K.V, Sudeep Holla
Cc: linux-coco, linux-arm-kernel, linux-kernel, Catalin Marinas,
Greg KH, Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi,
Mark Rutland, Will Deacon, Steven Price
In-Reply-To: <yq5ao6hlzbpa.fsf@kernel.org>
On 08/06/2026 09:19, Aneesh Kumar K.V wrote:
> Sudeep Holla <sudeep.holla@kernel.org> writes:
>
>> On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
>>> Sudeep Holla <sudeep.holla@kernel.org> writes:
>>>
>>> ...
>>>
>>>> +static const struct smccc_device_info smccc_devices[] __initconst = {
>>>> + {
>>>> + .func_id = ARM_SMCCC_TRNG_VERSION,
>>>> + .requires_smc = false,
>>>> + .min_return = ARM_SMCCC_TRNG_MIN_VERSION,
>>>> + .device_name = "arm-smccc-trng",
>>>> + },
>>>> +};
>>>> +
>>>> +static bool __init
>>>> +smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
>>>> +{
>>>> + struct arm_smccc_res res;
>>>> + unsigned long ret;
>>>> +
>>>> + if (!IS_ENABLED(CONFIG_ARM64))
>>>> + return false;
>>>> +
>>>> + if (smccc_conduit == SMCCC_CONDUIT_NONE)
>>>> + return false;
>>>> +
>>>> + if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
>>>> + return false;
>>>> +
>>>> + arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
>>>> + ret = res.a0;
>>>> +
>>>> + if ((s32)ret < 0)
>>>> + return false;
>>>> +
>>>> + return ret >= smccc_dev->min_return;
>>>> +}
>>>> +
>>>>
>>>
>>> I am not sure we want the check to be as simple as ret < 0. Some
>>> function IDs may return input errors based on the supplied arguments
>>> (for example, RMI_ERROR_INPUT). In those cases, we would likely want
>>> this to be handled via a callback.
>>>
>>
>> As I mentioned in response to Suzuki, we can defer that to probe of
>> that device. If *_VERSION, succeeds SMCCC core can add that device and
>> leave the rest to the core keeping the core and bus layer simple IMO.
>>
>>> We also want to use conditional compilation for some function IDs.
>>> Given the callback approach and the #ifdefs, I wonder whether what we
>>> currently have is actually simpler and more flexible.”
>>>
>>
>> I was trying to avoid conditional compilation altogether and hence the
>> reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64)
>> in above snippet must come as some condition to this generic probe.
>>
>> Adding any more logic or callback defeats the bus idea here if we need
>> to rely/depend on multiple conditional compilation or callbacks IMO.
>>
>> Let's find see if it can work with what we are adding now and may add in
>> near future and then decide.
>>
>
> If we move all the conditional checks to the driver probe path, then I
> think this can work. Something like the below:
>
> struct smccc_device_info {
> u32 func_id;
> bool requires_smc;
> const char *device_name;
> };
>
> static const struct smccc_device_info smccc_devices[] __initconst = {
> {
> .func_id = ARM_SMCCC_TRNG_VERSION,
> .requires_smc = false,
> .device_name = "arm-smccc-trng",
> },
>
> {
> .func_id = RSI_ABI_VERSION,
Don't we need parameters passed to this (Requested Interface version for
e.g.) ? See more below.
> .requires_smc = true,
> .device_name = RSI_DEV_NAME,
> },
> };
>
> static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
> {
> unsigned long ret;
> struct arm_smccc_res res;
>
> if (smccc_conduit == SMCCC_CONDUIT_NONE)
> return false;
>
> if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
> return false;
>
> arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
> ret = res.a0;
>
> if ((s32)ret == SMCCC_RET_NOT_SUPPORTED)
Is this a reliable check for all possible SMCCC services ? i.e., Are we
expected to get RET_NOT_SUPPORTED for any service for which the backend
is not available ?
Also, as pointed out RSI_ABI_VERSION may return other errors based on
the input (requested version, e.g., RSI_ERROR_INPUT) and we may still go
ahead and register the device ?
> return false;
>
> return true;
> }
>
> static int __init smccc_devices_init(void)
> {
> struct arm_smccc_device *sdev;
> const struct smccc_device_info *smccc_dev;
>
> for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
> smccc_dev = &smccc_devices[i];
>
> if (!smccc_probe_smccc_device(smccc_dev))
> continue;
>
> sdev = arm_smccc_device_register(smccc_dev->device_name);
> if (IS_ERR(sdev))
> pr_err("%s: could not register device: %ld\n",
> smccc_dev->device_name, PTR_ERR(sdev));
>
> }
>
> return 0;
> }
> device_initcall(smccc_devices_init);
>
> with the diff to hw_random/smccc_trng
>
> modified arch/arm64/include/asm/archrandom.h
> @@ -12,7 +12,7 @@
>
> extern bool smccc_trng_available;
>
> -static inline bool __init smccc_probe_trng(void)
> +static inline bool smccc_probe_trng(void)
> {
> struct arm_smccc_res res;
>
> modified drivers/char/hw_random/arm_smccc_trng.c
> @@ -19,6 +19,8 @@
> #include <linux/arm-smccc.h>
> #include <linux/arm-smccc-bus.h>
>
> +#include <asm/archrandom.h>
> +
> #ifdef CONFIG_ARM64
> #define ARM_SMCCC_TRNG_RND ARM_SMCCC_TRNG_RND64
> #define MAX_BITS_PER_CALL (3 * 64UL)
> @@ -98,6 +100,10 @@ static int smccc_trng_probe(struct arm_smccc_device *sdev)
> {
> struct hwrng *trng;
>
> + /* validate the minimum version requirement */
> + if (!smccc_probe_trng())
> + return -ENODEV;
> +
> trng = devm_kzalloc(&sdev->dev, sizeof(*trng), GFP_KERNEL);
> if (!trng)
> return -ENOMEM;
>
> We can also move arch/arm64/include/asm/rsi_smc.h to
> include/linux/arm-rsi-smccc.h. There was a suggestion to move these
super minor nit: arm-smccc-rsi.h ?
Cheers
Suzuki
> firmware interfaces out of architecture-specific code:
>
> https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
>
> This will also avoid the #ifdef CONFIG_ARM64
>
> -aneesh
^ permalink raw reply
* Re: [PATCH v12 10/15] bpf/rqspinlock: Use smp_cond_load_acquire_timeout()
From: bot+bpf-ci @ 2026-06-08 9:04 UTC (permalink / raw)
To: ankur.a.arora, linux-kernel, linux-arch, linux-arm-kernel,
linux-pm, bpf
Cc: arnd, catalin.marinas, will, peterz, akpm, mark.rutland, harisokn,
cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, broonie, joao.m.martins,
boris.ostrovsky, konrad.wilk, ashok.bhat, ankur.a.arora, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260608080440.127491-11-ankur.a.arora@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 3229 bytes --]
> bpf/rqspinlock: Use smp_cond_load_acquire_timeout()
>
> Switch out the conditional load interfaces used by rqspinlock
> to smp_cond_read_acquire_timeout() and its wrapper,
> atomic_cond_read_acquire_timeout().
>
> Both these handle the timeout and amortize as needed, so use the
> non-amortized RES_CHECK_TIMEOUT.
>
> RES_CHECK_TIMEOUT does double duty here -- presenting the current
> clock value, the timeout/deadlock error from clock_deadlock() to
> the cond-load and, returning the error value via ret.
>
> For correctness, we need to ensure that the error case of the
> cond-load interface always agrees with that in clock_deadlock().
>
> For the most part, this is fine because there's no independent clock,
> or double reads from the clock in cond-load -- either of which could
> lead to its internal state going out of sync from that of
> clock_deadlock().
>
> There is, however, an edge case where clock_deadlock() checks for:
>
> if (time > ts->timeout_end)
> return -ETIMEDOUT;
>
> while smp_cond_load_acquire_timeout() checks for:
>
> __time_now = (time_expr_ns);
> if (__time_now <= 0 || __time_now >= __time_end) {
> VAL = READ_ONCE(*__PTR);
> break;
> }
>
> This runs into a problem when (__time_now == __time_end) since
> clock_deadlock() does not treat it as a timeout condition but
> the second clause in the conditional above does.
> So, add an equality check in clock_deadlock().
>
> Finally, redefine SMP_TIMEOUT_POLL_COUNT to be 16k to be similar to
> the spin-count used in the amortized version. We only do this for
> non-arm64 as that uses a waiting implementation.
>
> Cc: bpf@vger.kernel.org
> Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Cc: Alexei Starovoitov <ast@kernel.org>
> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Besides switching to the new cond-load interface, this commit also
changes the boundary comparison in clock_deadlock() from:
if (time > ts->timeout_end)
return -ETIMEDOUT;
to:
if (time >= ts->timeout_end)
return -ETIMEDOUT;
so that time == timeout_end is now treated as a timeout, matching the
__time_now >= __time_end check in smp_cond_load_acquire_timeout().
The time > ts->timeout_end check, and the timeout_end field itself, were
first introduced in the then-named check_timeout() helper by:
commit 14c48ee81452 ("rqspinlock: Add support for timeouts")
Should this commit carry a Fixes: tag for that boundary change?
Fixes: 14c48ee81452 ("rqspinlock: Add support for timeouts")
This is offered tentatively: under the previous res_smp_cond_load_acquire
interface the '>' comparison was internally consistent, and the boundary
divergence only becomes observable once this commit switches to the
'__time_now >= __time_end' interface. So this may read more as a
self-contained adjustment than a fix for a pre-existing bug.
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27125050324
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
From: Liu Ying @ 2026-06-08 9:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
In-Reply-To: <20260608-imx93-ldb-v2-0-1b1fe621bfda@nxp.com>
DY1212W-4856 [1] is a 12.1" (WXGA) TFT LCD panel with LVDS interface.
The panel's 40-pin connector allows it to be directly connected to
i.MX93 11x11 EVK board.
Link: https://www.nxp.com/design/design-center/development-boards-and-designs/dy1212w-4856-tft-lcd-panel-with-lvds-interface:DY1212W-4856 [1]
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 4 ++
.../freescale/imx93-11x11-evk-dy1212w-4856.dtso | 81 ++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8ddaab127ab9..dbe27d757c86 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -588,6 +588,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-ontat-kd50g21-40nt-a1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-9x9-qsb-tianma-tm050rdh03.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk.dtb
+
+imx93-11x11-evk-dy1212w-4856-dtbs += imx93-11x11-evk.dtb imx93-11x11-evk-dy1212w-4856.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-evk-dy1212w-4856.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx93-11x11-frdm.dtb
imx93-11x11-frdm-pixpaper-dtbs += imx93-11x11-frdm.dtb imx93-11x11-frdm-pixpaper.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso
new file mode 100644
index 000000000000..35f7c5699e3a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk-dy1212w-4856.dtso
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/imx93-clock.h>
+
+&{/} {
+ panel-lvds {
+ compatible = "boe,ev121wxm-n10-1850";
+ backlight = <&backlight_lvds>;
+ power-supply = <&buck4>;
+
+ panel-timing {
+ /*
+ * Set clock frequency to 71142858Hz to accommodate
+ * IMX93_CLK_VIDEO_PLL rate at 498000000Hz in a rate
+ * table.
+ */
+ clock-frequency = <71142858>;
+ hactive = <1280>;
+ vactive = <800>;
+ hfront-porch = <48>;
+ hback-porch = <80>;
+ hsync-len = <32>;
+ vfront-porch = <3>;
+ vback-porch = <14>;
+ vsync-len = <6>;
+ };
+
+ port {
+ panel_lvds_in: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+ };
+};
+
+&backlight_lvds {
+ status = "okay";
+};
+
+&lcdif {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ remote-endpoint = <&panel_lvds_in>;
+ };
+ };
+ };
+};
+
+&media_blk_ctrl {
+ assigned-clocks = <&clk IMX93_CLK_MEDIA_AXI>,
+ <&clk IMX93_CLK_MEDIA_APB>,
+ <&clk IMX93_CLK_MEDIA_DISP_PIX>,
+ <&clk IMX93_CLK_VIDEO_PLL>;
+ assigned-clock-parents = <&clk IMX93_CLK_SYS_PLL_PFD1>,
+ <&clk IMX93_CLK_SYS_PLL_PFD1_DIV2>,
+ <&clk IMX93_CLK_VIDEO_PLL>;
+ /*
+ * Set IMX93_CLK_MEDIA_DISP_PIX rate to 71142858Hz to accommodate
+ * IMX93_CLK_VIDEO_PLL rate at 498000000Hz in a rate table.
+ */
+ assigned-clock-rates = <400000000>, <133333333>, <71142858>, <498000000>;
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: imx93: Add LVDS Display Bridge support
From: Liu Ying @ 2026-06-08 9:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
In-Reply-To: <20260608-imx93-ldb-v2-0-1b1fe621bfda@nxp.com>
Add LVDS Display Bridge(LDB) child node to mediamix blk-ctrl node
so that video could be output through a LVDS interface.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx93.dtsi | 37 ++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93.dtsi b/arch/arm64/boot/dts/freescale/imx93.dtsi
index b9abe143cb56..79fb4a15b733 100644
--- a/arch/arm64/boot/dts/freescale/imx93.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93.dtsi
@@ -178,6 +178,7 @@ &lcdif {
port {
lcdif_to_ldb: endpoint@1 {
reg = <1>;
+ remote-endpoint = <&ldb_from_lcdif>;
};
lcdif_to_dsi: endpoint@2 {
@@ -186,6 +187,42 @@ lcdif_to_dsi: endpoint@2 {
};
};
+&media_blk_ctrl {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ lvds_bridge: bridge@20 {
+ compatible = "fsl,imx93-ldb";
+ reg = <0x20 0x4>, <0x24 0x4>;
+ reg-names = "ldb", "lvds";
+ clocks = <&clk IMX93_CLK_LVDS_GATE>;
+ clock-names = "ldb";
+ assigned-clocks = <&clk IMX93_CLK_MEDIA_LDB>;
+ assigned-clock-parents = <&clk IMX93_CLK_VIDEO_PLL>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ ldb_from_lcdif: endpoint {
+ remote-endpoint = <&lcdif_to_ldb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ };
+ };
+ };
+ };
+};
+
&src {
mlmix: power-domain@44461800 {
compatible = "fsl,imx93-src-slice";
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: soc: imx: fsl,imx93-media-blk-ctrl: Allow LVDS Display Bridge child node
From: Liu Ying @ 2026-06-08 9:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
In-Reply-To: <20260608-imx93-ldb-v2-0-1b1fe621bfda@nxp.com>
i.MX93 SoC mediamix blk-ctrl contains one LDB_CTRL register and one LVDS
register which control video output through a LVDS interface. Allow the
LVDS Display Bridge(LDB) child node and add the child node to example.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
.../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 39 ++++++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
index d828c2e82965..124f5c206ee3 100644
--- a/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
+++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml
@@ -26,6 +26,12 @@ properties:
reg:
maxItems: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
'#power-domain-cells':
const: 1
@@ -92,6 +98,11 @@ properties:
- compatible
- ports
+ bridge@20:
+ type: object
+ $ref: /schemas/display/bridge/fsl,ldb.yaml#
+ unevaluatedProperties: false
+
allOf:
- if:
properties:
@@ -112,6 +123,7 @@ allOf:
- const: lcdif
- const: isi
- const: csi
+ bridge@20: false
- if:
properties:
compatible:
@@ -163,6 +175,8 @@ examples:
<&clk IMX93_CLK_MIPI_DSI_GATE>;
clock-names = "apb", "axi", "nic", "disp", "cam",
"pxp", "lcdif", "isi", "csi", "dsi";
+ #address-cells = <1>;
+ #size-cells = <1>;
#power-domain-cells = <1>;
dpi-bridge {
@@ -190,4 +204,29 @@ examples:
};
};
};
+
+ bridge@20 {
+ compatible = "fsl,imx93-ldb";
+ reg = <0x20 0x4>, <0x24 0x4>;
+ reg-names = "ldb", "lvds";
+ clocks = <&clk IMX93_CLK_LVDS_GATE>;
+ clock-names = "ldb";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ endpoint {
+ remote-endpoint = <&lcdif_to_ldb>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+ };
+ };
};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/3] arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
From: Liu Ying @ 2026-06-08 9:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Peng Fan
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Marco Felsch,
Liu Ying
Hi,
This patch series aims to add DY1212W-4856 [1] LVDS panel to i.MX93 11x11
EVK board.
Patch 1 allows LVDS Display Bridge (LDB) child node in i.MX93 mediamix
blk-ctrl DT binding.
Patch 2 adds LDB child node to mediamix blk-ctrl node in imx93.dtsi.
Patch 3 adds a DT overlay to support the DY1212W-4856 LVDS panel on
i.MX93 11x11 EVK board.
[1] https://www.nxp.com/design/design-center/development-boards-and-designs/dy1212w-4856-tft-lcd-panel-with-lvds-interface:DY1212W-4856
Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
Changes in v2:
- Rebase on next-20260605.
- Disallow bridge@20 for i.MX91 in patch 1. (Sashiko bot)
- Cc Marco.
- Link to v1: https://patch.msgid.link/20260513-imx93-ldb-v1-0-d11c5c3cc197@nxp.com
---
Liu Ying (3):
dt-bindings: soc: imx: fsl,imx93-media-blk-ctrl: Allow LVDS Display Bridge child node
arm64: dts: imx93: Add LVDS Display Bridge support
arm64: dts: imx93-11x11-evk: Add DY1212W-4856 LVDS panel
.../bindings/soc/imx/fsl,imx93-media-blk-ctrl.yaml | 39 +++++++++++
arch/arm64/boot/dts/freescale/Makefile | 4 ++
.../freescale/imx93-11x11-evk-dy1212w-4856.dtso | 81 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx93.dtsi | 37 ++++++++++
4 files changed, 161 insertions(+)
---
base-commit: 6e845bcb78c95af935094040bd4edc3c2b6dd784
change-id: 20260513-imx93-ldb-c5a4194e41ce
Best regards,
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: dts: gemini: Rename power controller node to poweroff
From: Linus Walleij @ 2026-06-08 9:01 UTC (permalink / raw)
To: Khushal Chitturi
Cc: sre, robh, krzk+dt, conor+dt, ulli.kroll, daniel.baluta,
simona.toaca, d-gole, m-chawdhry, linux-pm, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260330110135.10316-3-khushalchitturi@gmail.com>
On Mon, Mar 30, 2026 at 1:02 PM Khushal Chitturi
<khushalchitturi@gmail.com> wrote:
> Update the node name for the Cortina Gemini power controller from
> power-controller to poweroff since node "power controller" is
> reserved for power domain controller.
>
> Signed-off-by: Khushal Chitturi <khushalchitturi@gmail.com>
This patch 2/2 applied to the gemini for-next branch,
sorry for missing it.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v12 02/15] arm64: barrier: Support smp_cond_load_relaxed_timeout()
From: bot+bpf-ci @ 2026-06-08 8:53 UTC (permalink / raw)
To: ankur.a.arora, linux-kernel, linux-arch, linux-arm-kernel,
linux-pm, bpf
Cc: arnd, catalin.marinas, will, peterz, akpm, mark.rutland, harisokn,
cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, broonie, joao.m.martins,
boris.ostrovsky, konrad.wilk, ashok.bhat, ankur.a.arora, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260608080440.127491-3-ankur.a.arora@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fe60738e5943..fa676428ec3f 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1606,6 +1606,9 @@ config ARCH_SUPPORTS_CRASH_DUMP
> config ARCH_DEFAULT_CRASH_DUMP
> def_bool y
>
> +config ARCH_HAS_CPU_RELAX
> + def_bool y
> +
ARCH_HAS_CPU_RELAX isn't private to the barrier code. Before this it was
defined only by arch/x86, and the generic kernel already keys cpuidle
behavior off it in two places that arm64 builds.
In drivers/cpuidle/Makefile:
obj-$(CONFIG_ARCH_HAS_CPU_RELAX) += poll_state.o
and in drivers/acpi/processor_idle.c:
#define ACPI_IDLE_STATE_START (IS_ENABLED(CONFIG_ARCH_HAS_CPU_RELAX) ? 1 : 0)
...
if (IS_ENABLED(CONFIG_ARCH_HAS_CPU_RELAX)) {
cpuidle_poll_state_init(drv);
count = 1;
}
On arm64, ACPI_PROCESSOR is "default y" and depends on ARM64, and it
selects ACPI_PROCESSOR_IDLE which selects CPU_IDLE. So on an ACPI arm64
system this now builds poll_state.o and makes acpi_processor_setup_cstates()
register a POLL idle state as C-state index 0, shifting the firmware
C-states up by one.
The commit message describes this symbol only as indicating "an optimized
implementation of cpu_poll_relax()", and the generic patch describes it as
"a cpu_poll_relax() implementation that is expected to be cheaper". Neither
mentions the cpuidle/ACPI poll_state side effect.
Is enabling the cpuidle polling idle state on arm64 intended here, or is
ARCH_HAS_CPU_RELAX only meant to feed smp_cond_load_relaxed_timeout()? If
the latter, would a dedicated symbol (or decoupling poll_state/ACPI from
ARCH_HAS_CPU_RELAX) avoid the unintended idle-path change?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27125050324
^ permalink raw reply
* Re: [PATCH v12 05/15] arm64: rqspinlock: Remove private copy of smp_cond_load_acquire_timewait()
From: bot+bpf-ci @ 2026-06-08 8:53 UTC (permalink / raw)
To: ankur.a.arora, linux-kernel, linux-arch, linux-arm-kernel,
linux-pm, bpf
Cc: arnd, catalin.marinas, will, peterz, akpm, mark.rutland, harisokn,
cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, broonie, joao.m.martins,
boris.ostrovsky, konrad.wilk, ashok.bhat, ankur.a.arora, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260608080440.127491-6-ankur.a.arora@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]
> diff --git a/arch/arm64/include/asm/rqspinlock.h b/arch/arm64/include/asm/rqspinlock.h
> index 9ea0a74e5892..a385603436e9 100644
> --- a/arch/arm64/include/asm/rqspinlock.h
> +++ b/arch/arm64/include/asm/rqspinlock.h
> @@ -3,91 +3,6 @@
> #define _ASM_RQSPINLOCK_H
>
> #include <asm/barrier.h>
> -
> -/*
> - * Hardcode res_smp_cond_load_acquire implementations for arm64 to a custom
> - * version based on [0]. In rqspinlock code, our conditional expression involves
> - * checking the value _and_ additionally a timeout. However, on arm64, the
> - * WFE-based implementation may never spin again if no stores occur to the
> - * locked byte in the lock word. As such, we may be stuck forever if
> - * event-stream based unblocking is not available on the platform for WFE spin
> - * loops (arch_timer_evtstrm_available).
> - *
[ ... ]
> -#endif
> -
> -#define res_smp_cond_load_acquire(v, c) smp_cond_load_acquire_timewait(v, c, 0, 1)
> -
> #include <asm-generic/rqspinlock.h>
With res_smp_cond_load_acquire removed here, does arm64 now fall back to
the generic definition in kernel/bpf/rqspinlock.c?
#ifndef res_smp_cond_load_acquire
#define res_smp_cond_load_acquire(v, c) smp_cond_load_acquire(v, c)
#endif
On arm64, smp_cond_load_acquire() uses __cmpwait_relaxed(), which issues a
WFE that wakes only on a store to the monitored cache line or on an
event-stream tick.
The consumer is resilient_queued_spin_lock_slowpath():
kernel/bpf/rqspinlock.c:
res_smp_cond_load_acquire(&lock->locked,
!VAL || RES_CHECK_TIMEOUT(ts, ret, _Q_LOCKED_MASK));
The RES_CHECK_TIMEOUT() escape is part of cond_expr, so it is only
re-evaluated when smp_cond_load_acquire() returns from its WFE.
On platforms where arch_timer_evtstrm_available() is false, if the current
lock owner is stuck or dead and issues no further store to lock->locked,
can the WFE ever wake, and can the RES_CHECK_TIMEOUT timeout ever fire?
This looks like the exact case the removed comment described:
> - * checking the value _and_ additionally a timeout. However, on arm64, the
> - * WFE-based implementation may never spin again if no stores occur to the
> - * locked byte in the lock word. As such, we may be stuck forever if
> - * event-stream based unblocking is not available on the platform for WFE spin
> - * loops (arch_timer_evtstrm_available).
The removed private copy avoided this by falling back to a cpu_relax()-based
spinwait that always re-checks the timeout when the event stream is
unavailable.
Forward search of the series shows this is resolved by the later commit
7abb03c21db2 ("bpf/rqspinlock: Use smp_cond_load_acquire_timeout()"), which
switches rqspinlock to smp_cond_load_acquire_timeout(); on arm64 that uses
a waiting implementation handling the timeout and event-stream-absent case.
Should the change-over happen in the same commit, or is the window where a
kernel built or bisected at this commit can block indefinitely acceptable?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27125050324
^ permalink raw reply
* Re: [PATCH v12 01/15] asm-generic: barrier: Add smp_cond_load_relaxed_timeout()
From: bot+bpf-ci @ 2026-06-08 8:53 UTC (permalink / raw)
To: ankur.a.arora, linux-kernel, linux-arch, linux-arm-kernel,
linux-pm, bpf
Cc: arnd, catalin.marinas, will, peterz, akpm, mark.rutland, harisokn,
cl, ast, rafael, daniel.lezcano, memxor, zhenglifeng1, xueshuai,
rdunlap, david.laight.linux, broonie, joao.m.martins,
boris.ostrovsky, konrad.wilk, ashok.bhat, ankur.a.arora, ast,
andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260608080440.127491-2-ankur.a.arora@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 2681 bytes --]
> diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
> index d4f581c1e21d..c56df9513a08 100644
> --- a/include/asm-generic/barrier.h
> +++ b/include/asm-generic/barrier.h
> @@ -273,6 +273,75 @@ do { \
[ ... ]
> +#ifndef smp_cond_load_relaxed_timeout
> +#define smp_cond_load_relaxed_timeout(ptr, cond_expr, \
> + time_expr_ns, timeout_ns) \
> +({ \
> + typeof(ptr) __PTR = (ptr); \
> + __unqual_scalar_typeof(*(ptr)) VAL; \
> + u32 __count = 0, __spin = SMP_TIMEOUT_POLL_COUNT; \
> + s64 __timeout = (s64)timeout_ns; \
> + s64 __time_now, __time_end = 0; \
> + \
> + for (;;) { \
> + VAL = READ_ONCE(*__PTR); \
> + if (cond_expr) \
> + break; \
> + cpu_poll_relax(__PTR, VAL, (u64)__timeout); \
__timeout is held as a signed s64 but is cast to u64 here. On the first
iterations __timeout still holds the raw timeout_ns argument before any
time-check has run. If a caller passes a negative or already-expired
timeout_ns, the (u64) cast turns it into a value close to U64_MAX.
This is harmless while cpu_poll_relax() ignores its timeout argument and
falls back to cpu_relax(). Would it misbehave on an architecture whose
cpu_poll_relax() consumes the value, such as an arm64 WFET variant that
uses it as an event-stream deadline?
David Laight raised this on v11
(https://lore.kernel.org/lkml/20260508093206.389d9af2@pumpkin/):
Yes, the code is ok if cpu_poll_relax() ignores the timeout. But for
WFE it is all broken. ... if you assume/require that the converted
time is either 0 or greater than 200 then it can be used as the
initialiser for __n.
The Sashiko bot repeated the same concern as a medium finding on v12.
The v12 cover note opts to document the valid range rather than clamp at
runtime, but the code still passes (u64)__timeout unguarded, so would it
be worth converting timeout_ns into an absolute end-time (or 0 when WFE
is unused) before it reaches cpu_poll_relax()?
> + if (++__count < __spin) \
> + continue; \
> + __time_now = (s64)(time_expr_ns); \
> + if (unlikely(__time_end == 0)) \
> + __time_end = __time_now + __timeout; \
> + __timeout = __time_end - __time_now; \
> + if (__time_now <= 0 || __timeout <= 0) { \
> + VAL = READ_ONCE(*__PTR); \
> + break; \
> + } \
> + __count = 0; \
> + } \
> + (typeof(*(ptr)))VAL; \
> +})
> +#endif
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27125050324
^ permalink raw reply
* Re: [PATCH] ARM: footbridge: convert to sparse IRQs
From: Linus Walleij @ 2026-06-08 8:49 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-input, linux-serial, Russell King,
Arnd Bergmann, Greg Kroah-Hartman, Dmitry Torokhov, Jiri Slaby,
Russell King (Oracle), Kees Cook, Nathan Chancellor,
Sebastian Andrzej Siewior, Steven Rostedt, Thomas Weissschuh,
Peter Zijlstra
In-Reply-To: <20260510052107.555825-1-enelsonmoore@gmail.com>
On Sun, May 10, 2026 at 7:21 AM Ethan Nelson-Moore
<enelsonmoore@gmail.com> wrote:
> To improve future maintainability, change the interrupt handling for
> mach-footbridge to use sparse IRQs.
>
> Since the number of possible interrupts is already fixed and relatively
> small, just make it use all legacy interrupts preallocated using the
> .nr_irqs field in the machine descriptor, rather than actually
> allocating domains on the fly.
>
> Many files had to be adjusted to include <mach/irqs.h>
> explicitly because it is no longer implicitly included with sparse
> IRQs.
>
> Description adapted from commit c78a41fc04f0 ("ARM: s3c24xx: convert
> to sparse-irq").
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Have you tested this on real hardware?
The commit doesn't really say.
I might have to dig out my NetWinder to test this.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v14 24/44] KVM: arm64: Handle realm MMIO emulation
From: Steven Price @ 2026-06-08 8:49 UTC (permalink / raw)
To: Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <8b648b59-c411-4126-be18-686d2927f24a@redhat.com>
On 28/05/2026 06:03, Gavin Shan wrote:
> Hi Steve,
>
> On 5/13/26 11:17 PM, Steven Price wrote:
>> MMIO emulation for a realm cannot be done directly with the VM's
>> registers as they are protected from the host. However, for emulatable
>> data aborts, the RMM uses GPRS[0] to provide the read/written value.
>> We can transfer this from/to the equivalent VCPU's register entry and
>> then depend on the generic MMIO handling code in KVM.
>>
>> For a MMIO read, the value is placed in the shared RecExit structure
>> during kvm_handle_mmio_return() rather than in the VCPU's register
>> entry.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> Reviewed-by: Gavin Shan <gshan@redhat.com>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>> Changes since v7:
>> * New comment for rec_exit_sync_dabt() explaining the call to
>> vcpu_set_reg().
>> Changes since v5:
>> * Inject SEA to the guest is an emulatable MMIO access triggers a data
>> abort.
>> * kvm_handle_mmio_return() - disable kvm_incr_pc() for a REC (as the PC
>> isn't under the host's control) and move the REC_ENTER_EMULATED_MMIO
>> flag setting to this location (as that tells the RMM to skip the
>> instruction).
>> ---
>> arch/arm64/kvm/inject_fault.c | 4 +++-
>> arch/arm64/kvm/mmio.c | 16 ++++++++++++----
>> arch/arm64/kvm/rmi-exit.c | 14 ++++++++++++++
>> 3 files changed, 29 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/
>> inject_fault.c
>> index 89982bd3345f..6492397b73d7 100644
>> --- a/arch/arm64/kvm/inject_fault.c
>> +++ b/arch/arm64/kvm/inject_fault.c
>> @@ -228,7 +228,9 @@ static void inject_abt32(struct kvm_vcpu *vcpu,
>> bool is_pabt, u32 addr)
>> static void __kvm_inject_sea(struct kvm_vcpu *vcpu, bool iabt, u64
>> addr)
>> {
>> - if (vcpu_el1_is_32bit(vcpu))
>> + if (unlikely(vcpu_is_rec(vcpu)))
>> + vcpu->arch.rec.run->enter.flags |= REC_ENTER_FLAG_INJECT_SEA;
>> + else if (vcpu_el1_is_32bit(vcpu))
>> inject_abt32(vcpu, iabt, addr);
>> else
>> inject_abt64(vcpu, iabt, addr);
>> diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c
>> index e2285ed8c91d..6a8cb927fcca 100644
>> --- a/arch/arm64/kvm/mmio.c
>> +++ b/arch/arm64/kvm/mmio.c
>> @@ -6,6 +6,7 @@
>> #include <linux/kvm_host.h>
>> #include <asm/kvm_emulate.h>
>> +#include <asm/rmi_smc.h>
>> #include <trace/events/kvm.h>
>> #include "trace.h"
>> @@ -138,14 +139,21 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
>> trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
>> &data);
>> data = vcpu_data_host_to_guest(vcpu, data, len);
>> - vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
>> +
>> + if (vcpu_is_rec(vcpu))
>> + vcpu->arch.rec.run->enter.gprs[0] = data;
>> + else
>> + vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu), data);
>> }
>> /*
>> * The MMIO instruction is emulated and should not be re-executed
>> * in the guest.
>> */
>> - kvm_incr_pc(vcpu);
>> + if (vcpu_is_rec(vcpu))
>> + vcpu->arch.rec.run->enter.flags |= REC_ENTER_FLAG_EMULATED_MMIO;
>> + else
>> + kvm_incr_pc(vcpu);
>> return 1;
>> }
>> @@ -167,14 +175,14 @@ int io_mem_abort(struct kvm_vcpu *vcpu,
>> phys_addr_t fault_ipa)
>> * No valid syndrome? Ask userspace for help if it has
>> * volunteered to do so, and bail out otherwise.
>> *
>> - * In the protected VM case, there isn't much userspace can do
>> + * In the protected/realm VM case, there isn't much userspace can do
>> * though, so directly deliver an exception to the guest.
>> */
>> if (!kvm_vcpu_dabt_isvalid(vcpu)) {
>> trace_kvm_mmio_nisv(*vcpu_pc(vcpu), esr,
>> kvm_vcpu_get_hfar(vcpu), fault_ipa);
>> - if (vcpu_is_protected(vcpu))
>> + if (vcpu_is_protected(vcpu) || vcpu_is_rec(vcpu))
>> return kvm_inject_sea_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
>> if (test_bit(KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER,
>> diff --git a/arch/arm64/kvm/rmi-exit.c b/arch/arm64/kvm/rmi-exit.c
>> index e7c51b6cf6ce..8ec0d179eba2 100644
>> --- a/arch/arm64/kvm/rmi-exit.c
>> +++ b/arch/arm64/kvm/rmi-exit.c
>> @@ -25,6 +25,20 @@ static int rec_exit_reason_notimpl(struct kvm_vcpu
>> *vcpu)
>> static int rec_exit_sync_dabt(struct kvm_vcpu *vcpu)
>> {
>> + struct realm_rec *rec = &vcpu->arch.rec;
>> +
>> + /*
>> + * In the case of a write, copy over gprs[0] to the target GPR,
>> + * preparing to handle MMIO write fault. The content to be
>> written has
>> + * been saved to gprs[0] by the RMM (even if another register was
>> used
>> + * by the guest). In the case of normal memory access this is
>> redundant
>> + * (the guest will replay the instruction), but the overhead is
>> + * minimal.
>> + */
>> + if (kvm_vcpu_dabt_iswrite(vcpu) && kvm_vcpu_dabt_isvalid(vcpu))
>> + vcpu_set_reg(vcpu, kvm_vcpu_dabt_get_rd(vcpu),
>> + rec->run->exit.gprs[0]);
>> +
>
> { } is needed here.
Indeed - I'm surprised checkpatch didn't manage to flag that. I'll fix.
Thanks,
Steve
>> return kvm_handle_guest_abort(vcpu);
>> }
>>
>
> Thanks,
> Gavin
>
^ permalink raw reply
* Re: [PATCH v2 bpf-next] arm64: mm: Complete the PTE store in ptep_try_set()
From: Catalin Marinas @ 2026-06-08 8:43 UTC (permalink / raw)
To: Tejun Heo
Cc: Will Deacon, Alexei Starovoitov, David Hildenbrand, Andrea Righi,
Kumar Kartikeya Dwivedi, Andrew Morton, Mike Rapoport,
Andrii Nakryiko, Daniel Borkmann, Martin KaFai Lau,
Eduard Zingerman, Yonghong Song, Emil Tsalapatis, David Vernet,
Changwoo Min, linux-arm-kernel, linux-mm, bpf, linux-kernel
In-Reply-To: <7f5f7c94601312c1a401fb18998291cc@kernel.org>
On Sun, Jun 07, 2026 at 09:25:47PM -1000, Tejun Heo wrote:
> ptep_try_set() installs a kernel PTE with try_cmpxchg() but, unlike
> __set_pte(), skips the barriers that arm64 requires after writing a valid
> kernel PTE. Without them a subsequent access can fault instead of seeing
> the new mapping.
>
> Issue them with emit_pte_barriers() rather than __set_pte_complete().
> ptep_try_set() must finish the store before it returns, but
> __set_pte_complete() would defer the barriers when the calling context is in
> lazy MMU mode.
>
> v2: Emit the barriers directly instead of __set_pte_complete(). (Catalin)
Nit: I'd place this after the --- line.
> Fixes: 258df8fce42f ("mm: Add ptep_try_set() for lockless empty-slot installs")
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Link: https://lore.kernel.org/all/aiRFcz78QTZdIHHB@arm.com/
> Signed-off-by: Tejun Heo <tj@kernel.org>
> ---
> arch/arm64/include/asm/pgtable.h | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 3ce0f2a6cab6..3e579c26b383 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -1838,7 +1838,16 @@ static inline bool ptep_try_set(pte_t *ptep, pte_t new_pte)
> {
> pteval_t old = 0;
>
> - return try_cmpxchg(&pte_val(*ptep), &old, pte_val(new_pte));
> + if (!try_cmpxchg(&pte_val(*ptep), &old, pte_val(new_pte)))
> + return false;
> +
> + /*
> + * The store must be complete by the time this returns, but the caller
> + * may be in lazy MMU mode, where __set_pte_complete() would defer the
> + * barriers. Issue them directly.
> + */
> + emit_pte_barriers();
> + return true;
> }
> #define ptep_try_set ptep_try_set
It looks fine now. Thanks!
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v4 4/8] drm/bridge: pass extra events to the HPD callback
From: Francesco Dolcini @ 2026-06-08 8:39 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou, Luca Ceresoli, Francesco Dolcini, dri-devel,
linux-kernel, linux-usb, intel-gfx, intel-xe, linux-amlogic,
linux-arm-kernel, linux-arm-msm, freedreno
In-Reply-To: <20260608-hpd-irq-events-v4-4-30b62b335487@oss.qualcomm.com>
On Mon, Jun 08, 2026 at 12:33:05AM +0300, Dmitry Baryshkov wrote:
> The DisplayPort standard defines a special kind of HPD events called
> IRQ_HPD. These events are used to notify DP Source about the events on
> the Sink side.
>
> Bridge drivers report these events through the
> drm_bridge_hpd_notify_extra(). Pass down the extra status to the HPD
> callback, specified during the drm_bridge_hpd_enable(), letting
> underlying drivers (e.g. drm_bridge_connector) to receive these events.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> # lt8912b
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Sudeep Holla @ 2026-06-08 8:39 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: linux-coco, linux-arm-kernel, linux-kernel, Sudeep Holla,
Catalin Marinas, Greg KH, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Will Deacon, Steven Price,
Suzuki K Poulose
In-Reply-To: <yq5ao6hlzbpa.fsf@kernel.org>
On Mon, Jun 08, 2026 at 01:49:13PM +0530, Aneesh Kumar K.V wrote:
> Sudeep Holla <sudeep.holla@kernel.org> writes:
>
> > On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
> >> Sudeep Holla <sudeep.holla@kernel.org> writes:
> >>
> >> ...
> >>
> >> > +static const struct smccc_device_info smccc_devices[] __initconst = {
> >> > + {
> >> > + .func_id = ARM_SMCCC_TRNG_VERSION,
> >> > + .requires_smc = false,
> >> > + .min_return = ARM_SMCCC_TRNG_MIN_VERSION,
> >> > + .device_name = "arm-smccc-trng",
> >> > + },
> >> > +};
> >> > +
> >> > +static bool __init
> >> > +smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
> >> > +{
> >> > + struct arm_smccc_res res;
> >> > + unsigned long ret;
> >> > +
> >> > + if (!IS_ENABLED(CONFIG_ARM64))
> >> > + return false;
> >> > +
> >> > + if (smccc_conduit == SMCCC_CONDUIT_NONE)
> >> > + return false;
> >> > +
> >> > + if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
> >> > + return false;
> >> > +
> >> > + arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
> >> > + ret = res.a0;
> >> > +
> >> > + if ((s32)ret < 0)
> >> > + return false;
> >> > +
> >> > + return ret >= smccc_dev->min_return;
> >> > +}
> >> > +
> >> >
> >>
> >> I am not sure we want the check to be as simple as ret < 0. Some
> >> function IDs may return input errors based on the supplied arguments
> >> (for example, RMI_ERROR_INPUT). In those cases, we would likely want
> >> this to be handled via a callback.
> >>
> >
> > As I mentioned in response to Suzuki, we can defer that to probe of
> > that device. If *_VERSION, succeeds SMCCC core can add that device and
> > leave the rest to the core keeping the core and bus layer simple IMO.
> >
> >> We also want to use conditional compilation for some function IDs.
> >> Given the callback approach and the #ifdefs, I wonder whether what we
> >> currently have is actually simpler and more flexible.”
> >>
> >
> > I was trying to avoid conditional compilation altogether and hence the
> > reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64)
> > in above snippet must come as some condition to this generic probe.
> >
> > Adding any more logic or callback defeats the bus idea here if we need
> > to rely/depend on multiple conditional compilation or callbacks IMO.
> >
> > Let's find see if it can work with what we are adding now and may add in
> > near future and then decide.
> >
>
> If we move all the conditional checks to the driver probe path, then I
> think this can work. Something like the below:
>
Sounds good to me.
[...]
> We can also move arch/arm64/include/asm/rsi_smc.h to
> include/linux/arm-rsi-smccc.h. There was a suggestion to move these
> firmware interfaces out of architecture-specific code:
>
> https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
>
Ah OK, sorry I had missed this.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: simplify WAN device check in airoha_dev_init()
From: Lorenzo Bianconi @ 2026-06-08 8:29 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260606-airoha-eth-simplify-dev-init-v1-1-f08f8e404049@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]
> airoha_register_gdm_devices() iterates eth->ports[] in order, so GDM2's
> netdev is always registered before GDM3/GDM4. This means the explicit
> check for eth->ports[1] && eth->ports[1]->devs[0] is a redundant
> special-case of what airoha_get_wan_gdm_dev() already covers, since
> GDM2 is always marked as WAN during its own ndo_init.
> Remove the redundant check and rely solely on airoha_get_wan_gdm_dev()
> which handles both the GDM2-present and GDM2-absent cases.
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Please drop this patch since I need to modify it to address Andrew's request
about LAN/WAN configuration.
Regards,
Lorenzo
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 12 ++----------
> 1 file changed, 2 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 5a8e84fa9918..b333a7b309c2 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2004,18 +2004,10 @@ static int airoha_dev_init(struct net_device *netdev)
>
> switch (port->id) {
> case AIROHA_GDM3_IDX:
> - case AIROHA_GDM4_IDX: {
> - struct airoha_eth *eth = dev->eth;
> -
> - /* GDM2 supports a single net_device */
> - if (eth->ports[1] && eth->ports[1]->devs[0])
> - break;
> -
> - if (airoha_get_wan_gdm_dev(eth))
> + case AIROHA_GDM4_IDX:
> + if (airoha_get_wan_gdm_dev(dev->eth))
> break;
> -
> fallthrough;
> - }
> case AIROHA_GDM2_IDX:
> /* GDM2 is always used as wan */
> dev->flags |= AIROHA_PRIV_F_WAN;
>
> ---
> base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
> change-id: 20260606-airoha-eth-simplify-dev-init-5d53c7cc004e
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] usb: gadget: aspeed_udc: check endpoint DMA allocation
From: Ruoyu Wang @ 2026-06-08 8:19 UTC (permalink / raw)
To: Neal Liu, Greg Kroah-Hartman
Cc: Joel Stanley, Andrew Jeffery, linux-aspeed, linux-usb,
linux-arm-kernel, linux-kernel, Ruoyu Wang
ast_udc_probe() allocates a coherent DMA buffer used as the backing store
for endpoint buffers. ast_udc_init_ep() derives per-endpoint buffer
pointers from udc->ep0_buf, so a failed allocation is dereferenced during
probe.
Check the allocation before endpoint setup. The existing probe error path
called ast_udc_remove(), which unregisters the gadget unconditionally and
is not safe before usb_add_gadget_udc() succeeds. Add a local cleanup
helper for probe failures so pre-registration failures only unwind the
resources that were actually initialized.
This was found by a local static analysis checker for unchecked allocator
returns while scanning Linux 6.16. The change was checked by applying it
to current mainline and by running checkpatch. I do not have access to
Aspeed UDC hardware, so no runtime testing was performed.
Fixes: 055276c13205 ("usb: gadget: add Aspeed ast2600 udc driver")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
Note: a 2022 patch attempted to add only a NULL check for this
allocation:
https://lore.kernel.org/all/20221213025120.23149-1-jiasheng@iscas.ac.cn/
This version also fixes the probe unwind path so the clock is disabled
on allocation failure and usb_del_gadget_udc() is not called before the
gadget has been registered.
diff --git a/drivers/usb/gadget/udc/aspeed_udc.c b/drivers/usb/gadget/udc/aspeed_udc.c
index 7fc6696b7..809a7d5b7 100644
--- a/drivers/usb/gadget/udc/aspeed_udc.c
+++ b/drivers/usb/gadget/udc/aspeed_udc.c
@@ -1434,11 +1434,34 @@ static void ast_udc_init_hw(struct ast_udc_dev *udc)
ast_udc_write(udc, 0, AST_UDC_EP0_CTRL);
}
+static void ast_udc_cleanup(struct platform_device *pdev)
+{
+ struct ast_udc_dev *udc = platform_get_drvdata(pdev);
+ unsigned long flags;
+ u32 ctrl;
+
+ spin_lock_irqsave(&udc->lock, flags);
+
+ /* Disable upstream port connection */
+ ctrl = ast_udc_read(udc, AST_UDC_FUNC_CTRL) & ~USB_UPSTREAM_EN;
+ ast_udc_write(udc, ctrl, AST_UDC_FUNC_CTRL);
+
+ clk_disable_unprepare(udc->clk);
+
+ spin_unlock_irqrestore(&udc->lock, flags);
+
+ if (udc->ep0_buf)
+ dma_free_coherent(&pdev->dev,
+ AST_UDC_EP_DMA_SIZE * AST_UDC_NUM_ENDPOINTS,
+ udc->ep0_buf,
+ udc->ep0_buf_dma);
+
+ udc->ep0_buf = NULL;
+}
+
static void ast_udc_remove(struct platform_device *pdev)
{
struct ast_udc_dev *udc = platform_get_drvdata(pdev);
- unsigned long flags;
- u32 ctrl;
usb_del_gadget_udc(&udc->gadget);
if (udc->driver) {
@@ -1453,23 +1476,7 @@ static void ast_udc_remove(struct platform_device *pdev)
return;
}
- spin_lock_irqsave(&udc->lock, flags);
-
- /* Disable upstream port connection */
- ctrl = ast_udc_read(udc, AST_UDC_FUNC_CTRL) & ~USB_UPSTREAM_EN;
- ast_udc_write(udc, ctrl, AST_UDC_FUNC_CTRL);
-
- clk_disable_unprepare(udc->clk);
-
- spin_unlock_irqrestore(&udc->lock, flags);
-
- if (udc->ep0_buf)
- dma_free_coherent(&pdev->dev,
- AST_UDC_EP_DMA_SIZE * AST_UDC_NUM_ENDPOINTS,
- udc->ep0_buf,
- udc->ep0_buf_dma);
-
- udc->ep0_buf = NULL;
+ ast_udc_cleanup(pdev);
}
static int ast_udc_probe(struct platform_device *pdev)
@@ -1523,6 +1530,10 @@ static int ast_udc_probe(struct platform_device *pdev)
AST_UDC_EP_DMA_SIZE *
AST_UDC_NUM_ENDPOINTS,
&udc->ep0_buf_dma, GFP_KERNEL);
+ if (!udc->ep0_buf) {
+ rc = -ENOMEM;
+ goto err_disable_clk;
+ }
udc->gadget.speed = USB_SPEED_UNKNOWN;
udc->gadget.max_speed = USB_SPEED_HIGH;
@@ -1553,20 +1564,20 @@ static int ast_udc_probe(struct platform_device *pdev)
udc->irq = platform_get_irq(pdev, 0);
if (udc->irq < 0) {
rc = udc->irq;
- goto err;
+ goto err_cleanup;
}
rc = devm_request_irq(&pdev->dev, udc->irq, ast_udc_isr, 0,
KBUILD_MODNAME, udc);
if (rc) {
dev_err(&pdev->dev, "Failed to request interrupt\n");
- goto err;
+ goto err_cleanup;
}
rc = usb_add_gadget_udc(&pdev->dev, &udc->gadget);
if (rc) {
dev_err(&pdev->dev, "Failed to add gadget udc\n");
- goto err;
+ goto err_cleanup;
}
dev_info(&pdev->dev, "Initialized udc in USB%s mode\n",
@@ -1574,9 +1585,14 @@ static int ast_udc_probe(struct platform_device *pdev)
return 0;
+err_disable_clk:
+ clk_disable_unprepare(udc->clk);
+ goto err;
+err_cleanup:
+ ast_udc_cleanup(pdev);
+ goto err;
err:
dev_err(&pdev->dev, "Failed to udc probe, rc:0x%x\n", rc);
- ast_udc_remove(pdev);
return rc;
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] pinctrl: aspeed: Fix GPIO mux value for ADC-capable balls
From: Linus Walleij @ 2026-06-08 8:19 UTC (permalink / raw)
To: Billy Tsai
Cc: Andrew Jeffery, Joel Stanley, Bartosz Golaszewski, linux-aspeed,
openbmc, linux-gpio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260605-pinctrl-fix-v1-1-3d8cf7a6c348@aspeedtech.com>
On Fri, Jun 5, 2026 at 8:38 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
> aspeed_g7_soc1_gpio_request_enable() unconditionally writes mux
> function 0 to route the requested pin to GPIO. This is wrong for the
> ADC-capable balls W17 through AB19 (ADC0-ADC15), where function 0
> selects the ADC input and function 1 selects GPIO. Requesting one of
> those GPIOs therefore muxed the ball to ADC instead.
>
> Write mux value 1 for balls W17 through AB19 so the GPIO function is
> actually selected.
>
> Fixes: 4af4eb66aac3 ("pinctrl: aspeed: Add AST2700 SoC1 support")
> Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Patch applied! Will be for v7.2 at this point.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Aneesh Kumar K.V @ 2026-06-08 8:19 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-coco, linux-arm-kernel, linux-kernel, Catalin Marinas,
Sudeep Holla, Greg KH, Jeremy Linton, Jonathan Cameron,
Lorenzo Pieralisi, Mark Rutland, Will Deacon, Steven Price,
Suzuki K Poulose
In-Reply-To: <20260604-juicy-daft-starling-3eec1f@sudeepholla>
Sudeep Holla <sudeep.holla@kernel.org> writes:
> On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
>> Sudeep Holla <sudeep.holla@kernel.org> writes:
>>
>> ...
>>
>> > +static const struct smccc_device_info smccc_devices[] __initconst = {
>> > + {
>> > + .func_id = ARM_SMCCC_TRNG_VERSION,
>> > + .requires_smc = false,
>> > + .min_return = ARM_SMCCC_TRNG_MIN_VERSION,
>> > + .device_name = "arm-smccc-trng",
>> > + },
>> > +};
>> > +
>> > +static bool __init
>> > +smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
>> > +{
>> > + struct arm_smccc_res res;
>> > + unsigned long ret;
>> > +
>> > + if (!IS_ENABLED(CONFIG_ARM64))
>> > + return false;
>> > +
>> > + if (smccc_conduit == SMCCC_CONDUIT_NONE)
>> > + return false;
>> > +
>> > + if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
>> > + return false;
>> > +
>> > + arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
>> > + ret = res.a0;
>> > +
>> > + if ((s32)ret < 0)
>> > + return false;
>> > +
>> > + return ret >= smccc_dev->min_return;
>> > +}
>> > +
>> >
>>
>> I am not sure we want the check to be as simple as ret < 0. Some
>> function IDs may return input errors based on the supplied arguments
>> (for example, RMI_ERROR_INPUT). In those cases, we would likely want
>> this to be handled via a callback.
>>
>
> As I mentioned in response to Suzuki, we can defer that to probe of
> that device. If *_VERSION, succeeds SMCCC core can add that device and
> leave the rest to the core keeping the core and bus layer simple IMO.
>
>> We also want to use conditional compilation for some function IDs.
>> Given the callback approach and the #ifdefs, I wonder whether what we
>> currently have is actually simpler and more flexible.”
>>
>
> I was trying to avoid conditional compilation altogether and hence the
> reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64)
> in above snippet must come as some condition to this generic probe.
>
> Adding any more logic or callback defeats the bus idea here if we need
> to rely/depend on multiple conditional compilation or callbacks IMO.
>
> Let's find see if it can work with what we are adding now and may add in
> near future and then decide.
>
If we move all the conditional checks to the driver probe path, then I
think this can work. Something like the below:
struct smccc_device_info {
u32 func_id;
bool requires_smc;
const char *device_name;
};
static const struct smccc_device_info smccc_devices[] __initconst = {
{
.func_id = ARM_SMCCC_TRNG_VERSION,
.requires_smc = false,
.device_name = "arm-smccc-trng",
},
{
.func_id = RSI_ABI_VERSION,
.requires_smc = true,
.device_name = RSI_DEV_NAME,
},
};
static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
{
unsigned long ret;
struct arm_smccc_res res;
if (smccc_conduit == SMCCC_CONDUIT_NONE)
return false;
if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
return false;
arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
ret = res.a0;
if ((s32)ret == SMCCC_RET_NOT_SUPPORTED)
return false;
return true;
}
static int __init smccc_devices_init(void)
{
struct arm_smccc_device *sdev;
const struct smccc_device_info *smccc_dev;
for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
smccc_dev = &smccc_devices[i];
if (!smccc_probe_smccc_device(smccc_dev))
continue;
sdev = arm_smccc_device_register(smccc_dev->device_name);
if (IS_ERR(sdev))
pr_err("%s: could not register device: %ld\n",
smccc_dev->device_name, PTR_ERR(sdev));
}
return 0;
}
device_initcall(smccc_devices_init);
with the diff to hw_random/smccc_trng
modified arch/arm64/include/asm/archrandom.h
@@ -12,7 +12,7 @@
extern bool smccc_trng_available;
-static inline bool __init smccc_probe_trng(void)
+static inline bool smccc_probe_trng(void)
{
struct arm_smccc_res res;
modified drivers/char/hw_random/arm_smccc_trng.c
@@ -19,6 +19,8 @@
#include <linux/arm-smccc.h>
#include <linux/arm-smccc-bus.h>
+#include <asm/archrandom.h>
+
#ifdef CONFIG_ARM64
#define ARM_SMCCC_TRNG_RND ARM_SMCCC_TRNG_RND64
#define MAX_BITS_PER_CALL (3 * 64UL)
@@ -98,6 +100,10 @@ static int smccc_trng_probe(struct arm_smccc_device *sdev)
{
struct hwrng *trng;
+ /* validate the minimum version requirement */
+ if (!smccc_probe_trng())
+ return -ENODEV;
+
trng = devm_kzalloc(&sdev->dev, sizeof(*trng), GFP_KERNEL);
if (!trng)
return -ENOMEM;
We can also move arch/arm64/include/asm/rsi_smc.h to
include/linux/arm-rsi-smccc.h. There was a suggestion to move these
firmware interfaces out of architecture-specific code:
https://lore.kernel.org/all/agsNO9cc7H-b0H8L@willie-the-truck
This will also avoid the #ifdef CONFIG_ARM64
-aneesh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox