* RE: [EXT] Re: [PATCH 4/5] arm64: dts: imx93: Cortex-A Core remoteproc device node
From: Jiafei Pan @ 2026-04-30 6:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, andersson@kernel.org,
mathieu.poirier@linaro.org, Peng Fan, Frank Li,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Z.Q. Hou, Mingkai Hu, Jiafei Pan
In-Reply-To: <b7e93b01-39aa-4a9f-9927-6c634a6c727c@kernel.org>
> On 28/04/2026 11:08, Jiafei Pan wrote:
> > + init-on-array = <IMX93_CLK_LPUART2_GATE>; };
> > diff --git a/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
> > b/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
> > new file mode 100644
> > index 000000000000..9d9a60404d2b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
>
> Heh? A DTSI file for one device node?
>
> This looks a lot like downstream approach.
Use a dtsi file which could be leveraged by multiple boards, otherwise what's your suggestion? Thanks.
Jiafei.
>
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +/*
> > + * Copyright 2024-2026 NXP
> > + */
> > +
> > +/ {
> > + ca55_1: remoteproc-ca55-1 {
> > + compatible = "fsl,imx-rproc-psci";
>
> Also, you cannot have non-SoC compatibles for SoC component. Nothing here,
> nor in the binding patch, explains that.
>
> >
> Best regards,
> Krzysztof
Actually it is CPU Core related dts nodes, so I put it in SoC.
Jiafei.
^ permalink raw reply
* Re: [PATCH RFC 0/3] media: videobuf2: opt-in dma_resv producer fences for V4L2 dmabuf exports
From: Christian König @ 2026-04-30 6:51 UTC (permalink / raw)
To: Nicolas Dufresne, Markus Fritsche, Tomasz Figa, Marek Szyprowski,
Mauro Carvalho Chehab, Sumit Semwal, Ezequiel Garcia,
Philipp Zabel, Jacob Chen, Heiko Stuebner
Cc: linux-media, linux-kernel, dri-devel, linaro-mm-sig,
linux-rockchip, linux-arm-kernel
In-Reply-To: <3d8deeb15581b754e4c061d4c4a13657aa08bc3c.camel@ndufresne.ca>
On 4/29/26 23:22, Nicolas Dufresne wrote:
> Hi Markus,
>
> Le mercredi 29 avril 2026 à 19:53 +0000, Markus Fritsche a écrit :
>> Hi,
>>
>> This series proposes a small opt-in API in videobuf2-core that lets V4L2
>> drivers populate a dma_resv exclusive write fence on the dmabufs they
>> export to userspace, signalled when the buffer transitions to
>> VB2_BUF_STATE_DONE. Two example drivers (hantro, rockchip-rga) opt in
>> to demonstrate the call shape; the change is no-op for every other
>> driver.
>
> Thanks for attempting again this feat. I see you went for implicit fencing, but
> in the past we've been recommend to stay away from these and adopt an explicit
> fencing model. Is this something you have started to think about, have you
> reviewed past proposal in regard to fences ?
Yeah agree, I just wanted to note something similar.
Implicit fencing is basically just a workaround how the GPU HW used to work ~20years ago and only rarely makes sense today.
On the other hand putting it behind a flag might be acceptable when you want to interact with implicit synced HW, e.g. a GPU.
If you want to expose a dma_fence to userspace then using a sync_file as output from the IOCTL which kicks of the operation is usually the better approach.
>>
>> Why
>> ---
>> Modern Wayland compositors and any other userspace consumers that
>> import V4L2-produced dmabufs and want to do implicit synchronization
>> the spec-clean way (poll(POLLIN) on the dmabuf fd, or
>> DMA_BUF_IOCTL_EXPORT_SYNC_FILE for a sync_file) currently get either:
>>
>> 1. A stub fence from dma_buf_export_sync_file(), because the dmabuf's
>> dma_resv has no fences populated. The kernel substitutes
>> dma_fence_get_stub() which is permanently signalled. The compositor
>> "successfully" waits on a fence that represents nothing real about
>> the producer's state.
>> 2. A poll(POLLIN) on the dmabuf fd that returns immediately for the
>> same reason — dma_buf_poll_add_cb finds zero fences in the resv,
>> triggers the wake callback inline, and reports POLLIN ready before
>> the producer has actually said anything.
>>
>> Today this works as a happy accident on most paths because clients
>> attach buffers after VIDIOC_DQBUF, which the userspace V4L2 contract
>> guarantees only returns a buffer after the producer is done. So the
>> implicit "the kernel's stub fence is fine because the buffer is
>> already complete by the time anyone polls it" assumption has held.
>
> There is no accident, just saying. Have you studied also the other side of
> fences, the one that actually cause problem with Freedreno and Etnaviv ? To me
> these would be higher priority since they are known to cause "back flash" kind
> of bugs, specially for compositor that are not expecting GL driver to place
> implicit fences on imported (v4l2 allocated) buffers.
>
>>
>> But:
>>
>> - It's a contract gap. The kernel claims to expose implicit sync; it
>> does not, for V4L2 producers.
>> - It paid latency for nothing. Every Wayland frame from a V4L2
>> producer pays a DMA_BUF_IOCTL_EXPORT_SYNC_FILE round-trip for a
>> fence that's stub-signalled. On Mali-class hardware (RK3566 Wayland
>> chrome video playback), this contributed to compositor stalls.
>> Removing the wait at the compositor level is a workaround, not a
>> fix.
>> - It blocks downstream consumers from doing the right thing. A
>> Wayland compositor that defensively waits on a sync_file gets a
>> stub-fence pass-through with no actual gating; if the V4L2 driver
>> ever has an out-of-band path that releases the buffer before
>> finishing the write, there is no fence to gate on.
>
> Some things don't add up here. I think I want to remind that there is a contract
> in regard to delivering a fence to userspace. One of the most important aspect
> of fences is that they must in finit time be signaled, regardless what userspace
> decided to do next. And for that reason, you shouldn't deliver a fence to
> userspace if its not armed. In my reading, you are delivering that fence at
> QBUF(capture) time, just like what Gustavo was trying to do previously. Its even
> worse if you deliver it to your compositor allowing that compositor to hang
> forever by not feeding any bitstream.
+1
> Let's take Hantro driver as an example. The right moment to deliver the fence is
> either right before we set the DEC bit on the control register, or somewhere
> before that when you have bitstream, parameters and request queued. At that
> moment, you are guarantied that the decode will either finish or fail (yes, it
> can fail, and its extremely common with live stream, or when application calls
> streamoff, since in v4l2, we cancel work). Prior to that, user may starve the
> OUTPUT queue (the bitstream) and cause the fence to hold forever. This would
> break the contract I mention earlier.
Exactly that yes.
Regarding failed or canceled submission handling that is not so much of a problem since we also have proper error signaling on fences.
But what is usually problematic as well are things like dynamic memory management, e.g. when HW uses the PCIe PRI interface or similar functionality on other bus systems.
Getting the contract right is indeed really tricky but unfortunately mandatory because you otherwise run into deadlocks sooner or later.
> Though, if you attach the fence at that moment, you will need to design how to
> signal the fence readiness (rather then the data readiness). One idea would be
> (with userspace opting-in) to signal the queue at that moment. But then you
> can't do the memory management operation you would normally do in DQBUF. This of
> course don't apply to hantro, which has no device cache, but we can't design
> something in vb2 for the old HW. So we'd need to move memory management somwhere
> else, maybe buffer_done, though you have to carefully make sure in which context
> you do that, you can't sleep in an IRQ.
>
> There is an obvious benefit of basing your solution on
> DMA_BUF_IOCTL_EXPORT_SYNC_FILE, once you get there, you'll discover that there
> is very little room in v4l2_buffer, and that was causing a lot of headache to
> previous people attempting this. Though, if we look forward, we could also
> consider this a feature of the media_request. Queuing a request could maybe
> deliver a fence, assuming few pre-condition that guarantee execution (or
> failure) are met. We've seen with DW100 recently that its rather easy to convert
> an existing m2m driver to request. The media API is a much more open canvas to
> design new mechanism. We could have a really simple ioctl that attach out fences
> to request, and in a future hook it to our own depedency manager.
My request with the DMA-buf maintainer hat on would be to correctly annotate your fence submission path the with lockdep primitives Sima wrote and then make a few test runs with lockdep enabled.
It's not a prove of correctness but this at least gives you a good hint if your locking order and memory allocation paths are correct.
Regards,
Christian.
>
> I'm simply throwing ideas, I could have missed few things in your PoC, let me
> know.
>
> Nicolas
>
>> What
>> ----
>> Patch 1 adds:
>>
>> - struct dma_fence *release_fence to struct vb2_buffer
>> - u64 dma_resv_fence_context + atomic64_t dma_resv_fence_seqno +
>> spinlock_t dma_resv_fence_lock to struct vb2_queue
>> - vb2_buffer_attach_release_fence(vb) — drivers call this from their
>> buf_queue callback. Allocates a dma_fence on the queue's fence
>> context, attaches it as DMA_RESV_USAGE_WRITE on each plane's
>> dmabuf->resv. No-op for buffers without exported dmabufs.
>> - vb2_buffer_done() extended to signal+put the fence if attached,
>> so the producer's completion signal lands in the resv synchronously
>> with the userspace DQBUF wakeup.
>>
>> Patches 2 and 3 add a single call to the helper from hantro_buf_queue
>> and rga_buf_queue respectively. Both are demonstration drivers; other
>> vb2 drivers can opt in incrementally with the same one-line change.
>>
>> Tested on
>> ---------
>> PineTab2 (RK3566 / Mali-G52 panfrost / mainline 6.19.10, this series
>> backported), playing 1080p30 H.264 in chromium under KDE Plasma 6.6.4
>> Wayland. The test harness is the chromium-fourier patch series at
>> https://github.com/marfrit/fourier — chromium plus a KWin patch
>> that *previously bypassed* Transaction::watchDmaBuf because the
>> kernel-side fence was stub-signalled. With this series applied, the
>> bypass becomes unnecessary; KWin's fence wait completes correctly
>> because the fence now signals when hantro completes the capture
>> buffer write.
>>
>> End-to-end result before the kernel patch (chromium + Qt 6 patches +
>> KWin watchDmaBuf bypass): 1080p30 H.264 plays through, ~81% combined
>> chrome CPU, but the watchDmaBuf bypass weakens KWin's defenses against
>> misbehaving clients.
>>
>> End-to-end result after the kernel patch (chromium + Qt 6 patches +
>> plain unmodified KWin): 1080p30 H.264 plays through with the same CPU
>> profile, KWin's watchDmaBuf wait completes within microseconds against
>> the now-real producer fence, no defenses weakened.
>>
>> What's missing in this RFC
>> --------------------------
>> - Other vb2-using drivers don't opt in. Each maintainer should look
>> at their driver and decide. The hantro + rga patches show the
>> shape; copying it to other drivers should be straightforward.
>> - For drivers that have intermediate image-processor stages (e.g.
>> CSI -> ISP -> user), the fence semantics across stage boundaries
>> are out of scope here. This series only addresses the producer-to-
>> userspace edge.
>> - No selftest. videobuf2 doesn't have a great in-tree selftest harness
>> for dmabuf flows; the validation is end-to-end at the userspace
>> consumer level (KWin, in our case).
>>
>> Reviews especially welcome on:
>>
>> - The decision to make this opt-in per driver vs. automatic for all
>> vb2-CAPTURE queues. Auto-on would force every driver to be audited;
>> opt-in is incremental and safer but leaves the contract gap for
>> drivers nobody touches.
>> - Whether vb2_buffer_done is the right place to signal vs. an earlier
>> hook (e.g. immediately after DMA-from-device finishes). For hantro
>> the two are effectively the same; for drivers with asynchronous
>> post-processing they may differ.
>> - The choice of DMA_RESV_USAGE_WRITE — we are emitting the producer's
>> write completion, so WRITE matches dma-buf documentation, but a
>> sanity check is welcome.
>>
>> Cheers,
>> Markus
>>
>>
>> Markus Fritsche (3):
>> media: videobuf2: add dma_resv release-fence helper
>> media: hantro: attach dma_resv release fence at buf_queue
>> media: rockchip-rga: attach dma_resv release fence at buf_queue
>>
>> .../media/common/videobuf2/videobuf2-core.c | 95 +++++++++++++++++++
>> drivers/media/platform/rockchip/rga/rga-buf.c | 10 ++
>> .../media/platform/verisilicon/hantro_v4l2.c | 12 +++
>> include/media/videobuf2-core.h | 29 ++++++
>> 4 files changed, 146 insertions(+)
^ permalink raw reply
* RE: [EXT] Re: [PATCH 2/5] drivers: remoteproc: imx: add support for Cortex-A Core
From: Jiafei Pan @ 2026-04-30 6:47 UTC (permalink / raw)
To: Krzysztof Kozlowski, andersson@kernel.org,
mathieu.poirier@linaro.org, Peng Fan, Frank Li,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Z.Q. Hou, Mingkai Hu, Jiafei Pan
In-Reply-To: <3ddf533b-e023-4982-8ba0-0963b9d72c5c@kernel.org>
>
> On 28/04/2026 11:08, Jiafei Pan wrote:
> > Add Cortex-A Core remoteproc support, it use PSCI and SIP SMC call to
> > manage Cortex-A Core to be on or off.
> >
> > Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
>
>
> Why do you use subject prefix "drivers:"?
>
> Best regards,
> Krzysztof
Will remove it, thanks.
Jiafei.
^ permalink raw reply
* RE: [EXT] Re: [PATCH v2 1/5] dt-bindings: remoteproc: add imx-rproc-psci binding
From: Jiafei Pan @ 2026-04-30 6:46 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: imx@lists.linux.dev, Peng Fan, mathieu.poirier@linaro.org,
Mingkai Hu, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-remoteproc@vger.kernel.org,
Z.Q. Hou, festevam@gmail.com, kernel@pengutronix.de, Frank Li,
linux-arm-kernel@lists.infradead.org, andersson@kernel.org,
s.hauer@pengutronix.de, Jiafei Pan
In-Reply-To: <177743718015.3571544.12237368801599782841.robh@kernel.org>
> On Wed, 29 Apr 2026 11:10:43 +0800, Jiafei Pan wrote:
> > Add compatible string "fsl,imx-rproc-psci" for i.MX Cortex-A Core's
> > remoteproc support.
> >
> > Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
> > ---
> > .../remoteproc/fsl,imx-rproc-psci.yaml | 64
> +++++++++++++++++++
> > 1 file changed, 64 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.yaml
> >
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/re
> moteproc/fsl,imx-rproc-psci.yaml: properties:fsl,cpus-bits: '$ref' should not be
> valid under {'const': '$ref'}
> hint: Standard unit suffix properties don't need a type $ref
> from schema $id:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicet
> ree.org%2Fmeta-schemas%2Fcore.yaml&data=05%7C02%7CJiafei.Pan%40nx
> p.com%7C047a041815cd4324f05f08dea5a8672f%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C639130339864199051%7CUnknown%7CTWFp
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=olcEFl6U
> HPDO%2FSIhOEekKq%2BEdROarh3zIvVm1oh0FKM%3D&reserved=0
> Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.
> dts:8.9-16: Warning (ranges_format): /reserved-memory:ranges: empty
> "ranges" property but its #size-cells (2) differs from / (1)
> Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.
> dts:5.21-14.7: Warning (avoid_default_addr_size): /reserved-memory: Relying
> on default #address-cells value
> Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.
> dts:5.21-14.7: Warning (avoid_default_addr_size): /reserved-memory: Relying
> on default #size-cells value
> Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc-psci.example.
> dtb: Warning (unique_unit_address_if_enabled): Failed prerequisite
> 'avoid_default_addr_size'
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/re
> moteproc/fsl,imx-rproc-psci.example.dtb: /: 'compatible' is a required
> property
> from schema $id:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicet
> ree.org%2Fschemas%2Froot-node.yaml&data=05%7C02%7CJiafei.Pan%40nx
> p.com%7C047a041815cd4324f05f08dea5a8672f%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C639130339864225830%7CUnknown%7CTWFp
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nZOtCvf
> 57EyKj1cLd1TwW6sRJeAc67cOXgFG%2BSrVAX4%3D&reserved=0
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/re
> moteproc/fsl,imx-rproc-psci.example.dtb: /: 'model' is a required property
> from schema $id:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicet
> ree.org%2Fschemas%2Froot-node.yaml&data=05%7C02%7CJiafei.Pan%40nx
> p.com%7C047a041815cd4324f05f08dea5a8672f%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C639130339864244545%7CUnknown%7CTWFp
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=p5Qp6lO
> dpmNSnB1Deipk95Sx%2FtdU3cbhEZnoYHZqP4g%3D&reserved=0
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/re
> moteproc/fsl,imx-rproc-psci.example.dtb: /: '#address-cells' is a required
> property
> from schema $id:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicet
> ree.org%2Fschemas%2Froot-node.yaml&data=05%7C02%7CJiafei.Pan%40nx
> p.com%7C047a041815cd4324f05f08dea5a8672f%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C639130339864262531%7CUnknown%7CTWFp
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=09mohX
> SQe4bSnzh9WQWudNgLXQ6Hi1SwK%2BiQ59GLZPA%3D&reserved=0
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/re
> moteproc/fsl,imx-rproc-psci.example.dtb: /: '#size-cells' is a required
> property
> from schema $id:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicet
> ree.org%2Fschemas%2Froot-node.yaml&data=05%7C02%7CJiafei.Pan%40nx
> p.com%7C047a041815cd4324f05f08dea5a8672f%7C686ea1d3bc2b4c6fa92c
> d99c5c301635%7C0%7C0%7C639130339864282107%7CUnknown%7CTWFp
> bGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=R85RHd
> R7SyFE8vutb1nTigpDMvYB4balwMQ1dwJvmpc%3D&reserved=0
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/re
> moteproc/fsl,imx-rproc-psci.example.dtb: remoteproc-ca55-1
> (fsl,imx-rproc-psci): fsl,cpus-bits: 2 is not of type 'array'
> from schema $id:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevicet
> ree.org%2Fschemas%2Fproperty-units.yaml&data=05%7C02%7CJiafei.Pan%4
> 0nxp.com%7C047a041815cd4324f05f08dea5a8672f%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C639130339864301617%7CUnknown%7CT
> WFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa
> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0QR
> M5EVXEq2VABkbyBIVRxep0WGhG6aXe4ieI6%2FQAr0%3D&reserved=0
>
> doc reference errors (make refcheckdocs):
>
> See
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Fdevicetree%2Fpatch%2F20260429031047.308
> 93-2-Jiafei.Pan%40nxp.com&data=05%7C02%7CJiafei.Pan%40nxp.com%7C0
> 47a041815cd4324f05f08dea5a8672f%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C639130339864319641%7CUnknown%7CTWFpbGZsb3d8ey
> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi
> TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0Aovvm3Wuu3p%2F
> 2hzjrhG8kUQiNS7cWZ0jIALpFQyfho%3D&reserved=0
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above error(s),
> then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your
> schema.
Thanks for your comments, will update the patch.
Jiafei.
^ permalink raw reply
* Re: Re: [PATCH net-next v7 2/4] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing
From: 李志 @ 2026-04-30 6:43 UTC (permalink / raw)
To: Jakub Kicinski, andrew+netdev
Cc: devicetree, davem, edumazet, robh, krzk+dt, conor+dt, netdev,
pabeni, mcoquelin.stm32, alexandre.torgue, rmk+kernel, pjw,
palmer, aou, alex, linux-riscv, linux-stm32, linux-arm-kernel,
linux-kernel, maxime.chevallier, ningyu, linmin, pinkesh.vaghela,
pritesh.patel, weishangjuan, horms
In-Reply-To: <20260428180625.738223cf@kernel.org>
> -----原始邮件-----
> 发件人: "Jakub Kicinski" <kuba@kernel.org>
> 发送时间:2026-04-29 09:06:25 (星期三)
> 收件人: lizhi2@eswincomputing.com
> 抄送: devicetree@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com, rmk+kernel@armlinux.org.uk, pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr, linux-riscv@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, maxime.chevallier@bootlin.com, ningyu@eswincomputing.com, linmin@eswincomputing.com, pinkesh.vaghela@einfochips.com, pritesh.patel@einfochips.com, weishangjuan@eswincomputing.com, horms@kernel.org
> 主题: Re: [PATCH net-next v7 2/4] net: stmmac: eic7700: enable clocks before syscon access and correct RX sampling timing
>
>
> Why Fixes? If eth1 never worked this is not a fix but new functionality
> If you want to make this a fix to prevent incompatibility - cut it down
> just to the eth0 changes.
>
Thank you for the suggestion.
You're right that eth1 never worked at Gigabit speed, so this should
not be treated as a fix.
In v8, I will split the changes into two patches within the same series:
- Patch 1 will contain only the fixes affecting the existing eth0
functionality, and will keep the Fixes tag.
- Patch 2 will add the eth1 support (RX clock inversion workaround)
as new functionality, without a Fixes tag.
Please let me know if you would prefer a different split or ordering.
>
> AI says:
>
> The step unit is being silently changed from 0.1 ns (delay_ps / 100)
> to 0.02 ns (delay_ps / 20). The same DT value now programs 5x the number
> of delay steps into the hardware.
>
This change is intentional. The previous driver used an incorrect
conversion (100ps per step), while the actual hardware step is 20ps.
This patch corrects the delay calculation to match the hardware.
The DT binding is updated accordingly to reflect the correct
20ps granularity and enforce valid values.
This binding has not yet been used in any upstream DTS, so there
are no in-tree users relying on the previous behavior.
I will clarify this explicitly in the v8 commit message.
>
> AI says
>
> In the default case this logs "invalid speed %u" but then falls
> through and still executes the regmap_write() with the base dly_param. An
> unsupported speed reports an error and reprograms the hardware anyway.
>
> Should the default path return without writing, or should the write be
> moved into the valid cases only?
>
The default case should not reprogram any hardware registers.
I will change the implementation so that register writes are only
performed for valid speeds (SPEED_10/100/1000). For unsupported
speeds, the function will only log the error and return without
any side effects.
>
> AI says:
>
> First, rx-internal-delay-ps and tx-internal-delay-ps are silently
> demoted from required to optional. The previous driver returned
> -EINVAL with "missing required property ..." when either was absent;
> the else branches have been removed, so missing properties now leave
> eth_clk_dly_param at zero and fix_mac_speed() programs zero delay
> without diagnostic. Is this intentional, and if so should the commit
> message and the DT binding reflect it?
>
> Second, the previous code silently clamped out-of-range values via
> min() and only required non-zero step units by integer truncation.
> The new code rejects non-multiples of 20 and values greater than 2540
> ps with -EINVAL at probe time. DTBs that previously probed with
> clamped delays will now fail probe. Should this stricter validation
> also be called out in the commit message?
>
Yes, this change is intentional.
The previous implementation used incorrect delay semantics
(100ps step and implicit clamping), which does not match the
actual hardware behavior.
The new implementation corrects the hardware programming to use
the real 20ps step granularity and enforces valid ranges.
Regarding the DT binding change (required → optional) and the
stricter validation, this is also intentional. Zero delay is a
valid hardware configuration, and the stricter checks are added
to avoid silently masking invalid values.
Importantly, this binding has not been used by any upstream DTS
yet, so there are no in-tree users affected by this change.
I will explicitly document both the semantic change and the
compatibility notes in the v8 commit message and update the
binding description accordingly.
>
> AI says:
>
> The eswin,hsp-sp-csr phandle-args layout is expanded from 4 cells
> (phandle + 3 offsets) to 6 cells (phandle + 5 offsets), with new
> indices 3/4/5 now required. Any DTB produced against the original
> ea77dbbdbc4e binding will fail probe here with -EINVAL.
The previous phandle-args layout (4 cells) was based on an
incomplete initial design and did not fully describe all required
hardware register offsets.
The updated 6-cell format reflects the complete hardware CSR layout
and allows explicit configuration of additional control registers.
Importantly, this binding has not been used by any upstream DTS,
so there are no in-tree users affected by this change.
I agree that this is a DT ABI change, and I will explicitly document
the compatibility impact and updated binding description in the v8
series to make this clear.
^ permalink raw reply
* Re: [PATCH 0/8] firmware: sysfb: Consolidate config/code wrt. sysfb_primary_screen
From: Thomas Zimmermann @ 2026-04-30 6:35 UTC (permalink / raw)
To: patchwork-bot+linux-riscv
Cc: linux-riscv, javierm, arnd, ardb, ilias.apalodimas, chenhuacai,
kernel, maarten.lankhorst, mripard, airlied, simona, kys,
haiyangz, wei.liu, decui, longli, deller, linux-arm-kernel,
loongarch, linux-efi, dri-devel, linux-hyperv, linux-fbdev
In-Reply-To: <177751955329.2274119.12779807302343885295.git-patchwork-notify@kernel.org>
Hi
Am 30.04.26 um 05:25 schrieb patchwork-bot+linux-riscv@kernel.org:
> Hello:
>
> This series was applied to riscv/linux.git (fixes)
> by Ard Biesheuvel <ardb@kernel.org>:
Patch 3 was fairly controversial.
Best regards
Thomas
>
> On Thu, 2 Apr 2026 11:09:14 +0200 you wrote:
>> The global state sysfb_primary_screen holds information about the
>> framebuffer provided by EFI/BIOS systems. It is part of the sysfb
>> module, but used in several places without direct connection to
>> sysfb. Fix this by making users of sysfb_primary_screen depend on
>> CONFIG_SYSFB. Fix a few issues in the process.
>>
>> Patches 1 and 2 fix general errors in the Kconfig rules. In any case,
>> these patches should be considered even without the rest of the series.
>>
>> [...]
> Here is the summary with links:
> - [1/8] hv: Select CONFIG_SYSFB only for CONFIG_HYPERV_VMBUS
> https://git.kernel.org/riscv/c/d33db956c961
> - [2/8] firmware: efi: Never declare sysfb_primary_display on x86
> https://git.kernel.org/riscv/c/5241c2ca33bb
> - [3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
> (no matching commit)
> - [4/8] firmware: sysfb: Split sysfb.c into sysfb_primary.c and sysfb_pci.c
> (no matching commit)
> - [5/8] firmware: sysfb: Implement screen_info relocation for primary display
> (no matching commit)
> - [6/8] firmware: sysfb: Avoid forward-declaring sysfb_parent_dev()
> (no matching commit)
> - [7/8] firmware: efi: Make CONFIG_EFI_EARLYCON depend on CONFIG_SYSFB; clean up
> (no matching commit)
> - [8/8] firmware: sysfb: Move CONFIG_FIRMWARE_EDID to firmware options
> (no matching commit)
>
> You are awesome, thank you!
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* RE: [PATCH 3/5] drivers: remoteproc: imx: add autoboot support for A-core remoteproc
From: Jiafei Pan @ 2026-04-30 6:22 UTC (permalink / raw)
To: Daniel Baluta (OSS), andersson@kernel.org,
mathieu.poirier@linaro.org, Peng Fan, Frank Li,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Z.Q. Hou, Mingkai Hu, Jiafei Pan
In-Reply-To: <dfc04c5d-253f-470c-b32c-2da080e91139@oss.nxp.com>
On 4/28/26 12:08, Jiafei Pan wrote:
> [You don't often get email from jiafei.pan@nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>
> Add autoboot support for Cortex-A Core remoteproc.
>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> Please also add your Signed-off-by tag here.
Will update it, thanks.
Jiafei.
See: https://developercertificate.org/
^ permalink raw reply
* RE: [PATCH 5/5] remoteproc: imx: use device node name as processor name
From: Jiafei Pan @ 2026-04-30 6:21 UTC (permalink / raw)
To: Daniel Baluta (OSS), andersson@kernel.org,
mathieu.poirier@linaro.org, Peng Fan, Frank Li,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Z.Q. Hou, Mingkai Hu, Jiafei Pan
In-Reply-To: <685ed732-fe54-4d2b-b2e9-6bfd10d67b82@oss.nxp.com>
On 4/28/26 12:08, Jiafei Pan wrote:
> [You don't often get email from jiafei.pan@nxp.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> As currently there are maybe multiple remote processors, so change
> from using fixed name to using device node name as remote processor
> name in order to make them can be distinguished by through of name in
> sys filesystem.
>
> Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
> ---
> drivers/remoteproc/imx_rproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/imx_rproc.c
> b/drivers/remoteproc/imx_rproc.c index e8d239bef5c9..17026e390e88
> 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -1357,7 +1357,7 @@ static int imx_rproc_probe(struct platform_device *pdev)
> int ret;
>
> /* set some other name then imx */
> I think you can also remove the comment above.
Updated and send this patch in a separate thread as it has less relation with A-core remoteproc, thanks.
https://lore.kernel.org/all/20260430061701.27270-1-Jiafei.Pan@nxp.com/T/#u
Jiafei.
> - rproc = devm_rproc_alloc(dev, "imx-rproc", &imx_rproc_ops,
> + rproc = devm_rproc_alloc(dev, np->name, &imx_rproc_ops,
> NULL, sizeof(*priv));
> if (!rproc)
> return -ENOMEM;
> --
> 2.43.0
>
>
^ permalink raw reply
* [PATCH] remoteproc: imx: use device node name as processor name
From: Jiafei Pan @ 2026-04-30 6:17 UTC (permalink / raw)
To: andersson, mathieu.poirier, Frank.Li, s.hauer, kernel, festevam,
linux-remoteproc, imx, linux-arm-kernel, linux-kernel, peng.fan
Cc: daniel.baluta, Jiafei Pan
As currently there are maybe multiple remote processors, so change from
using fixed name to using device node name as remote processor name in
order to make them can be distinguished by through of name in sys
filesystem.
Signed-off-by: Jiafei Pan <Jiafei.Pan@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index e8d239bef5c9..38713f6f1c50 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -1356,8 +1356,7 @@ static int imx_rproc_probe(struct platform_device *pdev)
unsigned long cpus_bits;
int ret;
- /* set some other name then imx */
- rproc = devm_rproc_alloc(dev, "imx-rproc", &imx_rproc_ops,
+ rproc = devm_rproc_alloc(dev, np->name, &imx_rproc_ops,
NULL, sizeof(*priv));
if (!rproc)
return -ENOMEM;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/2] Add runtime PM support to K3 UDMA and K3 INTA
From: Rahul Sharma @ 2026-04-30 6:11 UTC (permalink / raw)
To: r-sharma3
Cc: Frank.Li, dmaengine, kristo, linux-arm-kernel, linux-kernel, nm,
peter.ujfalusi, ssantosh, tglx, vkoul
In-Reply-To: <20260429174904.4049243-1-r-sharma3@ti.com>
Hi,
This patch series consists of 2 different subsystems of Linux. But
they work together in same subsystem of SoC that is K3 DMSS(Data Movement
Subsystem).
Both patches can be merged to their respective trees, with no
inter-dependency. They have been posted together for the ease of review.
BR,
Rahul
^ permalink raw reply
* Re: [PATCH v3 3/3] p54spi: convert to devicetree
From: Krzysztof Kozlowski @ 2026-04-30 6:10 UTC (permalink / raw)
To: Arnd Bergmann, Arnd Bergmann
Cc: Aaro Koskinen, Andreas Kemnade, Bartosz Golaszewski,
Benoît Cousson, David S . Miller, Dmitry Torokhov,
Eric Dumazet, Felipe Balbi, Jakub Kicinski, Johannes Berg,
Kevin Hilman, Krzysztof Kozlowski, Linus Walleij, Paolo Abeni,
Rob Herring, Roger Quadros, Tony Lindgren, linux-wireless, Netdev,
devicetree, linux-kernel, linux-arm-kernel,
open list:GPIO SUBSYSTEM, Linux-OMAP, Christian Lamparter
In-Reply-To: <556b64c4-febb-4dc6-8d51-1b1c2d2c6aa6@app.fastmail.com>
On 29/04/2026 23:35, Arnd Bergmann wrote:
>
> The driver doesn't know the difference, so I assume they are
> either all compatible, or the other ones don't actually work.
> I've dropped everything except "st,stlc4550" now, as that is the
> one I used in the dts file. I kept the other identifiers
> in the binding as:
>
> compatible:
> oneOf:
> - const: st,stlc4560
> - items:
> - enum:
> - cnxt,3110x
> - st,stlc4550
> - isil,p54spi
Yes, just keep this enum part sorted alphabetically.
> - const: st,stlc4560
>
> Not sure if that's the best way to express this.
>
> Arnd
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/6] mfd: dt-bindings: mt6397: Add regulator supplies
From: Mark Brown @ 2026-04-30 6:08 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, linux-arm-kernel,
linux-mediatek, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260429074113.3720271-2-wenst@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 357 bytes --]
On Wed, Apr 29, 2026 at 03:41:07PM +0800, Chen-Yu Tsai wrote:
> On the MT6397 family each buck regulator has a separate supply. LDOs are
> split into various groups with independent supplies. There is also a
> supply for the regulator control logic.
Lee, this seems like mostly a regulator series - OK for me to apply this
patch and send you a tag for it?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: anacapa: name EDSFF and thermtrip SGPIO lines
From: Rex Fu via B4 Relay @ 2026-04-30 5:44 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, Rex Fu
From: Rex Fu <Rex.Fu@amd.com>
Name the Anacapa SGPIO lines used for EDSFF power-good and thermtrip
assertion signals.
The affected lines replace legacy or unused CPU-related names with the
platform signal names used by userspace monitoring.
Signed-off-by: Rex Fu <Rex.Fu@amd.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 2cb7bd128d24..fe960bb7bc27 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -912,7 +912,7 @@ &sgpiom0 {
"PWRGD_PVDDIO_P0", "",
"PWRGD_PVDDIO_MEM_S3_P0", "",
"PWRGD_CHMP_CPU0_FPGA", "",
- "PWRGD_CHIL_CPU0_FPGA", "",
+ "HPM_EDSFF_PG", "",
"PWRGD_CHEH_CPU0_FPGA", "",
"PWRGD_CHAD_CPU0_FPGA", "FM_BMC_READY_PLD",
"", "",
@@ -957,8 +957,8 @@ &sgpiom0 {
"PDB_ALERT_R_N", "",
/* L0-L7 line 176-191 */
- "CPU0_SP7R1", "", "CPU0_SP7R2", "",
- "CPU0_SP7R3", "", "CPU0_SP7R4", "",
+ "L_EDSFF2_PG", "", "L_EDSFF3_PG", "",
+ "R_EDSFF2_PG", "", "R_EDSFF3_PG", "",
"CPU0_CORETYPE0", "", "CPU0_CORETYPE1", "",
"CPU0_CORETYPE2", "", "FM_BIOS_POST_CMPLT_R_N", "",
@@ -984,8 +984,8 @@ &sgpiom0 {
"HPM_PWR_FAIL", "Port80_b0",
"FM_DIMM_IP_FAIL", "Port80_b1",
"FM_DIMM_AH_FAIL", "Port80_b2",
- "HPM_AMC_THERMTRIP_R_L", "Port80_b3",
- "FM_CPU0_THERMTRIP_N", "Port80_b4",
+ "AMC_THERMTRIP_ASSERT", "Port80_b3",
+ "CPU_THERMTRIP_ASSERT", "Port80_b4",
"PVDDCR_SOC_P0_OCP_L", "Port80_b5",
"CPLD_SGPIO_RDY", "Port80_b6",
"", "Port80_b7",
---
base-commit: 9974969c14031a097d6b45bcb7a06bb4aa525c40
change-id: 20260430-anacapa-sgpio-edsff-thermtrip-acb228bf61be
Best regards,
--
Rex Fu <Rex.Fu@amd.com>
^ permalink raw reply related
* [PATCH] arm64/mm: Replace BUG_ON() with VM_WARN_ON_ONCE()
From: Anshuman Khandual @ 2026-04-30 5:38 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Anshuman Khandual, Catalin Marinas, Will Deacon, Ryan Roberts,
David Hildenbrand, linux-kernel
Avoid BUG_ON() while checking for inconsistent page table state conditions
and instead replace them with VM_WARN_ON_ONCE().
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Suggested-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
This patch applies on v7.1-rc1
Took the liberty in including David's tag from an internal discussion.
Earlier context during D128 RFC review.
https://lore.kernel.org/all/d61a8e11-5b8c-4cea-a7f4-a890f65d62f4@kernel.org/
arch/arm64/include/asm/pgtable.h | 4 ++--
arch/arm64/mm/mmu.c | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 4dfa42b7d053..c9e4e00a9af2 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -1007,7 +1007,7 @@ static inline pud_t *p4d_pgtable(p4d_t p4d)
static inline phys_addr_t pud_offset_phys(p4d_t *p4dp, unsigned long addr)
{
- BUG_ON(!pgtable_l4_enabled());
+ VM_WARN_ON_ONCE(!pgtable_l4_enabled());
return p4d_page_paddr(READ_ONCE(*p4dp)) + pud_index(addr) * sizeof(pud_t);
}
@@ -1130,7 +1130,7 @@ static inline p4d_t *pgd_to_folded_p4d(pgd_t *pgdp, unsigned long addr)
static inline phys_addr_t p4d_offset_phys(pgd_t *pgdp, unsigned long addr)
{
- BUG_ON(!pgtable_l5_enabled());
+ VM_WARN_ON_ONCE(!pgtable_l5_enabled());
return pgd_page_paddr(READ_ONCE(*pgdp)) + p4d_index(addr) * sizeof(p4d_t);
}
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index dd85e093ffdb..4c8959153ac4 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -273,8 +273,8 @@ static int init_pmd(pmd_t *pmdp, unsigned long addr, unsigned long end,
if (ret)
return ret;
- BUG_ON(pmd_val(old_pmd) != 0 &&
- pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
+ VM_WARN_ON_ONCE(pmd_val(old_pmd) != 0 &&
+ pmd_val(old_pmd) != READ_ONCE(pmd_val(*pmdp)));
}
phys += next - addr;
} while (pmdp++, addr = next, addr != end);
@@ -394,8 +394,8 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
if (ret)
goto out;
- BUG_ON(pud_val(old_pud) != 0 &&
- pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
+ VM_WARN_ON_ONCE(pud_val(old_pud) != 0 &&
+ pud_val(old_pud) != READ_ONCE(pud_val(*pudp)));
}
phys += next - addr;
} while (pudp++, addr = next, addr != end);
@@ -445,8 +445,8 @@ static int alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
if (ret)
goto out;
- BUG_ON(p4d_val(old_p4d) != 0 &&
- p4d_val(old_p4d) != READ_ONCE(p4d_val(*p4dp)));
+ VM_WARN_ON_ONCE(p4d_val(old_p4d) != 0 &&
+ p4d_val(old_p4d) != READ_ONCE(p4d_val(*p4dp)));
phys += next - addr;
} while (p4dp++, addr = next, addr != end);
--
2.30.2
^ permalink raw reply related
* [PATCH v4] i2c: cadence: Add shutdown handler
From: Ajay Neeli @ 2026-04-30 5:30 UTC (permalink / raw)
To: git, andi.shyti, linux-arm-kernel, linux-i2c, linux-kernel
Cc: michal.simek, srinivas.goud, radhey.shyam.pandey, Ajay Neeli
During system reboot or kexec, in-flight I2C transfers can cause
spurious interrupts or leave the bus in an undefined state. Add a
shutdown handler that marks the adapter suspended and resets the
controller, ensuring a clean handoff.
Signed-off-by: Ajay Neeli <ajay.neeli@amd.com>
---
Link: https://lore.kernel.org/linux-i2c/20250730122907.18909-1-ajay.neeli@amd.com/
Changes v3->v4:
- Replaced disable_irq() with cdns_i2c_master_reset() to avoid
potential deadlocks during shutdown
- Added pm_runtime_status_suspended() check to skip register access
when clocks are disabled
Changes v2->v3:
Corrected a typo that caused a build error in v2
Changes in v1->v2:
Disable interrupts
---
drivers/i2c/busses/i2c-cadence.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 0fb728ade92e..da8770182a18 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -1635,6 +1635,25 @@ static void cdns_i2c_remove(struct platform_device *pdev)
reset_control_assert(id->reset);
}
+/**
+ * cdns_i2c_shutdown - Prepare I2C controller for system shutdown
+ * @pdev: Handle to the platform device structure
+ *
+ * Mark the adapter as suspended and reset the controller to ensure a clean
+ * handoff during system reboot or kexec.
+ */
+static void cdns_i2c_shutdown(struct platform_device *pdev)
+{
+ struct cdns_i2c *id = platform_get_drvdata(pdev);
+
+ /* Mark the adapter as suspended to prevent further I2C transfers */
+ i2c_mark_adapter_suspended(&id->adap);
+
+ /* Reset the controller state if active - clocks are disabled when suspended */
+ if (!pm_runtime_status_suspended(&pdev->dev))
+ cdns_i2c_master_reset(&id->adap);
+}
+
static struct platform_driver cdns_i2c_drv = {
.driver = {
.name = DRIVER_NAME,
@@ -1643,6 +1662,7 @@ static struct platform_driver cdns_i2c_drv = {
},
.probe = cdns_i2c_probe,
.remove = cdns_i2c_remove,
+ .shutdown = cdns_i2c_shutdown,
};
module_platform_driver(cdns_i2c_drv);
--
2.43.0
^ permalink raw reply related
* [PATCH] ARM: dts: bcm958625-meraki-mx6x: move pinctrl conkfig to pwm
From: Rosen Penev @ 2026-04-30 5:16 UTC (permalink / raw)
To: devicetree
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Ray Jui,
Scott Branden, Broadcom internal kernel review list,
moderated list:BROADCOM IPROC ARM ARCHITECTURE, open list
On boot there is this warning:
/axi@18000000/pinctrl@3f1c0: Fixed dependency cycle(s) with /axi@18000000/pinctrl@3f1c0/pwm_leds
Fix by moving the pinctrl configuration to pwm, which is the actual
consumer.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
.../arm/boot/dts/broadcom/bcm958625-meraki-mx6x-common.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm958625-meraki-mx6x-common.dtsi b/arch/arm/boot/dts/broadcom/bcm958625-meraki-mx6x-common.dtsi
index 7e71aecb7251..0ab2ed32be2a 100644
--- a/arch/arm/boot/dts/broadcom/bcm958625-meraki-mx6x-common.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm958625-meraki-mx6x-common.dtsi
@@ -121,9 +121,6 @@ &ohci0 {
};
&pinctrl {
- pinctrl-names = "default";
- pinctrl-0 = <&pwm_leds>;
-
pwm_leds: pwm_leds {
function = "pwm";
groups = "pwm1_grp", "pwm2_grp", "pwm3_grp";
@@ -131,6 +128,9 @@ pwm_leds: pwm_leds {
};
&pwm {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm_leds>;
+
status = "okay";
};
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/3] PCI: imx6: Add root port reset to support link recovery
From: Richard Zhu @ 2026-04-30 5:09 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel,
Richard Zhu
In-Reply-To: <20260430050954.3467984-1-hongxing.zhu@nxp.com>
The PCIe link can go down due to various unexpected circumstances. Add
root port reset support to enable link recovery for the i.MX PCIe
controller when the optional "intr" interrupt is present.
Reset root port to uninitialize, initialize the PCIe controller, and
restart the PCIe link at end when a link down event happens.
On i.MX95 platforms, link events and PME share the same interrupt line.
The link event interrupt cannot use a threaded-only IRQ handler because
the PME driver uses request_irq() with only the IRQF_SHARED flag set,
which requires a primary handler.
To handle this shared interrupt scenario, register a primary interrupt
handler with IRQF_SHARED for link events and manipulate the link event
enable bits to ensure the shared interrupt source triggers only one
handler at a time.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 123 ++++++++++++++++++++++++++
1 file changed, 123 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index e35044cc52185..38e0a16655092 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -34,6 +34,7 @@
#include <linux/pm_runtime.h>
#include "../../pci.h"
+#include "../pci-host-common.h"
#include "pcie-designware.h"
#define IMX8MQ_GPR_PCIE_REF_USE_PAD BIT(9)
@@ -78,6 +79,10 @@
#define IMX95_SID_MASK GENMASK(5, 0)
#define IMX95_MAX_LUT 32
+#define IMX95_LINK_INT_CTRL_STS 0x1040
+#define IMX95_LINK_DOWN_INT_STS BIT(11)
+#define IMX95_LINK_DOWN_INT_EN BIT(10)
+
#define IMX95_PCIE_RST_CTRL 0x3010
#define IMX95_PCIE_COLD_RST BIT(0)
@@ -125,6 +130,8 @@ enum imx_pcie_variants {
#define IMX_PCIE_MAX_INSTANCES 2
struct imx_pcie;
+static int imx_pcie_reset_root_port(struct pci_host_bridge *bridge,
+ struct pci_dev *pdev);
struct imx_pcie_drvdata {
enum imx_pcie_variants variant;
@@ -158,6 +165,7 @@ struct imx_pcie {
bool supports_clkreq;
bool enable_ext_refclk;
struct regmap *iomuxc_gpr;
+ u32 lnk_intr;
u16 msi_ctrl;
u32 controller_id;
struct reset_control *pciephy_reset;
@@ -1306,6 +1314,13 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
imx_setup_phy_mpll(imx_pcie);
+ /*
+ * Callback invoked by PCI core when link down is detected and
+ * recovery is needed.
+ */
+ if (pp->bridge)
+ pp->bridge->reset_root_port = imx_pcie_reset_root_port;
+
return 0;
err_phy_off:
@@ -1573,6 +1588,9 @@ static int imx_pcie_suspend_noirq(struct device *dev)
if (!(imx_pcie->drvdata->flags & IMX_PCIE_FLAG_SUPPORTS_SUSPEND))
return 0;
+ if (imx_pcie->lnk_intr)
+ regmap_clear_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
imx_pcie_msi_save_restore(imx_pcie, true);
if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT))
imx_pcie_lut_save(imx_pcie);
@@ -1623,6 +1641,9 @@ static int imx_pcie_resume_noirq(struct device *dev)
if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT))
imx_pcie_lut_restore(imx_pcie);
imx_pcie_msi_save_restore(imx_pcie, false);
+ if (imx_pcie->lnk_intr)
+ regmap_set_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
return 0;
}
@@ -1632,6 +1653,84 @@ static const struct dev_pm_ops imx_pcie_pm_ops = {
imx_pcie_resume_noirq)
};
+static irqreturn_t imx_pcie_lnk_irq_isr(int irq, void *priv)
+{
+ struct imx_pcie *imx_pcie = priv;
+ struct dw_pcie *pci = imx_pcie->pci;
+ struct device *dev = pci->dev;
+ u32 val;
+
+ regmap_read(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS, &val);
+ if (val & IMX95_LINK_DOWN_INT_STS) {
+ dev_dbg(dev, "PCIe link down detected, initiating recovery\n");
+ regmap_clear_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
+ regmap_set_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_STS);
+
+ return IRQ_WAKE_THREAD;
+ } else {
+ return IRQ_NONE;
+ }
+}
+
+static irqreturn_t imx_pcie_lnk_irq_thread(int irq, void *priv)
+{
+ struct imx_pcie *imx_pcie = priv;
+ struct dw_pcie *pci = imx_pcie->pci;
+ struct dw_pcie_rp *pp = &pci->pp;
+ struct pci_dev *port;
+
+ for_each_pci_bridge(port, pp->bridge->bus)
+ if (pci_pcie_type(port) == PCI_EXP_TYPE_ROOT_PORT)
+ pci_host_handle_link_down(port);
+
+ regmap_set_bits(imx_pcie->iomuxc_gpr, IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
+
+ return IRQ_HANDLED;
+}
+
+static int imx_pcie_reset_root_port(struct pci_host_bridge *bridge,
+ struct pci_dev *pdev)
+{
+ struct pci_bus *bus = bridge->bus;
+ struct dw_pcie_rp *pp = bus->sysdata;
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct imx_pcie *imx_pcie = to_imx_pcie(pci);
+ int ret;
+
+ imx_pcie_msi_save_restore(imx_pcie, true);
+ if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT))
+ imx_pcie_lut_save(imx_pcie);
+ imx_pcie_stop_link(pci);
+ imx_pcie_host_exit(pp);
+
+ ret = imx_pcie_host_init(pp);
+ if (ret) {
+ dev_err(pci->dev, "Failed to re-init PCIe\n");
+ return ret;
+ }
+ ret = dw_pcie_setup_rc(pp);
+ if (ret)
+ goto err_host_deinit;
+
+ imx_pcie_start_link(pci);
+ dw_pcie_wait_for_link(pci);
+
+ if (imx_check_flag(imx_pcie, IMX_PCIE_FLAG_HAS_LUT))
+ imx_pcie_lut_restore(imx_pcie);
+ imx_pcie_msi_save_restore(imx_pcie, false);
+
+ dev_dbg(pci->dev, "Root port reset completed\n");
+ return 0;
+
+err_host_deinit:
+ imx_pcie_host_exit(pp);
+
+ return ret;
+}
+
static int imx_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -1834,9 +1933,33 @@ static int imx_pcie_probe(struct platform_device *pdev)
val |= PCI_MSI_FLAGS_ENABLE;
dw_pcie_writew_dbi(pci, offset + PCI_MSI_FLAGS, val);
}
+
+ /* Get link event irq if it is present */
+ imx_pcie->lnk_intr = platform_get_irq_byname(pdev, "intr");
+ if (imx_pcie->lnk_intr > 0) {
+ ret = devm_request_threaded_irq(dev, imx_pcie->lnk_intr,
+ imx_pcie_lnk_irq_isr,
+ imx_pcie_lnk_irq_thread,
+ IRQF_SHARED,
+ "lnk", imx_pcie);
+ if (ret) {
+ dev_err_probe(dev, ret,
+ "unable to request LNK IRQ\n");
+ goto err_host_deinit;
+ }
+
+ regmap_set_bits(imx_pcie->iomuxc_gpr,
+ IMX95_LINK_INT_CTRL_STS,
+ IMX95_LINK_DOWN_INT_EN);
+ }
}
return 0;
+
+err_host_deinit:
+ dw_pcie_host_deinit(&pci->pp);
+
+ return ret;
}
static void imx_pcie_shutdown(struct platform_device *pdev)
--
2.37.1
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: imx95: Add dma, intr, aer and pme interrupters for pcie{0,1}
From: Richard Zhu @ 2026-04-30 5:09 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel,
Richard Zhu
In-Reply-To: <20260430050954.3467984-1-hongxing.zhu@nxp.com>
Add dma, intr, aer and pme interrupters for pcie{0,1}.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 71394871d8dd0..6896d9c15bf53 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1861,8 +1861,12 @@ pcie0: pcie@4c300000 {
bus-range = <0x00 0xff>;
num-lanes = <1>;
num-viewport = <8>;
- interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "msi";
+ interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi", "dma", "intr", "aer", "pme";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 306 IRQ_TYPE_LEVEL_HIGH>,
@@ -1936,8 +1940,12 @@ pcie1: pcie@4c380000 {
bus-range = <0x00 0xff>;
num-lanes = <1>;
num-viewport = <8>;
- interrupts = <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "msi";
+ interrupts = <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi", "dma", "intr", "aer", "pme";
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
interrupt-map = <0 0 0 1 &gic 0 0 GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
--
2.37.1
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme interrupts
From: Richard Zhu @ 2026-04-30 5:09 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel,
Richard Zhu, Frank Li
In-Reply-To: <20260430050954.3467984-1-hongxing.zhu@nxp.com>
Add 'intr', 'aer', and 'pme' interrupt entries to the i.MX6Q PCIe binding
to support PCIe event-based interrupts for general controller events,
Advanced Error Reporting, and Power Management Events respectively.
These interrupts are optional for existing variants (imx6q, imx6sx, imx6qp,
imx7d, imx8mq, imx8mm, imx8mp) to maintain backward compatibility with
existing device trees.
For fsl,imx95-pcie, all 5 interrupts (msi, dma, intr, aer, pme) are
mandatory due to hardware requirements.
This introduces an ABI requirement for fsl,imx95-pcie. The i.MX95 hardware
requires dedicated interrupt lines for AER, PME, and general controller
events due to its redesigned interrupt architecture. i.MX95 cannot
function correctly without explicit interrupt routing for error handling,
power management and link event detection.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
.../bindings/pci/fsl,imx6q-pcie.yaml | 30 +++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
index 9d1349855b422..97bbfc5238a20 100644
--- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
@@ -58,12 +58,18 @@ properties:
items:
- description: builtin MSI controller.
- description: builtin DMA controller.
+ - description: PCIe event interrupt.
+ - description: builtin AER SPI standalone interrupt line.
+ - description: builtin PME SPI standalone interrupt line.
interrupt-names:
minItems: 1
items:
- const: msi
- const: dma
+ - const: intr
+ - const: aer
+ - const: pme
reset-gpio:
description: Should specify the GPIO for controlling the PCI bus device
@@ -231,6 +237,30 @@ allOf:
- const: ref
- const: extref # Optional
+ interrupts:
+ minItems: 5
+ interrupt-names:
+ minItems: 5
+
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx6q-pcie
+ - fsl,imx6sx-pcie
+ - fsl,imx6qp-pcie
+ - fsl,imx7d-pcie
+ - fsl,imx8mm-pcie
+ - fsl,imx8mp-pcie
+ - fsl,imx8mq-pcie
+ - fsl,imx8q-pcie
+ then:
+ properties:
+ interrupts:
+ maxItems: 2
+ interrupt-names:
+ maxItems: 2
+
unevaluatedProperties: false
examples:
--
2.37.1
^ permalink raw reply related
* [PATCH v3 0/3] Add root port reset to support link recovery
From: Richard Zhu @ 2026-04-30 5:09 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam
Cc: linux-pci, linux-arm-kernel, devicetree, imx, linux-kernel
Based on the following patch-set[1] issued by Mani.
Add support for resetting the Root Port for i.MX PCIe to enable link recovery.
[1] [v7,0/4] PCI: Add support for resetting the Root Ports in a platform specific way
PCIe links can go down due to various unexpected circumstances. This patch series
adds root port reset support for link recovery on i.MX PCIe controllers when the
optional "intr" interrupt is present.
When a link down event is detected, the root port reset uninitializes and
reinitializes the PCIe controller, then restarts the PCIe link.
On i.MX95 platforms, link events and PME share the same interrupt line.
Link event interrupts cannot use only an IRQ thread handler because the PME
driver uses request_irq() to bind the PME interrupt directly with only the
IRQF_SHARED flag set.
To address this, we register one handler with IRQF_SHARED for link event
interrupts and manipulate the enable bits of link events to ensure the same
interrupt source is triggered only once at a time.
Additionally, this series adds 'intr', 'aer', and 'pme' interrupt entries to
the i.MX6Q PCIe binding to support PCIe event-based interrupts for general
controller events, Advanced Error Reporting, and Power Management Events
respectively.
Changes in v3:
- Don't add a new if:block; Drop the maxItems constraint of the interrupts
property for i.MX95 PCIe.
- Add constraints for the interrupts property for other variants.
- Regarding the ABI break: add descriptions explaining why these new
interrupts are mandatory and required by i.MX95 PCIe.
Changes in v2:
- Constrain the new added three interrupt entries to be valid only for the
i.MX95 variant using conditional schemas
[PATCH v3 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme
[PATCH v3 2/3] arm64: dts: imx95: Add dma, intr, aer and pme
[PATCH v3 3/3] PCI: imx6: Add root port reset to support link
Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml | 30 ++++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx95.dtsi | 16 +++++++++---
drivers/pci/controller/dwc/pci-imx6.c | 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 165 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH v6 4/6] media: mediatek: encoder: Add support for VCP encode process
From: Irui Wang (王瑞) @ 2026-04-30 4:08 UTC (permalink / raw)
To: robh+dt@kernel.org, Tiffany Lin (林慧珊),
mchehab@kernel.org, nicolas.dufresne@collabora.com,
Kyrie Wu (吴晗), hverkuil-cisco@xs4all.nl,
matthias.bgg@gmail.com, krzk+dt@kernel.org,
AngeloGioacchino Del Regno
Cc: linux-kernel@vger.kernel.org,
Longfei Wang (王龙飞),
linux-mediatek@lists.infradead.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org,
Maoguang Meng (孟毛广),
Yunfei Dong (董云飞),
Project_Global_Chrome_Upstream_Group,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <62415d732ccaed02bf12a8e68e10ac8d58b87fa9.camel@collabora.com>
Dear Nicolas,
Thank you greatly for taking the time to help review the patch.
On Wed, 2026-04-29 at 10:56 -0400, Nicolas Dufresne wrote:
> Le jeudi 23 avril 2026 à 15:33 +0800, Irui Wang a écrit :
> > Adapt the encoder driver to support VCP firmware interface.
> >
> > Set the encoder driver firmware type to 'VCP'.
> > Allocate RC buffers using the VCP device.
> > Send the shared memory address to VCP and map the encoder VSI
> > address
> > to the CPU address space using the VCP shared memory address.
> >
> > Signed-off-by: Irui Wang <irui.wang@mediatek.com>
> > ---
> > .../mediatek/vcodec/common/mtk_vcodec_fw.c | 6 +++++
> > .../mediatek/vcodec/common/mtk_vcodec_fw.h | 1 +
> > .../vcodec/common/mtk_vcodec_fw_priv.h | 1 +
> > .../vcodec/common/mtk_vcodec_fw_vcp.c | 6 +++++
> > .../vcodec/encoder/mtk_vcodec_enc_drv.c | 3 +++
> > .../vcodec/encoder/venc/venc_common_if.c | 23 ++++++++++++++-
> > ----
> > .../mediatek/vcodec/encoder/venc_vpu_if.c | 14 ++++++++++-
> > 7 files changed, 47 insertions(+), 7 deletions(-)
> >
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
> > b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
> > index 0381acceda25..7a504f093bd8 100644
> > --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
> > +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.c
> > @@ -105,3 +105,9 @@ int mtk_vcodec_fw_get_type(struct mtk_vcodec_fw
> > *fw)
> > return fw->type;
> > }
> > EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_type);
> > +
> > +struct device *mtk_vcodec_fw_get_dev(struct mtk_vcodec_fw *fw)
> > +{
> > + return fw->ops->get_fw_dev(fw);
> > +}
> > +EXPORT_SYMBOL_GPL(mtk_vcodec_fw_get_dev);
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> > b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> > index e7304a7dd3e0..56c26b91651e 100644
> > --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> > +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> > @@ -43,5 +43,6 @@ int mtk_vcodec_fw_ipi_send(struct mtk_vcodec_fw
> > *fw, int id,
> > int mtk_vcodec_fw_get_type(struct mtk_vcodec_fw *fw);
> > int mtk_vcodec_fw_get_ipi(enum mtk_vcodec_fw_type type, int
> > hw_id);
> > int mtk_vcodec_fw_get_venc_ipi(enum mtk_vcodec_fw_type type);
> > +struct device *mtk_vcodec_fw_get_dev(struct mtk_vcodec_fw *fw);
> >
> > #endif /* _MTK_VCODEC_FW_H_ */
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.
> > h
> > b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.
> > h
> > index 0a2a9b010244..710c83c871f4 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.
> > h
> > +++
> > b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_priv.
> > h
> > @@ -29,6 +29,7 @@ struct mtk_vcodec_fw_ops {
> > int (*ipi_send)(struct mtk_vcodec_fw *fw, int id, void *buf,
> > unsigned int len, unsigned int wait);
> > void (*release)(struct mtk_vcodec_fw *fw);
> > + struct device *(*get_fw_dev)(struct mtk_vcodec_fw *fw);
> > };
> >
> > #if IS_ENABLED(CONFIG_VIDEO_MEDIATEK_VCODEC_VPU)
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
> > b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
> > index 6b69ce44d4bb..2859fe78f67d 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw_vcp.c
> > @@ -500,6 +500,11 @@ static void mtk_vcodec_vcp_release(struct
> > mtk_vcodec_fw *fw)
> >
> > }
> >
> > +static struct device *mtk_vcodec_vcp_get_fw_dev(struct
> > mtk_vcodec_fw *fw)
> > +{
> > + return fw->vcp->vcp_device->dev;
> > +}
> > +
> > static const struct mtk_vcodec_fw_ops mtk_vcodec_vcp_msg = {
> > .load_firmware = mtk_vcodec_vcp_load_firmware,
> > .get_vdec_capa = mtk_vcodec_vcp_get_vdec_capa,
> > @@ -508,6 +513,7 @@ static const struct mtk_vcodec_fw_ops
> > mtk_vcodec_vcp_msg = {
> > .ipi_register = mtk_vcodec_vcp_set_ipi_register,
> > .ipi_send = mtk_vcodec_vcp_ipi_send,
> > .release = mtk_vcodec_vcp_release,
> > + .get_fw_dev = mtk_vcodec_vcp_get_fw_dev,
> > };
> >
> > struct mtk_vcodec_fw *mtk_vcodec_fw_vcp_init(void *priv, enum
> > mtk_vcodec_fw_use fw_use)
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv
> > .c
> > b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv
> > .c
> > index 4e4541b2fc8e..2f6ee0cd15e3 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv
> > .c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/encoder/mtk_vcodec_enc_drv
> > .c
> > @@ -262,6 +262,9 @@ static int mtk_vcodec_probe(struct
> > platform_device *pdev)
> > } else if (!of_property_read_u32(pdev->dev.of_node,
> > "mediatek,scp",
> > &rproc_phandle)) {
> > fw_type = SCP;
> > + } else if (!of_property_read_u32(pdev->dev.of_node,
> > "mediatek,vcp",
> > + &rproc_phandle)) {
> > + fw_type = VCP;
>
> Similar comment on the patchset you depend on, its third firmware
> type, and time
> to cleanup. The of_device_get_match_data() should be sufficient for
> this simple
> case, there is not reason for custom DT parsing here. PLace the
> fw_type in the
> pdata, and move of_device_get_match_data() call earlier.
>
> Please apply the same logic for the entire patchset. Every bit of
> information
> that is purely static to your device is better placed in the pdata
> then through
> addition of if/else conditions all over the place. The pdata can also
> have ops
> in it, letting easily firmware specific code without having to do
> if/else
> everywhere.
>
> Nicolas
I will clean up this if/else in next patch, and with the logic, I will
review and modify the entire patch set if needed.
Thanks
Best Regards
>
> > } else {
> > dev_err(&pdev->dev, "[MTK VCODEC] Could not get venc
> > IPI device");
> > return -ENODEV;
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_i
> > f.c
> > b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_i
> > f.c
> > index 050b827f0fd0..d981155aeb8c 100644
> > ---
> > a/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_i
> > f.c
> > +++
> > b/drivers/media/platform/mediatek/vcodec/encoder/venc/venc_common_i
> > f.c
> > @@ -480,8 +480,13 @@ static void venc_free_rc_buf(struct venc_inst
> > *inst,
> > {
> > int i;
> > struct device *dev;
> > + struct mtk_vcodec_fw *fw = inst->ctx->dev->fw_handler;
> > +
> > + if (mtk_vcodec_fw_get_type(fw) == VCP)
> > + dev = mtk_vcodec_fw_get_dev(fw);
> > + else
> > + dev = &inst->ctx->dev->plat_dev->dev;
> >
> > - dev = &inst->ctx->dev->plat_dev->dev;
> > mtk_venc_mem_free(inst, dev, &bufs->rc_code);
> >
> > for (i = 0; i < core_num; i++)
> > @@ -530,12 +535,18 @@ static int venc_alloc_rc_buf(struct venc_inst
> > *inst,
> > struct device *dev;
> > void *tmp_va;
> >
> > - dev = &inst->ctx->dev->plat_dev->dev;
> > - if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
> > - return -ENOMEM;
> > + if (mtk_vcodec_fw_get_type(fw) == VCP) {
> > + dev = mtk_vcodec_fw_get_dev(fw);
> > + if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
> > + return -ENOMEM;
> > + } else {
> > + dev = &inst->ctx->dev->plat_dev->dev;
> > + if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_code))
> > + return -ENOMEM;
> >
> > - tmp_va = mtk_vcodec_fw_map_dm_addr(fw, bufs->rc_code.pa);
> > - memcpy(bufs->rc_code.va, tmp_va, bufs->rc_code.size);
> > + tmp_va = mtk_vcodec_fw_map_dm_addr(fw, bufs-
> > >rc_code.pa);
> > + memcpy(bufs->rc_code.va, tmp_va, bufs->rc_code.size);
> > + }
> >
> > for (i = 0; i < core_num; i++) {
> > if (mtk_venc_mem_alloc(inst, dev, &bufs->rc_info[i]))
> > diff --git
> > a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
> > b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
> > index 7772b8442ebc..0f4693e04a9f 100644
> > --- a/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
> > +++ b/drivers/media/platform/mediatek/vcodec/encoder/venc_vpu_if.c
> > @@ -8,13 +8,23 @@
> > #include "venc_ipi_msg.h"
> > #include "venc_vpu_if.h"
> >
> > +#define VSI_OFFSET_MASK 0x0FFFFFFF
> > +
> > static void handle_enc_init_msg(struct venc_vpu_inst *vpu, const
> > void *data)
> > {
> > const struct venc_vpu_ipi_msg_init_comm *msg = data;
> > struct mtk_vcodec_fw *fw = vpu->ctx->dev->fw_handler;
> > + u64 pa_start, vsi_offset;
> >
> > vpu->inst_addr = msg->init_ack.vpu_inst_addr;
> > - vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, vpu->inst_addr);
> > +
> > + if (mtk_vcodec_fw_get_type(fw) == VCP) {
> > + pa_start = (u64)fw->vcp->iova_addr;
> > + vsi_offset = (msg->vpu_vsi_addr & VSI_OFFSET_MASK) -
> > (pa_start & VSI_OFFSET_MASK);
> > + vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, ENCODER_MEM) +
> > vsi_offset;
> > + } else {
> > + vpu->vsi = mtk_vcodec_fw_map_dm_addr(fw, msg-
> > >vpu_vsi_addr);
> > + }
> >
> > /* Firmware version field value is unspecified on MT8173. */
> > if (mtk_vcodec_fw_get_type(fw) == VPU)
> > @@ -155,6 +165,8 @@ int vpu_enc_init(struct venc_vpu_inst *vpu)
> > out.base.venc_inst = (unsigned long)vpu;
> > if (MTK_ENC_DRV_IS_COMM(vpu->ctx)) {
> > out.codec_type = vpu->ctx->q_data[MTK_Q_DATA_DST].fmt-
> > >fourcc;
> > + if (mtk_vcodec_fw_get_type(vpu->ctx->dev->fw_handler)
> > == VCP)
> > + out.shared_iova = vpu->ctx->dev->fw_handler-
> > >vcp->iova_addr;
> > msg_size = sizeof(struct venc_ap_ipi_msg_init_comm);
> > } else {
> > msg_size = sizeof(struct venc_ap_ipi_msg_init);
^ permalink raw reply
* [PATCH v2 4/5] mm: Don't retry page fault if folio is uptodate during swap-in
From: Barry Song (Xiaomi) @ 2026-04-30 4:04 UTC (permalink / raw)
To: akpm, linux-mm, willy
Cc: david, ljs, liam, vbabka, rppt, surenb, mhocko, jack, pfalcato,
wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl,
kasong, shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Barry Song (Xiaomi)
In-Reply-To: <20260430040427.4672-1-baohua@kernel.org>
If we are waiting for long I/O to complete, it makes sense to
avoid holding locks for too long. However, if the folio is
uptodate, we are likely only waiting for a concurrent PTE
update to finish. Retrying the entire page fault seems
excessive.
Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
---
mm/memory.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index 0c740ca363cc..a2e4f2d87ec8 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4949,6 +4949,13 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
}
swapcache = folio;
+ /*
+ * If the folio is uptodate, we are likely only waiting for
+ * another concurrent PTE mapping to complete, which should
+ * be brief. No need to drop the lock and retry the fault.
+ */
+ if (folio_test_uptodate(folio))
+ vmf->flags &= ~FAULT_FLAG_ALLOW_RETRY;
ret |= folio_lock_or_retry(folio, vmf);
if (ret & VM_FAULT_RETRY) {
if (fault_flag_allow_retry_first(vmf->flags) &&
--
2.39.3 (Apple Git-146)
^ permalink raw reply related
* [PATCH v2 5/5] mm/filemap: Avoid retrying page faults on uptodate folios in filemap faults
From: Barry Song (Xiaomi) @ 2026-04-30 4:04 UTC (permalink / raw)
To: akpm, linux-mm, willy
Cc: david, ljs, liam, vbabka, rppt, surenb, mhocko, jack, pfalcato,
wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl,
kasong, shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Barry Song (Xiaomi)
In-Reply-To: <20260430040427.4672-1-baohua@kernel.org>
For uptodate folios, we are not waiting on I/O. We should
be able to acquire the folio lock shortly, so there is no
need to drop per-vma locks and perform a full PF retry.
Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
---
mm/filemap.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/mm/filemap.c b/mm/filemap.c
index b532d6cbafc8..0d2f6af5d0fe 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -3533,6 +3533,13 @@ vm_fault_t filemap_fault(struct vm_fault *vmf)
}
}
+ /*
+ * If the folio is uptodate, we are likely only waiting for
+ * another concurrent PTE mapping to complete, which should
+ * be brief. No need to drop the lock and retry the fault.
+ */
+ if (folio_test_uptodate(folio))
+ vmf->flags &= ~FAULT_FLAG_ALLOW_RETRY;
if (!lock_folio_maybe_drop_mmap(vmf, folio, &fpin))
goto out_retry;
--
2.39.3 (Apple Git-146)
^ permalink raw reply related
* [PATCH v2 3/5] mm: Move folio_lock_or_retry() and drop __folio_lock_or_retry()
From: Barry Song (Xiaomi) @ 2026-04-30 4:04 UTC (permalink / raw)
To: akpm, linux-mm, willy
Cc: david, ljs, liam, vbabka, rppt, surenb, mhocko, jack, pfalcato,
wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl,
kasong, shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Barry Song (Xiaomi)
In-Reply-To: <20260430040427.4672-1-baohua@kernel.org>
folio_lock_or_retry() is effectively only used in mm/memory.c,
not in the filemap code. Move it there and make it static.
The helper __folio_lock_or_retry() can be folded into
folio_lock_or_retry(), allowing it to be removed.
Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
---
include/linux/pagemap.h | 17 -------------
mm/filemap.c | 45 ----------------------------------
mm/memory.c | 53 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 62 deletions(-)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 1f50991b43e3..500ab783bf70 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -1101,7 +1101,6 @@ static inline bool wake_page_match(struct wait_page_queue *wait_page,
void __folio_lock(struct folio *folio);
int __folio_lock_killable(struct folio *folio);
-vm_fault_t __folio_lock_or_retry(struct folio *folio, struct vm_fault *vmf);
void unlock_page(struct page *page);
void folio_unlock(struct folio *folio);
@@ -1198,22 +1197,6 @@ static inline int folio_lock_killable(struct folio *folio)
return 0;
}
-/*
- * folio_lock_or_retry - Lock the folio, unless this would block and the
- * caller indicated that it can handle a retry.
- *
- * Return value and mmap_lock implications depend on flags; see
- * __folio_lock_or_retry().
- */
-static inline vm_fault_t folio_lock_or_retry(struct folio *folio,
- struct vm_fault *vmf)
-{
- might_sleep();
- if (!folio_trylock(folio))
- return __folio_lock_or_retry(folio, vmf);
- return 0;
-}
-
/*
* This is exported only for folio_wait_locked/folio_wait_writeback, etc.,
* and should not be used directly.
diff --git a/mm/filemap.c b/mm/filemap.c
index a045b771e8de..b532d6cbafc8 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1740,51 +1740,6 @@ static int __folio_lock_async(struct folio *folio, struct wait_page_queue *wait)
return ret;
}
-/*
- * Return values:
- * 0 - folio is locked.
- * non-zero - folio is not locked.
- * mmap_lock or per-VMA lock has been released (mmap_read_unlock() or
- * vma_end_read()), unless flags had both FAULT_FLAG_ALLOW_RETRY and
- * FAULT_FLAG_RETRY_NOWAIT set, in which case the lock is still held.
- *
- * If neither ALLOW_RETRY nor KILLABLE are set, will always return 0
- * with the folio locked and the mmap_lock/per-VMA lock is left unperturbed.
- */
-vm_fault_t __folio_lock_or_retry(struct folio *folio, struct vm_fault *vmf)
-{
- unsigned int flags = vmf->flags;
-
- if (fault_flag_allow_retry_first(flags)) {
- /*
- * CAUTION! In this case, mmap_lock/per-VMA lock is not
- * released even though returning VM_FAULT_RETRY.
- */
- if (flags & FAULT_FLAG_RETRY_NOWAIT)
- return VM_FAULT_RETRY;
-
- release_fault_lock(vmf);
- if (flags & FAULT_FLAG_KILLABLE)
- folio_wait_locked_killable(folio);
- else
- folio_wait_locked(folio);
- return VM_FAULT_RETRY;
- }
- if (flags & FAULT_FLAG_KILLABLE) {
- bool ret;
-
- ret = __folio_lock_killable(folio);
- if (ret) {
- release_fault_lock(vmf);
- return VM_FAULT_RETRY;
- }
- } else {
- __folio_lock(folio);
- }
-
- return 0;
-}
-
/**
* page_cache_next_miss() - Find the next gap in the page cache.
* @mapping: Mapping.
diff --git a/mm/memory.c b/mm/memory.c
index 00ee1599d637..0c740ca363cc 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4442,6 +4442,59 @@ void unmap_mapping_range(struct address_space *mapping,
}
EXPORT_SYMBOL(unmap_mapping_range);
+/*
+ * folio_lock_or_retry - Lock the folio, unless this would block and the
+ * caller indicated that it can handle a retry.
+ *
+ * Return values:
+ * 0 - folio is locked.
+ * non-zero - folio is not locked.
+ * mmap_lock or per-VMA lock has been released (mmap_read_unlock() or
+ * vma_end_read()), unless flags had both FAULT_FLAG_ALLOW_RETRY and
+ * FAULT_FLAG_RETRY_NOWAIT set, in which case the lock is still held.
+ *
+ * If neither ALLOW_RETRY nor KILLABLE are set, will always return 0
+ * with the folio locked and the mmap_lock/per-VMA lock is left unperturbed.
+ */
+static inline vm_fault_t folio_lock_or_retry(struct folio *folio,
+ struct vm_fault *vmf)
+{
+ unsigned int flags = vmf->flags;
+
+ might_sleep();
+ if (folio_trylock(folio))
+ return 0;
+
+ if (fault_flag_allow_retry_first(flags)) {
+ /*
+ * CAUTION! In this case, mmap_lock/per-VMA lock is not
+ * released even though returning VM_FAULT_RETRY.
+ */
+ if (flags & FAULT_FLAG_RETRY_NOWAIT)
+ return VM_FAULT_RETRY;
+
+ release_fault_lock(vmf);
+ if (flags & FAULT_FLAG_KILLABLE)
+ folio_wait_locked_killable(folio);
+ else
+ folio_wait_locked(folio);
+ return VM_FAULT_RETRY;
+ }
+ if (flags & FAULT_FLAG_KILLABLE) {
+ bool ret;
+
+ ret = __folio_lock_killable(folio);
+ if (ret) {
+ release_fault_lock(vmf);
+ return VM_FAULT_RETRY;
+ }
+ } else {
+ __folio_lock(folio);
+ }
+
+ return 0;
+}
+
/*
* Restore a potential device exclusive pte to a working pte entry
*/
--
2.39.3 (Apple Git-146)
^ permalink raw reply related
* [PATCH v2 2/5] mm/swapin: Retry swapin by VMA lock if the lock was released for I/O
From: Barry Song (Xiaomi) @ 2026-04-30 4:04 UTC (permalink / raw)
To: akpm, linux-mm, willy
Cc: david, ljs, liam, vbabka, rppt, surenb, mhocko, jack, pfalcato,
wanglian, chentao, lianux.mm, kunwu.chan, liyangouwen1, chrisl,
kasong, shikemeng, nphamcs, bhe, youngjun.park, linux-arm-kernel,
linux-kernel, loongarch, linuxppc-dev, linux-riscv, linux-s390,
Barry Song (Xiaomi)
In-Reply-To: <20260430040427.4672-1-baohua@kernel.org>
If the current do_swap_page() took the per-VMA lock and we dropped it only
to wait for I/O completion (e.g., use folio_wait_locked()), then when
do_swap_page() is retried after the I/O completes, it should still qualify
for the per-VMA-lock path.
Tested-by: Wang Lian <wanglian@kylinos.cn>
Tested-by: Kunwu Chan <chentao@kylinos.cn>
Reviewed-by: Wang Lian <lianux.mm@gmail.com>
Reviewed-by: Kunwu Chan <kunwu.chan@gmail.com>
Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
---
mm/memory.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 199214f8de08..00ee1599d637 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4791,6 +4791,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
unsigned long page_idx;
unsigned long address;
pte_t *ptep;
+ bool retry_by_vma_lock = false;
if (!pte_unmap_same(vmf))
goto out;
@@ -4896,8 +4897,13 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
swapcache = folio;
ret |= folio_lock_or_retry(folio, vmf);
- if (ret & VM_FAULT_RETRY)
+ if (ret & VM_FAULT_RETRY) {
+ if (fault_flag_allow_retry_first(vmf->flags) &&
+ !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT) &&
+ (vmf->flags & FAULT_FLAG_VMA_LOCK))
+ retry_by_vma_lock = true;
goto out_release;
+ }
page = folio_file_page(folio, swp_offset(entry));
/*
@@ -5182,7 +5188,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
}
if (si)
put_swap_device(si);
- return ret;
+ return ret | (retry_by_vma_lock ? VM_FAULT_RETRY_VMA : 0);
}
static bool pte_range_none(pte_t *pte, int nr_pages)
--
2.39.3 (Apple Git-146)
^ 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