* [PATCH] ARM: dts: BCM5301X: drop extra AXI bus ranges that break PCIe
From: Rosen Penev @ 2026-06-28 23:11 UTC (permalink / raw)
To: devicetree
Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Broadcom internal kernel review list, Rob Herring,
Krzysztof Kozlowski, Conor Dooley,
moderated list:BROADCOM BCM5301X ARM ARCHITECTURE, open list
These addresses overlap with DRAM on BCM5301X/BCM470X SoCs, causing the OF
address translation code to route PCIe MMIO accesses through the AXI bus
space instead of directly to memory, breaking PCIe. Remove the extra
ranges to restore the original single-entry mapping that only covers the
AXI peripheral register space.
Assisted-by: opencode:big-pickle
Fixes: 767012397976 ("ARM: dts: BCM5301X: Describe PCIe controllers fully")
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
arch/arm/boot/dts/broadcom/bcm-ns.dtsi | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
index bd52de0faa3e..27a97c8122de 100644
--- a/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm-ns.dtsi
@@ -95,10 +95,7 @@ L2: cache-controller@22000 {
axi@18000000 {
compatible = "brcm,bus-axi";
reg = <0x18000000 0x1000>;
- ranges = <0x00000000 0x18000000 0x00100000>,
- <0x08000000 0x08000000 0x08000000>,
- <0x20000000 0x20000000 0x08000000>,
- <0x28000000 0x28000000 0x08000000>;
+ ranges = <0x00000000 0x18000000 0x00100000>;
#address-cells = <1>;
#size-cells = <1>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH rc v6 2/7] iommu/arm-smmu-v3: Implement is_attach_deferred() for kdump
From: Pranjal Shrivastava @ 2026-06-28 23:06 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, jgg, joro, kees, baolu.lu, kevin.tian,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <89cbd3760a13f11cf63f6ead12f44974511f308a.1779265413.git.nicolinc@nvidia.com>
On Wed, May 20, 2026 at 10:03:19AM -0700, Nicolin Chen wrote:
> Though the kdump kernel adopts the crashed kernel's stream table, the iommu
> core will still try to attach each probed device to a default domain, which
> overwrites the adopted STE and breaks in-flight DMA from that device.
>
> Implement an is_attach_deferred() callback to prevent this. For each device
> that has STE.V=1 and STE.Cfg!=Abort in the adopted table, defer the default
> domain attachment, until the device driver explicitly requests it.
>
> Fixes: b63b3439b856 ("iommu/arm-smmu-v3: Abort all transactions if SMMU is enabled in kdump kernel")
> Cc: stable@vger.kernel.org # v6.12+
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v3 8/8] arm64: dts: qcom: shikra-iqs-evk: Enable A704 GPU
From: Dmitry Baryshkov @ 2026-06-28 22:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bjorn Andersson,
Bibek Kumar Patro, linux-arm-msm, dri-devel, freedreno,
devicetree, linux-kernel, linux-arm-kernel, iommu,
Aditya Sherawat
In-Reply-To: <20260628-shikra-gpu-v3-8-9b28a3b167e1@oss.qualcomm.com>
On Sun, Jun 28, 2026 at 11:54:01PM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Enable the A704 GPU and configure its zap-shader firmware on the
> Shikra IQS EVK board.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v15 1/9] drm/bridge: Implement generic USB Type-C DP HPD bridge
From: Chaoyi Chen @ 2026-06-29 1:29 UTC (permalink / raw)
To: Xu Yang, Heikki Krogerus
Cc: Chaoyi Chen, Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen,
Luca Ceresoli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang,
Andy Yan, Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel
In-Reply-To: <erx73m2ueuvbzjteadjli6aki5by4pr3hyertkkqqoqwhaa4v3@5cstmshcercx>
Hello Xu Yang,
On 6/26/2026 7:15 PM, Xu Yang wrote:
> On Wed, Mar 04, 2026 at 05:41:44PM +0800, Chaoyi Chen wrote:
>> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>>
>> The HPD function of Type-C DP is implemented through
>> drm_connector_oob_hotplug_event(). For embedded DP, it is required
>> that the DRM connector fwnode corresponds to the Type-C port fwnode.
>>
>> To describe the relationship between the DP controller and the Type-C
>> port device, we usually using drm_bridge to build a bridge chain.
>>
>> Now several USB-C controller drivers have already implemented the DP
>> HPD bridge function provided by aux-hpd-bridge.c, it will build a DP
>> HPD bridge on USB-C connector port device.
>>
>> But this requires the USB-C controller driver to manually register the
>> HPD bridge. If the driver does not implement this feature, the bridge
>> will not be create.
>>
>> So this patch implements a generic DP HPD bridge based on
>> aux-hpd-bridge.c. It will monitor Type-C bus events, and when a
>> Type-C port device containing the DP svid is registered, it will
>> create an HPD bridge for it without the need for the USB-C controller
>> driver to implement it.
>>
>> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>> ---
>>
>> (no changes since v14)
>>
>> Changes in v13:
>> - Only register drm dp hpd bridge for typec port altmode device.
>>
>> (no changes since v12)
>>
>> Changes in v11:
>> - Switch to using typec bus notifiers.
>>
>> (no changes since v10)
>>
>> Changes in v9:
>> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
>> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
>> - Add more commit comment about problem background.
>>
>> Changes in v8:
>> - Merge generic DP HPD bridge into one module.
>> ---
>>
>> drivers/gpu/drm/bridge/Kconfig | 10 ++++
>> drivers/gpu/drm/bridge/Makefile | 1 +
>> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++++++++++++++++++
>> 3 files changed, 60 insertions(+)
>> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>>
>> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
>> index a250afd8d662..559487aa09a9 100644
>> --- a/drivers/gpu/drm/bridge/Kconfig
>> +++ b/drivers/gpu/drm/bridge/Kconfig
>> @@ -30,6 +30,16 @@ config DRM_AUX_HPD_BRIDGE
>> Simple bridge that terminates the bridge chain and provides HPD
>> support.
>>
>> +if DRM_AUX_HPD_BRIDGE
>> +config DRM_AUX_HPD_TYPEC_BRIDGE
>> + tristate
>> + depends on TYPEC || !TYPEC
>> + default TYPEC
>> + help
>> + Simple bridge that terminates the bridge chain and provides HPD
>> + support. It build bridge on each USB-C connector device node.
>> +endif
>> +
>
> Should CONFIG_TYPEC_DP_ALTMODE select this one? Otherwise, we need to do it
> manually.
>
> $ grep -nr --include=Kconfig "select DRM_AUX_HPD_BRIDGE" .
> ./drivers/soc/qcom/Kconfig:118: select DRM_AUX_HPD_BRIDGE
> ./drivers/usb/typec/ucsi/Kconfig:88: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/ucsi/Kconfig:99: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/tcpm/Kconfig:62: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
> ./drivers/usb/typec/tcpm/Kconfig:85: select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
>
That's a fair point. But based on the previous discussion, Heikki
point out that configurations in the TYPEC subsystem should not
select configurations from DRM.
--
Best,
Chaoyi
^ permalink raw reply
* Re: [PATCH v5 3/4] drm/bridge: analogix_dp: Add validation for samsung,lane-count property
From: Damon Ding @ 2026-06-29 1:53 UTC (permalink / raw)
To: Luca Ceresoli
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, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <178249136513.1374898.11400378046460567437.b4-review@b4>
Hi Luca,
On 6/27/2026 12:29 AM, Luca Ceresoli wrote:
> On Thu, 04 Jun 2026 16:52:19 +0800, Damon Ding <damon.ding@rock-chips.com> wrote:
>
> Hello Damon,
>
>>
>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> index 7a85774aaac1..e120ef3320c1 100644
>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>> @@ -1261,8 +1262,11 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
>> */
>> of_property_read_u32(dp_node, "samsung,link-rate",
>> &video_info->max_link_rate);
>> - of_property_read_u32(dp_node, "samsung,lane-count",
>> - &video_info->max_lane_count);
>> + ret = of_property_read_u32(dp_node, "samsung,lane-count",
>> + &video_info->max_lane_count);
>> + if (ret || !drm_dp_lane_count_is_valid(video_info->max_lane_count))
>> + return dev_err_probe(dp->dev, ret ? ret : -EINVAL,
>> + "failed to parse samsung,lane-count\n");
>
> I think this report by sashiko makes sense:
>
> > sashiko-bot@kernel.org <sashiko-bot@kernel.org>:
> >
> > [Severity: High]
> > Does this make the optional and deprecated samsung,lane-count property a
> > strict requirement?
> >
> > If samsung,lane-count is absent from the device tree, of_property_read_u32()
> > returns -EINVAL. This causes the condition to evaluate to true, aborting the
> > probe with an error.
> >
> > According to the device tree bindings
> > (Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml),
> > this property is marked as deprecated and explicitly optional because the
> > lane count can be read from the monitor. Does this patch break compatibility
> > with device trees that rightfully omit this deprecated property?
>
> (via: https://patch.msgid.link/20260604090935.7FC051F00898@smtp.kernel.org)
>
> Can you comment on this?
>
>
I was also confused about this handling at first. From commit
0d0abd894ead ("drm: bridge: analogix/dp: add max link rate and lane
count limit for RK3288"), its commit message does not explain why
samsung,lane-count was changed from a mandatory to optional property.
After digging into the code flow, I found that
analogix_dp_full_link_train() picks the smaller value between the
platform-supported lane count and the lane count retrieved from sink
DPCD for link training. If the samsung,lane-count property is
missing/invalid here, link training will end up using an unexpected lane
count configuration.
Additionally, I checked Samsung’s upstream device trees that utilize
this DP controller, and all of them carry the lane-count property. Based
on this observation, I believe restoring the strict mandatory
requirement for this property makes sense.
Should I create an independent fix patch to revert these two properties
to mandatory, instead of bundling the fix in this series?
Best regards,
Damon
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-29 2:08 UTC (permalink / raw)
To: Leo Yan, Suzuki K Poulose, Mike Leach, James Clark
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Yuanfang Zhang, linux-arm-msm, devicetree,
linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <20260626154949.GA1812158@e132581.arm.com>
Hi Leo/Suzuki,
On 6/26/2026 11:49 PM, Leo Yan wrote:
> On Fri, Jun 26, 2026 at 08:09:58PM +0800, Jie Gan wrote:
>
> [...]
>
>> I have another proposal: what if we allocate the ATID in trace_noc_id() when
>> the device does not already have a valid ATID?
>>
>> Possible scenarios:
>>
>> If the itnoc device is connected to a TPDM device (which has no ATID),
>> trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and a
>> valid ATID can be allocated for the path.
>>
>> If the itnoc device is connected to sources other than TPDM, trace_noc_id()
>> will never be invoked, and therefore no ATID will be allocated for the
>> device, saving resources.
>
> TBH, I'm not sure I can make a judgement here, as I don't have enough
> knowledge of the topology. And I'm not sure whether the listed
> connections cover all possible cases.
>
> I also found commit 5799dee92dc2:
>
> | This patch adds platform driver support for the CoreSight Interconnect
> | TNOC, Interconnect TNOC is a CoreSight link that forwards trace data
> | from a subsystem to the Aggregator TNOC. Compared to Aggregator TNOC,
> | it does not have aggregation and ATID functionality.
>
> With your proposal, wouldn't ATID be allocated for the interconnect
> TNOC while being skipped for the Aggregator TNOC? That seems to
> contradict the commit log.
The ATID is allocated to the Aggregator TNOC during probe. The "WA" in
driver definitely break the original design.
Can I fix the issue by adding "arm,primecell-periphid" property. That's
would be the best temp solution as it avoids breaking the original
design of both the TraceNoC AMBA driver and interconnect TraceNoC
platform driver.
The TraceNoC device here must be treated as an AMBA device and I am
continuing to investigate the issue with our hardware team. We aim to
fix it from hardware perspetive for existing platforms if possible and
ensure it is fixed in future platforms.
Thanks,
Jie
>
> Thanks,
> Leo
^ permalink raw reply
* RE: [PATCH V3 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Sherry Sun @ 2026-06-29 2:32 UTC (permalink / raw)
To: Frank Li (OSS), Sherry Sun (OSS)
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, Amitkumar Karwar, Neeraj Sanjay Kale,
marcel@holtmann.org, luiz.dentz@gmail.com, Hongxing Zhu,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, bhelgaas@google.com,
brgl@kernel.org, imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-pm@vger.kernel.org
In-Reply-To: <aj7VpvRQxhCyPVPg@SMW015318>
> Subject: Re: [PATCH V3 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
>
> On Fri, Jun 26, 2026 at 10:31:19AM +0800, Sherry Sun (OSS) wrote:
> > From: Sherry Sun <sherry.sun@nxp.com>
> >
> > Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> > suspend to preserve wakeup capability of the devices and also not to
> > power on the devices in the init path.
>
> Need empty line here.
Ok, will fix.
>
> > This allows controller power-off to be skipped when some devices(e.g.
> > M.2 cards key E without auxiliary power) required to support PCIe L2
> > link state and wake-up mechanisms.
> >
> > Move pci_pwrctrl_create_devices() to imx_pcie_probe() so that it is
> > only called once during probe, similar to other regulator_get calls.
> >
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 43
> > ++++++++++++++++-----------
> > 1 file changed, 25 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 0fa716d1ed75..0685573fee71 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -1382,16 +1382,12 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > }
> > }
> >
> > - ret = pci_pwrctrl_create_devices(dev);
> > - if (ret) {
> > - dev_err(dev, "failed to create pwrctrl devices\n");
> > - goto err_reg_disable;
> > - }
> > -
>
> Please two patch do that. one patch move pci_pwrctrl_create_devices() to
> probe
>
> one patch check skip_power_off.
>
> > - ret = pci_pwrctrl_power_on_devices(dev);
> > - if (ret) {
> > - dev_err(dev, "failed to power on pwrctrl devices\n");
> > - goto err_pwrctrl_destroy;
> > + if (!pp->skip_pwrctrl_off) {
> > + ret = pci_pwrctrl_power_on_devices(dev);
> > + if (ret) {
> > + dev_err(dev, "failed to power on pwrctrl devices\n");
> > + goto err_reg_disable;
> > + }
> > }
> >
> > ret = imx_pcie_clk_enable(imx_pcie); @@ -1460,10 +1456,8 @@
> static
> > int imx_pcie_host_init(struct dw_pcie_rp *pp)
> > err_clk_disable:
> > imx_pcie_clk_disable(imx_pcie);
> > err_pwrctrl_power_off:
> > - pci_pwrctrl_power_off_devices(dev);
> > -err_pwrctrl_destroy:
> > - if (ret != -EPROBE_DEFER)
> > - pci_pwrctrl_destroy_devices(dev);
> > + if (!pp->skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(dev);
> > err_reg_disable:
> > if (imx_pcie->vpcie)
> > regulator_disable(imx_pcie->vpcie);
> > @@ -1482,7 +1476,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp
> *pp)
> > }
> > imx_pcie_clk_disable(imx_pcie);
> >
> > - pci_pwrctrl_power_off_devices(pci->dev);
> > + if (!pci->pp.skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(pci->dev);
> > if (imx_pcie->vpcie)
> > regulator_disable(imx_pcie->vpcie);
> > }
> > @@ -1954,11 +1949,15 @@ static int imx_pcie_probe(struct
> platform_device *pdev)
> > if (ret)
> > return ret;
> >
> > + ret = pci_pwrctrl_create_devices(dev);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "failed to create pwrctrl
> > +devices\n");
> > +
> > pci->use_parent_dt_ranges = true;
> > if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> > ret = imx_add_pcie_ep(imx_pcie, pdev);
> > if (ret < 0)
> > - return ret;
> > + goto err_pwrctrl_destroy;
> >
> > /*
> > * FIXME: Only single Device (EPF) is supported due to the
> @@
> > -1973,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device
> *pdev)
> > pci->pp.use_atu_msg = true;
> > ret = dw_pcie_host_init(&pci->pp);
> > if (ret < 0)
> > - return ret;
> > + goto err_pwrctrl_destroy;
> >
> > if (pci_msi_enabled()) {
> > u8 offset = dw_pcie_find_capability(pci,
> PCI_CAP_ID_MSI); @@
> > -1985,16 +1984,24 @@ static int imx_pcie_probe(struct platform_device
> *pdev)
> > }
> >
> > return 0;
> > +
> > +err_pwrctrl_destroy:
> > + if (ret != -EPROBE_DEFER)
> > + pci_pwrctrl_destroy_devices(dev);
> > + return ret;
>
> Mani said he will fix DEFER problem soon.
Yes, so for now I'll make a patch to move pci_pwrctrl_create_devices() into the
probe() and temporarily add the err_pwrctrl_destroy error label until Mani fixes it.
Let me know if any other suggestions, thanks!
Best Regards
Sherry
>
> Frank
>
> > }
> >
> > static void imx_pcie_shutdown(struct platform_device *pdev) {
> > struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> > + struct dw_pcie *pci = imx_pcie->pci;
> > + struct dw_pcie_rp *pp = &pci->pp;
> >
> > /* bring down link, so bootloader gets clean state in case of reboot */
> > imx_pcie_assert_core_reset(imx_pcie);
> > imx_pcie_assert_perst(imx_pcie, true);
> > - pci_pwrctrl_power_off_devices(&pdev->dev);
> > + if (!pp->skip_pwrctrl_off)
> > + pci_pwrctrl_power_off_devices(&pdev->dev);
> > pci_pwrctrl_destroy_devices(&pdev->dev);
> > }
> >
> > --
> > 2.50.1
> >
> >
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: adc: add Axiado SARADC driver
From: Petar Stepanovic @ 2026-06-29 2:33 UTC (permalink / raw)
To: David Lechner, Akhila Kavi, Prasad Bolisetty, Jonathan Cameron,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <6770a7af-06cc-4240-9b20-c299e7080ab1@baylibre.com>
On 6/28/2026 1:07 AM, David Lechner wrote:
>> +#define AX_SARADC_CH(_index, _id) \
>> + { \
>> + .type = IIO_VOLTAGE, \
>> + .indexed = 1, \
>> + .channel = (_index), \
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>> + .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
>> + .datasheet_name = (_id), \
> This could probably be:
>
> .datasheet_name = "adc" #_index,
>
> and avoid the need for _id.
Thanks for the review, David.
Yes, that makes sense. I will update this and remove the extra _id
argument.
>> + }
>> +
>> +static const struct iio_chan_spec axiado_saradc_iio_channels[] = {
>> + AX_SARADC_CH(0, "adc0"), AX_SARADC_CH(1, "adc1"),
>> + AX_SARADC_CH(2, "adc2"), AX_SARADC_CH(3, "adc3"),
>> + AX_SARADC_CH(4, "adc4"), AX_SARADC_CH(5, "adc5"),
>> + AX_SARADC_CH(6, "adc6"), AX_SARADC_CH(7, "adc7"),
>> + AX_SARADC_CH(8, "adc8"), AX_SARADC_CH(9, "adc9"),
>> + AX_SARADC_CH(10, "adc10"), AX_SARADC_CH(11, "adc11"),
>> + AX_SARADC_CH(12, "adc12"), AX_SARADC_CH(13, "adc13"),
>> + AX_SARADC_CH(14, "adc14"), AX_SARADC_CH(15, "adc15"),
> Two columns looks a bit odd.
I will also reformat the channel table to one entry per line.
>> +};
>> +
>> +static void axiado_saradc_disable(void *data)
>> +{
>> + struct axiado_saradc *info = data;
>> +
>> + writel(AX_SARADC_GLOBAL_CTRL_PD, info->regs + AX_SARADC_GLOBAL_CTRL_REG);
> People usual make read and write wrappers or use regmap to avoid having
> to write `info->regs + AX_SARADC_GLOBAL_CTRL_REG` so many times.
My understanding is that simple read/write wrappers are not always
preferred unless they provide additional value. Would switching the
driver to regmap be acceptable here to avoid repeating the base address
calculation?
Regards,
Petar
^ permalink raw reply
* [PATCH v4 0/2] i2c: imx: Fix slave mode corner issues
From: Liem @ 2026-06-29 2:38 UTC (permalink / raw)
To: carlos.song
Cc: andi.shyti, biwen.li, festevam, frank.li, frank.li, imx, kernel,
liem16213, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa
In-Reply-To: <AM0PR04MB6802B863CD9B9AE1609C1785E8EB2@AM0PR04MB6802.eurprd04.prod.outlook.com>
This series fixes two issues in the i2c-imx target mode.
Patch 1 defers slave pointer assignment to after a successful resume
and protects it with the slave_lock to prevent races with the shared
IRQ handler.
Patch 2 cancels the hrtimer before clearing the slave pointer during
unregistration, preventing a potential use-after-free.
Changes in v4:
- Patch 1: reworked to avoid race with shared IRQ handler, as
suggested by Sashiko.
- Patch 2: unchanged.
Changes in v3:
- Split the original patch into two separate patches as suggested by
Frank Li.
- v2: https://lore.kernel.org/imx/
20260625160219.55116-1-liem16213@gmail.com/
Liem (2):
i2c: imx: Fix slave registration race and error handling
i2c: imx: Cancel hrtimer before clearing slave pointer
drivers/i2c/busses/i2c-imx.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v4 1/2] i2c: imx: Fix slave registration race and error handling
From: Liem @ 2026-06-29 2:38 UTC (permalink / raw)
To: carlos.song
Cc: andi.shyti, biwen.li, festevam, frank.li, frank.li, imx, kernel,
liem16213, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa
In-Reply-To: <20260629023829.152651-1-liem16213@gmail.com>
In i2c_imx_reg_slave(), the slave pointer was assigned before
pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed,
the error path returned without clearing i2c_imx->slave, leaving it
non-NULL and causing all subsequent registration attempts to fail
with -EBUSY.
Additionally, because this driver uses a shared IRQ, the interrupt
handler i2c_imx_isr() can execute concurrently and, after acquiring
slave_lock, dereference i2c_imx->slave. The previous fix attempt
added a lockless i2c_imx->slave = NULL on the error path, but that
could race with the ISR under the lock and still cause a NULL pointer
dereference.
Fix both issues by deferring the assignment of i2c_imx->slave and
i2c_imx->last_slave_event to after a successful resume, and by
performing the assignment inside the slave_lock critical section.
This guarantees that the slave pointer is never left stale on the
error path and is always valid when observed by the interrupt handler.
Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
Cc: stable@vger.kernel.org
Signed-off-by: Liem <liem16213@gmail.com>
---
v3 -> v4:
- Instead of clearing the slave pointer on error, defer the
assignment until after pm_runtime_resume_and_get() succeeds,
and take slave_lock to avoid racing with the shared IRQ handler.
Suggested by Sashiko and Carlos Song
---
drivers/i2c/busses/i2c-imx.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 28313d0fad37..2398c406e913 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -930,9 +930,6 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
if (i2c_imx->slave)
return -EBUSY;
- i2c_imx->slave = client;
- i2c_imx->last_slave_event = I2C_SLAVE_STOP;
-
/* Resume */
ret = pm_runtime_resume_and_get(i2c_imx->adapter.dev.parent);
if (ret < 0) {
@@ -940,6 +937,11 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
return ret;
}
+ scoped_guard(spinlock_irqsave, &i2c_imx->slave_lock) {
+ i2c_imx->slave = client;
+ i2c_imx->last_slave_event = I2C_SLAVE_STOP;
+ }
+
i2c_imx_slave_init(i2c_imx);
return 0;
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/2] i2c: imx: Cancel hrtimer before clearing slave pointer
From: Liem @ 2026-06-29 2:38 UTC (permalink / raw)
To: carlos.song
Cc: andi.shyti, biwen.li, festevam, frank.li, frank.li, imx, kernel,
liem16213, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa, Carlos Song
In-Reply-To: <20260629023829.152651-1-liem16213@gmail.com>
In i2c_imx_unreg_slave(), the slave pointer is set to NULL after
disabling interrupts. However, a pending interrupt might already
have started the hrtimer (i2c_imx_slave_timeout) before the pointer
was cleared. If the hrtimer fires after i2c_imx->slave is set to
NULL, the timer callback i2c_imx_slave_finish_op() will call
i2c_imx_slave_event() with a NULL slave pointer, which results in a
use-after-free / NULL pointer dereference.
Fix by canceling the hrtimer and waiting for it to complete after
disabling interrupts, before clearing the slave pointer.
Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
Cc: stable@vger.kernel.org
Acked-by: Carlos Song <carlos.song@nxp.com>
Signed-off-by: Liem <liem16213@gmail.com>
---
v3 -> v4: No changes, added Acked-by from Carlos Song.
---
drivers/i2c/busses/i2c-imx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 2398c406e913..b1c6581db774 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -960,6 +960,7 @@ static int i2c_imx_unreg_slave(struct i2c_client *client)
i2c_imx_reset_regs(i2c_imx);
+ hrtimer_cancel(&i2c_imx->slave_timer);
i2c_imx->slave = NULL;
/* Suspend */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Chris Lu (陸稚泓) @ 2026-06-29 3:01 UTC (permalink / raw)
To: luiz.dentz@gmail.com, i@rong.moe
Cc: Will-CY Lee (李政穎), marcel@holtmann.org,
AngeloGioacchino Del Regno, SS Wu (巫憲欣),
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
patchwork-bot+bluetooth@kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <4e96132bcfb267af05c06dc277b5ba6895e3ddde.camel@rong.moe>
Hi Rong,
Thanks for your understanding. We hope to find a better way to handle
this issue.
Hi Luiz,
Regarding this issue, MediaTek Bluetooth team has already initialed an
internal investigation for problematic combination and will seek
assistance from AMD SOC team to investigate the root cause of this
issue.
However, since this change has impact on MTK products, may I submit a
patch to remove it first?
If the investigation determines the issue lies within MTK BT
driver/firmware, we'll submit a separate solution to fix it.
On Sat, 2026-06-27 at 03:56 +0800, Rong Zhang wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>
>
> Hi Chris, Luiz,
>
> On Fri, 2026-06-26 at 17:56 +0000, Chris Lu (陸稚泓) wrote:
> > Hi Rong and Luiz,
> >
> > On Fri, 2026-06-26 at 12:54 -0400, Luiz Augusto von Dentz wrote:
> > > Hi,
> > >
> > >
> > > On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
> > > >
> > > > Hi Chris,
> > > >
> > > > 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)"
> > > > <Chris.Lu@mediatek.com> 写道：
> > > > > Hi Luiz,
> > > > >
> > > > > Could we revert this change?
> > > >
> > > > Please don't. The fundamental goal of the patch is to make
> > > > MT7922/MT7925 *usable* on affected platforms.
> > > >
> > > > Moreover, almost all recent AMD platforms ship with
> > > > MT7922/MT7925,
> > > > reverting this patch affects quite a lot of users. Almost every
> > > > AMD
> > > > platform I've met suffers from the issue, and there are plenty
> > > > of
> > > > bug reports.
> > > >
> > > > Intel platforms never ship with MTK WLAN NICs, so I can't tell
> > > > if
> > > > the issue is reproducible on them.
> > >
> > We still have non-AMD platforms with MT7922/7925, where
> > "wakeup by Bluetooth" is an essential feature. In other word, this
> > change will have a serious impact to them.
>
> Oh, perhaps I missed something before. Your words were a bit unclear
> to
> me at first glance.
>
> You previous reply said "wake on Bluetooth". I interpreted it as USB
> remote wakeup upon Bluetooch device connection.
>
> "Wakeup by Bluetooth" is clearer. You meant using the Bluetooth
> interface as a wakeup source to wake up the system from sleep, right?
>
> Hmm, it makes more sense to me.
>
> My patch was inspired by commit f4292e2faf52 ("Bluetooth: btusb: Make
> the CSR clone chip force-suspend workaround more generic"). The
> mentioned commit is correct as the quirky chips can't perform remote
> wakeup at all.
>
> If MT7922/MT7925 can reliably wake up the system from sleep, my patch
> could be a burden. I won't insist anymore if you'd like to revert it.
>
> >
> > > We cannot really remove it anymore, since it has already been
> > > pulled.
> > > Therefore, I strongly prefer that the issue is fixed somehow or
> > > if
> > > there is no other way then a proper revert patch must be sent,
> > > since
> > > I
> > > don't have any hardware with this controller I cannot really test
> > > this
> > > myself.
> > >
> > Got it.
> > > > >
> > > > > Sorry, MediaTek wasn't aware someone submitted this change
> > > > > and it
> > > > > had
> > > > > already been merged.
> > > > >
> > > > > MTK believes this issue is strongly related to the platform's
> > > > > USB
> > > > > hub
> > > > > behavior,
> > > >
> > > > Still, I believe that there are some interoperability issues in
> > > > MT7922/MT7925's hardware or firmware, as reinitializing the
> > > > XHCI
> > > > root hub (by logically removing it from the PCI bus and probing
> > > > it
> > > > again) doesn't make it recover at all.
> > > >
> > > > > The product lines MTK directly support haven't reported such
> > > > > issue.
> > > >
> > > > ...or did you mean none of the existing AMD platforms are
> > > > supported
> > > > by MTK?
> > > >
> > I'll report it to corresponding department to see if they have such
> > issue. (I'm not from Bluetooth with AMD platform support team)
> >
> > > > >
> > > > > Disable wake capability would severely impact wake on
> > > > > Bluetooth
> > > > > on
> > > > > MTK's official product lines.
> > > >
> > > > Could you kindly explain "MTK's official product lines"?
> > > >
> > Some products are module makers selling our modules to downstream
> > customers directly.
> >
> > > > > Furthermore, this patch looks like a
> > > > > workaround. There should be a better way to handle this
> > > > > issue. We
> > > > > hope
> > > > > this change can be reverted.
> > > >
> > > > The issue is severe on affected platforms by making the
> > > > Bluetooth
> > > > interface completely gone. IMHO, we must figure out the "better
> > > > way" before reverting it, or else it's more like burying your
> > > > head
> > > > into sand by shouting "works fine on our platforms" (TM).
> > > >
> > > > That being said, I think we can narrow the range of the quirk
> > > > down
> > > > to AMD platforms only. Does it make sense to you? If so, I will
> > > > submit a patch for this.
> > >
> > As I mentioned above, we have many platforms using the kernel
> > driver,
> > not just AMD,
> >
> > If this change can be limited to specific platform , it would be
> > the
> > best way so far.
>
> I plan to submit another patch to properly fix it next week. In
> general,
> I will:
>
> - narrow the quirk down to AMD platforms only
> - disable USB remote wakeup for runtime autosuspend only
> - leave the wakeup source as is, so users can enable "wakeup by
> Bluetooth" even on AMD platforms if they really want it
>
> Hopefully it will minimize the impact of the workaround.
>
> Thanks,
> Rong
>
> >
> > > Ok, then you guys please coordinate. I don't want to start
> > > requiring
> > > Sign-Off-By (SOB) from driver authors because this instance shows
> > > that
> > > response time can be very long. Therefore, the best way forward
> > > in my
> > > opinion, is to have the issue fixed in a way that works for both
> > > of
> > > you.
> >
> > Of course, Mediatek BT team also agree that any issue need to be
> > resolved, However, original issue for this change requires further
> > verification of Hardware/firmware and even USB behavior. A device
> > that
> > can reproduce the issue stably is required in order to experiment
> > and
> > identify the root cause.
> >
> > As mentioned, I'll deliver internally to relate support team. If
> > they
> > have similar settings, MTK will attempt to reproduce it and provide
> > an
> > official solution.
> >
> > Thanks very much for your input and understanding.
> >
> > Best Regards,
> > Chris Lu
Thanks,
Chris Lu
^ permalink raw reply
* Re: [PATCH v14 0/7] Provide support for Trigger Generation Unit
From: Songwei.Chai @ 2026-06-29 3:03 UTC (permalink / raw)
To: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
suzuki.poulose, james.clark, krzk+dt, conor+dt, gregkh
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, Songwei Chai
In-Reply-To: <48c6abce-c492-46a6-84ef-3074983e817c@oss.qualcomm.com>
Hi Greg & Alexander,
Apologies for interrupting again.
As the TGU hardware plays an important role in Qualcomm tracing design,
I would greatly appreciate it if you could kindly take some time to
review this at your earliest convenience.
Best regards,
Songwei
On 6/5/2026 11:14 AM, Songwei.Chai wrote:
> hi Greg & Alexander,
>
> I hope this message finds you well.
>
> We are currently working on a Qualcomm TGU (Trace Generation Unit)
> driver and would like to seek your guidance on how best to integrate
> it into the /hwtracing/ subsystem.
>
> TGU is a programmable hardware block that monitors signal conditions
> and triggers debug-related actions, effectively acting as a trace
> generation utility. Based on its functionality, placing it under
> |"drivers/hwtracing"| appears to be a reasonable choice.
>
> We initially explored integrating it into
> "|drivers/hwtracing/coresight"|.However, that approach did not receive
> support, primarily because the component is not tightly coupled with
> the CoreSight subsystem.
>
> *Chat History*:
> https://lore.kernel.org/all/CAJ9a7ViKxHThyZfFFDV_FkNRimk4uo1NrMtQ-kcaj1qO4ZcGnA@mail.gmail.com/
>
> As an alternative, we are proposing to introduce a dedicated
> |"drivers/hwtracing/qcom/"|directory, similar to the existing
> "|drivers/hwtracing/intel_th"|.
> A more detailed rationale can be found in the cover letter under the
> section /"Why we are proposing this:"/.
>
> *Current status of the patch:*
>
> * Reviewed-by: Jie Gan
> * Acked-by: Konrad Dybcio
>
> We would greatly appreciate it if you could take some time to review
> this patch and share your thoughts. Your feedback would be very
> helpful in moving this effort forward in the right direction.
>
> Thanks a lot for your time and consideration.
>
> Best regards,
> Songwei
>
> On 4/17/2026 3:33 PM, Songwei Chai wrote:
>> We propose creating a new qcom directory under drivers/hwtracing
>> to host this TGU driver, as well as additional Qualcomm-specific
>> hwtracing drivers that we plan to submit in the coming months.
>> This structure will help organize vendor-specific implementations
>> and facilitate future development and maintenance.
>>
>> Feedback from the community on this proposal is highly appreciated.
>>
>> - Why we are proposing this:
>>
>> TGU has the ability to monitor signal conditions and trigger
>> debug-related
>> actions, serving as a programmable hardware component that enhances
>> system
>> trace and debug capabilities. Placing it under drivers/hwtracing aligns
>> with its function as a trace generation utility.
>>
>> We previously attempted to push this driver to
>> drivers/hwtracing/coresight,
>> but did not receive support from the maintainers of the CoreSight
>> subsystem. The reason provided was: “This component is primarily a part
>> of the Qualcomm proprietary QPMDA subsystem, and is capable of operating
>> independently from the CoreSight hardware trace generation system.”
>>
>> Chat history :
>> https://lore.kernel.org/all/CAJ9a7ViKxHThyZfFFDV_FkNRimk4uo1NrMtQ-kcaj1qO4ZcGnA@mail.gmail.com/
>>
>> Given this, we have been considering whether it would be appropriate
>> to create a dedicated drivers/hwtracing/qcom directory for
>> Qualcomm-related hwtracing drivers. This would follow the precedent set
>> by Intel, which maintains its own directory at
>> drivers/hwtracing/intel_th.
>> We believe this structure would significantly facilitate
>> future submissions of related Qualcomm drivers.
>>
>> - Maintenance of drivers/hwtracing/qcom:
>>
>> Bjorn, who maintains linux-arm-msm, will be the maintainer of this
>> directory — we’ve discussed this with him and he’s aware that his task
>> list may grow accordingly. Additionally, Qualcomm engineers familiar
>> with
>> the debug hardware — such as [Tingwei Zhang, Jinlong Mao, Songwei Chai],
>> will be available to review incoming patches and support ongoing
>> development.
>>
>> - Detail for TGU:
>>
>> This component can be utilized to sense a plurality of signals and
>> create a trigger into the CTI or generate interrupts to processors
>> once the input signal meets the conditions. We can treat the TGU’s
>> workflow as a flowsheet, it has some “steps” regions for customization.
>> In each step region, we can set the signals that we want with priority
>> in priority_group, set the conditions in each step via condition_decode,
>> and set the resultant action by condition_select. Meanwhile,
>> some TGUs (not all) also provide timer/counter functionality.
>> Based on the characteristics described above, we consider the TGU as a
>> helper in the CoreSight subsystem. Its master device is the TPDM, which
>> can transmit signals from other subsystems, and we reuse the existing
>> ports mechanism to link the TPDM to the connected TGU.
>>
>> Here is a detailed example to explain how to use the TGU:
>>
>> In this example, the TGU is configured to use 2 conditions, 2 steps, and
>> the timer. The goal is to look for one of two patterns which are
>> generated
>> from TPDM, giving priority to one, and then generate a trigger once the
>> timer reaches a certain value. In other words, two conditions are used
>> for the first step to look for the two patterns, where the one with the
>> highest priority is used in the first condition. Then, in the second
>> step,
>> the timer is enabled and set to be compared to the given value at each
>> clock cycle. These steps are better shown below.
>> |-----------------|
>> | |
>> | TPDM |
>> | |
>> |-----------------|
>> |
>> |
>> --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
>> ------
>> | | |
>> | | |--------------------| |
>> | |---- ---> | | Go to next
>> steps | |
>> | | | |--- ---> | Enable
>> timer | |
>> | | v | | | |
>> | | |-----------------| | |--------------------| |
>> | | | | Yes | | |
>> | | | inputs==0xB | ----->| | <-------- |
>> | | | | | | No | |
>> | No | |-----------------| | v | |
>> | | | | |-----------------| | |
>> | | | | | | | |
>> | | | | | timer>=3 |-- |
>> | | v | | | |
>> | | |-----------------| | |-----------------| |
>> | | | | Yes | | |
>> | |--- | inputs==0xA | ----->| | Yes |
>> | | | | |
>> | |-----------------| v |
>> | |-----------------| |
>> | | | |
>> | | Trigger | |
>> | | | |
>> | |-----------------| |
>> | TGU | |
>> |--- --- --- --- --- --- --- --- --- --- --- --- --- --- |---
>> --- -- |
>> |
>> v
>> |-----------------|
>> |The controllers |
>> |which will use |
>> |triggers further |
>> |-----------------|
>>
>> steps:
>> 1. Reset TGU /*it will disable tgu and reset dataset*/
>> - echo 1 > /sys/bus/amba/devices/<tgu-name>/reset_tgu
>>
>> 2. Set the pattern match for priority0 to 0xA = 0b1010 and for
>> priority 1 to 0xB = 0b1011.
>> - echo 0x11113232 >
>> /sys/bus/amba/devices/<tgu-name>/step0_priority0/reg0
>> - echo 0x11113233 >
>> /sys/bus/amba/devices/<tgu-name>/step0_priority1/reg0
>>
>> Note:
>> Bit distribution diagram for each priority register
>> |-------------------------------------------------------------------|
>> | Bits | Field Nam | Description |
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 29:28 | SEL_BIT7_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 25:24 | SEL_BIT6_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 21:20 | SEL_BIT5_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 17:16 | SEL_BIT4_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 13:12 | SEL_BIT3_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 9:8 | SEL_BIT2_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 5:4 | SEL_BIT1_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> | | | 00 = bypass for OR
>> output |
>> | 1:0 | SEL_BIT0_TYPE2 | 01 = bypass for AND
>> output |
>> | | | 10 = sense input '0' is
>> true|
>> | | | 11 = sense input '1' is
>> true|
>> |-------------------------------------------------------------------|
>> These bits are used to identify the signals we want to sense, with
>> a maximum signal number of 140. For example, to sense the signal
>> 0xA (binary 1010), we set the value of bits 0 to 13 to 3232, which
>> represents 1010. The remaining bits are set to 1, as we want to use
>> AND gate to summarize all the signals we want to sense here. For
>> rising or falling edge detection of any input to the priority, set
>> the remaining bits to 0 to use an OR gate.
>>
>> 3. look for the pattern for priority_i i=0,1.
>> - echo 0x3 >
>> /sys/bus/amba/devices/<tgu-name>/step0_condition_decode/reg0
>> - echo 0x30 >
>> /sys/bus/amba/devices/<tgu-name>/step0_condition_decode/reg1
>>
>> |-------------------------------------------------------------------------------|
>> | Bits | Field Nam |
>> Description |
>> |-------------------------------------------------------------------------------|
>> | | |For each decoded
>> condition, this |
>> | 24 | NOT |inverts the output. If
>> the condition |
>> | | |decodes to true, and
>> the NOT field |
>> | | |is '1', then the output
>> is NOT true. |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | 21 | BC0_COMP_ACTIVE |comparator will be
>> actively included in|
>> | | |the decoding of this
>> particular |
>> | | |condition. |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | | |comparator will need to
>> be 1 to affect |
>> | 20 | BC0_COMP_HIGH |the decoding of this
>> condition. |
>> | | |Conversely, a '0' here
>> requires a '0' |
>> | | |from the
>> comparator |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | 17 | |comparator will be
>> actively included in|
>> | | TC0_COMP_ACTIVE |the decoding of this
>> particular |
>> | | |condition. |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | | |comparator will need to
>> be 1 to affect |
>> | 16 | TC0_COMP_HIGH |the decoding of this
>> particular |
>> | | |condition.Conversely, a 0 here |
>> | | |requires a '0' from the
>> comparator |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from Priority_n |
>> | | |OR logic will be
>> actively |
>> | 4n+3 | Priority_n_OR_ACTIVE|included in the
>> decoding of |
>> | | (n=0,1,2,3) |this particular
>> condition. |
>> | | | |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from Priority_n |
>> | | |will need to be '1' to
>> affect the |
>> | 4n+2 | Priority_n_OR_HIGH |decoding of this
>> particular |
>> | | (n=0,1,2,3) |condition. Conversely,
>> a '0' here |
>> | | |requires a '0' from
>> Priority_n OR logic|
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from Priority_n |
>> | | |AND logic will be
>> actively |
>> | 4n+1 |Priority_n_AND_ACTIVE|included in the
>> decoding of this |
>> | | (n=0,1,2,3) |particular
>> condition. |
>> | | | |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from Priority_n |
>> | | |AND logic will need to
>> be '1' to |
>> | 4n | Priority_n_AND_HIGH |affect the decoding of
>> this |
>> | | (n=0,1,2,3) |particular condition.
>> Conversely, |
>> | | |a '0' here requires a
>> '0' from |
>> | | |Priority_n AND
>> logic. |
>> |-------------------------------------------------------------------------------|
>> Since we use `priority_0` and `priority_1` with an AND output in
>> step 2, we set `0x3`
>> and `0x30` here to activate them.
>>
>> 4. Set NEXT_STEP = 1 and TC0_ENABLE = 1 so that when the conditions
>> are met then the next step will be step 1 and the timer will
>> be enabled.
>> - echo 0x20008 >
>> /sys/bus/amba/devices/<tgu-name>/step0_condition_select/reg0
>> - echo 0x20008 >
>> /sys/bus/amba/devices/<tgu-name>/step0_condition_select/reg1
>>
>> |-----------------------------------------------------------------------------|
>> | Bits | Field Nam |
>> Description |
>> |-----------------------------------------------------------------------------|
>> | | |This field defines the
>> next step the |
>> | 18:17 | NEXT_STEP |TGU will 'goto' for the
>> associated |
>> | | |Condition and
>> Step. |
>> |-----------------------------------------------------------------------------|
>> | | |For each possible output
>> trigger |
>> | 13 | TRIGGER |available, set a '1' if
>> you want |
>> | | |the trigger to go active
>> for the |
>> | | |associated condition and
>> Step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will cause BC0 to
>> increment if the|
>> | 9 | BC0_INC |associated Condition is
>> decoded for |
>> | | |this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will cause BC0 to
>> decrement if the|
>> | 8 | BC0_DEC |associated Condition is
>> decoded for |
>> | | |this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will clear BC0 count
>> value to 0 if|
>> | 7 | BC0_CLEAR |the associated Condition
>> is decoded |
>> | | |for this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will cause TC0 to
>> increment until |
>> | 3 | TC0_ENABLE |paused or cleared if the
>> associated |
>> | | |Condition is decoded for
>> this step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will cause TC0 to
>> pause until |
>> | 2 | TC0_PAUSE |enabled if the associated
>> Condition |
>> | | |is decoded for this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will clear TC0 count
>> value to 0 |
>> | 1 | TC0_CLEAR |if the associated
>> Condition is |
>> | | |decoded for this
>> step. |
>> |-----------------------------------------------------------------------------|
>> | | |This will set the done
>> signal to the |
>> | 0 | DONE |TGU FSM if the associated
>> Condition |
>> | | |is decoded for this
>> step. |
>> |-----------------------------------------------------------------------------|
>> Based on the distribution diagram, we set `0x20008` for
>> `priority0` and `priority1` to
>> achieve "jump to step 1 and enable TC0" once the signal is sensed.
>>
>> 5. activate the timer comparison for this step.
>> - echo 0x30000 >
>> /sys/bus/amba/devices/<tgu-name>/step1_condition_decode/reg0
>>
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | 17 | |comparator will be
>> actively included in|
>> | | TC0_COMP_ACTIVE |the decoding of this
>> particular |
>> | | |condition. |
>> |-------------------------------------------------------------------------------|
>> | | |When '1' the output
>> from the associated|
>> | | |comparator will need to
>> be 1 to affect |
>> | 16 | TC0_COMP_HIGH |the decoding of this
>> particular |
>> | | |condition.Conversely, a 0 here |
>> | | |requires a '0' from the
>> comparator |
>> |-------------------------------------------------------------------------------|
>> Accroding to the decode distribution diagram , we give 0x30000
>> here to set 16th&17th bit
>> to enable timer comparison.
>>
>> 6. Set the NEXT_STEP = 0 and TC0_PAUSE = 1 and TC0_CLEAR = 1
>> once the timer
>> has reached the given value.
>> - echo 0x6 >
>> /sys/bus/amba/devices/<tgu-name>/step1_condition_select/reg0
>>
>> 7. Enable Trigger 0 for TGU when the condition 0 is met in step1,
>> i.e. when the timer reaches 3.
>> - echo 0x2000 >
>> /sys/bus/amba/devices/<tgu-name>/step1_condition_select/default
>>
>> Note:
>> 1. 'default' register allows for establishing the resultant
>> action for
>> the default condition
>>
>> 2. Trigger:For each possible output trigger available from
>> the Design document, there are three triggers: interrupts, CTI,
>> and Cross-TGU mapping.All three triggers can occur, but
>> the choice of which trigger to use depends on the user's
>> needs.
>>
>> 8. Compare the timer to 3 in step 1.
>> - echo 0x3 > /sys/bus/amba/devices/<tgu-name>/step1_timer/reg0
>>
>> 9. enale tgu
>> - echo 1 > /sys/bus/amba/devices/<tgu-name>/enable_tgu
>> ---
>> Link to V13:
>> https://lore.kernel.org/all/20260402092838.341295-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V14:
>> - Fix some typos and formatting.
>> ---
>> Link to V12:
>> https://lore.kernel.org/all/20260317032639.2393221-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V13:
>> - add ":" after "KernelVersion"
>> - add an enablement check in the enable function to avoid increasing
>> the counter each time
>> ---
>> Link to V11:
>> https://lore.kernel.org/all/ee1ca8e6-8e5f-47d8-8a24-f904ee2fc6d0@oss.qualcomm.com/
>>
>> Changes in V12:
>> - Remove the in-ports property from the bindings, as this device is
>> decoupled from CoreSight.
>> - Update kernel version and date.
>> ---
>> Link to V10:
>> https://lore.kernel.org/all/20c5406d-3e9f-4fdb-84ba-4cbe629c79b5@oss.qualcomm.com/
>>
>> Changes in V11:
>> - Change the names of members in drvdata: max_xxx -> num_xxx, enable
>> -> enabled
>> - Use "FIELD_GET" to replace "BMVAL"
>> - Use devm_kcalloc to replace devm_kzalloc once create members of
>> value_table
>> - Keep a consistent \n above return
>> - Keep reverse-Christmas-tree style
>> - Add checks so that the enable and reset nodes only accept 0 or 1
>> ---
>> Link to V9:
>> https://lore.kernel.org/all/20251219065902.2296896-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V10:
>> - Modified code formatting based on Jie's feedback to improve
>> readability.
>> - Applied inverse Christmas tree order to the variables.
>> ---
>> Link to V8:
>> https://lore.kernel.org/all/20251203090055.2432719-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V9:
>> - Decoupled the tgu driver from coresight header file and registered
>> it as an amba device.
>> - Retained Rob's reviewed-by tag on patch1/7 since the file remains
>> unchanged.
>> - Updated the sysfs node path in the Documentation directory.
>> ---
>> Link to V7:
>> https://lore.kernel.org/all/20251104064043.88972-1-songwei.chai@oss.qualcomm.com/
>>
>> Changes in V8:
>> - Add "select" section in bindings.
>> - Update publish date in "sysfs-bus-coresight-devices-tgu".
>> ---
>> Link to V6:
>> https://lore.kernel.org/all/20250709104114.22240-1-songchai@qti.qualcomm.com/
>>
>> Changes in V7:
>> - Move the TGU code location from 'drivers/hwtracing/coresight/' to
>> 'drivers/hwtracing/qcom/'.
>> - Rename the spinlock used in the code from 'spinlock' to 'lock'.
>> - Perform the 'calculate_array_location' separately, instead of doing
>> it within the function.
>> - Update the sender email address.
>> ---
>> Link to V5:
>> https://lore.kernel.org/all/20250529081949.26493-1-quic_songchai@quicinc.com/
>>
>> Changes in V6:
>> - Replace spinlock with guard(spinlock) in tgu_enable.
>> - Remove redundant blank line.
>> - Update publish date and contact member's name in
>> "sysfs-bus-coresight-devices-tgu".
>> ---
>> Link to V4:
>> https://patchwork.kernel.org/project/linux-arm-msm/cover/20250423101054.954066-1-quic_songchai@quicinc.com/
>>
>> Changes in V5:
>> - Update publish date and kernel_version in
>> "sysfs-bus-coresight-devices-tgu"
>> ---
>> Link to V3:
>> https://lore.kernel.org/all/20250227092640.2666894-1-quic_songchai@quicinc.com/
>>
>> Changes in V4:
>> - Add changlog in coverletter.
>> - Correct 'year' in Copyright in patch1.
>> - Correct port mechansim description in patch1.
>> - Remove 'tgu-steps','tgu-regs','tgu-conditions','tgu-timer-counters'
>> from dt-binding
>> and set them through reading DEVID register as per Mike's suggestion.
>> - Modify tgu_disable func to make it have single return point in
>> patch2 as per
>> Mike's suggestion.
>> - Use sysfs_emit in enable_tgu_show func in ptach2.
>> - Remove redundant judgement in enable_tgu_store in patch2.
>> - Correct typo in description in patch3.
>> - Set default ret as SYSFS_GROUP_INVISIBLE, and returnret at end in
>> pacth3 as
>> per Mike's suggestion.
>> - Remove tgu_dataset_ro definition in patch3
>> - Use #define constants with explanations of what they are rather than
>> arbitrary magic numbers in patch3 and patch4.
>> - Check -EINVAL before using 'calculate_array_location()' in array in
>> patch4.
>> - Add 'default' in 'tgu_dataset_show''s switch part in patch4.
>> - Document the value needed to initiate the reset in pacth7.
>> - Check "value" in 'reset_tgu_store' and bail out with an error code
>> if 0 in patch7.
>> - Remove dev_dbg in 'reset_tgu_store' in patch7.
>> ---
>> Link to V2:
>> https://lore.kernel.org/all/20241010073917.16023-1-quic_songchai@quicinc.com/
>>
>> Changes in V3:
>> - Correct typo and format in dt-binding in patch1
>> - Rebase to the latest kernel version
>> ---
>> Link to V1:
>> https://lore.kernel.org/all/20240830092311.14400-1-quic_songchai@quicinc.com/
>>
>> Changes in V2:
>> - Use real name instead of login name,
>> - Correct typo and format in dt-binding and code.
>> - Bring order in tgu_prob(declarations with and without
>> assignments) as per
>> Krzysztof's suggestion.
>> - Add module device table in patch2.
>> - Set const for tgu_common_grp and tgu_ids in patch2.
>> - Initialize 'data' in tgu_ids to fix the warning in pacth2.
>> ---
>> Songwei Chai (7):
>> dt-bindings: arm: Add support for Qualcomm TGU trace
>> qcom-tgu: Add TGU driver
>> qcom-tgu: Add signal priority support
>> qcom-tgu: Add TGU decode support
>> qcom-tgu: Add support to configure next action
>> qcom-tgu: Add timer/counter functionality for TGU
>> qcom-tgu: Add reset node to initialize
>>
>> .../ABI/testing/sysfs-bus-amba-devices-tgu | 51 ++
>> .../devicetree/bindings/arm/qcom,tgu.yaml | 71 ++
>> drivers/Makefile | 1 +
>> drivers/hwtracing/Kconfig | 2 +
>> drivers/hwtracing/qcom/Kconfig | 20 +
>> drivers/hwtracing/qcom/Makefile | 3 +
>> drivers/hwtracing/qcom/tgu.c | 704 ++++++++++++++++++
>> drivers/hwtracing/qcom/tgu.h | 275 +++++++
>> 8 files changed, 1127 insertions(+)
>> create mode 100644
>> Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> create mode 100644 Documentation/devicetree/bindings/arm/qcom,tgu.yaml
>> create mode 100644 drivers/hwtracing/qcom/Kconfig
>> create mode 100644 drivers/hwtracing/qcom/Makefile
>> create mode 100644 drivers/hwtracing/qcom/tgu.c
>> create mode 100644 drivers/hwtracing/qcom/tgu.h
>>
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Joey Lu @ 2026-06-29 3:47 UTC (permalink / raw)
To: Icenowy Zheng, Conor Dooley
Cc: Conor Dooley, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <9456bde5059bea3aac1ed64355e3f017dd9bd3e5.camel@iscas.ac.cn>
On 6/26/2026 5:33 PM, Icenowy Zheng wrote:
> 在 2026-06-26五的 10:26 +0100，Conor Dooley写道：
>> On Fri, Jun 26, 2026 at 05:00:35PM +0800, Icenowy Zheng wrote:
>>> 在 2026-06-26五的 08:19 +0100，Conor Dooley写道：
>>>> On Fri, Jun 26, 2026 at 01:27:21PM +0800, Icenowy Zheng wrote:
>>>>> 在 2026-06-25四的 17:33 +0100，Conor Dooley写道：
>>>>>> On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
>>>>>>> +allOf:
>>>>>>> + - if:
>>>>>>> + properties:
>>>>>>> + compatible:
>>>>>>> + contains:
>>>>>>> + const: thead,th1520-dc8200
>>>>>>> + then:
>>>>>>> + properties:
>>>>>>> + clocks:
>>>>>>> + minItems: 5
>>>>>>> + maxItems: 5
>>>>>>> +
>>>>>>> + clock-names:
>>>>>>> + minItems: 5
>>>>>>> + maxItems: 5
>>>>>> All the maxItems here repeat the maximum constraint and do
>>>>>> nothing.
>>>>>>
>>>>>> Since you didn't change the minimum constraint at the top
>>>>>> level,
>>>>>> your
>>>>>> minItems also do nothing.
>>>>>>
>>>>>>> +
>>>>>>> + resets:
>>>>>>> + minItems: 3
>>>>>>> + maxItems: 3
>>>>>>> +
>>>>>>> + reset-names:
>>>>>>> + minItems: 3
>>>>>>> + maxItems: 3
>>>>>>> +
>>>>>>> + required:
>>>>>>> + - resets
>>>>>>> + - reset-names
>>>>>> Both conditional sections have this, but the original binding
>>>>>> doesn't
>>>>>> require these for the thead device. This is a functional
>>>>>> change
>>>>>> therefore and shouldn't be in a patch calling itself
>>>>>> "generalise
>>>>>> for
>>>>>> single ended variants".
>>>>> Well yes they're required.
>>>>>
>>>>> Should I send a patch adding the `thead,th1520-dc8200` part of
>>>>> the
>>>>> schema?
>>>> If you mean the code above, no. Adding a conditional section when
>>>> there's only that compatible doesn't make sense.
>>>>
>>>> What you could do is just add it at the top level though, which
>>>> would
>>>> also benefit this patch since it'd not have to be conditionally
>>>> added
>>>> for the new nuvoton device.
>>>> Just note in your commit message about what the ABI impact of the
>>>> change
>>>> to required properties is (effectively nothing because it's
>>>> optional
>>>> in
>>>> the driver and the only user has the properties).
>>> Okay, I will craft such a patch and send it.
>>>
>>>>>>> +
>>>>>>> + resets:
>>>>>>> + minItems: 1
>>>>>>> + maxItems: 1
>>>>>>> +
>>>>>>> + reset-names:
>>>>>>> + items:
>>>>>>> + - const: core
>>>>>> This is just maxItems: 1.
>>>>> Well the implicit rules of DT binding schemas are quite
>>>>> weird...
>>>> I don't think it is that strange, as the binding has
>>>> reset-names:
>>>> items:
>>>> - const: core
>>>> - const: axi
>>>> - const: ahb
>>> Ah does the list constraint the order of items? If it constrains
>>> the
>> It does, yes.
>> Alternatively, using an enum permits free ordering.
> Ah in this case this should be converted to an enum, I think.
>
> Should I send a patch for converting it?
>
> Thanks,
> Icenowy
Thank you all for the detailed review and discussion, it really helped
clarify the right approach.
Since I will supply all four clocks with the same phandle for core/axi/ahb,
and only one reset "core" for MA35D1, the ordering constraint in the
`items` list is not a problem, "core" is already the first entry. There
is no need to convert to an enum.
Regarding the clock situation for the MA35D1: I agree with supplying all
four clocks (core, axi, ahb, pix0) in the devicetree, even though the
MA35D1 clock controller gates core/axi/ahb with a single bit. The DT will
use the same clock phandle for core, axi, and ahb:
clocks = <&clk X>, <&clk X>, <&clk X>, <&pix_clk Y>;
clock-names = "core", "axi", "ahb", "pix0";
This correctly models the hardware topology. Since all three names resolve
to the same underlying clock node, the CCF's standard enable refcounting
handles the shared gate correctly without any custom implementation needed.
I will also revert the change in patch 4/7 that made axi and ahb clocks
optional, since they will now always be provided in the devicetree.
Regarding moving `resets` and `reset-names` to the top-level `required:`,
I will wait for Icenowy's patch to land before sending v6 to avoid
duplicating the work.
In v6 I will update patch 1/7 with:
- Update the subject to "dt-bindings: display: verisilicon,dc: add
support for nuvoton,ma35d1-dcu"
- Lower `clocks`/`clock-names` `minItems` to 4 at the top level
- Remove the `thead,th1520-dc8200` conditional block entirely
- Keep only the `nuvoton,ma35d1-dcu` conditional block, using only
`maxItems: 4` for clocks/clock-names and `maxItems: 1` for
resets/reset-names to tighten the top-level constraints
BR,
Joey
>>> order, it partly breaks the intention of having names; if it does
>>> not
>>> constrain the order, it needs to be clarified that the required 1
>>> reset
>>> is core instead of the other two.
>> Given the discussion we're having on the clocks, I wonder if this is
>> also an oversimplification and the IP has three resets inputs hooked
>> up
>> to one output of the reset controller (or 3 outputs controlled by one
>> bit..).
^ permalink raw reply
* Re: [PATCH v5 4/7] drm/verisilicon: make axi and ahb clocks optional
From: Joey Lu @ 2026-06-29 3:48 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <cf9af38dfe52548649b9010f298341d4064aaa21.camel@iscas.ac.cn>
On 6/26/2026 4:03 PM, Icenowy Zheng wrote:
> 在 2026-06-25四的 17:44 +0800，Joey Lu写道：
>> The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller
>> whose
>> AXI and AHB bus clocks share a single gate enable bit with the
>> display
>> core clock, so the clock driver does not expose them separately. This
>> patch makes the axi and ahb clocks optional in the probe.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ```
> Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ```
>
> Thanks,
> Icenowy
Thank you for the review. I will revert this patch entirely. As discussed
in the binding review, axi and ahb clocks will now always be supplied in
the devicetree using the same phandle as the core clock gate, so making
them optional in the driver is no longer needed.
>> ---
>> drivers/gpu/drm/verisilicon/vs_dc.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index 9729b693d360..fd1f5fe67a68 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> return PTR_ERR(dc->core_clk);
>> }
>>
>> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
>> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
>> if (IS_ERR(dc->axi_clk)) {
>> dev_err(dev, "can't get axi clock\n");
>> return PTR_ERR(dc->axi_clk);
>> }
>>
>> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
>> + dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
>> if (IS_ERR(dc->ahb_clk)) {
>> dev_err(dev, "can't get ahb clock\n");
>> return PTR_ERR(dc->ahb_clk);
^ permalink raw reply
* Re: [PATCH v5 3/7] drm/verisilicon: introduce per-variant hardware ops table
From: Joey Lu @ 2026-06-29 3:52 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <c842f858313732bd774abd2840cc97f730ac2e9f.camel@iscas.ac.cn>
On 6/26/2026 4:02 PM, Icenowy Zheng wrote:
> 在 2026-06-25四的 17:44 +0800，Joey Lu写道：
>> The DC8200 and DCUltraLite share a broadly similar register layout
>> but
>> differ in how the bridge, CRTC, primary plane and IRQ paths are
>> driven.
>> Introduce a vs_dc_funcs vtable so each variant can supply its own
>> implementation without scattering conditionals across multiple files.
>>
>> Add a generation field to struct vs_chip_identity to distinguish
>> variants.
>> Extract the DC8200-specific hardware ops into vs_dc8200.c and add
>> unified
>> IRQ bit definitions so implementations can translate hardware-
>> specific
>> bits to a common set. Update the shared code to dispatch through
>> dc->funcs.
>>
>> No behaviour change for existing DC8200 platforms.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> drivers/gpu/drm/verisilicon/Makefile | 2 +-
>> drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
>> drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
>> drivers/gpu/drm/verisilicon/vs_dc.c | 6 +-
>> drivers/gpu/drm/verisilicon/vs_dc.h | 32 +++++
>> drivers/gpu/drm/verisilicon/vs_dc8200.c | 115
>> ++++++++++++++++++
>> drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
>> drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
>> drivers/gpu/drm/verisilicon/vs_hwdb.c | 4 +
>> drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
>> .../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
>> 11 files changed, 214 insertions(+), 54 deletions(-)
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
>>
>> diff --git a/drivers/gpu/drm/verisilicon/Makefile
>> b/drivers/gpu/drm/verisilicon/Makefile
>> index 426f4bcaa834..9d4cd16452fa 100644
>> --- a/drivers/gpu/drm/verisilicon/Makefile
>> +++ b/drivers/gpu/drm/verisilicon/Makefile
>> @@ -1,6 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>>
>> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_drm.o
>> vs_hwdb.o \
>> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_drm.o vs_hwdb.o \
>> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>>
>> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
>> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
>> b/drivers/gpu/drm/verisilicon/vs_bridge.c
>> index dc7c85b07fe3..3fbc8d57f8a1 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
>> @@ -162,15 +162,8 @@ static void vs_bridge_enable_common(struct
>> vs_crtc *crtc,
>> VSDC_DISP_PANEL_CONFIG_DE_EN |
>> VSDC_DISP_PANEL_CONFIG_DAT_EN |
>> VSDC_DISP_PANEL_CONFIG_CLK_EN);
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> - VSDC_DISP_PANEL_CONFIG_RUNNING);
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_RUNNING(output));
>> -
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>> id),
>> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +
>> + dc->funcs->panel_enable_ex(dc, output);
>> }
>>
>> static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
>> @@ -228,14 +221,7 @@ static void vs_bridge_atomic_disable(struct
>> drm_bridge *bridge,
>> struct vs_dc *dc = crtc->dc;
>> unsigned int output = crtc->id;
>>
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
>> - VSDC_DISP_PANEL_START_RUNNING(output));
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> - VSDC_DISP_PANEL_CONFIG_RUNNING);
>> -
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>> id),
>> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> + dc->funcs->panel_disable_ex(dc, output);
>> }
>>
>> static const struct drm_bridge_funcs vs_dpi_bridge_funcs = {
>> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
>> b/drivers/gpu/drm/verisilicon/vs_crtc.c
>> index 0b8a35d09cd2..1c4aac708669 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_crtc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
>> @@ -16,10 +16,33 @@
>> #include "vs_crtc_regs.h"
>> #include "vs_crtc.h"
>> #include "vs_dc.h"
>> -#include "vs_dc_top_regs.h"
>> #include "vs_drm.h"
>> #include "vs_plane.h"
>>
>> +static void vs_crtc_atomic_begin(struct drm_crtc *crtc,
>> + struct drm_atomic_commit *state)
>> +{
>> + struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> + struct vs_dc *dc = vcrtc->dc;
>> + unsigned int output = vcrtc->id;
>> +
>> + if (dc->funcs->crtc_begin)
>> + dc->funcs->crtc_begin(dc, output);
>> +}
>> +
>> +static void vs_crtc_atomic_flush(struct drm_crtc *crtc,
>> + struct drm_atomic_commit *state)
>> +{
>> + struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> + struct vs_dc *dc = vcrtc->dc;
>> + unsigned int output = vcrtc->id;
>> +
>> + if (dc->funcs->crtc_flush)
>> + dc->funcs->crtc_flush(dc, output);
>> +
>> + drm_crtc_vblank_atomic_flush(crtc, state);
>> +}
>> +
>> static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
>> struct drm_atomic_commit *state)
>> {
>> @@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc
>> *crtc,
>> drm_crtc_vblank_off(crtc);
>>
>> clk_disable_unprepare(dc->pix_clk[output]);
>> +
>> + if (dc->funcs->crtc_disable_ex)
>> + dc->funcs->crtc_disable_ex(dc, output);
>> }
>>
>> static void vs_crtc_atomic_enable(struct drm_crtc *crtc,
>> @@ -42,6 +68,9 @@ static void vs_crtc_atomic_enable(struct drm_crtc
>> *crtc,
>> drm_WARN_ON(&dc->drm_dev->base,
>> clk_prepare_enable(dc->pix_clk[output]));
>>
>> + if (dc->funcs->crtc_enable_ex)
>> + dc->funcs->crtc_enable_ex(dc, output);
>> +
>> drm_crtc_vblank_on(crtc);
>> }
>>
>> @@ -119,7 +148,8 @@ static bool vs_crtc_mode_fixup(struct drm_crtc
>> *crtc,
>> }
>>
>> static const struct drm_crtc_helper_funcs vs_crtc_helper_funcs = {
>> - .atomic_flush = drm_crtc_vblank_atomic_flush,
>> + .atomic_begin = vs_crtc_atomic_begin,
>> + .atomic_flush = vs_crtc_atomic_flush,
>> .atomic_enable = vs_crtc_atomic_enable,
>> .atomic_disable = vs_crtc_atomic_disable,
>> .mode_set_nofb = vs_crtc_mode_set_nofb,
>> @@ -132,7 +162,7 @@ static int vs_crtc_enable_vblank(struct drm_crtc
>> *crtc)
>> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>> + dc->funcs->enable_vblank(dc, vcrtc->id);
>>
>> return 0;
>> }
>> @@ -142,7 +172,7 @@ static void vs_crtc_disable_vblank(struct
>> drm_crtc *crtc)
>> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>> + dc->funcs->disable_vblank(dc, vcrtc->id);
>> }
>>
>> static const struct drm_crtc_funcs vs_crtc_funcs = {
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index dad9967bc10b..9729b693d360 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -8,9 +8,7 @@
>> #include <linux/of.h>
>> #include <linux/of_graph.h>
>>
>> -#include "vs_crtc.h"
>> #include "vs_dc.h"
>> -#include "vs_dc_top_regs.h"
>> #include "vs_drm.h"
>> #include "vs_hwdb.h"
>>
>> @@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void
>> *private)
>> struct vs_dc *dc = private;
>> u32 irqs;
>>
>> - regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
>> + irqs = dc->funcs->irq_ack(dc);
>>
>> vs_drm_handle_irq(dc, irqs);
>>
>> @@ -136,6 +134,8 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
>>> identity.model,
>> dc->identity.revision, dc->identity.customer_id);
>>
>> + dc->funcs = &vs_dc8200_funcs;
>> +
>> if (port_count > dc->identity.display_count) {
>> dev_err(dev, "too many downstream ports than HW
>> capability\n");
>> ret = -EINVAL;
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
>> b/drivers/gpu/drm/verisilicon/vs_dc.h
>> index ed1016f18758..825f5dd6bf17 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
>> @@ -14,6 +14,7 @@
>> #include <linux/reset.h>
>>
>> #include <drm/drm_device.h>
>> +#include <drm/drm_plane.h>
>>
>> #include "vs_hwdb.h"
>>
>> @@ -22,6 +23,34 @@
>>
>> struct vs_drm_dev;
>> struct vs_crtc;
>> +struct vs_dc;
>> +
>> +struct vs_dc_funcs {
>> + /* Bridge: atomic_enable, atomic_disable */
>> + void (*panel_enable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*panel_disable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* CRTC: atomic_begin, atomic_flush */
>> + void (*crtc_begin)(struct vs_dc *dc, unsigned int output);
>> + void (*crtc_flush)(struct vs_dc *dc, unsigned int output);
>> +
>> + /* CRTC: atomic_enable, atomic_disable */
>> + void (*crtc_enable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*crtc_disable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* CRTC: enable_vblank, disable_vblank */
>> + void (*enable_vblank)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*disable_vblank)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* Primary plane: atomic_enable, atomic_disable,
>> atomic_update */
>> + void (*primary_plane_enable_ex)(struct vs_dc *dc, unsigned
>> int output);
>> + void (*primary_plane_disable_ex)(struct vs_dc *dc, unsigned
>> int output);
>> + void (*primary_plane_update_ex)(struct vs_dc *dc, unsigned
>> int output,
>> + struct drm_plane_state
>> *state);
>> +
>> + /* IRQ acknowledge */
>> + u32 (*irq_ack)(struct vs_dc *dc);
>> +};
>>
>> struct vs_dc {
>> struct regmap *regs;
>> @@ -33,6 +62,9 @@ struct vs_dc {
>>
>> struct vs_drm_dev *drm_dev;
>> struct vs_chip_identity identity;
>> + const struct vs_dc_funcs *funcs;
>> };
>>
>> +extern const struct vs_dc_funcs vs_dc8200_funcs;
>> +
>> #endif /* _VS_DC_H_ */
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> b/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> new file mode 100644
>> index 000000000000..17378f4ef96d
>> --- /dev/null
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> @@ -0,0 +1,115 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2025 Icenowy Zheng <uwu@icenowy.me>
>> + */
>> +
>> +#include <linux/regmap.h>
>> +
>> +#include "vs_bridge_regs.h"
>> +#include "vs_dc.h"
>> +#include "vs_dc_top_regs.h"
>> +#include "vs_drm.h"
>> +#include "vs_plane.h"
>> +#include "vs_primary_plane_regs.h"
>> +
>> +static void vs_dc8200_panel_enable_ex(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> + VSDC_DISP_PANEL_CONFIG_RUNNING);
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_RUNNING(output));
>> +
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
>> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_panel_disable_ex(struct vs_dc *dc, unsigned
>> int output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> + VSDC_DISP_PANEL_CONFIG_RUNNING);
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
>> + VSDC_DISP_PANEL_START_RUNNING(output));
>> +
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
>> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_enable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> + VSDC_TOP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dc8200_disable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> + VSDC_TOP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dc8200_plane_commit(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_enable_ex(struct vs_dc *dc,
>> unsigned int output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_FB_EN);
>> + regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
>> + VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_disable_ex(struct vs_dc *dc,
>> unsigned int output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_FB_EN);
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_update_ex(struct vs_dc *dc,
>> unsigned int output,
>> + struct drm_plane_state
>> *state)
>> +{
>> + regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
>> + VSDC_MAKE_PLANE_POS(state->crtc_x, state-
>>> crtc_y));
>> + regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
>> + VSDC_MAKE_PLANE_POS(state->crtc_x + state-
>>> crtc_w,
>> + state->crtc_y + state-
>>> crtc_h));
>> + regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
>> + VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static u32 vs_dc8200_irq_ack(struct vs_dc *dc)
>> +{
>> + u32 hw_irqs, unified = 0;
>> + unsigned int i;
>> +
>> + regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &hw_irqs);
>> +
>> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
>> + if (hw_irqs & VSDC_TOP_IRQ_VSYNC(i))
>> + unified |= VSDC_IRQ_VSYNC(i);
>> + }
> Maybe add a drm_WARN_ONCE for unknown hardware IRQ bit?
>
> Well, with this addressed,
>
> ```
> Reviewed-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
> ```
>
> Thanks,
> Icenowy
I will add a `drm_WARN_ONCE` after the IRQ translation loop in
`vs_dc8200_irq_ack` to catch any unknown hardware IRQ bits.
^ permalink raw reply
* Re: [PATCH v5 5/7] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: Joey Lu @ 2026-06-29 3:54 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <39e7d0426d1690ccfc8dbcfc77e7440bc5c9a725.camel@iscas.ac.cn>
On 6/26/2026 4:03 PM, Icenowy Zheng wrote:
> 在 2026-06-25四的 17:44 +0800，Joey Lu写道：
>> The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
>> controller (DC8000 generation) whose register layout differs from
>> the DC8200 in several important ways:
>>
>> 1. No CONFIG_EX commit path: framebuffer updates use the enable (bit
>> 0)
>> and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
>> registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
>> FB_BLEND_CONFIG, PANEL_CONFIG_EX).
>>
>> 2. No PANEL_START register: panel output starts when
>> PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
>> register.
>>
>> 3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
>> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
>> TOP_IRQ_EN (0x0014).
>>
>> 4. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
>> divider) clocks; no axi or ahb clocks required.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> drivers/gpu/drm/verisilicon/Makefile | 2 +-
>> drivers/gpu/drm/verisilicon/vs_dc.c | 5 +-
>> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
>> drivers/gpu/drm/verisilicon/vs_dc8000.c | 86
>> +++++++++++++++++++++++++
>> 4 files changed, 92 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
>>
>> diff --git a/drivers/gpu/drm/verisilicon/Makefile
>> b/drivers/gpu/drm/verisilicon/Makefile
>> index 9d4cd16452fa..d2fd8e4dff24 100644
>> --- a/drivers/gpu/drm/verisilicon/Makefile
>> +++ b/drivers/gpu/drm/verisilicon/Makefile
>> @@ -1,6 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>>
>> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_drm.o vs_hwdb.o \
>> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_dc8000.o vs_drm.o vs_hwdb.o \
>> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>>
>> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index fd1f5fe67a68..9499fffbca58 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
>>> identity.model,
>> dc->identity.revision, dc->identity.customer_id);
>>
>> - dc->funcs = &vs_dc8200_funcs;
>> + if (dc->identity.generation == VSDC_GEN_DC8200)
>> + dc->funcs = &vs_dc8200_funcs;
>> + else
>> + dc->funcs = &vs_dc8000_funcs;
>>
>> if (port_count > dc->identity.display_count) {
>> dev_err(dev, "too many downstream ports than HW
>> capability\n");
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
>> b/drivers/gpu/drm/verisilicon/vs_dc.h
>> index 825f5dd6bf17..ac96ad701199 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
>> @@ -66,5 +66,6 @@ struct vs_dc {
>> };
>>
>> extern const struct vs_dc_funcs vs_dc8200_funcs;
>> +extern const struct vs_dc_funcs vs_dc8000_funcs;
>>
>> #endif /* _VS_DC_H_ */
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c
>> b/drivers/gpu/drm/verisilicon/vs_dc8000.c
>> new file mode 100644
>> index 000000000000..fbe0fa516cac
>> --- /dev/null
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
>> @@ -0,0 +1,86 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2026 Joey Lu <yclu4@nuvoton.com>
>> + */
>> +
>> +#include <linux/regmap.h>
>> +
>> +#include "vs_crtc_regs.h"
>> +#include "vs_dc.h"
>> +#include "vs_drm.h"
>> +#include "vs_primary_plane_regs.h"
>> +
>> +static void vs_dc8000_panel_enable_ex(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_RESET);
>> +}
>> +
>> +static void vs_dc8000_panel_disable_ex(struct vs_dc *dc, unsigned
>> int output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_RESET);
>> +}
>> +
>> +static void vs_dc8000_crtc_begin(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_VALID);
>> +}
>> +
>> +static void vs_dc8000_crtc_flush(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_VALID);
>> +}
>> +
>> +static void vs_dc8000_crtc_enable_ex(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_ENABLE);
>> +}
>> +
>> +static void vs_dc8000_crtc_disable_ex(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_ENABLE);
>> +}
>> +
>> +static void vs_dc8000_enable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_DISP_IRQ_EN,
>> + VSDC_DISP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dc8000_disable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_DISP_IRQ_EN,
>> + VSDC_DISP_IRQ_VSYNC(output));
>> +}
>> +
>> +static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
>> +{
>> + u32 hw_irqs, unified = 0;
>> + unsigned int i;
>> +
>> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &hw_irqs);
>> +
>> + for (i = 0; i < VSDC_MAX_OUTPUTS; i++) {
>> + if (hw_irqs & VSDC_DISP_IRQ_VSYNC(i))
>> + unified |= VSDC_IRQ_VSYNC(i);
>> + }
> Maybe a warning for unknown IRQ bits should be added here.
>
> Thanks,
> Icenowy
I will add the same `drm_WARN_ONCE` pattern in `vs_dc8000_irq_ack` for
unknown `VSDC_DISP_IRQ_STA` bits.
>> +
>> + return unified;
>> +}
>> +
>> +const struct vs_dc_funcs vs_dc8000_funcs = {
>> + .panel_enable_ex = vs_dc8000_panel_enable_ex,
>> + .panel_disable_ex = vs_dc8000_panel_disable_ex,
>> + .crtc_begin = vs_dc8000_crtc_begin,
>> + .crtc_flush = vs_dc8000_crtc_flush,
>> + .crtc_enable_ex = vs_dc8000_crtc_enable_ex,
>> + .crtc_disable_ex = vs_dc8000_crtc_disable_ex,
>> + .enable_vblank = vs_dc8000_enable_vblank,
>> + .disable_vblank = vs_dc8000_disable_vblank,
>> + .irq_ack = vs_dc8000_irq_ack,
>> +};
^ permalink raw reply
* Re: [PATCH v3 00/12] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Shrikanth Hegde @ 2026-06-29 4:04 UTC (permalink / raw)
To: Jinjie Ruan, catalin.marinas, will, tsbogend, tglx, mingo, bp,
dave.hansen, hpa, peterz, kees, nathan, linusw, ojeda,
david.kaplan, lukas.bulwahn, ryan.roberts, maz, timothy.hayes,
lpieralisi, thuth, menglong8.dong, oupton, yeoreum.yun,
miko.lenczewski, broonie, kevin.brodsky, james.clark, yangyicong,
tabba, osandov, arnd, anshuman.khandual, david, akpm, ljs,
dev.jain, yang, chaitanyas.prakash, kprateek.nayak, chenl311,
thorsten.blum, chang.seok.bae, tim.c.chen, x86, linux-kernel,
linux-arm-kernel, linux-mips
In-Reply-To: <20260624092537.2916971-1-ruanjinjie@huawei.com>
On 6/24/26 2:55 PM, Jinjie Ruan wrote:
> Support for parallel secondary CPU bringup is already utilized by x86,
> MIPS, and RISC-V. This patch brings this capability to the arm64
> architecture.
>
> Introduce CONFIG_HOTPLUG_PARALLEL_SMT to avoid primary SMT threads
> to boot first constraint.
>
> And add a 'cpu' parameter to update_cpu_boot_status() to allow updating
> the boot status at a per-CPU granularity during parallel bringup.
>
> Rework the global `secondary_data` and `__early_cpu_boot_status` accessed
> during early boot into per-CPU arrays to allow secondary CPUs to boot
> in parallel.
>
Shouldn't this be called CONFIG_BRINGUP_PARALLEL instead?
Hotplug usually means disable/enable CPU at runtime.
^ permalink raw reply
* Re: [PATCH rc v6 1/7] iommu/arm-smmu-v3: Add arm_smmu_kdump_adopt_strtab() for kdump
From: Nicolin Chen @ 2026-06-29 4:01 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: will, robin.murphy, jgg, joro, kees, baolu.lu, kevin.tian,
miko.lenczewski, smostafa, linux-arm-kernel, iommu, linux-kernel,
stable, jamien
In-Reply-To: <akGnm_dzvoapjwoI@google.com>
On Sun, Jun 28, 2026 at 11:00:43PM +0000, Pranjal Shrivastava wrote:
> On Wed, May 20, 2026 at 10:03:18AM -0700, Nicolin Chen wrote:
> > +static int arm_smmu_kdump_adopt_l2_strtab(struct arm_smmu_device *smmu, u32 sid,
> > + phys_addr_t base, u32 span,
> > + struct arm_smmu_strtab_l2 **l2table)
[...]
> > +
> > + /*
> > + * Retest the span in case the L1 descriptor has been overwritten since
> > + * the adopt. Reject this master's insert; panic or SMMU-disable would
> > + * either lose the vmcore or cascade aborts. Do not try to fix it, as it
> > + * would break all other SIDs in the same bus (PCI case). The corruption
> > + * blast radius is already bounded to that bus range.
> > + */
> > + if (span != STRTAB_SPLIT + 1) {
> > + dev_err(smmu->dev,
> > + "kdump: L1[%u] span %u changed since adopt (was %u)\n",
> > + arm_smmu_strtab_l1_idx(sid), span, STRTAB_SPLIT + 1);
> > + return -EINVAL;
> > + }
> > +
> > + size = (1UL << (span - 1)) * sizeof(struct arm_smmu_ste);
> > +
> > + table = devm_memremap(smmu->dev, base, size, MEMREMAP_WB);
>
> Why do we use devm_memremap() here but memremap() in the rest of the
> functions (even for the L1 ptr)?
Because it's called by arm_smmu_init_l2_strtab() that is a later
stage (arm_smmu_insert_master) than the other adopt functions.
This is deliberate. Otherwise, no one would undo memremap.
I can add a line of note here.
> > +static int arm_smmu_kdump_adopt_strtab_2lvl(struct arm_smmu_device *smmu,
> > + u32 cfg_reg, phys_addr_t base)
[...]
> > +
> > + cfg->l2.l2ptrs =
> > + kcalloc(num_l1_ents, sizeof(*cfg->l2.l2ptrs), GFP_KERNEL);
> > + if (!cfg->l2.l2ptrs)
> > + return -ENOMEM;
>
> We shuold ummap cfg->l2.l1tab before returning -ENOMEM here
No. The caller would call cleanup() on the -ENOMEM.
> > + if (span != STRTAB_SPLIT + 1) {
> > + dev_err(smmu->dev,
> > + "kdump: L1[%u] unsupported span %u (vs %u)\n",
> > + i, span, STRTAB_SPLIT + 1);
> > + return -EINVAL;
>
> We leak kcalloc'd mem (l2.l2ptrs) here, also we should unmap cfg->l2.l1tab
Ditto.
> > +static int arm_smmu_kdump_adopt_strtab_linear(struct arm_smmu_device *smmu,
> > + u32 cfg_reg, phys_addr_t base)
> > +{
> > + u32 log2size = FIELD_GET(STRTAB_BASE_CFG_LOG2SIZE, cfg_reg);
> > + struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> > + unsigned int max_log2size;
> > + size_t size;
> > +
> > + /*
> > + * Only a coherent SMMU is supported at this moment. For a non-coherent
> > + * SMMU that wants to support ARM_SMMU_OPT_KDUMP_ADOPT, try MEMREMAP_WC.
> > + */
> > + if (WARN_ON(!(smmu->features & ARM_SMMU_FEAT_COHERENCY)))
> > + return -EOPNOTSUPP;
> > +
> > + /* Cap the size at what the kdump kernel itself would have allocated */
> > + if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB)
> > + max_log2size =
> > + ilog2(STRTAB_MAX_L1_ENTRIES * STRTAB_NUM_L2_STES);
>
> Looks like we'd never hit this if condition because we'd never support a
> "linear" strtab if the HW supports ARM_SMMU_FEAT_2_LVL_STRTAB. Please
> see arm_smmu_init_strtab:
It's a defensive check that Sashiko recommended, as we cannot be sure
that the crashed kernel was using the same driver, which I think it's
not bad to have..
> > + size = cfg->linear.num_ents * sizeof(struct arm_smmu_ste);
> > + cfg->linear.table = memremap(base, size, MEMREMAP_WB);
> > + if (!cfg->linear.table)
> > + return -ENOMEM;
>
> We seem to skips initializing cfg->linear.ste_dma (it is populated in
> arm_smmu_init_strtab_linear)
Yes, deliberately since it's not used anywhere in kdump adopt mode.
> While the comment notes that arm_smmu_write_strtab() is bypassed in the
> kdump case, leaving cfg->linear.ste_dma uninitialized seems like a
> ticking time bomb if any other part of the driver ever uses it.
I can't think of a reason...
> > +static void arm_smmu_kdump_adopt_cleanup(void *data)
> > +{
> > + struct arm_smmu_device *smmu = data;
> > + u32 cfg_reg = readl_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE_CFG);
>
> I'm worried about reading the HW register here, since this is a devres action, it
> can run after arm_smmu_device_remove() or arm_smmu_device_shutdown()
> (which would call rpm_put()). Please see __device_release_driver[1]:
>
> pm_runtime_put_sync(dev); <--- HW turned off
>
> device_remove(dev);
>
> if (dev->bus && dev->bus->dma_cleanup)
> dev->bus->dma_cleanup(dev);
>
> device_unbind_cleanup(dev); <--- This is where devm_release runs
> device_links_driver_cleanup(dev);
>
> Thus, even if we call rpm_get() here it would make no sense as the
> register contents would've been lost. Can we rely on some SW state
> here? smmu->features & 2LVL or maybe add an fmt in cfg?
Yes. Sashiko pointed it out too. We can do feature bit.
> > + * format, enforce the same format to match the adopted table.
> > + */
> > + ret = arm_smmu_kdump_adopt_strtab_linear(smmu, cfg_reg, base);
> > + if (!ret)
> > + smmu->features &= ~ARM_SMMU_FEAT_2_LVL_STRTAB;
>
> IIRC, this should NOT be set if we selected the linear format.
> Looking at arm_smmu_init_strtab(), if the HW supports 2-level tables,
> the driver unconditionally selects it. What is the expected scenario
> where the previous kernel would have allocated a linear table on 2-level
> capable hardware? IMO, it is a bug if we see linear fmt with this
> feature set. Am I missing something?
Again, the crashed kernel doesn't have to use the same driver.
I will address the rest of your comments.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v4 0/3] iommu/arm-smmu-v3: Tegra264 invalidation workaround
From: Ashish Mhetre @ 2026-06-29 4:11 UTC (permalink / raw)
To: Jon Hunter, Nicolin Chen, Will Deacon, Robin Murphy, Joerg Roedel,
Jason Gunthorpe
Cc: linux-arm-kernel, iommu, linux-kernel, linux-tegra
In-Reply-To: <96959efb-051c-411a-810f-927943d5491d@nvidia.com>
On 6/17/2026 1:51 PM, Jon Hunter wrote:
>
> On 17/06/2026 05:54, Nicolin Chen wrote:
>> On Wed, Jun 17, 2026 at 09:28:10AM +0530, Ashish Mhetre wrote:
>>> On 6/9/2026 1:02 PM, Ashish Mhetre wrote:
>>> Hi all,
>>>
>>> A gentle reminder to review the patches and share your comments.
>>
>> https://docs.kernel.org/process/maintainer-tip.html
>>
>> "
>> 4.2.9 Merge window
>>
>> Please do not expect patches to be reviewed or merged by tip
>> maintainers around or during the merge window. The trees are closed
>> to all but urgent fixes during this time. They reopen once the merge
>> window closes and a new -rc1 kernel has been released.
>> "
>>
>> I would wait for rc1 to rebase and respin.
>
> Assuming that they need to be rebased. If they apply cleanly to -next
> after -rc1 is out, then there is no need to rebase. However,
> definitely check.
>
> Jon
>
The patches apply cleanly on linux-next-20260626 and rebase is not
needed. Can you please let me know if the series is good for review
or should I rebase on latest linux-next and resend?
Thanks,
Ashish Mhetre
^ permalink raw reply
* Re: [PATCH v14 0/7] Provide support for Trigger Generation Unit
From: Greg KH @ 2026-06-29 4:22 UTC (permalink / raw)
To: Songwei.Chai
Cc: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
suzuki.poulose, james.clark, krzk+dt, conor+dt, linux-kernel,
linux-arm-kernel, linux-arm-msm, coresight, devicetree
In-Reply-To: <a36a1ed3-5194-465c-b029-0404e0f2bcee@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 11:03:33AM +0800, Songwei.Chai wrote:
> Hi Greg & Alexander,
>
> Apologies for interrupting again.
>
> As the TGU hardware plays an important role in Qualcomm tracing design, I
> would greatly appreciate it if you could kindly take some time to review
> this at your earliest convenience.
The merge window _just_ closed, please give us a chance to catch up.
Also, why us? Surely you have other reviewers for this code, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/6] arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE setup
From: Dev Jain @ 2026-06-29 5:34 UTC (permalink / raw)
To: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
akpm, urezki
Cc: baohua, Xueyuan.chen21, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <20260618084726.1070022-2-jiangwen6@xiaomi.com>
On 18/06/26 2:17 pm, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> For sizes aligned to CONT_PTE_SIZE and smaller than PMD_SIZE,
> we can handle CONT_PTE_SIZE groups together.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> arch/arm64/mm/hugetlbpage.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
> index a42c05cf56408..c4d8b226126cb 100644
> --- a/arch/arm64/mm/hugetlbpage.c
> +++ b/arch/arm64/mm/hugetlbpage.c
> @@ -110,6 +110,12 @@ static inline int num_contig_ptes(unsigned long size, size_t *pgsize)
> contig_ptes = CONT_PTES;
> break;
> default:
> + if (size > 0 && size < PMD_SIZE &&
> + IS_ALIGNED(size, CONT_PTE_SIZE)) {
> + contig_ptes = size >> PAGE_SHIFT;
> + *pgsize = PAGE_SIZE;
Nit: *pgsize update can go before contig_ptes, to keep the pattern elsewhere.
Reviewed-by: Dev Jain <dev.jain@arm.com>
> + break;
> + }
> WARN_ON(!__hugetlb_valid_size(size));
> }
>
> @@ -359,6 +365,10 @@ pte_t arch_make_huge_pte(pte_t entry, unsigned int shift, vm_flags_t flags)
> case CONT_PTE_SIZE:
> return pte_mkcont(entry);
> default:
> + if (pagesize > 0 && pagesize < PMD_SIZE &&
> + IS_ALIGNED(pagesize, CONT_PTE_SIZE))
> + return pte_mkcont(entry);
> +
> break;
> }
> pr_warn("%s: unrecognized huge page size 0x%lx\n",
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Icenowy Zheng @ 2026-06-29 5:31 UTC (permalink / raw)
To: Joey Lu, Conor Dooley
Cc: Conor Dooley, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <b3b7a0f8-93a8-4965-a2f3-3ca1552a25d6@gmail.com>
在 2026-06-29一的 11:47 +0800，Joey Lu写道：
>
> On 6/26/2026 5:33 PM, Icenowy Zheng wrote:
> > 在 2026-06-26五的 10:26 +0100，Conor Dooley写道：
> > > On Fri, Jun 26, 2026 at 05:00:35PM +0800, Icenowy Zheng wrote:
> > > > 在 2026-06-26五的 08:19 +0100，Conor Dooley写道：
> > > > > On Fri, Jun 26, 2026 at 01:27:21PM +0800, Icenowy Zheng
> > > > > wrote:
> > > > > > 在 2026-06-25四的 17:33 +0100，Conor Dooley写道：
> > > > > > > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > > > > > > > +allOf:
> > > > > > > > + - if:
> > > > > > > > + properties:
> > > > > > > > + compatible:
> > > > > > > > + contains:
> > > > > > > > + const: thead,th1520-dc8200
> > > > > > > > + then:
> > > > > > > > + properties:
> > > > > > > > + clocks:
> > > > > > > > + minItems: 5
> > > > > > > > + maxItems: 5
> > > > > > > > +
> > > > > > > > + clock-names:
> > > > > > > > + minItems: 5
> > > > > > > > + maxItems: 5
> > > > > > > All the maxItems here repeat the maximum constraint and
> > > > > > > do
> > > > > > > nothing.
> > > > > > >
> > > > > > > Since you didn't change the minimum constraint at the top
> > > > > > > level,
> > > > > > > your
> > > > > > > minItems also do nothing.
> > > > > > >
> > > > > > > > +
> > > > > > > > + resets:
> > > > > > > > + minItems: 3
> > > > > > > > + maxItems: 3
> > > > > > > > +
> > > > > > > > + reset-names:
> > > > > > > > + minItems: 3
> > > > > > > > + maxItems: 3
> > > > > > > > +
> > > > > > > > + required:
> > > > > > > > + - resets
> > > > > > > > + - reset-names
> > > > > > > Both conditional sections have this, but the original
> > > > > > > binding
> > > > > > > doesn't
> > > > > > > require these for the thead device. This is a functional
> > > > > > > change
> > > > > > > therefore and shouldn't be in a patch calling itself
> > > > > > > "generalise
> > > > > > > for
> > > > > > > single ended variants".
> > > > > > Well yes they're required.
> > > > > >
> > > > > > Should I send a patch adding the `thead,th1520-dc8200` part
> > > > > > of
> > > > > > the
> > > > > > schema?
> > > > > If you mean the code above, no. Adding a conditional section
> > > > > when
> > > > > there's only that compatible doesn't make sense.
> > > > >
> > > > > What you could do is just add it at the top level though,
> > > > > which
> > > > > would
> > > > > also benefit this patch since it'd not have to be
> > > > > conditionally
> > > > > added
> > > > > for the new nuvoton device.
> > > > > Just note in your commit message about what the ABI impact of
> > > > > the
> > > > > change
> > > > > to required properties is (effectively nothing because it's
> > > > > optional
> > > > > in
> > > > > the driver and the only user has the properties).
> > > > Okay, I will craft such a patch and send it.
> > > >
> > > > > > > > +
> > > > > > > > + resets:
> > > > > > > > + minItems: 1
> > > > > > > > + maxItems: 1
> > > > > > > > +
> > > > > > > > + reset-names:
> > > > > > > > + items:
> > > > > > > > + - const: core
> > > > > > > This is just maxItems: 1.
> > > > > > Well the implicit rules of DT binding schemas are quite
> > > > > > weird...
> > > > > I don't think it is that strange, as the binding has
> > > > > reset-names:
> > > > > items:
> > > > > - const: core
> > > > > - const: axi
> > > > > - const: ahb
> > > > Ah does the list constraint the order of items? If it
> > > > constrains
> > > > the
> > > It does, yes.
> > > Alternatively, using an enum permits free ordering.
> > Ah in this case this should be converted to an enum, I think.
> >
> > Should I send a patch for converting it?
> >
> > Thanks,
> > Icenowy
> Thank you all for the detailed review and discussion, it really
> helped
> clarify the right approach.
>
> Since I will supply all four clocks with the same phandle for
> core/axi/ahb,
> and only one reset "core" for MA35D1, the ordering constraint in the
> `items` list is not a problem, "core" is already the first entry.
> There
> is no need to convert to an enum.
>
> Regarding the clock situation for the MA35D1: I agree with supplying
> all
> four clocks (core, axi, ahb, pix0) in the devicetree, even though the
> MA35D1 clock controller gates core/axi/ahb with a single bit. The DT
> will
> use the same clock phandle for core, axi, and ahb:
>
> clocks = <&clk X>, <&clk X>, <&clk X>, <&pix_clk Y>;
> clock-names = "core", "axi", "ahb", "pix0";
>
> This correctly models the hardware topology. Since all three names
No, this doesn't correctly model the hardware topology -- this will
lead to clk_get_rate() return the rate of DC core clock when checking
the AXI clock rate, which is problematic because both clocks are
limiting the performance of the DC.
> resolve
> to the same underlying clock node, the CCF's standard enable
> refcounting
> handles the shared gate correctly without any custom implementation
> needed.
> I will also revert the change in patch 4/7 that made axi and ahb
> clocks
> optional, since they will now always be provided in the devicetree.
>
> Regarding moving `resets` and `reset-names` to the top-level
> `required:`,
> I will wait for Icenowy's patch to land before sending v6 to avoid
> duplicating the work.
The patch is sent.
>
> In v6 I will update patch 1/7 with:
> - Update the subject to "dt-bindings: display: verisilicon,dc: add
> support for nuvoton,ma35d1-dcu"
> - Lower `clocks`/`clock-names` `minItems` to 4 at the top level
> - Remove the `thead,th1520-dc8200` conditional block entirely
I think this conditional block will still be needed, because it will
need to constrain the minItems to ensure all clocks / resets are
populated.
Thanks,
Icenowy
> - Keep only the `nuvoton,ma35d1-dcu` conditional block, using only
> `maxItems: 4` for clocks/clock-names and `maxItems: 1` for
> resets/reset-names to tighten the top-level constraints
>
> BR,
> Joey
> > > > order, it partly breaks the intention of having names; if it
> > > > does
> > > > not
> > > > constrain the order, it needs to be clarified that the required
> > > > 1
> > > > reset
> > > > is core instead of the other two.
> > > Given the discussion we're having on the clocks, I wonder if this
> > > is
> > > also an oversimplification and the IP has three resets inputs
> > > hooked
> > > up
> > > to one output of the reset controller (or 3 outputs controlled by
> > > one
> > > bit..).
^ permalink raw reply
* Re: [PATCH v4 2/6] arm64/vmalloc: Allow arch_vmap_pte_range_map_size to batch multiple CONT_PTE
From: Dev Jain @ 2026-06-29 5:34 UTC (permalink / raw)
To: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
akpm, urezki
Cc: baohua, Xueyuan.chen21, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <20260618084726.1070022-3-jiangwen6@xiaomi.com>
On 18/06/26 2:17 pm, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> Allow arch_vmap_pte_range_map_size to batch across multiple CONT_PTE
> blocks, reducing both PTE setup and TLB flush iterations.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> arch/arm64/include/asm/vmalloc.h | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
> index 4ec1acd3c1b34..787fd17b48e2c 100644
> --- a/arch/arm64/include/asm/vmalloc.h
> +++ b/arch/arm64/include/asm/vmalloc.h
> @@ -23,6 +23,8 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr,
> unsigned long end, u64 pfn,
> unsigned int max_page_shift)
> {
> + unsigned long size;
> +
> /*
> * If the block is at least CONT_PTE_SIZE in size, and is naturally
> * aligned in both virtual and physical space, then we can pte-map the
> @@ -40,7 +42,9 @@ static inline unsigned long arch_vmap_pte_range_map_size(unsigned long addr,
> if (!IS_ALIGNED(PFN_PHYS(pfn), CONT_PTE_SIZE))
> return PAGE_SIZE;
>
> - return CONT_PTE_SIZE;
> + size = min3(end - addr, 1UL << max_page_shift, PMD_SIZE >> 1);
> + size = 1UL << __fls(size);
Nit: I'd rather use rounddown_pow_of_two() : __fls is confusing : )
Reviewed-by: Dev Jain <dev.jain@arm.com>
> + return size;
> }
>
> #define arch_vmap_pte_range_unmap_size arch_vmap_pte_range_unmap_size
^ permalink raw reply
* Re: [PATCH v4 3/6] mm/vmalloc: Extract vmap_set_ptes() to consolidate PTE mapping logic
From: Dev Jain @ 2026-06-29 5:54 UTC (permalink / raw)
To: Wen Jiang, linux-mm, linux-arm-kernel, catalin.marinas, will,
akpm, urezki
Cc: baohua, Xueyuan.chen21, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <20260618084726.1070022-4-jiangwen6@xiaomi.com>
On 18/06/26 2:17 pm, Wen Jiang wrote:
> Extract the common PTE mapping logic from vmap_pte_range() into a
> shared helper vmap_set_ptes(). This handles both CONT_PTE and regular
> PTE mappings in a single function, preparing for the next patch which
> will extend vmap_pages_pte_range() to also use this helper.
>
> The #ifdef CONFIG_HUGETLB_PAGE guard is moved inside vmap_set_ptes(),
> so callers no longer need to handle the conditional compilation.
>
> No functional change.
>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 44 +++++++++++++++++++++++++++++++-------------
> 1 file changed, 31 insertions(+), 13 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 2c2f74a07f396..6660f240d27c9 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -91,6 +91,35 @@ struct vfree_deferred {
> static DEFINE_PER_CPU(struct vfree_deferred, vfree_deferred);
>
> /*** Page table manipulation functions ***/
> +
> +/*
> + * Set PTE mappings for the given PFN. Try CONT_PTE mappings first when
CONT_PTE is arm64-specific, doesn't feel right to mention this in generic code.
If you really want to put a comment, just say:
"Try contiguous mappings at the PTE level for arches which support them, and if
requested by the caller. Fall back to PAGE_SIZE mappings otherwise.
Return: mapping size."
> + * supported, otherwise fall back to PAGE_SIZE mappings.
> + *
> + * Return: mapping size.
> + */
> +static __always_inline unsigned long vmap_set_ptes(pte_t *pte,
> + unsigned long addr, unsigned long end, u64 pfn,
> + pgprot_t prot, unsigned int max_page_shift)
> +{
> +#ifdef CONFIG_HUGETLB_PAGE
> + if (max_page_shift > PAGE_SHIFT) {
This if block is not needed, max_page_shift > PAGE_SHIFT is handled by
arch_vmap_pte_range_map_size.
With that:
Reviewed-by: Dev Jain <dev.jain@arm.com>
> + unsigned long size;
> +
> + size = arch_vmap_pte_range_map_size(addr, end, pfn, max_page_shift);
> + if (size != PAGE_SIZE) {
> + pte_t entry = pfn_pte(pfn, prot);
> +
> + entry = arch_make_huge_pte(entry, ilog2(size), 0);
> + set_huge_pte_at(&init_mm, addr, pte, entry, size);
> + return size;
> + }
> + }
> +#endif
> + set_pte_at(&init_mm, addr, pte, pfn_pte(pfn, prot));
> + return PAGE_SIZE;
> +}
> +
> static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> phys_addr_t phys_addr, pgprot_t prot,
> unsigned int max_page_shift, pgtbl_mod_mask *mask)
> @@ -119,19 +148,8 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> BUG();
> }
>
> -#ifdef CONFIG_HUGETLB_PAGE
> - size = arch_vmap_pte_range_map_size(addr, end, pfn, max_page_shift);
> - if (size != PAGE_SIZE) {
> - pte_t entry = pfn_pte(pfn, prot);
> -
> - entry = arch_make_huge_pte(entry, ilog2(size), 0);
> - set_huge_pte_at(&init_mm, addr, pte, entry, size);
> - pfn += PFN_DOWN(size);
> - continue;
> - }
> -#endif
> - set_pte_at(&init_mm, addr, pte, pfn_pte(pfn, prot));
> - pfn++;
> + size = vmap_set_ptes(pte, addr, end, pfn, prot, max_page_shift);
> + pfn += PFN_DOWN(size);
> } while (pte += PFN_DOWN(size), addr += size, addr != end);
>
> lazy_mmu_mode_disable();
^ 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