* [PATCH 0/2] spmi: pmic-arb: Add spmi-pmic-arb support for Hawi SoC
From: Fenglin Wu @ 2026-04-01 9:41 UTC (permalink / raw)
To: Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio
Cc: Subbaraman Narayanamurthy, David Collins, linux-arm-msm,
linux-kernel, devicetree, kernel, Fenglin Wu
Add compatible for Hawi SoC and add pmic-arb v8.5 support.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Fenglin Wu (2):
dt-bindings: spmi: glymur-spmi-pmic-arb: Add compatible for Hawi
spmi: spmi-pmic-arb: add support for PMIC arbiter v8.5
.../bindings/spmi/qcom,glymur-spmi-pmic-arb.yaml | 1 +
drivers/spmi/spmi-pmic-arb.c | 69 +++++++++++++++++++---
2 files changed, 61 insertions(+), 9 deletions(-)
---
base-commit: 840b0dd6b8c169e963f74265f508c54f1fe3c968
change-id: 20260323-hawi-spmi-a29ef97409a4
Best regards,
--
Fenglin Wu <fenglin.wu@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 4/6] drm/msm/a8xx: use pipe protect slot 15 for last-span-unbound feature
From: Konrad Dybcio @ 2026-04-01 9:32 UTC (permalink / raw)
To: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Akhil P Oommen, Bjorn Andersson
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel
In-Reply-To: <20260331-adreno-810-v1-4-725801dbb12b@pm.me>
On 4/1/26 4:17 AM, Alexander Koskovich wrote:
> A8XX GPUs have two sets of protect registers: 64 global slots and 16
> pipe specific slots. The last-span-unbound feature is only available
> on pipe protect registers, and should always target pipe slot 15.
>
> This matches the downstream driver which hardcodes pipe slot 15 for
> all A8XX GPUs (GRAPHICS.LA.15.0.r1) and resolves protect errors on
> A810.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> drivers/gpu/drm/msm/adreno/a8xx_gpu.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a8xx_gpu.c b/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
> index 5af82d43f1e4..63387ee9b04a 100644
> --- a/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
> @@ -252,11 +252,12 @@ static void a8xx_set_cp_protect(struct msm_gpu *gpu)
> }
>
> /*
> - * Last span feature is only supported on PIPE specific register.
> - * So update those here
> + * Last span setting is only being applied to the last pipe specific
> + * register. Hence duplicate the last span from protect reg into the
> + * BR and BV protect reg pipe 15.
> */
> - a8xx_write_pipe(gpu, PIPE_BR, REG_A8XX_CP_PROTECT_PIPE(protect->count_max), final_cfg);
> - a8xx_write_pipe(gpu, PIPE_BV, REG_A8XX_CP_PROTECT_PIPE(protect->count_max), final_cfg);
> + a8xx_write_pipe(gpu, PIPE_BR, REG_A8XX_CP_PROTECT_PIPE(15), final_cfg);
> + a8xx_write_pipe(gpu, PIPE_BV, REG_A8XX_CP_PROTECT_PIPE(15), final_cfg);
I think this is a better fix than:
https://lore.kernel.org/linux-arm-msm/20260225-glymur-protect-fix-v1-1-0deddedf9277@oss.qualcomm.com/
which will let us bring back the BUILD_BUG_ON.. WDYT Akhil?
FWIW KGSL just hardcodes the number 15 here as well.. may make it
configurable if that ever changes
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH v3 5/7] PCI: intel-gw: Add start_link callback function
From: Florian Eckert @ 2026-04-01 9:31 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de>
The pcie-intel-gw driver has no start_link callback function. This commit
adds the missing callback function so that the driver works again and does
not abort with the following error messages during probing.
[ 2.512015] intel-gw-pcie d1000000.pcie: host bridge /soc/pcie@d1000000 ranges:
[ 2.517868] intel-gw-pcie d1000000.pcie: MEM 0x00dc000000..0x00ddffffff -> 0x00dc000000
[ 2.528450] intel-combo-phy d0c00000.combo-phy: Set combo mode: combophy[1]: mode: PCIe single lane mode
[ 2.551619] intel-gw-pcie d1000000.pcie: No outbound iATU found
[ 2.556060] intel-gw-pcie d1000000.pcie: Cannot initialize host
[ 2.561901] intel-gw-pcie d1000000.pcie: probe with driver intel-gw-pcie failed with error -22
[ 2.571041] intel-gw-pcie c1100000.pcie: host bridge /soc/pcie@c1100000 ranges:
[ 2.577736] intel-gw-pcie c1100000.pcie: MEM 0x00ce000000..0x00cfffffff -> 0x00ce000000
[ 2.588299] intel-combo-phy c0c00000.combo-phy: Set combo mode: combophy[3]: mode: PCIe single lane mode
[ 2.611471] intel-gw-pcie c1100000.pcie: No outbound iATU found
[ 2.615934] intel-gw-pcie c1100000.pcie: Cannot initialize host
[ 2.621759] intel-gw-pcie c1100000.pcie: probe with driver intel-gw-pcie failed with error -22
Fixes: c5097b9869a1 ("Revert "PCI: dwc: Wait for link up only if link is started"")
Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started")
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index 6d9499d954674a26a74bff56b7fb5759767424c0..afd933050c92ee31c477e0b1738ab1136bdcfbf6 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -284,6 +284,16 @@ static void intel_pcie_turn_off(struct intel_pcie *pcie)
pcie_rc_cfg_wr_mask(pcie, PCI_COMMAND, PCI_COMMAND_MEMORY, 0);
}
+static int intel_pcie_start_link(struct dw_pcie *pci)
+{
+ struct intel_pcie *pcie = dev_get_drvdata(pci->dev);
+
+ intel_pcie_device_rst_deassert(pcie);
+ intel_pcie_ltssm_enable(pcie);
+
+ return 0;
+}
+
static int intel_pcie_host_setup(struct intel_pcie *pcie)
{
int ret;
@@ -310,25 +320,12 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
intel_pcie_link_setup(pcie);
intel_pcie_init_n_fts(pci);
- ret = dw_pcie_setup_rc(&pci->pp);
- if (ret)
- goto err;
-
dw_pcie_upconfig_setup(pci);
- intel_pcie_device_rst_deassert(pcie);
- intel_pcie_ltssm_enable(pcie);
-
- ret = dw_pcie_wait_for_link(pci);
- if (ret)
- goto err;
-
intel_pcie_core_irq_enable(pcie);
return 0;
-err:
- phy_exit(pcie->phy);
phy_err:
clk_disable_unprepare(pcie->core_clk);
clk_err:
@@ -386,6 +383,7 @@ static int intel_pcie_rc_init(struct dw_pcie_rp *pp)
}
static const struct dw_pcie_ops intel_pcie_ops = {
+ .start_link = intel_pcie_start_link,
};
static const struct dw_pcie_host_ops intel_pcie_dw_ops = {
--
2.47.3
^ permalink raw reply related
* [PATCH v3 6/7] PCI: intel-gw: Move driver atu base assignment to probe function
From: Florian Eckert @ 2026-04-01 9:31 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de>
If no ATU resource is defined in the devicetree, then driver´s default
value '0x300000' [1] is set. This is done during probing in the function
'dw_pcie_get_resources()' [2] by dwc core.
The driver overwrites this again when its own init callback
'pp->ops->init()' [3] function 'intel_pcie_host_setup()' [4] is called.
This is done, because the 'atu_base' value for this IP is '0xC0000'
rather than '0x300000'.
callstack:
intel_pcie_probe()
dw_pcie_host_init()
dw_pcie_host_get_resources()
dw_pcie_get_resources() [2]
pp->ops->init = intel_pcie_rc_init() [3]
intel_pcie_host_setup() [4]
However, this is a problem because, the callback 'pp->ops->init' is called
after 'dw_pcie_get_resources()' in dwc core (see callstack). The 'atu_base'
must be set before, so that this value is not set by dwc core. Therefor
the assignment of 'atu_base' is moved to driver´s probe function.
While we’re at it, the change also adds the option to load ATU information
from the device tree. For reasons of backwards compatibility, this is not
mandatory. If ‘atu’ is still not specified in the devicetree, then driver’s
default value is still used and set in driver´s probe function. If the 'atu'
resource is present in the devicetree, then dwc core loads it via the
function 'dw_pcie_get_resources()' and not in the driver´s probe function.
[1] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-designware.h#L292
[2] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-designware.c#L150
[3] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-designware-host.c#L589
[4] https://elixir.bootlin.com/linux/v6.19.10/source/drivers/pci/controller/dwc/pcie-intel-gw.c#L301
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 28 ++++++++++++++++++++++++++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index afd933050c92ee31c477e0b1738ab1136bdcfbf6..59b11e45944e199aac0f599f96d6cc90e2104708 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -310,8 +310,6 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
goto clk_err;
}
- pci->atu_base = pci->dbi_base + 0xC0000;
-
ret = phy_init(pcie->phy);
if (ret)
goto phy_err;
@@ -395,6 +393,7 @@ static int intel_pcie_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct intel_pcie *pcie;
struct dw_pcie_rp *pp;
+ struct resource *res;
struct dw_pcie *pci;
int ret;
@@ -419,6 +418,31 @@ static int intel_pcie_probe(struct platform_device *pdev)
pci->ops = &intel_pcie_ops;
pp->ops = &intel_pcie_dw_ops;
+ /*
+ * If the 'atu' resource is not available in the devicetree,
+ * then use the driver default value for backward compatibility.
+ * The 'atu' should always be set in the devicetree, as this is
+ * hardware specific setting that should not be defined in the
+ * source.
+ */
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
+ if (!res) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
+ pci->dbi_base = devm_pci_remap_cfg_resource(pci->dev, res);
+ if (IS_ERR(pci->dbi_base))
+ return PTR_ERR(pci->dbi_base);
+ pci->dbi_phys_addr = res->start;
+ pci->atu_base = devm_ioremap(dev, res->start + 0xC0000, SZ_4K);
+ if (!pci->atu_base) {
+ dev_err(dev, "failed to remap ATU space\n");
+ return -ENOMEM;
+
+ }
+ pci->atu_size = SZ_4K;
+ pci->atu_phys_addr = res->start + 0xC0000;
+ dev_warn(dev, "devicetree ATU resource is missing; driver`s default value is being used\n");
+ }
+
ret = dw_pcie_host_init(pp);
if (ret) {
dev_err(dev, "Cannot initialize host\n");
--
2.47.3
^ permalink raw reply related
* [PATCH v3 7/7] dt-bindings: PCI: intel,lgm-pcie: Add atu resource
From: Florian Eckert @ 2026-04-01 9:31 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de>
The 'atu' information is already set in the dwc core, if it is specified
in the devicetree. The driver uses its own default, if not set in the
devicetree. This information is hardware specific and should therefore be
maintained in the devicetree rather than in the source.
To be backward compatibile, this field is not mandatory. If 'atu'
resource is not specified in the devicetree, the driver’s default value
is used.
Old DTS entry for PCIe:
reg = <0xd1000000 0x1000>,
<0xd3000000 0x20000>,
<0xd0c41000.0x1000>;
reg-names = "dbi", "config", "app";
New DTS entry for PCIe:
reg = <0xd1000000 0x1000>,
<0xd10c0000 0x1000>,
<0xd3000000 0x20000>,
<0xd0c41000.0x1000>;
reg-names = "dbi", "atu", "config", "app";
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
index 54e2890ae6314ac6847fc23f49440d05d66d87d4..a7cb2b66b382a55d88211890aee068f25f05f61b 100644
--- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
@@ -27,16 +27,19 @@ properties:
- const: snps,dw-pcie
reg:
+ minItems: 3
items:
- description: Controller control and status registers.
- description: PCIe configuration registers.
- description: Controller application registers.
+ - description: Internal Address Translation Unit (iATU) registers.
reg-names:
items:
- const: dbi
- const: config
- const: app
+ - const: atu
ranges:
maxItems: 1
@@ -94,9 +97,10 @@ examples:
#address-cells = <3>;
#size-cells = <2>;
reg = <0xd0e00000 0x1000>,
+ <0xd0ec0000 0x1000>,
<0xd2000000 0x800000>,
<0xd0a41000 0x1000>;
- reg-names = "dbi", "config", "app";
+ reg-names = "dbi", "atu", "config", "app";
linux,pci-domain = <0>;
max-link-speed = <4>;
bus-range = <0x00 0x08>;
--
2.47.3
^ permalink raw reply related
* [PATCH v3 4/7] PCI: intel-gw: Enable clock before phy init
From: Florian Eckert @ 2026-04-01 9:31 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de>
To ensure that the boot sequence is correct, the dwc pcie core clock must
be switched on before phy init call [1]. This changes are based on patched
kernel sources of the MaxLinear SDK.
[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index e88b8243cc41c607c39e4d58c4dcd8c8c082e8b0..6d9499d954674a26a74bff56b7fb5759767424c0 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -291,13 +291,9 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
intel_pcie_core_rst_assert(pcie);
intel_pcie_device_rst_assert(pcie);
-
- ret = phy_init(pcie->phy);
- if (ret)
- return ret;
-
intel_pcie_core_rst_deassert(pcie);
+ /* Controller clock must be provided earlier than PHY */
ret = clk_prepare_enable(pcie->core_clk);
if (ret) {
dev_err(pcie->pci.dev, "Core clock enable failed: %d\n", ret);
@@ -306,13 +302,17 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
pci->atu_base = pci->dbi_base + 0xC0000;
+ ret = phy_init(pcie->phy);
+ if (ret)
+ goto phy_err;
+
intel_pcie_ltssm_disable(pcie);
intel_pcie_link_setup(pcie);
intel_pcie_init_n_fts(pci);
ret = dw_pcie_setup_rc(&pci->pp);
if (ret)
- goto app_init_err;
+ goto err;
dw_pcie_upconfig_setup(pci);
@@ -321,17 +321,18 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
ret = dw_pcie_wait_for_link(pci);
if (ret)
- goto app_init_err;
+ goto err;
intel_pcie_core_irq_enable(pcie);
return 0;
-app_init_err:
+err:
+ phy_exit(pcie->phy);
+phy_err:
clk_disable_unprepare(pcie->core_clk);
clk_err:
intel_pcie_core_rst_assert(pcie);
- phy_exit(pcie->phy);
return ret;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/7] MAINTAINERS: Remove bouncing intel-gw maintainer
From: Florian Eckert @ 2026-04-01 9:31 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de>
The maintainer's email address has been bouncing for months. Mark the PCI
intel-gw driver as orphaned.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 96ea84948d76aff5e07579911d0f370ae13f481b..26f3b2e192fa9ef2e1c89d2310bebaa0a67dff00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20505,9 +20505,8 @@ F: Documentation/devicetree/bindings/pci/intel,keembay-pcie*
F: drivers/pci/controller/dwc/pcie-keembay.c
PCIE DRIVER FOR INTEL LGM GW SOC
-M: Chuanhua Lei <lchuanhua@maxlinear.com>
L: linux-pci@vger.kernel.org
-S: Maintained
+S: Orphan
F: Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
F: drivers/pci/controller/dwc/pcie-intel-gw.c
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/7] PCI: intel-gw: Fixes to make the driver working again
From: Florian Eckert @ 2026-04-01 9:31 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
This patch series fixes and improve the 'intel-gw' driver to work again
with the current dwc pcie framework. The following changes are:
* Move interrupt 'enable' to its own function to improve readability,
and add additional register writes just as the Maxlinear kernel does in
their SDK.
* Enable clock for the PHY before PHY init call.
* Add missing 'start_link' callback. That was added to the PCIe dwc
framework.
* Move ATU base address assignment to the probe function and also add the
the possibility to read it from the devicetree by dwc core.
* Update devicetree documentation for intel-gw-pcie.yaml
* Remove unused preprocessor define.
* Mark driver as orphaned as the maitainer's email no longer works
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
Changes in v3:
- Update commit messages.
- Correct the sample code for dt bindings by adding the missing quotation
marks. Add 'minItems: 3' to avoid ABI issues.
- Move driver atu base assignment to probe function and keep backward
compatibility.
- Link to v2: https://lore.kernel.org/r/20260330-pcie-intel-gw-v2-0-8bd07367a298@dev.tdt.de
Changes in v2:
- Added additional information to the commit descriptions
- Add additional patch to mark driver as orphaned as the maintainer's
email no longer works.
- Fix wrong error path for enable clock before phy init.
- Add new patch to update the devicetree documentation for the 'atu'
resource
- Add additional recipients responsible for documenting the dervicetree
bindings.
- Link to v1: https://lore.kernel.org/r/20260317-pcie-intel-gw-v1-0-7fe13726ad4f@dev.tdt.de
---
Florian Eckert (7):
MAINTAINERS: Remove bouncing intel-gw maintainer
PCI: intel-gw: Remove unused define
PCI: intel-gw: Move interrupt enable to own function
PCI: intel-gw: Enable clock before phy init
PCI: intel-gw: Add start_link callback function
PCI: intel-gw: Move driver atu base assignment to probe function
dt-bindings: PCI: intel,lgm-pcie: Add atu resource
.../devicetree/bindings/pci/intel-gw-pcie.yaml | 6 +-
MAINTAINERS | 3 +-
drivers/pci/controller/dwc/pcie-intel-gw.c | 73 +++++++++++++++-------
3 files changed, 56 insertions(+), 26 deletions(-)
---
base-commit: ae6bbabc313433c724e15465c8b2341e02e2f0d7
change-id: 20260317-pcie-intel-gw-50902113f9e1
Best regards,
--
Florian Eckert <fe@dev.tdt.de>
^ permalink raw reply
* [PATCH v3 3/7] PCI: intel-gw: Move interrupt enable to own function
From: Florian Eckert @ 2026-04-01 9:31 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de>
To improve the readability of the code, move the interrupt enable
instructions to a separate function. That is already done for the disable
interrupt instruction.
In addtion, all pending interrupts are cleared and disabled, just as this
is done in the disable function 'intel_pcie_core_irq_disable()'. After
that, all relevant interrupts are enabled again. The 'PCIE_APP_IRNEN'
definition contains all the relevant interrupts that are of interest.
This change is also done in the Maxlinear SDK [1]. As I unfortunately
don’t have any documentation for this IP core, I suspect that the
intention is to set the IP core for interrupt handling to a specific
state. Perhaps the problem was that the IP core did not reinitialize the
interrupt register properly after a power cycle.
In my view, it can’t do any harm to switch the interrupt off and then on
again to set them to a specific state.
[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L431
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index 80d1607c46cbbb1e274b37a0bb9377a877678f5d..e88b8243cc41c607c39e4d58c4dcd8c8c082e8b0 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -195,6 +195,13 @@ static void intel_pcie_device_rst_deassert(struct intel_pcie *pcie)
gpiod_set_value_cansleep(pcie->reset_gpio, 0);
}
+static void intel_pcie_core_irq_enable(struct intel_pcie *pcie)
+{
+ pcie_app_wr(pcie, PCIE_APP_IRNEN, 0);
+ pcie_app_wr(pcie, PCIE_APP_IRNCR, PCIE_APP_IRN_INT);
+ pcie_app_wr(pcie, PCIE_APP_IRNEN, PCIE_APP_IRN_INT);
+}
+
static void intel_pcie_core_irq_disable(struct intel_pcie *pcie)
{
pcie_app_wr(pcie, PCIE_APP_IRNEN, 0);
@@ -316,9 +323,7 @@ static int intel_pcie_host_setup(struct intel_pcie *pcie)
if (ret)
goto app_init_err;
- /* Enable integrated interrupts */
- pcie_app_wr_mask(pcie, PCIE_APP_IRNEN, PCIE_APP_IRN_INT,
- PCIE_APP_IRN_INT);
+ intel_pcie_core_irq_enable(pcie);
return 0;
--
2.47.3
^ permalink raw reply related
* [PATCH v3 2/7] PCI: intel-gw: Remove unused define
From: Florian Eckert @ 2026-04-01 9:31 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260401-pcie-intel-gw-v3-0-63b008c5b7b2@dev.tdt.de>
The C preprocessor define 'PCIE_APP_INTX_OFST' is not used in the sources
and can therefore be deleted.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c b/drivers/pci/controller/dwc/pcie-intel-gw.c
index c21906eced61896c8a8307dbd6b72d229f9a5c5f..80d1607c46cbbb1e274b37a0bb9377a877678f5d 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -47,7 +47,6 @@
#define PCIE_APP_IRN_INTD BIT(16)
#define PCIE_APP_IRN_MSG_LTR BIT(18)
#define PCIE_APP_IRN_SYS_ERR_RC BIT(29)
-#define PCIE_APP_INTX_OFST 12
#define PCIE_APP_IRN_INT \
(PCIE_APP_IRN_AER_REPORT | PCIE_APP_IRN_PME | \
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 3/3] ARM: dts: qcom: msm8960: expressatt: Add MAX17048 fuel gauge
From: Konrad Dybcio @ 2026-04-01 9:28 UTC (permalink / raw)
To: guptarud, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-expressatt_fuel_guage-v2-3-947922834df1@gmail.com>
On 4/1/26 10:28 AM, Rudraksha Gupta via B4 Relay wrote:
> From: Rudraksha Gupta <guptarud@gmail.com>
>
> Add MAX17048 fuel gauge support.
>
> Tested by comparing battery capacity readings between upstream (mainline
> max17040 driver) and downstream (Samsung max17048_fuelgauge driver)
> across a full discharge cycle. Upstream reads ~3% lower throughout. Both
> track the discharge curve correctly:
>
> Upstream: 95 92 88 87 86 87 83 82 80 68 60 55 50 45 40 35 30 20 16 10 10 5 5 1
> Downstream: 95 94 92 91 91 89 87 86 84 73 64 59 51 48 43 38 33 23 17 14 12 8 6 3
>
> Each pair of readings was collected by checking the upstream capacity
> first, then moving the battery to a second expressatt running downstream
> Android to check its capacity. The battery was then moved back to the
> upstream device for the next reading. This swap occasionally caused the
> upstream capacity to read slightly higher than the previous value
> (e.g. 86 -> 87). When this happened, the reading was retaken after the
> value settled.
Ha, nice procedure!
Older phones used to chew through batteries on bootup, so perhaps that
could have had measurable impact as well..
[...]
> +&gsbi5_i2c {
> + status = "okay";
> +
> + fuel-gauge@36 {
> + compatible = "maxim,max17048";
> + reg = <0x36>;
> + maxim,double-soc;
> + maxim,rcomp = /bits/ 8 <0x62>;
> + maxim,alert-low-soc-level = <2>;
> + interrupt-parent = <&tlmm>;
> + interrupts = <67 IRQ_TYPE_EDGE_FALLING>;
interrupts-extended = <&tlmm 67 IRQ...>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v9 5/6] reset: rzv2h-usb2phy: Convert to regmap API
From: Philipp Zabel @ 2026-04-01 9:25 UTC (permalink / raw)
To: Tommaso Merciai
Cc: tomm.merciai, peda, linux-renesas-soc, biju.das.jz,
Fabrizio Castro, Lad Prabhakar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Greg Kroah-Hartman,
Josua Mayer, Ulf Hansson, devicetree, linux-kernel
In-Reply-To: <aczhCMdmi9cpkGkM@tom-desktop>
On Mi, 2026-04-01 at 11:10 +0200, Tommaso Merciai wrote:
[...]
>
> Then we can have:
>
> static const struct reg_sequence rzv2h_init_seq[] = {
> { .reg = 0xc10, .def = 0x67c },
> { .reg = 0xc14, .def = 0x01f },
> { .reg = 0x600, .def = 0x909 },
> };
>
> static const struct reg_sequence rzv2h_assert_seq[] = {
> { .reg = 0xb04, .def = 0x303 },
> { .reg = 0x000, .def = 0x206, .delay_us = 20 },
This will call fsleep(20), which maps to usleep_range(20, 25).
Please comment on why the delay is changed in the commit message.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM: dts: qcom: msm8960: Add GSBI5 I2C controller
From: Konrad Dybcio @ 2026-04-01 9:26 UTC (permalink / raw)
To: guptarud, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-expressatt_fuel_guage-v2-2-947922834df1@gmail.com>
On 4/1/26 10:28 AM, Rudraksha Gupta via B4 Relay wrote:
> From: Rudraksha Gupta <guptarud@gmail.com>
>
> Add the I2C controller node for GSBI5 (gpio24/gpio25) alongside
> its pinctrl default and sleep states.
>
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
> arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 35 ++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
> index fd28401cebb5..2088baef6c30 100644
> --- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
> +++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
> @@ -185,6 +185,24 @@ i2c3-pins {
> };
> };
>
> + i2c5_default_state: i2c5-default-state {
> + i2c5-pins {
You can drop this inner layer (i2c5-pins {}) and store the properties
directly under the -state {} node
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/7] cache: ax45mp_cache: refactor cache driver for generic Andes platform support
From: Conor Dooley @ 2026-04-01 9:25 UTC (permalink / raw)
To: Mina Chou
Cc: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc, tim609,
alex749, az70021
In-Reply-To: <acyDUU3FdAAPWfnS@atcsi01.andestech.com>
[-- Attachment #1: Type: text/plain, Size: 2946 bytes --]
On Wed, Apr 01, 2026 at 10:30:41AM +0800, Mina Chou wrote:
> Thank you both, Krzysztof and Conor, for the detailed review.
> I appreciate the feedback and admit this series needed more work
> before sending. I will address all the issues in the next version.
People making mistakes is whatever, as long as they don't keep making
them!
> A bit of background on the motivation: the main goal of this series
> was to prepare the Andes cache driver for a SoC Allwinner Avaotaf1 V821,
> which uses the Andes A27L2 CPU. We wanted to share a single cache driver
> across different Andes CPU variants, which is why we tried to move toward
I don't mind the kernel-side renaming all that much, the compatible
rename is what's problematic.
> more generic naming in both the driver and the compatible strings.
>
> We have two questions we'd appreciate guidance on:
> a) On compatible string naming: We'll drop patch [5/7][6/7] and won't
> rename any existing compatible strings. But we'd like to confirm
> the preferred approach for A27L2: would it be acceptable to add
> a generic compatible (andestech,andes-llcache) as an addition?
> If so, would a CPU-specific compatible (andestech,a27l2-cache)
> still be required alongside it?
Yes. I think that this cpu-specific compatible is what actually has
value, and adding something generic to all andes CPUs is a "nice to
have" convenience. Also, "andestech,andes-llcache" is a bit of a weak
name, repeating "andes" has no value. There's no code-name or something
for the IP that we could use instead of the second "andes" here?
> b) On Avaotaf1 V821 support: We are not in a position to submit the
> DTS on behalf of Allwinner. However, we would like to add the
> corresponding compatible strings to the existing binding
> documents (andestech,andes-llcache.yaml, sifive,plic-1.0.0.yaml,
> and riscv/cpus.yaml) in advance, so that the bindings are ready
> when Allwinner eventually submits their DTS.
> Would it be acceptable to upstream binding-only changes without
> an accompanying DTS at this stage?
Yes, of course. You're not willing to submit the dts, which is
understandable, but for the cache and plic bindings, you are able to add
the soc-specific compatibles for this device, right?
> For the next version, we're thinking of keeping only the changes
> needed to generalize the cache driver, and dropping the improvements
> for now to keep things focused. If you have any suggestion on how
> to approach this, we'd love to hear it.
Whatever you want. The improvements (or at least the things I think
are improvements) seem worth having. The problem was just patches doing
multiple things at once. If you decide to only do the generalisation,
that's fine, just make sure it is broken down so that each of your
bullet points in the commit messages.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: power: qcom,rpmhpd: Add new power domains and new levels
From: Konrad Dybcio @ 2026-04-01 9:21 UTC (permalink / raw)
To: Fenglin Wu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Ulf Hansson
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel
In-Reply-To: <20260401-haw-rpmhpd-v1-2-c830c79ed8f9@oss.qualcomm.com>
On 4/1/26 11:15 AM, Fenglin Wu wrote:
> Add definitions for the new power domains which present in Hawi SoC:
> - RPMHPD_DCX (Display Core X): supplies VDD_DISP for the display
> subsystem
> - RPMHPD_GBX (Graphics Box): supplies VDD_GFX_BX for the GPU/graphics
> subsystem
>
> Also, add constants for new power domain levels that supported in Hawi
> SoC, including: LOW_SVS_D3_0, LOW_SVS_D1_0, LOW_SVS_D0_0, SVS_L2_0,
> TURBO_L1_0/1/2, TURBO_L1_0/1/2.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Konrad Dybcio @ 2026-04-01 9:21 UTC (permalink / raw)
To: Fenglin Wu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Ulf Hansson
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel
In-Reply-To: <20260401-haw-rpmhpd-v1-3-c830c79ed8f9@oss.qualcomm.com>
On 4/1/26 11:15 AM, Fenglin Wu wrote:
> Add the RPMh power domains required for the Hawi SoC. This includes
> new definitions for domains supplying specific hardware components:
> - DCX: supplies VDD_DISP
> - GBX: supplies VDD_GFX_BX
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: x1e80100-dell-xps13-9345: introduce EC
From: Konrad Dybcio @ 2026-04-01 9:20 UTC (permalink / raw)
To: Aleksandrs Vinarskis, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
laurentiu.tudor1, Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <20260401-dell-xps-9345-ec-v1-4-afa5cacd49be@vinarskis.com>
On 4/1/26 9:33 AM, Aleksandrs Vinarskis wrote:
> Describe embedded controller, its interrupt and required thermal zones.
> Add EC's reset GPIO to reserved range, as triggering it during device
> operation leads to unrecoverable and unusable state.
>
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
[...]
> + io-channels = <&pmk8550_vadc PM8350_ADC7_GPIO3_100K_PU(1)>,
> + <&pmk8550_vadc PM8350_ADC7_GPIO4_100K_PU(1)>,
> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM1_100K_PU(1)>,
> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM2_100K_PU(1)>,
> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM3_100K_PU(1)>,
> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM4_100K_PU(1)>,
> + <&pmk8550_vadc PM8350_ADC7_AMUX_THM5_100K_PU(1)>;
> +
> + io-channel-names = "sys_therm0", "sys_therm1", "sys_therm2",
> + "sys_therm3", "sys_therm4", "sys_therm5",
> + "sys_therm6";
nit: one a line please, without a separating \n between x and x-names
[...]
> +&pmk8550_vadc {
> + /* sys_therm0, around DRAM */
another nit: I think repeating the name set in the label in each comment
is a little excessive
[...]
> &tlmm {
> gpio-reserved-ranges = <44 4>, /* SPI11 (TPM) */
> + <65 1>, /* EC Reset */
Is that a "this may not be accessed" or rather "you can, but it has dire
consequences"?
Would the EC driver/binding benefit from having a reference to that pin?
Konrad
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: hamoa-pmics: define VADC for pmk8550
From: Konrad Dybcio @ 2026-04-01 9:19 UTC (permalink / raw)
To: Aleksandrs Vinarskis, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
laurentiu.tudor1, Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <20260401-dell-xps-9345-ec-v1-3-afa5cacd49be@vinarskis.com>
On 4/1/26 9:33 AM, Aleksandrs Vinarskis wrote:
> Follow pattern of pmk8350 to add missing pmk8550 VADC to hamoa.
> Register address of 0x9000 matches example schema for spmi-adc5-gen3.
>
> Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> ---
> arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi b/arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi
> index 6a31a0adf8be472badea502a916cdbc9477e9f2b..58c0dd3ccca70bce3424f83bfd5a52b1fef35c2e 100644
> --- a/arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa-pmics.dtsi
> @@ -218,6 +218,17 @@ pon_resin: resin {
> };
> };
>
> + pmk8550_vadc: adc@9000 {
> + compatible = "qcom,spmi-adc5-gen3";
> + reg = <0x9000>, <0x9100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <0x0 0x90 0x1 IRQ_TYPE_EDGE_RISING>,
> + <0x0 0x91 0x1 IRQ_TYPE_EDGE_RISING>;
> + #io-channel-cells = <1>;
> + #thermal-sensor-cells = <1>;
You can probably add the DIE_TEMP/XO_THERM channels here directly
Konrad
^ permalink raw reply
* Re: [EXT] Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Daniel Baluta @ 2026-04-01 9:19 UTC (permalink / raw)
To: Guangliu Ding, Liviu Dudau
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB47073E9E8B5C704BCF5D9F72F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On 4/1/26 11:48, Guangliu Ding wrote:
> [You don't often get email from guangliu.ding@nxp.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Liviu
>
> Thanks for your review. Please refer to my comments below:
>
>> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
>>> Add compatible string of Mali G310 GPU on i.MX952 board.
>>>
>>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
>>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
>>> ---
>>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> index 8eccd4338a2b..6a10843a26e2 100644
>>> --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> @@ -20,6 +20,7 @@ properties:
>>> - enum:
>>> - mediatek,mt8196-mali
>>> - nxp,imx95-mali # G310
>>> + - nxp,imx952-mali # G310
>> Can you explain why this is needed? Can it not be covered by the existing
>> compatible?
> There are functional differences in GPU module (GPUMIX) between i.MX95
> and i.MX952. So they cannot be fully covered by a single existing compatible.
> On i.MX952, The GPU clock is controlled by hardware GPU auto clock-gating
> mechanism, while the GPU clock is managed explicitly by the driver on i.MX95.
> Because of these behavioral differences, separate compatible strings
> "nxp,imx95-mali" and "nxp,imx952-mali" are needed to allow the driver to handle
> the two variants independently and to keep room for future divergence.
This information should be added in the commit message explaining why
the change is needed.
But then where is the driver code taking care of these diferences?
^ permalink raw reply
* Re: [PATCH 2/4] platform: arm64: dell-xps-ec: new driver
From: Konrad Dybcio @ 2026-04-01 9:16 UTC (permalink / raw)
To: Aleksandrs Vinarskis, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen, Bryan O'Donoghue
Cc: linux-arm-msm, devicetree, linux-kernel, platform-driver-x86,
laurentiu.tudor1, Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <20260401-dell-xps-9345-ec-v1-2-afa5cacd49be@vinarskis.com>
On 4/1/26 9:33 AM, Aleksandrs Vinarskis wrote:
> Introduce EC driver for Dell XPS 13 9345 (codename 'tributo') which may
> partially of fully compatible with Snapdragon-based Dell Latitude,
> Inspiron ('thena'). Primary function of this driver is unblock EC's
> thermal management, specifically to provide it with necessary
> information to control device fans, peripherals power.
[...]
> +/*
> + * Format:
> + * - header/unknown (2 bytes)
> + * - per-thermistor entries (3 bytes): thermistor_id, param1, param2
> + */
> +static const u8 dell_xps_ec_thermistor_profile[] = {
> + 0xff, 0x54,
This is super wishful thinking, but 0x54 is ASCII 'T', perhaps for
"Thermistor" or "Temp"?
> +static int dell_xps_ec_suspend_cmd(struct dell_xps_ec *ec, bool suspend)
> +{
> + u8 buf[DELL_XPS_EC_SUSPEND_MSG_LEN] = {};
> + int ret;
> +
> + buf[0] = DELL_XPS_EC_SUSPEND_CMD;
> + buf[1] = suspend ? 0x01 : 0x00;
> + /* bytes 2..63 remain zero */
buf[1] = suspend
(since it's a boolean argument)
[...]
> + schedule_delayed_work(&ec->temp_work,
> + msecs_to_jiffies(DELL_XPS_EC_TEMP_INTERVAL_MS));
> + dev_info(dev, "Started periodic temperature reporting to EC every %d ms\n",
> + DELL_XPS_EC_TEMP_INTERVAL_MS);
dev_dbg()?
> +
> + /* Request IRQ for EC events */
> + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> + dell_xps_ec_irq_handler,
> + IRQF_ONESHOT, dev_name(dev), ec);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "Failed to request IRQ\n");
> +
> + return 0;
> +}
> +
> +/*
> + * Notify EC of suspend
> + *
> + * This will:
> + * - Ramp down the fans
> + * - Cut power to display/trackpad/keyboard/touch row
> + * - Periodically (?) power them back, such that wake-up source still works
FWIW
https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: soc: renesas: Document MFIS IP core
From: Geert Uytterhoeven @ 2026-04-01 9:16 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Krzysztof Kozlowski, Marek Vasut, Magnus Damm,
Rob Herring, Conor Dooley, devicetree
In-Reply-To: <20260331104527.29170-2-wsa+renesas@sang-engineering.com>
Hi Wolfram.
On Tue, 31 Mar 2026 at 12:45, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> Document the Renesas Multifunctional Interface (MFIS) as found on the
> Renesas R-Car X5H (r8a78000) SoC. MFIS includes features like Mailbox/HW
> Spinlock/Product Register/Error Injection/Error Detection and the likes.
> Family-compatible values are not introduced here because MFIS is usually
> very different per SoC.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
> Changes since v2:
> * added interrupt constraints
> * fixed whitespaces in example (Thanks, Krzysztof, for both!)
Thanks for the update!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas,r8a78000-mfis.yaml
> + interrupts:
> + minItems: 32
> + maxItems: 128
> + description:
> + The interrupts raised by the remote doorbells.
> +
> + interrupt-names:
> + minItems: 32
> + maxItems: 128
[...]
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,r8a78000-mfis
> + then:
> + properties:
> + interrupts:
> + minItems: 128
> + maxItems: 128
You can drop the maxItems constraints here...
> + interrupt-names:
> + minItems: 128
> + maxItems: 128
... and here.
> + items:
> + pattern: "^ch[0-9]+[ie]$"
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,r8a78000-mfis-scp
> + then:
> + properties:
> + interrupts:
> + minItems: 32
You can drop the minItems constraints here...
> + maxItems: 32
> + interrupt-names:
> + minItems: 32
... and here.
> + maxItems: 32
> + items:
> + pattern: "^ch[0-9]+i$"
> +
As these don't impact correctness:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Fenglin Wu @ 2026-04-01 9:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu
In-Reply-To: <20260401-haw-rpmhpd-v1-0-c830c79ed8f9@oss.qualcomm.com>
Add the RPMh power domains required for the Hawi SoC. This includes
new definitions for domains supplying specific hardware components:
- DCX: supplies VDD_DISP
- GBX: supplies VDD_GFX_BX
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
index 19849703be4a..f5ae2a63765d 100644
--- a/drivers/pmdomain/qcom/rpmhpd.c
+++ b/drivers/pmdomain/qcom/rpmhpd.c
@@ -102,11 +102,21 @@ static struct rpmhpd cx_ao_w_mx_parent = {
.res_name = "cx.lvl",
};
+static struct rpmhpd dcx = {
+ .pd = { .name = "dcx", },
+ .res_name = "dcx.lvl",
+};
+
static struct rpmhpd ebi = {
.pd = { .name = "ebi", },
.res_name = "ebi.lvl",
};
+static struct rpmhpd gbx = {
+ .pd = { .name = "gbx", },
+ .res_name = "gbx.lvl",
+};
+
static struct rpmhpd gfx = {
.pd = { .name = "gfx", },
.res_name = "gfx.lvl",
@@ -622,6 +632,33 @@ static const struct rpmhpd_desc kaanapali_desc = {
.num_pds = ARRAY_SIZE(kaanapali_rpmhpds),
};
+/* Hawi RPMH powerdomains */
+static struct rpmhpd *hawi_rpmhpds[] = {
+ [RPMHPD_CX] = &cx,
+ [RPMHPD_CX_AO] = &cx_ao,
+ [RPMHPD_DCX] = &dcx,
+ [RPMHPD_EBI] = &ebi,
+ [RPMHPD_GBX] = &gbx,
+ [RPMHPD_GFX] = &gfx,
+ [RPMHPD_GMXC] = &gmxc,
+ [RPMHPD_LCX] = &lcx,
+ [RPMHPD_LMX] = &lmx,
+ [RPMHPD_MMCX] = &mmcx,
+ [RPMHPD_MMCX_AO] = &mmcx_ao,
+ [RPMHPD_MX] = &mx,
+ [RPMHPD_MX_AO] = &mx_ao,
+ [RPMHPD_MXC] = &mxc,
+ [RPMHPD_MXC_AO] = &mxc_ao,
+ [RPMHPD_MSS] = &mss,
+ [RPMHPD_NSP] = &nsp,
+ [RPMHPD_NSP2] = &nsp2,
+};
+
+static const struct rpmhpd_desc hawi_desc = {
+ .rpmhpds = hawi_rpmhpds,
+ .num_pds = ARRAY_SIZE(hawi_rpmhpds),
+};
+
/* QDU1000/QRU1000 RPMH powerdomains */
static struct rpmhpd *qdu1000_rpmhpds[] = {
[QDU1000_CX] = &cx,
@@ -796,6 +833,7 @@ static const struct rpmhpd_desc qcs615_desc = {
static const struct of_device_id rpmhpd_match_table[] = {
{ .compatible = "qcom,glymur-rpmhpd", .data = &glymur_desc },
+ { .compatible = "qcom,hawi-rpmhpd", .data = &hawi_desc },
{ .compatible = "qcom,kaanapali-rpmhpd", .data = &kaanapali_desc },
{ .compatible = "qcom,milos-rpmhpd", .data = &milos_desc },
{ .compatible = "qcom,qcs615-rpmhpd", .data = &qcs615_desc },
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: power: qcom,rpmhpd: Add new power domains and new levels
From: Fenglin Wu @ 2026-04-01 9:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu
In-Reply-To: <20260401-haw-rpmhpd-v1-0-c830c79ed8f9@oss.qualcomm.com>
Add definitions for the new power domains which present in Hawi SoC:
- RPMHPD_DCX (Display Core X): supplies VDD_DISP for the display
subsystem
- RPMHPD_GBX (Graphics Box): supplies VDD_GFX_BX for the GPU/graphics
subsystem
Also, add constants for new power domain levels that supported in Hawi
SoC, including: LOW_SVS_D3_0, LOW_SVS_D1_0, LOW_SVS_D0_0, SVS_L2_0,
TURBO_L1_0/1/2, TURBO_L1_0/1/2.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
include/dt-bindings/power/qcom,rpmhpd.h | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/include/dt-bindings/power/qcom,rpmhpd.h b/include/dt-bindings/power/qcom,rpmhpd.h
index 06851363ae0e..67e2634fdc99 100644
--- a/include/dt-bindings/power/qcom,rpmhpd.h
+++ b/include/dt-bindings/power/qcom,rpmhpd.h
@@ -28,15 +28,20 @@
#define RPMHPD_XO 18
#define RPMHPD_NSP2 19
#define RPMHPD_GMXC 20
+#define RPMHPD_DCX 21
+#define RPMHPD_GBX 22
/* RPMh Power Domain performance levels */
#define RPMH_REGULATOR_LEVEL_RETENTION 16
#define RPMH_REGULATOR_LEVEL_MIN_SVS 48
+#define RPMH_REGULATOR_LEVEL_LOW_SVS_D3_0 49
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D3 50
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D2_1 51
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D2 52
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D1_1 54
+#define RPMH_REGULATOR_LEVEL_LOW_SVS_D1_0 55
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D1 56
+#define RPMH_REGULATOR_LEVEL_LOW_SVS_D0_0 59
#define RPMH_REGULATOR_LEVEL_LOW_SVS_D0 60
#define RPMH_REGULATOR_LEVEL_LOW_SVS 64
#define RPMH_REGULATOR_LEVEL_LOW_SVS_P1 72
@@ -47,6 +52,7 @@
#define RPMH_REGULATOR_LEVEL_SVS_L0 144
#define RPMH_REGULATOR_LEVEL_SVS_L1 192
#define RPMH_REGULATOR_LEVEL_SVS_L2 224
+#define RPMH_REGULATOR_LEVEL_SVS_L2_0 225
#define RPMH_REGULATOR_LEVEL_NOM 256
#define RPMH_REGULATOR_LEVEL_NOM_L0 288
#define RPMH_REGULATOR_LEVEL_NOM_L1 320
@@ -54,8 +60,14 @@
#define RPMH_REGULATOR_LEVEL_TURBO 384
#define RPMH_REGULATOR_LEVEL_TURBO_L0 400
#define RPMH_REGULATOR_LEVEL_TURBO_L1 416
+#define RPMH_REGULATOR_LEVEL_TURBO_L1_0 417
+#define RPMH_REGULATOR_LEVEL_TURBO_L1_1 418
+#define RPMH_REGULATOR_LEVEL_TURBO_L1_2 419
#define RPMH_REGULATOR_LEVEL_TURBO_L2 432
#define RPMH_REGULATOR_LEVEL_TURBO_L3 448
+#define RPMH_REGULATOR_LEVEL_TURBO_L3_0 449
+#define RPMH_REGULATOR_LEVEL_TURBO_L3_1 450
+#define RPMH_REGULATOR_LEVEL_TURBO_L3_2 451
#define RPMH_REGULATOR_LEVEL_TURBO_L4 452
#define RPMH_REGULATOR_LEVEL_TURBO_L5 456
#define RPMH_REGULATOR_LEVEL_SUPER_TURBO 464
--
2.43.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: power: qcom,rpmpd: Add Hawi RPMh power domain
From: Fenglin Wu @ 2026-04-01 9:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu
In-Reply-To: <20260401-haw-rpmhpd-v1-0-c830c79ed8f9@oss.qualcomm.com>
Document the RPMh power domain for Hawi SoC.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 27af5b8aa134..35a0e01c2015 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -18,6 +18,7 @@ properties:
oneOf:
- enum:
- qcom,glymur-rpmhpd
+ - qcom,hawi-rpmhpd
- qcom,kaanapali-rpmhpd
- qcom,mdm9607-rpmpd
- qcom,milos-rpmhpd
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] power: qcom,rpmpd: add RPMh power doamins support for Hawi SoC
From: Fenglin Wu @ 2026-04-01 9:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu
Add constant definitions for the new power domains and new voltage
levels present in Hawi SoC. Also add RPMH power domain support for
Hawi SoC.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Fenglin Wu (3):
dt-bindings: power: qcom,rpmpd: Add Hawi RPMh power domain
dt-bindings: power: qcom,rpmhpd: Add new power domains and new levels
pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++
include/dt-bindings/power/qcom,rpmhpd.h | 12 +++++++
3 files changed, 51 insertions(+)
---
base-commit: 33b1a2ee3a3df63e7a08e51e6de2b2d28ddf257f
change-id: 20260401-haw-rpmhpd-b40a68a3ce79
Best regards,
--
Fenglin Wu <fenglin.wu@oss.qualcomm.com>
^ 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