* [PATCH v2 00/10] Add PCIe support for Tesla FSD SoC
[not found] <CGME20250625165241epcas5p471ca039a776513c4da7ee2a0955de5c2@epcas5p4.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
[not found] ` <CGME20250625165248epcas5p10eefe9e1f1a89806793c86decc63f232@epcas5p1.samsung.com>
` (9 more replies)
0 siblings, 10 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
FSD platform has three instances of DesignWare based PCIe IP,
one is in FSYS0 block and other two in FSYS1 block.
This patch series add required DT binding, DT file modifications,
Controller driver support and PHY driver support for the same.
To keep single PCIe controller driver for all Samsung
manufactured SoC, we have made changes to Exynos file to extend
support for FSD platform and other Samsung manufactured SoCs which
shall be upstreamed soon.
First a version was posted as a separate driver file:
https://lore.kernel.org/lkml/20221121105210.68596-1-shradha.t@samsung.com/
This was rejected and request was made to add the support in exynos file
itself.
Then another patchset was posted to refactor existing exynos file:
https://lore.kernel.org/lkml/649a8d88-0504-5aa9-d167-d25d394f3f26@linaro.org/T/
This requested some major changes
Taking both these reviews into consideration, I have posted a fresh
patchset where both changes to exynos framework and addition of new FSD
support is present.
v2:
- Reordered patches for removing unused MACROs and renaming them
- Fixed all incomplete DT bindings
- Modified PHY driver code to adopt better design
- Removed patch to add alignment data in PCI endpoint test driver
- Added dts changes in the patchset itself
v1: https://lore.kernel.org/lkml/20250518193152.63476-1-shradha.t@samsung.com/
Shradha Todi (10):
PCI: exynos: Remove unused MACROs in exynos PCI file
PCI: exynos: Change macro names to exynos specific
PCI: exynos: Reorder MACROs to maintain consistency
PCI: exynos: Add platform device private data
PCI: exynos: Add structure to hold resource operations
dt-bindings: PCI: Add bindings support for Tesla FSD SoC
dt-bindings: phy: Add PHY bindings support for FSD SoC
phy: exynos: Add PCIe PHY support for FSD SoC
PCI: exynos: Add support for Tesla FSD SoC
arm64: dts: fsd: Add PCIe support for Tesla FSD SoC
.../bindings/pci/samsung,exynos-pcie.yaml | 121 ++--
.../bindings/pci/tesla,fsd-pcie-ep.yaml | 91 +++
.../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +-
arch/arm64/boot/dts/tesla/fsd-evb.dts | 36 ++
arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi | 65 ++
arch/arm64/boot/dts/tesla/fsd.dtsi | 147 +++++
drivers/pci/controller/dwc/pci-exynos.c | 568 +++++++++++++++---
drivers/phy/samsung/phy-exynos-pcie.c | 317 +++++++++-
8 files changed, 1240 insertions(+), 130 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v2 01/10] PCI: exynos: Remove unused MACROs in exynos PCI file
[not found] ` <CGME20250625165248epcas5p10eefe9e1f1a89806793c86decc63f232@epcas5p1.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
0 siblings, 0 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi, Hrishikesh Dileep
Some MACROs are defined in the exynos PCI file but are
not used anywhere within the file. Remove such unused
MACROs.
Suggested-by: Hrishikesh Dileep <hrishikesh.d@samsung.com>
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index 1f0e98d07109..f9140d1f1d19 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -31,8 +31,6 @@
#define IRQ_INTB_ASSERT BIT(2)
#define IRQ_INTC_ASSERT BIT(4)
#define IRQ_INTD_ASSERT BIT(6)
-#define PCIE_IRQ_LEVEL 0x004
-#define PCIE_IRQ_SPECIAL 0x008
#define PCIE_IRQ_EN_PULSE 0x00c
#define PCIE_IRQ_EN_LEVEL 0x010
#define PCIE_IRQ_EN_SPECIAL 0x014
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 02/10] PCI: exynos: Change macro names to exynos specific
[not found] ` <CGME20250625165253epcas5p1339d784e500ad629a64fb4aad792e79b@epcas5p1.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
0 siblings, 0 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
Prefix macro names in exynos file with the term "EXYNOS" as the current
macro names seem to be generic to PCIe.
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 112 ++++++++++++------------
1 file changed, 56 insertions(+), 56 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index f9140d1f1d19..30d12ff9b0c6 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -26,28 +26,28 @@
#define to_exynos_pcie(x) dev_get_drvdata((x)->dev)
/* PCIe ELBI registers */
-#define PCIE_IRQ_PULSE 0x000
-#define IRQ_INTA_ASSERT BIT(0)
-#define IRQ_INTB_ASSERT BIT(2)
-#define IRQ_INTC_ASSERT BIT(4)
-#define IRQ_INTD_ASSERT BIT(6)
-#define PCIE_IRQ_EN_PULSE 0x00c
-#define PCIE_IRQ_EN_LEVEL 0x010
-#define PCIE_IRQ_EN_SPECIAL 0x014
-#define PCIE_SW_WAKE 0x018
-#define PCIE_BUS_EN BIT(1)
-#define PCIE_CORE_RESET 0x01c
-#define PCIE_CORE_RESET_ENABLE BIT(0)
-#define PCIE_STICKY_RESET 0x020
-#define PCIE_NONSTICKY_RESET 0x024
-#define PCIE_APP_INIT_RESET 0x028
-#define PCIE_APP_LTSSM_ENABLE 0x02c
-#define PCIE_ELBI_RDLH_LINKUP 0x074
-#define PCIE_ELBI_XMLH_LINKUP BIT(4)
-#define PCIE_ELBI_LTSSM_ENABLE 0x1
-#define PCIE_ELBI_SLV_AWMISC 0x11c
-#define PCIE_ELBI_SLV_ARMISC 0x120
-#define PCIE_ELBI_SLV_DBI_ENABLE BIT(21)
+#define EXYNOS_PCIE_IRQ_PULSE 0x000
+#define EXYNOS_IRQ_INTA_ASSERT BIT(0)
+#define EXYNOS_IRQ_INTB_ASSERT BIT(2)
+#define EXYNOS_IRQ_INTC_ASSERT BIT(4)
+#define EXYNOS_IRQ_INTD_ASSERT BIT(6)
+#define EXYNOS_PCIE_IRQ_EN_PULSE 0x00c
+#define EXYNOS_PCIE_IRQ_EN_LEVEL 0x010
+#define EXYNOS_PCIE_IRQ_EN_SPECIAL 0x014
+#define EXYNOS_PCIE_SW_WAKE 0x018
+#define EXYNOS_PCIE_BUS_EN BIT(1)
+#define EXYNOS_PCIE_CORE_RESET 0x01c
+#define EXYNOS_PCIE_CORE_RESET_ENABLE BIT(0)
+#define EXYNOS_PCIE_STICKY_RESET 0x020
+#define EXYNOS_PCIE_NONSTICKY_RESET 0x024
+#define EXYNOS_PCIE_APP_INIT_RESET 0x028
+#define EXYNOS_PCIE_APP_LTSSM_ENABLE 0x02c
+#define EXYNOS_PCIE_ELBI_RDLH_LINKUP 0x074
+#define EXYNOS_PCIE_ELBI_XMLH_LINKUP BIT(4)
+#define EXYNOS_PCIE_ELBI_LTSSM_ENABLE 0x1
+#define EXYNOS_PCIE_ELBI_SLV_AWMISC 0x11c
+#define EXYNOS_PCIE_ELBI_SLV_ARMISC 0x120
+#define EXYNOS_PCIE_ELBI_SLV_DBI_ENABLE BIT(21)
struct exynos_pcie {
struct dw_pcie pci;
@@ -71,49 +71,49 @@ static void exynos_pcie_sideband_dbi_w_mode(struct exynos_pcie *ep, bool on)
{
u32 val;
- val = exynos_pcie_readl(ep->elbi_base, PCIE_ELBI_SLV_AWMISC);
+ val = exynos_pcie_readl(ep->elbi_base, EXYNOS_PCIE_ELBI_SLV_AWMISC);
if (on)
- val |= PCIE_ELBI_SLV_DBI_ENABLE;
+ val |= EXYNOS_PCIE_ELBI_SLV_DBI_ENABLE;
else
- val &= ~PCIE_ELBI_SLV_DBI_ENABLE;
- exynos_pcie_writel(ep->elbi_base, val, PCIE_ELBI_SLV_AWMISC);
+ val &= ~EXYNOS_PCIE_ELBI_SLV_DBI_ENABLE;
+ exynos_pcie_writel(ep->elbi_base, val, EXYNOS_PCIE_ELBI_SLV_AWMISC);
}
static void exynos_pcie_sideband_dbi_r_mode(struct exynos_pcie *ep, bool on)
{
u32 val;
- val = exynos_pcie_readl(ep->elbi_base, PCIE_ELBI_SLV_ARMISC);
+ val = exynos_pcie_readl(ep->elbi_base, EXYNOS_PCIE_ELBI_SLV_ARMISC);
if (on)
- val |= PCIE_ELBI_SLV_DBI_ENABLE;
+ val |= EXYNOS_PCIE_ELBI_SLV_DBI_ENABLE;
else
- val &= ~PCIE_ELBI_SLV_DBI_ENABLE;
- exynos_pcie_writel(ep->elbi_base, val, PCIE_ELBI_SLV_ARMISC);
+ val &= ~EXYNOS_PCIE_ELBI_SLV_DBI_ENABLE;
+ exynos_pcie_writel(ep->elbi_base, val, EXYNOS_PCIE_ELBI_SLV_ARMISC);
}
static void exynos_pcie_assert_core_reset(struct exynos_pcie *ep)
{
u32 val;
- val = exynos_pcie_readl(ep->elbi_base, PCIE_CORE_RESET);
- val &= ~PCIE_CORE_RESET_ENABLE;
- exynos_pcie_writel(ep->elbi_base, val, PCIE_CORE_RESET);
- exynos_pcie_writel(ep->elbi_base, 0, PCIE_STICKY_RESET);
- exynos_pcie_writel(ep->elbi_base, 0, PCIE_NONSTICKY_RESET);
+ val = exynos_pcie_readl(ep->elbi_base, EXYNOS_PCIE_CORE_RESET);
+ val &= ~EXYNOS_PCIE_CORE_RESET_ENABLE;
+ exynos_pcie_writel(ep->elbi_base, val, EXYNOS_PCIE_CORE_RESET);
+ exynos_pcie_writel(ep->elbi_base, 0, EXYNOS_PCIE_STICKY_RESET);
+ exynos_pcie_writel(ep->elbi_base, 0, EXYNOS_PCIE_NONSTICKY_RESET);
}
static void exynos_pcie_deassert_core_reset(struct exynos_pcie *ep)
{
u32 val;
- val = exynos_pcie_readl(ep->elbi_base, PCIE_CORE_RESET);
- val |= PCIE_CORE_RESET_ENABLE;
+ val = exynos_pcie_readl(ep->elbi_base, EXYNOS_PCIE_CORE_RESET);
+ val |= EXYNOS_PCIE_CORE_RESET_ENABLE;
- exynos_pcie_writel(ep->elbi_base, val, PCIE_CORE_RESET);
- exynos_pcie_writel(ep->elbi_base, 1, PCIE_STICKY_RESET);
- exynos_pcie_writel(ep->elbi_base, 1, PCIE_NONSTICKY_RESET);
- exynos_pcie_writel(ep->elbi_base, 1, PCIE_APP_INIT_RESET);
- exynos_pcie_writel(ep->elbi_base, 0, PCIE_APP_INIT_RESET);
+ exynos_pcie_writel(ep->elbi_base, val, EXYNOS_PCIE_CORE_RESET);
+ exynos_pcie_writel(ep->elbi_base, 1, EXYNOS_PCIE_STICKY_RESET);
+ exynos_pcie_writel(ep->elbi_base, 1, EXYNOS_PCIE_NONSTICKY_RESET);
+ exynos_pcie_writel(ep->elbi_base, 1, EXYNOS_PCIE_APP_INIT_RESET);
+ exynos_pcie_writel(ep->elbi_base, 0, EXYNOS_PCIE_APP_INIT_RESET);
}
static int exynos_pcie_start_link(struct dw_pcie *pci)
@@ -121,21 +121,21 @@ static int exynos_pcie_start_link(struct dw_pcie *pci)
struct exynos_pcie *ep = to_exynos_pcie(pci);
u32 val;
- val = exynos_pcie_readl(ep->elbi_base, PCIE_SW_WAKE);
- val &= ~PCIE_BUS_EN;
- exynos_pcie_writel(ep->elbi_base, val, PCIE_SW_WAKE);
+ val = exynos_pcie_readl(ep->elbi_base, EXYNOS_PCIE_SW_WAKE);
+ val &= ~EXYNOS_PCIE_BUS_EN;
+ exynos_pcie_writel(ep->elbi_base, val, EXYNOS_PCIE_SW_WAKE);
/* assert LTSSM enable */
- exynos_pcie_writel(ep->elbi_base, PCIE_ELBI_LTSSM_ENABLE,
- PCIE_APP_LTSSM_ENABLE);
+ exynos_pcie_writel(ep->elbi_base, EXYNOS_PCIE_ELBI_LTSSM_ENABLE,
+ EXYNOS_PCIE_APP_LTSSM_ENABLE);
return 0;
}
static void exynos_pcie_clear_irq_pulse(struct exynos_pcie *ep)
{
- u32 val = exynos_pcie_readl(ep->elbi_base, PCIE_IRQ_PULSE);
+ u32 val = exynos_pcie_readl(ep->elbi_base, EXYNOS_PCIE_IRQ_PULSE);
- exynos_pcie_writel(ep->elbi_base, val, PCIE_IRQ_PULSE);
+ exynos_pcie_writel(ep->elbi_base, val, EXYNOS_PCIE_IRQ_PULSE);
}
static irqreturn_t exynos_pcie_irq_handler(int irq, void *arg)
@@ -148,12 +148,12 @@ static irqreturn_t exynos_pcie_irq_handler(int irq, void *arg)
static void exynos_pcie_enable_irq_pulse(struct exynos_pcie *ep)
{
- u32 val = IRQ_INTA_ASSERT | IRQ_INTB_ASSERT |
- IRQ_INTC_ASSERT | IRQ_INTD_ASSERT;
+ u32 val = EXYNOS_IRQ_INTA_ASSERT | EXYNOS_IRQ_INTB_ASSERT |
+ EXYNOS_IRQ_INTC_ASSERT | EXYNOS_IRQ_INTD_ASSERT;
- exynos_pcie_writel(ep->elbi_base, val, PCIE_IRQ_EN_PULSE);
- exynos_pcie_writel(ep->elbi_base, 0, PCIE_IRQ_EN_LEVEL);
- exynos_pcie_writel(ep->elbi_base, 0, PCIE_IRQ_EN_SPECIAL);
+ exynos_pcie_writel(ep->elbi_base, val, EXYNOS_PCIE_IRQ_EN_PULSE);
+ exynos_pcie_writel(ep->elbi_base, 0, EXYNOS_PCIE_IRQ_EN_LEVEL);
+ exynos_pcie_writel(ep->elbi_base, 0, EXYNOS_PCIE_IRQ_EN_SPECIAL);
}
static u32 exynos_pcie_read_dbi(struct dw_pcie *pci, void __iomem *base,
@@ -210,9 +210,9 @@ static struct pci_ops exynos_pci_ops = {
static bool exynos_pcie_link_up(struct dw_pcie *pci)
{
struct exynos_pcie *ep = to_exynos_pcie(pci);
- u32 val = exynos_pcie_readl(ep->elbi_base, PCIE_ELBI_RDLH_LINKUP);
+ u32 val = exynos_pcie_readl(ep->elbi_base, EXYNOS_PCIE_ELBI_RDLH_LINKUP);
- return val & PCIE_ELBI_XMLH_LINKUP;
+ return val & EXYNOS_PCIE_ELBI_XMLH_LINKUP;
}
static int exynos_pcie_host_init(struct dw_pcie_rp *pp)
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 03/10] PCI: exynos: Reorder MACROs to maintain consistency
[not found] ` <CGME20250625165258epcas5p4ddbbcfa60703f3682b94ae4eb814da7e@epcas5p4.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
0 siblings, 0 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi, Hrishikesh Dileep
Exynos PCI file follows MACRO definition order where
register offset is defined in ascending order and each
bit field within the offset is defined right after offset
definition. Some MACROs are out of order and so reorder
those MACROs to maintain consistency.
Suggested-by: Hrishikesh Dileep <hrishikesh.d@samsung.com>
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index 30d12ff9b0c6..b4ec167b0583 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -27,11 +27,11 @@
/* PCIe ELBI registers */
#define EXYNOS_PCIE_IRQ_PULSE 0x000
+#define EXYNOS_PCIE_IRQ_EN_PULSE 0x00c
#define EXYNOS_IRQ_INTA_ASSERT BIT(0)
#define EXYNOS_IRQ_INTB_ASSERT BIT(2)
#define EXYNOS_IRQ_INTC_ASSERT BIT(4)
#define EXYNOS_IRQ_INTD_ASSERT BIT(6)
-#define EXYNOS_PCIE_IRQ_EN_PULSE 0x00c
#define EXYNOS_PCIE_IRQ_EN_LEVEL 0x010
#define EXYNOS_PCIE_IRQ_EN_SPECIAL 0x014
#define EXYNOS_PCIE_SW_WAKE 0x018
@@ -42,9 +42,9 @@
#define EXYNOS_PCIE_NONSTICKY_RESET 0x024
#define EXYNOS_PCIE_APP_INIT_RESET 0x028
#define EXYNOS_PCIE_APP_LTSSM_ENABLE 0x02c
+#define EXYNOS_PCIE_ELBI_LTSSM_ENABLE 0x1
#define EXYNOS_PCIE_ELBI_RDLH_LINKUP 0x074
#define EXYNOS_PCIE_ELBI_XMLH_LINKUP BIT(4)
-#define EXYNOS_PCIE_ELBI_LTSSM_ENABLE 0x1
#define EXYNOS_PCIE_ELBI_SLV_AWMISC 0x11c
#define EXYNOS_PCIE_ELBI_SLV_ARMISC 0x120
#define EXYNOS_PCIE_ELBI_SLV_DBI_ENABLE BIT(21)
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 04/10] PCI: exynos: Add platform device private data
[not found] ` <CGME20250625165305epcas5p31ee49285a57e2fb88a005ec1dfed4199@epcas5p3.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
0 siblings, 0 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
In order to extend this driver to all Samsung manufactured SoCs having
DWC PCIe controller, add private data structure which will hold platform
device specific information. It holds function ops like DWC host ops,
DWC generic ops, and PCI read/write ops which will be used as driver
data for different compatibles.
Suggested-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 32 ++++++++++++++++++++-----
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index b4ec167b0583..c830b20d54f0 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -49,9 +49,16 @@
#define EXYNOS_PCIE_ELBI_SLV_ARMISC 0x120
#define EXYNOS_PCIE_ELBI_SLV_DBI_ENABLE BIT(21)
+struct samsung_pcie_pdata {
+ struct pci_ops *pci_ops;
+ const struct dw_pcie_ops *dwc_ops;
+ const struct dw_pcie_host_ops *host_ops;
+};
+
struct exynos_pcie {
struct dw_pcie pci;
void __iomem *elbi_base;
+ const struct samsung_pcie_pdata *pdata;
struct clk_bulk_data *clks;
struct phy *phy;
struct regulator_bulk_data supplies[2];
@@ -220,7 +227,7 @@ static int exynos_pcie_host_init(struct dw_pcie_rp *pp)
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
struct exynos_pcie *ep = to_exynos_pcie(pci);
- pp->bridge->ops = &exynos_pci_ops;
+ pp->bridge->ops = ep->pdata->pci_ops;
exynos_pcie_assert_core_reset(ep);
@@ -268,7 +275,7 @@ static int exynos_add_pcie_port(struct exynos_pcie *ep,
return 0;
}
-static const struct dw_pcie_ops dw_pcie_ops = {
+static const struct dw_pcie_ops exynos_dw_pcie_ops = {
.read_dbi = exynos_pcie_read_dbi,
.write_dbi = exynos_pcie_write_dbi,
.link_up = exynos_pcie_link_up,
@@ -279,6 +286,7 @@ static int exynos_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct exynos_pcie *ep;
+ const struct samsung_pcie_pdata *pdata;
struct device_node *np = dev->of_node;
int ret;
@@ -286,8 +294,11 @@ static int exynos_pcie_probe(struct platform_device *pdev)
if (!ep)
return -ENOMEM;
+ pdata = of_device_get_match_data(dev);
+
+ ep->pdata = pdata;
ep->pci.dev = dev;
- ep->pci.ops = &dw_pcie_ops;
+ ep->pci.ops = pdata->dwc_ops;
ep->phy = devm_of_phy_get(dev, np, NULL);
if (IS_ERR(ep->phy))
@@ -363,9 +374,9 @@ static int exynos_pcie_resume_noirq(struct device *dev)
return ret;
/* exynos_pcie_host_init controls ep->phy */
- exynos_pcie_host_init(pp);
+ ep->pdata->host_ops->init(pp);
dw_pcie_setup_rc(pp);
- exynos_pcie_start_link(pci);
+ ep->pdata->dwc_ops->start_link(pci);
return dw_pcie_wait_for_link(pci);
}
@@ -374,8 +385,17 @@ static const struct dev_pm_ops exynos_pcie_pm_ops = {
exynos_pcie_resume_noirq)
};
+static const struct samsung_pcie_pdata exynos_5433_pcie_rc_pdata = {
+ .dwc_ops = &exynos_dw_pcie_ops,
+ .pci_ops = &exynos_pci_ops,
+ .host_ops = &exynos_pcie_host_ops,
+};
+
static const struct of_device_id exynos_pcie_of_match[] = {
- { .compatible = "samsung,exynos5433-pcie", },
+ {
+ .compatible = "samsung,exynos5433-pcie",
+ .data = (void *) &exynos_5433_pcie_rc_pdata,
+ },
{ },
};
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 05/10] PCI: exynos: Add structure to hold resource operations
[not found] ` <CGME20250625165310epcas5p309194787ad2c6ac45da32240a8c86c28@epcas5p3.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
0 siblings, 0 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
Some resources might differ based on platforms and we need platform
specific functions to initialize or alter them. For better code
re-usability, making a separate res_ops which will hold all such
function pointers or other resource specific data. Also move common
operations for host init into the probe sequence.
Suggested-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 103 ++++++++++++++++++------
1 file changed, 78 insertions(+), 25 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index c830b20d54f0..dff23cf648f5 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -53,6 +53,7 @@ struct samsung_pcie_pdata {
struct pci_ops *pci_ops;
const struct dw_pcie_ops *dwc_ops;
const struct dw_pcie_host_ops *host_ops;
+ const struct samsung_res_ops *res_ops;
};
struct exynos_pcie {
@@ -61,7 +62,13 @@ struct exynos_pcie {
const struct samsung_pcie_pdata *pdata;
struct clk_bulk_data *clks;
struct phy *phy;
- struct regulator_bulk_data supplies[2];
+ struct regulator_bulk_data *supplies;
+ int supplies_cnt;
+};
+
+struct samsung_res_ops {
+ int (*init_regulator)(struct exynos_pcie *ep);
+ irqreturn_t (*pcie_irq_handler)(int irq, void *arg);
};
static void exynos_pcie_writel(void __iomem *base, u32 val, u32 reg)
@@ -74,6 +81,31 @@ static u32 exynos_pcie_readl(void __iomem *base, u32 reg)
return readl(base + reg);
}
+static int samsung_regulator_enable(struct exynos_pcie *ep)
+{
+ int ret;
+
+ if (ep->supplies_cnt == 0)
+ return 0;
+
+ ret = regulator_bulk_enable(ep->supplies_cnt, ep->supplies);
+
+ return ret;
+}
+
+static void samsung_regulator_disable(struct exynos_pcie *ep)
+{
+ struct device *dev = ep->pci.dev;
+ int ret;
+
+ if (ep->supplies_cnt == 0)
+ return;
+
+ ret = regulator_bulk_disable(ep->supplies_cnt, ep->supplies);
+ if (ret)
+ dev_warn(dev, "failed to disable regulators: %d\n", ret);
+}
+
static void exynos_pcie_sideband_dbi_w_mode(struct exynos_pcie *ep, bool on)
{
u32 val;
@@ -244,7 +276,26 @@ static const struct dw_pcie_host_ops exynos_pcie_host_ops = {
.init = exynos_pcie_host_init,
};
-static int exynos_add_pcie_port(struct exynos_pcie *ep,
+static int exynos_init_regulator(struct exynos_pcie *ep)
+{
+ struct device *dev = ep->pci.dev;
+ int ret = 0;
+
+ ep->supplies_cnt = 2;
+
+ ep->supplies = devm_kcalloc(dev, ep->supplies_cnt, sizeof(*ep->supplies), GFP_KERNEL);
+ if (!ep->supplies)
+ return -ENOMEM;
+
+ ep->supplies[0].supply = "vdd18";
+ ep->supplies[1].supply = "vdd10";
+
+ ret = devm_regulator_bulk_get(dev, ep->supplies_cnt, ep->supplies);
+
+ return ret;
+}
+
+static int samsung_irq_init(struct exynos_pcie *ep,
struct platform_device *pdev)
{
struct dw_pcie *pci = &ep->pci;
@@ -256,22 +307,15 @@ static int exynos_add_pcie_port(struct exynos_pcie *ep,
if (pp->irq < 0)
return pp->irq;
- ret = devm_request_irq(dev, pp->irq, exynos_pcie_irq_handler,
+ ret = devm_request_irq(dev, pp->irq, ep->pdata->res_ops->pcie_irq_handler,
IRQF_SHARED, "exynos-pcie", ep);
if (ret) {
dev_err(dev, "failed to request irq\n");
return ret;
}
- pp->ops = &exynos_pcie_host_ops;
pp->msi_irq[0] = -ENODEV;
- ret = dw_pcie_host_init(pp);
- if (ret) {
- dev_err(dev, "failed to initialize host\n");
- return ret;
- }
-
return 0;
}
@@ -282,6 +326,11 @@ static const struct dw_pcie_ops exynos_dw_pcie_ops = {
.start_link = exynos_pcie_start_link,
};
+static const struct samsung_res_ops exynos_res_ops_data = {
+ .init_regulator = exynos_init_regulator,
+ .pcie_irq_handler = exynos_pcie_irq_handler,
+};
+
static int exynos_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -313,28 +362,31 @@ static int exynos_pcie_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
- ep->supplies[0].supply = "vdd18";
- ep->supplies[1].supply = "vdd10";
- ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(ep->supplies),
- ep->supplies);
- if (ret)
- return ret;
+ if (pdata->res_ops && pdata->res_ops->init_regulator) {
+ ret = ep->pdata->res_ops->init_regulator(ep);
+ if (ret)
+ return ret;
+ }
- ret = regulator_bulk_enable(ARRAY_SIZE(ep->supplies), ep->supplies);
+ ret = samsung_regulator_enable(ep);
if (ret)
return ret;
platform_set_drvdata(pdev, ep);
-
- ret = exynos_add_pcie_port(ep, pdev);
+ ret = samsung_irq_init(ep, pdev);
+ if (ret)
+ goto fail_regulator;
+ ep->pci.pp.ops = pdata->host_ops;
+ ret = dw_pcie_host_init(&ep->pci.pp);
if (ret < 0)
- goto fail_probe;
+ goto fail_phy_init;
return 0;
-fail_probe:
+fail_phy_init:
phy_exit(ep->phy);
- regulator_bulk_disable(ARRAY_SIZE(ep->supplies), ep->supplies);
+fail_regulator:
+ samsung_regulator_disable(ep);
return ret;
}
@@ -347,7 +399,7 @@ static void exynos_pcie_remove(struct platform_device *pdev)
exynos_pcie_assert_core_reset(ep);
phy_power_off(ep->phy);
phy_exit(ep->phy);
- regulator_bulk_disable(ARRAY_SIZE(ep->supplies), ep->supplies);
+ samsung_regulator_disable(ep);
}
static int exynos_pcie_suspend_noirq(struct device *dev)
@@ -357,7 +409,7 @@ static int exynos_pcie_suspend_noirq(struct device *dev)
exynos_pcie_assert_core_reset(ep);
phy_power_off(ep->phy);
phy_exit(ep->phy);
- regulator_bulk_disable(ARRAY_SIZE(ep->supplies), ep->supplies);
+ samsung_regulator_disable(ep);
return 0;
}
@@ -369,7 +421,7 @@ static int exynos_pcie_resume_noirq(struct device *dev)
struct dw_pcie_rp *pp = &pci->pp;
int ret;
- ret = regulator_bulk_enable(ARRAY_SIZE(ep->supplies), ep->supplies);
+ ret = samsung_regulator_enable(ep);
if (ret)
return ret;
@@ -389,6 +441,7 @@ static const struct samsung_pcie_pdata exynos_5433_pcie_rc_pdata = {
.dwc_ops = &exynos_dw_pcie_ops,
.pci_ops = &exynos_pci_ops,
.host_ops = &exynos_pcie_host_ops,
+ .res_ops = &exynos_res_ops_data,
};
static const struct of_device_id exynos_pcie_of_match[] = {
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
[not found] ` <CGME20250625165315epcas5p19f081c8a0e2e7dc87698577cc2d460ca@epcas5p1.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
2025-06-27 16:29 ` Bjorn Helgaas
2025-06-27 21:12 ` Rob Herring
0 siblings, 2 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
Document the PCIe controller device tree bindings for Tesla FSD
SoC for both RC and EP.
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
.../bindings/pci/samsung,exynos-pcie.yaml | 121 ++++++++++++------
.../bindings/pci/tesla,fsd-pcie-ep.yaml | 91 +++++++++++++
2 files changed, 176 insertions(+), 36 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
index f20ed7e709f7..595156759b06 100644
--- a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
@@ -11,16 +11,15 @@ maintainers:
- Jaehoon Chung <jh80.chung@samsung.com>
description: |+
- Exynos5433 SoC PCIe host controller is based on the Synopsys DesignWare
+ Samsung SoCs PCIe host controller is based on the Synopsys DesignWare
PCIe IP and thus inherits all the common properties defined in
snps,dw-pcie.yaml.
-allOf:
- - $ref: /schemas/pci/snps,dw-pcie.yaml#
-
properties:
compatible:
- const: samsung,exynos5433-pcie
+ enum:
+ - samsung,exynos5433-pcie
+ - tesla,fsd-pcie
reg:
items:
@@ -37,52 +36,102 @@ properties:
interrupts:
maxItems: 1
- clocks:
- items:
- - description: PCIe bridge clock
- - description: PCIe bus clock
-
- clock-names:
- items:
- - const: pcie
- - const: pcie_bus
-
phys:
maxItems: 1
- vdd10-supply:
- description:
- Phandle to a regulator that provides 1.0V power to the PCIe block.
-
- vdd18-supply:
- description:
- Phandle to a regulator that provides 1.8V power to the PCIe block.
-
- num-lanes:
- const: 1
-
- num-viewport:
- const: 3
-
required:
- reg
- reg-names
- interrupts
- "#address-cells"
- "#size-cells"
- - "#interrupt-cells"
- - interrupt-map
- - interrupt-map-mask
- ranges
- - bus-range
- device_type
- num-lanes
- - num-viewport
- clocks
- clock-names
- phys
- - vdd10-supply
- - vdd18-supply
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - tesla,fsd-pcie
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: aux
+ - const: dbi
+ - const: mstr
+ - const: slv
+
+ samsung,syscon-pcie:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: phandle for system control registers, used to
+ control signals at system level
+
+ num-lanes:
+ maximum: 4
+
+ required:
+ - samsung,syscon-pcie
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - samsung,exynos5433-pcie
+ then:
+ properties:
+ clocks:
+ items:
+ - description: pcie bridge clock
+ - description: pcie bus clock
+
+ clock-names:
+ items:
+ - const: pcie
+ - const: pcie_bus
+
+ vdd10-supply:
+ description:
+ phandle to a regulator that provides 1.0v power to the pcie block.
+
+ vdd18-supply:
+ description:
+ phandle to a regulator that provides 1.8v power to the pcie block.
+
+ num-lanes:
+ const: 1
+
+ num-viewport:
+ const: 3
+
+ assigned-clocks:
+ maxItems: 2
+
+ assigned-clock-parents:
+ maxItems: 2
+
+ assigned-clock-rates:
+ maxItems: 2
+
+ required:
+ - "#interrupt-cells"
+ - interrupt-map
+ - interrupt-map-mask
+ - bus-range
+ - num-viewport
+ - vdd10-supply
+ - vdd18-supply
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
new file mode 100644
index 000000000000..f85615a0225d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/tesla,fsd-pcie-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Samsung SoC series PCIe Endpoint Controller
+
+maintainers:
+ - Shradha Todi <shradha.t@samsung.com>
+
+description: |+
+ Samsung SoCs PCIe endpoint controller is based on the Synopsys DesignWare
+ PCIe IP and thus inherits all the common properties defined in
+ snps,dw-pcie-ep.yaml.
+
+allOf:
+ - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
+
+properties:
+ compatible:
+ const: tesla,fsd-pcie-ep
+
+ reg:
+ maxItems: 4
+
+ reg-names:
+ items:
+ - const: elbi
+ - const: dbi
+ - const: dbi2
+ - const: addr_space
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: aux
+ - const: dbi
+ - const: mstr
+ - const: slv
+
+ num-lanes:
+ maximum: 4
+
+ samsung,syscon-pcie:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: phandle for system control registers, used to
+ control signals at system level
+
+ phys:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - num-lanes
+ - samsung,syscon-pcie
+ - phys
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/fsd-clk.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcieep0: pcie-ep@16a00000 {
+ compatible = "tesla,fsd-pcie-ep";
+ reg = <0x0 0x168b0000 0x0 0x1000>,
+ <0x0 0x16a00000 0x0 0x2000>,
+ <0x0 0x16a01000 0x0 0x80>,
+ <0x0 0x17000000 0x0 0xff0000>;
+ reg-names = "elbi", "dbi", "dbi2", "addr_space";
+ clocks = <&clock_fsys1 PCIE_LINK0_IPCLKPORT_AUX_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_DBI_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_MSTR_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_SLV_ACLK>;
+ clock-names = "aux", "dbi", "mstr", "slv";
+ num-lanes = <4>;
+ samsung,syscon-pcie = <&sysreg_fsys1 0x50c>;
+ phys = <&pciephy1>;
+ };
+ };
+...
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
[not found] ` <CGME20250625165319epcas5p3721c19f6e6b482438c62dd1ef784de03@epcas5p3.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
2025-06-27 21:17 ` Rob Herring
0 siblings, 1 reply; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
Document PHY device tree bindings for Tesla FSD SoCs.
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
.../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
index 41df8bb08ff7..4dc20156cdde 100644
--- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
@@ -15,10 +15,13 @@ properties:
const: 0
compatible:
- const: samsung,exynos5433-pcie-phy
+ enum:
+ - samsung,exynos5433-pcie-phy
+ - tesla,fsd-pcie-phy
reg:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
samsung,pmu-syscon:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -30,6 +33,24 @@ properties:
description: phandle for FSYS sysreg interface, used to control
sysreg registers bits for PCIe PHY
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - tesla,fsd-pcie-phy
+ then:
+ description:
+ The PHY controller nodes are represented in the aliases node
+ using the following format 'pciephy{n}'. Depending on whether
+ n is 0 or 1, the phy init sequence is chosen.
+ properties:
+ reg:
+ items:
+ - description: PHY
+ - description: PCS
+
required:
- "#phy-cells"
- compatible
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 08/10] phy: exynos: Add PCIe PHY support for FSD SoC
[not found] ` <CGME20250625165323epcas5p44d291cb0b46df7e015907e4c2903447f@epcas5p4.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
2025-06-26 23:09 ` Vinod Koul
0 siblings, 1 reply; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
Add PCIe PHY support for Tesla FSD SoC.
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
drivers/phy/samsung/phy-exynos-pcie.c | 317 +++++++++++++++++++++++++-
1 file changed, 316 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/samsung/phy-exynos-pcie.c b/drivers/phy/samsung/phy-exynos-pcie.c
index 53c9230c2907..001a49bde2f4 100644
--- a/drivers/phy/samsung/phy-exynos-pcie.c
+++ b/drivers/phy/samsung/phy-exynos-pcie.c
@@ -34,11 +34,113 @@
/* PMU PCIE PHY isolation control */
#define EXYNOS5433_PMU_PCIE_PHY_OFFSET 0x730
+/* FSD: PCIe PHY common registers */
+#define FSD_PCIE_PHY_TRSV_CMN_REG03 0x000c
+#define FSD_PCIE_PHY_TRSV_CMN_REG01E 0x0078
+#define FSD_PCIE_PHY_TRSV_CMN_REG02D 0x00b4
+#define FSD_PCIE_PHY_TRSV_CMN_REG031 0x00c4
+#define FSD_PCIE_PHY_TRSV_CMN_REG036 0x00d8
+#define FSD_PCIE_PHY_TRSV_CMN_REG05F 0x017c
+#define FSD_PCIE_PHY_TRSV_CMN_REG060 0x0180
+#define FSD_PCIE_PHY_TRSV_CMN_REG062 0x0188
+#define FSD_PCIE_PHY_TRSV_CMN_REG061 0x0184
+#define FSD_PCIE_PHY_AGG_BIF_RESET 0x0200
+#define FSD_PCIE_PHY_AGG_BIF_CLOCK 0x0208
+#define FSD_PCIE_PHY_CMN_RESET 0x0228
+
+/* FSD: PCIe PHY lane registers */
+#define FSD_PCIE_LANE_OFFSET 0x0400
+#define FSD_PCIE_NUM_LANES 0x4
+
+#define FSD_PCIE_PHY_TRSV_REG001_LN_N 0x0404
+#define FSD_PCIE_PHY_TRSV_REG002_LN_N 0x0408
+#define FSD_PCIE_PHY_TRSV_REG005_LN_N 0x0414
+#define FSD_PCIE_PHY_TRSV_REG006_LN_N 0x0418
+#define FSD_PCIE_PHY_TRSV_REG007_LN_N 0x041c
+#define FSD_PCIE_PHY_TRSV_REG009_LN_N 0x0424
+#define FSD_PCIE_PHY_TRSV_REG00A_LN_N 0x0428
+#define FSD_PCIE_PHY_TRSV_REG00C_LN_N 0x0430
+#define FSD_PCIE_PHY_TRSV_REG012_LN_N 0x0448
+#define FSD_PCIE_PHY_TRSV_REG013_LN_N 0x044c
+#define FSD_PCIE_PHY_TRSV_REG014_LN_N 0x0450
+#define FSD_PCIE_PHY_TRSV_REG015_LN_N 0x0454
+#define FSD_PCIE_PHY_TRSV_REG016_LN_N 0x0458
+#define FSD_PCIE_PHY_TRSV_REG018_LN_N 0x0460
+#define FSD_PCIE_PHY_TRSV_REG020_LN_N 0x0480
+#define FSD_PCIE_PHY_TRSV_REG026_LN_N 0x0498
+#define FSD_PCIE_PHY_TRSV_REG029_LN_N 0x04a4
+#define FSD_PCIE_PHY_TRSV_REG031_LN_N 0x04c4
+#define FSD_PCIE_PHY_TRSV_REG036_LN_N 0x04d8
+#define FSD_PCIE_PHY_TRSV_REG039_LN_N 0x04e4
+#define FSD_PCIE_PHY_TRSV_REG03B_LN_N 0x04ec
+#define FSD_PCIE_PHY_TRSV_REG03C_LN_N 0x04f0
+#define FSD_PCIE_PHY_TRSV_REG03E_LN_N 0x04f8
+#define FSD_PCIE_PHY_TRSV_REG03F_LN_N 0x04fc
+#define FSD_PCIE_PHY_TRSV_REG043_LN_N 0x050c
+#define FSD_PCIE_PHY_TRSV_REG044_LN_N 0x0510
+#define FSD_PCIE_PHY_TRSV_REG046_LN_N 0x0518
+#define FSD_PCIE_PHY_TRSV_REG048_LN_N 0x0520
+#define FSD_PCIE_PHY_TRSV_REG049_LN_N 0x0524
+#define FSD_PCIE_PHY_TRSV_REG04E_LN_N 0x0538
+#define FSD_PCIE_PHY_TRSV_REG052_LN_N 0x0548
+#define FSD_PCIE_PHY_TRSV_REG068_LN_N 0x05a0
+#define FSD_PCIE_PHY_TRSV_REG069_LN_N 0x05a4
+#define FSD_PCIE_PHY_TRSV_REG06A_LN_N 0x05a8
+#define FSD_PCIE_PHY_TRSV_REG06B_LN_N 0x05ac
+#define FSD_PCIE_PHY_TRSV_REG07B_LN_N 0x05ec
+#define FSD_PCIE_PHY_TRSV_REG083_LN_N 0x060c
+#define FSD_PCIE_PHY_TRSV_REG084_LN_N 0x0610
+#define FSD_PCIE_PHY_TRSV_REG086_LN_N 0x0618
+#define FSD_PCIE_PHY_TRSV_REG087_LN_N 0x061c
+#define FSD_PCIE_PHY_TRSV_REG08B_LN_N 0x062c
+#define FSD_PCIE_PHY_TRSV_REG09C_LN_N 0x0670
+#define FSD_PCIE_PHY_TRSV_REG09D_LN_N 0x0674
+#define FSD_PCIE_PHY_TRSV_REG09E_LN_N 0x0678
+#define FSD_PCIE_PHY_TRSV_REG09F_LN_N 0x067c
+#define FSD_PCIE_PHY_TRSV_REG0A2_LN_N 0x0688
+#define FSD_PCIE_PHY_TRSV_REG0A4_LN_N 0x0690
+#define FSD_PCIE_PHY_TRSV_REG0CE_LN_N 0x0738
+#define FSD_PCIE_PHY_TRSV_REG0FC_LN_N 0x07f0
+#define FSD_PCIE_PHY_TRSV_REG0FD_LN_N 0x07f4
+#define FSD_PCIE_PHY_TRSV_REG0FE_LN_N 0x07f8
+#define FSD_PCIE_PHY_TRSV_REG0CE_LN_1 0x0b38
+#define FSD_PCIE_PHY_TRSV_REG0CE_LN_2 0x0f38
+#define FSD_PCIE_PHY_TRSV_REG0CE_LN_3 0x1338
+
+/* FSD: PCIe PCS registers */
+#define FSD_PCIE_PCS_BRF_0 0x0004
+#define FSD_PCIE_PCS_BRF_1 0x0804
+#define FSD_PCIE_PCS_CLK 0x0180
+
+/* FSD: PCIe SYSREG registers */
+#define FSD_PCIE_SYSREG_PHY_0_CON 0x042c
+#define FSD_PCIE_SYSREG_PHY_0_CON_MASK 0x03ff
+#define FSD_PCIE_SYSREG_PHY_0_REF_SEL (0x2 << 0)
+#define FSD_PCIE_SYSREG_PHY_0_REF_SEL_MASK 0x3
+#define FSD_PCIE_SYSREG_PHY_0_AUX_EN BIT(4)
+#define FSD_PCIE_SYSREG_PHY_0_CMN_RSTN BIT(8)
+#define FSD_PCIE_SYSREG_PHY_0_INIT_RSTN BIT(9)
+
+#define FSD_PCIE_SYSREG_PHY_1_CON 0x0500
+#define FSD_PCIE_SYSREG_PHY_1_CON_MASK 0x01ff
+#define FSD_PCIE_SYSREG_PHY_1_REF_SEL (0x2 << 4)
+#define FSD_PCIE_SYSREG_PHY_1_REF_SEL_MASK 0x30
+#define FSD_PCIE_SYSREG_PHY_1_AUX_EN BIT(0)
+#define FSD_PCIE_SYSREG_PHY_1_CMN_RSTN BIT(1)
+#define FSD_PCIE_SYSREG_PHY_1_INIT_RSTN BIT(3)
+
/* For Exynos pcie phy */
struct exynos_pcie_phy {
void __iomem *base;
+ void __iomem *pcs_base;
struct regmap *pmureg;
struct regmap *fsysreg;
+ int phy_id;
+ const struct samsung_drv_data *drv_data;
+};
+
+struct samsung_drv_data {
+ const struct phy_ops *phy_ops;
};
static void exynos_pcie_phy_writel(void __iomem *base, u32 val, u32 offset)
@@ -133,9 +235,212 @@ static const struct phy_ops exynos5433_phy_ops = {
.owner = THIS_MODULE,
};
+static void fsd_pcie_phy_writel(struct exynos_pcie_phy *phy_ctrl, u32 offset, u32 val)
+{
+ void __iomem *phy_base = phy_ctrl->base;
+ u32 i;
+
+ for (i = 0; i < FSD_PCIE_NUM_LANES; i++)
+ writel(val, phy_base + (offset + i * FSD_PCIE_LANE_OFFSET));
+}
+
+struct fsd_pcie_phy_pdata {
+ u32 phy_con_offset;
+ u32 phy_con_mask;
+ u32 phy_ref_sel;
+ u32 phy_ref_sel_mask;
+ u32 phy_aux_en;
+ u32 phy_cmn_rstn;
+ u32 phy_init_rstn;
+};
+
+static const struct fsd_pcie_phy_pdata fsd_phy_con[] = {
+{
+ .phy_con_offset = FSD_PCIE_SYSREG_PHY_0_CON,
+ .phy_con_mask = FSD_PCIE_SYSREG_PHY_0_CON_MASK,
+ .phy_ref_sel = FSD_PCIE_SYSREG_PHY_0_REF_SEL,
+ .phy_ref_sel_mask = FSD_PCIE_SYSREG_PHY_0_REF_SEL_MASK,
+ .phy_aux_en = FSD_PCIE_SYSREG_PHY_0_AUX_EN,
+ .phy_cmn_rstn = FSD_PCIE_SYSREG_PHY_0_CMN_RSTN,
+ .phy_init_rstn = FSD_PCIE_SYSREG_PHY_0_INIT_RSTN,
+ },
+ {
+ .phy_con_offset = FSD_PCIE_SYSREG_PHY_1_CON,
+ .phy_con_mask = FSD_PCIE_SYSREG_PHY_1_CON_MASK,
+ .phy_ref_sel = FSD_PCIE_SYSREG_PHY_1_REF_SEL,
+ .phy_ref_sel_mask = FSD_PCIE_SYSREG_PHY_1_REF_SEL_MASK,
+ .phy_aux_en = FSD_PCIE_SYSREG_PHY_1_AUX_EN,
+ .phy_cmn_rstn = FSD_PCIE_SYSREG_PHY_1_CMN_RSTN,
+ .phy_init_rstn = FSD_PCIE_SYSREG_PHY_1_INIT_RSTN,
+ },
+ { },
+};
+
+static int fsd_pcie_phy_reset(struct phy *phy)
+{
+ struct exynos_pcie_phy *phy_ctrl = phy_get_drvdata(phy);
+ const struct fsd_pcie_phy_pdata *pdata = &fsd_phy_con[phy_ctrl->phy_id];
+
+ writel(0x1, phy_ctrl->pcs_base + FSD_PCIE_PCS_CLK);
+
+ regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
+ pdata->phy_con_mask, 0x0);
+ regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
+ pdata->phy_aux_en, pdata->phy_aux_en);
+ regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
+ pdata->phy_ref_sel_mask, pdata->phy_ref_sel);
+ /* perform init reset release */
+ regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
+ pdata->phy_init_rstn, pdata->phy_init_rstn);
+
+ return 0;
+}
+
+static void fsd_pcie_phy1_init(struct exynos_pcie_phy *phy_ctrl)
+{
+ void __iomem *pbase = phy_ctrl->base;
+
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG07B_LN_N, 0x20);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG052_LN_N, 0x00);
+ writel(0xaa, pbase + FSD_PCIE_PHY_TRSV_CMN_REG01E);
+ writel(0x28, pbase + FSD_PCIE_PHY_TRSV_CMN_REG02D);
+ writel(0x28, pbase + FSD_PCIE_PHY_TRSV_CMN_REG031);
+ writel(0x21, pbase + FSD_PCIE_PHY_TRSV_CMN_REG036);
+ writel(0x12, pbase + FSD_PCIE_PHY_TRSV_CMN_REG05F);
+ writel(0x23, pbase + FSD_PCIE_PHY_TRSV_CMN_REG060);
+ writel(0x0, pbase + FSD_PCIE_PHY_TRSV_CMN_REG061);
+ writel(0x0, pbase + FSD_PCIE_PHY_TRSV_CMN_REG062);
+ writel(0x15, pbase + FSD_PCIE_PHY_TRSV_CMN_REG03);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG039_LN_N, 0xf);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03B_LN_N, 0x13);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03C_LN_N, 0x66);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG044_LN_N, 0x57);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03E_LN_N, 0x10);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03F_LN_N, 0x44);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG043_LN_N, 0x11);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG046_LN_N, 0xef);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG048_LN_N, 0x06);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG049_LN_N, 0xaf);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG04E_LN_N, 0x28);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG068_LN_N, 0x1f);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG069_LN_N, 0xc);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG06A_LN_N, 0x8);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG06B_LN_N, 0x78);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG083_LN_N, 0xa);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG084_LN_N, 0x80);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG087_LN_N, 0x30);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG08B_LN_N, 0xa0);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09C_LN_N, 0xf7);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09E_LN_N, 0x33);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0A2_LN_N, 0xfa);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0A4_LN_N, 0xf2);
+ writel(0x8, pbase + FSD_PCIE_PHY_TRSV_REG0CE_LN_N);
+ writel(0x9, pbase + FSD_PCIE_PHY_TRSV_REG0CE_LN_1);
+ writel(0x9, pbase + FSD_PCIE_PHY_TRSV_REG0CE_LN_2);
+ writel(0x9, pbase + FSD_PCIE_PHY_TRSV_REG0CE_LN_3);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0FE_LN_N, 0x33);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG001_LN_N, 0x3f);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG005_LN_N, 0x2b);
+}
+
+static void fsd_pcie_phy0_init(struct exynos_pcie_phy *phy_ctrl)
+{
+ void __iomem *pbase = phy_ctrl->base;
+
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG07B_LN_N, 0x20);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG052_LN_N, 0x00);
+ writel(0x11, pbase + FSD_PCIE_PHY_TRSV_CMN_REG05F);
+ writel(0x23, pbase + FSD_PCIE_PHY_TRSV_CMN_REG060);
+ writel(0x0, pbase + FSD_PCIE_PHY_TRSV_CMN_REG062);
+ writel(0x15, pbase + FSD_PCIE_PHY_TRSV_CMN_REG03);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0CE_LN_N, 0x8);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG039_LN_N, 0xf);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03B_LN_N, 0x13);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03C_LN_N, 0xf6);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG044_LN_N, 0x57);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03E_LN_N, 0x10);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03F_LN_N, 0x04);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG043_LN_N, 0x11);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG049_LN_N, 0x6f);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG04E_LN_N, 0x18);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG068_LN_N, 0x1f);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG069_LN_N, 0xc);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG06B_LN_N, 0x78);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG083_LN_N, 0xa);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG084_LN_N, 0x80);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG086_LN_N, 0xff);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG087_LN_N, 0x3c);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09D_LN_N, 0x7c);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09E_LN_N, 0x33);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09F_LN_N, 0x33);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG001_LN_N, 0x3f);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG002_LN_N, 0x1c);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG005_LN_N, 0x2b);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG006_LN_N, 0x3);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG007_LN_N, 0x0c);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG009_LN_N, 0x10);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG00A_LN_N, 0x1);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG00C_LN_N, 0x93);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG012_LN_N, 0x1);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG013_LN_N, 0x0);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG014_LN_N, 0x70);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG015_LN_N, 0x0);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG016_LN_N, 0x70);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0FC_LN_N, 0x80);
+ fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0FD_LN_N, 0x0);
+}
+
+static int fsd_pcie_phy_init(struct phy *phy)
+{
+ struct exynos_pcie_phy *phy_ctrl = phy_get_drvdata(phy);
+ void __iomem *phy_base = phy_ctrl->base;
+ const struct fsd_pcie_phy_pdata *pdata = &fsd_phy_con[phy_ctrl->phy_id];
+
+ fsd_pcie_phy_reset(phy);
+
+ if (phy_ctrl->phy_id == 1)
+ writel(0x2, phy_base + FSD_PCIE_PHY_CMN_RESET);
+
+ writel(0x00, phy_ctrl->pcs_base + FSD_PCIE_PCS_BRF_0);
+ writel(0x00, phy_ctrl->pcs_base + FSD_PCIE_PCS_BRF_1);
+ writel(0x00, phy_base + FSD_PCIE_PHY_AGG_BIF_RESET);
+ writel(0x00, phy_base + FSD_PCIE_PHY_AGG_BIF_CLOCK);
+
+ if (phy_ctrl->phy_id == 1) {
+ fsd_pcie_phy1_init(phy_ctrl);
+ writel(0x3, phy_base + FSD_PCIE_PHY_CMN_RESET);
+ } else {
+ fsd_pcie_phy0_init(phy_ctrl);
+ }
+
+ regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
+ pdata->phy_cmn_rstn, pdata->phy_cmn_rstn);
+
+ return 0;
+}
+
+static const struct phy_ops fsd_phy_ops = {
+ .init = fsd_pcie_phy_init,
+ .reset = fsd_pcie_phy_reset,
+ .owner = THIS_MODULE,
+};
+
+static const struct samsung_drv_data exynos5433_drv_data = {
+ .phy_ops = &exynos5433_phy_ops,
+};
+
+static const struct samsung_drv_data fsd_drv_data = {
+ .phy_ops = &fsd_phy_ops,
+};
+
static const struct of_device_id exynos_pcie_phy_match[] = {
{
.compatible = "samsung,exynos5433-pcie-phy",
+ .data = &exynos5433_drv_data,
+ },
+ {
+ .compatible = "tesla,fsd-pcie-phy",
+ .data = &fsd_drv_data,
},
{},
};
@@ -146,11 +451,18 @@ static int exynos_pcie_phy_probe(struct platform_device *pdev)
struct exynos_pcie_phy *exynos_phy;
struct phy *generic_phy;
struct phy_provider *phy_provider;
+ const struct samsung_drv_data *drv_data;
+
+ drv_data = of_device_get_match_data(dev);
+ if (!drv_data)
+ return -ENODEV;
exynos_phy = devm_kzalloc(dev, sizeof(*exynos_phy), GFP_KERNEL);
if (!exynos_phy)
return -ENOMEM;
+ exynos_phy->drv_data = drv_data;
+
exynos_phy->base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(exynos_phy->base))
return PTR_ERR(exynos_phy->base);
@@ -169,12 +481,15 @@ static int exynos_pcie_phy_probe(struct platform_device *pdev)
return PTR_ERR(exynos_phy->fsysreg);
}
- generic_phy = devm_phy_create(dev, dev->of_node, &exynos5433_phy_ops);
+ generic_phy = devm_phy_create(dev, dev->of_node, drv_data->phy_ops);
if (IS_ERR(generic_phy)) {
dev_err(dev, "failed to create PHY\n");
return PTR_ERR(generic_phy);
}
+ exynos_phy->pcs_base = devm_platform_ioremap_resource(pdev, 1);
+
+ exynos_phy->phy_id = of_alias_get_id(dev->of_node, "pciephy");
phy_set_drvdata(generic_phy, exynos_phy);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 09/10] PCI: exynos: Add support for Tesla FSD SoC
[not found] ` <CGME20250625165327epcas5p2c51b6032a6439cd1a7a884b360be1354@epcas5p2.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
2025-06-27 19:30 ` Bjorn Helgaas
2025-06-30 16:26 ` Dan Carpenter
0 siblings, 2 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
Add host and endpoint controller driver support for FSD SoC.
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
drivers/pci/controller/dwc/pci-exynos.c | 331 +++++++++++++++++++++++-
1 file changed, 323 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-exynos.c b/drivers/pci/controller/dwc/pci-exynos.c
index dff23cf648f5..5b525156b9f5 100644
--- a/drivers/pci/controller/dwc/pci-exynos.c
+++ b/drivers/pci/controller/dwc/pci-exynos.c
@@ -20,6 +20,8 @@
#include <linux/regulator/consumer.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/mfd/syscon.h>
#include "pcie-designware.h"
@@ -49,17 +51,46 @@
#define EXYNOS_PCIE_ELBI_SLV_ARMISC 0x120
#define EXYNOS_PCIE_ELBI_SLV_DBI_ENABLE BIT(21)
+#define FSD_IRQ2_STS 0x008
+#define FSD_IRQ_MSI_ENABLE BIT(17)
+#define FSD_IRQ2_EN 0x018
+#define FSD_PCIE_APP_LTSSM_ENABLE 0x054
+#define FSD_PCIE_LTSSM_ENABLE 0x1
+#define FSD_PCIE_DEVICE_TYPE 0x080
+#define FSD_DEVICE_TYPE_RC 0x4
+#define FSD_DEVICE_TYPE_EP 0x0
+#define FSD_PCIE_CXPL_DEBUG_00_31 0x2C8
+
+/* to store different SoC variants of Samsung */
+enum samsung_pcie_variants {
+ FSD,
+ EXYNOS_5433,
+};
+
+/* Values to be written to SYSREG to view DBI space as CDM/DBI2/IATU/DMA */
+enum fsd_pcie_addr_type {
+ ADDR_TYPE_DBI = 0x0,
+ ADDR_TYPE_DBI2 = 0x12,
+ ADDR_TYPE_ATU = 0x36,
+ ADDR_TYPE_DMA = 0x3f,
+};
+
struct samsung_pcie_pdata {
struct pci_ops *pci_ops;
const struct dw_pcie_ops *dwc_ops;
const struct dw_pcie_host_ops *host_ops;
+ const struct dw_pcie_ep_ops *ep_ops;
const struct samsung_res_ops *res_ops;
+ unsigned int soc_variant;
+ enum dw_pcie_device_mode device_mode;
};
struct exynos_pcie {
struct dw_pcie pci;
void __iomem *elbi_base;
const struct samsung_pcie_pdata *pdata;
+ struct regmap *sysreg;
+ unsigned int sysreg_offset;
struct clk_bulk_data *clks;
struct phy *phy;
struct regulator_bulk_data *supplies;
@@ -69,6 +100,7 @@ struct exynos_pcie {
struct samsung_res_ops {
int (*init_regulator)(struct exynos_pcie *ep);
irqreturn_t (*pcie_irq_handler)(int irq, void *arg);
+ void (*set_device_mode)(struct exynos_pcie *ep);
};
static void exynos_pcie_writel(void __iomem *base, u32 val, u32 reg)
@@ -326,11 +358,203 @@ static const struct dw_pcie_ops exynos_dw_pcie_ops = {
.start_link = exynos_pcie_start_link,
};
+static void fsd_pcie_stop_link(struct dw_pcie *pci)
+{
+ u32 val;
+ struct exynos_pcie *ep = to_exynos_pcie(pci);
+
+ val = readl(ep->elbi_base + FSD_PCIE_APP_LTSSM_ENABLE);
+ val &= ~FSD_PCIE_LTSSM_ENABLE;
+ writel(val, ep->elbi_base + FSD_PCIE_APP_LTSSM_ENABLE);
+}
+
+static int fsd_pcie_start_link(struct dw_pcie *pci)
+{
+ struct exynos_pcie *ep = to_exynos_pcie(pci);
+ struct dw_pcie_ep *dw_ep = &pci->ep;
+
+ if (dw_pcie_link_up(pci))
+ return 0;
+
+ writel(FSD_PCIE_LTSSM_ENABLE, ep->elbi_base + FSD_PCIE_APP_LTSSM_ENABLE);
+
+ /* no need to wait for link in case of host as core files take care */
+ if (ep->pdata->device_mode == DW_PCIE_RC_TYPE)
+ return 0;
+
+ /* check if the link is up or not in case of EP */
+ if (!dw_pcie_wait_for_link(pci)) {
+ dw_pcie_ep_linkup(dw_ep);
+ return 0;
+ }
+
+ return -ETIMEDOUT;
+}
+
+static irqreturn_t fsd_pcie_irq_handler(int irq, void *arg)
+{
+ u32 val;
+ struct exynos_pcie *ep = arg;
+ struct dw_pcie *pci = &ep->pci;
+ struct dw_pcie_rp *pp = &pci->pp;
+
+ val = readl(ep->elbi_base + FSD_IRQ2_STS);
+ if ((val & FSD_IRQ_MSI_ENABLE) == FSD_IRQ_MSI_ENABLE) {
+ val &= FSD_IRQ_MSI_ENABLE;
+ writel(val, ep->elbi_base + FSD_IRQ2_STS);
+ dw_handle_msi_irq(pp);
+ }
+
+ return IRQ_HANDLED;
+}
+
+static void fsd_pcie_msi_init(struct exynos_pcie *ep)
+{
+ int val;
+
+ val = readl(ep->elbi_base + FSD_IRQ2_EN);
+ val |= FSD_IRQ_MSI_ENABLE;
+ writel(val, ep->elbi_base + FSD_IRQ2_EN);
+}
+
+static void __iomem *fsd_atu_setting(struct dw_pcie *pci, void __iomem *base)
+{
+ struct exynos_pcie *ep = to_exynos_pcie(pci);
+
+ if (base >= pci->atu_base) {
+ regmap_write(ep->sysreg, ep->sysreg_offset, ADDR_TYPE_ATU);
+ return (base - DEFAULT_DBI_ATU_OFFSET);
+ } else if (base == pci->dbi_base) {
+ regmap_write(ep->sysreg, ep->sysreg_offset, ADDR_TYPE_DBI);
+ } else if (base == pci->dbi_base2) {
+ regmap_write(ep->sysreg, ep->sysreg_offset, ADDR_TYPE_DBI2);
+ }
+
+ return base;
+}
+
+static u32 fsd_pcie_read_dbi(struct dw_pcie *pci, void __iomem *base,
+ u32 reg, size_t size)
+{
+ void __iomem *addr;
+ u32 val;
+
+ addr = fsd_atu_setting(pci, base);
+
+ dw_pcie_read(addr + reg, size, &val);
+
+ return val;
+}
+
+static void fsd_pcie_write_dbi(struct dw_pcie *pci, void __iomem *base,
+ u32 reg, size_t size, u32 val)
+{
+ void __iomem *addr;
+
+ addr = fsd_atu_setting(pci, base);
+
+ dw_pcie_write(addr + reg, size, val);
+}
+
+static void fsd_pcie_write_dbi2(struct dw_pcie *pci, void __iomem *base,
+ u32 reg, size_t size, u32 val)
+{
+ struct exynos_pcie *ep = to_exynos_pcie(pci);
+
+ fsd_atu_setting(pci, base);
+ dw_pcie_write(pci->dbi_base + reg, size, val);
+ regmap_write(ep->sysreg, ep->sysreg_offset, ADDR_TYPE_DBI);
+}
+
+static bool fsd_pcie_link_up(struct dw_pcie *pci)
+{
+ u32 val;
+ struct exynos_pcie *ep = to_exynos_pcie(pci);
+
+ val = readl(ep->elbi_base + FSD_PCIE_CXPL_DEBUG_00_31);
+ val &= PORT_LOGIC_LTSSM_STATE_MASK;
+
+ return (val == PORT_LOGIC_LTSSM_STATE_L0);
+}
+
+static int fsd_pcie_host_init(struct dw_pcie_rp *pp)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct exynos_pcie *ep = to_exynos_pcie(pci);
+
+ phy_init(ep->phy);
+ fsd_pcie_msi_init(ep);
+
+ return 0;
+}
+
+static const struct dw_pcie_host_ops fsd_pcie_host_ops = {
+ .init = fsd_pcie_host_init,
+};
+
+static int fsd_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
+ unsigned int type, u16 interrupt_num)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+
+ switch (type) {
+ case PCI_IRQ_INTX:
+ return dw_pcie_ep_raise_intx_irq(ep, func_no);
+ case PCI_IRQ_MSIX:
+ dev_err(pci->dev, "EP does not support MSIX\n");
+ return -EINVAL;
+ case PCI_IRQ_MSI:
+ return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
+ default:
+ dev_err(pci->dev, "UNKNOWN IRQ type\n");
+ }
+
+ return 0;
+}
+
+static const struct pci_epc_features fsd_pcie_epc_features = {
+ .linkup_notifier = false,
+ .msi_capable = true,
+ .msix_capable = false,
+};
+
+static const struct pci_epc_features *fsd_pcie_get_features(struct dw_pcie_ep *ep)
+{
+ return &fsd_pcie_epc_features;
+}
+
+static const struct dw_pcie_ep_ops fsd_ep_ops = {
+ .raise_irq = fsd_pcie_raise_irq,
+ .get_features = fsd_pcie_get_features,
+};
+
+static void fsd_set_device_mode(struct exynos_pcie *ep)
+{
+ if (ep->pdata->device_mode == DW_PCIE_RC_TYPE)
+ writel(FSD_DEVICE_TYPE_RC, ep->elbi_base + FSD_PCIE_DEVICE_TYPE);
+ else
+ writel(FSD_DEVICE_TYPE_EP, ep->elbi_base + FSD_PCIE_DEVICE_TYPE);
+}
+
+static const struct dw_pcie_ops fsd_dw_pcie_ops = {
+ .read_dbi = fsd_pcie_read_dbi,
+ .write_dbi = fsd_pcie_write_dbi,
+ .write_dbi2 = fsd_pcie_write_dbi2,
+ .start_link = fsd_pcie_start_link,
+ .stop_link = fsd_pcie_stop_link,
+ .link_up = fsd_pcie_link_up,
+};
+
static const struct samsung_res_ops exynos_res_ops_data = {
.init_regulator = exynos_init_regulator,
.pcie_irq_handler = exynos_pcie_irq_handler,
};
+static const struct samsung_res_ops fsd_res_ops_data = {
+ .pcie_irq_handler = fsd_pcie_irq_handler,
+ .set_device_mode = fsd_set_device_mode,
+};
+
static int exynos_pcie_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -353,6 +577,26 @@ static int exynos_pcie_probe(struct platform_device *pdev)
if (IS_ERR(ep->phy))
return PTR_ERR(ep->phy);
+ if (ep->pdata->soc_variant == FSD) {
+ ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(36));
+ if (ret)
+ return ret;
+
+ ep->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
+ "samsung,syscon-pcie");
+ if (IS_ERR(ep->sysreg)) {
+ dev_err(dev, "sysreg regmap lookup failed.\n");
+ return PTR_ERR(ep->sysreg);
+ }
+
+ ret = of_property_read_u32_index(dev->of_node, "samsung,syscon-pcie", 1,
+ &ep->sysreg_offset);
+ if (ret) {
+ dev_err(dev, "couldn't get the register offset for syscon!\n");
+ return ret;
+ }
+ }
+
/* External Local Bus interface (ELBI) registers */
ep->elbi_base = devm_platform_ioremap_resource_byname(pdev, "elbi");
if (IS_ERR(ep->elbi_base))
@@ -373,13 +617,43 @@ static int exynos_pcie_probe(struct platform_device *pdev)
return ret;
platform_set_drvdata(pdev, ep);
- ret = samsung_irq_init(ep, pdev);
- if (ret)
- goto fail_regulator;
- ep->pci.pp.ops = pdata->host_ops;
- ret = dw_pcie_host_init(&ep->pci.pp);
- if (ret < 0)
+
+ if (pdata->res_ops->set_device_mode)
+ pdata->res_ops->set_device_mode(ep);
+
+ switch (ep->pdata->device_mode) {
+ case DW_PCIE_RC_TYPE:
+ ret = samsung_irq_init(ep, pdev);
+ if (ret)
+ goto fail_regulator;
+
+ ep->pci.pp.ops = pdata->host_ops;
+
+ ret = dw_pcie_host_init(&ep->pci.pp);
+ if (ret < 0)
+ goto fail_phy_init;
+
+ break;
+ case DW_PCIE_EP_TYPE:
+ phy_init(ep->phy);
+
+ ep->pci.ep.ops = pdata->ep_ops;
+
+ ret = dw_pcie_ep_init(&ep->pci.ep);
+ if (ret < 0)
+ goto fail_phy_init;
+
+ ret = dw_pcie_ep_init_registers(&ep->pci.ep);
+ if (ret)
+ goto fail_phy_init;
+
+ pci_epc_init_notify(ep->pci.ep.epc);
+
+ break;
+ default:
+ dev_err(dev, "invalid device type\n");
goto fail_phy_init;
+ }
return 0;
@@ -395,8 +669,11 @@ static void exynos_pcie_remove(struct platform_device *pdev)
{
struct exynos_pcie *ep = platform_get_drvdata(pdev);
+ if (ep->pdata->device_mode == DW_PCIE_EP_TYPE)
+ return;
dw_pcie_host_deinit(&ep->pci.pp);
- exynos_pcie_assert_core_reset(ep);
+ if (ep->pdata->soc_variant == EXYNOS_5433)
+ exynos_pcie_assert_core_reset(ep);
phy_power_off(ep->phy);
phy_exit(ep->phy);
samsung_regulator_disable(ep);
@@ -405,8 +682,16 @@ static void exynos_pcie_remove(struct platform_device *pdev)
static int exynos_pcie_suspend_noirq(struct device *dev)
{
struct exynos_pcie *ep = dev_get_drvdata(dev);
+ struct dw_pcie *pci = &ep->pci;
- exynos_pcie_assert_core_reset(ep);
+ if (ep->pdata->device_mode == DW_PCIE_EP_TYPE)
+ return 0;
+
+ if (ep->pdata->dwc_ops->stop_link)
+ ep->pdata->dwc_ops->stop_link(pci);
+
+ if (ep->pdata->soc_variant == EXYNOS_5433)
+ exynos_pcie_assert_core_reset(ep);
phy_power_off(ep->phy);
phy_exit(ep->phy);
samsung_regulator_disable(ep);
@@ -421,6 +706,9 @@ static int exynos_pcie_resume_noirq(struct device *dev)
struct dw_pcie_rp *pp = &pci->pp;
int ret;
+ if (ep->pdata->device_mode == DW_PCIE_EP_TYPE)
+ return 0;
+
ret = samsung_regulator_enable(ep);
if (ret)
return ret;
@@ -437,11 +725,30 @@ static const struct dev_pm_ops exynos_pcie_pm_ops = {
exynos_pcie_resume_noirq)
};
+
+static const struct samsung_pcie_pdata fsd_hw3_pcie_rc_pdata = {
+ .dwc_ops = &fsd_dw_pcie_ops,
+ .host_ops = &fsd_pcie_host_ops,
+ .res_ops = &fsd_res_ops_data,
+ .soc_variant = FSD,
+ .device_mode = DW_PCIE_RC_TYPE,
+};
+
+static const struct samsung_pcie_pdata fsd_hw3_pcie_ep_pdata = {
+ .dwc_ops = &fsd_dw_pcie_ops,
+ .ep_ops = &fsd_ep_ops,
+ .res_ops = &fsd_res_ops_data,
+ .soc_variant = FSD,
+ .device_mode = DW_PCIE_EP_TYPE,
+};
+
static const struct samsung_pcie_pdata exynos_5433_pcie_rc_pdata = {
.dwc_ops = &exynos_dw_pcie_ops,
.pci_ops = &exynos_pci_ops,
.host_ops = &exynos_pcie_host_ops,
.res_ops = &exynos_res_ops_data,
+ .soc_variant = EXYNOS_5433,
+ .device_mode = DW_PCIE_RC_TYPE,
};
static const struct of_device_id exynos_pcie_of_match[] = {
@@ -449,6 +756,14 @@ static const struct of_device_id exynos_pcie_of_match[] = {
.compatible = "samsung,exynos5433-pcie",
.data = (void *) &exynos_5433_pcie_rc_pdata,
},
+ {
+ .compatible = "tesla,fsd-pcie",
+ .data = (void *) &fsd_hw3_pcie_rc_pdata,
+ },
+ {
+ .compatible = "tesla,fsd-pcie-ep",
+ .data = (void *) &fsd_hw3_pcie_ep_pdata,
+ },
{ },
};
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 10/10] arm64: dts: fsd: Add PCIe support for Tesla FSD SoC
[not found] ` <CGME20250625165332epcas5p4e138b7f7c8ebb938dc526c5dc29412bb@epcas5p4.samsung.com>
@ 2025-06-25 16:52 ` Shradha Todi
0 siblings, 0 replies; 30+ messages in thread
From: Shradha Todi @ 2025-06-25 16:52 UTC (permalink / raw)
To: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd
Cc: manivannan.sadhasivam, lpieralisi, kw, robh, bhelgaas, jingoohan1,
krzk+dt, conor+dt, alim.akhtar, vkoul, kishon, arnd, m.szyprowski,
jh80.chung, pankaj.dubey, Shradha Todi
Add the support for PCIe controller driver and phy driver for Tesla FSD.
It includes support for both RC and EP.
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: Shradha Todi <shradha.t@samsung.com>
---
arch/arm64/boot/dts/tesla/fsd-evb.dts | 36 +++++
arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi | 65 +++++++++
arch/arm64/boot/dts/tesla/fsd.dtsi | 147 +++++++++++++++++++++
3 files changed, 248 insertions(+)
diff --git a/arch/arm64/boot/dts/tesla/fsd-evb.dts b/arch/arm64/boot/dts/tesla/fsd-evb.dts
index 9ff22e1c8723..c8f2019e6abf 100644
--- a/arch/arm64/boot/dts/tesla/fsd-evb.dts
+++ b/arch/arm64/boot/dts/tesla/fsd-evb.dts
@@ -19,6 +19,8 @@ / {
aliases {
serial0 = &serial_0;
serial1 = &serial_1;
+ pciephy0 = &pciephy0;
+ pciephy1 = &pciephy1;
};
chosen {
@@ -130,3 +132,37 @@ &serial_0 {
&ufs {
status = "okay";
};
+
+&pcierc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_clkreq>, <&pcie1_wake>, <&pcie1_preset>,
+ <&pcie0_slot1>;
+};
+
+&pcieep2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_clkreq>, <&pcie1_wake>, <&pcie1_preset>,
+ <&pcie0_slot1>;
+};
+
+&pcierc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_clkreq>, <&pcie0_wake0>, <&pcie0_preset0>,
+ <&pcie0_slot0>;
+};
+
+&pcieep0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_clkreq>, <&pcie0_wake0>, <&pcie0_preset0>,
+ <&pcie0_slot0>;
+};
+
+&pcierc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_clkreq>, <&pcie0_wake1>, <&pcie0_preset0>;
+};
+
+&pcieep1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_clkreq>, <&pcie0_wake1>, <&pcie0_preset0>;
+};
diff --git a/arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi b/arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi
index 6f4658f57453..fa99aa4b9906 100644
--- a/arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi
@@ -120,6 +120,27 @@ eth0_mdio: eth0-mdio-pins {
samsung,pin-pud = <FSD_PIN_PULL_NONE>;
samsung,pin-drv = <FSD_PIN_DRV_LV4>;
};
+
+ pcie1_clkreq: pcie1-clkreq-pins {
+ samsung,pins = "gpf6-0";
+ samsung,pin-function = <FSD_PIN_FUNC_2>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ };
+
+ pcie1_wake: pcie1-wake-pins {
+ samsung,pins = "gpf6-1";
+ samsung,pin-function = <FSD_PIN_FUNC_2>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ };
+
+ pcie1_preset: pcie1-preset-pins {
+ samsung,pins = "gpf6-2";
+ samsung,pin-function = <FSD_PIN_FUNC_2>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ };
};
&pinctrl_peric {
@@ -493,6 +514,50 @@ eth1_mdio: eth1-mdio-pins {
samsung,pin-pud = <FSD_PIN_PULL_UP>;
samsung,pin-drv = <FSD_PIN_DRV_LV4>;
};
+
+ pcie0_clkreq: pcie0-clkreq-pins {
+ samsung,pins = "gpc8-0";
+ samsung,pin-function = <FSD_PIN_FUNC_2>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ };
+
+ pcie0_wake0: pcie0-wake0-pins {
+ samsung,pins = "gpc8-1";
+ samsung,pin-function = <FSD_PIN_FUNC_2>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ };
+
+ pcie0_preset0: pcie0-preset0-pins {
+ samsung,pins = "gpc8-2";
+ samsung,pin-function = <FSD_PIN_FUNC_2>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ };
+
+ pcie0_wake1: pcie0-wake1-pins {
+ samsung,pins = "gpc8-3";
+ samsung,pin-function = <FSD_PIN_FUNC_2>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ };
+
+ pcie0_slot0: pcie0-gpio22-pins {
+ samsung,pins = "gpg2-6";
+ samsung,pin-function = <FSD_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ samsung,pin-val = <1>;
+ };
+
+ pcie0_slot1: pcie0-gpio23-pins {
+ samsung,pins = "gpg2-7";
+ samsung,pin-function = <FSD_PIN_FUNC_OUTPUT>;
+ samsung,pin-pud = <FSD_PIN_PULL_UP>;
+ samsung,pin-drv = <FSD_PIN_DRV_LV4>;
+ samsung,pin-val = <1>;
+ };
};
&pinctrl_pmu {
diff --git a/arch/arm64/boot/dts/tesla/fsd.dtsi b/arch/arm64/boot/dts/tesla/fsd.dtsi
index a5ebb3f9b18f..9e2d095546fa 100644
--- a/arch/arm64/boot/dts/tesla/fsd.dtsi
+++ b/arch/arm64/boot/dts/tesla/fsd.dtsi
@@ -1009,6 +1009,16 @@ ethernet1: ethernet@14300000 {
status = "disabled";
};
+ pciephy0: pcie-phy@15080000 {
+ compatible = "tesla,fsd-pcie-phy";
+ #phy-cells = <0>;
+ reg = <0x0 0x15080000 0x0 0x2000>,
+ <0x0 0x150a0000 0x0 0x1000>;
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ samsung,fsys-sysreg = <&sysreg_fsys0>;
+ status = "disabled";
+ };
+
ufs: ufs@15120000 {
compatible = "tesla,fsd-ufs";
reg = <0x0 0x15120000 0x0 0x200>, /* 0: HCI standard */
@@ -1057,6 +1067,143 @@ ethernet0: ethernet@15300000 {
iommus = <&smmu_fsys0 0x0 0x1>;
status = "disabled";
};
+
+ pcierc2: pcie@15400000 {
+ compatible = "tesla,fsd-pcie";
+ reg = <0x0 0x15400000 0x0 0x2000>,
+ <0x0 0x15090000 0x0 0x1000>,
+ <0x0 0x15800000 0x0 0x1000>;
+ reg-names = "dbi", "elbi", "config";
+ ranges = <0x82000000 0 0x15801000 0 0x15801000 0 0xffefff>;
+ clocks = <&clock_fsys0 PCIE_SUBCTRL_INST0_AUX_CLK_SOC>,
+ <&clock_fsys0 PCIE_SUBCTRL_INST0_DBI_ACLK_SOC>,
+ <&clock_fsys0 PCIE_SUBCTRL_INST0_MSTR_ACLK_SOC>,
+ <&clock_fsys0 PCIE_SUBCTRL_INST0_SLV_ACLK_SOC>;
+ clock-names = "aux", "dbi", "mstr", "slv";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ dma-coherent;
+ device_type = "pci";
+ interrupts = <GIC_SPI 93 IRQ_TYPE_EDGE_RISING>;
+ num-lanes = <4>;
+ samsung,syscon-pcie = <&sysreg_fsys0 0x434>;
+ phys = <&pciephy0>;
+ iommu-map = <0x0 &smmu_fsys0 0x4 0x10000>;
+ iommu-map-mask = <0x0>;
+ status = "disabled";
+ };
+
+ pcieep2: pcie-ep@15400000 {
+ compatible = "tesla,fsd-pcie-ep";
+ reg = <0x0 0x15090000 0x0 0x1000>,
+ <0x0 0x15400000 0x0 0x2000>,
+ <0x0 0x15402000 0x0 0x80>,
+ <0x0 0x15800000 0x0 0xff0000>;
+ reg-names = "elbi", "dbi", "dbi2", "addr_space";
+ clocks = <&clock_fsys0 PCIE_SUBCTRL_INST0_AUX_CLK_SOC>,
+ <&clock_fsys0 PCIE_SUBCTRL_INST0_DBI_ACLK_SOC>,
+ <&clock_fsys0 PCIE_SUBCTRL_INST0_MSTR_ACLK_SOC>,
+ <&clock_fsys0 PCIE_SUBCTRL_INST0_SLV_ACLK_SOC>;
+ clock-names = "aux", "dbi", "mstr", "slv";
+ num-lanes = <4>;
+ samsung,syscon-pcie = <&sysreg_fsys0 0x434>;
+ phys = <&pciephy0>;
+ status = "disabled";
+ };
+
+ pciephy1: pcie-phy@16880000 {
+ compatible = "tesla,fsd-pcie-phy";
+ #phy-cells = <0>;
+ reg = <0x0 0x16880000 0x0 0x2000>,
+ <0x0 0x16860000 0x0 0x1000>;
+ samsung,pmu-syscon = <&pmu_system_controller>;
+ samsung,fsys-sysreg = <&sysreg_fsys1>;
+ status = "disabled";
+ };
+
+ pcierc0: pcie@16a00000 {
+ compatible = "tesla,fsd-pcie";
+ reg = <0x0 0x16a00000 0x0 0x2000>,
+ <0x0 0x168b0000 0x0 0x1000>,
+ <0x0 0x17000000 0x0 0x1000>;
+ reg-names = "dbi", "elbi", "config";
+ ranges = <0x82000000 0 0x17001000 0 0x17001000 0 0xffefff>;
+ clocks = <&clock_fsys1 PCIE_LINK0_IPCLKPORT_AUX_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_DBI_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_MSTR_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_SLV_ACLK>;
+ clock-names = "aux", "dbi", "mstr", "slv";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ dma-coherent;
+ device_type = "pci";
+ interrupts = <GIC_SPI 115 IRQ_TYPE_EDGE_RISING>;
+ num-lanes = <4>;
+ samsung,syscon-pcie = <&sysreg_fsys1 0x50c>;
+ phys = <&pciephy1>;
+ iommu-map = <0x0 &smmu_imem 0x0 0x10000>;
+ iommu-map-mask = <0x0>;
+ status = "disabled";
+ };
+
+ pcieep0: pcie-ep@16a00000 {
+ compatible = "tesla,fsd-pcie-ep";
+ reg = <0x0 0x168b0000 0x0 0x1000>,
+ <0x0 0x16a00000 0x0 0x2000>,
+ <0x0 0x16a02000 0x0 0x80>,
+ <0x0 0x17000000 0x0 0xff0000>;
+ reg-names = "elbi", "dbi", "dbi2", "addr_space";
+ clocks = <&clock_fsys1 PCIE_LINK0_IPCLKPORT_AUX_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_DBI_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_MSTR_ACLK>,
+ <&clock_fsys1 PCIE_LINK0_IPCLKPORT_SLV_ACLK>;
+ clock-names = "aux", "dbi", "mstr", "slv";
+ num-lanes = <4>;
+ samsung,syscon-pcie = <&sysreg_fsys1 0x50c>;
+ phys = <&pciephy1>;
+ status = "disabled";
+ };
+
+ pcierc1: pcie@16b00000 {
+ compatible = "tesla,fsd-pcie";
+ reg = <0x0 0x16b00000 0x0 0x2000>,
+ <0x0 0x168c0000 0x0 0x1000>,
+ <0x0 0x18000000 0x0 0x1000>;
+ reg-names = "dbi", "elbi", "config";
+ ranges = <0x82000000 0 0x18001000 0 0x18001000 0 0xffefff>;
+ clocks = <&clock_fsys1 PCIE_LINK1_IPCLKPORT_AUX_ACLK>,
+ <&clock_fsys1 PCIE_LINK1_IPCLKPORT_DBI_ACLK>,
+ <&clock_fsys1 PCIE_LINK1_IPCLKPORT_MSTR_ACLK>,
+ <&clock_fsys1 PCIE_LINK1_IPCLKPORT_SLV_ACLK>;
+ clock-names = "aux", "dbi", "mstr", "slv";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ dma-coherent;
+ device_type = "pci";
+ interrupts = <GIC_SPI 117 IRQ_TYPE_EDGE_RISING>;
+ num-lanes = <4>;
+ samsung,syscon-pcie = <&sysreg_fsys1 0x510>;
+ phys = <&pciephy1>;
+ status = "disabled";
+ };
+
+ pcieep1: pcie-ep@16b00000 {
+ compatible = "tesla,fsd-pcie-ep";
+ reg = <0x0 0x168c0000 0x0 0x1000>,
+ <0x0 0x16b00000 0x0 0x2000>,
+ <0x0 0x16b02000 0x0 0x80>,
+ <0x0 0x18000000 0x0 0xff0000>;
+ reg-names = "elbi", "dbi", "dbi2", "addr_space";
+ clocks = <&clock_fsys1 PCIE_LINK1_IPCLKPORT_AUX_ACLK>,
+ <&clock_fsys1 PCIE_LINK1_IPCLKPORT_DBI_ACLK>,
+ <&clock_fsys1 PCIE_LINK1_IPCLKPORT_MSTR_ACLK>,
+ <&clock_fsys1 PCIE_LINK1_IPCLKPORT_SLV_ACLK>;
+ clock-names = "aux", "dbi", "mstr", "slv";
+ num-lanes = <4>;
+ samsung,syscon-pcie = <&sysreg_fsys1 0x510>;
+ phys = <&pciephy1>;
+ status = "disabled";
+ };
};
};
--
2.49.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v2 08/10] phy: exynos: Add PCIe PHY support for FSD SoC
2025-06-25 16:52 ` [PATCH v2 08/10] phy: exynos: Add PCIe PHY " Shradha Todi
@ 2025-06-26 23:09 ` Vinod Koul
0 siblings, 0 replies; 30+ messages in thread
From: Vinod Koul @ 2025-06-26 23:09 UTC (permalink / raw)
To: Shradha Todi
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, manivannan.sadhasivam,
lpieralisi, kw, robh, bhelgaas, jingoohan1, krzk+dt, conor+dt,
alim.akhtar, kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
On 25-06-25, 22:22, Shradha Todi wrote:
> Add PCIe PHY support for Tesla FSD SoC.
>
> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> ---
> drivers/phy/samsung/phy-exynos-pcie.c | 317 +++++++++++++++++++++++++-
> 1 file changed, 316 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/phy/samsung/phy-exynos-pcie.c b/drivers/phy/samsung/phy-exynos-pcie.c
> index 53c9230c2907..001a49bde2f4 100644
> --- a/drivers/phy/samsung/phy-exynos-pcie.c
> +++ b/drivers/phy/samsung/phy-exynos-pcie.c
> @@ -34,11 +34,113 @@
> /* PMU PCIE PHY isolation control */
> #define EXYNOS5433_PMU_PCIE_PHY_OFFSET 0x730
>
> +/* FSD: PCIe PHY common registers */
> +#define FSD_PCIE_PHY_TRSV_CMN_REG03 0x000c
> +#define FSD_PCIE_PHY_TRSV_CMN_REG01E 0x0078
> +#define FSD_PCIE_PHY_TRSV_CMN_REG02D 0x00b4
> +#define FSD_PCIE_PHY_TRSV_CMN_REG031 0x00c4
> +#define FSD_PCIE_PHY_TRSV_CMN_REG036 0x00d8
> +#define FSD_PCIE_PHY_TRSV_CMN_REG05F 0x017c
> +#define FSD_PCIE_PHY_TRSV_CMN_REG060 0x0180
> +#define FSD_PCIE_PHY_TRSV_CMN_REG062 0x0188
> +#define FSD_PCIE_PHY_TRSV_CMN_REG061 0x0184
> +#define FSD_PCIE_PHY_AGG_BIF_RESET 0x0200
> +#define FSD_PCIE_PHY_AGG_BIF_CLOCK 0x0208
> +#define FSD_PCIE_PHY_CMN_RESET 0x0228
> +
> +/* FSD: PCIe PHY lane registers */
> +#define FSD_PCIE_LANE_OFFSET 0x0400
> +#define FSD_PCIE_NUM_LANES 0x4
> +
> +#define FSD_PCIE_PHY_TRSV_REG001_LN_N 0x0404
> +#define FSD_PCIE_PHY_TRSV_REG002_LN_N 0x0408
> +#define FSD_PCIE_PHY_TRSV_REG005_LN_N 0x0414
> +#define FSD_PCIE_PHY_TRSV_REG006_LN_N 0x0418
> +#define FSD_PCIE_PHY_TRSV_REG007_LN_N 0x041c
> +#define FSD_PCIE_PHY_TRSV_REG009_LN_N 0x0424
> +#define FSD_PCIE_PHY_TRSV_REG00A_LN_N 0x0428
> +#define FSD_PCIE_PHY_TRSV_REG00C_LN_N 0x0430
> +#define FSD_PCIE_PHY_TRSV_REG012_LN_N 0x0448
> +#define FSD_PCIE_PHY_TRSV_REG013_LN_N 0x044c
> +#define FSD_PCIE_PHY_TRSV_REG014_LN_N 0x0450
> +#define FSD_PCIE_PHY_TRSV_REG015_LN_N 0x0454
> +#define FSD_PCIE_PHY_TRSV_REG016_LN_N 0x0458
> +#define FSD_PCIE_PHY_TRSV_REG018_LN_N 0x0460
> +#define FSD_PCIE_PHY_TRSV_REG020_LN_N 0x0480
> +#define FSD_PCIE_PHY_TRSV_REG026_LN_N 0x0498
> +#define FSD_PCIE_PHY_TRSV_REG029_LN_N 0x04a4
> +#define FSD_PCIE_PHY_TRSV_REG031_LN_N 0x04c4
> +#define FSD_PCIE_PHY_TRSV_REG036_LN_N 0x04d8
> +#define FSD_PCIE_PHY_TRSV_REG039_LN_N 0x04e4
> +#define FSD_PCIE_PHY_TRSV_REG03B_LN_N 0x04ec
> +#define FSD_PCIE_PHY_TRSV_REG03C_LN_N 0x04f0
> +#define FSD_PCIE_PHY_TRSV_REG03E_LN_N 0x04f8
> +#define FSD_PCIE_PHY_TRSV_REG03F_LN_N 0x04fc
> +#define FSD_PCIE_PHY_TRSV_REG043_LN_N 0x050c
> +#define FSD_PCIE_PHY_TRSV_REG044_LN_N 0x0510
> +#define FSD_PCIE_PHY_TRSV_REG046_LN_N 0x0518
> +#define FSD_PCIE_PHY_TRSV_REG048_LN_N 0x0520
> +#define FSD_PCIE_PHY_TRSV_REG049_LN_N 0x0524
> +#define FSD_PCIE_PHY_TRSV_REG04E_LN_N 0x0538
> +#define FSD_PCIE_PHY_TRSV_REG052_LN_N 0x0548
> +#define FSD_PCIE_PHY_TRSV_REG068_LN_N 0x05a0
> +#define FSD_PCIE_PHY_TRSV_REG069_LN_N 0x05a4
> +#define FSD_PCIE_PHY_TRSV_REG06A_LN_N 0x05a8
> +#define FSD_PCIE_PHY_TRSV_REG06B_LN_N 0x05ac
> +#define FSD_PCIE_PHY_TRSV_REG07B_LN_N 0x05ec
> +#define FSD_PCIE_PHY_TRSV_REG083_LN_N 0x060c
> +#define FSD_PCIE_PHY_TRSV_REG084_LN_N 0x0610
> +#define FSD_PCIE_PHY_TRSV_REG086_LN_N 0x0618
> +#define FSD_PCIE_PHY_TRSV_REG087_LN_N 0x061c
> +#define FSD_PCIE_PHY_TRSV_REG08B_LN_N 0x062c
> +#define FSD_PCIE_PHY_TRSV_REG09C_LN_N 0x0670
> +#define FSD_PCIE_PHY_TRSV_REG09D_LN_N 0x0674
> +#define FSD_PCIE_PHY_TRSV_REG09E_LN_N 0x0678
> +#define FSD_PCIE_PHY_TRSV_REG09F_LN_N 0x067c
> +#define FSD_PCIE_PHY_TRSV_REG0A2_LN_N 0x0688
> +#define FSD_PCIE_PHY_TRSV_REG0A4_LN_N 0x0690
> +#define FSD_PCIE_PHY_TRSV_REG0CE_LN_N 0x0738
> +#define FSD_PCIE_PHY_TRSV_REG0FC_LN_N 0x07f0
> +#define FSD_PCIE_PHY_TRSV_REG0FD_LN_N 0x07f4
> +#define FSD_PCIE_PHY_TRSV_REG0FE_LN_N 0x07f8
> +#define FSD_PCIE_PHY_TRSV_REG0CE_LN_1 0x0b38
> +#define FSD_PCIE_PHY_TRSV_REG0CE_LN_2 0x0f38
> +#define FSD_PCIE_PHY_TRSV_REG0CE_LN_3 0x1338
> +
> +/* FSD: PCIe PCS registers */
> +#define FSD_PCIE_PCS_BRF_0 0x0004
> +#define FSD_PCIE_PCS_BRF_1 0x0804
> +#define FSD_PCIE_PCS_CLK 0x0180
> +
> +/* FSD: PCIe SYSREG registers */
> +#define FSD_PCIE_SYSREG_PHY_0_CON 0x042c
> +#define FSD_PCIE_SYSREG_PHY_0_CON_MASK 0x03ff
> +#define FSD_PCIE_SYSREG_PHY_0_REF_SEL (0x2 << 0)
Please use GENMASK for this
> +#define FSD_PCIE_SYSREG_PHY_0_REF_SEL_MASK 0x3
> +#define FSD_PCIE_SYSREG_PHY_0_AUX_EN BIT(4)
> +#define FSD_PCIE_SYSREG_PHY_0_CMN_RSTN BIT(8)
> +#define FSD_PCIE_SYSREG_PHY_0_INIT_RSTN BIT(9)
> +
> +#define FSD_PCIE_SYSREG_PHY_1_CON 0x0500
> +#define FSD_PCIE_SYSREG_PHY_1_CON_MASK 0x01ff
> +#define FSD_PCIE_SYSREG_PHY_1_REF_SEL (0x2 << 4)
> +#define FSD_PCIE_SYSREG_PHY_1_REF_SEL_MASK 0x30
> +#define FSD_PCIE_SYSREG_PHY_1_AUX_EN BIT(0)
> +#define FSD_PCIE_SYSREG_PHY_1_CMN_RSTN BIT(1)
> +#define FSD_PCIE_SYSREG_PHY_1_INIT_RSTN BIT(3)
> +
> /* For Exynos pcie phy */
> struct exynos_pcie_phy {
> void __iomem *base;
> + void __iomem *pcs_base;
> struct regmap *pmureg;
> struct regmap *fsysreg;
> + int phy_id;
> + const struct samsung_drv_data *drv_data;
> +};
> +
> +struct samsung_drv_data {
> + const struct phy_ops *phy_ops;
> };
>
> static void exynos_pcie_phy_writel(void __iomem *base, u32 val, u32 offset)
> @@ -133,9 +235,212 @@ static const struct phy_ops exynos5433_phy_ops = {
> .owner = THIS_MODULE,
> };
>
> +static void fsd_pcie_phy_writel(struct exynos_pcie_phy *phy_ctrl, u32 offset, u32 val)
> +{
> + void __iomem *phy_base = phy_ctrl->base;
> + u32 i;
> +
> + for (i = 0; i < FSD_PCIE_NUM_LANES; i++)
> + writel(val, phy_base + (offset + i * FSD_PCIE_LANE_OFFSET));
> +}
> +
> +struct fsd_pcie_phy_pdata {
> + u32 phy_con_offset;
> + u32 phy_con_mask;
> + u32 phy_ref_sel;
> + u32 phy_ref_sel_mask;
> + u32 phy_aux_en;
> + u32 phy_cmn_rstn;
> + u32 phy_init_rstn;
> +};
> +
> +static const struct fsd_pcie_phy_pdata fsd_phy_con[] = {
> +{
> + .phy_con_offset = FSD_PCIE_SYSREG_PHY_0_CON,
> + .phy_con_mask = FSD_PCIE_SYSREG_PHY_0_CON_MASK,
> + .phy_ref_sel = FSD_PCIE_SYSREG_PHY_0_REF_SEL,
> + .phy_ref_sel_mask = FSD_PCIE_SYSREG_PHY_0_REF_SEL_MASK,
> + .phy_aux_en = FSD_PCIE_SYSREG_PHY_0_AUX_EN,
> + .phy_cmn_rstn = FSD_PCIE_SYSREG_PHY_0_CMN_RSTN,
> + .phy_init_rstn = FSD_PCIE_SYSREG_PHY_0_INIT_RSTN,
> + },
> + {
> + .phy_con_offset = FSD_PCIE_SYSREG_PHY_1_CON,
> + .phy_con_mask = FSD_PCIE_SYSREG_PHY_1_CON_MASK,
> + .phy_ref_sel = FSD_PCIE_SYSREG_PHY_1_REF_SEL,
> + .phy_ref_sel_mask = FSD_PCIE_SYSREG_PHY_1_REF_SEL_MASK,
> + .phy_aux_en = FSD_PCIE_SYSREG_PHY_1_AUX_EN,
> + .phy_cmn_rstn = FSD_PCIE_SYSREG_PHY_1_CMN_RSTN,
> + .phy_init_rstn = FSD_PCIE_SYSREG_PHY_1_INIT_RSTN,
> + },
> + { },
> +};
> +
> +static int fsd_pcie_phy_reset(struct phy *phy)
> +{
> + struct exynos_pcie_phy *phy_ctrl = phy_get_drvdata(phy);
> + const struct fsd_pcie_phy_pdata *pdata = &fsd_phy_con[phy_ctrl->phy_id];
> +
> + writel(0x1, phy_ctrl->pcs_base + FSD_PCIE_PCS_CLK);
> +
> + regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
> + pdata->phy_con_mask, 0x0);
> + regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
> + pdata->phy_aux_en, pdata->phy_aux_en);
> + regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
> + pdata->phy_ref_sel_mask, pdata->phy_ref_sel);
> + /* perform init reset release */
> + regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
> + pdata->phy_init_rstn, pdata->phy_init_rstn);
> +
> + return 0;
> +}
> +
> +static void fsd_pcie_phy1_init(struct exynos_pcie_phy *phy_ctrl)
> +{
> + void __iomem *pbase = phy_ctrl->base;
> +
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG07B_LN_N, 0x20);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG052_LN_N, 0x00);
> + writel(0xaa, pbase + FSD_PCIE_PHY_TRSV_CMN_REG01E);
> + writel(0x28, pbase + FSD_PCIE_PHY_TRSV_CMN_REG02D);
> + writel(0x28, pbase + FSD_PCIE_PHY_TRSV_CMN_REG031);
> + writel(0x21, pbase + FSD_PCIE_PHY_TRSV_CMN_REG036);
> + writel(0x12, pbase + FSD_PCIE_PHY_TRSV_CMN_REG05F);
> + writel(0x23, pbase + FSD_PCIE_PHY_TRSV_CMN_REG060);
> + writel(0x0, pbase + FSD_PCIE_PHY_TRSV_CMN_REG061);
> + writel(0x0, pbase + FSD_PCIE_PHY_TRSV_CMN_REG062);
> + writel(0x15, pbase + FSD_PCIE_PHY_TRSV_CMN_REG03);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG039_LN_N, 0xf);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03B_LN_N, 0x13);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03C_LN_N, 0x66);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG044_LN_N, 0x57);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03E_LN_N, 0x10);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03F_LN_N, 0x44);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG043_LN_N, 0x11);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG046_LN_N, 0xef);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG048_LN_N, 0x06);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG049_LN_N, 0xaf);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG04E_LN_N, 0x28);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG068_LN_N, 0x1f);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG069_LN_N, 0xc);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG06A_LN_N, 0x8);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG06B_LN_N, 0x78);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG083_LN_N, 0xa);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG084_LN_N, 0x80);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG087_LN_N, 0x30);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG08B_LN_N, 0xa0);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09C_LN_N, 0xf7);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09E_LN_N, 0x33);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0A2_LN_N, 0xfa);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0A4_LN_N, 0xf2);
> + writel(0x8, pbase + FSD_PCIE_PHY_TRSV_REG0CE_LN_N);
> + writel(0x9, pbase + FSD_PCIE_PHY_TRSV_REG0CE_LN_1);
> + writel(0x9, pbase + FSD_PCIE_PHY_TRSV_REG0CE_LN_2);
> + writel(0x9, pbase + FSD_PCIE_PHY_TRSV_REG0CE_LN_3);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0FE_LN_N, 0x33);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG001_LN_N, 0x3f);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG005_LN_N, 0x2b);
> +}
> +
> +static void fsd_pcie_phy0_init(struct exynos_pcie_phy *phy_ctrl)
> +{
> + void __iomem *pbase = phy_ctrl->base;
> +
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG07B_LN_N, 0x20);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG052_LN_N, 0x00);
> + writel(0x11, pbase + FSD_PCIE_PHY_TRSV_CMN_REG05F);
> + writel(0x23, pbase + FSD_PCIE_PHY_TRSV_CMN_REG060);
> + writel(0x0, pbase + FSD_PCIE_PHY_TRSV_CMN_REG062);
> + writel(0x15, pbase + FSD_PCIE_PHY_TRSV_CMN_REG03);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0CE_LN_N, 0x8);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG039_LN_N, 0xf);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03B_LN_N, 0x13);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03C_LN_N, 0xf6);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG044_LN_N, 0x57);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03E_LN_N, 0x10);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG03F_LN_N, 0x04);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG043_LN_N, 0x11);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG049_LN_N, 0x6f);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG04E_LN_N, 0x18);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG068_LN_N, 0x1f);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG069_LN_N, 0xc);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG06B_LN_N, 0x78);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG083_LN_N, 0xa);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG084_LN_N, 0x80);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG086_LN_N, 0xff);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG087_LN_N, 0x3c);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09D_LN_N, 0x7c);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09E_LN_N, 0x33);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG09F_LN_N, 0x33);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG001_LN_N, 0x3f);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG002_LN_N, 0x1c);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG005_LN_N, 0x2b);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG006_LN_N, 0x3);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG007_LN_N, 0x0c);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG009_LN_N, 0x10);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG00A_LN_N, 0x1);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG00C_LN_N, 0x93);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG012_LN_N, 0x1);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG013_LN_N, 0x0);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG014_LN_N, 0x70);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG015_LN_N, 0x0);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG016_LN_N, 0x70);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0FC_LN_N, 0x80);
> + fsd_pcie_phy_writel(phy_ctrl, FSD_PCIE_PHY_TRSV_REG0FD_LN_N, 0x0);
> +}
> +
> +static int fsd_pcie_phy_init(struct phy *phy)
> +{
> + struct exynos_pcie_phy *phy_ctrl = phy_get_drvdata(phy);
> + void __iomem *phy_base = phy_ctrl->base;
> + const struct fsd_pcie_phy_pdata *pdata = &fsd_phy_con[phy_ctrl->phy_id];
> +
> + fsd_pcie_phy_reset(phy);
> +
> + if (phy_ctrl->phy_id == 1)
> + writel(0x2, phy_base + FSD_PCIE_PHY_CMN_RESET);
> +
> + writel(0x00, phy_ctrl->pcs_base + FSD_PCIE_PCS_BRF_0);
> + writel(0x00, phy_ctrl->pcs_base + FSD_PCIE_PCS_BRF_1);
> + writel(0x00, phy_base + FSD_PCIE_PHY_AGG_BIF_RESET);
> + writel(0x00, phy_base + FSD_PCIE_PHY_AGG_BIF_CLOCK);
> +
> + if (phy_ctrl->phy_id == 1) {
> + fsd_pcie_phy1_init(phy_ctrl);
> + writel(0x3, phy_base + FSD_PCIE_PHY_CMN_RESET);
> + } else {
> + fsd_pcie_phy0_init(phy_ctrl);
> + }
> +
> + regmap_update_bits(phy_ctrl->fsysreg, pdata->phy_con_offset,
> + pdata->phy_cmn_rstn, pdata->phy_cmn_rstn);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops fsd_phy_ops = {
> + .init = fsd_pcie_phy_init,
> + .reset = fsd_pcie_phy_reset,
> + .owner = THIS_MODULE,
> +};
> +
> +static const struct samsung_drv_data exynos5433_drv_data = {
> + .phy_ops = &exynos5433_phy_ops,
> +};
> +
> +static const struct samsung_drv_data fsd_drv_data = {
> + .phy_ops = &fsd_phy_ops,
> +};
> +
> static const struct of_device_id exynos_pcie_phy_match[] = {
> {
> .compatible = "samsung,exynos5433-pcie-phy",
> + .data = &exynos5433_drv_data,
> + },
> + {
> + .compatible = "tesla,fsd-pcie-phy",
> + .data = &fsd_drv_data,
> },
> {},
> };
Can you split this to two patches, one for the move and second for
adding fsd one...
Also, no need to post everything togther, phy can be sent as a
standalone one
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
2025-06-25 16:52 ` [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC Shradha Todi
@ 2025-06-27 16:29 ` Bjorn Helgaas
2025-07-01 11:33 ` Shradha Todi
2025-06-27 21:12 ` Rob Herring
1 sibling, 1 reply; 30+ messages in thread
From: Bjorn Helgaas @ 2025-06-27 16:29 UTC (permalink / raw)
To: Shradha Todi
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, manivannan.sadhasivam,
lpieralisi, kw, robh, bhelgaas, jingoohan1, krzk+dt, conor+dt,
alim.akhtar, vkoul, kishon, arnd, m.szyprowski, jh80.chung,
pankaj.dubey
On Wed, Jun 25, 2025 at 10:22:25PM +0530, Shradha Todi wrote:
> Document the PCIe controller device tree bindings for Tesla FSD
> SoC for both RC and EP.
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
> - clocks:
> - items:
> - - description: PCIe bridge clock
> - - description: PCIe bus clock
> - vdd10-supply:
> - description:
> - Phandle to a regulator that provides 1.0V power to the PCIe block.
> -
> - vdd18-supply:
> - description:
> - Phandle to a regulator that provides 1.8V power to the PCIe block.
> + - description: pcie bridge clock
> + - description: pcie bus clock
Gratuitous "PCIe" capitalization changes here and in supplies below.
This is just plain English text so we can use English conventions.
> + vdd10-supply:
> + description:
> + phandle to a regulator that provides 1.0v power to the pcie block.
> +
> + vdd18-supply:
> + description:
> + phandle to a regulator that provides 1.8v power to the pcie block.
I *would* be OK if you dropped the periods at the end of these, which
would make them match the other descriptions in this binding.
> +++ b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
I'm not sure about the "tesla,fsd-pcie-ep.yaml" filename. I see that
it currently only describes a tesla endpoint, but it seems like maybe
this should be parallel to the "samsung,exynos-pcie.yaml" host
controller binding.
Bjorn
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/10] PCI: exynos: Add support for Tesla FSD SoC
2025-06-25 16:52 ` [PATCH v2 09/10] PCI: exynos: Add support for Tesla " Shradha Todi
@ 2025-06-27 19:30 ` Bjorn Helgaas
2025-07-01 11:18 ` Shradha Todi
2025-06-30 16:26 ` Dan Carpenter
1 sibling, 1 reply; 30+ messages in thread
From: Bjorn Helgaas @ 2025-06-27 19:30 UTC (permalink / raw)
To: Shradha Todi
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, manivannan.sadhasivam,
lpieralisi, kw, robh, bhelgaas, jingoohan1, krzk+dt, conor+dt,
alim.akhtar, vkoul, kishon, arnd, m.szyprowski, jh80.chung,
pankaj.dubey
On Wed, Jun 25, 2025 at 10:22:28PM +0530, Shradha Todi wrote:
> Add host and endpoint controller driver support for FSD SoC.
> +++ b/drivers/pci/controller/dwc/pci-exynos.c
> @@ -20,6 +20,8 @@
> #include <linux/regulator/consumer.h>
> #include <linux/mod_devicetable.h>
> #include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
The trend is to sort these alphabetically. The last couple additions
didn't observe this, but maybe these new ones could go a little
farther up and make it more sorted rather than less?
> +#define FSD_PCIE_CXPL_DEBUG_00_31 0x2C8
Existing #defines use lower-case hex; please follow suit.
> +/* to store different SoC variants of Samsung */
> +enum samsung_pcie_variants {
> + FSD,
> + EXYNOS_5433,
> +};
> struct samsung_pcie_pdata {
> struct pci_ops *pci_ops;
> const struct dw_pcie_ops *dwc_ops;
> const struct dw_pcie_host_ops *host_ops;
> + const struct dw_pcie_ep_ops *ep_ops;
> const struct samsung_res_ops *res_ops;
> + unsigned int soc_variant;
> + enum dw_pcie_device_mode device_mode;
> };
> +static u32 fsd_pcie_read_dbi(struct dw_pcie *pci, void __iomem *base,
> + u32 reg, size_t size)
> +{
> + void __iomem *addr;
> + u32 val;
> +
> + addr = fsd_atu_setting(pci, base);
> +
> + dw_pcie_read(addr + reg, size, &val);
> +
> + return val;
Remove blank lines to match style of fsd_pcie_write_dbi2().
> +}
> +
> +static void fsd_pcie_write_dbi(struct dw_pcie *pci, void __iomem *base,
> + u32 reg, size_t size, u32 val)
> +{
> + void __iomem *addr;
> +
> + addr = fsd_atu_setting(pci, base);
> +
> + dw_pcie_write(addr + reg, size, val);
Ditto.
> +}
> +
> +static void fsd_pcie_write_dbi2(struct dw_pcie *pci, void __iomem *base,
> + u32 reg, size_t size, u32 val)
> +{
> + struct exynos_pcie *ep = to_exynos_pcie(pci);
> +
> + fsd_atu_setting(pci, base);
> + dw_pcie_write(pci->dbi_base + reg, size, val);
> + regmap_write(ep->sysreg, ep->sysreg_offset, ADDR_TYPE_DBI);
> +}
> +static int fsd_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> + unsigned int type, u16 interrupt_num)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> +
> + switch (type) {
> + case PCI_IRQ_INTX:
> + return dw_pcie_ep_raise_intx_irq(ep, func_no);
> + case PCI_IRQ_MSIX:
> + dev_err(pci->dev, "EP does not support MSIX\n");
s/MSIX/MSI-X/ to match spec usage.
> @@ -373,13 +617,43 @@ static int exynos_pcie_probe(struct platform_device *pdev)
> return ret;
>
> platform_set_drvdata(pdev, ep);
> - ret = samsung_irq_init(ep, pdev);
> - if (ret)
> - goto fail_regulator;
> - ep->pci.pp.ops = pdata->host_ops;
> - ret = dw_pcie_host_init(&ep->pci.pp);
> - if (ret < 0)
> +
> + if (pdata->res_ops->set_device_mode)
> + pdata->res_ops->set_device_mode(ep);
> +
> + switch (ep->pdata->device_mode) {
> + case DW_PCIE_RC_TYPE:
> + ret = samsung_irq_init(ep, pdev);
> + if (ret)
> + goto fail_regulator;
> +
> + ep->pci.pp.ops = pdata->host_ops;
> +
> + ret = dw_pcie_host_init(&ep->pci.pp);
> + if (ret < 0)
> + goto fail_phy_init;
> +
> + break;
> + case DW_PCIE_EP_TYPE:
> + phy_init(ep->phy);
> +
> + ep->pci.ep.ops = pdata->ep_ops;
> +
> + ret = dw_pcie_ep_init(&ep->pci.ep);
> + if (ret < 0)
> + goto fail_phy_init;
> +
> + ret = dw_pcie_ep_init_registers(&ep->pci.ep);
> + if (ret)
> + goto fail_phy_init;
> +
> + pci_epc_init_notify(ep->pci.ep.epc);
> +
> + break;
> + default:
> + dev_err(dev, "invalid device type\n");
> goto fail_phy_init;
> + }
This would be a little nicer if you added soc_variant and device_mode
and the code that sets and tests them for exynos_5433 first in a
separate patch. Then it would be more obvious that the new FSD parts
don't affect exynos_5433 since this patch would only be *adding*
FSD-specific things.
> static const struct samsung_pcie_pdata exynos_5433_pcie_rc_pdata = {
> .dwc_ops = &exynos_dw_pcie_ops,
> .pci_ops = &exynos_pci_ops,
> .host_ops = &exynos_pcie_host_ops,
> .res_ops = &exynos_res_ops_data,
> + .soc_variant = EXYNOS_5433,
> + .device_mode = DW_PCIE_RC_TYPE,
> };
> static const struct of_device_id exynos_pcie_of_match[] = {
> @@ -449,6 +756,14 @@ static const struct of_device_id exynos_pcie_of_match[] = {
> .compatible = "samsung,exynos5433-pcie",
> .data = (void *) &exynos_5433_pcie_rc_pdata,
> },
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
2025-06-25 16:52 ` [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC Shradha Todi
2025-06-27 16:29 ` Bjorn Helgaas
@ 2025-06-27 21:12 ` Rob Herring
2025-07-01 11:11 ` Shradha Todi
2025-07-01 13:38 ` Shradha Todi
1 sibling, 2 replies; 30+ messages in thread
From: Rob Herring @ 2025-06-27 21:12 UTC (permalink / raw)
To: Shradha Todi
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, manivannan.sadhasivam,
lpieralisi, kw, bhelgaas, jingoohan1, krzk+dt, conor+dt,
alim.akhtar, vkoul, kishon, arnd, m.szyprowski, jh80.chung,
pankaj.dubey
On Wed, Jun 25, 2025 at 10:22:25PM +0530, Shradha Todi wrote:
> Document the PCIe controller device tree bindings for Tesla FSD
> SoC for both RC and EP.
Drop 'bindings support for ' in the subject.
>
> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> ---
> .../bindings/pci/samsung,exynos-pcie.yaml | 121 ++++++++++++------
I think this should be its own schema file. There's not much shared.
> .../bindings/pci/tesla,fsd-pcie-ep.yaml | 91 +++++++++++++
> 2 files changed, 176 insertions(+), 36 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
> index f20ed7e709f7..595156759b06 100644
> --- a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
> @@ -11,16 +11,15 @@ maintainers:
> - Jaehoon Chung <jh80.chung@samsung.com>
>
> description: |+
> - Exynos5433 SoC PCIe host controller is based on the Synopsys DesignWare
> + Samsung SoCs PCIe host controller is based on the Synopsys DesignWare
> PCIe IP and thus inherits all the common properties defined in
> snps,dw-pcie.yaml.
>
> -allOf:
> - - $ref: /schemas/pci/snps,dw-pcie.yaml#
> -
> properties:
> compatible:
> - const: samsung,exynos5433-pcie
> + enum:
> + - samsung,exynos5433-pcie
> + - tesla,fsd-pcie
>
> reg:
> items:
> @@ -37,52 +36,102 @@ properties:
> interrupts:
> maxItems: 1
>
> - clocks:
> - items:
> - - description: PCIe bridge clock
> - - description: PCIe bus clock
> -
> - clock-names:
> - items:
> - - const: pcie
> - - const: pcie_bus
> -
> phys:
> maxItems: 1
>
> - vdd10-supply:
> - description:
> - Phandle to a regulator that provides 1.0V power to the PCIe block.
> -
> - vdd18-supply:
> - description:
> - Phandle to a regulator that provides 1.8V power to the PCIe block.
> -
> - num-lanes:
> - const: 1
> -
> - num-viewport:
> - const: 3
> -
> required:
> - reg
> - reg-names
> - interrupts
> - "#address-cells"
> - "#size-cells"
> - - "#interrupt-cells"
> - - interrupt-map
> - - interrupt-map-mask
> - ranges
> - - bus-range
> - device_type
> - num-lanes
> - - num-viewport
> - clocks
> - clock-names
> - phys
> - - vdd10-supply
> - - vdd18-supply
> +
> +allOf:
> + - $ref: /schemas/pci/snps,dw-pcie.yaml#
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - tesla,fsd-pcie
> + then:
> + properties:
> + clocks:
> + maxItems: 4
> +
> + clock-names:
> + items:
> + - const: aux
> + - const: dbi
> + - const: mstr
> + - const: slv
> +
> + samsung,syscon-pcie:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description: phandle for system control registers, used to
> + control signals at system level
> +
> + num-lanes:
> + maximum: 4
> +
> + required:
> + - samsung,syscon-pcie
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - samsung,exynos5433-pcie
> + then:
> + properties:
> + clocks:
> + items:
> + - description: pcie bridge clock
> + - description: pcie bus clock
> +
> + clock-names:
> + items:
> + - const: pcie
> + - const: pcie_bus
> +
> + vdd10-supply:
> + description:
> + phandle to a regulator that provides 1.0v power to the pcie block.
> +
> + vdd18-supply:
> + description:
> + phandle to a regulator that provides 1.8v power to the pcie block.
> +
> + num-lanes:
> + const: 1
> +
> + num-viewport:
> + const: 3
> +
> + assigned-clocks:
> + maxItems: 2
> +
> + assigned-clock-parents:
> + maxItems: 2
> +
> + assigned-clock-rates:
> + maxItems: 2
> +
> + required:
> + - "#interrupt-cells"
> + - interrupt-map
> + - interrupt-map-mask
> + - bus-range
> + - num-viewport
> + - vdd10-supply
> + - vdd18-supply
>
> unevaluatedProperties: false
>
> diff --git a/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
> new file mode 100644
> index 000000000000..f85615a0225d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
> @@ -0,0 +1,91 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/tesla,fsd-pcie-ep.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Samsung SoC series PCIe Endpoint Controller
> +
> +maintainers:
> + - Shradha Todi <shradha.t@samsung.com>
> +
> +description: |+
Don't need '|+'
> + Samsung SoCs PCIe endpoint controller is based on the Synopsys DesignWare
> + PCIe IP and thus inherits all the common properties defined in
> + snps,dw-pcie-ep.yaml.
> +
> +allOf:
> + - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
> +
> +properties:
> + compatible:
> + const: tesla,fsd-pcie-ep
> +
> + reg:
> + maxItems: 4
> +
> + reg-names:
> + items:
> + - const: elbi
> + - const: dbi
> + - const: dbi2
> + - const: addr_space
> +
> + clocks:
> + maxItems: 4
> +
> + clock-names:
> + items:
> + - const: aux
> + - const: dbi
> + - const: mstr
> + - const: slv
> +
> + num-lanes:
> + maximum: 4
> +
> + samsung,syscon-pcie:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + description: phandle for system control registers, used to
> + control signals at system level
> +
> + phys:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - num-lanes
> + - samsung,syscon-pcie
> + - phys
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/fsd-clk.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + bus {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + pcieep0: pcie-ep@16a00000 {
> + compatible = "tesla,fsd-pcie-ep";
> + reg = <0x0 0x168b0000 0x0 0x1000>,
> + <0x0 0x16a00000 0x0 0x2000>,
> + <0x0 0x16a01000 0x0 0x80>,
> + <0x0 0x17000000 0x0 0xff0000>;
> + reg-names = "elbi", "dbi", "dbi2", "addr_space";
> + clocks = <&clock_fsys1 PCIE_LINK0_IPCLKPORT_AUX_ACLK>,
> + <&clock_fsys1 PCIE_LINK0_IPCLKPORT_DBI_ACLK>,
> + <&clock_fsys1 PCIE_LINK0_IPCLKPORT_MSTR_ACLK>,
> + <&clock_fsys1 PCIE_LINK0_IPCLKPORT_SLV_ACLK>;
> + clock-names = "aux", "dbi", "mstr", "slv";
> + num-lanes = <4>;
> + samsung,syscon-pcie = <&sysreg_fsys1 0x50c>;
> + phys = <&pciephy1>;
> + };
> + };
> +...
> --
> 2.49.0
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
2025-06-25 16:52 ` [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for " Shradha Todi
@ 2025-06-27 21:17 ` Rob Herring
2025-07-01 11:06 ` Shradha Todi
0 siblings, 1 reply; 30+ messages in thread
From: Rob Herring @ 2025-06-27 21:17 UTC (permalink / raw)
To: Shradha Todi
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, manivannan.sadhasivam,
lpieralisi, kw, bhelgaas, jingoohan1, krzk+dt, conor+dt,
alim.akhtar, vkoul, kishon, arnd, m.szyprowski, jh80.chung,
pankaj.dubey
On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
> Document PHY device tree bindings for Tesla FSD SoCs.
>
> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> ---
> .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> index 41df8bb08ff7..4dc20156cdde 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> @@ -15,10 +15,13 @@ properties:
> const: 0
>
> compatible:
> - const: samsung,exynos5433-pcie-phy
> + enum:
> + - samsung,exynos5433-pcie-phy
> + - tesla,fsd-pcie-phy
>
> reg:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
>
> samsung,pmu-syscon:
> $ref: /schemas/types.yaml#/definitions/phandle
> @@ -30,6 +33,24 @@ properties:
> description: phandle for FSYS sysreg interface, used to control
> sysreg registers bits for PCIe PHY
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - tesla,fsd-pcie-phy
> + then:
> + description:
> + The PHY controller nodes are represented in the aliases node
> + using the following format 'pciephy{n}'. Depending on whether
> + n is 0 or 1, the phy init sequence is chosen.
What? Don't make up your own aliases.
If the PHY instances are different, then maybe you need a different
compatible. If this is just selecting the PHY mode, you can do that in
PHY cells as the mode depends on the consumer.
> + properties:
> + reg:
> + items:
> + - description: PHY
> + - description: PCS
else:
properties:
reg:
maxItems: 1
> +
> required:
> - "#phy-cells"
> - compatible
> --
> 2.49.0
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/10] PCI: exynos: Add support for Tesla FSD SoC
2025-06-25 16:52 ` [PATCH v2 09/10] PCI: exynos: Add support for Tesla " Shradha Todi
2025-06-27 19:30 ` Bjorn Helgaas
@ 2025-06-30 16:26 ` Dan Carpenter
1 sibling, 0 replies; 30+ messages in thread
From: Dan Carpenter @ 2025-06-30 16:26 UTC (permalink / raw)
To: oe-kbuild, Shradha Todi, linux-pci, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, linux-phy, linux-fsd
Cc: lkp, oe-kbuild-all, manivannan.sadhasivam, lpieralisi, kw, robh,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey,
Shradha Todi
Hi Shradha,
kernel test robot noticed the following build warnings:
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Shradha-Todi/PCI-exynos-Remove-unused-MACROs-in-exynos-PCI-file/20250626-104154
base: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link: https://lore.kernel.org/r/20250625165229.3458-10-shradha.t%40samsung.com
patch subject: [PATCH v2 09/10] PCI: exynos: Add support for Tesla FSD SoC
config: um-randconfig-r071-20250630 (https://download.01.org/0day-ci/archive/20250630/202506301329.VWoiH0yn-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14+deb12u1) 12.2.0
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
| Closes: https://lore.kernel.org/r/202506301329.VWoiH0yn-lkp@intel.com/
smatch warnings:
drivers/pci/controller/dwc/pci-exynos.c:621 exynos_pcie_probe() error: we previously assumed 'pdata->res_ops' could be null (see line 609)
drivers/pci/controller/dwc/pci-exynos.c:655 exynos_pcie_probe() warn: missing error code 'ret'
vim +621 drivers/pci/controller/dwc/pci-exynos.c
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 595 dev_err(dev, "couldn't get the register offset for syscon!\n");
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 596 return ret;
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 597 }
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 598 }
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 599
778f7c194b1dac drivers/pci/controller/dwc/pci-exynos.c Jaehoon Chung 2020-11-13 600 /* External Local Bus interface (ELBI) registers */
778f7c194b1dac drivers/pci/controller/dwc/pci-exynos.c Jaehoon Chung 2020-11-13 601 ep->elbi_base = devm_platform_ioremap_resource_byname(pdev, "elbi");
778f7c194b1dac drivers/pci/controller/dwc/pci-exynos.c Jaehoon Chung 2020-11-13 602 if (IS_ERR(ep->elbi_base))
778f7c194b1dac drivers/pci/controller/dwc/pci-exynos.c Jaehoon Chung 2020-11-13 603 return PTR_ERR(ep->elbi_base);
778f7c194b1dac drivers/pci/controller/dwc/pci-exynos.c Jaehoon Chung 2020-11-13 604
10106d5c1f9cee drivers/pci/controller/dwc/pci-exynos.c Cristian Ciocaltea 2024-12-17 605 ret = devm_clk_bulk_get_all_enabled(dev, &ep->clks);
6b11143f9344dd dripdata->res_opsvers/pci/controller/dwc/pci-exynos.c Shradha Todi 2024-02-20 606 if (ret < 0)
6b11143f9344dd drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2024-02-20 607 return ret;
4b1ced841b2e31 drivers/pci/host/pci-exynos.c Jingoo Han 2013-07-31 608
ed1b6ec2c47ce8 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 @609 if (pdata->res_ops && pdata->res_ops->init_regulator) {
^^^^^^^^^^^^^^
This code assumes pdata->res_ops can be NULL
ed1b6ec2c47ce8 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 610 ret = ep->pdata->res_ops->init_regulator(ep);
4b1ced841b2e31 drivers/pci/host/pci-exynos.c Jingoo Han 2013-07-31 611 if (ret)
4b1ced841b2e31 drivers/pci/host/pci-exynos.c Jingoo Han 2013-07-31 612 return ret;
ed1b6ec2c47ce8 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 613 }
4b1ced841b2e31 drivers/pci/host/pci-exynos.c Jingoo Han 2013-07-31 614
ed1b6ec2c47ce8 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 615 ret = samsung_regulator_enable(ep);
3278478084747c drivers/pci/host/pci-exynos.c Niyas Ahmed S T 2017-02-01 616 if (ret)
3278478084747c drivers/pci/host/pci-exynos.c Niyas Ahmed S T 2017-02-01 617 return ret;
4b1ced841b2e31 drivers/pci/host/pci-exynos.c Jingoo Han 2013-07-31 618
b2e6d3055d5545 drivers/pci/dwc/pci-exynos.c Bjorn Helgaas 2017-02-21 619 platform_set_drvdata(pdev, ep);
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 620
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 @621 if (pdata->res_ops->set_device_mode)
^^^^^^^^^^^^^^
But this dereferences it without checking. Most likely the
NULL check should be removed?
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 622 pdata->res_ops->set_device_mode(ep);
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 623
b9388ee21b4e79 drivers/pci/controller/dwc/pci-exynos.c Shradha Todi 2025-06-25 624 switch (ep->pdata->device_mode) {
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
2025-06-27 21:17 ` Rob Herring
@ 2025-07-01 11:06 ` Shradha Todi
2025-07-01 11:25 ` Krzysztof Kozlowski
0 siblings, 1 reply; 30+ messages in thread
From: Shradha Todi @ 2025-07-01 11:06 UTC (permalink / raw)
To: 'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: 28 June 2025 02:47
> To: Shradha Todi <shradha.t@samsung.com>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
>
> On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
> > Document PHY device tree bindings for Tesla FSD SoCs.
> >
> > Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> > ---
> > .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
> > 1 file changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > index 41df8bb08ff7..4dc20156cdde 100644
> > --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> > @@ -15,10 +15,13 @@ properties:
> > const: 0
> >
> > compatible:
> > - const: samsung,exynos5433-pcie-phy
> > + enum:
> > + - samsung,exynos5433-pcie-phy
> > + - tesla,fsd-pcie-phy
> >
> > reg:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 2
> >
> > samsung,pmu-syscon:
> > $ref: /schemas/types.yaml#/definitions/phandle
> > @@ -30,6 +33,24 @@ properties:
> > description: phandle for FSYS sysreg interface, used to control
> > sysreg registers bits for PCIe PHY
> >
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - tesla,fsd-pcie-phy
> > + then:
> > + description:
> > + The PHY controller nodes are represented in the aliases node
> > + using the following format 'pciephy{n}'. Depending on whether
> > + n is 0 or 1, the phy init sequence is chosen.
>
> What? Don't make up your own aliases.
>
> If the PHY instances are different, then maybe you need a different
> compatible. If this is just selecting the PHY mode, you can do that in
> PHY cells as the mode depends on the consumer.
>
FSD PCIe has 2 instances of PHY. Both are the same HW Samsung
PHYs (Therefore share the same register offsets). But the PHY used here
does not support auto adaptation so we need to tune the PHYs
according to the use case (considering channel loss, etc). This is why we
have 2 different SW PHY initialization sequence depending on the instance
number. Do you think having different compatible (something like
tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
is okay in this case? I actually took reference from files like:
drivers/usb/phy/phy-am335x-control.c
drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
who use alias to differentiate between register offsets for instances.
>
> > + properties:
> > + reg:
> > + items:
> > + - description: PHY
> > + - description: PCS
>
> else:
> properties:
> reg:
> maxItems: 1
>
Will update. Thanks for the review!
> > +
> > required:
> > - "#phy-cells"
> > - compatible
> > --
> > 2.49.0
> >
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
2025-06-27 21:12 ` Rob Herring
@ 2025-07-01 11:11 ` Shradha Todi
2025-07-01 11:20 ` Krzysztof Kozlowski
2025-07-01 13:38 ` Shradha Todi
1 sibling, 1 reply; 30+ messages in thread
From: Shradha Todi @ 2025-07-01 11:11 UTC (permalink / raw)
To: 'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: 28 June 2025 02:43
> To: Shradha Todi <shradha.t@samsung.com>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
>
> On Wed, Jun 25, 2025 at 10:22:25PM +0530, Shradha Todi wrote:
> > Document the PCIe controller device tree bindings for Tesla FSD
> > SoC for both RC and EP.
>
> Drop 'bindings support for ' in the subject.
>
> >
> > Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> > ---
> > .../bindings/pci/samsung,exynos-pcie.yaml | 121 ++++++++++++------
>
> I think this should be its own schema file. There's not much shared.
>
Will make 2 new bindings - samsung,exynos-pcie-common.yaml and
tesla,fsd-pcie.yaml
Does that sound okay?
> > .../bindings/pci/tesla,fsd-pcie-ep.yaml | 91 +++++++++++++
> > 2 files changed, 176 insertions(+), 36 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
> b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
> > index f20ed7e709f7..595156759b06 100644
> > --- a/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
> > @@ -11,16 +11,15 @@ maintainers:
> > - Jaehoon Chung <jh80.chung@samsung.com>
> >
> > description: |+
> > - Exynos5433 SoC PCIe host controller is based on the Synopsys DesignWare
> > + Samsung SoCs PCIe host controller is based on the Synopsys DesignWare
> > PCIe IP and thus inherits all the common properties defined in
> > snps,dw-pcie.yaml.
> >
> > -allOf:
> > - - $ref: /schemas/pci/snps,dw-pcie.yaml#
> > -
> > properties:
> > compatible:
> > - const: samsung,exynos5433-pcie
> > + enum:
> > + - samsung,exynos5433-pcie
> > + - tesla,fsd-pcie
> >
> > reg:
> > items:
> > @@ -37,52 +36,102 @@ properties:
> > interrupts:
> > maxItems: 1
> >
> > - clocks:
> > - items:
> > - - description: PCIe bridge clock
> > - - description: PCIe bus clock
> > -
> > - clock-names:
> > - items:
> > - - const: pcie
> > - - const: pcie_bus
> > -
> > phys:
> > maxItems: 1
> >
> > - vdd10-supply:
> > - description:
> > - Phandle to a regulator that provides 1.0V power to the PCIe block.
> > -
> > - vdd18-supply:
> > - description:
> > - Phandle to a regulator that provides 1.8V power to the PCIe block.
> > -
> > - num-lanes:
> > - const: 1
> > -
> > - num-viewport:
> > - const: 3
> > -
> > required:
> > - reg
> > - reg-names
> > - interrupts
> > - "#address-cells"
> > - "#size-cells"
> > - - "#interrupt-cells"
> > - - interrupt-map
> > - - interrupt-map-mask
> > - ranges
> > - - bus-range
> > - device_type
> > - num-lanes
> > - - num-viewport
> > - clocks
> > - clock-names
> > - phys
> > - - vdd10-supply
> > - - vdd18-supply
> > +
> > +allOf:
> > + - $ref: /schemas/pci/snps,dw-pcie.yaml#
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - tesla,fsd-pcie
> > + then:
> > + properties:
> > + clocks:
> > + maxItems: 4
> > +
> > + clock-names:
> > + items:
> > + - const: aux
> > + - const: dbi
> > + - const: mstr
> > + - const: slv
> > +
> > + samsung,syscon-pcie:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + description: phandle for system control registers, used to
> > + control signals at system level
> > +
> > + num-lanes:
> > + maximum: 4
> > +
> > + required:
> > + - samsung,syscon-pcie
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - samsung,exynos5433-pcie
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: pcie bridge clock
> > + - description: pcie bus clock
> > +
> > + clock-names:
> > + items:
> > + - const: pcie
> > + - const: pcie_bus
> > +
> > + vdd10-supply:
> > + description:
> > + phandle to a regulator that provides 1.0v power to the pcie block.
> > +
> > + vdd18-supply:
> > + description:
> > + phandle to a regulator that provides 1.8v power to the pcie block.
> > +
> > + num-lanes:
> > + const: 1
> > +
> > + num-viewport:
> > + const: 3
> > +
> > + assigned-clocks:
> > + maxItems: 2
> > +
> > + assigned-clock-parents:
> > + maxItems: 2
> > +
> > + assigned-clock-rates:
> > + maxItems: 2
> > +
> > + required:
> > + - "#interrupt-cells"
> > + - interrupt-map
> > + - interrupt-map-mask
> > + - bus-range
> > + - num-viewport
> > + - vdd10-supply
> > + - vdd18-supply
> >
> > unevaluatedProperties: false
> >
> > diff --git a/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
> b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
> > new file mode 100644
> > index 000000000000..f85615a0225d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: https://protect2.fireeye.com/v1/url?k=48166268-299d775e-4817e927-74fe485fffe0-
> 300a108993374478&q=1&e=3e3a0fc6-8338-4fe3-b352-
> 2e510a3c6aaa&u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fpci%2Ftesla%2Cfsd-pcie-ep.yaml%23
> > +$schema: https://protect2.fireeye.com/v1/url?k=60c79c47-014c8971-60c61708-74fe485fffe0-
> 2608e7d54b39a025&q=1&e=3e3a0fc6-8338-4fe3-b352-
> 2e510a3c6aaa&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
> > +
> > +title: Samsung SoC series PCIe Endpoint Controller
> > +
> > +maintainers:
> > + - Shradha Todi <shradha.t@samsung.com>
> > +
> > +description: |+
>
> Don't need '|+'
>
> > + Samsung SoCs PCIe endpoint controller is based on the Synopsys DesignWare
> > + PCIe IP and thus inherits all the common properties defined in
> > + snps,dw-pcie-ep.yaml.
> > +
> > +allOf:
> > + - $ref: /schemas/pci/snps,dw-pcie-ep.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: tesla,fsd-pcie-ep
> > +
> > + reg:
> > + maxItems: 4
> > +
> > + reg-names:
> > + items:
> > + - const: elbi
> > + - const: dbi
> > + - const: dbi2
> > + - const: addr_space
> > +
> > + clocks:
> > + maxItems: 4
> > +
> > + clock-names:
> > + items:
> > + - const: aux
> > + - const: dbi
> > + - const: mstr
> > + - const: slv
> > +
> > + num-lanes:
> > + maximum: 4
> > +
> > + samsung,syscon-pcie:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + description: phandle for system control registers, used to
> > + control signals at system level
> > +
> > + phys:
> > + maxItems: 1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - clocks
> > + - clock-names
> > + - num-lanes
> > + - samsung,syscon-pcie
> > + - phys
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/fsd-clk.h>
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + bus {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + pcieep0: pcie-ep@16a00000 {
> > + compatible = "tesla,fsd-pcie-ep";
> > + reg = <0x0 0x168b0000 0x0 0x1000>,
> > + <0x0 0x16a00000 0x0 0x2000>,
> > + <0x0 0x16a01000 0x0 0x80>,
> > + <0x0 0x17000000 0x0 0xff0000>;
> > + reg-names = "elbi", "dbi", "dbi2", "addr_space";
> > + clocks = <&clock_fsys1 PCIE_LINK0_IPCLKPORT_AUX_ACLK>,
> > + <&clock_fsys1 PCIE_LINK0_IPCLKPORT_DBI_ACLK>,
> > + <&clock_fsys1 PCIE_LINK0_IPCLKPORT_MSTR_ACLK>,
> > + <&clock_fsys1 PCIE_LINK0_IPCLKPORT_SLV_ACLK>;
> > + clock-names = "aux", "dbi", "mstr", "slv";
> > + num-lanes = <4>;
> > + samsung,syscon-pcie = <&sysreg_fsys1 0x50c>;
> > + phys = <&pciephy1>;
> > + };
> > + };
> > +...
> > --
> > 2.49.0
> >
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v2 09/10] PCI: exynos: Add support for Tesla FSD SoC
2025-06-27 19:30 ` Bjorn Helgaas
@ 2025-07-01 11:18 ` Shradha Todi
2025-07-01 16:57 ` Bjorn Helgaas
0 siblings, 1 reply; 30+ messages in thread
From: Shradha Todi @ 2025-07-01 11:18 UTC (permalink / raw)
To: 'Bjorn Helgaas'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw, robh,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
> -----Original Message-----
> From: Bjorn Helgaas <helgaas@kernel.org>
> Sent: 28 June 2025 01:01
> To: Shradha Todi <shradha.t@samsung.com>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> robh@kernel.org; bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org;
> conor+dt@kernel.org; alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org;
> arnd@arndb.de; m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 09/10] PCI: exynos: Add support for Tesla FSD SoC
>
> On Wed, Jun 25, 2025 at 10:22:28PM +0530, Shradha Todi wrote:
> > Add host and endpoint controller driver support for FSD SoC.
>
> > +++ b/drivers/pci/controller/dwc/pci-exynos.c
> > @@ -20,6 +20,8 @@
> > #include <linux/regulator/consumer.h>
> > #include <linux/mod_devicetable.h>
> > #include <linux/module.h>
> > +#include <linux/regmap.h>
> > +#include <linux/mfd/syscon.h>
>
> The trend is to sort these alphabetically. The last couple additions
> didn't observe this, but maybe these new ones could go a little
> farther up and make it more sorted rather than less?
>
> > +#define FSD_PCIE_CXPL_DEBUG_00_31 0x2C8
>
> Existing #defines use lower-case hex; please follow suit.
>
> > +/* to store different SoC variants of Samsung */
> > +enum samsung_pcie_variants {
> > + FSD,
> > + EXYNOS_5433,
> > +};
>
> > struct samsung_pcie_pdata {
> > struct pci_ops *pci_ops;
> > const struct dw_pcie_ops *dwc_ops;
> > const struct dw_pcie_host_ops *host_ops;
> > + const struct dw_pcie_ep_ops *ep_ops;
> > const struct samsung_res_ops *res_ops;
> > + unsigned int soc_variant;
> > + enum dw_pcie_device_mode device_mode;
> > };
>
> > +static u32 fsd_pcie_read_dbi(struct dw_pcie *pci, void __iomem *base,
> > + u32 reg, size_t size)
> > +{
> > + void __iomem *addr;
> > + u32 val;
> > +
> > + addr = fsd_atu_setting(pci, base);
> > +
> > + dw_pcie_read(addr + reg, size, &val);
> > +
> > + return val;
>
> Remove blank lines to match style of fsd_pcie_write_dbi2().
>
> > +}
> > +
> > +static void fsd_pcie_write_dbi(struct dw_pcie *pci, void __iomem *base,
> > + u32 reg, size_t size, u32 val)
> > +{
> > + void __iomem *addr;
> > +
> > + addr = fsd_atu_setting(pci, base);
> > +
> > + dw_pcie_write(addr + reg, size, val);
>
> Ditto.
>
> > +}
> > +
> > +static void fsd_pcie_write_dbi2(struct dw_pcie *pci, void __iomem *base,
> > + u32 reg, size_t size, u32 val)
> > +{
> > + struct exynos_pcie *ep = to_exynos_pcie(pci);
> > +
> > + fsd_atu_setting(pci, base);
> > + dw_pcie_write(pci->dbi_base + reg, size, val);
> > + regmap_write(ep->sysreg, ep->sysreg_offset, ADDR_TYPE_DBI);
> > +}
>
> > +static int fsd_pcie_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > + unsigned int type, u16 interrupt_num)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +
> > + switch (type) {
> > + case PCI_IRQ_INTX:
> > + return dw_pcie_ep_raise_intx_irq(ep, func_no);
> > + case PCI_IRQ_MSIX:
> > + dev_err(pci->dev, "EP does not support MSIX\n");
>
> s/MSIX/MSI-X/ to match spec usage.
>
Thanks for the review! Will take care of all mentioned changes in next version
> > @@ -373,13 +617,43 @@ static int exynos_pcie_probe(struct platform_device *pdev)
> > return ret;
> >
> > platform_set_drvdata(pdev, ep);
> > - ret = samsung_irq_init(ep, pdev);
> > - if (ret)
> > - goto fail_regulator;
> > - ep->pci.pp.ops = pdata->host_ops;
> > - ret = dw_pcie_host_init(&ep->pci.pp);
> > - if (ret < 0)
> > +
> > + if (pdata->res_ops->set_device_mode)
> > + pdata->res_ops->set_device_mode(ep);
> > +
> > + switch (ep->pdata->device_mode) {
> > + case DW_PCIE_RC_TYPE:
> > + ret = samsung_irq_init(ep, pdev);
> > + if (ret)
> > + goto fail_regulator;
> > +
> > + ep->pci.pp.ops = pdata->host_ops;
> > +
> > + ret = dw_pcie_host_init(&ep->pci.pp);
> > + if (ret < 0)
> > + goto fail_phy_init;
> > +
> > + break;
> > + case DW_PCIE_EP_TYPE:
> > + phy_init(ep->phy);
> > +
> > + ep->pci.ep.ops = pdata->ep_ops;
> > +
> > + ret = dw_pcie_ep_init(&ep->pci.ep);
> > + if (ret < 0)
> > + goto fail_phy_init;
> > +
> > + ret = dw_pcie_ep_init_registers(&ep->pci.ep);
> > + if (ret)
> > + goto fail_phy_init;
> > +
> > + pci_epc_init_notify(ep->pci.ep.epc);
> > +
> > + break;
> > + default:
> > + dev_err(dev, "invalid device type\n");
> > goto fail_phy_init;
> > + }
>
> This would be a little nicer if you added soc_variant and device_mode
> and the code that sets and tests them for exynos_5433 first in a
> separate patch. Then it would be more obvious that the new FSD parts
> don't affect exynos_5433 since this patch would only be *adding*
> FSD-specific things.
>
Sure, I have no issues in splitting the patches further. Though unfortunately,
I or anyone I know does not possess a board which has Exynos 5433 chipset.
Therefore, I'm unable to verify these changes for Exynos chipset. I took care
to not disturb the exynos flow functionally but would be great if someone
could test this and confirm that it works well on Exynos 5433 after the changes.
> > static const struct samsung_pcie_pdata exynos_5433_pcie_rc_pdata = {
> > .dwc_ops = &exynos_dw_pcie_ops,
> > .pci_ops = &exynos_pci_ops,
> > .host_ops = &exynos_pcie_host_ops,
> > .res_ops = &exynos_res_ops_data,
> > + .soc_variant = EXYNOS_5433,
> > + .device_mode = DW_PCIE_RC_TYPE,
> > };
>
> > static const struct of_device_id exynos_pcie_of_match[] = {
> > @@ -449,6 +756,14 @@ static const struct of_device_id exynos_pcie_of_match[] = {
> > .compatible = "samsung,exynos5433-pcie",
> > .data = (void *) &exynos_5433_pcie_rc_pdata,
> > },
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
2025-07-01 11:11 ` Shradha Todi
@ 2025-07-01 11:20 ` Krzysztof Kozlowski
0 siblings, 0 replies; 30+ messages in thread
From: Krzysztof Kozlowski @ 2025-07-01 11:20 UTC (permalink / raw)
To: Shradha Todi, 'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
On 01/07/2025 13:11, Shradha Todi wrote:
>
>
>> -----Original Message-----
>> From: Rob Herring <robh@kernel.org>
>> Sent: 28 June 2025 02:43
>> To: Shradha Todi <shradha.t@samsung.com>
>> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-
>> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
>> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
>> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
>> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
>> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
>> Subject: Re: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
>>
>> On Wed, Jun 25, 2025 at 10:22:25PM +0530, Shradha Todi wrote:
>>> Document the PCIe controller device tree bindings for Tesla FSD
>>> SoC for both RC and EP.
>>
>> Drop 'bindings support for ' in the subject.
Please kindly trim the replies from unnecessary context. It makes it
much easier to find new content.
Where is your reply? I even scrolled till the end of email and I only
see quotes.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
2025-07-01 11:06 ` Shradha Todi
@ 2025-07-01 11:25 ` Krzysztof Kozlowski
2025-07-01 13:35 ` Shradha Todi
0 siblings, 1 reply; 30+ messages in thread
From: Krzysztof Kozlowski @ 2025-07-01 11:25 UTC (permalink / raw)
To: Shradha Todi, 'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
On 01/07/2025 13:06, Shradha Todi wrote:
>
>
>> -----Original Message-----
>> From: Rob Herring <robh@kernel.org>
>> Sent: 28 June 2025 02:47
>> To: Shradha Todi <shradha.t@samsung.com>
>> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-
>> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
>> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
>> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
>> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
>> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
>> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
>>
>> On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
>>> Document PHY device tree bindings for Tesla FSD SoCs.
>>>
>>> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
>>> ---
>>> .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
>>> 1 file changed, 23 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
>> b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
>>> index 41df8bb08ff7..4dc20156cdde 100644
>>> --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
>>> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
>>> @@ -15,10 +15,13 @@ properties:
>>> const: 0
>>>
>>> compatible:
>>> - const: samsung,exynos5433-pcie-phy
>>> + enum:
>>> + - samsung,exynos5433-pcie-phy
>>> + - tesla,fsd-pcie-phy
>>>
>>> reg:
>>> - maxItems: 1
>>> + minItems: 1
>>> + maxItems: 2
>>>
>>> samsung,pmu-syscon:
>>> $ref: /schemas/types.yaml#/definitions/phandle
>>> @@ -30,6 +33,24 @@ properties:
>>> description: phandle for FSYS sysreg interface, used to control
>>> sysreg registers bits for PCIe PHY
>>>
>>> +allOf:
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + enum:
>>> + - tesla,fsd-pcie-phy
>>> + then:
>>> + description:
>>> + The PHY controller nodes are represented in the aliases node
>>> + using the following format 'pciephy{n}'. Depending on whether
>>> + n is 0 or 1, the phy init sequence is chosen.
>>
>> What? Don't make up your own aliases.
>>
>> If the PHY instances are different, then maybe you need a different
>> compatible. If this is just selecting the PHY mode, you can do that in
>> PHY cells as the mode depends on the consumer.
>>
>
> FSD PCIe has 2 instances of PHY. Both are the same HW Samsung
> PHYs (Therefore share the same register offsets). But the PHY used here
So same?
> does not support auto adaptation so we need to tune the PHYs
> according to the use case (considering channel loss, etc). This is why we
So not same? Decide. Either it is same or not, cannot be both.
If you mean that some wiring is different on the board, then how does it
differ in soc thus how it is per-soc property? If these are use-cases,
then how is even suitable for DT?
I use your Tesla FSD differently and then I exchange DTSI and compatibles?
You are no describing real problem and both binding and your
explanations are vague and imprecise. Binding tells nothing about it, so
it is example of skipping important decisions.
> have 2 different SW PHY initialization sequence depending on the instance
> number. Do you think having different compatible (something like
> tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
> is okay in this case? I actually took reference from files like:
And in different use case on same soc you are going to reverse
compatibles or instance IDs?
> drivers/usb/phy/phy-am335x-control.c
So you took 15 years old hardware, code and binding as an example.
No, don't do that ever.
Anyway, poor choices even in newer code should not drive your design.
Design it properly, describe the hardware.
> drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> who use alias to differentiate between register offsets for instances.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
2025-06-27 16:29 ` Bjorn Helgaas
@ 2025-07-01 11:33 ` Shradha Todi
2025-07-01 17:16 ` Bjorn Helgaas
0 siblings, 1 reply; 30+ messages in thread
From: Shradha Todi @ 2025-07-01 11:33 UTC (permalink / raw)
To: 'Bjorn Helgaas'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw, robh,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
> -----Original Message-----
> From: Bjorn Helgaas <helgaas@kernel.org>
> Sent: 27 June 2025 22:00
> To: Shradha Todi <shradha.t@samsung.com>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> robh@kernel.org; bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org;
> conor+dt@kernel.org; alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org;
> arnd@arndb.de; m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
>
> On Wed, Jun 25, 2025 at 10:22:25PM +0530, Shradha Todi wrote:
> > Document the PCIe controller device tree bindings for Tesla FSD
> > SoC for both RC and EP.
>
> > +++ b/Documentation/devicetree/bindings/pci/samsung,exynos-pcie.yaml
>
> > - clocks:
> > - items:
> > - - description: PCIe bridge clock
> > - - description: PCIe bus clock
>
> > - vdd10-supply:
> > - description:
> > - Phandle to a regulator that provides 1.0V power to the PCIe block.
> > -
> > - vdd18-supply:
> > - description:
> > - Phandle to a regulator that provides 1.8V power to the PCIe block.
>
> > + - description: pcie bridge clock
> > + - description: pcie bus clock
>
> Gratuitous "PCIe" capitalization changes here and in supplies below.
> This is just plain English text so we can use English conventions.
>
> > + vdd10-supply:
> > + description:
> > + phandle to a regulator that provides 1.0v power to the pcie block.
> > +
> > + vdd18-supply:
> > + description:
> > + phandle to a regulator that provides 1.8v power to the pcie block.
>
> I *would* be OK if you dropped the periods at the end of these, which
> would make them match the other descriptions in this binding.
>
> > +++ b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
>
> I'm not sure about the "tesla,fsd-pcie-ep.yaml" filename. I see that
> it currently only describes a tesla endpoint, but it seems like maybe
> this should be parallel to the "samsung,exynos-pcie.yaml" host
> controller binding.
>
> Bjorn
Actually there is no support for Exynos5433 in EP mode. Initially I named
the binding file "samsung,exynos-pcie-ep.yaml" to make it parallel to the host
controller bindings. But I received a comment that file names should match
the compatible strings which makes sense so I changed it to this.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
2025-07-01 11:25 ` Krzysztof Kozlowski
@ 2025-07-01 13:35 ` Shradha Todi
2025-07-02 20:18 ` Krzysztof Kozlowski
0 siblings, 1 reply; 30+ messages in thread
From: Shradha Todi @ 2025-07-01 13:35 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', 'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: 01 July 2025 16:55
> To: Shradha Todi <shradha.t@samsung.com>; 'Rob Herring' <robh@kernel.org>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> fsd@tesla.com; mani@kernel.org; lpieralisi@kernel.org; kw@linux.com; bhelgaas@google.com;
> jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org; alim.akhtar@samsung.com;
> vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de; m.szyprowski@samsung.com;
> jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
>
> On 01/07/2025 13:06, Shradha Todi wrote:
> >
> >
> >> -----Original Message-----
> >> From: Rob Herring <robh@kernel.org>
> >> Sent: 28 June 2025 02:47
> >> To: Shradha Todi <shradha.t@samsung.com>
> >> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > linux-
> >> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> >> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> >> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> >> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
> >> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> >> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
> >>
> >> On Wed, Jun 25, 2025 at 10:22:26PM +0530, Shradha Todi wrote:
> >>> Document PHY device tree bindings for Tesla FSD SoCs.
> >>>
> >>> Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> >>> ---
> >>> .../bindings/phy/samsung,exynos-pcie-phy.yaml | 25 +++++++++++++++++--
> >>> 1 file changed, 23 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> >> b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> >>> index 41df8bb08ff7..4dc20156cdde 100644
> >>> --- a/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> >>> +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-pcie-phy.yaml
> >>> @@ -15,10 +15,13 @@ properties:
> >>> const: 0
> >>>
> >>> compatible:
> >>> - const: samsung,exynos5433-pcie-phy
> >>> + enum:
> >>> + - samsung,exynos5433-pcie-phy
> >>> + - tesla,fsd-pcie-phy
> >>>
> >>> reg:
> >>> - maxItems: 1
> >>> + minItems: 1
> >>> + maxItems: 2
> >>>
> >>> samsung,pmu-syscon:
> >>> $ref: /schemas/types.yaml#/definitions/phandle
> >>> @@ -30,6 +33,24 @@ properties:
> >>> description: phandle for FSYS sysreg interface, used to control
> >>> sysreg registers bits for PCIe PHY
> >>>
> >>> +allOf:
> >>> + - if:
> >>> + properties:
> >>> + compatible:
> >>> + contains:
> >>> + enum:
> >>> + - tesla,fsd-pcie-phy
> >>> + then:
> >>> + description:
> >>> + The PHY controller nodes are represented in the aliases node
> >>> + using the following format 'pciephy{n}'. Depending on whether
> >>> + n is 0 or 1, the phy init sequence is chosen.
> >>
> >> What? Don't make up your own aliases.
> >>
> >> If the PHY instances are different, then maybe you need a different
> >> compatible. If this is just selecting the PHY mode, you can do that in
> >> PHY cells as the mode depends on the consumer.
> >>
> >
> > FSD PCIe has 2 instances of PHY. Both are the same HW Samsung
> > PHYs (Therefore share the same register offsets). But the PHY used here
>
> So same?
>
> > does not support auto adaptation so we need to tune the PHYs
> > according to the use case (considering channel loss, etc). This is why we
>
> So not same? Decide. Either it is same or not, cannot be both.
>
> If you mean that some wiring is different on the board, then how does it
> differ in soc thus how it is per-soc property? If these are use-cases,
> then how is even suitable for DT?
>
> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
>
> You are no describing real problem and both binding and your
> explanations are vague and imprecise. Binding tells nothing about it, so
> it is example of skipping important decisions.
>
> > have 2 different SW PHY initialization sequence depending on the instance
> > number. Do you think having different compatible (something like
> > tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
> > is okay in this case? I actually took reference from files like:
>
> And in different use case on same soc you are going to reverse
> compatibles or instance IDs?
>
Even though both the PHYs are exactly identical in terms of hardware,
they need to be programmed/initialized/configured differently.
Sorry for my misuse of the word "use-case". To clarify, these configurations
will always remain the same for FSD SoC even if you use it differently.
I will use different compatibles for them as I understand that it is the best
option.
> > drivers/usb/phy/phy-am335x-control.c
>
> So you took 15 years old hardware, code and binding as an example.
>
> No, don't do that ever.
>
> Anyway, poor choices even in newer code should not drive your design.
> Design it properly, describe the hardware.
>
> > drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> > who use alias to differentiate between register offsets for instances.
>
>
>
> Best regards,
> Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
2025-06-27 21:12 ` Rob Herring
2025-07-01 11:11 ` Shradha Todi
@ 2025-07-01 13:38 ` Shradha Todi
1 sibling, 0 replies; 30+ messages in thread
From: Shradha Todi @ 2025-07-01 13:38 UTC (permalink / raw)
To: 'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, manivannan.sadhasivam,
lpieralisi, kw, bhelgaas, jingoohan1, krzk+dt, conor+dt,
alim.akhtar, vkoul, kishon, arnd, m.szyprowski, jh80.chung,
pankaj.dubey
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: 28 June 2025 02:43
> To: Shradha Todi <shradha.t@samsung.com>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux-
> samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org; conor+dt@kernel.org;
> alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org; arnd@arndb.de;
> m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
>
> On Wed, Jun 25, 2025 at 10:22:25PM +0530, Shradha Todi wrote:
> > Document the PCIe controller device tree bindings for Tesla FSD
> > SoC for both RC and EP.
>
> Drop 'bindings support for ' in the subject.
>
> >
> > Signed-off-by: Shradha Todi <shradha.t@samsung.com>
> > ---
> > .../bindings/pci/samsung,exynos-pcie.yaml | 121 ++++++++++++------
>
> I think this should be its own schema file. There's not much shared.
>
Resending my reply after trimming.
Will make 2 new bindings - samsung,exynos-pcie-common.yaml and
tesla,fsd-pcie.yaml
Does that sound okay?
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/10] PCI: exynos: Add support for Tesla FSD SoC
2025-07-01 11:18 ` Shradha Todi
@ 2025-07-01 16:57 ` Bjorn Helgaas
0 siblings, 0 replies; 30+ messages in thread
From: Bjorn Helgaas @ 2025-07-01 16:57 UTC (permalink / raw)
To: Shradha Todi
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw, robh,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
On Tue, Jul 01, 2025 at 04:48:13PM +0530, Shradha Todi wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@kernel.org>
> > Sent: 28 June 2025 01:01
> > To: Shradha Todi <shradha.t@samsung.com>
> > Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> linux-
> > samsung-soc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-
> > fsd@tesla.com; manivannan.sadhasivam@linaro.org; lpieralisi@kernel.org; kw@linux.com;
> > robh@kernel.org; bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org;
> > conor+dt@kernel.org; alim.akhtar@samsung.com; vkoul@kernel.org; kishon@kernel.org;
> > arnd@arndb.de; m.szyprowski@samsung.com; jh80.chung@samsung.com; pankaj.dubey@samsung.com
> > Subject: Re: [PATCH v2 09/10] PCI: exynos: Add support for Tesla FSD SoC
Would be good if your mailer could support the usual quote mechanism,
e.g. the "On Wed, Jun 25, 2025 at 10:22:28PM +0530, Shradha Todi
wrote:" line below. No need for all the header duplication above.
> > On Wed, Jun 25, 2025 at 10:22:28PM +0530, Shradha Todi wrote:
> > > Add host and endpoint controller driver support for FSD SoC.
> > This would be a little nicer if you added soc_variant and device_mode
> > and the code that sets and tests them for exynos_5433 first in a
> > separate patch. Then it would be more obvious that the new FSD parts
> > don't affect exynos_5433 since this patch would only be *adding*
> > FSD-specific things.
>
> Sure, I have no issues in splitting the patches further. Though
> unfortunately, I or anyone I know does not possess a board which has
> Exynos 5433 chipset. Therefore, I'm unable to verify these changes
> for Exynos chipset. I took care to not disturb the exynos flow
> functionally but would be great if someone could test this and
> confirm that it works well on Exynos 5433 after the changes.
Yeah, that's a common situation, and there's no problem with adding
this functionality. But in the unlikely event there's a mistake that
relates to Exynos 5433, it will be easier for someone with that board
to analyze the problem if the changes that affect exynos_5433 are
split out into a patch that doesn't include any FSD-related changes.
> > > static const struct samsung_pcie_pdata exynos_5433_pcie_rc_pdata = {
> > > .dwc_ops = &exynos_dw_pcie_ops,
> > > .pci_ops = &exynos_pci_ops,
> > > .host_ops = &exynos_pcie_host_ops,
> > > .res_ops = &exynos_res_ops_data,
> > > + .soc_variant = EXYNOS_5433,
> > > + .device_mode = DW_PCIE_RC_TYPE,
> > > };
> >
> > > static const struct of_device_id exynos_pcie_of_match[] = {
> > > @@ -449,6 +756,14 @@ static const struct of_device_id exynos_pcie_of_match[] = {
> > > .compatible = "samsung,exynos5433-pcie",
> > > .data = (void *) &exynos_5433_pcie_rc_pdata,
> > > },
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC
2025-07-01 11:33 ` Shradha Todi
@ 2025-07-01 17:16 ` Bjorn Helgaas
0 siblings, 0 replies; 30+ messages in thread
From: Bjorn Helgaas @ 2025-07-01 17:16 UTC (permalink / raw)
To: Shradha Todi
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw, robh,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
On Tue, Jul 01, 2025 at 05:03:31PM +0530, Shradha Todi wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@kernel.org>
> > Sent: 27 June 2025 22:00
> > On Wed, Jun 25, 2025 at 10:22:25PM +0530, Shradha Todi wrote:
> > > Document the PCIe controller device tree bindings for Tesla FSD
> > > SoC for both RC and EP.
> > > +++ b/Documentation/devicetree/bindings/pci/tesla,fsd-pcie-ep.yaml
> >
> > I'm not sure about the "tesla,fsd-pcie-ep.yaml" filename. I see that
> > it currently only describes a tesla endpoint, but it seems like maybe
> > this should be parallel to the "samsung,exynos-pcie.yaml" host
> > controller binding.
>
> Actually there is no support for Exynos5433 in EP mode. Initially I
> named the binding file "samsung,exynos-pcie-ep.yaml" to make it
> parallel to the host controller bindings. But I received a comment
> that file names should match the compatible strings which makes
> sense so I changed it to this.
Certainly makes sense to match the compatible strings, although
samsung,exynos-pcie.yaml now includes both:
samsung,exynos5433-pcie
tesla,fsd-pcie
Exynos5433 may not support EP mode, but I assume the underlying IP for
the Tesla FSD in EP mode is still Samsung, and I assume some Exynos
device may someday support EP mode.
But I see Krzysztof's suggestion that the filename match compatible
and also Rob's observation that there's not much shared between
samsung,exynos5433-pcie and tesla,fsd-pcie.
Maybe that means both the RC and EP bindings should be named
"tesla,fsd..." It seems a little weird that the same hardware would
be named described by either "samsung-exynos" or "tesla,fsd" just
depending on a mode switch.
Bjorn
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
2025-07-01 13:35 ` Shradha Todi
@ 2025-07-02 20:18 ` Krzysztof Kozlowski
2025-07-04 13:09 ` Pankaj Dubey
0 siblings, 1 reply; 30+ messages in thread
From: Krzysztof Kozlowski @ 2025-07-02 20:18 UTC (permalink / raw)
To: Shradha Todi, 'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung, pankaj.dubey
On 01/07/2025 15:35, Shradha Todi wrote:
>>> does not support auto adaptation so we need to tune the PHYs
>>> according to the use case (considering channel loss, etc). This is why we
>>
>> So not same? Decide. Either it is same or not, cannot be both.
>>
>> If you mean that some wiring is different on the board, then how does it
>> differ in soc thus how it is per-soc property? If these are use-cases,
>> then how is even suitable for DT?
>>
>> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
>>
>> You are no describing real problem and both binding and your
>> explanations are vague and imprecise. Binding tells nothing about it, so
>> it is example of skipping important decisions.
>>
>>> have 2 different SW PHY initialization sequence depending on the instance
>>> number. Do you think having different compatible (something like
>>> tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as platform data
>>> is okay in this case? I actually took reference from files like:
>>
>> And in different use case on same soc you are going to reverse
>> compatibles or instance IDs?
>>
>
> Even though both the PHYs are exactly identical in terms of hardware,
> they need to be programmed/initialized/configured differently.
>
> Sorry for my misuse of the word "use-case". To clarify, these configurations
> will always remain the same for FSD SoC even if you use it differently.
>
> I will use different compatibles for them as I understand that it is the best
> option.
I still do not see the difference in hardware explained.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
2025-07-02 20:18 ` Krzysztof Kozlowski
@ 2025-07-04 13:09 ` Pankaj Dubey
2025-07-05 7:47 ` Krzysztof Kozlowski
0 siblings, 1 reply; 30+ messages in thread
From: Pankaj Dubey @ 2025-07-04 13:09 UTC (permalink / raw)
To: 'Krzysztof Kozlowski', 'Shradha Todi',
'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, July 3, 2025 1:48 AM
> To: Shradha Todi <shradha.t@samsung.com>; 'Rob Herring'
> <robh@kernel.org>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-fsd@tesla.com;
> mani@kernel.org; lpieralisi@kernel.org; kw@linux.com;
> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org;
> conor+dt@kernel.org; alim.akhtar@samsung.com; vkoul@kernel.org;
> kishon@kernel.org; arnd@arndb.de; m.szyprowski@samsung.com;
> jh80.chung@samsung.com; pankaj.dubey@samsung.com
> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for
> FSD SoC
>
> On 01/07/2025 15:35, Shradha Todi wrote:
> >>> does not support auto adaptation so we need to tune the PHYs
> >>> according to the use case (considering channel loss, etc). This is
> >>> why we
> >>
> >> So not same? Decide. Either it is same or not, cannot be both.
> >>
> >> If you mean that some wiring is different on the board, then how does
> >> it differ in soc thus how it is per-soc property? If these are
> >> use-cases, then how is even suitable for DT?
> >>
> >> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
> >>
> >> You are no describing real problem and both binding and your
> >> explanations are vague and imprecise. Binding tells nothing about it,
> >> so it is example of skipping important decisions.
> >>
> >>> have 2 different SW PHY initialization sequence depending on the
> >>> instance number. Do you think having different compatible (something
> >>> like
> >>> tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as
> >>> platform data is okay in this case? I actually took reference from files like:
> >>
> >> And in different use case on same soc you are going to reverse
> >> compatibles or instance IDs?
> >>
> >
> > Even though both the PHYs are exactly identical in terms of hardware,
> > they need to be programmed/initialized/configured differently.
> >
> > Sorry for my misuse of the word "use-case". To clarify, these
> > configurations will always remain the same for FSD SoC even if you use it
> differently.
> >
> > I will use different compatibles for them as I understand that it is
> > the best option.
>
> I still do not see the difference in hardware explained.
>
Hi Krzysztof
Let me add more details and see if that makes sense to understand the intention
behind the current design of the PHY driver.
In FSD SoC, the two PHY instances, although having identical hardware design and
register maps, are placed in different locations (Placement and routing) inside the
SoC and have distinct PHY-to-Controller topologies.
One instance is connected to two PCIe controllers, while the other is connected to
only one. As a result, they experience different analog environments, including
varying channel losses and noise profiles.
Since these PHYs lack internal adaptation mechanisms and f/w based tuning,
manual register programming is required for analog tuning, such as equalization,
de-emphasis, and gain. To ensure optimal signal integrity, it is essential to use different
register values for each PHY instance, despite their identical hardware design.
This is because the same register values may not be suitable for both instances due to
their differing environments and topologies.
Do let us know if this explains the intention behind separate programming sequence
for both instance of the PHY?
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for FSD SoC
2025-07-04 13:09 ` Pankaj Dubey
@ 2025-07-05 7:47 ` Krzysztof Kozlowski
0 siblings, 0 replies; 30+ messages in thread
From: Krzysztof Kozlowski @ 2025-07-05 7:47 UTC (permalink / raw)
To: Pankaj Dubey, 'Shradha Todi', 'Rob Herring'
Cc: linux-pci, devicetree, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-phy, linux-fsd, mani, lpieralisi, kw,
bhelgaas, jingoohan1, krzk+dt, conor+dt, alim.akhtar, vkoul,
kishon, arnd, m.szyprowski, jh80.chung
On 04/07/2025 15:09, Pankaj Dubey wrote:
>
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Thursday, July 3, 2025 1:48 AM
>> To: Shradha Todi <shradha.t@samsung.com>; 'Rob Herring'
>> <robh@kernel.org>
>> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; linux-samsung-soc@vger.kernel.org; linux-
>> kernel@vger.kernel.org; linux-phy@lists.infradead.org; linux-fsd@tesla.com;
>> mani@kernel.org; lpieralisi@kernel.org; kw@linux.com;
>> bhelgaas@google.com; jingoohan1@gmail.com; krzk+dt@kernel.org;
>> conor+dt@kernel.org; alim.akhtar@samsung.com; vkoul@kernel.org;
>> kishon@kernel.org; arnd@arndb.de; m.szyprowski@samsung.com;
>> jh80.chung@samsung.com; pankaj.dubey@samsung.com
>> Subject: Re: [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for
>> FSD SoC
>>
>> On 01/07/2025 15:35, Shradha Todi wrote:
>>>>> does not support auto adaptation so we need to tune the PHYs
>>>>> according to the use case (considering channel loss, etc). This is
>>>>> why we
>>>>
>>>> So not same? Decide. Either it is same or not, cannot be both.
>>>>
>>>> If you mean that some wiring is different on the board, then how does
>>>> it differ in soc thus how it is per-soc property? If these are
>>>> use-cases, then how is even suitable for DT?
>>>>
>>>> I use your Tesla FSD differently and then I exchange DTSI and compatibles?
>>>>
>>>> You are no describing real problem and both binding and your
>>>> explanations are vague and imprecise. Binding tells nothing about it,
>>>> so it is example of skipping important decisions.
>>>>
>>>>> have 2 different SW PHY initialization sequence depending on the
>>>>> instance number. Do you think having different compatible (something
>>>>> like
>>>>> tesla,fsd-pcie-phy0 and tesla,fsd-pcie-phy1) and having phy ID as
>>>>> platform data is okay in this case? I actually took reference from files like:
>>>>
>>>> And in different use case on same soc you are going to reverse
>>>> compatibles or instance IDs?
>>>>
>>>
>>> Even though both the PHYs are exactly identical in terms of hardware,
>>> they need to be programmed/initialized/configured differently.
>>>
>>> Sorry for my misuse of the word "use-case". To clarify, these
>>> configurations will always remain the same for FSD SoC even if you use it
>> differently.
>>>
>>> I will use different compatibles for them as I understand that it is
>>> the best option.
>>
>> I still do not see the difference in hardware explained.
>>
>
> Hi Krzysztof
>
> Let me add more details and see if that makes sense to understand the intention
> behind the current design of the PHY driver.
>
> In FSD SoC, the two PHY instances, although having identical hardware design and
> register maps, are placed in different locations (Placement and routing) inside the
> SoC and have distinct PHY-to-Controller topologies.
>
> One instance is connected to two PCIe controllers, while the other is connected to
> only one. As a result, they experience different analog environments, including
> varying channel losses and noise profiles.
>
> Since these PHYs lack internal adaptation mechanisms and f/w based tuning,
> manual register programming is required for analog tuning, such as equalization,
> de-emphasis, and gain. To ensure optimal signal integrity, it is essential to use different
> register values for each PHY instance, despite their identical hardware design.
> This is because the same register values may not be suitable for both instances due to
> their differing environments and topologies.
>
> Do let us know if this explains the intention behind separate programming sequence
> for both instance of the PHY?
Thanks, it explains and it should be in binding description if you go
with different compatible, but you should first check if existing
properties do not describe these differences enough, e.g. num-lanes,
max-link-speed.
equalization has its own properties for example.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2025-07-05 7:55 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CGME20250625165241epcas5p471ca039a776513c4da7ee2a0955de5c2@epcas5p4.samsung.com>
2025-06-25 16:52 ` [PATCH v2 00/10] Add PCIe support for Tesla FSD SoC Shradha Todi
[not found] ` <CGME20250625165248epcas5p10eefe9e1f1a89806793c86decc63f232@epcas5p1.samsung.com>
2025-06-25 16:52 ` [PATCH v2 01/10] PCI: exynos: Remove unused MACROs in exynos PCI file Shradha Todi
[not found] ` <CGME20250625165253epcas5p1339d784e500ad629a64fb4aad792e79b@epcas5p1.samsung.com>
2025-06-25 16:52 ` [PATCH v2 02/10] PCI: exynos: Change macro names to exynos specific Shradha Todi
[not found] ` <CGME20250625165258epcas5p4ddbbcfa60703f3682b94ae4eb814da7e@epcas5p4.samsung.com>
2025-06-25 16:52 ` [PATCH v2 03/10] PCI: exynos: Reorder MACROs to maintain consistency Shradha Todi
[not found] ` <CGME20250625165305epcas5p31ee49285a57e2fb88a005ec1dfed4199@epcas5p3.samsung.com>
2025-06-25 16:52 ` [PATCH v2 04/10] PCI: exynos: Add platform device private data Shradha Todi
[not found] ` <CGME20250625165310epcas5p309194787ad2c6ac45da32240a8c86c28@epcas5p3.samsung.com>
2025-06-25 16:52 ` [PATCH v2 05/10] PCI: exynos: Add structure to hold resource operations Shradha Todi
[not found] ` <CGME20250625165315epcas5p19f081c8a0e2e7dc87698577cc2d460ca@epcas5p1.samsung.com>
2025-06-25 16:52 ` [PATCH v2 06/10] dt-bindings: PCI: Add bindings support for Tesla FSD SoC Shradha Todi
2025-06-27 16:29 ` Bjorn Helgaas
2025-07-01 11:33 ` Shradha Todi
2025-07-01 17:16 ` Bjorn Helgaas
2025-06-27 21:12 ` Rob Herring
2025-07-01 11:11 ` Shradha Todi
2025-07-01 11:20 ` Krzysztof Kozlowski
2025-07-01 13:38 ` Shradha Todi
[not found] ` <CGME20250625165319epcas5p3721c19f6e6b482438c62dd1ef784de03@epcas5p3.samsung.com>
2025-06-25 16:52 ` [PATCH v2 07/10] dt-bindings: phy: Add PHY bindings support for " Shradha Todi
2025-06-27 21:17 ` Rob Herring
2025-07-01 11:06 ` Shradha Todi
2025-07-01 11:25 ` Krzysztof Kozlowski
2025-07-01 13:35 ` Shradha Todi
2025-07-02 20:18 ` Krzysztof Kozlowski
2025-07-04 13:09 ` Pankaj Dubey
2025-07-05 7:47 ` Krzysztof Kozlowski
[not found] ` <CGME20250625165323epcas5p44d291cb0b46df7e015907e4c2903447f@epcas5p4.samsung.com>
2025-06-25 16:52 ` [PATCH v2 08/10] phy: exynos: Add PCIe PHY " Shradha Todi
2025-06-26 23:09 ` Vinod Koul
[not found] ` <CGME20250625165327epcas5p2c51b6032a6439cd1a7a884b360be1354@epcas5p2.samsung.com>
2025-06-25 16:52 ` [PATCH v2 09/10] PCI: exynos: Add support for Tesla " Shradha Todi
2025-06-27 19:30 ` Bjorn Helgaas
2025-07-01 11:18 ` Shradha Todi
2025-07-01 16:57 ` Bjorn Helgaas
2025-06-30 16:26 ` Dan Carpenter
[not found] ` <CGME20250625165332epcas5p4e138b7f7c8ebb938dc526c5dc29412bb@epcas5p4.samsung.com>
2025-06-25 16:52 ` [PATCH v2 10/10] arm64: dts: fsd: Add PCIe " Shradha Todi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).