* [PATCH v6 1/3] PCI: Add pci_ats_required() for CXL.cache capable devices
From: Nicolin Chen @ 2026-05-21 20:34 UTC (permalink / raw)
To: jgg, will
Cc: robin.murphy, joro, bhelgaas, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl, nirmoyd
In-Reply-To: <cover.1779392420.git.nicolinc@nvidia.com>
Controlled by IOMMU drivers, ATS can be enabled "on demand", when a given
PASID on a device is attached to an I/O page table. This is working, even
when a device has no translation on its RID (i.e., RID is IOMMU bypassed).
However, certain PCIe devices require non-PASID ATS on their RID even when
the RID is IOMMU bypassed. Call this "ATS always on" in IOMMU term.
For example, CXL spec r4.0 notes in sec 3.2.5.13 Memory Type on CXL.cache:
"To source requests on CXL.cache, devices need to get the Host Physical
Address (HPA) from the Host by means of an ATS request on CXL.io."
In other words, the CXL.cache capability requires ATS; otherwise, it can't
access host physical memory.
Introduce a new pci_ats_required() helper for the IOMMU driver to scan a
PCI device and shift ATS policies between "on demand" and "always on".
Add the support for CXL.cache devices first. Pre-CXL devices will be added
in quirks.c file.
Note that pci_ats_required() validates against pci_ats_supported(), so we
ensure that untrusted devices (e.g. external ports) will not be always on.
This maintains the existing ATS security policy regarding potential side-
channel attacks via ATS.
Cc: linux-cxl@vger.kernel.org
Suggested-by: Vikram Sethi <vsethi@nvidia.com>
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
include/linux/pci-ats.h | 3 +++
include/uapi/linux/pci_regs.h | 1 +
drivers/pci/ats.c | 46 +++++++++++++++++++++++++++++++++++
3 files changed, 50 insertions(+)
diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
index 75c6c86cf09dc..f3723b6861294 100644
--- a/include/linux/pci-ats.h
+++ b/include/linux/pci-ats.h
@@ -12,6 +12,7 @@ int pci_prepare_ats(struct pci_dev *dev, int ps);
void pci_disable_ats(struct pci_dev *dev);
int pci_ats_queue_depth(struct pci_dev *dev);
int pci_ats_page_aligned(struct pci_dev *dev);
+bool pci_ats_required(struct pci_dev *dev);
#else /* CONFIG_PCI_ATS */
static inline bool pci_ats_supported(struct pci_dev *d)
{ return false; }
@@ -24,6 +25,8 @@ static inline int pci_ats_queue_depth(struct pci_dev *d)
{ return -ENODEV; }
static inline int pci_ats_page_aligned(struct pci_dev *dev)
{ return 0; }
+static inline bool pci_ats_required(struct pci_dev *dev)
+{ return false; }
#endif /* CONFIG_PCI_ATS */
#ifdef CONFIG_PCI_PRI
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index 14f634ab9350d..6ac45be1008b8 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -1349,6 +1349,7 @@
/* CXL r4.0, 8.1.3: PCIe DVSEC for CXL Device */
#define PCI_DVSEC_CXL_DEVICE 0
#define PCI_DVSEC_CXL_CAP 0xA
+#define PCI_DVSEC_CXL_CACHE_CAPABLE _BITUL(0)
#define PCI_DVSEC_CXL_MEM_CAPABLE _BITUL(2)
#define PCI_DVSEC_CXL_HDM_COUNT __GENMASK(5, 4)
#define PCI_DVSEC_CXL_CTRL 0xC
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index ec6c8dbdc5e9c..84cd06d74fc9c 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -205,6 +205,52 @@ int pci_ats_page_aligned(struct pci_dev *pdev)
return 0;
}
+/*
+ * CXL r4.0, sec 3.2.5.13 Memory Type on CXL.cache notes: to source requests on
+ * CXL.cache, devices need to get the Host Physical Address (HPA) from the Host
+ * by means of an ATS request on CXL.io.
+ *
+ * In other words, CXL.cache devices cannot access host physical memory without
+ * ATS.
+ *
+ * Check Cache_Capable instead of Cache_Enable because CXL.cache may be enabled
+ * after the caller uses this to make its ATS decision.
+ */
+static bool pci_cxl_ats_required(struct pci_dev *pdev)
+{
+ int offset;
+ u16 cap;
+
+ offset = pci_find_dvsec_capability(pdev, PCI_VENDOR_ID_CXL,
+ PCI_DVSEC_CXL_DEVICE);
+ if (!offset)
+ return false;
+
+ if (pci_read_config_word(pdev, offset + PCI_DVSEC_CXL_CAP, &cap))
+ return false;
+
+ return cap & PCI_DVSEC_CXL_CACHE_CAPABLE;
+}
+
+/**
+ * pci_ats_required - Whether the PCI device requires ATS
+ * @pdev: the PCI device
+ *
+ * Returns true, if the PCI device requires ATS for basic functional operation.
+ */
+bool pci_ats_required(struct pci_dev *pdev)
+{
+ if (!pci_ats_supported(pdev))
+ return false;
+
+ /* A VF inherits its PF's requirement for ATS function */
+ if (pdev->is_virtfn)
+ pdev = pci_physfn(pdev);
+
+ return pci_cxl_ats_required(pdev);
+}
+EXPORT_SYMBOL_GPL(pci_ats_required);
+
#ifdef CONFIG_PCI_PRI
void pci_pri_init(struct pci_dev *pdev)
{
--
2.43.0
^ permalink raw reply related
* [PATCH v6 2/3] PCI: Allow ATS to be always on for pre-CXL devices
From: Nicolin Chen @ 2026-05-21 20:34 UTC (permalink / raw)
To: jgg, will
Cc: robin.murphy, joro, bhelgaas, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl, nirmoyd
In-Reply-To: <cover.1779392420.git.nicolinc@nvidia.com>
Some NVIDIA GPU/NIC devices, though they don't implement CXL config space,
have many CXL-like properties. Call this kind "pre-CXL".
Similar to CXL.cache capability, these pre-CXL devices also require the ATS
function even when their RIDs are IOMMU bypassed, i.e. keep ATS "always on"
v.s. "on demand" when a non-zero PASID line gets enabled in SVA use cases.
Introduce pci_dev_specific_ats_required() quirk function to scan a list of
IDs for these devices. Then, include it in pci_ats_required().
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com>
Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
---
drivers/pci/pci.h | 9 +++++++++
drivers/pci/ats.c | 3 ++-
drivers/pci/quirks.c | 42 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4a14f88e543a2..e8ad27abb1cfe 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -1155,6 +1155,15 @@ static inline int pci_dev_specific_reset(struct pci_dev *dev, bool probe)
}
#endif
+#if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_PCI_ATS)
+bool pci_dev_specific_ats_required(struct pci_dev *dev);
+#else
+static inline bool pci_dev_specific_ats_required(struct pci_dev *dev)
+{
+ return false;
+}
+#endif
+
#if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_ARM64)
int acpi_get_rc_resources(struct device *dev, const char *hid, u16 segment,
struct resource *res);
diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
index 84cd06d74fc9c..96efa00d97433 100644
--- a/drivers/pci/ats.c
+++ b/drivers/pci/ats.c
@@ -247,7 +247,8 @@ bool pci_ats_required(struct pci_dev *pdev)
if (pdev->is_virtfn)
pdev = pci_physfn(pdev);
- return pci_cxl_ats_required(pdev);
+ return pci_cxl_ats_required(pdev) ||
+ pci_dev_specific_ats_required(pdev);
}
EXPORT_SYMBOL_GPL(pci_ats_required);
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index caaed1a01dc02..c0242f3e9f063 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -5715,6 +5715,48 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1457, quirk_intel_e2000_no_ats);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1459, quirk_intel_e2000_no_ats);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x145a, quirk_intel_e2000_no_ats);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x145c, quirk_intel_e2000_no_ats);
+
+static bool quirk_nvidia_gpu_ats_required(struct pci_dev *pdev)
+{
+ switch (pdev->device) {
+ case 0x2e00 ... 0x2e3f: /* GB20B */
+ return true;
+ }
+ return false;
+}
+
+static const struct pci_dev_ats_required {
+ u16 vendor;
+ u16 device;
+ bool (*ats_required)(struct pci_dev *dev);
+} pci_dev_ats_required[] = {
+ /* NVIDIA GPUs */
+ { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID, quirk_nvidia_gpu_ats_required },
+ /* NVIDIA CX10 Family NVlink-C2C */
+ { PCI_VENDOR_ID_MELLANOX, 0x2101, NULL },
+ { 0 }
+};
+
+/*
+ * Some NVIDIA devices do not implement CXL config space, but present as PCIe
+ * devices that can issue CXL-like cache operations like CXL.cache. Thus, they
+ * require ATS to obtain host physical addresses, like pci_cxl_ats_required().
+ */
+bool pci_dev_specific_ats_required(struct pci_dev *pdev)
+{
+ const struct pci_dev_ats_required *i;
+
+ for (i = pci_dev_ats_required; i->vendor; i++) {
+ if (i->vendor != pdev->vendor)
+ continue;
+ if (i->ats_required && i->ats_required(pdev))
+ return true;
+ if (!i->ats_required && i->device == pdev->device)
+ return true;
+ }
+
+ return false;
+}
#endif /* CONFIG_PCI_ATS */
/* Freescale PCIe doesn't support MSI in RC mode */
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/3] Allow ATS to be always on for certain ATS-capable devices
From: Nicolin Chen @ 2026-05-21 20:34 UTC (permalink / raw)
To: jgg, will
Cc: robin.murphy, joro, bhelgaas, praan, baolu.lu, kevin.tian,
miko.lenczewski, linux-arm-kernel, iommu, linux-kernel, linux-pci,
dan.j.williams, jonathan.cameron, vsethi, linux-cxl, nirmoyd
PCI ATS function is controlled by the IOMMU driver calling pci_enable_ats()
and pci_disable_ats() helpers. Depending on the driver implementation:
- ATS should be enabled when a translation channel is enabled on a PASID
(a typical SVA case).
- ATS should be disabled when the device's RID is IOMMU bypassed and its
PASIDs are not IOMMU-translated for any SVA use case.
However, certain PCIe devices require non-PASID ATS on the RID, even if the
RID is IOMMU bypassed. E.g. CXL.cache capability requires ATS to access the
physical memory; some pre-CXL NVIDIA GPUs also require the ATS to be always
on even when their RIDs are IOMMU bypassed.
Provide a helper function to detect CXL.cache capability and scan through a
pre-CXL device ID list.
As the initial use case, call the helper in ARM SMMUv3 driver and adapt the
driver accordingly with a per-device ats_always_on flag.
This is on Github:
https://github.com/nicolinc/iommufd/commits/pci_ats_always_on-v6
Changelog
v6
* Add Acked-by from Bjorn
* Slightly update commit message (Yi's comments)
* [pci] Drop the redundant pci_ats_disabled() check
* [smmu] Fix mismatched detach path against attach path
* [smmu] Propagate arm_smmu_master_prepare_ats() error code
v5
https://lore.kernel.org/all/cover.1779304390.git.nicolinc@nvidia.com/
* Add Reviewed-by from Dave
* Update comments in pci helpers
* s/pci_ats_always_on/pci_ats_required
* s/pci_cxl_ats_always_on/pci_cxl_ats_required
* s/pci_dev_specific_ats_always_on/pci_dev_specific_ats_required
v4
https://lore.kernel.org/all/cover.1777269009.git.nicolinc@nvidia.com/
* Rebase on v7.1-rc1
* Added Reviewed/Tested/Acked-by lines
* Update commit messages and inline comments
* [pci-quirks] Add range-based scan for NVIDIA GPUs
* [smmu] Add missing arm_smmu_remove_master() in error path
* [pci-ats] Don't init "cap=0"; check pci_read_config_word error
v3
https://lore.kernel.org/all/cover.1772833963.git.nicolinc@nvidia.com/
* Add Reviewed-by from Jonathan
* Update function kdocs of PCI APIs
* Simplify boolean return/variable computations
v2
https://lore.kernel.org/all/cover.1771886695.git.nicolinc@nvidia.com/
* s/non-CXL/pre-CXL
* Rebase on v7.0-rc1
* Update inline comments and commit message
* Add WARN_ON back at !ptr in arm_smmu_clear_cd()
* Add NVIDIA CX10 Family NVlink-C2C to the pre-CXL list
* Do not add boolean parameter to arm_smmu_attach_dev_ste()
v1
https://lore.kernel.org/all/cover.1768624180.git.nicolinc@nvidia.com/
Nicolin Chen (3):
PCI: Add pci_ats_required() for CXL.cache capable devices
PCI: Allow ATS to be always on for pre-CXL devices
iommu/arm-smmu-v3: Allow ATS to be always on
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
drivers/pci/pci.h | 9 +++
include/linux/pci-ats.h | 3 +
include/uapi/linux/pci_regs.h | 1 +
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 81 ++++++++++++++++++---
drivers/pci/ats.c | 47 ++++++++++++
drivers/pci/quirks.c | 42 +++++++++++
7 files changed, 175 insertions(+), 9 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v4 1/1] dt-bindings: remoteproc: mtk,scp: Allow multiple memory regions for MT8188
From: Conor Dooley @ 2026-05-21 20:26 UTC (permalink / raw)
To: Arnab Layek
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, robh,
krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
andersson, mathieu.poirier, linux-remoteproc,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260520112629.3420612-2-arnab.layek@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]
On Wed, May 20, 2026 at 07:26:29PM +0800, Arnab Layek wrote:
> The MT8188 SCP can use either one or two reserved memory regions:
> - Required: Main SCP SRAM memory region (mandatory for SCP operation)
> - Optional: SCP L1TCM memory region (Level 1 Tightly Coupled Memory,
> used for performance optimization when available, but not required
> for basic SCP functionality)
>
> Other MediaTek SoCs (MT8183, MT8186, MT8192, MT8195) use only a single
> memory region and must remain restricted to one region for backward
> compatibility.
>
> Update the base schema to allow 1-2 memory regions (minItems: 1,
> maxItems: 2), following the pattern used by other MediaTek dt-bindings
> like mediatek,vcodec-encoder.yaml where the base property defines a
> permissive range accommodating all device variants.
>
> Add two conditionals:
> 1. Explicitly restrict non-MT8188 devices to maxItems: 1
> 2. Document MT8188's two regions with descriptions (minItems: 1 makes
> the L1TCM region optional, allowing boards to specify 1-2 regions
> based on hardware configuration)
>
> This approach maintains backward compatibility while enabling MT8188 to
> specify 1-2 memory regions depending on board design and performance
> requirements.
>
> Signed-off-by: Arnab Layek <arnab.layek@mediatek.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
> ---
> .../bindings/remoteproc/mtk,scp.yaml | 45 ++++++++++++++++++-
> 1 file changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> index bdbb12118da4..fca9b0675eae 100644
> --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml
> @@ -55,7 +55,8 @@ properties:
> initializing SCP.
>
> memory-region:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
>
> cros-ec-rpmsg:
> $ref: /schemas/embedded-controller/google,cros-ec.yaml
> @@ -123,7 +124,8 @@ patternProperties:
> initializing sub cores of multi-core SCP.
>
> memory-region:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
>
> cros-ec-rpmsg:
> $ref: /schemas/embedded-controller/google,cros-ec.yaml
> @@ -205,6 +207,45 @@ allOf:
> items:
> - const: cfg
> - const: l1tcm
> + - if:
> + properties:
> + compatible:
> + enum:
> + - mediatek,mt8183-scp
> + - mediatek,mt8186-scp
> + - mediatek,mt8192-scp
> + - mediatek,mt8195-scp
> + - mediatek,mt8195-scp-dual
> + then:
> + properties:
> + memory-region:
> + maxItems: 1
> + patternProperties:
> + "^scp@[a-f0-9]+$":
> + properties:
> + memory-region:
> + maxItems: 1
> + - if:
> + properties:
> + compatible:
> + enum:
> + - mediatek,mt8188-scp
> + - mediatek,mt8188-scp-dual
> + then:
> + properties:
> + memory-region:
> + minItems: 1
> + items:
> + - description: Main SCP SRAM memory region
> + - description: Optional SCP L1TCM memory region
> + patternProperties:
> + "^scp@[a-f0-9]+$":
> + properties:
> + memory-region:
> + minItems: 1
> + items:
> + - description: Main SCP SRAM memory region
> + - description: Optional SCP L1TCM memory region
>
> additionalProperties: false
>
> --
> 2.45.2
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 19/23] drm: bridge: dw_hdmi: Use delayed_work to debounce hotplug event
From: Jonas Karlman @ 2026-05-21 20:13 UTC (permalink / raw)
To: Neil Armstrong
Cc: Andrzej Hajda, Robert Foss, Heiko Stuebner, Laurent Pinchart,
Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Liu Ying,
Sandy Huang, Andy Yan, Chen-Yu Tsai, Christian Hewitt,
Diederik de Haas, Nicolas Frattaroli, Dmitry Baryshkov, dri-devel,
linux-arm-kernel, linux-rockchip, linux-amlogic, linux-sunxi, imx,
linux-kernel
In-Reply-To: <e584ab2b-677d-4893-95c9-7b68165633c6@linaro.org>
Hi Neil,
On 5/20/2026 11:58 AM, Neil Armstrong wrote:
> Hi,
>
> On 5/18/26 20:01, Jonas Karlman wrote:
>> HDMI Specification Version 1.4b chapter 8.5 mentions:
>>
>> An HDMI Sink shall not assert high voltage level on its Hot Plug
>> Detect pin when the E-EDID is not available for reading.
>>
>> A Source may use a high voltage level Hot Plug Detect signal to
>> initiate the reading of E-EDID data.
>>
>> An HDMI Sink shall indicate any change to the contents of the E-EDID
>> by driving a low voltage level pulse on the Hot Plug Detect pin. This
>> pulse shall be at least 100 msec.
>>
>> Use a delayed work to debounce reacting on HPD events to improve
>> handling of a HPD low voltage level pulse when a sink changes the EDID.
>>
>> The delayed work is only enabled between enable_hpd()/hpd_enable() and
>> disable_hpd()/hpd_disable() calls from core, i.e. enabled after
>> attach/bind/resume and disabled before detach/unbind/suspend.
>>
>> The 1100 msec hotplug debounce timeout was arbitrarily picked to match
>> other drivers using same const, and testing using a Raspberry Pi Monitor
>> seem to use a 200-300 msec pulse when going from standby to power on
>> state.
>
> The logic looks ok, but I'm puzzled by the 1.1 sec debounce, which after
> plugging in a monitor will only send an irq event after 1.1s which is very long.
>
> Since the spec says 100ms and the real worls values are more like 200-300ms,
> I would first reduce this to 500ms.
You are correct, this value was picked based on existing values used by
other drivers:
exynos/exynos_hdmi.c:#define HOTPLUG_DEBOUNCE_MS 1100
bridge/ti-tfp410.c:#define HOTPLUG_DEBOUNCE_MS 1100
amd/display/amdgpu_dm/amdgpu_dm.h:#define AMDGPU_DM_MAX_HDMI_HPD_DEBOUNCE_MS 5000
rockchip/dw_hdmi_qp-rockchip.c:#define HOTPLUG_DEBOUNCE_MS 150
150 ms was too short for my test monitor (Raspberry Pi Monitor), it
does a HPD low voltage level pulse when powering on of around 200+ ms.
[82.641903] dw_hdmi_hardirq: EVENT=plugout
[82.841939] dw_hdmi_hardirq: EVENT=plugin
And on my LG OLED 4K TV there was typically a pulse of around 700-900 ms.
So the 1.1 seconds used by other drivers seemed like a good candidate :-)
> But as I understand the code right now, on the first HPD front the irq work
> is programmed to run after the debounce time, but if it's a pulse the irq would
> also trigger on the second HPD front and then delay again the work after the
> debounce time.
Your analysis is correct, any HPD event would keep debouncing adding 1.1
timout from each HPD irq, both plugout and plugin.
The intention was to allow for up to 1.1 seconds to pass between a
plugout and a plugin, before we treated a plugout as a full disconnect
event, and not to delay a possible connected event by 1.1 seconds.
> My understanding of a debounce was that we "ignore" the pulse by only generating
> a single irq event when the pulse is finished.
Correct, as long as the pulse was less than 1.1 seconds.
> The current code does that, we will only have a single irq event and the HPD
> will return as connected state, good. But this delays the irq event 1.1s _after_
> the end of the pulse, which I would expect the event to be send at tht debounce
> time after the start of the pulse.
Good catch and I agree, we should delay/timeout the disconnected state
longer than plugin and react on plugin almost immediately.
> Like, program the work at the beginning of the pulse, if somehow the pulse ends before
> the debounce time, send the irq event immediately, otherwise let the debounce
> work run after the debounce time which will trigger a disconnect event.
>
> But the delay is too high, 1.1s could be a manual unplug/plug or bad connector
> with false contact on the hpd pin.
>
> I would rather reduce this to something more realistic like 500ms or less and
> try to better handle the pulse somehow. But I don't have any idea if the scheme
> I described is doable.
We can configure different delays for plugout and plugin, I am currently
testing something like following:
#define HOTPLUG_CONNECTED_DEBOUNCE_MS 150
#define HOTPLUG_DISCONNECTED_DEBOUNCE_MS 500
delay = status == connector_status_connected ?
HOTPLUG_CONNECTED_DEBOUNCE_MS :
HOTPLUG_DISCONNECTED_DEBOUNCE_MS;
mod_delayed_work(system_percpu_wq, &hdmi->hpd_work,
msecs_to_jiffies(delay));
That would mean:
- at plugout we (re-)start the timer to trigger in 500ms
- at plugin we (re-)start the timer to trigger in 150ms
- whenever the timer triggers the hpd_work is started
- the hpw_work trigger normal detect() handling to determin if
connector status (or EDID) has changed
Example during power on of a Raspberry Pi Monitor:
[82.641903] dw_hdmi_hardirq: EVENT=plugout
[82.648276] dw_hdmi_schedule_hpd_work(status=2)
[82.841939] dw_hdmi_hardirq: EVENT=plugin
[82.848211] dw_hdmi_schedule_hpd_work(status=1)
[83.008573] dw_hdmi_hpd_work(): START
[83.020358] dw_hdmi_bridge_detect()
[83.034958] dw_hdmi_bridge_edid_read()
[83.187102] [drm:update_display_info.part.0] [CONNECTOR:55:HDMI-A-1] CEA VCDB 0x4a
[83.194471] [drm:update_display_info.part.0] [CONNECTOR:55:HDMI-A-1] HDMI: DVI dual 0, max TMDS clock 0 kHz
[83.201755] [drm:update_display_info.part.0] [CONNECTOR:55:HDMI-A-1] ELD monitor RPI MON156
[83.208968] [drm:update_display_info.part.0] [CONNECTOR:55:HDMI-A-1] HDMI: latency present 0 0, video latency 0 0, audio latency 0 0
[83.216588] [drm:update_display_info.part.0] [CONNECTOR:55:HDMI-A-1] ELD size 36, SAD count 1
[83.224445] [drm:check_connector_changed] [CONNECTOR:55:HDMI-A-1] Same epoch counter 2
[83.231553] dw_hdmi_hpd_work(): END
Around 205ms between HPD=0 and HPD=1 and around 160ms from plugin until
delayed hpd_work starts.
And at full plugout the debounce time is around 497 ms:
[95.125105] dw_hdmi_hardirq: EVENT=plugout
[95.147586] dw_hdmi_schedule_hpd_work(status=2)
[95.645277] dw_hdmi_hpd_work(): START
[95.667741] dw_hdmi_bridge_detect()
[95.691523] [drm:drm_edid_connector_update] [CONNECTOR:55:HDMI-A-1] EDID changed, epoch counter 3
[95.709861] [drm:check_connector_changed] [CONNECTOR:55:HDMI-A-1] status updated from connected to disconnected
[95.722674] [drm:check_connector_changed] [CONNECTOR:55:HDMI-A-1] Changed epoch counter 2 => 4
[95.735173] [drm:drm_sysfs_connector_hotplug_event] [CONNECTOR:55:HDMI-A-1] generating connector hotplug event
[95.746326] [drm:drm_fb_helper_hotplug_event]
[95.754871] [drm:drm_client_modeset_probe]
[95.762429] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:55:HDMI-A-1]
[95.769758] dw_hdmi_bridge_detect()
[95.776597] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:55:HDMI-A-1] disconnected
[95.784389] [drm:drm_client_modeset_probe] No connectors reported connected with modes
[95.791865] [drm:drm_client_modeset_probe] [CONNECTOR:55:HDMI-A-1] enabled? no
[95.799426] [drm:drm_client_firmware_config.isra.0] Not using firmware configuration
[95.807140] [drm:drm_client_modeset_probe] picking CRTCs for 1920x1080 config
[95.818422] dw_hdmi_bridge_atomic_disable()
[95.826412] [drm:vop2_plane_atomic_disable] Smart0-win0 disable
[95.868341] [drm:drm_client_hotplug] fbdev: ret=0
[95.878206] dw_hdmi_hpd_work(): END
With a much quicker reaction on plugin event maybe the 1.1 seconds could
stay to avoid having to do a full teardown, disable() + enable() cycle,
at slightly longer HPD pulses.
Or maybe it is time to re-spin an old cec-adapter debounce series [1]
that can allow for some additional time until the CEC phys addr is fully
invalidated at a longer HPD low voltage level pulse.
[1] https://lore.kernel.org/linux-media/HE1PR06MB40115700084D1D875673D60EAC9D0@HE1PR06MB4011.eurprd06.prod.outlook.com/
Regards,
Jonas
>
> Neil
>
>>
>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>> ---
>> v7: Change to free irq before mute and clear using IH regs, also include
>> clear of STAT0_RX_SENSE
>> v6: Change back to disable_delayed_work_sync() in hpd disable ops,
>> Ensure HPD interrupt is masked and IRQ handler is disabled early
>> in dw_hdmi_remove() to prevent any irq re-arming of delayed work,
>> Drop use of suspend helper
>> v5: Change to none-sync disable_delayed_work() in hpd disable ops,
>> Change to cancel_delayed_work_sync() in remove,
>> Add cancel_delayed_work_sync() to new suspend helper
>> v4: Disable/mask delayed_work until enable_hpd()/hpd_enable(),
>> Read connector status directly from HW regs in hpd_work
>> v3: New patch
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 80 +++++++++++++++++++++--
>> 1 file changed, 75 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 8afc9d240121..270db58a0e7c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -50,6 +50,8 @@
>>
>> #define HDMI14_MAX_TMDSCLK 340000000
>>
>> +#define HOTPLUG_DEBOUNCE_MS 1100
>> +
>> static const u16 csc_coeff_default[3][4] = {
>> { 0x2000, 0x0000, 0x0000, 0x0000 },
>> { 0x0000, 0x2000, 0x0000, 0x0000 },
>> @@ -185,6 +187,7 @@ struct dw_hdmi {
>> hdmi_codec_plugged_cb plugged_cb;
>> struct device *codec_dev;
>> enum drm_connector_status last_connector_result;
>> + struct delayed_work hpd_work;
>> };
>>
>> const struct dw_hdmi_plat_data *dw_hdmi_to_plat_data(struct dw_hdmi *hdmi)
>> @@ -2517,6 +2520,20 @@ static void dw_hdmi_connector_force(struct drm_connector *connector)
>> dw_hdmi_connector_status_update(hdmi, connector, connector->status);
>> }
>>
>> +static void dw_hdmi_connector_enable_hpd(struct drm_connector *connector)
>> +{
>> + struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi, connector);
>> +
>> + enable_delayed_work(&hdmi->hpd_work);
>> +}
>> +
>> +static void dw_hdmi_connector_disable_hpd(struct drm_connector *connector)
>> +{
>> + struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi, connector);
>> +
>> + disable_delayed_work_sync(&hdmi->hpd_work);
>> +}
>> +
>> static void dw_hdmi_connector_destroy(struct drm_connector *connector)
>> {
>> struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi, connector);
>> @@ -2538,6 +2555,8 @@ static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
>> static const struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
>> .get_modes = dw_hdmi_connector_get_modes,
>> .atomic_check = dw_hdmi_connector_atomic_check,
>> + .enable_hpd = dw_hdmi_connector_enable_hpd,
>> + .disable_hpd = dw_hdmi_connector_disable_hpd,
>> };
>>
>> static int dw_hdmi_connector_create(struct dw_hdmi *hdmi)
>> @@ -2968,6 +2987,20 @@ static const struct drm_edid *dw_hdmi_bridge_edid_read(struct drm_bridge *bridge
>> return dw_hdmi_edid_read(hdmi, connector);
>> }
>>
>> +static void dw_hdmi_bridge_hpd_enable(struct drm_bridge *bridge)
>> +{
>> + struct dw_hdmi *hdmi = bridge->driver_private;
>> +
>> + enable_delayed_work(&hdmi->hpd_work);
>> +}
>> +
>> +static void dw_hdmi_bridge_hpd_disable(struct drm_bridge *bridge)
>> +{
>> + struct dw_hdmi *hdmi = bridge->driver_private;
>> +
>> + disable_delayed_work_sync(&hdmi->hpd_work);
>> +}
>> +
>> static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
>> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
>> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
>> @@ -2981,6 +3014,8 @@ static const struct drm_bridge_funcs dw_hdmi_bridge_funcs = {
>> .mode_valid = dw_hdmi_bridge_mode_valid,
>> .detect = dw_hdmi_bridge_detect,
>> .edid_read = dw_hdmi_bridge_edid_read,
>> + .hpd_enable = dw_hdmi_bridge_hpd_enable,
>> + .hpd_disable = dw_hdmi_bridge_hpd_disable,
>> };
>>
>> /* -----------------------------------------------------------------------------
>> @@ -3101,8 +3136,8 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>> status == connector_status_connected ?
>> "plugin" : "plugout");
>>
>> - if (hdmi->bridge.dev)
>> - drm_helper_hpd_irq_event(hdmi->bridge.dev);
>> + mod_delayed_work(system_percpu_wq, &hdmi->hpd_work,
>> + msecs_to_jiffies(HOTPLUG_DEBOUNCE_MS));
>> }
>>
>> hdmi_writeb(hdmi, intr_stat, HDMI_IH_PHY_STAT0);
>> @@ -3112,6 +3147,29 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
>> return IRQ_HANDLED;
>> }
>>
>> +static void dw_hdmi_hpd_work(struct work_struct *work)
>> +{
>> + struct dw_hdmi *hdmi = container_of(work, struct dw_hdmi, hpd_work.work);
>> + struct drm_device *dev = hdmi->bridge.dev;
>> +
>> + if (WARN_ON(!dev))
>> + return;
>> +
>> + /*
>> + * Notify the DRM core of the HPD event using drm_helper_hpd_irq_event()
>> + * instead of drm_bridge_hpd_notify(). This will cause the DRM function
>> + * check_connector_changed() to be called, which in turn calls the
>> + * connector detect()/force() funcs to detect any connection status or
>> + * epoch changes. The bridge connector detect() func also ensures that
>> + * any hpd_notify() funcs are called for all bridges in the chain.
>> + *
>> + * drm_bridge_hpd_notify() shares a mutex with drm_bridge_hpd_disable(),
>> + * and can result in a deadlock due to the disable_delayed_work_sync()
>> + * call to wait on work to complete in dw_hdmi_bridge_hpd_disable().
>> + */
>> + drm_helper_hpd_irq_event(dev);
>> +}
>> +
>> static const struct dw_hdmi_phy_data dw_hdmi_phys[] = {
>> {
>> .type = DW_HDMI_PHY_DWC_HDMI_TX_PHY,
>> @@ -3396,6 +3454,9 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
>> goto err_res;
>> }
>>
>> + INIT_DELAYED_WORK(&hdmi->hpd_work, dw_hdmi_hpd_work);
>> + disable_delayed_work(&hdmi->hpd_work);
>> +
>> ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
>> dw_hdmi_irq, IRQF_SHARED,
>> dev_name(dev), hdmi);
>> @@ -3532,6 +3593,18 @@ EXPORT_SYMBOL_GPL(dw_hdmi_probe);
>>
>> void dw_hdmi_remove(struct dw_hdmi *hdmi)
>> {
>> + struct platform_device *pdev = to_platform_device(hdmi->dev);
>> + int irq = platform_get_irq(pdev, 0);
>> +
>> + /* Free, mute and clear phy interrupts */
>> + devm_free_irq(hdmi->dev, irq, hdmi);
>> + hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
>> + hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
>> + HDMI_IH_PHY_STAT0);
>> +
>> + /* Cancel any pending hot plug work */
>> + cancel_delayed_work_sync(&hdmi->hpd_work);
>> +
>> drm_bridge_remove(&hdmi->bridge);
>>
>> if (hdmi->audio && !IS_ERR(hdmi->audio))
>> @@ -3539,9 +3612,6 @@ void dw_hdmi_remove(struct dw_hdmi *hdmi)
>> if (!IS_ERR(hdmi->cec))
>> platform_device_unregister(hdmi->cec);
>>
>> - /* Disable all interrupts */
>> - hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);
>> -
>> if (hdmi->i2c)
>> i2c_del_adapter(&hdmi->i2c->adap);
>> else
>
^ permalink raw reply
* Re: [RFC PATCH 2/2] arm64: mm: add SMCCC-backed cache invalidate provider
From: Dan Williams (nvidia) @ 2026-05-21 20:10 UTC (permalink / raw)
To: Srirangan Madhavan, catalin.marinas, will, mark.rutland,
lpieralisi, sudeep.holla
Cc: conor, jic23, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams,
Srirangan Madhavan
In-Reply-To: <20260521073047.320614-3-smadhavan@nvidia.com>
Srirangan Madhavan wrote:
> Add an arm64 cache maintenance backend that discovers SMCCC cache
> clean+invalidate support, queries attributes, handles transient BUSY and
> RATE_LIMITED responses with bounded retries, and registers with the generic
> cache coherency framework.
>
> Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
> ---
> MAINTAINERS | 1 +
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 182 insertions(+)
> create mode 100644 arch/arm64/mm/cache_maint.c
[..]
> +static int arm64_smccc_cache_wbinv(struct cache_coherency_ops_inst *cci,
> + struct cc_inval_params *invp)
> +{
> + struct arm64_smccc_cache *cache =
> + container_of(cci, struct arm64_smccc_cache, cci);
> + struct arm_smccc_res res = {};
> + int delay_us = smccc_cache_delay_us(cache);
> + u64 gen = 0;
> + s32 status;
> + int ret;
> + int i;
> +
> + if (!invp->size)
> + return -EINVAL;
> +
> + if (cache->global_op)
> + gen = READ_ONCE(cache->global_flush_gen);
> +
> + guard(mutex)(&cache->lock);
> +
> + /*
> + * If firmware reports a global operation type, a successful operation
> + * covers every request that was already waiting behind it. Skip if the
> + * generation advanced while this request was waiting to enter the
> + * serialized firmware call path.
> + */
> + if (cache->global_op && gen != READ_ONCE(cache->global_flush_gen))
> + return 0;
Hmm, this looks like it could under flush which is worse than over
flushing. The ordering is:
CPU0 CPU1
<dirty>
flush_gen==0
lock
flush_gen==0
flush <dirty>
flush_gen++ flush_gen==0
lock
flush_gen==1
skip
I.e. if CPU1 is racing dirtying while CPU0 is still flushing, then there
is a window for CPU1 to read the updated flush_gen and skip when it
needs to follow on with a new flush cycle. So this either needs a more
sophisticated queue / batch system to track which requests might get
satisfied while waiting for a turn, or just drop the optimization until
it is clear it causes a problem in practice.
I think dropping the optimization is practical for now.
> +
> + for (i = 0; i < SMCCC_CACHE_MAX_RETRIES; i++) {
> + /* Long firmware operations can trigger watchdog checks. */
> + touch_nmi_watchdog();
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION,
> + invp->addr, invp->size, 0UL, &res);
> + status = (s32)res.a0;
> + ret = smccc_cache_status_to_errno(status);
> + if (!ret) {
> + if (cache->global_op) {
> + WRITE_ONCE(cache->global_flush_gen,
> + cache->global_flush_gen + 1);
> + }
> + return 0;
> + }
> +
> + if (ret != -EBUSY && ret != -EAGAIN)
> + return ret;
I notice that cxl_region_invalidate_memregion() only expects failures to
find a flush capability, not failures to execute a flush.
Just a note to circle back to this concern.
^ permalink raw reply
* Re: [PATCH v6 01/10] dt-bindings: display: rockchip: analogix-dp: Fix hclk as third clock for RK3588
From: Conor Dooley @ 2026-05-21 19:54 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521080835.1362416-2-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 3681 bytes --]
On Thu, May 21, 2026 at 04:08:26PM +0800, Damon Ding wrote:
> RK3588 eDP controller requires HCLK_VO1 to access the VO1 GRF
> registers and enable the video datapath.
>
> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
> phandle reference, which allowed the eDP to work without explicitly
> managing the hclk_vo1 clock. However, this is not safe or explicit.
>
> To make the clock dependency explicit, enforce per-SoC clock-names
> requirements:
> - RK3288: 2 clocks (dp, pclk)
> - RK3399: 3 clocks (dp, pclk, grf)
> - RK3588: 3 clocks (dp, pclk, hclk)
>
> Do not reuse the 'grf' clock name for RK3588 because it represents
> a different clock with distinct control logic:
> - The 'grf' clock is only for GRF register access and is toggled
> dynamically during register access.
> - The 'hclk' clock controls both GRF access and video datapath
> gating, and must remain enabled during probe.
>
> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> ---
>
> Changes in v4:
> - Modify the commit msg.
>
> Changes in v5:
> - Enforce the correct third clock name on a per-compatible basis.
> - Modify the commit msg simultaneously.
>
> Changes in v6:
> - Expand more detail commit msg about using hclk instead of grf clock.
> ---
> .../rockchip/rockchip,analogix-dp.yaml | 37 +++++++++++++++++--
> 1 file changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index d99b23b88cc5..8001c1facf98 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -23,10 +23,7 @@ properties:
>
> clock-names:
> minItems: 2
> - items:
> - - const: dp
> - - const: pclk
> - - const: grf
Instead of removing this, you can make it
items:
- const: dp
- const pclk
- enum:
- grf
- hclk
> + maxItems: 3
And delete this.
>
> power-domains:
> maxItems: 1
> @@ -60,6 +57,33 @@ required:
> allOf:
> - $ref: /schemas/display/bridge/analogix,dp.yaml#
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3288-dp
> + then:
> + properties:
> + clock-names:
> + items:
> + - const: dp
> + - const: pclk
Then this becomes
clock-names:
maxItems: 2
clocks:
maxItems: 2
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - rockchip,rk3399-edp
> + then:
> + properties:
> + clock-names:
> + items:
> + - const: dp
> + - const: pclk
> + - const: grf
maybe this needs a minItems: 3? Depends on if the grf clock is
mandatory. Also probably needs a
clocks:
minItems: 3
if that's the case.
> +
> - if:
> properties:
> compatible:
> @@ -68,6 +92,11 @@ allOf:
> - rockchip,rk3588-edp
> then:
> properties:
> + clock-names:
> + items:
> + - const: dp
> + - const: pclk
> + - const: hclk
And the same here as for the 3399.
Cheers,
Conor.
> resets:
> minItems: 2
> reset-names:
> --
> 2.34.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: display: bridge: analogix-dp: Add data-lanes support for endpoint
From: Conor Dooley @ 2026-05-21 19:50 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521114459.1394264-2-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]
On Thu, May 21, 2026 at 07:44:57PM +0800, Damon Ding wrote:
> Add data-lanes property support to the port@1 endpoint for physical
> lane mapping configuration.
>
> Lane mapping is mainly used for below scenarios:
> 1. Correct PCB lane swap and differential line routing crossover
> without hardware changes;
> 2. Adapt mismatched lane pin definitions between SoC and eDP panel;
> 3. Support multiple panel hardware variants on the same board
> by configuring data-lanes in device tree only.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Sashiko complaint here looks valid.
pw-bot: changes-requested
Thanks,
Conor.
>
> ---
>
> Changes in v2:
> - Add lane mapping application scenarios in commit message.
> - Remove redundant deprecated property 'data-lanes' for eDP node.
> - Update port@1 $ref to /schemas/graph.yaml#/$defs/port-base.
> ---
> .../bindings/display/bridge/analogix,dp.yaml | 17 ++++++++++++-----
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> index 62f0521b0924..e34fdb21adb4 100644
> --- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
> @@ -42,13 +42,20 @@ properties:
> properties:
> port@0:
> $ref: /schemas/graph.yaml#/properties/port
> - description:
> - Input node to receive pixel data.
> + description: Input node to receive pixel data.
>
> port@1:
> - $ref: /schemas/graph.yaml#/properties/port
> - description:
> - Port node with one endpoint connected to a dp-connector node.
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + description: Port node with one endpoint connected to sink device node.
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> + items:
> + enum: [ 0, 1, 2, 3 ]
>
> required:
> - port@0
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: rockchip: analogix-dp: Add data-lanes example
From: Conor Dooley @ 2026-05-21 19:47 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260521114459.1394264-3-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
On Thu, May 21, 2026 at 07:44:58PM +0800, Damon Ding wrote:
> Add data-lanes setting in endpoint example to show actual lane mapping
> usage.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Squash this with patch 1.
pw-bot: changes-requested
Thanks,
Conor.
> ---
> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index bb75d898a5c5..cf75c926318b 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -151,6 +151,7 @@ examples:
> reg = <1>;
>
> edp_out_panel: endpoint {
> + data-lanes = <0 1>;
> remote-endpoint = <&panel_in_edp>;
> };
> };
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 1/1] dt-bindings: display: imx: Add television encoder (TVE) for imx53
From: Frank.Li @ 2026-05-21 19:37 UTC (permalink / raw)
To: Philipp Zabel, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:DRM DRIVERS FOR FREESCALE IMX 5/6,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
Cc: imx, Krzysztof Kozlowski
From: Frank Li <Frank.Li@nxp.com>
Add television encoder (TVE) for legacy i.MX53 (over 15 years) to fix below
DTB_CHECK warnings:
arch/arm/boot/dts/nxp/imx/imx53-ard.dtb: /soc/bus@60000000/tve@63ff0000: failed to match any schema with compatible: ['fsl,imx53-tve']
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Change in v2
- add Krzysztof Kozlowski's review tag
- move fsl,tve-mode to required list
About cleanup 300 lines warnings for i.MX ARM platformi
---
.../bindings/display/imx/fsl,imx53-tve.yaml | 104 ++++++++++++++++++
1 file changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml
diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml
new file mode 100644
index 0000000000000..2fcf447459122
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/fsl,imx53-tve.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/imx/fsl,imx53-tve.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX53 Television Encoder (TVE)
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The Television Encoder (TVE) is a hardware block in the i.MX53 SoC that
+ converts digital video data into analog TV signals (NTSC/PAL).
+
+properties:
+ compatible:
+ const: fsl,imx53-tve
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: TVE gate clock
+ - description: Display interface selector clock
+
+ clock-names:
+ items:
+ - const: tve
+ - const: di_sel
+
+ ddc-i2c-bus:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ Phandle to the I2C bus used for DDC (Display Data Channel) communication
+ to read EDID information from the connected display.
+
+ dac-supply:
+ description:
+ Regulator supply for the TVE DAC (Digital-to-Analog Converter).
+
+ fsl,tve-mode:
+ $ref: /schemas/types.yaml#/definitions/string
+ description:
+ TVE output mode selection.
+ enum:
+ - ntsc
+ - pal
+ - vga
+
+ fsl,hsync-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Pin number for horizontal sync signal in VGA mode.
+ minimum: 0
+ maximum: 8
+
+ fsl,vsync-pin:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Pin number for vertical sync signal in VGA mode.
+ minimum: 0
+ maximum: 8
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Port node with one endpoint connected to the IPU display interface.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - fsl,tve-mode
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx5-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ tve@63ff0000 {
+ compatible = "fsl,imx53-tve";
+ reg = <0x63ff0000 0x1000>;
+ interrupts = <92>;
+ clocks = <&clks IMX5_CLK_TVE_GATE>,
+ <&clks IMX5_CLK_IPU_DI1_SEL>;
+ clock-names = "tve", "di_sel";
+ fsl,tve-mode = "vga";
+
+ port {
+ endpoint {
+ remote-endpoint = <&ipu_di1_tve>;
+ };
+ };
+ };
+
--
2.43.0
^ permalink raw reply related
* [PATCH v2 6/6] ARM: dts: imx6-display5: replace marvell,88E1510 with ethernet-phy-ieee802.3-c22
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Replace the vendor-specific PHY compatible string with the generic
ethernet-phy-ieee802.3-c22 compatible.
The marvell,88E1510 compatible is listed in whitelist_phys[] and is
never matched against a PHY driver. PHY devices are expected to use
the generic ethernet-phy-ieee802.3-c22 compatible unless a specific
MDIO driver match is required.
The 88E1510 is compatible with Clause 22 PHY devices, so use the
generic compatible string instead.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6q-display5-tianma-tm070-1280x768.dtb: /soc/bus@2100000/ethernet@2188000/mdio/ethernet-phy@0: failed to match any schema with compatible: ['marvell,88E1510']
Known other user (uboot) did not use marvell,88E1510.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi b/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
index 4e448b4810f27..21e8bbdab4e69 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi
@@ -208,7 +208,7 @@ mdio {
#address-cells = <1>;
#size-cells = <0>;
ethernet_phy0: ethernet-phy@0 {
- compatible = "marvell,88E1510";
+ compatible = "ethernet-phy-ieee802.3-c22";
device_type = "ethernet-phy";
/* Set LED0 control: */
/* On - Link, Blink - Activity, Off - No Link */
--
2.43.0
^ permalink raw reply related
* [PATCH v2 5/6] ARM: dts: imx: replace undocumented compatible string edt,edt-ft5x06 with edt,edt-ft5206
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
The edt,edt-ft5x06 compatible is not referenced in
drivers/input/touchscreen/edt-ft5x06.c and is not documented.
There is no publicly available datasheet or binding information that
distinguishes edt-ft5206/ft5306/ft5406 variants and the driver treats these
FT5x06-family controllers with the same configuration model. So switch to
the lowest common and documented baseline compatible edt,edt-ft5206.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dtb: /soc/bus@60000000/i2c@63fc8000/touchscreen@38: failed to match any schema with compatible: ['edt,edt-ft5x06']
ABI impact consideration:
Not affect Linux kernel. The I2C subsystem uses a legacy fallback mechanism
where it strips the vendor prefix from the compatible string to derive the
client name, resulting in edt-ft5x06
{ .name = "edt-ft5x06", .driver_data = (long)&edt_ft5x06_data },
After this, the driver was actively binding to these devices based on the
compatible string.
Known user (U-Boot) does not parse or use edt,edt-ft* touchscreen
compatibles.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- update commit about ABI impact base on feedback from sashiko AI
- add missed change in imx6qdl-nitrogen6_som2.dtsi (sashiko AI)
Change binding doc discuss at
- https://lore.kernel.org/imx/aasmQiZJO2gSKzNH@lizhi-Precision-Tower-5810/
---
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 2 +-
14 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
index 2acbc86cabb31..aa1c7e5012c6a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
@@ -248,7 +248,7 @@ &i2c1 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts b/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
index 872cf7e16f20c..6a1063c455f0c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts
@@ -201,7 +201,7 @@ sgtl5000: codec@a {
};
polytouch: edt-ft5x06@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06_1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts b/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
index 0225a621ec7a9..ccf6a048c9184 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts
@@ -169,7 +169,7 @@ &i2c3 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
index 610b2a72fe825..cebfd622df688 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi
@@ -256,7 +256,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
index ef0c26688446e..f8a7218b13ef2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi
@@ -405,7 +405,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi
index 03fe053880ca6..fb1c923c46bca 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi
@@ -326,7 +326,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
index 6a353a99e13da..9fe52e0ca7aa2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi
@@ -333,7 +333,7 @@ touchscreen@4 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <9 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
index c39a9ebdaba1c..ca4cb986efbc2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi
@@ -217,7 +217,7 @@ &i2c2 {
status = "okay";
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio5>;
interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
index ec1528ff3ea01..fe25934e06b1f 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
@@ -292,7 +292,7 @@ sgtl5000: sgtl5000@a {
};
polytouch: edt-ft5x06@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
index bf7dbb4f1f3ed..e99ba04216b86 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts
@@ -62,7 +62,7 @@ &i2c3 {
status = "okay";
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
index 6cfc943a8fa3e..f79090fb2e6e2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts
@@ -65,7 +65,7 @@ &i2c3 {
status = "okay";
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
interrupt-parent = <&gpio1>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
index 1992dfb53b45c..192c6a95ae589 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi
@@ -317,7 +317,7 @@ sgtl5000: codec@a {
};
polytouch: polytouch@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_edt_ft5x06>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts b/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
index 347dd0fe4f82e..fca8aab9d8507 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts
@@ -70,7 +70,7 @@ pca9554: io-expander@25 {
};
touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_touchscreen>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
index 62221131336f1..673bbe49de525 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
@@ -49,7 +49,7 @@ sgtl5000: codec@a {
&i2c4 {
polytouch: touchscreen@38 {
- compatible = "edt,edt-ft5x06";
+ compatible = "edt,edt-ft5206";
reg = <0x38>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_touchscreen>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/6] ARM: dts: imx: Add bus-type for ov5642/ov5640
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Add bus-type (MEDIA_BUS_TYPE_PARALLEL) for ov5642/ov5640. i.MX53 and
i.MX6UL only supports parallel csi interface. Fix below CHECK_DTBS
warnings:
arm/boot/dts/nxp/imx/imx53-smd.dtb: ov5642@3c (ovti,ov5642): port:endpoint: 'bus-type' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 2 ++
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 1 +
2 files changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-smd.dts b/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
index a1e19f9709b2c..8c02731c7ba9d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-smd.dts
@@ -5,6 +5,7 @@
/dts-v1/;
#include <dt-bindings/input/input.h>
+#include <dt-bindings/media/video-interfaces.h>
#include "imx53.dtsi"
/ {
@@ -314,6 +315,7 @@ camera: ov5642@3c {
port {
ov5642_to_ipu_csi0: endpoint {
remote-endpoint = <&ipu_csi0_from_parallel_sensor>;
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
bus-width = <8>;
hsync-active = <1>;
vsync-active = <1>;
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
index 3d147b160ecf1..32afe4130e211 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
@@ -217,6 +217,7 @@ camera@3c {
port {
ov5640_to_parallel: endpoint {
remote-endpoint = <¶llel_from_ov5640>;
+ bus-type = <MEDIA_BUS_TYPE_PARALLEL>;
bus-width = <8>;
data-shift = <2>; /* lines 9:2 are used */
hsync-active = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/6] ARM: dts: imx6qdl-tx6: remove undocumented karo,imx6qdl-tx6-sgtl5000 and keep only simple-audio-card
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Remove the undocumented and unused compatible karo,imx6qdl-tx6-sgtl5000 and
retain only the generic simple-audio-card sound configuration.
The karo,imx6qdl-tx6-sgtl5000 compatible is not documented and is not
referenced by any in-kernel driver. The audio setup is already fully
described using simple-audio-card, which is the standard and supported
binding for this hardware configuration.
No known users (such as uboot) rely on karo,imx6qdl-tx6-sgtl5000.
Fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-tx6dl-comtft.dtb: /sound: failed to match any schema with compatible: ['karo,imx6qdl-tx6-sgtl5000', 'simple-audio-card']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
index 57297d6521cf0..ec1528ff3ea01 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi
@@ -148,8 +148,7 @@ reg_usbotg_vbus: regulator-usbotg-vbus {
};
sound {
- compatible = "karo,imx6qdl-tx6-sgtl5000",
- "simple-audio-card";
+ compatible = "simple-audio-card";
simple-audio-card,name = "imx6qdl-tx6-sgtl5000-audio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_audmux>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/6] ARM: dts: imx: remove redundant bus-width for video-mux
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Remove redundant bus-width property according to video-mux.yaml to fix
below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-gw51xx.dtb: ipu1_csi0_mux (video-mux): port@4:endpoint: Unevaluated properties are not allowed ('bus-width' was unexpected)
from schema $id: http://devicetree.org/schemas/media/video-mux.yaml
The bus-width already set at remote endpoint (camera).
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts | 4 ----
arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 2 --
10 files changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
index 9ea23dd54f3ce..62b05fe70cd97 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
index 182e8194c2490..c1787510d3941 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
index a106c4e3e3299..934b0325e6f5a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu1_csi1_mux: endpoint {
};
&ipu1_csi1_from_ipu1_csi1_mux {
- bus-width = <8>;
};
&ipu1_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi1_mux>;
- bus-width = <8>;
};
&ipu1_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
index 6e1c493c9c8c4..31996ddde117a 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu2_csi1_mux: endpoint {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
index f13df8e9c8c4b..f224273fa863e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts
@@ -32,12 +32,10 @@ adv7180_to_ipu2_csi1_mux: endpoint {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts b/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
index d5d46908cf6ed..804ee044be52d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts
@@ -90,12 +90,10 @@ tda1997x_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <16>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
- bus-width = <16>;
};
&ipu1_csi0 {
@@ -104,12 +102,10 @@ &ipu1_csi0 {
};
&ipu2_csi1_from_ipu2_csi1_mux {
- bus-width = <8>;
};
&ipu2_csi1_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu2_csi1_mux>;
- bus-width = <8>;
};
&ipu2_csi1 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
index beff5a0f58ab4..fb18b87adb441 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi
@@ -384,12 +384,10 @@ adv7180_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
index 6136a95b92599..55647c1dacfa5 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi
@@ -440,12 +440,10 @@ tda1997x_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <16>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&tda1997x_to_ipu1_csi0_mux>;
- bus-width = <16>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
index 552114a69f5b9..bdbcad5e35d82 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi
@@ -397,12 +397,10 @@ adv7180_to_ipu1_csi0_mux: endpoint {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
index b9dde0af3b995..40d8887cb8bc7 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi
@@ -245,12 +245,10 @@ accelerometer@1c {
};
&ipu1_csi0_from_ipu1_csi0_mux {
- bus-width = <8>;
};
&ipu1_csi0_mux_from_parallel_sensor {
remote-endpoint = <&adv7180_to_ipu1_csi0_mux>;
- bus-width = <8>;
};
&ipu1_csi0 {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/6] ARM: dts: cleanup some CHECK_DTBS warning for imx5/6 (round 2)
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
Cleanup CHECK_DTBS warning for imx_v6_v7_defconfig. (below 500 line warning
left) after apply pending binding doc patch.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v2:
- fix sashiko AI's feedback, detail see each patch's change log
- Link to v1: https://lore.kernel.org/r/20260515-imx25_dts_simple_warning_2-v1-0-b06bff192a05@nxp.com
---
Frank Li (6):
ARM: dts: imx: add (power|vdd)-supply for related node
ARM: dts: imx: remove redundant bus-width for video-mux
ARM: dts: imx: Add bus-type for ov5642/ov5640
ARM: dts: imx6qdl-tx6: remove undocumented karo,imx6qdl-tx6-sgtl5000 and keep only simple-audio-card
ARM: dts: imx: replace undocumented compatible string edt,edt-ft5x06 with edt,edt-ft5206
ARM: dts: imx6-display5: replace marvell,88E1510 with ethernet-phy-ieee802.3-c22
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 11 ++++++++++-
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts | 7 +++++++
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 2 ++
arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts | 2 --
arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts | 4 ----
arch/arm/boot/dts/nxp/imx/imx6q-novena.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-var-dt6customboard.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 2 --
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 5 ++---
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 2 +-
30 files changed, 37 insertions(+), 39 deletions(-)
---
base-commit: d26bfe9856a36453f591b9620dac996ff9f02443
change-id: 20260511-imx25_dts_simple_warning_2-10d3c75b8889
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v2 1/6] ARM: dts: imx: add (power|vdd)-supply for related node
From: Frank.Li @ 2026-05-21 19:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Frank Li
In-Reply-To: <20260521-imx25_dts_simple_warning_2-v2-0-c6557df516a9@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
Add required power-supply and vdd-supply properties to fix below CHECK_DTB
warnings:
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dtb: panel (edt,etm0700g0dh6): 'power-supply' is a required property
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v2
- change regulator name to 5v (sashika AI)
---
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 9 +++++++++
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts | 7 +++++++
arch/arm/boot/dts/nxp/imx/imx6q-novena.dts | 1 +
4 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
index 6210673f93bea..2acbc86cabb31 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts
@@ -84,6 +84,7 @@ panel {
pinctrl-0 = <&pinctrl_display_gpio>;
pinctrl-names = "default";
enable-gpios = <&gpio6 0 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_3p2v>;
port {
panel_in: endpoint {
@@ -98,6 +99,13 @@ beeper {
gpios = <&gpio6 3 GPIO_ACTIVE_HIGH>;
};
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
reg_usbh1_vbus: regulator-usbh1-vbus {
compatible = "regulator-fixed";
regulator-name = "vbus";
@@ -259,6 +267,7 @@ eeprom@50 {
dac@60 {
compatible = "microchip,mcp4725";
reg = <0x60>;
+ vdd-supply = <®_3v3>;
};
};
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
index e395004e80e6d..34cb0c344ff6e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi
@@ -10,6 +10,7 @@
/ {
panel: panel-rgb {
compatible = "powertip,ph800480t013-idf02";
+ power-supply = <®_5v>;
port {
panel_rgb_in: endpoint {
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
index 1a00d290092ad..ebec884958776 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts
@@ -29,6 +29,13 @@ memory@70000000 {
reg = <0x70000000 0x20000000>;
};
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5v";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
reg_usb1_vbus: regulator-usb-vbus {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts b/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
index 24fc3ff1c70c2..cd9a050fa906e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-novena.dts
@@ -109,6 +109,7 @@ led-heartbeat {
panel: panel {
compatible = "innolux,n133hse-ea1";
backlight = <&backlight>;
+ power-supply = <®_lvds_lcd>;
};
reg_2p5v: regulator-2p5v {
--
2.43.0
^ permalink raw reply related
* [PATCH] ARM: zte: clean up zx297520v3 doc. warnings
From: Randy Dunlap @ 2026-05-21 19:14 UTC (permalink / raw)
To: linux-kernel
Cc: Randy Dunlap, Stefan Dösinger, Linus Walleij,
Krzysztof Kozlowski, linux-arm-kernel, Jonathan Corbet,
Shuah Khan, linux-doc
Fix multiple documentation build warnings.
Improve punctuation and formatting of the rendered output.
Documentation/arch/arm/zte/zx297520v3.rst:66: WARNING: Title underline too short.
3. Building for built-in U-Boot
--------------------------- [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:90: WARNING: Enumerated list ends without a blank line; unexpected unindent. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:116: WARNING: Inline literal start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:137: ERROR: Unexpected indentation. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:138: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:164: WARNING: Inline literal start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:164: WARNING: Inline interpreted text or phrase reference start-string without end-string. [docutils]
Documentation/arch/arm/zte/zx297520v3.rst:7: WARNING: Document or section may not begin with a transition. [docutils]
Fixes: 220ae5d36dba ("ARM: zte: Add zx297520v3 platform support")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
Cc: Stefan Dösinger <stefandoesinger@gmail.com>
Cc: Linus Walleij <linusw@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: linux-doc@vger.kernel.org
Documentation/arch/arm/zte/zx297520v3.rst | 119 +++++++++-----------
1 file changed, 59 insertions(+), 60 deletions(-)
--- linux-next.orig/Documentation/arch/arm/zte/zx297520v3.rst
+++ linux-next/Documentation/arch/arm/zte/zx297520v3.rst
@@ -4,15 +4,13 @@
Booting Linux on ZTE zx297520v3 SoCs
====================================
-...............................................................................
-
Author: Stefan Dösinger
Date : 27 Jan 2026
1. Hardware description
---------------------------
-Zx297520v3 SoCs use a 64 bit capable Cortex-A53 CPU and GICv3, although they
+Zx297520v3 SoCs use a 64-bit capable Cortex-A53 CPU and GICv3, although they
run in arm32 mode only. The CPU has support EL3, but no hypervisor (EL2) and
it seems to lack VFP and NEON.
@@ -27,7 +25,7 @@ Some devices, especially the stationary
Ethernet switch.
Usually the devices have LEDs for status indication, although some have SPI or
-I2C connected displays
+I2C connected displays.
Some have an SD card slot. If it exists, it is a better choice for the root
file system because it easily outperforms the built-in NAND.
@@ -39,7 +37,7 @@ IRQs on either ends.
There is also a Cortex M0 CPU, which is responsible for early HW initialization
and starting the Cortex A53 CPU. It does not have any essential purpose once
-U-Boot is started. A SRAM-Based handover protocol exists to run custom code on
+U-Boot is started. An SRAM-based handover protocol exists to run custom code on
this CPU.
2. Booting via USB
@@ -63,13 +61,13 @@ Contains an U-Boot version that can be u
CPU and interrupt controller to comply with Linux's booting requirements.
3. Building for built-in U-Boot
----------------------------
+-------------------------------
The devices come with an ancient U-Boot that loads legacy uImages from NAND and
boots them without a chance for the user to interrupt. The images are stored in
files ap_cpuap.bin and ap_recovery.bin on a jffs2 partition named imagefs,
usually mtd4. A file named "fotaflag" switches between the two modes.
-In addition to the uImage header, those files have a 384 byte signature header,
+In addition to the uImage header, those files have a 384-byte signature header,
which is used for authenticating the images on some devices. Most devices have
this authentication disabled and it is enough to pad the uImage files with 384
zero bytes.
@@ -88,7 +86,7 @@ So to build an image that boots from NAN
6) dd if=/dev/zero bs=1 count=384 of=ap_recovery.bin
7) cat uimg >> ap_recovery.bin
8) Place this file onto imagefs on the device. Delete ap_cpuap.bin if the
-free space is not enough.
+ free space is not enough.
9) Create the file fotaflag: echo -n FOTA-RECOVERY > fotaflag
For development, booting ap_recovery.bin is recommended because the normal boot
@@ -113,55 +111,56 @@ the binary blobs.
The assembly code below is given as an example of how to achieve this:
-```
-#include <linux/irqchip/arm-gic-v3.h>
-#include <asm/assembler.h>
-#include <asm/cp15.h>
-
-@ Detect sane bootloaders and skip the hack
-ldr r3, =0xf2000000
-ldr r3, [r3]
-ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
-cmp r3, r4
-beq skip_zx_hack
-@ This allows EL1 to handle ints hat are normally handled by EL2/3.
-ldr r3, =0xf2000000
-str r4, [r3]
-
-cps #MON_MODE
-
-@ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
-@ seems to respond only to non-secure addresses. I have taken insipiration from
-@ Raspberry pi's armstub7.S here.
-mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
- @ Allow hypervisor call.
-mcr p15, 0, r3, c1, c1, 0
-
-@ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
-ldr r3, =0xF22020a8
-ldr r4, =0x50
-str r4, [r3]
-ldr r3, =0xF22020ac
-ldr r4, =0x14
-str r4, [r3]
-
-@ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
-@ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
-mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
-orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
-mcr p15, 6, r3, c12, c12, 5
-mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
-orr r3, #(ICC_SRE_EL1_SRE)
-mcr p15, 0, r3, c12, c12, 5
-
-@ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
-@ for EL2.
-mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
-orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
-mcr p15, 4, r3, c12, c9, 5
-isb
-
-@ Back to SVC mode
-cps #SVC_MODE
-skip_zx_hack:
-```
+::
+
+ #include <linux/irqchip/arm-gic-v3.h>
+ #include <asm/assembler.h>
+ #include <asm/cp15.h>
+
+ @ Detect sane bootloaders and skip the hack
+ ldr r3, =0xf2000000
+ ldr r3, [r3]
+ ldr r4, =(GICD_CTLR_ARE_NS | GICD_CTLR_DS)
+ cmp r3, r4
+ beq skip_zx_hack
+ @ This allows EL1 to handle ints hat are normally handled by EL2/3.
+ ldr r3, =0xf2000000
+ str r4, [r3]
+
+ cps #MON_MODE
+
+ @ Work in non-secure physical address space: SCR_EL3.NS = 1. At least the UART
+ @ seems to respond only to non-secure addresses. I have taken insipiration from
+ @ Raspberry pi's armstub7.S here.
+ mov r3, #0x131 @ non-secure, Make F, A bits in CPSR writeable
+ @ Allow hypervisor call.
+ mcr p15, 0, r3, c1, c1, 0
+
+ @ AP_PPI_MODE_REG: Configure timer PPIs (10, 11, 13, 14) to active-low.
+ ldr r3, =0xF22020a8
+ ldr r4, =0x50
+ str r4, [r3]
+ ldr r3, =0xF22020ac
+ ldr r4, =0x14
+ str r4, [r3]
+
+ @ Enable EL2 access to ICC_SRE (bit 3, ICC_SRE_EL3.Enable). Enable system reg
+ @ access to GICv3 registers (bit 0, ICC_SRE_EL3.SRE) for EL1 and EL3.
+ mrc p15, 6, r3, c12, c12, 5 @ ICC_SRE_EL3
+ orr r3, #0x9 @ FIXME: No defines for SRE_EL3 values?
+ mcr p15, 6, r3, c12, c12, 5
+ mrc p15, 0, r3, c12, c12, 5 @ ICC_SRE_EL1
+ orr r3, #(ICC_SRE_EL1_SRE)
+ mcr p15, 0, r3, c12, c12, 5
+
+ @ Like ICC_SRE_EL3, enable EL1 access to ICC_SRE and system register access
+ @ for EL2.
+ mrc p15, 4, r3, c12, c9, 5 @ ICC_SRE_EL2 aka ICC_HSRE
+ orr r3, r3, #(ICC_SRE_EL2_ENABLE | ICC_SRE_EL2_SRE)
+ mcr p15, 4, r3, c12, c9, 5
+ isb
+
+ @ Back to SVC mode
+ cps #SVC_MODE
+ skip_zx_hack:
+
^ permalink raw reply
* Re: [PATCH] pwm: imx27: Fix variable truncation in .apply()
From: Frank Li @ 2026-05-21 18:56 UTC (permalink / raw)
To: Ronaldo Nunez
Cc: linux-pwm, Uwe Kleine-König, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260521000054.4790-1-rnunez@baylibre.com>
On Wed, May 20, 2026 at 09:00:54PM -0300, Ronaldo Nunez wrote:
> This patch fixes a variable truncation when calculating period in
Remove "This Patch" just
Fix a variable 'tmp' truncation when calculating period in
> microseconds as part of the solution for the ERR051198 in .apply()
> callback.
>
> The problem was identified when reducing the duty cycle through sysfs,
> with enable set to 1. The condition to fix errata ERR051198 for period
> smaller than 2us is always being met, due to a truncation on tmp,
> variable from .apply() callback, caused by the multiplication of
> NSEC_PER_SEC, PWMPR (period register) and the prescaler which can easily
> overflow u32.
It'd better provide actual example value for PWMPR and prescaler when
overflow happen.
> Declaring tmp as u64 makes it large enough to accommodate
> larger multiplication results.
>
> Testing:
> - Hardware: Udoo Neo Extended with iMX6SoloX SoC
> - Tools: Verified with a logic analyzer
needn't this part.
Frank
>
> Signed-off-by: Ronaldo Nunez <rnunez@baylibre.com>
> ---
> drivers/pwm/pwm-imx27.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pwm/pwm-imx27.c b/drivers/pwm/pwm-imx27.c
> index 3d34cdc4a3a5..c8b801fcb525 100644
> --- a/drivers/pwm/pwm-imx27.c
> +++ b/drivers/pwm/pwm-imx27.c
> @@ -200,7 +200,7 @@ static void pwm_imx27_wait_fifo_slot(struct pwm_chip *chip,
> static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> const struct pwm_state *state)
> {
> - unsigned long period_cycles, duty_cycles, prescale, period_us, tmp;
> + unsigned long period_cycles, duty_cycles, prescale, period_us;
> struct pwm_imx27_chip *imx = to_pwm_imx27_chip(chip);
> unsigned long long c;
> unsigned long long clkrate;
> @@ -208,6 +208,7 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> int val;
> int ret;
> u32 cr;
> + u64 tmp;
>
> clkrate = clk_get_rate(imx->clks[PWM_IMX27_PER].clk);
> c = clkrate * state->period;
> @@ -249,6 +250,11 @@ static int pwm_imx27_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> val = readl(imx->mmio_base + MX3_PWMPR);
> val = val >= MX3_PWMPR_MAX ? MX3_PWMPR_MAX : val;
> cr = readl(imx->mmio_base + MX3_PWMCR);
> +
> + /*
> + * tmp stores period in nanoseconds. Result fits in u64 since
> + * val <= 0xfffe and prescaler in [1, 0x1000].
> + */
> tmp = NSEC_PER_SEC * (u64)(val + 2) * MX3_PWMCR_PRESCALER_GET(cr);
> tmp = DIV_ROUND_UP_ULL(tmp, clkrate);
> period_us = DIV_ROUND_UP_ULL(tmp, 1000);
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc: xlnx: enable auto boot feature
From: Shah, Tanmay @ 2026-05-21 18:48 UTC (permalink / raw)
To: Mathieu Poirier, Tanmay Shah
Cc: andersson, robh, krzk+dt, conor+dt, michal.simek, ben.levinsky,
linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cbd418a3-1585-4592-8e86-b0750e19ec0f@amd.com>
On 5/21/2026 1:38 PM, Shah, Tanmay wrote:
> Hello,
>
> Thank you for the reviews, please find my comments below:
>
> On 5/21/2026 12:48 PM, Mathieu Poirier wrote:
>> Good morning,
>>
>> I don't recal reviewing the first revision of this set. Can you provide a link
>> to it so that I can read the comments that were provided?
>>
>
> Here it is:
> https://lore.kernel.org/linux-remoteproc/20260422202558.2362971-1-tanmay.shah@amd.com/
>
> The device-tree bindings needed rework in v1, so I sent v2, before we
> ever reviewed the driver part.
>
>
>> On Fri, May 01, 2026 at 07:37:07AM -0700, Tanmay Shah wrote:
>>> remoteproc framework has capability to start (or attach to) the remote
>>
>> The remoteproc framework...
>>
>
> Ack.
>
>>> processor automatically if auto boot flag is set by the driver during
>>> probe. If remote core is not started before the Linux boot, and linux is
>>> expected to start the remote core then it uses "firmware-name" property
>>> to load default firmware during auto boot.
>>>
>>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>>> ---
>>> drivers/remoteproc/xlnx_r5_remoteproc.c | 48 +++++++++++++++++--------
>>> 1 file changed, 34 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> index 45a62cb98072..652030f9cea2 100644
>>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>>> @@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
>>> };
>>>
>>> /**
>>> - * zynqmp_r5_add_rproc_core() - Add core data to framework.
>>> - * Allocate and add struct rproc object for each r5f core
>>> + * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
>>> + * Allocate struct rproc object for each r5f core
>>> * This is called for each individual r5f core
>>> *
>>> * @cdev: Device node of each r5 core
>>> *
>>> * Return: zynqmp_r5_core object for success else error code pointer
>>> */
>>> -static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>>> +static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
>>
>> Why is there a need to change the function's name?
>>
>
> Before, the function was actually adding the rproc core by calling
> rproc_add() function, but now it only allocates the memory by calling
> rproc_alloc(). For auto boot to work it's important to add rproc core
> after all the other hw is initialized (such as mbox, tcm, sram,
> power-domains etc). More details below [1].
>
>>> {
>>> struct zynqmp_r5_core *r5_core;
>>> + const char *fw_name = NULL;
>>> struct rproc *r5_rproc;
>>> int ret;
>>>
>>> @@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>>> if (ret)
>>> return ERR_PTR(ret);
>>>
>>> + ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
>>> + if (ret < 0 && ret != -EINVAL)
>>> + return ERR_PTR(dev_err_probe(cdev, ret,
>>> + "failed to parse firmware-name\n"));
>>> +
>>> /* Allocate remoteproc instance */
>>> r5_rproc = rproc_alloc(cdev, dev_name(cdev),
>>> &zynqmp_r5_rproc_ops,
>>> - NULL, sizeof(struct zynqmp_r5_core));
>>> + fw_name, sizeof(struct zynqmp_r5_core));
>>> if (!r5_rproc) {
>>> dev_err(cdev, "failed to allocate memory for rproc instance\n");
>>> return ERR_PTR(-ENOMEM);
>>> @@ -932,6 +938,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>>> r5_rproc->recovery_disabled = true;
>>> r5_rproc->has_iommu = false;
>>> r5_rproc->auto_boot = false;
>>> +
>>> + /* attempt to boot automatically if the firmware-name is provided */
>>> + if (fw_name)
>>> + r5_rproc->auto_boot = true;
>>> +
>>
>> What happens when a firmware name needs to be provided in the DT but you don't
>> want to automatically boot the remote processor?
>>
>
> I think that use case is not needed. If the user/system-designer doesn't
> want auto-boot, then having firmware-name in the device-tree serves no
> purpose. User can always load the firmware via sysfs once kernel boots.
>
>>> r5_core = r5_rproc->priv;
>>> r5_core->dev = cdev;
>>> r5_core->np = dev_of_node(cdev);
>>> @@ -941,13 +952,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>>> goto free_rproc;
>>> }
>>>
>>> - /* Add R5 remoteproc core */
>>> - ret = rproc_add(r5_rproc);
>>> - if (ret) {
>>> - dev_err(cdev, "failed to add r5 remoteproc\n");
>>> - goto free_rproc;
>>> - }
>>> -
>>
>> I'm not sure why there is a need to move this to zynqmp_r5_cluster_init()? Is
>> it simply to make the error path easier to handle? If so, please do that in a
>> separate patch.
>>
>
> [1] This was moved to make auto-boot work. The remote core can auto-boot
> only after other hardware is initialized. The zynqmp_r5_core_init()
> initializes sram, TCM and power-domains of the core. Also, mailbox is
> requested before zynqmp_r5_core_init() as well. We can't auto-boot core
> directly without all this. So, I had to move rproc_add() at the end of
> the cluster init, and rename above function from
> zynqmp_r5_add_rproc_core to zynqmp_r5_alloc_rproc_core.
>
> If you prefer, I will add above explanation in the commit text, or as
> comment right before rproc_add().
>
>
>
>>> r5_core->rproc = r5_rproc;
>>> return r5_core;
>>>
>>> @@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
>>> if (zynqmp_r5_get_rsc_table_va(r5_core))
>>> dev_dbg(r5_core->dev, "rsc tbl not found\n");
>>> r5_core->rproc->state = RPROC_DETACHED;
>>> + r5_core->rproc->auto_boot = true;
>>
>> I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?
>>
>
> That function is now zynqmp_r5_alloc_core() as mentioned above. Also,
> until now, auto_boot was set to 'false' only to show that it is
> disabled. It is actually used and enabled now.
>
"I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?"
I probably misunderstood this comment. Here is the correct explanation:
The auto_boot setting in the zynqmp_r5_alloc_core() is done if the
'firmware-name' property is present in the device-tree.
Here it is done, if the remote core is already running. This is to
support attach-detach use case.
So, auto_boot is possible in two cases: 1) If firmware-name property is
available (Linux boots the remote), 2) If firmware is already loaded and
remote was started by the boot loader. (Linux attaches to the running
remote).
This is the second use case.
Thanks,
Tanmay
>> Thanks,
>> Mathieu
>>
>>> }
>>> }
>>>
>>> @@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>>> enum rpu_oper_mode fw_reg_val;
>>> struct device **child_devs;
>>> enum rpu_tcm_comb tcm_mode;
>>> - int core_count, ret, i;
>>> + int core_count, ret, i, j;
>>> struct mbox_info *ipi;
>>>
>>> ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
>>> @@ -1390,7 +1395,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>>> child_devs[i] = &child_pdev->dev;
>>>
>>> /* create and add remoteproc instance of type struct rproc */
>>> - r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
>>> + r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
>>> if (IS_ERR(r5_cores[i])) {
>>> ret = PTR_ERR(r5_cores[i]);
>>> r5_cores[i] = NULL;
>>> @@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>>> goto release_r5_cores;
>>> }
>>>
>>> + for (j = 0; j < cluster->core_count; j++) {
>>> + /* Add R5 remoteproc core */
>>> + ret = rproc_add(r5_cores[j]->rproc);
>>> + if (ret) {
>>> + dev_err_probe(r5_cores[j]->dev, ret,
>>> + "failed to add remoteproc\n");
>>> + goto delete_r5_cores;
>>> + }
>>> + }
>>> +
>>> kfree(child_devs);
>>> return 0;
>>>
>>> +delete_r5_cores:
>>> + i = core_count - 1;
>>> + /* delete previous added rproc */
>>> + while (--j >= 0)
>>> + rproc_del(r5_cores[j]->rproc);
>>> +
>>> release_r5_cores:
>>> while (i >= 0) {
>>> put_device(child_devs[i]);
>>> if (r5_cores[i]) {
>>> zynqmp_r5_free_mbox(r5_cores[i]->ipi);
>>> of_reserved_mem_device_release(r5_cores[i]->dev);
>>> - rproc_del(r5_cores[i]->rproc);
>>> rproc_free(r5_cores[i]->rproc);
>>> }
>>> i--;
>>> --
>>> 2.34.1
>>>
>
^ permalink raw reply
* Re: [PATCH v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
From: Andrew Lunn @ 2026-05-21 18:44 UTC (permalink / raw)
To: dev.taqnialabs
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, netdev,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260521-xgmac-mmc_rx_crc-cleanup-v2-1-7d9de09f5898@gmail.com>
On Thu, May 21, 2026 at 04:32:46PM +0000, Abid Ali via B4 Relay wrote:
> From: Abid Ali <dev.taqnialabs@gmail.com>
>
> MMC_XGMAC_RX_CRC_ERR is clear-on-read, and just a single read would
> update the mmc_rx_crc_error counter.
>
> [1] commit b6cdf09 ("net: stmmac: xgmac: Implement MMC counters").
> The duplicate read appears to have been unintentionally introduced in
> the intial MMC counter implementation. The databook does not mention
> MMC_XGMAC_RX_CRC_ERR needing the additional read.
Thanks for the updated commit message.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc: xlnx: enable auto boot feature
From: Shah, Tanmay @ 2026-05-21 18:38 UTC (permalink / raw)
To: Mathieu Poirier, Tanmay Shah
Cc: andersson, robh, krzk+dt, conor+dt, michal.simek, ben.levinsky,
linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <ag9FcXeIIiJWdld7@p14s>
Hello,
Thank you for the reviews, please find my comments below:
On 5/21/2026 12:48 PM, Mathieu Poirier wrote:
> Good morning,
>
> I don't recal reviewing the first revision of this set. Can you provide a link
> to it so that I can read the comments that were provided?
>
Here it is:
https://lore.kernel.org/linux-remoteproc/20260422202558.2362971-1-tanmay.shah@amd.com/
The device-tree bindings needed rework in v1, so I sent v2, before we
ever reviewed the driver part.
> On Fri, May 01, 2026 at 07:37:07AM -0700, Tanmay Shah wrote:
>> remoteproc framework has capability to start (or attach to) the remote
>
> The remoteproc framework...
>
Ack.
>> processor automatically if auto boot flag is set by the driver during
>> probe. If remote core is not started before the Linux boot, and linux is
>> expected to start the remote core then it uses "firmware-name" property
>> to load default firmware during auto boot.
>>
>> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
>> ---
>> drivers/remoteproc/xlnx_r5_remoteproc.c | 48 +++++++++++++++++--------
>> 1 file changed, 34 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> index 45a62cb98072..652030f9cea2 100644
>> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
>> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
>> @@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
>> };
>>
>> /**
>> - * zynqmp_r5_add_rproc_core() - Add core data to framework.
>> - * Allocate and add struct rproc object for each r5f core
>> + * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
>> + * Allocate struct rproc object for each r5f core
>> * This is called for each individual r5f core
>> *
>> * @cdev: Device node of each r5 core
>> *
>> * Return: zynqmp_r5_core object for success else error code pointer
>> */
>> -static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>> +static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
>
> Why is there a need to change the function's name?
>
Before, the function was actually adding the rproc core by calling
rproc_add() function, but now it only allocates the memory by calling
rproc_alloc(). For auto boot to work it's important to add rproc core
after all the other hw is initialized (such as mbox, tcm, sram,
power-domains etc). More details below [1].
>> {
>> struct zynqmp_r5_core *r5_core;
>> + const char *fw_name = NULL;
>> struct rproc *r5_rproc;
>> int ret;
>>
>> @@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>> if (ret)
>> return ERR_PTR(ret);
>>
>> + ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
>> + if (ret < 0 && ret != -EINVAL)
>> + return ERR_PTR(dev_err_probe(cdev, ret,
>> + "failed to parse firmware-name\n"));
>> +
>> /* Allocate remoteproc instance */
>> r5_rproc = rproc_alloc(cdev, dev_name(cdev),
>> &zynqmp_r5_rproc_ops,
>> - NULL, sizeof(struct zynqmp_r5_core));
>> + fw_name, sizeof(struct zynqmp_r5_core));
>> if (!r5_rproc) {
>> dev_err(cdev, "failed to allocate memory for rproc instance\n");
>> return ERR_PTR(-ENOMEM);
>> @@ -932,6 +938,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>> r5_rproc->recovery_disabled = true;
>> r5_rproc->has_iommu = false;
>> r5_rproc->auto_boot = false;
>> +
>> + /* attempt to boot automatically if the firmware-name is provided */
>> + if (fw_name)
>> + r5_rproc->auto_boot = true;
>> +
>
> What happens when a firmware name needs to be provided in the DT but you don't
> want to automatically boot the remote processor?
>
I think that use case is not needed. If the user/system-designer doesn't
want auto-boot, then having firmware-name in the device-tree serves no
purpose. User can always load the firmware via sysfs once kernel boots.
>> r5_core = r5_rproc->priv;
>> r5_core->dev = cdev;
>> r5_core->np = dev_of_node(cdev);
>> @@ -941,13 +952,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
>> goto free_rproc;
>> }
>>
>> - /* Add R5 remoteproc core */
>> - ret = rproc_add(r5_rproc);
>> - if (ret) {
>> - dev_err(cdev, "failed to add r5 remoteproc\n");
>> - goto free_rproc;
>> - }
>> -
>
> I'm not sure why there is a need to move this to zynqmp_r5_cluster_init()? Is
> it simply to make the error path easier to handle? If so, please do that in a
> separate patch.
>
[1] This was moved to make auto-boot work. The remote core can auto-boot
only after other hardware is initialized. The zynqmp_r5_core_init()
initializes sram, TCM and power-domains of the core. Also, mailbox is
requested before zynqmp_r5_core_init() as well. We can't auto-boot core
directly without all this. So, I had to move rproc_add() at the end of
the cluster init, and rename above function from
zynqmp_r5_add_rproc_core to zynqmp_r5_alloc_rproc_core.
If you prefer, I will add above explanation in the commit text, or as
comment right before rproc_add().
>> r5_core->rproc = r5_rproc;
>> return r5_core;
>>
>> @@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
>> if (zynqmp_r5_get_rsc_table_va(r5_core))
>> dev_dbg(r5_core->dev, "rsc tbl not found\n");
>> r5_core->rproc->state = RPROC_DETACHED;
>> + r5_core->rproc->auto_boot = true;
>
> I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?
>
That function is now zynqmp_r5_alloc_core() as mentioned above. Also,
until now, auto_boot was set to 'false' only to show that it is
disabled. It is actually used and enabled now.
> Thanks,
> Mathieu
>
>> }
>> }
>>
>> @@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>> enum rpu_oper_mode fw_reg_val;
>> struct device **child_devs;
>> enum rpu_tcm_comb tcm_mode;
>> - int core_count, ret, i;
>> + int core_count, ret, i, j;
>> struct mbox_info *ipi;
>>
>> ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
>> @@ -1390,7 +1395,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>> child_devs[i] = &child_pdev->dev;
>>
>> /* create and add remoteproc instance of type struct rproc */
>> - r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
>> + r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
>> if (IS_ERR(r5_cores[i])) {
>> ret = PTR_ERR(r5_cores[i]);
>> r5_cores[i] = NULL;
>> @@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
>> goto release_r5_cores;
>> }
>>
>> + for (j = 0; j < cluster->core_count; j++) {
>> + /* Add R5 remoteproc core */
>> + ret = rproc_add(r5_cores[j]->rproc);
>> + if (ret) {
>> + dev_err_probe(r5_cores[j]->dev, ret,
>> + "failed to add remoteproc\n");
>> + goto delete_r5_cores;
>> + }
>> + }
>> +
>> kfree(child_devs);
>> return 0;
>>
>> +delete_r5_cores:
>> + i = core_count - 1;
>> + /* delete previous added rproc */
>> + while (--j >= 0)
>> + rproc_del(r5_cores[j]->rproc);
>> +
>> release_r5_cores:
>> while (i >= 0) {
>> put_device(child_devs[i]);
>> if (r5_cores[i]) {
>> zynqmp_r5_free_mbox(r5_cores[i]->ipi);
>> of_reserved_mem_device_release(r5_cores[i]->dev);
>> - rproc_del(r5_cores[i]->rproc);
>> rproc_free(r5_cores[i]->rproc);
>> }
>> i--;
>> --
>> 2.34.1
>>
^ permalink raw reply
* [PATCH] media: bcm2835-unicam: Fix log status runtime access
From: Eugen Hristev @ 2026-05-21 18:09 UTC (permalink / raw)
To: Raspberry Pi Kernel Maintenance, Mauro Carvalho Chehab,
Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Dave Stevenson, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Jean-Michel Hautbois
Cc: Naushir Patuck, linux-media, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, Eugen Hristev
When requesting log status, the block might be powered
off, but registers are being read.
Avoid reading the registers if the device is not
resumed, thus also avoid powering up the device just
for log status.
Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface")
Signed-off-by: Eugen Hristev <ehristev@kernel.org>
---
drivers/media/platform/broadcom/bcm2835-unicam.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
index 8d28ba0b59a3..818694f007e2 100644
--- a/drivers/media/platform/broadcom/bcm2835-unicam.c
+++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
@@ -2052,6 +2052,10 @@ static int unicam_log_status(struct file *file, void *fh)
node->fmt.fmt.pix.width, node->fmt.fmt.pix.height);
dev_info(unicam->dev, "V4L2 format: %08x\n",
node->fmt.fmt.pix.pixelformat);
+
+ if (!pm_runtime_get_if_in_use(unicam->dev))
+ return 0;
+
reg = unicam_reg_read(unicam, UNICAM_IPIPE);
dev_info(unicam->dev, "Unpacking/packing: %u / %u\n",
unicam_get_field(reg, UNICAM_PUM_MASK),
---
base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
change-id: 20260521-bcmpipm-6c578e73239c
Best regards,
--
Eugen Hristev <ehristev@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 7/8] sched_ext: Sub-allocator over kernel-claimed BPF arena pages
From: Andrea Righi @ 2026-05-21 17:54 UTC (permalink / raw)
To: Tejun Heo
Cc: David Vernet, Changwoo Min, Alexei Starovoitov, Andrii Nakryiko,
Daniel Borkmann, Martin KaFai Lau, Kumar Kartikeya Dwivedi,
Peter Zijlstra, Catalin Marinas, Will Deacon, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, Andrew Morton,
David Hildenbrand, Mike Rapoport, Emil Tsalapatis, sched-ext, bpf,
x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <dd5b3702a826666242b6eb6e805bf83f@kernel.org>
On Thu, May 21, 2026 at 07:37:46AM -1000, Tejun Heo wrote:
> Build a per-scheduler sub-allocator on top of pages claimed from the BPF
> arena registered in the previous patch. Subsequent kernel-managed
> arena-resident structures (e.g. per-CPU set_cmask cmask) carve their storage
> from this pool.
>
> scx_arena_pool_init() creates a gen_pool. scx_arena_alloc() returns the
> kernel VA. On exhaustion, the pool grows by claiming more pages via
> bpf_arena_alloc_pages_sleepable(). Chunks are added at the kernel-side
> mapping address; callers translate to the BPF-arena form themselves if
> needed.
>
> Allocations sleep (GFP_KERNEL) - they may grow the pool through vzalloc and
> arena page allocation. All current consumers run from the enable path (after
> ops.init() and the kernel-side arena auto-discovery, before validate_ops()),
> where sleeping is fine.
>
> scx_arena_pool_destroy() walks each chunk, returns outstanding ranges to the
> gen_pool with gen_pool_free() and then calls gen_pool_destroy(). The
> underlying arena pages are released when the arena map itself is torn down,
> so the pool destroy doesn't free them explicitly.
>
> v2: Switch scx_arena_alloc() to a loop. (Andrea)
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Andrea Righi <arighi@nvidia.com>
Looks good to me.
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Thanks,
-Andrea
> ---
> kernel/sched/build_policy.c | 4 +
> kernel/sched/ext.c | 11 +++
> kernel/sched/ext_arena.c | 126 ++++++++++++++++++++++++++++++++++++++++++++
> kernel/sched/ext_arena.h | 18 ++++++
> kernel/sched/ext_internal.h | 5 +
> 5 files changed, 164 insertions(+)
>
> --- a/kernel/sched/build_policy.c
> +++ b/kernel/sched/build_policy.c
> @@ -59,12 +59,16 @@
>
> #ifdef CONFIG_SCHED_CLASS_EXT
> # include <linux/btf_ids.h>
> +# include <linux/find.h>
> +# include <linux/genalloc.h>
> # include "ext_types.h"
> # include "ext_internal.h"
> # include "ext_cid.h"
> +# include "ext_arena.h"
> # include "ext_idle.h"
> # include "ext.c"
> # include "ext_cid.c"
> +# include "ext_arena.c"
> # include "ext_idle.c"
> #endif
>
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -5003,6 +5003,7 @@ static void scx_sched_free_rcu_work(stru
>
> rhashtable_free_and_destroy(&sch->dsq_hash, NULL, NULL);
> free_exit_info(sch->exit_info);
> + scx_arena_pool_destroy(sch);
> if (sch->arena_map)
> bpf_map_put(sch->arena_map);
> kfree(sch);
> @@ -7155,6 +7156,12 @@ static void scx_root_enable_workfn(struc
> sch->exit_info->flags |= SCX_EFLAG_INITIALIZED;
> }
>
> + ret = scx_arena_pool_init(sch);
> + if (ret) {
> + cpus_read_unlock();
> + goto err_disable;
> + }
> +
> for (i = SCX_OPI_CPU_HOTPLUG_BEGIN; i < SCX_OPI_CPU_HOTPLUG_END; i++)
> if (((void (**)(void))ops)[i])
> set_bit(i, sch->has_op);
> @@ -7473,6 +7480,10 @@ static void scx_sub_enable_workfn(struct
> sch->exit_info->flags |= SCX_EFLAG_INITIALIZED;
> }
>
> + ret = scx_arena_pool_init(sch);
> + if (ret)
> + goto err_disable;
> +
> if (validate_ops(sch, ops))
> goto err_disable;
>
> --- /dev/null
> +++ b/kernel/sched/ext_arena.c
> @@ -0,0 +1,126 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * BPF extensible scheduler class: Documentation/scheduler/sched-ext.rst
> + *
> + * scx_arena_pool: kernel-side sub-allocator over BPF-arena pages.
> + *
> + * Each chunk added to @sch->arena_pool comes from one
> + * bpf_arena_alloc_pages_sleepable() call and is registered at the
> + * kernel-side mapping address. Callers translate to the BPF-arena form
> + * themselves if needed.
> + *
> + * Allocations grow the pool on demand. Underlying arena pages are released
> + * when the arena map itself is torn down.
> + *
> + * Copyright (c) 2026 Meta Platforms, Inc. and affiliates.
> + * Copyright (c) 2026 Tejun Heo <tj@kernel.org>
> + */
> +
> +enum scx_arena_consts {
> + SCX_ARENA_MIN_ORDER = 3, /* 8-byte minimum sub-allocation */
> + SCX_ARENA_GROW_PAGES = 4, /* per growth */
> +};
> +
> +s32 scx_arena_pool_init(struct scx_sched *sch)
> +{
> + if (!sch->arena_map)
> + return 0;
> +
> + sch->arena_pool = gen_pool_create(SCX_ARENA_MIN_ORDER, NUMA_NO_NODE);
> + if (!sch->arena_pool)
> + return -ENOMEM;
> + return 0;
> +}
> +
> +static void scx_arena_clear_chunk(struct gen_pool *pool, struct gen_pool_chunk *chunk,
> + void *data)
> +{
> + int order = pool->min_alloc_order;
> + size_t chunk_sz = chunk->end_addr - chunk->start_addr + 1;
> + unsigned long end_bit = chunk_sz >> order;
> + unsigned long b, e;
> +
> + for_each_set_bitrange(b, e, chunk->bits, end_bit)
> + gen_pool_free(pool, chunk->start_addr + (b << order),
> + (e - b) << order);
> +}
> +
> +/*
> + * Tear down the pool. Outstanding gen_pool allocations are freed via
> + * scx_arena_clear_chunk() so gen_pool_destroy() doesn't BUG. The underlying
> + * arena pages are released when the arena map itself is torn down.
> + */
> +void scx_arena_pool_destroy(struct scx_sched *sch)
> +{
> + if (!sch->arena_pool)
> + return;
> + gen_pool_for_each_chunk(sch->arena_pool, scx_arena_clear_chunk, NULL);
> + gen_pool_destroy(sch->arena_pool);
> + sch->arena_pool = NULL;
> +}
> +
> +/*
> + * Grow the pool by @page_cnt pages. bpf_arena_alloc_pages_sleepable() and
> + * gen_pool_add() (which calls vzalloc(GFP_KERNEL)) require a sleepable
> + * context.
> + */
> +static int scx_arena_grow(struct scx_sched *sch, u32 page_cnt)
> +{
> + u64 kern_vm_start;
> + u32 uaddr32;
> + void *p;
> + int ret;
> +
> + if (!sch->arena_map || !sch->arena_pool)
> + return -EINVAL;
> +
> + p = bpf_arena_alloc_pages_sleepable(sch->arena_map, NULL,
> + page_cnt, NUMA_NO_NODE, 0);
> + if (!p)
> + return -ENOMEM;
> +
> + uaddr32 = (u32)(unsigned long)p;
> + kern_vm_start = bpf_arena_map_kern_vm_start(sch->arena_map);
> +
> + ret = gen_pool_add(sch->arena_pool, kern_vm_start + uaddr32,
> + page_cnt * PAGE_SIZE, NUMA_NO_NODE);
> + if (ret) {
> + bpf_arena_free_pages_non_sleepable(sch->arena_map, p, page_cnt);
> + return ret;
> + }
> + return 0;
> +}
> +
> +/*
> + * Allocate @size bytes from the arena pool. Returns kernel VA on success, NULL
> + * on failure. May grow the pool via scx_arena_grow() which sleeps. Caller must
> + * be in a GFP_KERNEL context.
> + */
> +void *scx_arena_alloc(struct scx_sched *sch, size_t size)
> +{
> + unsigned long kern_va;
> + u32 page_cnt;
> +
> + might_sleep();
> +
> + if (!sch->arena_pool)
> + return NULL;
> +
> + while (true) {
> + kern_va = gen_pool_alloc(sch->arena_pool, size);
> + if (kern_va)
> + break;
> + page_cnt = max_t(u32, SCX_ARENA_GROW_PAGES,
> + (size + PAGE_SIZE - 1) >> PAGE_SHIFT);
> + if (scx_arena_grow(sch, page_cnt))
> + return NULL;
> + }
> +
> + return (void *)kern_va;
> +}
> +
> +void scx_arena_free(struct scx_sched *sch, void *kern_va, size_t size)
> +{
> + if (sch->arena_pool && kern_va)
> + gen_pool_free(sch->arena_pool, (unsigned long)kern_va, size);
> +}
> --- /dev/null
> +++ b/kernel/sched/ext_arena.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * BPF extensible scheduler class: Documentation/scheduler/sched-ext.rst
> + *
> + * Copyright (c) 2025 Meta Platforms, Inc. and affiliates.
> + * Copyright (c) 2025 Tejun Heo <tj@kernel.org>
> + */
> +#ifndef _KERNEL_SCHED_EXT_ARENA_H
> +#define _KERNEL_SCHED_EXT_ARENA_H
> +
> +struct scx_sched;
> +
> +s32 scx_arena_pool_init(struct scx_sched *sch);
> +void scx_arena_pool_destroy(struct scx_sched *sch);
> +void *scx_arena_alloc(struct scx_sched *sch, size_t size);
> +void scx_arena_free(struct scx_sched *sch, void *kern_va, size_t size);
> +
> +#endif /* _KERNEL_SCHED_EXT_ARENA_H */
> --- a/kernel/sched/ext_internal.h
> +++ b/kernel/sched/ext_internal.h
> @@ -1116,8 +1116,13 @@ struct scx_sched {
> * Arena map auto-discovered from member progs at struct_ops attach.
> * cid-form schedulers must use exactly one arena across all member
> * progs. NULL on cpu-form.
> + *
> + * @arena_pool sub-allocates @arena_map. Each gen_pool chunk is added
> + * at the kernel-side mapping address. Grows on demand and pages are
> + * not released until sched destroy.
> */
> struct bpf_map *arena_map;
> + struct gen_pool *arena_pool;
>
> DECLARE_BITMAP(has_op, SCX_OPI_END);
>
^ permalink raw reply
* Re: [PATCH v2 2/2] remoteproc: xlnx: enable auto boot feature
From: Mathieu Poirier @ 2026-05-21 17:48 UTC (permalink / raw)
To: Tanmay Shah
Cc: andersson, robh, krzk+dt, conor+dt, michal.simek, ben.levinsky,
linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260501143707.1591110-3-tanmay.shah@amd.com>
Good morning,
I don't recal reviewing the first revision of this set. Can you provide a link
to it so that I can read the comments that were provided?
On Fri, May 01, 2026 at 07:37:07AM -0700, Tanmay Shah wrote:
> remoteproc framework has capability to start (or attach to) the remote
The remoteproc framework...
> processor automatically if auto boot flag is set by the driver during
> probe. If remote core is not started before the Linux boot, and linux is
> expected to start the remote core then it uses "firmware-name" property
> to load default firmware during auto boot.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/remoteproc/xlnx_r5_remoteproc.c | 48 +++++++++++++++++--------
> 1 file changed, 34 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 45a62cb98072..652030f9cea2 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
> };
>
> /**
> - * zynqmp_r5_add_rproc_core() - Add core data to framework.
> - * Allocate and add struct rproc object for each r5f core
> + * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
> + * Allocate struct rproc object for each r5f core
> * This is called for each individual r5f core
> *
> * @cdev: Device node of each r5 core
> *
> * Return: zynqmp_r5_core object for success else error code pointer
> */
> -static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> +static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
Why is there a need to change the function's name?
> {
> struct zynqmp_r5_core *r5_core;
> + const char *fw_name = NULL;
> struct rproc *r5_rproc;
> int ret;
>
> @@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> if (ret)
> return ERR_PTR(ret);
>
> + ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
> + if (ret < 0 && ret != -EINVAL)
> + return ERR_PTR(dev_err_probe(cdev, ret,
> + "failed to parse firmware-name\n"));
> +
> /* Allocate remoteproc instance */
> r5_rproc = rproc_alloc(cdev, dev_name(cdev),
> &zynqmp_r5_rproc_ops,
> - NULL, sizeof(struct zynqmp_r5_core));
> + fw_name, sizeof(struct zynqmp_r5_core));
> if (!r5_rproc) {
> dev_err(cdev, "failed to allocate memory for rproc instance\n");
> return ERR_PTR(-ENOMEM);
> @@ -932,6 +938,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> r5_rproc->recovery_disabled = true;
> r5_rproc->has_iommu = false;
> r5_rproc->auto_boot = false;
> +
> + /* attempt to boot automatically if the firmware-name is provided */
> + if (fw_name)
> + r5_rproc->auto_boot = true;
> +
What happens when a firmware name needs to be provided in the DT but you don't
want to automatically boot the remote processor?
> r5_core = r5_rproc->priv;
> r5_core->dev = cdev;
> r5_core->np = dev_of_node(cdev);
> @@ -941,13 +952,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> goto free_rproc;
> }
>
> - /* Add R5 remoteproc core */
> - ret = rproc_add(r5_rproc);
> - if (ret) {
> - dev_err(cdev, "failed to add r5 remoteproc\n");
> - goto free_rproc;
> - }
> -
I'm not sure why there is a need to move this to zynqmp_r5_cluster_init()? Is
it simply to make the error path easier to handle? If so, please do that in a
separate patch.
> r5_core->rproc = r5_rproc;
> return r5_core;
>
> @@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> if (zynqmp_r5_get_rsc_table_va(r5_core))
> dev_dbg(r5_core->dev, "rsc tbl not found\n");
> r5_core->rproc->state = RPROC_DETACHED;
> + r5_core->rproc->auto_boot = true;
I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?
Thanks,
Mathieu
> }
> }
>
> @@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> enum rpu_oper_mode fw_reg_val;
> struct device **child_devs;
> enum rpu_tcm_comb tcm_mode;
> - int core_count, ret, i;
> + int core_count, ret, i, j;
> struct mbox_info *ipi;
>
> ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
> @@ -1390,7 +1395,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> child_devs[i] = &child_pdev->dev;
>
> /* create and add remoteproc instance of type struct rproc */
> - r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
> + r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
> if (IS_ERR(r5_cores[i])) {
> ret = PTR_ERR(r5_cores[i]);
> r5_cores[i] = NULL;
> @@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> goto release_r5_cores;
> }
>
> + for (j = 0; j < cluster->core_count; j++) {
> + /* Add R5 remoteproc core */
> + ret = rproc_add(r5_cores[j]->rproc);
> + if (ret) {
> + dev_err_probe(r5_cores[j]->dev, ret,
> + "failed to add remoteproc\n");
> + goto delete_r5_cores;
> + }
> + }
> +
> kfree(child_devs);
> return 0;
>
> +delete_r5_cores:
> + i = core_count - 1;
> + /* delete previous added rproc */
> + while (--j >= 0)
> + rproc_del(r5_cores[j]->rproc);
> +
> release_r5_cores:
> while (i >= 0) {
> put_device(child_devs[i]);
> if (r5_cores[i]) {
> zynqmp_r5_free_mbox(r5_cores[i]->ipi);
> of_reserved_mem_device_release(r5_cores[i]->dev);
> - rproc_del(r5_cores[i]->rproc);
> rproc_free(r5_cores[i]->rproc);
> }
> i--;
> --
> 2.34.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox