* [PATCH v5 3/7] PCI: intel-gw: Move interrupt enable to own function
From: Florian Eckert @ 2026-04-17 8:35 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
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260417-pcie-intel-gw-v5-0-0a2b933fe04f@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 addition, 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 is 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.
The reason why the MaxLinear SDK is used as a reference here is, that this
pcie dwc IP is used in the URX851 and URX850 SoC. This SoC was originally
developed by Intel when they acquired Lantiq’s home networking division in
2015 [2]. In 2020 the home network division was sold to MaxLinear [3].
Since then, this SoC belongs to MaxLinear. They use their own SDK,
which runs on kernel version '5.15.x'.
[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L431
[2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home
[3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform
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 v5 4/7] PCI: intel-gw: Enable clock before phy init
From: Florian Eckert @ 2026-04-17 8:35 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
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260417-pcie-intel-gw-v5-0-0a2b933fe04f@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.
The reason why the MaxLinear SDK is used as a reference here is, that this
pcie dwc IP is used in the URX851 and URX850 SoC. This SoC was originally
developed by Intel when they acquired Lantiq’s home networking division in
2015 [2]. In 2020 the home network division was sold to MaxLinear [3].
Since then, this SoC belongs to MaxLinear. They use their own SDK,
which runs on kernel version '5.15.x'.
[1] https://github.com/maxlinear/linux/blob/updk_9.1.90/drivers/pci/controller/dwc/pcie-intel-gw.c#L544
[2] https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home
[3] https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform
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 v5 5/7] PCI: intel-gw: Add start_link callback function
From: Florian Eckert @ 2026-04-17 8:35 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
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260417-pcie-intel-gw-v5-0-0a2b933fe04f@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 v5 6/7] PCI: intel-gw: Move driver atu base assignment to probe function
From: Florian Eckert @ 2026-04-17 8:35 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
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260417-pcie-intel-gw-v5-0-0a2b933fe04f@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' offset 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. Therefore
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 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://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-designware.h?h=v7.0#n292
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-designware.c?h=v7.0#n150
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-designware-host.c?h=v7.0#n588
[4] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-intel-gw.c?h=v7.0#n301
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 v5 0/7] PCI: intel-gw: Fixes to make the driver working again
From: Florian Eckert @ 2026-04-17 8:35 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
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
This 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 v5:
- Also add the DTS 'minItems' option for 'reg-names'.
- Add missing quotation marks to the DTS example change to make the DTS
bot hopefully happy.
- Link to v4: https://lore.kernel.org/r/20260415-pcie-intel-gw-v4-0-ad45d2418c8e@dev.tdt.de
Changes in v4:
- Add 'atu' to the end of the resource definition to ensure backwords
compatibility.
- Updated the commit description to explain why the MaxLinear SDK is used
as a reference.
- Remove 'Rahul Tanwar <rtanwar@maxlinear.com>' out of the loop, as the email
address is no longer valid and is being rejected.
- Link to v3: https://lore.kernel.org/r/20260401-pcie-intel-gw-v3-0-63b008c5b7b2@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 | 9 ++-
MAINTAINERS | 3 +-
drivers/pci/controller/dwc/pcie-intel-gw.c | 73 +++++++++++++++-------
3 files changed, 58 insertions(+), 27 deletions(-)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260317-pcie-intel-gw-50902113f9e1
Best regards,
--
Florian Eckert <fe@dev.tdt.de>
^ permalink raw reply
* [PATCH v5 2/7] PCI: intel-gw: Remove unused define
From: Florian Eckert @ 2026-04-17 8:35 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
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260417-pcie-intel-gw-v5-0-0a2b933fe04f@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
* [PATCH v5 1/7] MAINTAINERS: Remove bouncing intel-gw maintainer
From: Florian Eckert @ 2026-04-17 8:35 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
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260417-pcie-intel-gw-v5-0-0a2b933fe04f@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 d1cc0e12fe1f004da89b1aa339116908f642e894..725f333f265bef416b5144c56649cb6eae736e40 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20518,9 +20518,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 v5 7/7] dt-bindings: PCI: intel,lgm-pcie: Add atu resource
From: Florian Eckert @ 2026-04-17 8:35 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
Cc: linux-pci, linux-kernel, devicetree, Florian Eckert,
Eckert.Florian, ms
In-Reply-To: <20260417-pcie-intel-gw-v5-0-0a2b933fe04f@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 compatible, this field is not mandatory. If 'atu'
resource is not specified in the devicetree, the driver’s default value
is used.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
---
Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
index 54e2890ae6314ac6847fc23f49440d05d66d87d4..394bb46b38e601345429de828f491980f8058d25 100644
--- a/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/intel-gw-pcie.yaml
@@ -27,16 +27,20 @@ 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:
+ minItems: 3
items:
- const: dbi
- const: config
- const: app
+ - const: atu
ranges:
maxItems: 1
@@ -95,8 +99,9 @@ examples:
#size-cells = <2>;
reg = <0xd0e00000 0x1000>,
<0xd2000000 0x800000>,
- <0xd0a41000 0x1000>;
- reg-names = "dbi", "config", "app";
+ <0xd0a41000 0x1000>,
+ <0xd0ec0000 0x1000>;
+ reg-names = "dbi", "config", "app", "atu";
linux,pci-domain = <0>;
max-link-speed = <4>;
bus-range = <0x00 0x08>;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v10 02/11] lib: kstrtox: add kstrtoudec64() and kstrtodec64()
From: Rodrigo Alencar @ 2026-04-17 8:36 UTC (permalink / raw)
To: Rodrigo Alencar, linux-kernel, linux-iio, devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260415-adf41513-iio-driver-v10-2-df61046d5457@analog.com>
On 26/04/15 10:51AM, Rodrigo Alencar wrote:
> Add helpers that parses decimal numbers into 64-bit number, i.e., decimal
> point numbers with pre-defined scale are parsed into a 64-bit value (fixed
> precision). After the decimal point, digits beyond the specified scale
> are ignored.
...
> +static int _kstrtoudec64(const char *s, unsigned int scale, u64 *res)
> +{
> + u64 _res = 0, _frac = 0;
> + unsigned int rv;
> +
> + if (scale > 19) /* log10(2^64) = 19.26 */
> + return -EINVAL;
> +
> + if (*s != '.') {
> + rv = _parse_integer(s, 10, &_res);
> + if (rv & KSTRTOX_OVERFLOW)
> + return -ERANGE;
> + if (rv == 0)
> + return -EINVAL;
> + s += rv;
> + }
> +
> + if (*s == '.' && scale) {
> + s++; /* skip decimal point */
> + rv = _parse_integer_limit(s, 10, &_frac, scale);
> + if (rv & KSTRTOX_OVERFLOW)
> + return -ERANGE;
> + if (rv == 0)
> + return -EINVAL;
> + s += rv;
> + if (rv < scale)
> + _frac *= int_pow(10, scale - rv);
> + while (isdigit(*s)) /* truncate */
> + s++;
> + }
> +
> + if (*s == '\n')
> + s++;
> + if (*s)
> + return -EINVAL;
> +
> + if (check_mul_overflow(_res, int_pow(10, scale), &_res) ||
> + check_add_overflow(_res, _frac, &_res))
> + return -ERANGE;
> +
> + *res = _res;
> + return 0;
> +}
I have an alternative (slightly more complex) implementation of this function
that handles E notation. I find this particularly handy when writting big
values like 25 GHz when the ABI is defined in Hz, so instead of writing
25000000000, one can just use 25e9, or 2.5e10. I found that my python code
was printing big floating point values or really small ones using E notation
and that was giving me -EINVAL, so I had to adjust formatting when generating
the string input to the file. No big deal, and we would not need this here,
but if maintainers find this useful I could add it into a v11 of this series.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 2/5] media: synopsys: Add support for multiple streams
From: Frank Li @ 2026-04-17 8:38 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-2-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:53AM +0800, Guoniu Zhou wrote:
> The current driver only supports single stream operation. Add support
> for multiple concurrent streams by tracking enabled streams with a
> bitmask and only initializing the hardware once for the first stream.
>
> This enables use cases such as surround view systems where multiple
> camera streams need to be processed simultaneously through the same
> CSI-2 receiver interface.
Look like this driver only one sink and one source pad, how to implement
multiple stream.
Frank
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v7 2/2] arm64: defconfig: enable BST SDHCI controller
From: gordon.ge @ 2026-04-17 8:38 UTC (permalink / raw)
To: yangzh0906
Cc: krzk, arnd, krzk+dt, robh, conor+dt, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260310091211.4171307-3-yangzh0906@thundersoft.com>
Acked-by: Gordon Ge <gordon.ge@bst.ai>
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: dts: bst: enable eMMC controller in C1200 CDCU1.0 board
From: gordon.ge @ 2026-04-17 8:47 UTC (permalink / raw)
To: yangzh0906
Cc: krzk, arnd, krzk+dt, robh, conor+dt, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260310091211.4171307-2-yangzh0906@thundersoft.com>
Acked-by: Gordon Ge <gordon.ge@bst.ai>
^ permalink raw reply
* [PATCH v5 0/2] Add Xiaomi 12 Lite 5G (taoyao) device tree
From: Stanislav Zaikin @ 2026-04-17 8:47 UTC (permalink / raw)
To: devicetree
Cc: linux-arm-msm, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-kernel, val, Stanislav Zaikin
This series adds device tree support for the Xiaomi 12 Lite 5G (taoyao),
based on the Qualcomm SM7325 SoC.
The display panel model is unknown, so bootloader-initialized
simple-framebuffer is therefore used to expose the display.
Changes in v5:
- Patch no. 1 - no changes
- Change vccq-supply to vccq2-supply in ufs node as it's ufs2.2 (patch no. 2)
- Val's patch for goodix-berlin didn't have effect on my touchscreen,
therefore keep the touchscreen szie (no changes in this regard in
patch no. 2)
- Link to v4:
https://lore.kernel.org/all/20260305093941.305122-1-zstaseg@gmail.com/
Changes in v4:
- Patch no. 1 - no changes
- Removed Konrad's R-b tag, please take a look again (patch no. 2)
- Fixed vreg_s2b_0p7 regulator name to spmb2 (patch no. 2)
- Switched bluetooth to wcn6750-pmu (patch no. 2)
- Dropped qcom,local-bd-address-broken as it has no effect (patch no. 2)
- Added wifi calibration variant "Xiaomi_taoyao" (also sent board-2.bin
files to ath11k) (patch no. 2)
- Link to v3:
https://lore.kernel.org/all/20260224114424.1966947-1-zstaseg@gmail.com/
Changes in v3:
- Patch no. 1 - no changes
- Drop unit address for framebuffer node (patch no. 2)
- Add Konrad's R-b tag (patch no. 2)
- Link to v2:
https://lore.kernel.org/all/20260216120715.3432191-1-zstaseg@gmail.com/
Changes in v2:
- Add Rob's A-b tag (patch no. 1)
- Add explicit framebuffer_reserved label (patch no. 2)
- Use memory-region for simple-framebuffer (patch no. 2)
- Fix reserved-memory naming: make node names consistent with labels
and intended subsystem (CVP/camera/video) (patch no. 2)
- Convert mem-type value from <0x02> to <2> (patch no. 2)
- Fix s2b regulator comment style (patch no. 2)
- Remove unused gpio-reserved-ranges entry (<32 2>) (patch no. 2)
- Link to v1:
https://lore.kernel.org/all/20260204115645.1343750-1-zstaseg@gmail.com/
Stanislav Zaikin (2):
dt-bindings: arm: qcom: Add SM7325 Xiaomi 12 Lite 5G (taoyao)
arm64: dts: qcom: Add Xiaomi 12 Lite 5G (taoyao) DTS
.../devicetree/bindings/arm/qcom.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sm7325-xiaomi-taoyao.dts | 907 ++++++++++++++++++
3 files changed, 909 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm7325-xiaomi-taoyao.dts
--
2.51.0
^ permalink raw reply
* [PATCH v5 1/2] dt-bindings: arm: qcom: Add SM7325 Xiaomi 12 Lite 5G (taoyao)
From: Stanislav Zaikin @ 2026-04-17 8:47 UTC (permalink / raw)
To: devicetree
Cc: linux-arm-msm, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-kernel, val, Stanislav Zaikin
In-Reply-To: <20260417084749.253242-1-zstaseg@gmail.com>
Xiaomi 12 Lite 5G (xiaomi,taoyao) is a smartphone based on the SM7325
SoC.
Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d84bd3bca201..711cf3bba6e8 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -982,6 +982,7 @@ properties:
- items:
- enum:
- nothing,spacewar
+ - xiaomi,taoyao
- const: qcom,sm7325
- items:
--
2.51.0
^ permalink raw reply related
* [PATCH v5 2/2] arm64: dts: qcom: Add Xiaomi 12 Lite 5G (taoyao) DTS
From: Stanislav Zaikin @ 2026-04-17 8:47 UTC (permalink / raw)
To: devicetree
Cc: linux-arm-msm, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-kernel, val, Stanislav Zaikin
In-Reply-To: <20260417084749.253242-1-zstaseg@gmail.com>
Xiaomi 12 Lite 5G is a handset released in 2022
This commit has the following features working:
- Display (with simple fb)
- Touchscreen
- UFS
- Power and volume buttons
- Pinctrl
- RPM Regulators
- Remoteprocs - wifi, bluetooth
- USB (Device Mode)
Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/sm7325-xiaomi-taoyao.dts | 907 ++++++++++++++++++
2 files changed, 908 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/sm7325-xiaomi-taoyao.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f34d5ed331c..61618da3f68c 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -280,6 +280,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sm7125-xiaomi-curtana.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7125-xiaomi-joyeuse.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7225-fairphone-fp4.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm7325-nothing-spacewar.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sm7325-xiaomi-taoyao.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8150-hdk.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8150-microsoft-surface-duo.dtb
dtb-$(CONFIG_ARCH_QCOM) += sm8150-mtp.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm7325-xiaomi-taoyao.dts b/arch/arm64/boot/dts/qcom/sm7325-xiaomi-taoyao.dts
new file mode 100644
index 000000000000..8baaf0bb7630
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm7325-xiaomi-taoyao.dts
@@ -0,0 +1,907 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (c) 2025, Stanislav Zaikin <zstaseg@gmail.com>
+ */
+
+/dts-v1/;
+
+/* PM7250B is configured to use SID8/9 */
+#define PM7250B_SID 8
+#define PM7250B_SID1 9
+
+#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pm7325.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include <dt-bindings/sound/qcom,q6afe.h>
+#include <dt-bindings/sound/qcom,q6asm.h>
+
+#include "sm7325.dtsi"
+#include "pm7325.dtsi"
+#include "pm7250b.dtsi" /* PM7250B */
+#include "pm8350c.dtsi" /* PM7350C */
+#include "pmk8350.dtsi" /* PMK7325 */
+
+/* The following reserved memory regions have different addresses or sizes */
+/delete-node/ &adsp_mem;
+/delete-node/ &cdsp_mem;
+/delete-node/ &rmtfs_mem;
+
+/ {
+ model = "Xiaomi 12 Lite 5G";
+ compatible = "xiaomi,taoyao", "qcom,sm7325";
+ chassis-type = "handset";
+
+ aliases {
+ serial0 = &uart5;
+ serial1 = &uart7;
+ };
+
+ chosen {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ framebuffer0: framebuffer {
+ compatible = "simple-framebuffer";
+ memory-region = <&framebuffer_reserved>;
+ width = <1080>;
+ height = <2400>;
+ stride = <(1080 * 4)>;
+ format = "a8r8g8b8";
+
+ clocks = <&gcc GCC_DISP_HF_AXI_CLK>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&key_vol_up>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ gpios = <&pm7325_gpios 6 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_VOLUMEUP>;
+ };
+ };
+
+ pmic-glink {
+ compatible = "qcom,sm7325-pmic-glink",
+ "qcom,qcm6490-pmic-glink",
+ "qcom,pmic-glink";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ orientation-gpios = <&tlmm 140 GPIO_ACTIVE_HIGH>;
+
+ connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ power-role = "dual";
+ data-role = "dual";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ pmic_glink_hs_in: endpoint {
+ remote-endpoint = <&usb_1_dwc3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ pmic_glink_sbu: endpoint {
+ remote-endpoint = <&fsa4480_sbu_mux>;
+ };
+ };
+ };
+ };
+ };
+
+ vreg_oled_dvdd: regulator-oled-dvdd {
+ compatible = "regulator-fixed";
+ regulator-name = "oled_dvdd";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ gpio = <&tlmm 46 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vreg_s1b_1p856>;
+ regulator-boot-on;
+ };
+
+ /* S2B is really ebi.lvl but it's there for supply map completeness sake. */
+ vreg_s2b_0p7: regulator-smpb2 {
+ compatible = "regulator-fixed";
+ regulator-name = "vreg_s2b_0p7";
+
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <700000>;
+ regulator-always-on;
+ vin-supply = <&vph_pwr>;
+ };
+
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ };
+
+ reserved-memory {
+ cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
+ reg = <0x0 0x81800000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ cvp_mem: cvp@86200000 {
+ reg = <0x0 0x86200000 0x0 0x500000>;
+ no-map;
+ };
+
+ adsp_mem: adsp@86700000 {
+ reg = <0x0 0x86700000 0x0 0x4000000>;
+ no-map;
+ };
+
+ camera_mem: camera@8ad00000 {
+ reg = <0x0 0x8ad00000 0x0 0x500000>;
+ no-map;
+ };
+
+ ipa_gsi_mem: ipa-gsi@8b710000 {
+ reg = <0x0 0x8b710000 0x0 0xa000>;
+ no-map;
+ };
+
+ cdsp_mem: cdsp@9c700000 {
+ reg = <0x0 0x9c700000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ ramoops@a9000000 {
+ compatible = "ramoops";
+ reg = <0x0 0xa9000000 0x0 0x200000>;
+ pmsg-size = <0x200000>;
+ mem-type = <2>;
+ };
+
+ removed_mem: removed@c0000000 {
+ reg = <0x0 0xc0000000 0x0 0x6800000>;
+ no-map;
+ };
+
+ pil_trustedvm_mem: pil-trustedvm-region@d0800000 {
+ reg = <0x0 0xd0800000 0x0 0x76f7000>;
+ no-map;
+ };
+
+ qrtr_shmem: qrtr-shmem@d7ef7000 {
+ reg = <0x0 0xd7ef7000 0x0 0x9000>;
+ no-map;
+ };
+
+ neuron_block_0_mem: neuron-block@d7f00000 {
+ reg = <0x0 0xd7f00000 0x0 0x80000>;
+ no-map;
+ };
+
+ neuron_block_1_mem: neuron-block@d7f80000 {
+ reg = <0x0 0xd7f80000 0x0 0x80000>;
+ no-map;
+ };
+
+ framebuffer_reserved: framebuffer@e1000000 {
+ reg = <0x0 0xe1000000 0x0 (1080 * 2400 * 4)>;
+ no-map;
+ };
+
+ rmtfs_mem: rmtfs@ef500000 {
+ compatible = "qcom,rmtfs-mem";
+ reg = <0x0 0xe7d00000 0x0 0x280000>;
+ no-map;
+
+ qcom,client-id = <1>;
+ qcom,vmid = <QCOM_SCM_VMID_MSS_MSA>,
+ <QCOM_SCM_VMID_NAV>;
+ };
+ };
+
+ wcn6750-pmu {
+ compatible = "qcom,wcn6750-pmu";
+ pinctrl-0 = <&hst_bt_en>,
+ <&hst_sw_ctrl>;
+ pinctrl-names = "default";
+ vddio-supply = <&vreg_l19b_1p8>;
+ vddaon-supply = <&vreg_s7b_0p952>;
+ vddasd-supply = <&vreg_l11c_2p8>;
+ vddpmu-supply = <&vreg_s7b_0p952>;
+ vddrfa0p8-supply = <&vreg_s7b_0p952>;
+ vddrfa1p2-supply = <&vreg_s8b_1p256>;
+ vddrfa1p7-supply = <&vreg_s1b_1p856>;
+ vddrfa2p2-supply = <&vreg_s1c_2p2>;
+
+ bt-enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
+ swctrl-gpios = <&tlmm 86 GPIO_ACTIVE_HIGH>;
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p7: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p7";
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm7325-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s8-supply = <&vph_pwr>;
+
+ vdd-l1-l4-l12-l15-supply = <&vreg_s7b_0p952>;
+ vdd-l2-l7-supply = <&vreg_bob>;
+ vdd-l3-supply = <&vreg_s2b_0p7>;
+ vdd-l5-supply = <&vreg_s2b_0p7>;
+ vdd-l6-l9-l10-supply = <&vreg_s8b_1p256>;
+ vdd-l8-supply = <&vreg_s7b_0p952>;
+ vdd-l11-l17-l18-l19-supply = <&vreg_s1b_1p856>;
+ vdd-l13-supply = <&vreg_s7b_0p952>;
+ vdd-l14-l16-supply = <&vreg_s8b_1p256>;
+
+ /*
+ * S2, L4-L5 are ARCs:
+ * S2 - ebi.lvl,
+ * L4 - lmx.lvl,
+ * L5 - lcx.lvl.
+ *
+ * L10 are unused.
+ */
+
+ vreg_s1b_1p856: smps1 {
+ regulator-name = "vreg_s1b_1p856";
+ regulator-min-microvolt = <1840000>;
+ regulator-max-microvolt = <2040000>;
+ };
+
+ vreg_s7b_0p952: smps7 {
+ regulator-name = "vreg_s7b_0p952";
+ regulator-min-microvolt = <535000>;
+ regulator-max-microvolt = <1120000>;
+ };
+
+ vreg_s8b_1p256: smps8 {
+ regulator-name = "vreg_s8b_1p256";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>;
+ };
+
+ vreg_l1b_0p912: ldo1 {
+ regulator-name = "vreg_l1b_0p912";
+ regulator-min-microvolt = <825000>;
+ regulator-max-microvolt = <925000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2b_3p072: ldo2 {
+ regulator-name = "vreg_l2b_3p072";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3b_0p6: ldo3 {
+ regulator-name = "vreg_l3b_0p6";
+ regulator-min-microvolt = <312000>;
+ regulator-max-microvolt = <910000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6b_1p2: ldo6 {
+ regulator-name = "vreg_l6b_1p2";
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_2p96: ldo7 {
+ regulator-name = "vreg_l7b_2p96";
+ /* Constrained for UFS VCC, at least until UFS driver scales voltage */
+ regulator-min-microvolt = <2952000>;
+ regulator-max-microvolt = <2952000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_0p904: ldo8 {
+ regulator-name = "vreg_l8b_0p904";
+ regulator-min-microvolt = <870000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_1p2: ldo9 {
+ regulator-name = "vreg_l9b_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11b_1p776: ldo11 {
+ regulator-name = "vreg_l11b_1p776";
+ regulator-min-microvolt = <1504000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_0p8: ldo12 {
+ regulator-name = "vreg_l12b_0p8";
+ regulator-min-microvolt = <751000>;
+ regulator-max-microvolt = <824000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13b_0p8: ldo13 {
+ regulator-name = "vreg_l13b_0p8";
+ regulator-min-microvolt = <530000>;
+ regulator-max-microvolt = <824000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_1p2: ldo14 {
+ regulator-name = "vreg_l14b_1p2";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_0p88: ldo15 {
+ regulator-name = "vreg_l15b_0p88";
+ regulator-min-microvolt = <765000>;
+ regulator-max-microvolt = <1020000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l16b_1p2: ldo16 {
+ regulator-name = "vreg_l16b_1p2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_1p8: ldo17 {
+ regulator-name = "vreg_l17b_1p8";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l18b_1p8: ldo18 {
+ regulator-name = "vreg_l18b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l19b_1p8: ldo19 {
+ regulator-name = "vreg_l19b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8350c-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s9-supply = <&vph_pwr>;
+ vdd-s10-supply = <&vph_pwr>;
+
+ vdd-l1-l12-supply = <&vreg_s1b_1p856>;
+ vdd-l2-l8-supply = <&vreg_s1b_1p856>;
+ vdd-l3-l4-l5-l7-l13-supply = <&vreg_bob>;
+ vdd-l6-l9-l11-supply = <&vreg_bob>;
+ vdd-l10-supply = <&vreg_s7b_0p952>;
+
+ vdd-bob-supply = <&vph_pwr>;
+
+ /*
+ * S2, S5, S7, S10 are ARCs:
+ * S2 - cx.lvl,
+ * S5 - mss.lvl,
+ * S7 - gfx.lvl,
+ * S10 - mx.lvl.
+ */
+
+ vreg_s1c_2p2: smps1 {
+ regulator-name = "vreg_s1c_2p2";
+ regulator-min-microvolt = <2190000>;
+ regulator-max-microvolt = <2210000>;
+ };
+
+ vreg_s9c_0p676: smps9 {
+ regulator-name = "vreg_s9c_0p676";
+ regulator-min-microvolt = <1010000>;
+ regulator-max-microvolt = <1170000>;
+ };
+
+ vreg_l1c_1p8: ldo1 {
+ regulator-name = "vreg_l1c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c_1p8: ldo2 {
+ regulator-name = "vreg_l2c_1p8";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3c_3p0: ldo3 {
+ regulator-name = "vreg_l3c_3p0";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3540000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c_1p8_3p0: ldo4 {
+ regulator-name = "vreg_l4c_1p8_3p0";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5c_1p8_3p0: ldo5 {
+ regulator-name = "vreg_l5c_1p8_3p0";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6c_2p96: ldo6 {
+ regulator-name = "vreg_l6c_2p96";
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c_3p0: ldo7 {
+ regulator-name = "vreg_l7c_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c_1p8: ldo8 {
+ regulator-name = "vreg_l8c_1p8";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c_2p96: ldo9 {
+ regulator-name = "vreg_l9c_2p96";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l10c_0p88: ldo10 {
+ regulator-name = "vreg_l10c_0p88";
+ regulator-min-microvolt = <720000>;
+ regulator-max-microvolt = <1050000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11c_2p8: ldo11 {
+ regulator-name = "vreg_l11c_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12c_1p8: ldo12 {
+ regulator-name = "vreg_l12c_1p8";
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13c_3p0: ldo13 {
+ regulator-name = "vreg_l13c_3p0";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob: bob {
+ regulator-name = "vreg_bob";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+ };
+ };
+};
+
+&dispcc {
+ status = "disabled";
+};
+
+&gcc {
+ protected-clocks = <GCC_CFG_NOC_LPASS_CLK>,
+ <GCC_MSS_CFG_AHB_CLK>,
+ <GCC_MSS_OFFLINE_AXI_CLK>,
+ <GCC_MSS_Q6SS_BOOT_CLK_SRC>,
+ <GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+ <GCC_MSS_SNOC_AXI_CLK>,
+ <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
+ <GCC_QSPI_CORE_CLK>,
+ <GCC_QSPI_CORE_CLK_SRC>,
+ <GCC_SEC_CTRL_CLK_SRC>,
+ <GCC_WPSS_AHB_BDG_MST_CLK>,
+ <GCC_WPSS_AHB_CLK>,
+ <GCC_WPSS_RSCP_CLK>;
+};
+
+&gpi_dma0 {
+ status = "okay";
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/sm7325/xiaomi/taoyao/a660_zap.mbn";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+
+ status = "okay";
+
+ typec-mux@42 {
+ compatible = "fcs,fsa4480";
+ reg = <0x42>;
+
+ vcc-supply = <&vreg_bob>;
+
+ mode-switch;
+ orientation-switch;
+
+ port {
+ fsa4480_sbu_mux: endpoint {
+ remote-endpoint = <&pmic_glink_sbu>;
+ };
+ };
+ };
+};
+
+&ipa {
+ qcom,gsi-loader = "self";
+ memory-region = <&ipa_fw_mem>;
+ firmware-name = "qcom/sm7325/xiaomi/taoyao/ipa_fws.mbn";
+
+ status = "okay";
+};
+
+&lpass_audiocc {
+ compatible = "qcom,qcm6490-lpassaudiocc";
+ /delete-property/ power-domains;
+};
+
+&pm7325_gpios {
+ key_vol_up: key-vol-up-n-state {
+ pins = "gpio6";
+ function = PMIC_GPIO_FUNC_NORMAL;
+ power-source = <1>;
+ bias-pull-up;
+ input-enable;
+ };
+};
+
+&pmk8350_rtc {
+ status = "okay";
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&qup_spi13_cs {
+ drive-strength = <6>;
+ bias-disable;
+};
+
+&qup_spi13_data_clk {
+ drive-strength = <6>;
+ bias-disable;
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/sm7325/xiaomi/taoyao/adsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm7325/xiaomi/taoyao/cdsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_mpss {
+ firmware-name = "qcom/sm7325/xiaomi/taoyao/modem.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_wpss {
+ firmware-name = "qcom/sm7325/xiaomi/taoyao/wpss.mbn";
+
+ status = "okay";
+};
+
+&spi13 {
+ status = "okay";
+
+ touchscreen@0 {
+ compatible = "goodix,gt9916";
+ reg = <0>;
+
+ interrupts-extended = <&tlmm 81 IRQ_TYPE_LEVEL_LOW>;
+
+ reset-gpios = <&tlmm 105 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&vreg_l7c_3p0>;
+ vddio-supply = <&vreg_l2c_1p8>;
+
+ spi-max-frequency = <5000000>;
+
+ touchscreen-size-x = <10800>;
+ touchscreen-size-y = <24000>;
+
+ pinctrl-0 = <&ts_irq>, <&ts_reset>;
+ pinctrl-names = "default";
+ };
+};
+
+&tlmm {
+ gpio-reserved-ranges = <48 4>, <56 4>;
+
+ bt_uart_sleep_cts: bt-uart-sleep-cts-state {
+ pins = "gpio28";
+ function = "gpio";
+ bias-bus-hold;
+ };
+
+ bt_uart_sleep_rts: bt-uart-sleep-rts-state {
+ pins = "gpio29";
+ function = "gpio";
+ bias-pull-down;
+ };
+
+ bt_uart_sleep_txd: bt-uart-sleep-txd-state {
+ pins = "gpio30";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ bt_uart_sleep_rxd: bt-uart-sleep-rxd-state {
+ pins = "gpio31";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ sde_dsi_active: sde-dsi-active-state {
+ pins = "gpio44";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ sde_dsi_sleep: sde-dsi-sleep-state {
+ pins = "gpio44";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sde_te_active_sleep: sde-te-active-state {
+ pins = "gpio80";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ ts_irq: ts-irq-state {
+ pins = "gpio81";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+
+ hst_bt_en: hst-bt-en-state {
+ pins = "gpio85";
+ function = "gpio";
+ output-low;
+ bias-disable;
+ };
+
+ hst_sw_ctrl: hst-sw-ctrl-state {
+ pins = "gpio86";
+ function = "gpio";
+ bias-pull-down;
+ };
+
+ ts_reset: ts-reset-state {
+ pins = "gpio105";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-pull-up;
+ };
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&uart7 {
+ /delete-property/interrupts;
+ interrupts-extended = <&intc GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>,
+ <&tlmm 31 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-1 = <&bt_uart_sleep_cts>,
+ <&bt_uart_sleep_rts>,
+ <&bt_uart_sleep_txd>,
+ <&bt_uart_sleep_rxd>;
+ pinctrl-names = "default", "sleep";
+
+ status = "okay";
+
+ bluetooth: bluetooth {
+ compatible = "qcom,wcn6750-bt";
+
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddbtcmx-supply = <&vreg_pmu_btcmx_0p85>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p7-supply = <&vreg_pmu_rfa_1p7>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ max-speed = <3200000>;
+ };
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l7b_2p96>;
+ vcc-max-microamp = <800000>;
+ /*
+ * Technically l9b enables an eLDO (supplied by s1b) which then powers
+ * VCCQ2 of the UFS.
+ */
+ vccq2-supply = <&vreg_l9b_1p2>;
+ vccq2-max-microamp = <900000>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l10c_0p88>;
+ vdda-pll-supply = <&vreg_l6b_1p2>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ /* USB 2.0 only */
+ qcom,select-utmi-as-pipe-clk;
+
+ dr_mode = "otg";
+ usb-role-switch;
+ maximum-speed = "high-speed";
+ /* Remove USB3 phy */
+ phys = <&usb_1_hsphy>;
+ phy-names = "usb2-phy";
+
+ status = "okay";
+};
+
+&usb_1_dwc3_hs {
+ remote-endpoint = <&pmic_glink_hs_in>;
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vreg_l10c_0p88>;
+ vdda18-supply = <&vreg_l1c_1p8>;
+ vdda33-supply = <&vreg_l2b_3p072>;
+
+ status = "okay";
+};
+
+&venus {
+ firmware-name = "qcom/sm7325/xiaomi/taoyao/vpu20_1v.mbn";
+
+ status = "okay";
+};
+
+&wifi {
+ qcom,calibration-variant = "Xiaomi_taoyao";
+
+ status = "okay";
+};
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 3/5] media: synopsys: Add PHY stopstate wait for i.MX93
From: Frank Li @ 2026-04-17 8:51 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-3-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:54AM +0800, Guoniu Zhou wrote:
> Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
> ensures proper PHY initialization by verifying that the clock lane and
> all active data lanes have entered the stop state before proceeding with
> further operations.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
...
>
> +static int imx93_csi2rx_wait_for_phy_stopstate(struct dw_mipi_csi2rx_device *csi2)
> +{
> + struct device *dev = csi2->dev;
> + void __iomem *addr;
> + u32 stopstate_mask;
> + u32 val;
> + int ret;
> +
> + if (!dw_mipi_csi2rx_has_reg(csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE)) {
> + dev_err(dev, "phy_stopstate register not available\n");
> + return -ENXIO;
> + }
Needn't this check, you just implment this specfic callback for imx93, so
DW_MIPI_CSI2RX_PHY_STOPSTATE must be there.
> +
> + stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2->lanes_num - 1, 0);
> + addr = dw_mipi_csi2rx_get_regaddr(csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
> +
> + ret = readl_poll_timeout(addr, val, (val & stopstate_mask) != stopstate_mask,
> + 1000, 2000000);
There are dw_mipi_csi2rx_read() helper function. So you already use
read_poll_timeout(dw_mipi_csi2rx_read, ...)
Frank
^ permalink raw reply
* Re: [PATCH v4 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Arnd Bergmann @ 2026-04-17 8:59 UTC (permalink / raw)
To: Stefan Dösinger, Jonathan Corbet, Shuah Khan, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial
In-Reply-To: <20260416-send-v4-7-e19d02b944ec@gmail.com>
On Thu, Apr 16, 2026, at 22:19, Stefan Dösinger wrote:
>
> The reason why I add the serial1=uart1 alias is to keep console=ttyAMA1
> stable regardless of the other enabled UARTs. UART0, as the name
> implies, has a lower MMIO address, but uart1 is the one that usually has
> the boot output and console.
I'm not sure I'm following here. You generally want to either make
sure the alias matches whatever number is printed on the product
if there are multiple numbered ports, or you just use 'serial0'
as the only alias if there is only one port.
> + aliases {
> + serial1 = &uart1;
> + };
Either way, the alias should go into the board specific file, not
the general SoC file, as a board might be using a different
set of UARTs.
> +
> + /* The UART clock defaults to 26 mhz. It will be replaced when the zx29 clock
> + * framework is added.
> + */
> + uartclk: uartclk: clock-26000000 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <26000000>;
> + };
> +
> + uart1: serial@1408000 {
> + compatible = "arm,pl011", "arm,primecell";
> + arm,primecell-periphid = <0x001feffe>;
> + reg = <0x01408000 0x1000>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&uartclk>;
> + clock-names = "apb_pclk";
> + };
Since you know the addresses of the other uart instances, I would
suggest you add all of them at the same time.
Arnd
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Andrea della Porta @ 2026-04-17 9:05 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andrea della Porta, linux-pwm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov, mbrugger
In-Reply-To: <aeDmk-t5Lc1zpkg9@monoceros>
Hi Uwe,
On 15:48 Thu 16 Apr , Uwe Kleine-König wrote:
> Hello Andrea,
>
> one thing I forgot to ask: Is there a public reference manual covering
> the hardware. If yes, please add a link at the top of the driver.
Sort of, it's already reported in this driver top comment (Datasheet: tag).
The PWM controller is part of the RP1 chipset and you can find its description
under the PWM section. This is not a full-fledged datasheet but the registers
for the controller are somewhow documented.
>
> On Thu, Apr 16, 2026 at 12:30:43PM +0200, Andrea della Porta wrote:
> > On 19:31 Fri 10 Apr , Uwe Kleine-König wrote:
> > > I assume there is a glitch if I update two channels and the old
> > > configuration of the first channel ends while I'm in the middle of
> > > configuring the second?
> >
> > The configuration registers are per-channel but the update flag is global.
> > I don't have details of the hw insights, my best guess is that anything that
> > you set in the registers before updating the flag will take effect, so there
> > should be no glitches.
>
> Would be great if you could test that. (Something along the lines of:
> configure a very short period and wait a bit to be sure the short
> configuration is active. Configure something with a long period and wait
> shortly to be sure that the long period started, then change the duty,
> toggle the update bit and modify a 2nd channel without toggling update
> again. Then check the output of the 2nd channel after the first
> channel's period ended.
I stand corrected here: after some more investigation it seems that only the
enable/disable (plus osme other not currently used registers) depends on the
global update flag, while the period and duty per-channel registers are
independtly updatable while they are latched on the end of (specific channel)
period strobe.
I'd say that this should avoid any cross-channel glitches since they are managed
independently. Unfortunately I'm not able to test this with my current (and
rather old) equipment, this would require at least an external trigger channel.
Regarding the setup of a new value exactly during the strobe: I think this is
quite hard to achieve.
>
> > > > + if (ticks > U32_MAX)
> > > > + ticks = U32_MAX;
> > > > + wfhw->period_ticks = ticks;
> > >
> > > What happens if wf->period_length_ns > 0 but ticks == 0?
> >
> > I've added a check, returning 1 to signal teh round-up, and a minimum tick of 1
> > in this case.
>
> Sounds good. Are you able to verify that there is no +1 missing in the
> calculation, e.g. using 1 as register value really gives you a period of
> 1 tick and not 2?
You are right. The scope reveals there's always one extra (low signal) tick at the
end of each period. Let's say that teh user want 10 tick period, we have to use
9 instead to account for the extra tick at the end, so that the complete period
contains that extra tick?
This also means that if we ask for 100% duty cycle, the output waveform will
have the high part of the signal lasting one tick less than expected.a I guess
this is the accepted compromise.
OTOH, the minimum tick period would be 2 tick, less than that will otherwise
degenerate in a disabled channel.
>
> > > > + if (wf->duty_offset_ns + wf->duty_length_ns >= wf->period_length_ns) {
> > >
> > > The maybe surprising effect here is that in the two cases
> > >
> > > wf->duty_offset_ns == wf->period_length_ns and wf->duty_length_ns == 0
> > >
> > > and
> > >
> > > wf->duty_length_ns == wf->period_length_ns and wf->duty_offset_ns == 0
> > >
> > > you're configuring inverted polarity. I doesn't matter technically
> > > because the result is the same, but for consumers still using pwm_state
> > > this is irritating. That's why pwm-stm32 uses inverted polarity only if
> > > also wf->duty_length_ns and wf->duty_offset_ns are non-zero.
>
> Please align to the pwm-stm32 algorithm (as of
> https://patch.msgid.link/c5e7767cee821b5f6e00f95bd14a5e13015646fb.1776264104.git.u.kleine-koenig@baylibre.com)
> here to decide when to select inverted polarity.
Yep, I did already done when you sent that patch.
>
> > > > + }
> > > > +
> > > > + return 0;
> > > > +
> > > > +err_disable_clk:
> > > > + clk_disable_unprepare(rp1->clk);
> > > > +
> > > > + return ret;
> > > > +}
> > >
> > > On remove you miss to balance the call to clk_prepare_enable() (if no
> > > failed call to clk_prepare_enable() in rp1_pwm_resume() happend).
> >
> > Since this driver now exports a syscon, it's only builtin (=Y) so
> > it cannot be unloaded.
> > I've also avoided the .remove callback via .suppress_bind_attrs.
>
> Oh no, please work cleanly here and make the driver unbindable. This
> yields better code quality and also helps during development and
> debugging.
I wish to, but the issue here is that this driver exports a syscon via
of_syscon_register_regmap() which I think doesn't have the unregister
counterpart. So the consumer will break in case we can unbind/unload
the module and the syscon will leak.
If you have any alternative I'll be glad to discuss.
Many thanks,
Andrea
>
> Best regards
> Uwe
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Krzysztof Kozlowski @ 2026-04-17 9:18 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <aeBQRStG3imY0cOe@hu-qianyu-lv.qualcomm.com>
On Wed, Apr 15, 2026 at 07:58:13PM -0700, Qiang Yu wrote:
> On Wed, Apr 15, 2026 at 09:50:28AM +0200, Krzysztof Kozlowski wrote:
> > On Sun, Apr 12, 2026 at 11:25:56PM -0700, Qiang Yu wrote:
> > > The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
> > >
> > > 1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
> > > 4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
> > > 2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
> > > follower to form a single 8-lane PCIe Gen5 interface
> > >
> > > In bifurcation mode, the hardware design requires controlling additional
> > > resources beyond the standard pcie3a PHY configuration:
> > >
> > > - pcie3b's aux_clk (phy_b_aux)
> > > - pcie3b's phy_gdsc power domain
> > > - pcie3b's bcr/nocsr reset
> > >
> > > Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
> > > 8-lane bifurcation configuration.
> >
> > Do you describe PCI3A or PCI3B or something combined PCI3?
>
> I describe a single x8 PHY with resources from both the pcie3a and pcie3b
> PHY blocks for x8 operation.
>
> >
> > >
> > > The phy_b_aux clock is used as the 6th clock instead of pipediv2,
> > > requiring the clock-names enum to be extended to support both
> > > [phy_b_aux, pipediv2] options at index 5. This follows the existing
> > > pattern used for [rchng, refgen] clocks at index 3.
> > >
> > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > ---
> > > .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 53 ++++++++++++++++++----
> > > 1 file changed, 45 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..14eba5d705b1956c1bb00cc8c95171ed6488299b 100644
> > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > @@ -18,6 +18,7 @@ properties:
> > > enum:
> > > - qcom,glymur-qmp-gen4x2-pcie-phy
> > > - qcom,glymur-qmp-gen5x4-pcie-phy
> > > + - qcom,glymur-qmp-gen5x8-pcie-phy
> >
> > That's the same device as 5x4, no? One device, one compatible and this
> > suggests you will have three PCI phys in the DT - two 5x4 and one 5x8?
> >
>
> It is not the same as the 5x4 PHY. In DT, we model three PHY nodes:
> phy_3a (1x4), phy_3b (1x4), and a separate phy_1x8 node for x8 mode.
OK, that's what I wanted to hear. And that's what should not be done,
You should not have a separate node for the same hardware. First, DTC
will give you a W=1 warning, although warning itself should be moved to
W=2.
Second, the warning tells important story - same hardware is described
twice.
You only need phy_3a and phy_3b, so only two in total.
phy_3a could have resources of phy_3b OR could have a phandle to
companion (follower) phy to fetch resources from it. I don't know yet
which choice is better, though.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add crypto engine
From: Harshal Dev @ 2026-04-17 9:22 UTC (permalink / raw)
To: Konrad Dybcio, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov
Cc: Neeraj Soni, Kuldeep Singh, Abel Vesa, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <653fc8bb-295f-4f1d-b9ac-a33e0d8a933b@oss.qualcomm.com>
Hi,
On 4/16/2026 7:10 PM, Konrad Dybcio wrote:
> On 4/16/26 3:07 PM, Harshal Dev wrote:
>> On Glymur, there is a crypto engine IP block similar to the ones found on
>> SM8x50 platforms.
>>
>> Describe the crypto engine and its BAM.
>>
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/glymur.dtsi | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>> index f23cf81ddb77..e8c796f2c572 100644
>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>> @@ -3675,6 +3675,32 @@ pcie3b_phy: phy@f10000 {
>> status = "disabled";
>> };
>>
>> + cryptobam: dma-controller@1dc4000 {
>> + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0";
>> + reg = <0x0 0x01dc4000 0x0 0x28000>;
>> + interrupts = <GIC_SPI 272 IRQ_TYPE_LEVEL_HIGH>;
>> + #dma-cells = <1>;
>> + iommus = <&apps_smmu 0x480 0x0>,
>> + <&apps_smmu 0x481 0x0>;
>
> It seems like these aren't the right SIDs on this platform.. Have you
> tested this patch on hw?
Thanks a lot for catching this Konrad. The correct SID pairs are <0x80 0x0> and <0x81 0x0>.
(I hope I don't need to pad them?)
Unfortunately, I could only validate driver probe on my limited ramdisk environment:
[ 4.583802] qcrypto 1dfa000.crypto: Crypto device found, version 5.9.1
I was waiting for Wenjia to run the full crypto user-space test suite once. I'll update the
SIDs and wait for a Tested-by from him.
Regards,
Harshal
>
> Konrad
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: add TRNG node
From: Harshal Dev @ 2026-04-17 9:23 UTC (permalink / raw)
To: Konrad Dybcio, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov
Cc: linux-arm-msm, linux-crypto, devicetree, linux-kernel
In-Reply-To: <28108ec6-2b06-4b63-8e41-fa75b7858acf@oss.qualcomm.com>
On 4/16/2026 6:03 PM, Konrad Dybcio wrote:
> On 4/16/26 2:26 PM, Harshal Dev wrote:
>> Glymur has a True Random Number Generator, add the node with the correct
>> compatible set.
>>
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/glymur.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>> index f23cf81ddb77..c9d46ec82ccc 100644
>> --- a/arch/arm64/boot/dts/qcom/glymur.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>> @@ -3675,6 +3675,11 @@ pcie3b_phy: phy@f10000 {
>> status = "disabled";
>> };
>>
>> + rng: rng@10c3000 {
>> + compatible = "qcom,glymur-trng", "qcom,trng";
>> + reg = <0x0 0x10c3000 0x0 0x1000>;
>
> Please pad the address part to 8 hex digits with leading zeroes
>
Ack.
Regards,
Harshal
> with that:
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
^ permalink raw reply
* [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
Several boards based on the RK3576 and RK3588(S) SoCs use a
GPIO-controlled voltage bias circuit on the HDMI data lines that must be
switched according to the active link mode: asserted for HDMI 2.1 FRL
and deasserted for HDMI 1.4/2.0 TMDS.
This series adds the frl-enable-gpios property to the HDMI nodes of all
boards for which the GPIO configuration could be identified from vendor
BSP kernel sources and/or schematics where available. In a small number
of cases it was necessary to extract and disassemble the DTB from the
vendor firmware image.
One board remains unhandled (rk3588-edgeble-neu6a-io), pending
clarification from the vendor.
For each affected board the patches:
- set frl-enable-gpios with the appropriate GPIO reference and
GPIO_ACTIVE_LOW polarity (inverted relative to the BSP enable-gpios /
GPIO_ACTIVE_HIGH convention, which effectively acts as
tmds-enable-gpios)
- extend pinctrl-0 of the HDMI node to include the new pin group
- add the corresponding pinctrl definition under &pinctrl
It's worth noting the Rockchip platform glue driver for the DesignWare
HDMI QP TX controller already drives the frl-enable GPIO, but since FRL
is not yet supported, TMDS mode is unconditionally selected. This
ensures a consistent setup independent of hardware reset defaults and
bootloader state.
Furthermore, this allows removing a few DT quirks hardcoding the active
link mode and paves the way for a follow-up series enabling HDMI 2.1 FRL
support.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
Cristian Ciocaltea (40):
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-sige7
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-armsom-w3
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-evb
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-coolpi-cm5-genbook
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb1-v10
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-evb2-v10
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-firefly-itx-3588j
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-friendlyelec-cm3588-nas
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-h96-max-v58
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-jaguar
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-mnt-reform2
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-nanopc-t6
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-max
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-plus
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-orangepi-5-ultra
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-roc-rt
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5-itx
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-rock-5b-5bp-5t
arm64: dts: rockchip: Add frl-enable-gpios to rk3588-tiger
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-coolpi-4b
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-gameforce-ace
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-indiedroid-nova
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-khadas-edge2
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-nanopi-r6
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-odroid-m2
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-5
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-orangepi-cm5-base
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-radxa-cm5-io
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-roc-pc
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5a
arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5c
.../boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-evb2-v10.dts | 8 ++++++++
.../boot/dts/rockchip/rk3576-luckfox-core3576.dtsi | 9 ++++-----
arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-nanopi-r76s.dts | 9 ++++-----
arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dts | 8 ++++++++
arch/arm64/boot/dts/rockchip/rk3588-armsom-sige7.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588-armsom-w3.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-coolpi-cm5-evb.dts | 17 ++++++++++++++++-
.../boot/dts/rockchip/rk3588-coolpi-cm5-genbook.dts | 10 +++++++++-
arch/arm64/boot/dts/rockchip/rk3588-evb1-v10.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-evb2-v10.dts | 9 +++++++++
.../boot/dts/rockchip/rk3588-firefly-itx-3588j.dts | 9 +++++++++
.../dts/rockchip/rk3588-friendlyelec-cm3588-nas.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-h96-max-v58.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 10 +++++++++-
arch/arm64/boot/dts/rockchip/rk3588-mnt-reform2.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588-nanopc-t6.dtsi | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-max.dts | 15 ++++++++++++++-
arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 16 ++++++++++++++++
.../arm64/boot/dts/rockchip/rk3588-orangepi-5-ultra.dts | 9 ++++++++-
arch/arm64/boot/dts/rockchip/rk3588-roc-rt.dts | 16 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 9 ++++++++-
arch/arm64/boot/dts/rockchip/rk3588-rock-5b-5bp-5t.dtsi | 16 +++++++++++++++-
arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts | 3 ++-
arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 9 ++++++++-
arch/arm64/boot/dts/rockchip/rk3588s-coolpi-4b.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588s-gameforce-ace.dts | 8 +++-----
.../arm64/boot/dts/rockchip/rk3588s-indiedroid-nova.dts | 10 +++++++++-
arch/arm64/boot/dts/rockchip/rk3588s-khadas-edge2.dts | 13 +++++++++----
arch/arm64/boot/dts/rockchip/rk3588s-nanopi-r6.dtsi | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 9 +++++++++
.../boot/dts/rockchip/rk3588s-orangepi-cm5-base.dts | 3 ++-
arch/arm64/boot/dts/rockchip/rk3588s-radxa-cm5-io.dts | 9 +++++++++
arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts | 15 ++++++++++++---
arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts | 10 +++++++++-
arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts | 10 +++++++++-
41 files changed, 392 insertions(+), 35 deletions(-)
---
base-commit: 452c3b1ea875276105ac90ba474f72b4cd9b77a2
change-id: 20260417-dts-rk-frl-enable-gpios-ce9930dbf5ca
^ permalink raw reply
* [PATCH 01/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO2_B0 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts b/arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts
index b19f9b6be6bf..9f356bfcb663 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-100ask-dshanpi-a1.dts
@@ -278,6 +278,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -738,6 +740,12 @@ hp_det: hp-det {
};
};
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
pcie {
pcie_reset: pcie-reset {
rockchip,pins = <1 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 02/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO2_B0 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
index 1c100ffd1518..43a5c6859909 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
@@ -304,6 +304,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -819,6 +821,12 @@ hp_det_l: hp-det-l {
};
};
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
hym8563_int: hym8563-int {
rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
* [PATCH 03/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
From: Cristian Ciocaltea @ 2026-04-17 9:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO2_B0 line to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
index fb0dd1bc5148..b112432528ed 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dts
@@ -370,6 +370,8 @@ &gpu {
};
&hdmi {
+ pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
+ frl-enable-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -895,6 +897,12 @@ host_wake_bt: host-wake-bt {
};
};
+ hdmi {
+ hdmi_frl_en: hdmi-frl-en {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
hym8563 {
rtc_int: rtc-int {
rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox