* [PATCH v20 01/19] PCI: Add INTx Mechanism Messages macros
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 02/19] PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu() Yoshihiro Shimoda
` (19 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Add "Message Routing" and "INTx Mechanism Messages" macros to enable
a PCIe driver to send messages for INTx Interrupt Signaling.
The "Message Routing" is from Table 2-17, and the "INTx Mechanism
Messages" is from Table 2-18 on the PCI Express Base Specification,
Rev. 4.0 Version 1.0.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/pci/pci.h | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 83778dc1615d..99231fa7dcfc 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -19,6 +19,24 @@
*/
#define PCIE_PME_TO_L2_TIMEOUT_US 10000
+/* Message Routing (r[2:0]) */
+#define PCI_MSG_TYPE_R_RC 0
+#define PCI_MSG_TYPE_R_ADDR 1
+#define PCI_MSG_TYPE_R_ID 2
+#define PCI_MSG_TYPE_R_BC 3
+#define PCI_MSG_TYPE_R_LOCAL 4
+#define PCI_MSG_TYPE_R_GATHER 5
+
+/* INTx Mechanism Messages */
+#define PCI_MSG_CODE_ASSERT_INTA 0x20
+#define PCI_MSG_CODE_ASSERT_INTB 0x21
+#define PCI_MSG_CODE_ASSERT_INTC 0x22
+#define PCI_MSG_CODE_ASSERT_INTD 0x23
+#define PCI_MSG_CODE_DEASSERT_INTA 0x24
+#define PCI_MSG_CODE_DEASSERT_INTB 0x25
+#define PCI_MSG_CODE_DEASSERT_INTC 0x26
+#define PCI_MSG_CODE_DEASSERT_INTD 0x27
+
extern const unsigned char pcie_link_speed[];
extern bool pci_early_dump;
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 02/19] PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 01/19] PCI: Add INTx Mechanism Messages macros Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2024-01-29 22:42 ` Frank Li
2023-08-25 9:32 ` [PATCH v20 03/19] PCI: dwc: Add outbound MSG TLPs support Yoshihiro Shimoda
` (18 subsequent siblings)
20 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
This is a preparation before adding the Msg-type outbound iATU
mapping. The respective update will require two more arguments added
to __dw_pcie_prog_outbound_atu(). That will make the already
complicated function prototype even more hard to comprehend accepting
_eight_ arguments. In order to prevent that and keep the code
more-or-less readable all the outbound iATU-related arguments are
moved to the new config-structure: struct dw_pcie_ob_atu_cfg pointer
to which shall be passed to dw_pcie_prog_outbound_atu(). The structure
is supposed to be locally defined and populated with the outbound iATU
settings implied by the caller context.
As a result of the denoted change there is no longer need in having
the two distinctive methods for the Host and End-point outbound iATU
setups since the corresponding code can directly call the
dw_pcie_prog_outbound_atu() method with the config-structure
populated. Thus dw_pcie_prog_ep_outbound_atu() is dropped.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
.../pci/controller/dwc/pcie-designware-ep.c | 21 +++++---
.../pci/controller/dwc/pcie-designware-host.c | 52 +++++++++++++------
drivers/pci/controller/dwc/pcie-designware.c | 49 ++++++-----------
drivers/pci/controller/dwc/pcie-designware.h | 15 ++++--
4 files changed, 77 insertions(+), 60 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index ab87ea3b0986..747d5bc07222 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -182,9 +182,8 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no, int type,
return 0;
}
-static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
- phys_addr_t phys_addr,
- u64 pci_addr, size_t size)
+static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep,
+ struct dw_pcie_ob_atu_cfg *atu)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
u32 free_win;
@@ -196,13 +195,13 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
return -EINVAL;
}
- ret = dw_pcie_prog_ep_outbound_atu(pci, func_no, free_win, PCIE_ATU_TYPE_MEM,
- phys_addr, pci_addr, size);
+ atu->index = free_win;
+ ret = dw_pcie_prog_outbound_atu(pci, atu);
if (ret)
return ret;
set_bit(free_win, ep->ob_window_map);
- ep->outbound_addr[free_win] = phys_addr;
+ ep->outbound_addr[free_win] = atu->cpu_addr;
return 0;
}
@@ -305,8 +304,14 @@ static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
int ret;
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
-
- ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
+ struct dw_pcie_ob_atu_cfg atu = { 0 };
+
+ atu.func_no = func_no;
+ atu.type = PCIE_ATU_TYPE_MEM;
+ atu.cpu_addr = addr;
+ atu.pci_addr = pci_addr;
+ atu.size = size;
+ ret = dw_pcie_ep_outbound_atu(ep, &atu);
if (ret) {
dev_err(pci->dev, "Failed to enable address\n");
return ret;
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
index 5c8cbc3afae4..01eff83c1f6d 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -551,6 +551,7 @@ static void __iomem *dw_pcie_other_conf_map_bus(struct pci_bus *bus,
{
struct dw_pcie_rp *pp = bus->sysdata;
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct dw_pcie_ob_atu_cfg atu = { 0 };
int type, ret;
u32 busdev;
@@ -573,8 +574,12 @@ static void __iomem *dw_pcie_other_conf_map_bus(struct pci_bus *bus,
else
type = PCIE_ATU_TYPE_CFG1;
- ret = dw_pcie_prog_outbound_atu(pci, 0, type, pp->cfg0_base, busdev,
- pp->cfg0_size);
+ atu.type = type;
+ atu.cpu_addr = pp->cfg0_base;
+ atu.pci_addr = busdev;
+ atu.size = pp->cfg0_size;
+
+ ret = dw_pcie_prog_outbound_atu(pci, &atu);
if (ret)
return NULL;
@@ -586,6 +591,7 @@ static int dw_pcie_rd_other_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie_rp *pp = bus->sysdata;
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct dw_pcie_ob_atu_cfg atu = { 0 };
int ret;
ret = pci_generic_config_read(bus, devfn, where, size, val);
@@ -593,9 +599,12 @@ static int dw_pcie_rd_other_conf(struct pci_bus *bus, unsigned int devfn,
return ret;
if (pp->cfg0_io_shared) {
- ret = dw_pcie_prog_outbound_atu(pci, 0, PCIE_ATU_TYPE_IO,
- pp->io_base, pp->io_bus_addr,
- pp->io_size);
+ atu.type = PCIE_ATU_TYPE_IO;
+ atu.cpu_addr = pp->io_base;
+ atu.pci_addr = pp->io_bus_addr;
+ atu.size = pp->io_size;
+
+ ret = dw_pcie_prog_outbound_atu(pci, &atu);
if (ret)
return PCIBIOS_SET_FAILED;
}
@@ -608,6 +617,7 @@ static int dw_pcie_wr_other_conf(struct pci_bus *bus, unsigned int devfn,
{
struct dw_pcie_rp *pp = bus->sysdata;
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct dw_pcie_ob_atu_cfg atu = { 0 };
int ret;
ret = pci_generic_config_write(bus, devfn, where, size, val);
@@ -615,9 +625,12 @@ static int dw_pcie_wr_other_conf(struct pci_bus *bus, unsigned int devfn,
return ret;
if (pp->cfg0_io_shared) {
- ret = dw_pcie_prog_outbound_atu(pci, 0, PCIE_ATU_TYPE_IO,
- pp->io_base, pp->io_bus_addr,
- pp->io_size);
+ atu.type = PCIE_ATU_TYPE_IO;
+ atu.cpu_addr = pp->io_base;
+ atu.pci_addr = pp->io_bus_addr;
+ atu.size = pp->io_size;
+
+ ret = dw_pcie_prog_outbound_atu(pci, &atu);
if (ret)
return PCIBIOS_SET_FAILED;
}
@@ -652,6 +665,7 @@ static struct pci_ops dw_pcie_ops = {
static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
{
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct dw_pcie_ob_atu_cfg atu = { 0 };
struct resource_entry *entry;
int i, ret;
@@ -679,10 +693,13 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
if (pci->num_ob_windows <= ++i)
break;
- ret = dw_pcie_prog_outbound_atu(pci, i, PCIE_ATU_TYPE_MEM,
- entry->res->start,
- entry->res->start - entry->offset,
- resource_size(entry->res));
+ atu.index = i;
+ atu.type = PCIE_ATU_TYPE_MEM;
+ atu.cpu_addr = entry->res->start;
+ atu.pci_addr = entry->res->start - entry->offset;
+ atu.size = resource_size(entry->res);
+
+ ret = dw_pcie_prog_outbound_atu(pci, &atu);
if (ret) {
dev_err(pci->dev, "Failed to set MEM range %pr\n",
entry->res);
@@ -692,10 +709,13 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
if (pp->io_size) {
if (pci->num_ob_windows > ++i) {
- ret = dw_pcie_prog_outbound_atu(pci, i, PCIE_ATU_TYPE_IO,
- pp->io_base,
- pp->io_bus_addr,
- pp->io_size);
+ atu.index = i;
+ atu.type = PCIE_ATU_TYPE_IO;
+ atu.cpu_addr = pp->io_base;
+ atu.pci_addr = pp->io_bus_addr;
+ atu.size = pp->io_size;
+
+ ret = dw_pcie_prog_outbound_atu(pci, &atu);
if (ret) {
dev_err(pci->dev, "Failed to set IO range %pr\n",
entry->res);
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index 2459f2a61b9b..49b785509576 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -464,56 +464,56 @@ static inline u32 dw_pcie_enable_ecrc(u32 val)
return val | PCIE_ATU_TD;
}
-static int __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no,
- int index, int type, u64 cpu_addr,
- u64 pci_addr, u64 size)
+int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
+ const struct dw_pcie_ob_atu_cfg *atu)
{
+ u64 cpu_addr = atu->cpu_addr;
u32 retries, val;
u64 limit_addr;
if (pci->ops && pci->ops->cpu_addr_fixup)
cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
- limit_addr = cpu_addr + size - 1;
+ limit_addr = cpu_addr + atu->size - 1;
if ((limit_addr & ~pci->region_limit) != (cpu_addr & ~pci->region_limit) ||
!IS_ALIGNED(cpu_addr, pci->region_align) ||
- !IS_ALIGNED(pci_addr, pci->region_align) || !size) {
+ !IS_ALIGNED(atu->pci_addr, pci->region_align) || !atu->size) {
return -EINVAL;
}
- dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LOWER_BASE,
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LOWER_BASE,
lower_32_bits(cpu_addr));
- dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_BASE,
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_BASE,
upper_32_bits(cpu_addr));
- dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LIMIT,
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LIMIT,
lower_32_bits(limit_addr));
if (dw_pcie_ver_is_ge(pci, 460A))
- dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_LIMIT,
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_LIMIT,
upper_32_bits(limit_addr));
- dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LOWER_TARGET,
- lower_32_bits(pci_addr));
- dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_TARGET,
- upper_32_bits(pci_addr));
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LOWER_TARGET,
+ lower_32_bits(atu->pci_addr));
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_TARGET,
+ upper_32_bits(atu->pci_addr));
- val = type | PCIE_ATU_FUNC_NUM(func_no);
+ val = atu->type | PCIE_ATU_FUNC_NUM(atu->func_no);
if (upper_32_bits(limit_addr) > upper_32_bits(cpu_addr) &&
dw_pcie_ver_is_ge(pci, 460A))
val |= PCIE_ATU_INCREASE_REGION_SIZE;
if (dw_pcie_ver_is(pci, 490A))
val = dw_pcie_enable_ecrc(val);
- dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_REGION_CTRL1, val);
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
- dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_REGION_CTRL2, PCIE_ATU_ENABLE);
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2, PCIE_ATU_ENABLE);
/*
* Make sure ATU enable takes effect before any subsequent config
* and I/O accesses.
*/
for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
- val = dw_pcie_readl_atu_ob(pci, index, PCIE_ATU_REGION_CTRL2);
+ val = dw_pcie_readl_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2);
if (val & PCIE_ATU_ENABLE)
return 0;
@@ -525,21 +525,6 @@ static int __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no,
return -ETIMEDOUT;
}
-int dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
- u64 cpu_addr, u64 pci_addr, u64 size)
-{
- return __dw_pcie_prog_outbound_atu(pci, 0, index, type,
- cpu_addr, pci_addr, size);
-}
-
-int dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int index,
- int type, u64 cpu_addr, u64 pci_addr,
- u64 size)
-{
- return __dw_pcie_prog_outbound_atu(pci, func_no, index, type,
- cpu_addr, pci_addr, size);
-}
-
static inline u32 dw_pcie_readl_atu_ib(struct dw_pcie *pci, u32 index, u32 reg)
{
return dw_pcie_readl_atu(pci, PCIE_ATU_REGION_DIR_IB, index, reg);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 755bcb406769..296c5b1ddc91 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -298,6 +298,15 @@ enum dw_pcie_ltssm {
DW_PCIE_LTSSM_UNKNOWN = 0xFFFFFFFF,
};
+struct dw_pcie_ob_atu_cfg {
+ int index;
+ int type;
+ u8 func_no;
+ u64 cpu_addr;
+ u64 pci_addr;
+ u64 size;
+};
+
struct dw_pcie_host_ops {
int (*host_init)(struct dw_pcie_rp *pp);
void (*host_deinit)(struct dw_pcie_rp *pp);
@@ -429,10 +438,8 @@ void dw_pcie_write_dbi2(struct dw_pcie *pci, u32 reg, size_t size, u32 val);
int dw_pcie_link_up(struct dw_pcie *pci);
void dw_pcie_upconfig_setup(struct dw_pcie *pci);
int dw_pcie_wait_for_link(struct dw_pcie *pci);
-int dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
- u64 cpu_addr, u64 pci_addr, u64 size);
-int dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int index,
- int type, u64 cpu_addr, u64 pci_addr, u64 size);
+int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
+ const struct dw_pcie_ob_atu_cfg *atu);
int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int type,
u64 cpu_addr, u64 pci_addr, u64 size);
int dw_pcie_prog_ep_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 02/19] PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
2023-08-25 9:32 ` [PATCH v20 02/19] PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu() Yoshihiro Shimoda
@ 2024-01-29 22:42 ` Frank Li
2024-01-30 0:46 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Frank Li @ 2024-01-29 22:42 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc
On Fri, Aug 25, 2023 at 06:32:02PM +0900, Yoshihiro Shimoda wrote:
> This is a preparation before adding the Msg-type outbound iATU
> mapping. The respective update will require two more arguments added
> to __dw_pcie_prog_outbound_atu(). That will make the already
> complicated function prototype even more hard to comprehend accepting
> _eight_ arguments. In order to prevent that and keep the code
> more-or-less readable all the outbound iATU-related arguments are
> moved to the new config-structure: struct dw_pcie_ob_atu_cfg pointer
> to which shall be passed to dw_pcie_prog_outbound_atu(). The structure
> is supposed to be locally defined and populated with the outbound iATU
> settings implied by the caller context.
>
> As a result of the denoted change there is no longer need in having
> the two distinctive methods for the Host and End-point outbound iATU
> setups since the corresponding code can directly call the
> dw_pcie_prog_outbound_atu() method with the config-structure
> populated. Thus dw_pcie_prog_ep_outbound_atu() is dropped.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Yoshihiro:
I want to use this patch to send out PME message when suspend,
which should be similar with raise INTx. Can I include your this patches in
my PME enable patches list if your patch still not merge yet.
Frank
> ---
> .../pci/controller/dwc/pcie-designware-ep.c | 21 +++++---
> .../pci/controller/dwc/pcie-designware-host.c | 52 +++++++++++++------
> drivers/pci/controller/dwc/pcie-designware.c | 49 ++++++-----------
> drivers/pci/controller/dwc/pcie-designware.h | 15 ++++--
> 4 files changed, 77 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index ab87ea3b0986..747d5bc07222 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -182,9 +182,8 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no, int type,
> return 0;
> }
>
> -static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> - phys_addr_t phys_addr,
> - u64 pci_addr, size_t size)
> +static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep,
> + struct dw_pcie_ob_atu_cfg *atu)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> u32 free_win;
> @@ -196,13 +195,13 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> return -EINVAL;
> }
>
> - ret = dw_pcie_prog_ep_outbound_atu(pci, func_no, free_win, PCIE_ATU_TYPE_MEM,
> - phys_addr, pci_addr, size);
> + atu->index = free_win;
> + ret = dw_pcie_prog_outbound_atu(pci, atu);
> if (ret)
> return ret;
>
> set_bit(free_win, ep->ob_window_map);
> - ep->outbound_addr[free_win] = phys_addr;
> + ep->outbound_addr[free_win] = atu->cpu_addr;
>
> return 0;
> }
> @@ -305,8 +304,14 @@ static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> int ret;
> struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> -
> - ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
> + struct dw_pcie_ob_atu_cfg atu = { 0 };
> +
> + atu.func_no = func_no;
> + atu.type = PCIE_ATU_TYPE_MEM;
> + atu.cpu_addr = addr;
> + atu.pci_addr = pci_addr;
> + atu.size = size;
> + ret = dw_pcie_ep_outbound_atu(ep, &atu);
> if (ret) {
> dev_err(pci->dev, "Failed to enable address\n");
> return ret;
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 5c8cbc3afae4..01eff83c1f6d 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -551,6 +551,7 @@ static void __iomem *dw_pcie_other_conf_map_bus(struct pci_bus *bus,
> {
> struct dw_pcie_rp *pp = bus->sysdata;
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct dw_pcie_ob_atu_cfg atu = { 0 };
> int type, ret;
> u32 busdev;
>
> @@ -573,8 +574,12 @@ static void __iomem *dw_pcie_other_conf_map_bus(struct pci_bus *bus,
> else
> type = PCIE_ATU_TYPE_CFG1;
>
> - ret = dw_pcie_prog_outbound_atu(pci, 0, type, pp->cfg0_base, busdev,
> - pp->cfg0_size);
> + atu.type = type;
> + atu.cpu_addr = pp->cfg0_base;
> + atu.pci_addr = busdev;
> + atu.size = pp->cfg0_size;
> +
> + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> if (ret)
> return NULL;
>
> @@ -586,6 +591,7 @@ static int dw_pcie_rd_other_conf(struct pci_bus *bus, unsigned int devfn,
> {
> struct dw_pcie_rp *pp = bus->sysdata;
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct dw_pcie_ob_atu_cfg atu = { 0 };
> int ret;
>
> ret = pci_generic_config_read(bus, devfn, where, size, val);
> @@ -593,9 +599,12 @@ static int dw_pcie_rd_other_conf(struct pci_bus *bus, unsigned int devfn,
> return ret;
>
> if (pp->cfg0_io_shared) {
> - ret = dw_pcie_prog_outbound_atu(pci, 0, PCIE_ATU_TYPE_IO,
> - pp->io_base, pp->io_bus_addr,
> - pp->io_size);
> + atu.type = PCIE_ATU_TYPE_IO;
> + atu.cpu_addr = pp->io_base;
> + atu.pci_addr = pp->io_bus_addr;
> + atu.size = pp->io_size;
> +
> + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> if (ret)
> return PCIBIOS_SET_FAILED;
> }
> @@ -608,6 +617,7 @@ static int dw_pcie_wr_other_conf(struct pci_bus *bus, unsigned int devfn,
> {
> struct dw_pcie_rp *pp = bus->sysdata;
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct dw_pcie_ob_atu_cfg atu = { 0 };
> int ret;
>
> ret = pci_generic_config_write(bus, devfn, where, size, val);
> @@ -615,9 +625,12 @@ static int dw_pcie_wr_other_conf(struct pci_bus *bus, unsigned int devfn,
> return ret;
>
> if (pp->cfg0_io_shared) {
> - ret = dw_pcie_prog_outbound_atu(pci, 0, PCIE_ATU_TYPE_IO,
> - pp->io_base, pp->io_bus_addr,
> - pp->io_size);
> + atu.type = PCIE_ATU_TYPE_IO;
> + atu.cpu_addr = pp->io_base;
> + atu.pci_addr = pp->io_bus_addr;
> + atu.size = pp->io_size;
> +
> + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> if (ret)
> return PCIBIOS_SET_FAILED;
> }
> @@ -652,6 +665,7 @@ static struct pci_ops dw_pcie_ops = {
> static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> {
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct dw_pcie_ob_atu_cfg atu = { 0 };
> struct resource_entry *entry;
> int i, ret;
>
> @@ -679,10 +693,13 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> if (pci->num_ob_windows <= ++i)
> break;
>
> - ret = dw_pcie_prog_outbound_atu(pci, i, PCIE_ATU_TYPE_MEM,
> - entry->res->start,
> - entry->res->start - entry->offset,
> - resource_size(entry->res));
> + atu.index = i;
> + atu.type = PCIE_ATU_TYPE_MEM;
> + atu.cpu_addr = entry->res->start;
> + atu.pci_addr = entry->res->start - entry->offset;
> + atu.size = resource_size(entry->res);
> +
> + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> if (ret) {
> dev_err(pci->dev, "Failed to set MEM range %pr\n",
> entry->res);
> @@ -692,10 +709,13 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
>
> if (pp->io_size) {
> if (pci->num_ob_windows > ++i) {
> - ret = dw_pcie_prog_outbound_atu(pci, i, PCIE_ATU_TYPE_IO,
> - pp->io_base,
> - pp->io_bus_addr,
> - pp->io_size);
> + atu.index = i;
> + atu.type = PCIE_ATU_TYPE_IO;
> + atu.cpu_addr = pp->io_base;
> + atu.pci_addr = pp->io_bus_addr;
> + atu.size = pp->io_size;
> +
> + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> if (ret) {
> dev_err(pci->dev, "Failed to set IO range %pr\n",
> entry->res);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index 2459f2a61b9b..49b785509576 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -464,56 +464,56 @@ static inline u32 dw_pcie_enable_ecrc(u32 val)
> return val | PCIE_ATU_TD;
> }
>
> -static int __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no,
> - int index, int type, u64 cpu_addr,
> - u64 pci_addr, u64 size)
> +int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
> + const struct dw_pcie_ob_atu_cfg *atu)
> {
> + u64 cpu_addr = atu->cpu_addr;
> u32 retries, val;
> u64 limit_addr;
>
> if (pci->ops && pci->ops->cpu_addr_fixup)
> cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
>
> - limit_addr = cpu_addr + size - 1;
> + limit_addr = cpu_addr + atu->size - 1;
>
> if ((limit_addr & ~pci->region_limit) != (cpu_addr & ~pci->region_limit) ||
> !IS_ALIGNED(cpu_addr, pci->region_align) ||
> - !IS_ALIGNED(pci_addr, pci->region_align) || !size) {
> + !IS_ALIGNED(atu->pci_addr, pci->region_align) || !atu->size) {
> return -EINVAL;
> }
>
> - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LOWER_BASE,
> + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LOWER_BASE,
> lower_32_bits(cpu_addr));
> - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_BASE,
> + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_BASE,
> upper_32_bits(cpu_addr));
>
> - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LIMIT,
> + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LIMIT,
> lower_32_bits(limit_addr));
> if (dw_pcie_ver_is_ge(pci, 460A))
> - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_LIMIT,
> + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_LIMIT,
> upper_32_bits(limit_addr));
>
> - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LOWER_TARGET,
> - lower_32_bits(pci_addr));
> - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_TARGET,
> - upper_32_bits(pci_addr));
> + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LOWER_TARGET,
> + lower_32_bits(atu->pci_addr));
> + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_TARGET,
> + upper_32_bits(atu->pci_addr));
>
> - val = type | PCIE_ATU_FUNC_NUM(func_no);
> + val = atu->type | PCIE_ATU_FUNC_NUM(atu->func_no);
> if (upper_32_bits(limit_addr) > upper_32_bits(cpu_addr) &&
> dw_pcie_ver_is_ge(pci, 460A))
> val |= PCIE_ATU_INCREASE_REGION_SIZE;
> if (dw_pcie_ver_is(pci, 490A))
> val = dw_pcie_enable_ecrc(val);
> - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_REGION_CTRL1, val);
> + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
>
> - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_REGION_CTRL2, PCIE_ATU_ENABLE);
> + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2, PCIE_ATU_ENABLE);
>
> /*
> * Make sure ATU enable takes effect before any subsequent config
> * and I/O accesses.
> */
> for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
> - val = dw_pcie_readl_atu_ob(pci, index, PCIE_ATU_REGION_CTRL2);
> + val = dw_pcie_readl_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2);
> if (val & PCIE_ATU_ENABLE)
> return 0;
>
> @@ -525,21 +525,6 @@ static int __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no,
> return -ETIMEDOUT;
> }
>
> -int dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> - u64 cpu_addr, u64 pci_addr, u64 size)
> -{
> - return __dw_pcie_prog_outbound_atu(pci, 0, index, type,
> - cpu_addr, pci_addr, size);
> -}
> -
> -int dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> - int type, u64 cpu_addr, u64 pci_addr,
> - u64 size)
> -{
> - return __dw_pcie_prog_outbound_atu(pci, func_no, index, type,
> - cpu_addr, pci_addr, size);
> -}
> -
> static inline u32 dw_pcie_readl_atu_ib(struct dw_pcie *pci, u32 index, u32 reg)
> {
> return dw_pcie_readl_atu(pci, PCIE_ATU_REGION_DIR_IB, index, reg);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 755bcb406769..296c5b1ddc91 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -298,6 +298,15 @@ enum dw_pcie_ltssm {
> DW_PCIE_LTSSM_UNKNOWN = 0xFFFFFFFF,
> };
>
> +struct dw_pcie_ob_atu_cfg {
> + int index;
> + int type;
> + u8 func_no;
> + u64 cpu_addr;
> + u64 pci_addr;
> + u64 size;
> +};
> +
> struct dw_pcie_host_ops {
> int (*host_init)(struct dw_pcie_rp *pp);
> void (*host_deinit)(struct dw_pcie_rp *pp);
> @@ -429,10 +438,8 @@ void dw_pcie_write_dbi2(struct dw_pcie *pci, u32 reg, size_t size, u32 val);
> int dw_pcie_link_up(struct dw_pcie *pci);
> void dw_pcie_upconfig_setup(struct dw_pcie *pci);
> int dw_pcie_wait_for_link(struct dw_pcie *pci);
> -int dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> - u64 cpu_addr, u64 pci_addr, u64 size);
> -int dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> - int type, u64 cpu_addr, u64 pci_addr, u64 size);
> +int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
> + const struct dw_pcie_ob_atu_cfg *atu);
> int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int type,
> u64 cpu_addr, u64 pci_addr, u64 size);
> int dw_pcie_prog_ep_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 02/19] PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
2024-01-29 22:42 ` Frank Li
@ 2024-01-30 0:46 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2024-01-30 0:46 UTC (permalink / raw)
To: Frank Li
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
> From: Frank Li, Sent: Tuesday, January 30, 2024 7:42 AM
>
> On Fri, Aug 25, 2023 at 06:32:02PM +0900, Yoshihiro Shimoda wrote:
> > This is a preparation before adding the Msg-type outbound iATU
> > mapping. The respective update will require two more arguments added
> > to __dw_pcie_prog_outbound_atu(). That will make the already
> > complicated function prototype even more hard to comprehend accepting
> > _eight_ arguments. In order to prevent that and keep the code
> > more-or-less readable all the outbound iATU-related arguments are
> > moved to the new config-structure: struct dw_pcie_ob_atu_cfg pointer
> > to which shall be passed to dw_pcie_prog_outbound_atu(). The structure
> > is supposed to be locally defined and populated with the outbound iATU
> > settings implied by the caller context.
> >
> > As a result of the denoted change there is no longer need in having
> > the two distinctive methods for the Host and End-point outbound iATU
> > setups since the corresponding code can directly call the
> > dw_pcie_prog_outbound_atu() method with the config-structure
> > populated. Thus dw_pcie_prog_ep_outbound_atu() is dropped.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> Yoshihiro:
>
> I want to use this patch to send out PME message when suspend,
> which should be similar with raise INTx. Can I include your this patches in
> my PME enable patches list if your patch still not merge yet.
Sure!
This patch is not merged yet because INTx support requires framework modification
and this INTx support is not mandatory for my environment [1].
[1]
https://lore.kernel.org/all/TYBPR01MB534141F4F7B419BFE473D9B5D8FAA@TYBPR01MB5341.jpnprd01.prod.outlook.com/
Best regards,
Yoshihiro Shimoda
> Frank
>
> > ---
> > .../pci/controller/dwc/pcie-designware-ep.c | 21 +++++---
> > .../pci/controller/dwc/pcie-designware-host.c | 52 +++++++++++++------
> > drivers/pci/controller/dwc/pcie-designware.c | 49 ++++++-----------
> > drivers/pci/controller/dwc/pcie-designware.h | 15 ++++--
> > 4 files changed, 77 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index ab87ea3b0986..747d5bc07222 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -182,9 +182,8 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep, u8 func_no, int type,
> > return 0;
> > }
> >
> > -static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> > - phys_addr_t phys_addr,
> > - u64 pci_addr, size_t size)
> > +static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep,
> > + struct dw_pcie_ob_atu_cfg *atu)
> > {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 free_win;
> > @@ -196,13 +195,13 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep, u8 func_no,
> > return -EINVAL;
> > }
> >
> > - ret = dw_pcie_prog_ep_outbound_atu(pci, func_no, free_win, PCIE_ATU_TYPE_MEM,
> > - phys_addr, pci_addr, size);
> > + atu->index = free_win;
> > + ret = dw_pcie_prog_outbound_atu(pci, atu);
> > if (ret)
> > return ret;
> >
> > set_bit(free_win, ep->ob_window_map);
> > - ep->outbound_addr[free_win] = phys_addr;
> > + ep->outbound_addr[free_win] = atu->cpu_addr;
> >
> > return 0;
> > }
> > @@ -305,8 +304,14 @@ static int dw_pcie_ep_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> > int ret;
> > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > -
> > - ret = dw_pcie_ep_outbound_atu(ep, func_no, addr, pci_addr, size);
> > + struct dw_pcie_ob_atu_cfg atu = { 0 };
> > +
> > + atu.func_no = func_no;
> > + atu.type = PCIE_ATU_TYPE_MEM;
> > + atu.cpu_addr = addr;
> > + atu.pci_addr = pci_addr;
> > + atu.size = size;
> > + ret = dw_pcie_ep_outbound_atu(ep, &atu);
> > if (ret) {
> > dev_err(pci->dev, "Failed to enable address\n");
> > return ret;
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c b/drivers/pci/controller/dwc/pcie-designware-host.c
> > index 5c8cbc3afae4..01eff83c1f6d 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > @@ -551,6 +551,7 @@ static void __iomem *dw_pcie_other_conf_map_bus(struct pci_bus *bus,
> > {
> > struct dw_pcie_rp *pp = bus->sysdata;
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > + struct dw_pcie_ob_atu_cfg atu = { 0 };
> > int type, ret;
> > u32 busdev;
> >
> > @@ -573,8 +574,12 @@ static void __iomem *dw_pcie_other_conf_map_bus(struct pci_bus *bus,
> > else
> > type = PCIE_ATU_TYPE_CFG1;
> >
> > - ret = dw_pcie_prog_outbound_atu(pci, 0, type, pp->cfg0_base, busdev,
> > - pp->cfg0_size);
> > + atu.type = type;
> > + atu.cpu_addr = pp->cfg0_base;
> > + atu.pci_addr = busdev;
> > + atu.size = pp->cfg0_size;
> > +
> > + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> > if (ret)
> > return NULL;
> >
> > @@ -586,6 +591,7 @@ static int dw_pcie_rd_other_conf(struct pci_bus *bus, unsigned int devfn,
> > {
> > struct dw_pcie_rp *pp = bus->sysdata;
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > + struct dw_pcie_ob_atu_cfg atu = { 0 };
> > int ret;
> >
> > ret = pci_generic_config_read(bus, devfn, where, size, val);
> > @@ -593,9 +599,12 @@ static int dw_pcie_rd_other_conf(struct pci_bus *bus, unsigned int devfn,
> > return ret;
> >
> > if (pp->cfg0_io_shared) {
> > - ret = dw_pcie_prog_outbound_atu(pci, 0, PCIE_ATU_TYPE_IO,
> > - pp->io_base, pp->io_bus_addr,
> > - pp->io_size);
> > + atu.type = PCIE_ATU_TYPE_IO;
> > + atu.cpu_addr = pp->io_base;
> > + atu.pci_addr = pp->io_bus_addr;
> > + atu.size = pp->io_size;
> > +
> > + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> > if (ret)
> > return PCIBIOS_SET_FAILED;
> > }
> > @@ -608,6 +617,7 @@ static int dw_pcie_wr_other_conf(struct pci_bus *bus, unsigned int devfn,
> > {
> > struct dw_pcie_rp *pp = bus->sysdata;
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > + struct dw_pcie_ob_atu_cfg atu = { 0 };
> > int ret;
> >
> > ret = pci_generic_config_write(bus, devfn, where, size, val);
> > @@ -615,9 +625,12 @@ static int dw_pcie_wr_other_conf(struct pci_bus *bus, unsigned int devfn,
> > return ret;
> >
> > if (pp->cfg0_io_shared) {
> > - ret = dw_pcie_prog_outbound_atu(pci, 0, PCIE_ATU_TYPE_IO,
> > - pp->io_base, pp->io_bus_addr,
> > - pp->io_size);
> > + atu.type = PCIE_ATU_TYPE_IO;
> > + atu.cpu_addr = pp->io_base;
> > + atu.pci_addr = pp->io_bus_addr;
> > + atu.size = pp->io_size;
> > +
> > + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> > if (ret)
> > return PCIBIOS_SET_FAILED;
> > }
> > @@ -652,6 +665,7 @@ static struct pci_ops dw_pcie_ops = {
> > static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> > {
> > struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > + struct dw_pcie_ob_atu_cfg atu = { 0 };
> > struct resource_entry *entry;
> > int i, ret;
> >
> > @@ -679,10 +693,13 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> > if (pci->num_ob_windows <= ++i)
> > break;
> >
> > - ret = dw_pcie_prog_outbound_atu(pci, i, PCIE_ATU_TYPE_MEM,
> > - entry->res->start,
> > - entry->res->start - entry->offset,
> > - resource_size(entry->res));
> > + atu.index = i;
> > + atu.type = PCIE_ATU_TYPE_MEM;
> > + atu.cpu_addr = entry->res->start;
> > + atu.pci_addr = entry->res->start - entry->offset;
> > + atu.size = resource_size(entry->res);
> > +
> > + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> > if (ret) {
> > dev_err(pci->dev, "Failed to set MEM range %pr\n",
> > entry->res);
> > @@ -692,10 +709,13 @@ static int dw_pcie_iatu_setup(struct dw_pcie_rp *pp)
> >
> > if (pp->io_size) {
> > if (pci->num_ob_windows > ++i) {
> > - ret = dw_pcie_prog_outbound_atu(pci, i, PCIE_ATU_TYPE_IO,
> > - pp->io_base,
> > - pp->io_bus_addr,
> > - pp->io_size);
> > + atu.index = i;
> > + atu.type = PCIE_ATU_TYPE_IO;
> > + atu.cpu_addr = pp->io_base;
> > + atu.pci_addr = pp->io_bus_addr;
> > + atu.size = pp->io_size;
> > +
> > + ret = dw_pcie_prog_outbound_atu(pci, &atu);
> > if (ret) {
> > dev_err(pci->dev, "Failed to set IO range %pr\n",
> > entry->res);
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> > index 2459f2a61b9b..49b785509576 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -464,56 +464,56 @@ static inline u32 dw_pcie_enable_ecrc(u32 val)
> > return val | PCIE_ATU_TD;
> > }
> >
> > -static int __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no,
> > - int index, int type, u64 cpu_addr,
> > - u64 pci_addr, u64 size)
> > +int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
> > + const struct dw_pcie_ob_atu_cfg *atu)
> > {
> > + u64 cpu_addr = atu->cpu_addr;
> > u32 retries, val;
> > u64 limit_addr;
> >
> > if (pci->ops && pci->ops->cpu_addr_fixup)
> > cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
> >
> > - limit_addr = cpu_addr + size - 1;
> > + limit_addr = cpu_addr + atu->size - 1;
> >
> > if ((limit_addr & ~pci->region_limit) != (cpu_addr & ~pci->region_limit) ||
> > !IS_ALIGNED(cpu_addr, pci->region_align) ||
> > - !IS_ALIGNED(pci_addr, pci->region_align) || !size) {
> > + !IS_ALIGNED(atu->pci_addr, pci->region_align) || !atu->size) {
> > return -EINVAL;
> > }
> >
> > - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LOWER_BASE,
> > + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LOWER_BASE,
> > lower_32_bits(cpu_addr));
> > - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_BASE,
> > + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_BASE,
> > upper_32_bits(cpu_addr));
> >
> > - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LIMIT,
> > + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LIMIT,
> > lower_32_bits(limit_addr));
> > if (dw_pcie_ver_is_ge(pci, 460A))
> > - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_LIMIT,
> > + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_LIMIT,
> > upper_32_bits(limit_addr));
> >
> > - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_LOWER_TARGET,
> > - lower_32_bits(pci_addr));
> > - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_UPPER_TARGET,
> > - upper_32_bits(pci_addr));
> > + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_LOWER_TARGET,
> > + lower_32_bits(atu->pci_addr));
> > + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_TARGET,
> > + upper_32_bits(atu->pci_addr));
> >
> > - val = type | PCIE_ATU_FUNC_NUM(func_no);
> > + val = atu->type | PCIE_ATU_FUNC_NUM(atu->func_no);
> > if (upper_32_bits(limit_addr) > upper_32_bits(cpu_addr) &&
> > dw_pcie_ver_is_ge(pci, 460A))
> > val |= PCIE_ATU_INCREASE_REGION_SIZE;
> > if (dw_pcie_ver_is(pci, 490A))
> > val = dw_pcie_enable_ecrc(val);
> > - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_REGION_CTRL1, val);
> > + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
> >
> > - dw_pcie_writel_atu_ob(pci, index, PCIE_ATU_REGION_CTRL2, PCIE_ATU_ENABLE);
> > + dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2, PCIE_ATU_ENABLE);
> >
> > /*
> > * Make sure ATU enable takes effect before any subsequent config
> > * and I/O accesses.
> > */
> > for (retries = 0; retries < LINK_WAIT_MAX_IATU_RETRIES; retries++) {
> > - val = dw_pcie_readl_atu_ob(pci, index, PCIE_ATU_REGION_CTRL2);
> > + val = dw_pcie_readl_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2);
> > if (val & PCIE_ATU_ENABLE)
> > return 0;
> >
> > @@ -525,21 +525,6 @@ static int __dw_pcie_prog_outbound_atu(struct dw_pcie *pci, u8 func_no,
> > return -ETIMEDOUT;
> > }
> >
> > -int dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> > - u64 cpu_addr, u64 pci_addr, u64 size)
> > -{
> > - return __dw_pcie_prog_outbound_atu(pci, 0, index, type,
> > - cpu_addr, pci_addr, size);
> > -}
> > -
> > -int dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > - int type, u64 cpu_addr, u64 pci_addr,
> > - u64 size)
> > -{
> > - return __dw_pcie_prog_outbound_atu(pci, func_no, index, type,
> > - cpu_addr, pci_addr, size);
> > -}
> > -
> > static inline u32 dw_pcie_readl_atu_ib(struct dw_pcie *pci, u32 index, u32 reg)
> > {
> > return dw_pcie_readl_atu(pci, PCIE_ATU_REGION_DIR_IB, index, reg);
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> > index 755bcb406769..296c5b1ddc91 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -298,6 +298,15 @@ enum dw_pcie_ltssm {
> > DW_PCIE_LTSSM_UNKNOWN = 0xFFFFFFFF,
> > };
> >
> > +struct dw_pcie_ob_atu_cfg {
> > + int index;
> > + int type;
> > + u8 func_no;
> > + u64 cpu_addr;
> > + u64 pci_addr;
> > + u64 size;
> > +};
> > +
> > struct dw_pcie_host_ops {
> > int (*host_init)(struct dw_pcie_rp *pp);
> > void (*host_deinit)(struct dw_pcie_rp *pp);
> > @@ -429,10 +438,8 @@ void dw_pcie_write_dbi2(struct dw_pcie *pci, u32 reg, size_t size, u32 val);
> > int dw_pcie_link_up(struct dw_pcie *pci);
> > void dw_pcie_upconfig_setup(struct dw_pcie *pci);
> > int dw_pcie_wait_for_link(struct dw_pcie *pci);
> > -int dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
> > - u64 cpu_addr, u64 pci_addr, u64 size);
> > -int dw_pcie_prog_ep_outbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > - int type, u64 cpu_addr, u64 pci_addr, u64 size);
> > +int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
> > + const struct dw_pcie_ob_atu_cfg *atu);
> > int dw_pcie_prog_inbound_atu(struct dw_pcie *pci, int index, int type,
> > u64 cpu_addr, u64 pci_addr, u64 size);
> > int dw_pcie_prog_ep_inbound_atu(struct dw_pcie *pci, u8 func_no, int index,
> > --
> > 2.25.1
> >
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH v20 03/19] PCI: dwc: Add outbound MSG TLPs support
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 01/19] PCI: Add INTx Mechanism Messages macros Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 02/19] PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu() Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support Yoshihiro Shimoda
` (17 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Add "code" and "routing" into struct dw_pcie_ob_atu_cfg for triggering
INTx IRQs by iATU in the PCIe endpoint mode in near the future.
PCIE_ATU_INHIBIT_PAYLOAD is set to issue TLP type of Msg instead of
MsgD. So, this implementation supports the data-less messages only
for now.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/pci/controller/dwc/pcie-designware.c | 9 +++++++--
drivers/pci/controller/dwc/pcie-designware.h | 4 ++++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index 49b785509576..2d0f816fa0ab 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -498,7 +498,7 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_UPPER_TARGET,
upper_32_bits(atu->pci_addr));
- val = atu->type | PCIE_ATU_FUNC_NUM(atu->func_no);
+ val = atu->type | atu->routing | PCIE_ATU_FUNC_NUM(atu->func_no);
if (upper_32_bits(limit_addr) > upper_32_bits(cpu_addr) &&
dw_pcie_ver_is_ge(pci, 460A))
val |= PCIE_ATU_INCREASE_REGION_SIZE;
@@ -506,7 +506,12 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
val = dw_pcie_enable_ecrc(val);
dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
- dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2, PCIE_ATU_ENABLE);
+ val = PCIE_ATU_ENABLE;
+ if (atu->type == PCIE_ATU_TYPE_MSG) {
+ /* The data-less messages only for now */
+ val |= PCIE_ATU_INHIBIT_PAYLOAD | atu->code;
+ }
+ dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL2, val);
/*
* Make sure ATU enable takes effect before any subsequent config
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 296c5b1ddc91..8f22a7bc0523 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -147,11 +147,13 @@
#define PCIE_ATU_TYPE_IO 0x2
#define PCIE_ATU_TYPE_CFG0 0x4
#define PCIE_ATU_TYPE_CFG1 0x5
+#define PCIE_ATU_TYPE_MSG 0x10
#define PCIE_ATU_TD BIT(8)
#define PCIE_ATU_FUNC_NUM(pf) ((pf) << 20)
#define PCIE_ATU_REGION_CTRL2 0x004
#define PCIE_ATU_ENABLE BIT(31)
#define PCIE_ATU_BAR_MODE_ENABLE BIT(30)
+#define PCIE_ATU_INHIBIT_PAYLOAD BIT(22)
#define PCIE_ATU_FUNC_NUM_MATCH_EN BIT(19)
#define PCIE_ATU_LOWER_BASE 0x008
#define PCIE_ATU_UPPER_BASE 0x00C
@@ -302,6 +304,8 @@ struct dw_pcie_ob_atu_cfg {
int index;
int type;
u8 func_no;
+ u8 code;
+ u8 routing;
u64 cpu_addr;
u64 pci_addr;
u64 size;
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (2 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 03/19] PCI: dwc: Add outbound MSG TLPs support Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-09-13 23:31 ` Bjorn Helgaas
2023-08-25 9:32 ` [PATCH v20 05/19] PCI: dwc: endpoint: Add multiple PFs support for dbi2 Yoshihiro Shimoda
` (16 subsequent siblings)
20 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Add support for triggering INTx IRQs by using outbound iATU.
Outbound iATU is utilized to send assert and de-assert INTA TLPs
as simulated edge IRQ for INTA. (Other INT[BCD] are not asserted.)
This INTx support is optional (if there is no memory for INTx,
probe will not fail).
The message is generated based on the payloadless Msg TLP with type
0x14, where 0x4 is the routing code implying the Terminate at
Receiver message. The message code is specified as b1000xx for
the INTx assertion and b1001xx for the INTx de-assertion.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
---
.../pci/controller/dwc/pcie-designware-ep.c | 70 +++++++++++++++++--
drivers/pci/controller/dwc/pcie-designware.h | 2 +
2 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 747d5bc07222..91e3c4335031 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -6,9 +6,11 @@
* Author: Kishon Vijay Abraham I <kishon@ti.com>
*/
+#include <linux/delay.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include "../../pci.h"
#include "pcie-designware.h"
#include <linux/pci-epc.h>
#include <linux/pci-epf.h>
@@ -484,14 +486,61 @@ static const struct pci_epc_ops epc_ops = {
.get_features = dw_pcie_ep_get_features,
};
+static int dw_pcie_ep_send_msg(struct dw_pcie_ep *ep, u8 func_no, u8 code,
+ u8 routing)
+{
+ struct dw_pcie_ob_atu_cfg atu = { 0 };
+ struct pci_epc *epc = ep->epc;
+ int ret;
+
+ atu.func_no = func_no;
+ atu.code = code;
+ atu.routing = routing;
+ atu.type = PCIE_ATU_TYPE_MSG;
+ atu.cpu_addr = ep->intx_mem_phys;
+ atu.size = epc->mem->window.page_size;
+
+ ret = dw_pcie_ep_outbound_atu(ep, &atu);
+ if (ret)
+ return ret;
+
+ /* A dummy-write ep->intx_mem is converted to a Msg TLP */
+ writel(0, ep->intx_mem);
+
+ dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->intx_mem_phys);
+
+ return 0;
+}
+
int dw_pcie_ep_raise_legacy_irq(struct dw_pcie_ep *ep, u8 func_no)
{
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
struct device *dev = pci->dev;
+ int ret;
- dev_err(dev, "EP cannot trigger legacy IRQs\n");
+ if (!ep->intx_mem) {
+ dev_err(dev, "legacy IRQs not supported\n");
+ return -EOPNOTSUPP;
+ }
- return -EINVAL;
+ /*
+ * Even though the PCI bus specification implies the level-triggered
+ * INTx interrupts the kernel PCIe endpoint framework has a single
+ * PCI_EPC_IRQ_INTx flag defined for the legacy IRQs simulation. Thus
+ * this function sends the Deassert_INTx PCIe TLP after the Assert_INTx
+ * message with the 50 usec duration basically implementing the
+ * rising-edge triggering IRQ. Hopefully the interrupt controller will
+ * still be able to register the incoming IRQ event...
+ */
+ ret = dw_pcie_ep_send_msg(ep, func_no, PCI_MSG_CODE_ASSERT_INTA,
+ PCI_MSG_TYPE_R_LOCAL);
+ if (ret)
+ return ret;
+
+ usleep_range(50, 100);
+
+ return dw_pcie_ep_send_msg(ep, func_no, PCI_MSG_CODE_DEASSERT_INTA,
+ PCI_MSG_TYPE_R_LOCAL);
}
EXPORT_SYMBOL_GPL(dw_pcie_ep_raise_legacy_irq);
@@ -622,6 +671,10 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
dw_pcie_edma_remove(pci);
+ if (ep->intx_mem)
+ pci_epc_mem_free_addr(epc, ep->intx_mem_phys, ep->intx_mem,
+ epc->mem->window.page_size);
+
pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
epc->mem->window.page_size);
@@ -793,9 +846,14 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
goto err_exit_epc_mem;
}
+ ep->intx_mem = pci_epc_mem_alloc_addr(epc, &ep->intx_mem_phys,
+ epc->mem->window.page_size);
+ if (!ep->intx_mem)
+ dev_warn(dev, "Failed to reserve memory for INTx\n");
+
ret = dw_pcie_edma_detect(pci);
if (ret)
- goto err_free_epc_mem;
+ goto err_free_epc_mem_intx;
if (ep->ops->get_features) {
epc_features = ep->ops->get_features(ep);
@@ -812,7 +870,11 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
err_remove_edma:
dw_pcie_edma_remove(pci);
-err_free_epc_mem:
+err_free_epc_mem_intx:
+ if (ep->intx_mem)
+ pci_epc_mem_free_addr(epc, ep->intx_mem_phys, ep->intx_mem,
+ epc->mem->window.page_size);
+
pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
epc->mem->window.page_size);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 8f22a7bc0523..e02d4986bc2b 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -376,6 +376,8 @@ struct dw_pcie_ep {
unsigned long *ob_window_map;
void __iomem *msi_mem;
phys_addr_t msi_mem_phys;
+ void __iomem *intx_mem;
+ phys_addr_t intx_mem_phys;
struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
};
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support
2023-08-25 9:32 ` [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support Yoshihiro Shimoda
@ 2023-09-13 23:31 ` Bjorn Helgaas
2023-09-14 7:56 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-13 23:31 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc
On Fri, Aug 25, 2023 at 06:32:04PM +0900, Yoshihiro Shimoda wrote:
> Add support for triggering INTx IRQs by using outbound iATU.
> Outbound iATU is utilized to send assert and de-assert INTA TLPs
> as simulated edge IRQ for INTA. (Other INT[BCD] are not asserted.)
> This INTx support is optional (if there is no memory for INTx,
> probe will not fail).
>
> The message is generated based on the payloadless Msg TLP with type
> 0x14, where 0x4 is the routing code implying the Terminate at
> Receiver message. The message code is specified as b1000xx for
> the INTx assertion and b1001xx for the INTx de-assertion.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> ---
> .../pci/controller/dwc/pcie-designware-ep.c | 70 +++++++++++++++++--
> drivers/pci/controller/dwc/pcie-designware.h | 2 +
> 2 files changed, 68 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 747d5bc07222..91e3c4335031 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -6,9 +6,11 @@
> * Author: Kishon Vijay Abraham I <kishon@ti.com>
> */
>
> +#include <linux/delay.h>
> #include <linux/of.h>
> #include <linux/platform_device.h>
>
> +#include "../../pci.h"
> #include "pcie-designware.h"
> #include <linux/pci-epc.h>
> #include <linux/pci-epf.h>
> @@ -484,14 +486,61 @@ static const struct pci_epc_ops epc_ops = {
> .get_features = dw_pcie_ep_get_features,
> };
>
> +static int dw_pcie_ep_send_msg(struct dw_pcie_ep *ep, u8 func_no, u8 code,
> + u8 routing)
> +{
> + struct dw_pcie_ob_atu_cfg atu = { 0 };
> + struct pci_epc *epc = ep->epc;
> + int ret;
> +
> + atu.func_no = func_no;
> + atu.code = code;
> + atu.routing = routing;
> + atu.type = PCIE_ATU_TYPE_MSG;
> + atu.cpu_addr = ep->intx_mem_phys;
> + atu.size = epc->mem->window.page_size;
> +
> + ret = dw_pcie_ep_outbound_atu(ep, &atu);
> + if (ret)
> + return ret;
> +
> + /* A dummy-write ep->intx_mem is converted to a Msg TLP */
> + writel(0, ep->intx_mem);
> +
> + dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->intx_mem_phys);
> +
> + return 0;
> +}
> +
> int dw_pcie_ep_raise_legacy_irq(struct dw_pcie_ep *ep, u8 func_no)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct device *dev = pci->dev;
> + int ret;
>
> - dev_err(dev, "EP cannot trigger legacy IRQs\n");
> + if (!ep->intx_mem) {
> + dev_err(dev, "legacy IRQs not supported\n");
> + return -EOPNOTSUPP;
> + }
>
> - return -EINVAL;
> + /*
> + * Even though the PCI bus specification implies the level-triggered
> + * INTx interrupts the kernel PCIe endpoint framework has a single
> + * PCI_EPC_IRQ_INTx flag defined for the legacy IRQs simulation. Thus
> + * this function sends the Deassert_INTx PCIe TLP after the Assert_INTx
> + * message with the 50 usec duration basically implementing the
> + * rising-edge triggering IRQ. Hopefully the interrupt controller will
> + * still be able to register the incoming IRQ event...
I'm not really convinced about this "assert INTA, wait 50us, deassert
INTA" thing. All the INTx language in the spec is like this:
... the virtual INTx wire must be asserted whenever and *as long as*
the following conditions are satisfied:
- The Interrupt Disable bit in the Command register is set to 0b.
- The <feature> Interrupt Enable bit in the <feature> Control
Register is set to 1b.
- The <feature> Status bit in the <feature> Status register is
set.
E.g., sec PCIe r6.0, sec 5.5.6 (Link Activation), 6.1.6 (Native PME),
6.2.4.1.2 (AER Interrupt Generation), 6.2.11.1 (DPC Interrupts),
6.7.3.4 (Software Notification of Hot-Plug Events).
So it seems to me like the endpoint needs an "interrupt status" bit,
and the Deassert_INTx message would be sent when the host interrupt
handler clears that bit.
> + */
> + ret = dw_pcie_ep_send_msg(ep, func_no, PCI_MSG_CODE_ASSERT_INTA,
> + PCI_MSG_TYPE_R_LOCAL);
> + if (ret)
> + return ret;
> +
> + usleep_range(50, 100);
> +
> + return dw_pcie_ep_send_msg(ep, func_no, PCI_MSG_CODE_DEASSERT_INTA,
> + PCI_MSG_TYPE_R_LOCAL);
> }
> EXPORT_SYMBOL_GPL(dw_pcie_ep_raise_legacy_irq);
>
> @@ -622,6 +671,10 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
>
> dw_pcie_edma_remove(pci);
>
> + if (ep->intx_mem)
> + pci_epc_mem_free_addr(epc, ep->intx_mem_phys, ep->intx_mem,
> + epc->mem->window.page_size);
> +
> pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> epc->mem->window.page_size);
>
> @@ -793,9 +846,14 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> goto err_exit_epc_mem;
> }
>
> + ep->intx_mem = pci_epc_mem_alloc_addr(epc, &ep->intx_mem_phys,
> + epc->mem->window.page_size);
> + if (!ep->intx_mem)
> + dev_warn(dev, "Failed to reserve memory for INTx\n");
> +
> ret = dw_pcie_edma_detect(pci);
> if (ret)
> - goto err_free_epc_mem;
> + goto err_free_epc_mem_intx;
>
> if (ep->ops->get_features) {
> epc_features = ep->ops->get_features(ep);
> @@ -812,7 +870,11 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> err_remove_edma:
> dw_pcie_edma_remove(pci);
>
> -err_free_epc_mem:
> +err_free_epc_mem_intx:
> + if (ep->intx_mem)
> + pci_epc_mem_free_addr(epc, ep->intx_mem_phys, ep->intx_mem,
> + epc->mem->window.page_size);
> +
> pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> epc->mem->window.page_size);
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 8f22a7bc0523..e02d4986bc2b 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -376,6 +376,8 @@ struct dw_pcie_ep {
> unsigned long *ob_window_map;
> void __iomem *msi_mem;
> phys_addr_t msi_mem_phys;
> + void __iomem *intx_mem;
> + phys_addr_t intx_mem_phys;
> struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
> };
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support
2023-09-13 23:31 ` Bjorn Helgaas
@ 2023-09-14 7:56 ` Yoshihiro Shimoda
2023-09-15 21:23 ` Bjorn Helgaas
0 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-14 7:56 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hi Bjorn,
> From: Bjorn Helgaas, Sent: Thursday, September 14, 2023 8:31 AM
>
> On Fri, Aug 25, 2023 at 06:32:04PM +0900, Yoshihiro Shimoda wrote:
> > Add support for triggering INTx IRQs by using outbound iATU.
> > Outbound iATU is utilized to send assert and de-assert INTA TLPs
> > as simulated edge IRQ for INTA. (Other INT[BCD] are not asserted.)
> > This INTx support is optional (if there is no memory for INTx,
> > probe will not fail).
> >
> > The message is generated based on the payloadless Msg TLP with type
> > 0x14, where 0x4 is the routing code implying the Terminate at
> > Receiver message. The message code is specified as b1000xx for
> > the INTx assertion and b1001xx for the INTx de-assertion.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > ---
> > .../pci/controller/dwc/pcie-designware-ep.c | 70 +++++++++++++++++--
> > drivers/pci/controller/dwc/pcie-designware.h | 2 +
> > 2 files changed, 68 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 747d5bc07222..91e3c4335031 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -6,9 +6,11 @@
> > * Author: Kishon Vijay Abraham I <kishon@ti.com>
> > */
> >
> > +#include <linux/delay.h>
> > #include <linux/of.h>
> > #include <linux/platform_device.h>
> >
> > +#include "../../pci.h"
> > #include "pcie-designware.h"
> > #include <linux/pci-epc.h>
> > #include <linux/pci-epf.h>
> > @@ -484,14 +486,61 @@ static const struct pci_epc_ops epc_ops = {
> > .get_features = dw_pcie_ep_get_features,
> > };
> >
> > +static int dw_pcie_ep_send_msg(struct dw_pcie_ep *ep, u8 func_no, u8 code,
> > + u8 routing)
> > +{
> > + struct dw_pcie_ob_atu_cfg atu = { 0 };
> > + struct pci_epc *epc = ep->epc;
> > + int ret;
> > +
> > + atu.func_no = func_no;
> > + atu.code = code;
> > + atu.routing = routing;
> > + atu.type = PCIE_ATU_TYPE_MSG;
> > + atu.cpu_addr = ep->intx_mem_phys;
> > + atu.size = epc->mem->window.page_size;
> > +
> > + ret = dw_pcie_ep_outbound_atu(ep, &atu);
> > + if (ret)
> > + return ret;
> > +
> > + /* A dummy-write ep->intx_mem is converted to a Msg TLP */
> > + writel(0, ep->intx_mem);
> > +
> > + dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->intx_mem_phys);
> > +
> > + return 0;
> > +}
> > +
> > int dw_pcie_ep_raise_legacy_irq(struct dw_pcie_ep *ep, u8 func_no)
> > {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > struct device *dev = pci->dev;
> > + int ret;
> >
> > - dev_err(dev, "EP cannot trigger legacy IRQs\n");
> > + if (!ep->intx_mem) {
> > + dev_err(dev, "legacy IRQs not supported\n");
> > + return -EOPNOTSUPP;
> > + }
> >
> > - return -EINVAL;
> > + /*
> > + * Even though the PCI bus specification implies the level-triggered
> > + * INTx interrupts the kernel PCIe endpoint framework has a single
> > + * PCI_EPC_IRQ_INTx flag defined for the legacy IRQs simulation. Thus
> > + * this function sends the Deassert_INTx PCIe TLP after the Assert_INTx
> > + * message with the 50 usec duration basically implementing the
> > + * rising-edge triggering IRQ. Hopefully the interrupt controller will
> > + * still be able to register the incoming IRQ event...
>
> I'm not really convinced about this "assert INTA, wait 50us, deassert
> INTA" thing. All the INTx language in the spec is like this:
>
> ... the virtual INTx wire must be asserted whenever and *as long as*
> the following conditions are satisfied:
>
> - The Interrupt Disable bit in the Command register is set to 0b.
>
> - The <feature> Interrupt Enable bit in the <feature> Control
> Register is set to 1b.
>
> - The <feature> Status bit in the <feature> Status register is
> set.
>
> E.g., sec PCIe r6.0, sec 5.5.6 (Link Activation), 6.1.6 (Native PME),
> 6.2.4.1.2 (AER Interrupt Generation), 6.2.11.1 (DPC Interrupts),
> 6.7.3.4 (Software Notification of Hot-Plug Events).
>
> So it seems to me like the endpoint needs an "interrupt status" bit,
> and the Deassert_INTx message would be sent when the host interrupt
> handler clears that bit.
Thank you very much for your comments! About this topic,
Frank also has a similar opinion before [1]. So, I asked Kishon
about this, but I didn't get any comment from Kishon at that time.
Anyway, to handle INTx on PCIe endpoint framework properly,
we need to modify the PCIe Endpoint framework, IIUC.
Should I modify the PCIe Endpoint framework at first?
Or, can this patch be applied as-is?
I guess that such modification of the PCIe Endpoint framework
need much time. So, if I should modify the framework at first,
I would like to drop adding INTx support [2] from my patch series
because supporting INTx on my PCIe controller is not mandatory.
[1]
https://lore.kernel.org/linux-pci/TYBPR01MB5341EFAC471AEBB9100D6051D8719@TYBPR01MB5341.jpnprd01.prod.outlook.com/
[2]
The following patches are not needed if INTx support should be dropped:
eb185e1e628a PCI: designware-ep: Add INTx IRQs support
5d0e51f85b23 PCI: dwc: Add outbound MSG TLPs support
4758bef61cc2 PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
44938b13046b PCI: Add INTx Mechanism Messages macros
Best regards,
Yoshihiro Shimoda
> > + */
> > + ret = dw_pcie_ep_send_msg(ep, func_no, PCI_MSG_CODE_ASSERT_INTA,
> > + PCI_MSG_TYPE_R_LOCAL);
> > + if (ret)
> > + return ret;
> > +
> > + usleep_range(50, 100);
> > +
> > + return dw_pcie_ep_send_msg(ep, func_no, PCI_MSG_CODE_DEASSERT_INTA,
> > + PCI_MSG_TYPE_R_LOCAL);
> > }
> > EXPORT_SYMBOL_GPL(dw_pcie_ep_raise_legacy_irq);
> >
> > @@ -622,6 +671,10 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
> >
> > dw_pcie_edma_remove(pci);
> >
> > + if (ep->intx_mem)
> > + pci_epc_mem_free_addr(epc, ep->intx_mem_phys, ep->intx_mem,
> > + epc->mem->window.page_size);
> > +
> > pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> > epc->mem->window.page_size);
> >
> > @@ -793,9 +846,14 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > goto err_exit_epc_mem;
> > }
> >
> > + ep->intx_mem = pci_epc_mem_alloc_addr(epc, &ep->intx_mem_phys,
> > + epc->mem->window.page_size);
> > + if (!ep->intx_mem)
> > + dev_warn(dev, "Failed to reserve memory for INTx\n");
> > +
> > ret = dw_pcie_edma_detect(pci);
> > if (ret)
> > - goto err_free_epc_mem;
> > + goto err_free_epc_mem_intx;
> >
> > if (ep->ops->get_features) {
> > epc_features = ep->ops->get_features(ep);
> > @@ -812,7 +870,11 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > err_remove_edma:
> > dw_pcie_edma_remove(pci);
> >
> > -err_free_epc_mem:
> > +err_free_epc_mem_intx:
> > + if (ep->intx_mem)
> > + pci_epc_mem_free_addr(epc, ep->intx_mem_phys, ep->intx_mem,
> > + epc->mem->window.page_size);
> > +
> > pci_epc_mem_free_addr(epc, ep->msi_mem_phys, ep->msi_mem,
> > epc->mem->window.page_size);
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> > index 8f22a7bc0523..e02d4986bc2b 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -376,6 +376,8 @@ struct dw_pcie_ep {
> > unsigned long *ob_window_map;
> > void __iomem *msi_mem;
> > phys_addr_t msi_mem_phys;
> > + void __iomem *intx_mem;
> > + phys_addr_t intx_mem_phys;
> > struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
> > };
> >
> > --
> > 2.25.1
> >
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support
2023-09-14 7:56 ` Yoshihiro Shimoda
@ 2023-09-15 21:23 ` Bjorn Helgaas
2023-09-19 7:22 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-15 21:23 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
On Thu, Sep 14, 2023 at 07:56:21AM +0000, Yoshihiro Shimoda wrote:
> > From: Bjorn Helgaas, Sent: Thursday, September 14, 2023 8:31 AM
> > On Fri, Aug 25, 2023 at 06:32:04PM +0900, Yoshihiro Shimoda wrote:
> > > Add support for triggering INTx IRQs by using outbound iATU.
> > > Outbound iATU is utilized to send assert and de-assert INTA TLPs
> > > as simulated edge IRQ for INTA. (Other INT[BCD] are not asserted.)
> > > This INTx support is optional (if there is no memory for INTx,
> > > probe will not fail).
> > >
> > > The message is generated based on the payloadless Msg TLP with type
> > > 0x14, where 0x4 is the routing code implying the Terminate at
> > > Receiver message. The message code is specified as b1000xx for
> > > the INTx assertion and b1001xx for the INTx de-assertion.
> > >
> > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > > ---
> > > .../pci/controller/dwc/pcie-designware-ep.c | 70 +++++++++++++++++--
> > > drivers/pci/controller/dwc/pcie-designware.h | 2 +
> > > 2 files changed, 68 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > index 747d5bc07222..91e3c4335031 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > @@ -6,9 +6,11 @@
> > > * Author: Kishon Vijay Abraham I <kishon@ti.com>
> > > */
> > >
> > > +#include <linux/delay.h>
> > > #include <linux/of.h>
> > > #include <linux/platform_device.h>
> > >
> > > +#include "../../pci.h"
> > > #include "pcie-designware.h"
> > > #include <linux/pci-epc.h>
> > > #include <linux/pci-epf.h>
> > > @@ -484,14 +486,61 @@ static const struct pci_epc_ops epc_ops = {
> > > .get_features = dw_pcie_ep_get_features,
> > > };
> > >
> > > +static int dw_pcie_ep_send_msg(struct dw_pcie_ep *ep, u8 func_no, u8 code,
> > > + u8 routing)
> > > +{
> > > + struct dw_pcie_ob_atu_cfg atu = { 0 };
> > > + struct pci_epc *epc = ep->epc;
> > > + int ret;
> > > +
> > > + atu.func_no = func_no;
> > > + atu.code = code;
> > > + atu.routing = routing;
> > > + atu.type = PCIE_ATU_TYPE_MSG;
> > > + atu.cpu_addr = ep->intx_mem_phys;
> > > + atu.size = epc->mem->window.page_size;
> > > +
> > > + ret = dw_pcie_ep_outbound_atu(ep, &atu);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /* A dummy-write ep->intx_mem is converted to a Msg TLP */
> > > + writel(0, ep->intx_mem);
> > > +
> > > + dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->intx_mem_phys);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > int dw_pcie_ep_raise_legacy_irq(struct dw_pcie_ep *ep, u8 func_no)
> > > {
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > struct device *dev = pci->dev;
> > > + int ret;
> > >
> > > - dev_err(dev, "EP cannot trigger legacy IRQs\n");
> > > + if (!ep->intx_mem) {
> > > + dev_err(dev, "legacy IRQs not supported\n");
> > > + return -EOPNOTSUPP;
> > > + }
> > >
> > > - return -EINVAL;
> > > + /*
> > > + * Even though the PCI bus specification implies the level-triggered
> > > + * INTx interrupts the kernel PCIe endpoint framework has a single
> > > + * PCI_EPC_IRQ_INTx flag defined for the legacy IRQs simulation. Thus
> > > + * this function sends the Deassert_INTx PCIe TLP after the Assert_INTx
> > > + * message with the 50 usec duration basically implementing the
> > > + * rising-edge triggering IRQ. Hopefully the interrupt controller will
> > > + * still be able to register the incoming IRQ event...
> >
> > I'm not really convinced about this "assert INTA, wait 50us, deassert
> > INTA" thing. All the INTx language in the spec is like this:
> >
> > ... the virtual INTx wire must be asserted whenever and *as long as*
> > the following conditions are satisfied:
> >
> > - The Interrupt Disable bit in the Command register is set to 0b.
> >
> > - The <feature> Interrupt Enable bit in the <feature> Control
> > Register is set to 1b.
> >
> > - The <feature> Status bit in the <feature> Status register is
> > set.
> >
> > E.g., sec PCIe r6.0, sec 5.5.6 (Link Activation), 6.1.6 (Native PME),
> > 6.2.4.1.2 (AER Interrupt Generation), 6.2.11.1 (DPC Interrupts),
> > 6.7.3.4 (Software Notification of Hot-Plug Events).
> >
> > So it seems to me like the endpoint needs an "interrupt status" bit,
> > and the Deassert_INTx message would be sent when the host interrupt
> > handler clears that bit.
>
> Thank you very much for your comments! About this topic,
> Frank also has a similar opinion before [1]. So, I asked Kishon
> about this, but I didn't get any comment from Kishon at that time.
> Anyway, to handle INTx on PCIe endpoint framework properly,
> we need to modify the PCIe Endpoint framework, IIUC.
>
> Should I modify the PCIe Endpoint framework at first?
> Or, can this patch be applied as-is?
> I guess that such modification of the PCIe Endpoint framework
> need much time. So, if I should modify the framework at first,
> I would like to drop adding INTx support [2] from my patch series
> because supporting INTx on my PCIe controller is not mandatory.
>
> [1]
> https://lore.kernel.org/linux-pci/TYBPR01MB5341EFAC471AEBB9100D6051D8719@TYBPR01MB5341.jpnprd01.prod.outlook.com/
>
> [2]
> The following patches are not needed if INTx support should be dropped:
>
> eb185e1e628a PCI: designware-ep: Add INTx IRQs support
> 5d0e51f85b23 PCI: dwc: Add outbound MSG TLPs support
> 4758bef61cc2 PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
> 44938b13046b PCI: Add INTx Mechanism Messages macros
Since INTx support isn't mandatory at this time, I think we should
drop these patches for now. If/when somebody definitely needs INTx
support, we can resurrect them, and then we'll have more clarity on
how it should work and we'll be better able to test it.
Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support
2023-09-15 21:23 ` Bjorn Helgaas
@ 2023-09-19 7:22 ` Yoshihiro Shimoda
2023-09-19 10:39 ` Bjorn Helgaas
0 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-19 7:22 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hello Bjorn,
> From: Bjorn Helgaas, Sent: Saturday, September 16, 2023 6:24 AM
>
> On Thu, Sep 14, 2023 at 07:56:21AM +0000, Yoshihiro Shimoda wrote:
> > > From: Bjorn Helgaas, Sent: Thursday, September 14, 2023 8:31 AM
> > > On Fri, Aug 25, 2023 at 06:32:04PM +0900, Yoshihiro Shimoda wrote:
> > > > Add support for triggering INTx IRQs by using outbound iATU.
> > > > Outbound iATU is utilized to send assert and de-assert INTA TLPs
> > > > as simulated edge IRQ for INTA. (Other INT[BCD] are not asserted.)
> > > > This INTx support is optional (if there is no memory for INTx,
> > > > probe will not fail).
> > > >
> > > > The message is generated based on the payloadless Msg TLP with type
> > > > 0x14, where 0x4 is the routing code implying the Terminate at
> > > > Receiver message. The message code is specified as b1000xx for
> > > > the INTx assertion and b1001xx for the INTx de-assertion.
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > > > ---
> > > > .../pci/controller/dwc/pcie-designware-ep.c | 70 +++++++++++++++++--
> > > > drivers/pci/controller/dwc/pcie-designware.h | 2 +
> > > > 2 files changed, 68 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > > index 747d5bc07222..91e3c4335031 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > > > @@ -6,9 +6,11 @@
> > > > * Author: Kishon Vijay Abraham I <kishon@ti.com>
> > > > */
> > > >
> > > > +#include <linux/delay.h>
> > > > #include <linux/of.h>
> > > > #include <linux/platform_device.h>
> > > >
> > > > +#include "../../pci.h"
> > > > #include "pcie-designware.h"
> > > > #include <linux/pci-epc.h>
> > > > #include <linux/pci-epf.h>
> > > > @@ -484,14 +486,61 @@ static const struct pci_epc_ops epc_ops = {
> > > > .get_features = dw_pcie_ep_get_features,
> > > > };
> > > >
> > > > +static int dw_pcie_ep_send_msg(struct dw_pcie_ep *ep, u8 func_no, u8 code,
> > > > + u8 routing)
> > > > +{
> > > > + struct dw_pcie_ob_atu_cfg atu = { 0 };
> > > > + struct pci_epc *epc = ep->epc;
> > > > + int ret;
> > > > +
> > > > + atu.func_no = func_no;
> > > > + atu.code = code;
> > > > + atu.routing = routing;
> > > > + atu.type = PCIE_ATU_TYPE_MSG;
> > > > + atu.cpu_addr = ep->intx_mem_phys;
> > > > + atu.size = epc->mem->window.page_size;
> > > > +
> > > > + ret = dw_pcie_ep_outbound_atu(ep, &atu);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + /* A dummy-write ep->intx_mem is converted to a Msg TLP */
> > > > + writel(0, ep->intx_mem);
> > > > +
> > > > + dw_pcie_ep_unmap_addr(epc, func_no, 0, ep->intx_mem_phys);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > int dw_pcie_ep_raise_legacy_irq(struct dw_pcie_ep *ep, u8 func_no)
> > > > {
> > > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > struct device *dev = pci->dev;
> > > > + int ret;
> > > >
> > > > - dev_err(dev, "EP cannot trigger legacy IRQs\n");
> > > > + if (!ep->intx_mem) {
> > > > + dev_err(dev, "legacy IRQs not supported\n");
> > > > + return -EOPNOTSUPP;
> > > > + }
> > > >
> > > > - return -EINVAL;
> > > > + /*
> > > > + * Even though the PCI bus specification implies the level-triggered
> > > > + * INTx interrupts the kernel PCIe endpoint framework has a single
> > > > + * PCI_EPC_IRQ_INTx flag defined for the legacy IRQs simulation. Thus
> > > > + * this function sends the Deassert_INTx PCIe TLP after the Assert_INTx
> > > > + * message with the 50 usec duration basically implementing the
> > > > + * rising-edge triggering IRQ. Hopefully the interrupt controller will
> > > > + * still be able to register the incoming IRQ event...
> > >
> > > I'm not really convinced about this "assert INTA, wait 50us, deassert
> > > INTA" thing. All the INTx language in the spec is like this:
> > >
> > > ... the virtual INTx wire must be asserted whenever and *as long as*
> > > the following conditions are satisfied:
> > >
> > > - The Interrupt Disable bit in the Command register is set to 0b.
> > >
> > > - The <feature> Interrupt Enable bit in the <feature> Control
> > > Register is set to 1b.
> > >
> > > - The <feature> Status bit in the <feature> Status register is
> > > set.
> > >
> > > E.g., sec PCIe r6.0, sec 5.5.6 (Link Activation), 6.1.6 (Native PME),
> > > 6.2.4.1.2 (AER Interrupt Generation), 6.2.11.1 (DPC Interrupts),
> > > 6.7.3.4 (Software Notification of Hot-Plug Events).
> > >
> > > So it seems to me like the endpoint needs an "interrupt status" bit,
> > > and the Deassert_INTx message would be sent when the host interrupt
> > > handler clears that bit.
> >
> > Thank you very much for your comments! About this topic,
> > Frank also has a similar opinion before [1]. So, I asked Kishon
> > about this, but I didn't get any comment from Kishon at that time.
> > Anyway, to handle INTx on PCIe endpoint framework properly,
> > we need to modify the PCIe Endpoint framework, IIUC.
> >
> > Should I modify the PCIe Endpoint framework at first?
> > Or, can this patch be applied as-is?
> > I guess that such modification of the PCIe Endpoint framework
> > need much time. So, if I should modify the framework at first,
> > I would like to drop adding INTx support [2] from my patch series
> > because supporting INTx on my PCIe controller is not mandatory.
> >
> > [1]
> > https://lore.kernel.org/linux-pci/TYBPR01MB5341EFAC471AEBB9100D6051D8719@TYBPR01MB5341.jpnprd01.prod.outlook.com/
> >
> > [2]
> > The following patches are not needed if INTx support should be dropped:
> >
> > eb185e1e628a PCI: designware-ep: Add INTx IRQs support
> > 5d0e51f85b23 PCI: dwc: Add outbound MSG TLPs support
> > 4758bef61cc2 PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
> > 44938b13046b PCI: Add INTx Mechanism Messages macros
>
> Since INTx support isn't mandatory at this time, I think we should
> drop these patches for now. If/when somebody definitely needs INTx
> support, we can resurrect them, and then we'll have more clarity on
> how it should work and we'll be better able to test it.
I got it.
In this case, should I submit the patch series as v21? Or, like the previous
time [1], should I submit some patches for squashing the controller/rcar branch?
[1] https://lore.kernel.org/linux-pci/20230901131711.2861283-1-yoshihiro.shimoda.uh@renesas.com/
Best regards,
Yoshihiro Shimoda
> Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support
2023-09-19 7:22 ` Yoshihiro Shimoda
@ 2023-09-19 10:39 ` Bjorn Helgaas
2023-09-19 11:55 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-19 10:39 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
On Tue, Sep 19, 2023 at 07:22:48AM +0000, Yoshihiro Shimoda wrote:
> > From: Bjorn Helgaas, Sent: Saturday, September 16, 2023 6:24 AM
> > On Thu, Sep 14, 2023 at 07:56:21AM +0000, Yoshihiro Shimoda wrote:
> > ...
> > > The following patches are not needed if INTx support should be dropped:
> > >
> > > eb185e1e628a PCI: designware-ep: Add INTx IRQs support
> > > 5d0e51f85b23 PCI: dwc: Add outbound MSG TLPs support
> > > 4758bef61cc2 PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
> > > 44938b13046b PCI: Add INTx Mechanism Messages macros
> >
> > Since INTx support isn't mandatory at this time, I think we should
> > drop these patches for now. If/when somebody definitely needs INTx
> > support, we can resurrect them, and then we'll have more clarity on
> > how it should work and we'll be better able to test it.
>
> I got it.
>
> In this case, should I submit the patch series as v21?
I think it will be simpler if you post a v21 that includes squashing
the R-Car drivers together as well as dropping these INTx patches.
Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support
2023-09-19 10:39 ` Bjorn Helgaas
@ 2023-09-19 11:55 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-19 11:55 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hello Bjorn,
> From: Bjorn Helgaas, Sent: Tuesday, September 19, 2023 7:40 PM
>
> On Tue, Sep 19, 2023 at 07:22:48AM +0000, Yoshihiro Shimoda wrote:
> > > From: Bjorn Helgaas, Sent: Saturday, September 16, 2023 6:24 AM
> > > On Thu, Sep 14, 2023 at 07:56:21AM +0000, Yoshihiro Shimoda wrote:
> > > ...
>
> > > > The following patches are not needed if INTx support should be dropped:
> > > >
> > > > eb185e1e628a PCI: designware-ep: Add INTx IRQs support
> > > > 5d0e51f85b23 PCI: dwc: Add outbound MSG TLPs support
> > > > 4758bef61cc2 PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
> > > > 44938b13046b PCI: Add INTx Mechanism Messages macros
> > >
> > > Since INTx support isn't mandatory at this time, I think we should
> > > drop these patches for now. If/when somebody definitely needs INTx
> > > support, we can resurrect them, and then we'll have more clarity on
> > > how it should work and we'll be better able to test it.
> >
> > I got it.
> >
> > In this case, should I submit the patch series as v21?
>
> I think it will be simpler if you post a v21 that includes squashing
> the R-Car drivers together as well as dropping these INTx patches.
Thank you for your reply! I'll make such a patch series.
Best regards,
Yoshihiro Shimoda
> Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH v20 05/19] PCI: dwc: endpoint: Add multiple PFs support for dbi2
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (3 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 04/19] PCI: designware-ep: Add INTx IRQs support Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 06/19] PCI: dwc: Add dw_pcie_link_set_max_link_width() Yoshihiro Shimoda
` (15 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
The commit 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support
for DWC") added .func_conf_select() to get the configuration space of
different PFs and assumed that the offsets between dbi and dbi2 would
be the same. However, Renesas R-Car Gen4 PCIe controllers have different
offsets of function 1: dbi (+0x1000) and dbi2 (+0x800). To get
the offset for dbi2, add .get_dbi2_offset() and
dw_pcie_ep_get_dbi2_offset().
Note:
- .func_conf_select() should be renamed later.
- dw_pcie_ep_get_dbi2_offset() will call .func_conf_select()
if .get_dbi2_offset() doesn't exist for backward compatibility.
- dw_pcie_writeX_{dbi/dbi2} APIs accepted the func_no argument,
so that these offset calculations are contained in the API
definitions itself as it should.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
.../pci/controller/dwc/pcie-designware-ep.c | 32 ++++++++++++++-----
drivers/pci/controller/dwc/pcie-designware.h | 1 +
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 91e3c4335031..feeb2ea3c9c7 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -54,21 +54,35 @@ static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8 func_no)
return func_offset;
}
+static unsigned int dw_pcie_ep_get_dbi2_offset(struct dw_pcie_ep *ep, u8 func_no)
+{
+ unsigned int dbi2_offset = 0;
+
+ if (ep->ops->get_dbi2_offset)
+ dbi2_offset = ep->ops->get_dbi2_offset(ep, func_no);
+ else if (ep->ops->func_conf_select) /* for backward compatibility */
+ dbi2_offset = ep->ops->func_conf_select(ep, func_no);
+
+ return dbi2_offset;
+}
+
static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
enum pci_barno bar, int flags)
{
- u32 reg;
- unsigned int func_offset = 0;
+ unsigned int func_offset, dbi2_offset;
struct dw_pcie_ep *ep = &pci->ep;
+ u32 reg, reg_dbi2;
func_offset = dw_pcie_ep_func_select(ep, func_no);
+ dbi2_offset = dw_pcie_ep_get_dbi2_offset(ep, func_no);
reg = func_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
+ reg_dbi2 = dbi2_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
dw_pcie_dbi_ro_wr_en(pci);
- dw_pcie_writel_dbi2(pci, reg, 0x0);
+ dw_pcie_writel_dbi2(pci, reg_dbi2, 0x0);
dw_pcie_writel_dbi(pci, reg, 0x0);
if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
- dw_pcie_writel_dbi2(pci, reg + 4, 0x0);
+ dw_pcie_writel_dbi2(pci, reg_dbi2 + 4, 0x0);
dw_pcie_writel_dbi(pci, reg + 4, 0x0);
}
dw_pcie_dbi_ro_wr_dis(pci);
@@ -229,16 +243,18 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
{
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ unsigned int func_offset, dbi2_offset;
enum pci_barno bar = epf_bar->barno;
size_t size = epf_bar->size;
int flags = epf_bar->flags;
- unsigned int func_offset = 0;
+ u32 reg, reg_dbi2;
int ret, type;
- u32 reg;
func_offset = dw_pcie_ep_func_select(ep, func_no);
+ dbi2_offset = dw_pcie_ep_get_dbi2_offset(ep, func_no);
reg = PCI_BASE_ADDRESS_0 + (4 * bar) + func_offset;
+ reg_dbi2 = PCI_BASE_ADDRESS_0 + (4 * bar) + dbi2_offset;
if (!(flags & PCI_BASE_ADDRESS_SPACE))
type = PCIE_ATU_TYPE_MEM;
@@ -254,11 +270,11 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
dw_pcie_dbi_ro_wr_en(pci);
- dw_pcie_writel_dbi2(pci, reg, lower_32_bits(size - 1));
+ dw_pcie_writel_dbi2(pci, reg_dbi2, lower_32_bits(size - 1));
dw_pcie_writel_dbi(pci, reg, flags);
if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64) {
- dw_pcie_writel_dbi2(pci, reg + 4, upper_32_bits(size - 1));
+ dw_pcie_writel_dbi2(pci, reg_dbi2 + 4, upper_32_bits(size - 1));
dw_pcie_writel_dbi(pci, reg + 4, 0);
}
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index e02d4986bc2b..b731e38a71fc 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -354,6 +354,7 @@ struct dw_pcie_ep_ops {
* driver.
*/
unsigned int (*func_conf_select)(struct dw_pcie_ep *ep, u8 func_no);
+ unsigned int (*get_dbi2_offset)(struct dw_pcie_ep *ep, u8 func_no);
};
struct dw_pcie_ep_func {
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 06/19] PCI: dwc: Add dw_pcie_link_set_max_link_width()
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (4 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 05/19] PCI: dwc: endpoint: Add multiple PFs support for dbi2 Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling Yoshihiro Shimoda
` (14 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda, Manivannan Sadhasivam
This patch is a preparation before adding the Max-Link-width capability
setup which would in its turn complete the max-link-width setup
procedure defined by Synopsys in the HW-manual. Seeing there is
a max-link-speed setup method defined in the DW PCIe core driver
it would be good to have a similar function for the link width setup.
That's why we need to define a dedicated function first from already
implemented but incomplete link-width setting up code.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>3
---
drivers/pci/controller/dwc/pcie-designware.c | 86 ++++++++++----------
1 file changed, 41 insertions(+), 45 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index 2d0f816fa0ab..5cca34140d2a 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -728,6 +728,46 @@ static void dw_pcie_link_set_max_speed(struct dw_pcie *pci, u32 link_gen)
}
+static void dw_pcie_link_set_max_link_width(struct dw_pcie *pci, u32 num_lanes)
+{
+ u32 lwsc, plc;
+
+ if (!num_lanes)
+ return;
+
+ /* Set the number of lanes */
+ plc = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
+ plc &= ~PORT_LINK_FAST_LINK_MODE;
+ plc &= ~PORT_LINK_MODE_MASK;
+
+ /* Set link width speed control register */
+ lwsc = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);
+ lwsc &= ~PORT_LOGIC_LINK_WIDTH_MASK;
+ switch (num_lanes) {
+ case 1:
+ plc |= PORT_LINK_MODE_1_LANES;
+ lwsc |= PORT_LOGIC_LINK_WIDTH_1_LANES;
+ break;
+ case 2:
+ plc |= PORT_LINK_MODE_2_LANES;
+ lwsc |= PORT_LOGIC_LINK_WIDTH_2_LANES;
+ break;
+ case 4:
+ plc |= PORT_LINK_MODE_4_LANES;
+ lwsc |= PORT_LOGIC_LINK_WIDTH_4_LANES;
+ break;
+ case 8:
+ plc |= PORT_LINK_MODE_8_LANES;
+ lwsc |= PORT_LOGIC_LINK_WIDTH_8_LANES;
+ break;
+ default:
+ dev_err(pci->dev, "num-lanes %u: invalid value\n", num_lanes);
+ return;
+ }
+ dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, plc);
+ dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, lwsc);
+}
+
void dw_pcie_iatu_detect(struct dw_pcie *pci)
{
int max_region, ob, ib;
@@ -1009,49 +1049,5 @@ void dw_pcie_setup(struct dw_pcie *pci)
val |= PORT_LINK_DLL_LINK_EN;
dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, val);
- if (!pci->num_lanes) {
- dev_dbg(pci->dev, "Using h/w default number of lanes\n");
- return;
- }
-
- /* Set the number of lanes */
- val &= ~PORT_LINK_FAST_LINK_MODE;
- val &= ~PORT_LINK_MODE_MASK;
- switch (pci->num_lanes) {
- case 1:
- val |= PORT_LINK_MODE_1_LANES;
- break;
- case 2:
- val |= PORT_LINK_MODE_2_LANES;
- break;
- case 4:
- val |= PORT_LINK_MODE_4_LANES;
- break;
- case 8:
- val |= PORT_LINK_MODE_8_LANES;
- break;
- default:
- dev_err(pci->dev, "num-lanes %u: invalid value\n", pci->num_lanes);
- return;
- }
- dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, val);
-
- /* Set link width speed control register */
- val = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL);
- val &= ~PORT_LOGIC_LINK_WIDTH_MASK;
- switch (pci->num_lanes) {
- case 1:
- val |= PORT_LOGIC_LINK_WIDTH_1_LANES;
- break;
- case 2:
- val |= PORT_LOGIC_LINK_WIDTH_2_LANES;
- break;
- case 4:
- val |= PORT_LOGIC_LINK_WIDTH_4_LANES;
- break;
- case 8:
- val |= PORT_LOGIC_LINK_WIDTH_8_LANES;
- break;
- }
- dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
+ dw_pcie_link_set_max_link_width(pci, pci->num_lanes);
}
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (5 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 06/19] PCI: dwc: Add dw_pcie_link_set_max_link_width() Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-09-14 16:00 ` Bjorn Helgaas
2023-08-25 9:32 ` [PATCH v20 08/19] PCI: tegra194: Drop PCI_EXP_LNKSTA_NLW setting Yoshihiro Shimoda
` (13 subsequent siblings)
20 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Update dw_pcie_link_set_max_link_width() to set PCI_EXP_LNKCAP_MLW.
In accordance with the DW PCIe RC/EP HW manuals [1,2,3,...] aside with
the PORT_LINK_CTRL_OFF.LINK_CAPABLE and GEN2_CTRL_OFF.NUM_OF_LANES[8:0]
field there is another one which needs to be updated. It's
LINK_CAPABILITIES_REG.PCIE_CAP_MAX_LINK_WIDTH. If it isn't done at
the very least the maximum link-width capability CSR won't expose
the actual maximum capability.
[1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
Version 4.60a, March 2015, p.1032
[2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
Version 4.70a, March 2016, p.1065
[3] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
Version 4.90a, March 2016, p.1057
...
[X] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint,
Version 5.40a, March 2019, p.1396
[X+1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
Version 5.40a, March 2019, p.1266
Suggested-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
---
drivers/pci/controller/dwc/pcie-designware.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index 5cca34140d2a..c4998194fe74 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -730,7 +730,8 @@ static void dw_pcie_link_set_max_speed(struct dw_pcie *pci, u32 link_gen)
static void dw_pcie_link_set_max_link_width(struct dw_pcie *pci, u32 num_lanes)
{
- u32 lwsc, plc;
+ u32 lnkcap, lwsc, plc;
+ u8 cap;
if (!num_lanes)
return;
@@ -766,6 +767,12 @@ static void dw_pcie_link_set_max_link_width(struct dw_pcie *pci, u32 num_lanes)
}
dw_pcie_writel_dbi(pci, PCIE_PORT_LINK_CONTROL, plc);
dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, lwsc);
+
+ cap = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
+ lnkcap = dw_pcie_readl_dbi(pci, cap + PCI_EXP_LNKCAP);
+ lnkcap &= ~PCI_EXP_LNKCAP_MLW;
+ lnkcap |= FIELD_PREP(PCI_EXP_LNKCAP_MLW, num_lanes);
+ dw_pcie_writel_dbi(pci, cap + PCI_EXP_LNKCAP, lnkcap);
}
void dw_pcie_iatu_detect(struct dw_pcie *pci)
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling
2023-08-25 9:32 ` [PATCH v20 07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling Yoshihiro Shimoda
@ 2023-09-14 16:00 ` Bjorn Helgaas
2023-09-14 20:48 ` Serge Semin
0 siblings, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-14 16:00 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc
On Fri, Aug 25, 2023 at 06:32:07PM +0900, Yoshihiro Shimoda wrote:
> Update dw_pcie_link_set_max_link_width() to set PCI_EXP_LNKCAP_MLW.
> In accordance with the DW PCIe RC/EP HW manuals [1,2,3,...] aside with
> the PORT_LINK_CTRL_OFF.LINK_CAPABLE and GEN2_CTRL_OFF.NUM_OF_LANES[8:0]
> field there is another one which needs to be updated. It's
> LINK_CAPABILITIES_REG.PCIE_CAP_MAX_LINK_WIDTH. If it isn't done at
> the very least the maximum link-width capability CSR won't expose
> the actual maximum capability.
>
> [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> Version 4.60a, March 2015, p.1032
> [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> Version 4.70a, March 2016, p.1065
> [3] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> Version 4.90a, March 2016, p.1057
> ...
> [X] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint,
> Version 5.40a, March 2019, p.1396
> [X+1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> Version 5.40a, March 2019, p.1266
Is there value in keeping all four of these Root Port citations? I
assume that if you have the most recent one (X+1), it completely
obsoletes the older ones, so you should never have to look at the
older ones?
Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling
2023-09-14 16:00 ` Bjorn Helgaas
@ 2023-09-14 20:48 ` Serge Semin
2023-09-14 20:59 ` Bjorn Helgaas
0 siblings, 1 reply; 57+ messages in thread
From: Serge Semin @ 2023-09-14 20:48 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Yoshihiro Shimoda, jingoohan1, gustavo.pimentel, lpieralisi,
robh+dt, kw, manivannan.sadhasivam, bhelgaas, kishon,
krzysztof.kozlowski+dt, conor+dt, marek.vasut+renesas, linux-pci,
devicetree, linux-renesas-soc
On Thu, Sep 14, 2023 at 11:00:58AM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 25, 2023 at 06:32:07PM +0900, Yoshihiro Shimoda wrote:
> > Update dw_pcie_link_set_max_link_width() to set PCI_EXP_LNKCAP_MLW.
> > In accordance with the DW PCIe RC/EP HW manuals [1,2,3,...] aside with
> > the PORT_LINK_CTRL_OFF.LINK_CAPABLE and GEN2_CTRL_OFF.NUM_OF_LANES[8:0]
> > field there is another one which needs to be updated. It's
> > LINK_CAPABILITIES_REG.PCIE_CAP_MAX_LINK_WIDTH. If it isn't done at
> > the very least the maximum link-width capability CSR won't expose
> > the actual maximum capability.
> >
> > [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > Version 4.60a, March 2015, p.1032
> > [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > Version 4.70a, March 2016, p.1065
> > [3] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > Version 4.90a, March 2016, p.1057
> > ...
> > [X] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint,
> > Version 5.40a, March 2019, p.1396
> > [X+1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > Version 5.40a, March 2019, p.1266
>
> Is there value in keeping all four of these Root Port citations? I
> assume that if you have the most recent one (X+1), it completely
> obsoletes the older ones, so you should never have to look at the
> older ones?
In general the procedure may differ from one device version to
another. Though it doesn't concern DW PCIe IP-cores. So by citing all
these manuals I implied that all DW PCIe controllers expect the same
link-width initialization procedure. Keeping that in mind I guess the
text could be indeed simplified by keeping only two citations (note
[X] and [X+1] refer to the Root Port and End-point HW databooks of the
same IP-core version) and noting in the text that the procedure is
common for the older DW PCIe controllers too.
In anyway I wouldn't say that new IP-core databooks obsolete the
old one since the driver supports all old and new controllers. So
before introducing a generic procedure we need to make sure that it
will work for all the known to be supported devices. From that
perspective citing all the available databooks gets to make sense.
-Serge(y)
>
> Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling
2023-09-14 20:48 ` Serge Semin
@ 2023-09-14 20:59 ` Bjorn Helgaas
2023-09-14 21:25 ` Serge Semin
0 siblings, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-14 20:59 UTC (permalink / raw)
To: Serge Semin
Cc: Yoshihiro Shimoda, jingoohan1, gustavo.pimentel, lpieralisi,
robh+dt, kw, manivannan.sadhasivam, bhelgaas, kishon,
krzysztof.kozlowski+dt, conor+dt, marek.vasut+renesas, linux-pci,
devicetree, linux-renesas-soc
On Thu, Sep 14, 2023 at 11:48:39PM +0300, Serge Semin wrote:
> On Thu, Sep 14, 2023 at 11:00:58AM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 25, 2023 at 06:32:07PM +0900, Yoshihiro Shimoda wrote:
> > > Update dw_pcie_link_set_max_link_width() to set PCI_EXP_LNKCAP_MLW.
> > > In accordance with the DW PCIe RC/EP HW manuals [1,2,3,...] aside with
> > > the PORT_LINK_CTRL_OFF.LINK_CAPABLE and GEN2_CTRL_OFF.NUM_OF_LANES[8:0]
> > > field there is another one which needs to be updated. It's
> > > LINK_CAPABILITIES_REG.PCIE_CAP_MAX_LINK_WIDTH. If it isn't done at
> > > the very least the maximum link-width capability CSR won't expose
> > > the actual maximum capability.
> > >
> > > [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > > Version 4.60a, March 2015, p.1032
> > > [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > > Version 4.70a, March 2016, p.1065
> > > [3] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > > Version 4.90a, March 2016, p.1057
> > > ...
> > > [X] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint,
> > > Version 5.40a, March 2019, p.1396
> > > [X+1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > > Version 5.40a, March 2019, p.1266
>
> > Is there value in keeping all four of these Root Port citations? I
> > assume that if you have the most recent one (X+1), it completely
> > obsoletes the older ones, so you should never have to look at the
> > older ones?
>
> In general the procedure may differ from one device version to
> another. Though it doesn't concern DW PCIe IP-cores. So by citing all
> these manuals I implied that all DW PCIe controllers expect the same
> link-width initialization procedure. Keeping that in mind I guess the
> text could be indeed simplified by keeping only two citations (note
> [X] and [X+1] refer to the Root Port and End-point HW databooks of the
> same IP-core version) and noting in the text that the procedure is
> common for the older DW PCIe controllers too.
>
> In anyway I wouldn't say that new IP-core databooks obsolete the
> old one since the driver supports all old and new controllers. So
> before introducing a generic procedure we need to make sure that it
> will work for all the known to be supported devices. From that
> perspective citing all the available databooks gets to make sense.
You mean that instead of merely *adding* new details about new
devices, v5.40a might OMIT details specific to older devices covered
by v4.60a? That sounds like ... kind of an unhelpful way to manage
the spec, but if so, I see your point.
Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling
2023-09-14 20:59 ` Bjorn Helgaas
@ 2023-09-14 21:25 ` Serge Semin
0 siblings, 0 replies; 57+ messages in thread
From: Serge Semin @ 2023-09-14 21:25 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Yoshihiro Shimoda, jingoohan1, gustavo.pimentel, lpieralisi,
robh+dt, kw, manivannan.sadhasivam, bhelgaas, kishon,
krzysztof.kozlowski+dt, conor+dt, marek.vasut+renesas, linux-pci,
devicetree, linux-renesas-soc
On Thu, Sep 14, 2023 at 03:59:06PM -0500, Bjorn Helgaas wrote:
> On Thu, Sep 14, 2023 at 11:48:39PM +0300, Serge Semin wrote:
> > On Thu, Sep 14, 2023 at 11:00:58AM -0500, Bjorn Helgaas wrote:
> > > On Fri, Aug 25, 2023 at 06:32:07PM +0900, Yoshihiro Shimoda wrote:
> > > > Update dw_pcie_link_set_max_link_width() to set PCI_EXP_LNKCAP_MLW.
> > > > In accordance with the DW PCIe RC/EP HW manuals [1,2,3,...] aside with
> > > > the PORT_LINK_CTRL_OFF.LINK_CAPABLE and GEN2_CTRL_OFF.NUM_OF_LANES[8:0]
> > > > field there is another one which needs to be updated. It's
> > > > LINK_CAPABILITIES_REG.PCIE_CAP_MAX_LINK_WIDTH. If it isn't done at
> > > > the very least the maximum link-width capability CSR won't expose
> > > > the actual maximum capability.
> > > >
> > > > [1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > > > Version 4.60a, March 2015, p.1032
> > > > [2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > > > Version 4.70a, March 2016, p.1065
> > > > [3] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > > > Version 4.90a, March 2016, p.1057
> > > > ...
> > > > [X] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint,
> > > > Version 5.40a, March 2019, p.1396
> > > > [X+1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
> > > > Version 5.40a, March 2019, p.1266
> >
> > > Is there value in keeping all four of these Root Port citations? I
> > > assume that if you have the most recent one (X+1), it completely
> > > obsoletes the older ones, so you should never have to look at the
> > > older ones?
> >
> > In general the procedure may differ from one device version to
> > another. Though it doesn't concern DW PCIe IP-cores. So by citing all
> > these manuals I implied that all DW PCIe controllers expect the same
> > link-width initialization procedure. Keeping that in mind I guess the
> > text could be indeed simplified by keeping only two citations (note
> > [X] and [X+1] refer to the Root Port and End-point HW databooks of the
> > same IP-core version) and noting in the text that the procedure is
> > common for the older DW PCIe controllers too.
> >
> > In anyway I wouldn't say that new IP-core databooks obsolete the
> > old one since the driver supports all old and new controllers. So
> > before introducing a generic procedure we need to make sure that it
> > will work for all the known to be supported devices. From that
> > perspective citing all the available databooks gets to make sense.
>
> You mean that instead of merely *adding* new details about new
> devices, v5.40a might OMIT details specific to older devices covered
> by v4.60a? That sounds like ... kind of an unhelpful way to manage
> the spec, but if so, I see your point.
Right. I can't say for all the Synopsys IP-core documents but for
instance DW PCIe, DW uMCTL2 DDRC, DW *MAC docs tend to omit a lot of
changes history info. The most extensive list of changes is available
in the release notes provided as a separate document.
-Serge(y)
>
> Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH v20 08/19] PCI: tegra194: Drop PCI_EXP_LNKSTA_NLW setting
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (6 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 09/19] PCI: dwc: Add EDMA_UNROLL capability flag Yoshihiro Shimoda
` (12 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda, Thierry Reding,
Jonathan Hunter
dw_pcie_setup() is already setting PCI_EXP_LNKCAP_MLW to pcie->num_lanes
in the PCI_EXP_LNKCAP register for programming maximum link width. Hence,
remove the redundant setting here.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/pci/controller/dwc/pcie-tegra194.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index d51deda4fc9c..63abb048679c 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -917,12 +917,6 @@ static int tegra_pcie_dw_host_init(struct dw_pcie_rp *pp)
AMBA_ERROR_RESPONSE_CRS_SHIFT);
dw_pcie_writel_dbi(pci, PORT_LOGIC_AMBA_ERROR_RESPONSE_DEFAULT, val);
- /* Configure Max lane width from DT */
- val = dw_pcie_readl_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKCAP);
- val &= ~PCI_EXP_LNKCAP_MLW;
- val |= (pcie->num_lanes << PCI_EXP_LNKSTA_NLW_SHIFT);
- dw_pcie_writel_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKCAP, val);
-
/* Clear Slot Clock Configuration bit if SRNS configuration */
if (pcie->enable_srns) {
val_16 = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base +
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 09/19] PCI: dwc: Add EDMA_UNROLL capability flag
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (7 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 08/19] PCI: tegra194: Drop PCI_EXP_LNKSTA_NLW setting Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-09-14 16:09 ` Bjorn Helgaas
2023-08-25 9:32 ` [PATCH v20 10/19] PCI: dwc: Expose dw_pcie_ep_exit() to module Yoshihiro Shimoda
` (11 subsequent siblings)
20 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Renesas R-Car Gen4 PCIe controllers have an unexpected register value in
the eDMA CTRL register. So, add a new capability flag "EDMA_UNROLL"
which would force the unrolled eDMA mapping for the problematic device.
Suggested-by: Serge Semin <fancer.lancer@gmail.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/pci/controller/dwc/pcie-designware.c | 8 +++++++-
drivers/pci/controller/dwc/pcie-designware.h | 5 +++--
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index c4998194fe74..4812ce040f1e 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -883,8 +883,14 @@ static int dw_pcie_edma_find_chip(struct dw_pcie *pci)
* Indirect eDMA CSRs access has been completely removed since v5.40a
* thus no space is now reserved for the eDMA channels viewport and
* former DMA CTRL register is no longer fixed to FFs.
+ *
+ * Note that Renesas R-Car S4-8's PCIe controllers for unknown reason
+ * have zeros in the eDMA CTRL register even though the HW-manual
+ * explicitly states there must FFs if the unrolled mapping is enabled.
+ * For such cases the low-level drivers are supposed to manually
+ * activate the unrolled mapping to bypass the auto-detection procedure.
*/
- if (dw_pcie_ver_is_ge(pci, 540A))
+ if (dw_pcie_ver_is_ge(pci, 540A) || dw_pcie_cap_is(pci, EDMA_UNROLL))
val = 0xFFFFFFFF;
else
val = dw_pcie_readl_dbi(pci, PCIE_DMA_VIEWPORT_BASE + PCIE_DMA_CTRL);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index b731e38a71fc..c7759a508ca9 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -51,8 +51,9 @@
/* DWC PCIe controller capabilities */
#define DW_PCIE_CAP_REQ_RES 0
-#define DW_PCIE_CAP_IATU_UNROLL 1
-#define DW_PCIE_CAP_CDM_CHECK 2
+#define DW_PCIE_CAP_EDMA_UNROLL 1
+#define DW_PCIE_CAP_IATU_UNROLL 2
+#define DW_PCIE_CAP_CDM_CHECK 3
#define dw_pcie_cap_is(_pci, _cap) \
test_bit(DW_PCIE_CAP_ ## _cap, &(_pci)->caps)
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 09/19] PCI: dwc: Add EDMA_UNROLL capability flag
2023-08-25 9:32 ` [PATCH v20 09/19] PCI: dwc: Add EDMA_UNROLL capability flag Yoshihiro Shimoda
@ 2023-09-14 16:09 ` Bjorn Helgaas
2023-09-14 21:07 ` Serge Semin
0 siblings, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-14 16:09 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc
On Fri, Aug 25, 2023 at 06:32:09PM +0900, Yoshihiro Shimoda wrote:
> Renesas R-Car Gen4 PCIe controllers have an unexpected register value in
> the eDMA CTRL register. So, add a new capability flag "EDMA_UNROLL"
> which would force the unrolled eDMA mapping for the problematic device.
>
> Suggested-by: Serge Semin <fancer.lancer@gmail.com>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> drivers/pci/controller/dwc/pcie-designware.c | 8 +++++++-
> drivers/pci/controller/dwc/pcie-designware.h | 5 +++--
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index c4998194fe74..4812ce040f1e 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -883,8 +883,14 @@ static int dw_pcie_edma_find_chip(struct dw_pcie *pci)
> * Indirect eDMA CSRs access has been completely removed since v5.40a
> * thus no space is now reserved for the eDMA channels viewport and
> * former DMA CTRL register is no longer fixed to FFs.
> + *
> + * Note that Renesas R-Car S4-8's PCIe controllers for unknown reason
> + * have zeros in the eDMA CTRL register even though the HW-manual
> + * explicitly states there must FFs if the unrolled mapping is enabled.
> + * For such cases the low-level drivers are supposed to manually
> + * activate the unrolled mapping to bypass the auto-detection procedure.
> */
> - if (dw_pcie_ver_is_ge(pci, 540A))
> + if (dw_pcie_ver_is_ge(pci, 540A) || dw_pcie_cap_is(pci, EDMA_UNROLL))
> val = 0xFFFFFFFF;
> else
> val = dw_pcie_readl_dbi(pci, PCIE_DMA_VIEWPORT_BASE + PCIE_DMA_CTRL);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index b731e38a71fc..c7759a508ca9 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -51,8 +51,9 @@
>
> /* DWC PCIe controller capabilities */
> #define DW_PCIE_CAP_REQ_RES 0
> -#define DW_PCIE_CAP_IATU_UNROLL 1
> -#define DW_PCIE_CAP_CDM_CHECK 2
> +#define DW_PCIE_CAP_EDMA_UNROLL 1
> +#define DW_PCIE_CAP_IATU_UNROLL 2
> +#define DW_PCIE_CAP_CDM_CHECK 3
Why did you make the new DW_PCIE_CAP_EDMA_UNROLL "1" and shift all the
existing ones down? If they don't need to be ordered like this,
leaving the existing ones alone and making DW_PCIE_CAP_EDMA_UNROLL "3"
would be a simpler one-line diff.
> #define dw_pcie_cap_is(_pci, _cap) \
> test_bit(DW_PCIE_CAP_ ## _cap, &(_pci)->caps)
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 09/19] PCI: dwc: Add EDMA_UNROLL capability flag
2023-09-14 16:09 ` Bjorn Helgaas
@ 2023-09-14 21:07 ` Serge Semin
0 siblings, 0 replies; 57+ messages in thread
From: Serge Semin @ 2023-09-14 21:07 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Yoshihiro Shimoda, jingoohan1, gustavo.pimentel, lpieralisi,
robh+dt, kw, manivannan.sadhasivam, bhelgaas, kishon,
krzysztof.kozlowski+dt, conor+dt, marek.vasut+renesas, linux-pci,
devicetree, linux-renesas-soc
Hi Bjorn
On Thu, Sep 14, 2023 at 11:09:41AM -0500, Bjorn Helgaas wrote:
> On Fri, Aug 25, 2023 at 06:32:09PM +0900, Yoshihiro Shimoda wrote:
> > Renesas R-Car Gen4 PCIe controllers have an unexpected register value in
> > the eDMA CTRL register. So, add a new capability flag "EDMA_UNROLL"
> > which would force the unrolled eDMA mapping for the problematic device.
> >
> > Suggested-by: Serge Semin <fancer.lancer@gmail.com>
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > ---
> > drivers/pci/controller/dwc/pcie-designware.c | 8 +++++++-
> > drivers/pci/controller/dwc/pcie-designware.h | 5 +++--
> > 2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> > index c4998194fe74..4812ce040f1e 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -883,8 +883,14 @@ static int dw_pcie_edma_find_chip(struct dw_pcie *pci)
> > * Indirect eDMA CSRs access has been completely removed since v5.40a
> > * thus no space is now reserved for the eDMA channels viewport and
> > * former DMA CTRL register is no longer fixed to FFs.
> > + *
> > + * Note that Renesas R-Car S4-8's PCIe controllers for unknown reason
> > + * have zeros in the eDMA CTRL register even though the HW-manual
> > + * explicitly states there must FFs if the unrolled mapping is enabled.
> > + * For such cases the low-level drivers are supposed to manually
> > + * activate the unrolled mapping to bypass the auto-detection procedure.
> > */
> > - if (dw_pcie_ver_is_ge(pci, 540A))
> > + if (dw_pcie_ver_is_ge(pci, 540A) || dw_pcie_cap_is(pci, EDMA_UNROLL))
> > val = 0xFFFFFFFF;
> > else
> > val = dw_pcie_readl_dbi(pci, PCIE_DMA_VIEWPORT_BASE + PCIE_DMA_CTRL);
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> > index b731e38a71fc..c7759a508ca9 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -51,8 +51,9 @@
> >
> > /* DWC PCIe controller capabilities */
> > #define DW_PCIE_CAP_REQ_RES 0
> > -#define DW_PCIE_CAP_IATU_UNROLL 1
> > -#define DW_PCIE_CAP_CDM_CHECK 2
> > +#define DW_PCIE_CAP_EDMA_UNROLL 1
> > +#define DW_PCIE_CAP_IATU_UNROLL 2
> > +#define DW_PCIE_CAP_CDM_CHECK 3
>
> Why did you make the new DW_PCIE_CAP_EDMA_UNROLL "1" and shift all the
> existing ones down? If they don't need to be ordered like this,
> leaving the existing ones alone and making DW_PCIE_CAP_EDMA_UNROLL "3"
> would be a simpler one-line diff.
The discussion in framework of which this patch was born is available
here:
https://lore.kernel.org/linux-pci/20221121124400.1282768-6-yoshihiro.shimoda.uh@renesas.com/
So the patch is mainly what I suggested back then. Though in my case
DW_PCIE_CAP_EDMA_UNROLL was intended to have index 2.
Why didn't I add the unrolled DMA-capability macros to the tail of the
list? My intention was to have the IATU and EDMA unrolled capability
flags defined nearby for the sake of having a tiny bit better
readability since functionally they look similar but refer to the
different controller modules. IMO it was better to have the flags
functionally grouped than to save several diff lines.
-Serge(y)
>
> > #define dw_pcie_cap_is(_pci, _cap) \
> > test_bit(DW_PCIE_CAP_ ## _cap, &(_pci)->caps)
> > --
> > 2.25.1
> >
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH v20 10/19] PCI: dwc: Expose dw_pcie_ep_exit() to module
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (8 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 09/19] PCI: dwc: Add EDMA_UNROLL capability flag Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 11/19] PCI: dwc: Expose dw_pcie_write_dbi2() " Yoshihiro Shimoda
` (10 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Since no PCIe controller drivers call this, this change is not required
for now. But, Renesas R-Car Gen4 PCIe controller driver will call this
and if the controller driver is built as a kernel module, the following
build error happens. So, expose dw_pcie_ep_exit() for it.
ERROR: modpost: "dw_pcie_ep_exit" [drivers/pci/controller/dwc/pcie-rcar-gen4-ep-drv.ko] undefined!
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/pci/controller/dwc/pcie-designware-ep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index feeb2ea3c9c7..6eb897572d2b 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -696,6 +696,7 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
pci_epc_mem_exit(epc);
}
+EXPORT_SYMBOL_GPL(dw_pcie_ep_exit);
static unsigned int dw_pcie_ep_find_ext_capability(struct dw_pcie *pci, int cap)
{
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 11/19] PCI: dwc: Expose dw_pcie_write_dbi2() to module
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (9 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 10/19] PCI: dwc: Expose dw_pcie_ep_exit() to module Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 18:18 ` Serge Semin
2023-08-25 9:32 ` [PATCH v20 12/19] PCI: dwc: endpoint: Introduce .pre_init() and .deinit() Yoshihiro Shimoda
` (9 subsequent siblings)
20 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Since no PCIe controller drivers call this, this change is not required
for now. But, Renesas R-Car Gen4 PCIe controller driver will call this
and if the controller driver is built as a kernel module, the following
build error happens. So, expose dw_pcie_write_dbi2() for it.
ERROR: modpost: "dw_pcie_write_dbi2" [drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.ko] undefined!
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/pci/controller/dwc/pcie-designware.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
index 4812ce040f1e..0251fa1357f9 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -365,6 +365,7 @@ void dw_pcie_write_dbi2(struct dw_pcie *pci, u32 reg, size_t size, u32 val)
if (ret)
dev_err(pci->dev, "write DBI address failed\n");
}
+EXPORT_SYMBOL_GPL(dw_pcie_write_dbi2);
static inline void __iomem *dw_pcie_select_atu(struct dw_pcie *pci, u32 dir,
u32 index)
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 11/19] PCI: dwc: Expose dw_pcie_write_dbi2() to module
2023-08-25 9:32 ` [PATCH v20 11/19] PCI: dwc: Expose dw_pcie_write_dbi2() " Yoshihiro Shimoda
@ 2023-08-25 18:18 ` Serge Semin
0 siblings, 0 replies; 57+ messages in thread
From: Serge Semin @ 2023-08-25 18:18 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, linux-pci, devicetree,
linux-renesas-soc
On Fri, Aug 25, 2023 at 06:32:11PM +0900, Yoshihiro Shimoda wrote:
> Since no PCIe controller drivers call this, this change is not required
> for now. But, Renesas R-Car Gen4 PCIe controller driver will call this
> and if the controller driver is built as a kernel module, the following
> build error happens. So, expose dw_pcie_write_dbi2() for it.
>
> ERROR: modpost: "dw_pcie_write_dbi2" [drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.ko] undefined!
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
-Serge(y)
> ---
> drivers/pci/controller/dwc/pcie-designware.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index 4812ce040f1e..0251fa1357f9 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -365,6 +365,7 @@ void dw_pcie_write_dbi2(struct dw_pcie *pci, u32 reg, size_t size, u32 val)
> if (ret)
> dev_err(pci->dev, "write DBI address failed\n");
> }
> +EXPORT_SYMBOL_GPL(dw_pcie_write_dbi2);
>
> static inline void __iomem *dw_pcie_select_atu(struct dw_pcie *pci, u32 dir,
> u32 index)
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH v20 12/19] PCI: dwc: endpoint: Introduce .pre_init() and .deinit()
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (10 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 11/19] PCI: dwc: Expose dw_pcie_write_dbi2() " Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 13/19] dt-bindings: PCI: dwc: Update maxItems of reg and reg-names Yoshihiro Shimoda
` (8 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Renesas R-Car Gen4 PCIe controllers require vendor-specific
initialization before .init(). To use dw->dbi and dw->num-lanes
in the initialization code, introduce .pre_init() into struct
dw_pcie_ep_ops. Also introduce .deinit() to disable the controller
by using vendor-specific de-initialization.
Note that the ep_init in the struct dw_pcie_ep_ops should be renamed
to init later.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
---
drivers/pci/controller/dwc/pcie-designware-ep.c | 12 +++++++++++-
drivers/pci/controller/dwc/pcie-designware.h | 2 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 6eb897572d2b..aac0e5263f97 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -695,6 +695,9 @@ void dw_pcie_ep_exit(struct dw_pcie_ep *ep)
epc->mem->window.page_size);
pci_epc_mem_exit(epc);
+
+ if (ep->ops->deinit)
+ ep->ops->deinit(ep);
}
EXPORT_SYMBOL_GPL(dw_pcie_ep_exit);
@@ -798,6 +801,9 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
ep->phys_base = res->start;
ep->addr_size = resource_size(res);
+ if (ep->ops->pre_init)
+ ep->ops->pre_init(ep);
+
dw_pcie_version_detect(pci);
dw_pcie_iatu_detect(pci);
@@ -852,7 +858,7 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
ep->page_size);
if (ret < 0) {
dev_err(dev, "Failed to initialize address space\n");
- return ret;
+ goto err_ep_deinit;
}
ep->msi_mem = pci_epc_mem_alloc_addr(epc, &ep->msi_mem_phys,
@@ -898,6 +904,10 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
err_exit_epc_mem:
pci_epc_mem_exit(epc);
+err_ep_deinit:
+ if (ep->ops->deinit)
+ ep->ops->deinit(ep);
+
return ret;
}
EXPORT_SYMBOL_GPL(dw_pcie_ep_init);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index c7759a508ca9..b5040440b7c0 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -343,7 +343,9 @@ struct dw_pcie_rp {
};
struct dw_pcie_ep_ops {
+ void (*pre_init)(struct dw_pcie_ep *ep);
void (*ep_init)(struct dw_pcie_ep *ep);
+ void (*deinit)(struct dw_pcie_ep *ep);
int (*raise_irq)(struct dw_pcie_ep *ep, u8 func_no,
unsigned int type, u16 interrupt_num);
const struct pci_epc_features* (*get_features)(struct dw_pcie_ep *ep);
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 13/19] dt-bindings: PCI: dwc: Update maxItems of reg and reg-names
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (11 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 12/19] PCI: dwc: endpoint: Introduce .pre_init() and .deinit() Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 14/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host Yoshihiro Shimoda
` (7 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda, Rob Herring,
Manivannan Sadhasivam
Update maxItems of reg and reg-names on both host and endpoint
for supporting Renesas R-Car Gen4 PCIe controllers later.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
---
Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml | 4 ++--
Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
index 8fc2151691a4..cb727f60be0b 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie-ep.yaml
@@ -33,11 +33,11 @@ properties:
normal controller functioning. iATU memory IO region is also required
if the space is unrolled (IP-core version >= 4.80a).
minItems: 2
- maxItems: 5
+ maxItems: 6
reg-names:
minItems: 2
- maxItems: 5
+ maxItems: 6
items:
oneOf:
- description:
diff --git a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
index 1a83f0f65f19..0bfcfd6ccb5f 100644
--- a/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml
@@ -33,11 +33,11 @@ properties:
are required for the normal controller work. iATU memory IO region is
also required if the space is unrolled (IP-core version >= 4.80a).
minItems: 2
- maxItems: 5
+ maxItems: 6
reg-names:
minItems: 2
- maxItems: 5
+ maxItems: 6
items:
oneOf:
- description:
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 14/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (12 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 13/19] dt-bindings: PCI: dwc: Update maxItems of reg and reg-names Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-31 13:12 ` Geert Uytterhoeven
2023-08-25 9:32 ` [PATCH v20 15/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint Yoshihiro Shimoda
` (6 subsequent siblings)
20 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda, Rob Herring
Document bindings for Renesas R-Car Gen4 and R-Car S4-8 (R8A779F0)
PCIe host module.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
---
.../bindings/pci/rcar-gen4-pci-host.yaml | 123 ++++++++++++++++++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
new file mode 100644
index 000000000000..513a3416dd8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rcar-gen4-pci-host.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen4 PCIe Host
+
+maintainers:
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+allOf:
+ - $ref: snps,dw-pcie.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: renesas,r8a779f0-pcie # R-Car S4-8
+ - const: renesas,rcar-gen4-pcie # R-Car Gen4
+
+ reg:
+ maxItems: 6
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: atu
+ - const: dma
+ - const: app
+ - const: config
+
+ interrupts:
+ maxItems: 4
+
+ interrupt-names:
+ items:
+ - const: msi
+ - const: dma
+ - const: sft_ce
+ - const: app
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: ref
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ resets-names:
+ items:
+ - const: pwr
+
+ max-link-speed:
+ maximum: 4
+
+ num-lanes:
+ maximum: 4
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+ - resets
+ - reset-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a779f0-sysc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie: pcie@e65d0000 {
+ compatible = "renesas,r8a779f0-pcie", "renesas,rcar-gen4-pcie";
+ reg = <0 0xe65d0000 0 0x1000>, <0 0xe65d2000 0 0x0800>,
+ <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
+ <0 0xe65d6200 0 0x0e00>, <0 0xfe000000 0 0x400000>;
+ reg-names = "dbi", "dbi2", "atu", "dma", "app", "config";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ bus-range = <0x00 0xff>;
+ device_type = "pci";
+ ranges = <0x01000000 0 0x00000000 0 0xfe000000 0 0x00400000>,
+ <0x02000000 0 0x30000000 0 0x30000000 0 0x10000000>;
+ dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
+ interrupts = <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi", "dma", "sft_ce", "app";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 624>, <&clkref>;
+ clock-names = "core", "ref";
+ power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
+ resets = <&cpg 624>;
+ reset-names = "pwr";
+ num-lanes = <2>;
+ snps,enable-cdm-check;
+ max-link-speed = <4>;
+ };
+ };
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 14/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host
2023-08-25 9:32 ` [PATCH v20 14/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host Yoshihiro Shimoda
@ 2023-08-31 13:12 ` Geert Uytterhoeven
2023-09-01 1:13 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Geert Uytterhoeven @ 2023-08-31 13:12 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc, Rob Herring
Hi Shimoda-san,
On Fri, Aug 25, 2023 at 3:18 PM Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> Document bindings for Renesas R-Car Gen4 and R-Car S4-8 (R8A779F0)
> PCIe host module.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
> @@ -0,0 +1,123 @@
> + resets:
> + maxItems: 1
> +
> + resets-names:
reset-names
> + items:
> + - const: pwr
> +
> + max-link-speed:
> + maximum: 4
> +
> + num-lanes:
> + maximum: 4
> +
> +required:
> + - compatible
> + - reg
Missing "reg-names".
> + - interrupts
> + - clocks
> + - clock-names
> + - power-domains
> + - resets
> + - reset-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/r8a779f0-sysc.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pcie: pcie@e65d0000 {
> + compatible = "renesas,r8a779f0-pcie", "renesas,rcar-gen4-pcie";
> + reg = <0 0xe65d0000 0 0x1000>, <0 0xe65d2000 0 0x0800>,
> + <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
> + <0 0xe65d6200 0 0x0e00>, <0 0xfe000000 0 0x400000>;
The lenght "0x0e00" does not match your DTS patch
https://lore.kernel.org/linux-renesas-soc/20230828041434.2747699-2-yoshihiro.shimoda.uh@renesas.com
> + reg-names = "dbi", "dbi2", "atu", "dma", "app", "config";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + bus-range = <0x00 0xff>;
> + device_type = "pci";
> + ranges = <0x01000000 0 0x00000000 0 0xfe000000 0 0x00400000>,
> + <0x02000000 0 0x30000000 0 0x30000000 0 0x10000000>;
> + dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
> + interrupts = <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
What about SPI 419, 420, 421?
> + interrupt-names = "msi", "dma", "sft_ce", "app";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 624>, <&clkref>;
> + clock-names = "core", "ref";
> + power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
> + resets = <&cpg 624>;
> + reset-names = "pwr";
> + num-lanes = <2>;
> + snps,enable-cdm-check;
> + max-link-speed = <4>;
> + };
> + };
BTW, I think it would be good to make the order of the properties and
in the example match between the host and endpoint bindings, to make
the output of
"diff Documentation/devicetree/bindings/pci/rcar-gen4-pci-{host,ep}.yaml"
as small as possible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
> + - interrupts
> + - clocks
> + - clock-names
> + - power-domains
> + - resets
> + - reset-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/r8a779f0-sysc.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pcie: pcie@e65d0000 {
> + compatible = "renesas,r8a779f0-pcie", "renesas,rcar-gen4-pcie";
> + reg = <0 0xe65d0000 0 0x1000>, <0 0xe65d2000 0 0x0800>,
> + <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
> + <0 0xe65d6200 0 0x0e00>, <0 0xfe000000 0 0x400000>;
> + reg-names = "dbi", "dbi2", "atu", "dma", "app", "config";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + bus-range = <0x00 0xff>;
> + device_type = "pci";
> + ranges = <0x01000000 0 0x00000000 0 0xfe000000 0 0x00400000>,
> + <0x02000000 0 0x30000000 0 0x30000000 0 0x10000000>;
> + dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
> + interrupts = <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "msi", "dma", "sft_ce", "app";
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = <0 0 0 1 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 2 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 3 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> + <0 0 0 4 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 624>, <&clkref>;
> + clock-names = "core", "ref";
> + power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
> + resets = <&cpg 624>;
> + reset-names = "pwr";
> + num-lanes = <2>;
> + snps,enable-cdm-check;
> + max-link-speed = <4>;
> + };
> + };
> --
> 2.25.1
>
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 14/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host
2023-08-31 13:12 ` Geert Uytterhoeven
@ 2023-09-01 1:13 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-01 1:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Rob Herring
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Thursday, August 31, 2023 10:13 PM
>
> Hi Shimoda-san,
>
> On Fri, Aug 25, 2023 at 3:18 PM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> > Document bindings for Renesas R-Car Gen4 and R-Car S4-8 (R8A779F0)
> > PCIe host module.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
>
> Thanks for your patch!
Thank you for your review!
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
> > @@ -0,0 +1,123 @@
>
> > + resets:
> > + maxItems: 1
> > +
> > + resets-names:
>
> reset-names
Oops! I'll fix it.
> > + items:
> > + - const: pwr
> > +
> > + max-link-speed:
> > + maximum: 4
> > +
> > + num-lanes:
> > + maximum: 4
> > +
> > +required:
> > + - compatible
> > + - reg
>
> Missing "reg-names".
I got it. I'll add it.
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - power-domains
> > + - resets
> > + - reset-names
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + #include <dt-bindings/power/r8a779f0-sysc.h>
> > +
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + pcie: pcie@e65d0000 {
> > + compatible = "renesas,r8a779f0-pcie", "renesas,rcar-gen4-pcie";
> > + reg = <0 0xe65d0000 0 0x1000>, <0 0xe65d2000 0 0x0800>,
> > + <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
> > + <0 0xe65d6200 0 0x0e00>, <0 0xfe000000 0 0x400000>;
>
> The lenght "0x0e00" does not match your DTS patch
<snip URL>
It seemed my DTS patch was not correct. Also, as you mentioned on the other email [1],
I should add a reg for "phy". I'll revise the dt-bindings doc.
https://lore.kernel.org/all/CAMuHMdWrrwwY=8bySDVYc9jD9zdKbeNytDVUSm7vci6LN=g6Qg@mail.gmail.com/
>
> > + reg-names = "dbi", "dbi2", "atu", "dma", "app", "config";
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + bus-range = <0x00 0xff>;
> > + device_type = "pci";
> > + ranges = <0x01000000 0 0x00000000 0 0xfe000000 0 0x00400000>,
> > + <0x02000000 0 0x30000000 0 0x30000000 0 0x10000000>;
> > + dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
> > + interrupts = <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
>
> What about SPI 419, 420, 421?
These SPI interrupts cannot match the Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml.
Also, I cannot describe the detail of these SPI interrupts behavior because of the datasheet
doesn't mention the detail... So, I didn't describe them.
> > + interrupt-names = "msi", "dma", "sft_ce", "app";
> > + #interrupt-cells = <1>;
> > + interrupt-map-mask = <0 0 0 7>;
> > + interrupt-map = <0 0 0 1 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> > + <0 0 0 2 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> > + <0 0 0 3 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> > + <0 0 0 4 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 624>, <&clkref>;
> > + clock-names = "core", "ref";
> > + power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
> > + resets = <&cpg 624>;
> > + reset-names = "pwr";
> > + num-lanes = <2>;
> > + snps,enable-cdm-check;
> > + max-link-speed = <4>;
> > + };
> > + };
>
> BTW, I think it would be good to make the order of the properties and
> in the example match between the host and endpoint bindings, to make
> the output of
> "diff Documentation/devicetree/bindings/pci/rcar-gen4-pci-{host,ep}.yaml"
> as small as possible.
Thank you for your suggestion! I'll revise the dt-bindings doc.
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
>
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - power-domains
> > + - resets
> > + - reset-names
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + #include <dt-bindings/power/r8a779f0-sysc.h>
> > +
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + pcie: pcie@e65d0000 {
> > + compatible = "renesas,r8a779f0-pcie", "renesas,rcar-gen4-pcie";
> > + reg = <0 0xe65d0000 0 0x1000>, <0 0xe65d2000 0 0x0800>,
> > + <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
> > + <0 0xe65d6200 0 0x0e00>, <0 0xfe000000 0 0x400000>;
> > + reg-names = "dbi", "dbi2", "atu", "dma", "app", "config";
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + bus-range = <0x00 0xff>;
> > + device_type = "pci";
> > + ranges = <0x01000000 0 0x00000000 0 0xfe000000 0 0x00400000>,
> > + <0x02000000 0 0x30000000 0 0x30000000 0 0x10000000>;
> > + dma-ranges = <0x42000000 0 0x00000000 0 0x00000000 1 0x00000000>;
> > + interrupts = <GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "msi", "dma", "sft_ce", "app";
> > + #interrupt-cells = <1>;
> > + interrupt-map-mask = <0 0 0 7>;
> > + interrupt-map = <0 0 0 1 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> > + <0 0 0 2 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> > + <0 0 0 3 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>,
> > + <0 0 0 4 &gic GIC_SPI 416 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 624>, <&clkref>;
> > + clock-names = "core", "ref";
> > + power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
> > + resets = <&cpg 624>;
> > + reset-names = "pwr";
> > + num-lanes = <2>;
> > + snps,enable-cdm-check;
> > + max-link-speed = <4>;
> > + };
> > + };
> > --
> > 2.25.1
> >
>
>
> --
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH v20 15/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (13 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 14/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-31 13:16 ` Geert Uytterhoeven
2023-08-25 9:32 ` [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support Yoshihiro Shimoda
` (5 subsequent siblings)
20 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda, Rob Herring,
Manivannan Sadhasivam
Document bindings for Renesas R-Car Gen4 and R-Car S4-8 (R8A779F0)
PCIe endpoint module.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
---
.../bindings/pci/rcar-gen4-pci-ep.yaml | 106 ++++++++++++++++++
1 file changed, 106 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
diff --git a/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
new file mode 100644
index 000000000000..4e6be856104c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022-2023 Renesas Electronics Corp.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/rcar-gen4-pci-ep.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car Gen4 PCIe Endpoint
+
+maintainers:
+ - Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+
+allOf:
+ - $ref: snps,dw-pcie-ep.yaml#
+
+properties:
+ compatible:
+ items:
+ - const: renesas,r8a779f0-pcie-ep # R-Car S4-8
+ - const: renesas,rcar-gen4-pcie-ep # R-Car Gen4
+
+ reg:
+ maxItems: 6
+
+ reg-names:
+ items:
+ - const: dbi
+ - const: dbi2
+ - const: atu
+ - const: dma
+ - const: app
+ - const: addr_space
+
+ interrupts:
+ maxItems: 3
+
+ interrupt-names:
+ items:
+ - const: dma
+ - const: sft_ce
+ - const: app
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: ref
+
+ max-functions:
+ maximum: 2
+
+ max-link-speed:
+ maximum: 4
+
+ num-lanes:
+ maximum: 4
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+ - resets
+ - power-domains
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a779f0-sysc.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ pcie0_ep: pcie-ep@e65d0000 {
+ compatible = "renesas,r8a779f0-pcie-ep", "renesas,rcar-gen4-pcie-ep";
+ reg = <0 0xe65d0000 0 0x2000>, <0 0xe65d2800 0 0x0800>,
+ <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
+ <0 0xe65d6200 0 0x0e00>, <0 0xfe000000 0 0x400000>;
+ reg-names = "dbi", "dbi2", "atu", "dma", "app", "addr_space";
+ interrupts = <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "dma", "sft_ce", "app";
+ clocks = <&cpg CPG_MOD 624>, <&pcie0_clkref>;
+ clock-names = "core", "ref";
+ power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
+ resets = <&cpg 624>;
+ num-lanes = <2>;
+ max-link-speed = <4>;
+ max-functions = /bits/ 8 <2>;
+ };
+ };
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 15/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint
2023-08-25 9:32 ` [PATCH v20 15/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint Yoshihiro Shimoda
@ 2023-08-31 13:16 ` Geert Uytterhoeven
2023-09-01 1:13 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Geert Uytterhoeven @ 2023-08-31 13:16 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc, Rob Herring, Manivannan Sadhasivam
Hi Shimoda-san,
On Fri, Aug 25, 2023 at 3:57 PM Yoshihiro Shimoda
<yoshihiro.shimoda.uh@renesas.com> wrote:
> Document bindings for Renesas R-Car Gen4 and R-Car S4-8 (R8A779F0)
> PCIe endpoint module.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Thanks for your patch!
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
> @@ -0,0 +1,106 @@
> + resets:
> + maxItems: 1
Missing reset-names, cfr.
Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - resets
> + - power-domains
> + - clocks
> + - clock-names
Missing reset-names.
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/r8a779f0-sysc.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + pcie0_ep: pcie-ep@e65d0000 {
> + compatible = "renesas,r8a779f0-pcie-ep", "renesas,rcar-gen4-pcie-ep";
> + reg = <0 0xe65d0000 0 0x2000>, <0 0xe65d2800 0 0x0800>,
<0 0xe65d2800 0 0x0800> does not match your DTS patch
https://lore.kernel.org/linux-renesas-soc/20230828041434.2747699-2-yoshihiro.shimoda.uh@renesas.com
> + <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
> + <0 0xe65d6200 0 0x0e00>, <0 0xfe000000 0 0x400000>;
> + reg-names = "dbi", "dbi2", "atu", "dma", "app", "addr_space";
> + interrupts = <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
What about SPI 419, 420, 421?
> + interrupt-names = "dma", "sft_ce", "app";
> + clocks = <&cpg CPG_MOD 624>, <&pcie0_clkref>;
> + clock-names = "core", "ref";
> + power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
> + resets = <&cpg 624>;
> + num-lanes = <2>;
> + max-link-speed = <4>;
> + max-functions = /bits/ 8 <2>;
> + };
> + };
BTW, I think it would be good to make the order of the properties and
in the example match between the host and endpoint bindings, to make
the output of
"diff Documentation/devicetree/bindings/pci/rcar-gen4-pci-{host,ep}.yaml"
as small as possible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 15/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint
2023-08-31 13:16 ` Geert Uytterhoeven
@ 2023-09-01 1:13 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-01 1:13 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Rob Herring, Manivannan Sadhasivam
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Thursday, August 31, 2023 10:17 PM
>
> Hi Shimoda-san,
>
> On Fri, Aug 25, 2023 at 3:57 PM Yoshihiro Shimoda
> <yoshihiro.shimoda.uh@renesas.com> wrote:
> > Document bindings for Renesas R-Car Gen4 and R-Car S4-8 (R8A779F0)
> > PCIe endpoint module.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > Acked-by: Manivannan Sadhasivam <mani@kernel.org>
>
> Thanks for your patch!
Thank you for your review!
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
> > @@ -0,0 +1,106 @@
>
> > + resets:
> > + maxItems: 1
>
> Missing reset-names, cfr.
> Documentation/devicetree/bindings/pci/snps,dw-pcie-common.yaml
Oops! I'll add reset-names.
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - interrupts
> > + - resets
> > + - power-domains
> > + - clocks
> > + - clock-names
>
> Missing reset-names.
I'll add it.
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/r8a779f0-cpg-mssr.h>
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + #include <dt-bindings/power/r8a779f0-sysc.h>
> > +
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + pcie0_ep: pcie-ep@e65d0000 {
> > + compatible = "renesas,r8a779f0-pcie-ep", "renesas,rcar-gen4-pcie-ep";
> > + reg = <0 0xe65d0000 0 0x2000>, <0 0xe65d2800 0 0x0800>,
>
> <0 0xe65d2800 0 0x0800> does not match your DTS patch
<snip URL>
Oops. This example is not correct. I'll revise it.
>
> > + <0 0xe65d3000 0 0x2000>, <0 0xe65d5000 0 0x1200>,
> > + <0 0xe65d6200 0 0x0e00>, <0 0xfe000000 0 0x400000>;
> > + reg-names = "dbi", "dbi2", "atu", "dma", "app", "addr_space";
> > + interrupts = <GIC_SPI 417 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 422 IRQ_TYPE_LEVEL_HIGH>;
>
> What about SPI 419, 420, 421?
These SPI interrupts cannot match the Documentation/devicetree/bindings/pci/snps,dw-pcie.yaml.
Also, I cannot describe the detail of these SPI interrupts behavior because of the datasheet
doesn't mention the detail... So, I didn't describe them.
> > + interrupt-names = "dma", "sft_ce", "app";
> > + clocks = <&cpg CPG_MOD 624>, <&pcie0_clkref>;
> > + clock-names = "core", "ref";
> > + power-domains = <&sysc R8A779F0_PD_ALWAYS_ON>;
> > + resets = <&cpg 624>;
> > + num-lanes = <2>;
> > + max-link-speed = <4>;
> > + max-functions = /bits/ 8 <2>;
> > + };
> > + };
>
> BTW, I think it would be good to make the order of the properties and
> in the example match between the host and endpoint bindings, to make
> the output of
> "diff Documentation/devicetree/bindings/pci/rcar-gen4-pci-{host,ep}.yaml"
> as small as possible.
Thank you for your suggestion! I'll revise the dt-bindings doc.
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (14 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 15/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-09-14 16:34 ` Bjorn Helgaas
2023-09-14 16:58 ` Bjorn Helgaas
2023-08-25 9:32 ` [PATCH v20 17/19] PCI: rcar-gen4-ep: Add R-Car Gen4 PCIe Endpoint support Yoshihiro Shimoda
` (4 subsequent siblings)
20 siblings, 2 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Add R-Car Gen4 PCIe Host support. This controller is based on
Synopsys DesignWare PCIe, but this controller has vendor-specific
registers so that requires initialization code like mode setting
and retraining and so on.
To reduce code delta, adds some helper functions which are used by
both the host driver and the endpoint driver (which is added
immediately afterwards) into a separate file.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
---
drivers/pci/controller/dwc/Kconfig | 10 +
drivers/pci/controller/dwc/Makefile | 2 +
.../controller/dwc/pcie-rcar-gen4-host-drv.c | 135 +++++++++++
drivers/pci/controller/dwc/pcie-rcar-gen4.c | 227 ++++++++++++++++++
drivers/pci/controller/dwc/pcie-rcar-gen4.h | 44 ++++
5 files changed, 418 insertions(+)
create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c
create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4.c
create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4.h
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index ab96da43e0c2..3884a67e4d56 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -415,4 +415,14 @@ config PCIE_VISCONTI_HOST
Say Y here if you want PCIe controller support on Toshiba Visconti SoC.
This driver supports TMPV7708 SoC.
+config PCIE_RCAR_GEN4
+ tristate "Renesas R-Car Gen4 PCIe Host controller"
+ depends on ARCH_RENESAS || COMPILE_TEST
+ depends on PCI_MSI
+ select PCIE_DW_HOST
+ help
+ Say Y here if you want PCIe host controller support on R-Car Gen4 SoCs.
+ To compile this driver as a module, choose M here: the module will be
+ called pcie-rcar-gen4-host.ko. This uses the DesignWare core.
+
endmenu
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index bf5c311875a1..ab2c6bc16216 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
obj-$(CONFIG_PCIE_VISCONTI_HOST) += pcie-visconti.o
+pcie-rcar-gen4-host-objs := pcie-rcar-gen4.o pcie-rcar-gen4-host-drv.o
+obj-$(CONFIG_PCIE_RCAR_GEN4) += pcie-rcar-gen4-host.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c b/drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c
new file mode 100644
index 000000000000..bf62804a84dc
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PCIe host controller driver for Renesas R-Car Gen4 Series SoCs
+ * Copyright (C) 2022-2023 Renesas Electronics Corporation
+ */
+
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+
+#include "pcie-rcar-gen4.h"
+#include "pcie-designware.h"
+
+static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
+{
+ struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+ int ret;
+ u32 val;
+
+ gpiod_set_value_cansleep(dw->pe_rst, 1);
+
+ ret = rcar_gen4_pcie_common_init(rcar);
+ if (ret)
+ return ret;
+
+ /*
+ * According to the section 3.5.7.2 "RC Mode" in DWC PCIe Dual Mode
+ * Rev.5.20a, we should disable two BARs to avoid unnecessary memory
+ * assignment during device enumeration.
+ */
+ dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_0, 0x0);
+ dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_1, 0x0);
+
+ /* Enable MSI interrupt signal */
+ val = readl(rcar->base + PCIEINTSTS0EN);
+ val |= MSI_CTRL_INT;
+ writel(val, rcar->base + PCIEINTSTS0EN);
+
+ msleep(100); /* pe_rst requires 100msec delay */
+
+ gpiod_set_value_cansleep(dw->pe_rst, 0);
+
+ return 0;
+}
+
+static void rcar_gen4_pcie_host_deinit(struct dw_pcie_rp *pp)
+{
+ struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+
+ gpiod_set_value_cansleep(dw->pe_rst, 1);
+ rcar_gen4_pcie_common_deinit(rcar);
+}
+
+static const struct dw_pcie_host_ops rcar_gen4_pcie_host_ops = {
+ .host_init = rcar_gen4_pcie_host_init,
+ .host_deinit = rcar_gen4_pcie_host_deinit,
+};
+
+static int rcar_gen4_add_dw_pcie_rp(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie_rp *pp = &rcar->dw.pp;
+
+ pp->num_vectors = MAX_MSI_IRQS;
+ pp->ops = &rcar_gen4_pcie_host_ops;
+ rcar->mode = DW_PCIE_RC_TYPE;
+
+ return dw_pcie_host_init(pp);
+}
+
+static void rcar_gen4_remove_dw_pcie_rp(struct rcar_gen4_pcie *rcar)
+{
+ dw_pcie_host_deinit(&rcar->dw.pp);
+}
+
+static int rcar_gen4_pcie_probe(struct platform_device *pdev)
+{
+ struct rcar_gen4_pcie *rcar;
+ int err;
+
+ rcar = rcar_gen4_pcie_devm_alloc(pdev);
+ if (IS_ERR(rcar))
+ return PTR_ERR(rcar);
+
+ err = rcar_gen4_pcie_get_resources(rcar);
+ if (err)
+ return err;
+
+ err = rcar_gen4_pcie_prepare(rcar);
+ if (err)
+ return err;
+
+ err = rcar_gen4_add_dw_pcie_rp(rcar);
+ if (err)
+ goto err_unprepare;
+
+ return 0;
+
+err_unprepare:
+ rcar_gen4_pcie_unprepare(rcar);
+
+ return err;
+}
+
+static void rcar_gen4_pcie_remove(struct platform_device *pdev)
+{
+ struct rcar_gen4_pcie *rcar = platform_get_drvdata(pdev);
+
+ rcar_gen4_remove_dw_pcie_rp(rcar);
+ rcar_gen4_pcie_unprepare(rcar);
+}
+
+static const struct of_device_id rcar_gen4_pcie_of_match[] = {
+ { .compatible = "renesas,rcar-gen4-pcie", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rcar_gen4_pcie_of_match);
+
+static struct platform_driver rcar_gen4_pcie_driver = {
+ .driver = {
+ .name = "pcie-rcar-gen4",
+ .of_match_table = rcar_gen4_pcie_of_match,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ },
+ .probe = rcar_gen4_pcie_probe,
+ .remove_new = rcar_gen4_pcie_remove,
+};
+module_platform_driver(rcar_gen4_pcie_driver);
+
+MODULE_DESCRIPTION("Renesas R-Car Gen4 PCIe host controller driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
new file mode 100644
index 000000000000..6da4d816891b
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PCIe host/endpoint controller driver for Renesas R-Car Gen4 Series SoCs
+ * Copyright (C) 2022-2023 Renesas Electronics Corporation
+ */
+
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/of_device.h>
+#include <linux/pci.h>
+#include <linux/pm_runtime.h>
+#include <linux/reset.h>
+
+#include "pcie-rcar-gen4.h"
+#include "pcie-designware.h"
+
+/* Renesas-specific */
+#define PCIERSTCTRL1 0x0014
+#define APP_HOLD_PHY_RST BIT(16)
+#define APP_LTSSM_ENABLE BIT(0)
+
+#define RCAR_NUM_SPEED_CHANGE_RETRIES 10
+#define RCAR_MAX_LINK_SPEED 4
+
+static void rcar_gen4_pcie_ltssm_enable(struct rcar_gen4_pcie *rcar,
+ bool enable)
+{
+ u32 val;
+
+ val = readl(rcar->base + PCIERSTCTRL1);
+ if (enable) {
+ val |= APP_LTSSM_ENABLE;
+ val &= ~APP_HOLD_PHY_RST;
+ } else {
+ /*
+ * Since the datasheet of R-Car doesn't mention how to assert
+ * the APP_HOLD_PHY_RST, don't assert it again. Otherwise,
+ * hang-up issue happened in the dw_edma_core_off() when
+ * the controller didn't detect a PCI device.
+ */
+ val &= ~APP_LTSSM_ENABLE;
+ }
+ writel(val, rcar->base + PCIERSTCTRL1);
+}
+
+static int rcar_gen4_pcie_link_up(struct dw_pcie *dw)
+{
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+ u32 val, mask;
+
+ val = readl(rcar->base + PCIEINTSTS0);
+ mask = RDLH_LINK_UP | SMLH_LINK_UP;
+
+ return (val & mask) == mask;
+}
+
+/*
+ * Manually initiate the speed change. Return true if the change succeeded,
+ * false if the change didn't finish within certain periods.
+ */
+static bool rcar_gen4_pcie_speed_change(struct dw_pcie *dw)
+{
+ u32 val;
+ int i;
+
+ val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
+ val &= ~PORT_LOGIC_SPEED_CHANGE;
+ dw_pcie_writel_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
+
+ val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
+ val |= PORT_LOGIC_SPEED_CHANGE;
+ dw_pcie_writel_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
+
+ for (i = 0; i < RCAR_NUM_SPEED_CHANGE_RETRIES; i++) {
+ val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
+ if (!(val & PORT_LOGIC_SPEED_CHANGE))
+ return true;
+ usleep_range(10000, 11000);
+ }
+
+ return false;
+}
+
+/*
+ * Enable LTSSM of this controller and manually initiate the speed change.
+ * Always return true.
+ */
+static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
+{
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+ int i, changes;
+
+ rcar_gen4_pcie_ltssm_enable(rcar, true);
+
+ /*
+ * Require direct speed change with retrying here if the link_gen is
+ * PCIe Gen2 or higher.
+ */
+ changes = min_not_zero(dw->link_gen, RCAR_MAX_LINK_SPEED) - 1;
+
+ /*
+ * Since dw_pcie_setup_rc() sets it once, PCIe Gen2 will be trained.
+ * So, this needs remaining times for up to PCIe Gen4 if RC mode.
+ */
+ if (changes && rcar->mode == DW_PCIE_RC_TYPE)
+ changes--;
+
+ for (i = 0; i < changes; i++) {
+ if (!rcar_gen4_pcie_speed_change(dw))
+ break; /* No error because possible disconnected here if EP mode */
+ }
+
+ return 0;
+}
+
+static void rcar_gen4_pcie_stop_link(struct dw_pcie *dw)
+{
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+
+ rcar_gen4_pcie_ltssm_enable(rcar, false);
+}
+
+int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie *dw = &rcar->dw;
+ u32 val;
+ int ret;
+
+ ret = clk_bulk_prepare_enable(DW_PCIE_NUM_CORE_CLKS, dw->core_clks);
+ if (ret) {
+ dev_err(dw->dev, "Failed to enable ref clocks\n");
+ return ret;
+ }
+
+ if (!reset_control_status(dw->core_rsts[DW_PCIE_PWR_RST].rstc))
+ reset_control_assert(dw->core_rsts[DW_PCIE_PWR_RST].rstc);
+
+ val = readl(rcar->base + PCIEMSR0);
+ if (rcar->mode == DW_PCIE_RC_TYPE) {
+ val |= DEVICE_TYPE_RC;
+ } else if (rcar->mode == DW_PCIE_EP_TYPE) {
+ val |= DEVICE_TYPE_EP;
+ } else {
+ ret = -EINVAL;
+ goto err_unprepare;
+ }
+
+ if (dw->num_lanes < 4)
+ val |= BIFUR_MOD_SET_ON;
+
+ writel(val, rcar->base + PCIEMSR0);
+
+ ret = reset_control_deassert(dw->core_rsts[DW_PCIE_PWR_RST].rstc);
+ if (ret)
+ goto err_unprepare;
+
+ return 0;
+
+err_unprepare:
+ clk_bulk_disable_unprepare(DW_PCIE_NUM_CORE_CLKS, dw->core_clks);
+
+ return ret;
+}
+
+void rcar_gen4_pcie_common_deinit(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie *dw = &rcar->dw;
+
+ reset_control_assert(dw->core_rsts[DW_PCIE_PWR_RST].rstc);
+ clk_bulk_disable_unprepare(DW_PCIE_NUM_CORE_CLKS, dw->core_clks);
+}
+
+int rcar_gen4_pcie_prepare(struct rcar_gen4_pcie *rcar)
+{
+ struct device *dev = rcar->dw.dev;
+ int err;
+
+ pm_runtime_enable(dev);
+ err = pm_runtime_resume_and_get(dev);
+ if (err < 0) {
+ dev_err(dev, "Failed to resume/get Runtime PM\n");
+ pm_runtime_disable(dev);
+ }
+
+ return err;
+}
+
+void rcar_gen4_pcie_unprepare(struct rcar_gen4_pcie *rcar)
+{
+ struct device *dev = rcar->dw.dev;
+
+ pm_runtime_put(dev);
+ pm_runtime_disable(dev);
+}
+
+int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar)
+{
+ /* Renesas-specific registers */
+ rcar->base = devm_platform_ioremap_resource_byname(rcar->pdev, "app");
+
+ return PTR_ERR_OR_ZERO(rcar->base);
+}
+
+static const struct dw_pcie_ops dw_pcie_ops = {
+ .start_link = rcar_gen4_pcie_start_link,
+ .stop_link = rcar_gen4_pcie_stop_link,
+ .link_up = rcar_gen4_pcie_link_up,
+};
+
+struct rcar_gen4_pcie *rcar_gen4_pcie_devm_alloc(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rcar_gen4_pcie *rcar;
+
+ rcar = devm_kzalloc(dev, sizeof(*rcar), GFP_KERNEL);
+ if (!rcar)
+ return ERR_PTR(-ENOMEM);
+
+ rcar->dw.ops = &dw_pcie_ops;
+ rcar->dw.dev = dev;
+ rcar->pdev = pdev;
+ dw_pcie_cap_set(&rcar->dw, EDMA_UNROLL);
+ dw_pcie_cap_set(&rcar->dw, REQ_RES);
+ platform_set_drvdata(pdev, rcar);
+
+ return rcar;
+}
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.h b/drivers/pci/controller/dwc/pcie-rcar-gen4.h
new file mode 100644
index 000000000000..7cbb3767c2d4
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * PCIe host/endpoint controller driver for Renesas R-Car Gen4 Series SoCs
+ * Copyright (C) 2022-2023 Renesas Electronics Corporation
+ */
+
+#ifndef _PCIE_RCAR_GEN4_H_
+#define _PCIE_RCAR_GEN4_H_
+
+#include <linux/io.h>
+#include <linux/pci.h>
+
+#include "pcie-designware.h"
+
+/* Renesas-specific */
+#define PCIEMSR0 0x0000
+#define BIFUR_MOD_SET_ON BIT(0)
+#define DEVICE_TYPE_EP 0
+#define DEVICE_TYPE_RC BIT(4)
+
+#define PCIEINTSTS0 0x0084
+#define PCIEINTSTS0EN 0x0310
+#define MSI_CTRL_INT BIT(26)
+#define SMLH_LINK_UP BIT(7)
+#define RDLH_LINK_UP BIT(6)
+#define PCIEDMAINTSTSEN 0x0314
+#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
+
+struct rcar_gen4_pcie {
+ struct dw_pcie dw;
+ void __iomem *base;
+ struct platform_device *pdev;
+ enum dw_pcie_device_mode mode;
+};
+#define to_rcar_gen4_pcie(_dw) container_of(_dw, struct rcar_gen4_pcie, dw)
+
+int rcar_gen4_pcie_common_init(struct rcar_gen4_pcie *rcar);
+void rcar_gen4_pcie_common_deinit(struct rcar_gen4_pcie *rcar);
+int rcar_gen4_pcie_prepare(struct rcar_gen4_pcie *rcar);
+void rcar_gen4_pcie_unprepare(struct rcar_gen4_pcie *rcar);
+int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar);
+struct rcar_gen4_pcie *rcar_gen4_pcie_devm_alloc(struct platform_device *pdev);
+
+#endif /* _PCIE_RCAR_GEN4_H_ */
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
2023-08-25 9:32 ` [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support Yoshihiro Shimoda
@ 2023-09-14 16:34 ` Bjorn Helgaas
2023-09-15 9:37 ` Yoshihiro Shimoda
2023-09-14 16:58 ` Bjorn Helgaas
1 sibling, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-14 16:34 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc
On Fri, Aug 25, 2023 at 06:32:16PM +0900, Yoshihiro Shimoda wrote:
> Add R-Car Gen4 PCIe Host support. This controller is based on
> Synopsys DesignWare PCIe, but this controller has vendor-specific
> registers so that requires initialization code like mode setting
> and retraining and so on.
>
> To reduce code delta, adds some helper functions which are used by
> both the host driver and the endpoint driver (which is added
> immediately afterwards) into a separate file.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> ---
> drivers/pci/controller/dwc/Kconfig | 10 +
> drivers/pci/controller/dwc/Makefile | 2 +
> .../controller/dwc/pcie-rcar-gen4-host-drv.c | 135 +++++++++++
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 227 ++++++++++++++++++
> drivers/pci/controller/dwc/pcie-rcar-gen4.h | 44 ++++
> 5 files changed, 418 insertions(+)
> create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c
Is "pcie-rcar-gen4-host-drv.c" following some pattern? I don't see
"-drv" in any nearby filenames. Typical names are "-host.c" for host
driver and "-ep.c" for endpoint driver.
> create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4.c
> create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4.h
> +config PCIE_RCAR_GEN4
If you look through drivers/pci/controller/dwc/Kconfig, it's typical
to use a "_HOST" suffix on the symbol to enable host controller
drivers. Similarly, "_EP" suffix for endpoint drivers.
> + tristate "Renesas R-Car Gen4 PCIe Host controller"
> + depends on ARCH_RENESAS || COMPILE_TEST
> + depends on PCI_MSI
> + select PCIE_DW_HOST
> +static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> + int ret;
> + u32 val;
> +
> + gpiod_set_value_cansleep(dw->pe_rst, 1);
> +
> + ret = rcar_gen4_pcie_common_init(rcar);
> + if (ret)
> + return ret;
> +
> + /*
> + * According to the section 3.5.7.2 "RC Mode" in DWC PCIe Dual Mode
> + * Rev.5.20a, we should disable two BARs to avoid unnecessary memory
> + * assignment during device enumeration.
> + */
> + dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_0, 0x0);
> + dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_1, 0x0);
> +
> + /* Enable MSI interrupt signal */
> + val = readl(rcar->base + PCIEINTSTS0EN);
> + val |= MSI_CTRL_INT;
> + writel(val, rcar->base + PCIEINTSTS0EN);
> +
> + msleep(100); /* pe_rst requires 100msec delay */
Can we include a spec reference for this delay? Ideally this would be
a #define and likely shared across drivers.
> + gpiod_set_value_cansleep(dw->pe_rst, 0);
> +
> + return 0;
> +}
> + * Manually initiate the speed change. Return true if the change succeeded,
> + * false if the change didn't finish within certain periods.
> + */
> +static bool rcar_gen4_pcie_speed_change(struct dw_pcie *dw)
This looks like it should return int, e.g., 0 for success, negative
for failure. Boolean functions ideally would not have side effects
and the name would be a condition that can be true or false.
> +{
> + u32 val;
> + int i;
> +
> + val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
> + val &= ~PORT_LOGIC_SPEED_CHANGE;
> + dw_pcie_writel_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> +
> + val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
> + val |= PORT_LOGIC_SPEED_CHANGE;
> + dw_pcie_writel_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> +
> + for (i = 0; i < RCAR_NUM_SPEED_CHANGE_RETRIES; i++) {
> + val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
> + if (!(val & PORT_LOGIC_SPEED_CHANGE))
> + return true;
> + usleep_range(10000, 11000);
Where did these values (num retries and sleep duration) come from?
Can we include a spec citation for them?
> + }
> +
> + return false;
> +}
> +
> +/*
> + * Enable LTSSM of this controller and manually initiate the speed change.
> + * Always return true.
This doesn't return "true". It returns *0*, which is a perfectly good
"success" value, but it isn't "true", which would be a non-zero value.
> + */
> +static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
> +{
> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> + int i, changes;
> +
> + rcar_gen4_pcie_ltssm_enable(rcar, true);
> +
> + /*
> + * Require direct speed change with retrying here if the link_gen is
> + * PCIe Gen2 or higher.
> + */
> + changes = min_not_zero(dw->link_gen, RCAR_MAX_LINK_SPEED) - 1;
> +
> + /*
> + * Since dw_pcie_setup_rc() sets it once, PCIe Gen2 will be trained.
> + * So, this needs remaining times for up to PCIe Gen4 if RC mode.
> + */
> + if (changes && rcar->mode == DW_PCIE_RC_TYPE)
> + changes--;
> +
> + for (i = 0; i < changes; i++) {
> + if (!rcar_gen4_pcie_speed_change(dw))
> + break; /* No error because possible disconnected here if EP mode */
Rest of the file fits in 80 columns, it'd be nice if the comment did
too.
> + }
> +
> + return 0;
> +}
> +#define PCIEMSR0 0x0000
> +#define BIFUR_MOD_SET_ON BIT(0)
> +#define DEVICE_TYPE_EP 0
> +#define DEVICE_TYPE_RC BIT(4)
> +
> +#define PCIEINTSTS0 0x0084
> +#define PCIEINTSTS0EN 0x0310
> +#define MSI_CTRL_INT BIT(26)
> +#define SMLH_LINK_UP BIT(7)
> +#define RDLH_LINK_UP BIT(6)
> +#define PCIEDMAINTSTSEN 0x0314
> +#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
These register offsets are hard to decode whenthey'reallruntogether.
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
2023-09-14 16:34 ` Bjorn Helgaas
@ 2023-09-15 9:37 ` Yoshihiro Shimoda
2023-09-15 20:38 ` Bjorn Helgaas
0 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-15 9:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hi Bjorn,
> From: Bjorn Helgaas, Sent: Friday, September 15, 2023 1:35 AM
>
> On Fri, Aug 25, 2023 at 06:32:16PM +0900, Yoshihiro Shimoda wrote:
> > Add R-Car Gen4 PCIe Host support. This controller is based on
> > Synopsys DesignWare PCIe, but this controller has vendor-specific
> > registers so that requires initialization code like mode setting
> > and retraining and so on.
> >
> > To reduce code delta, adds some helper functions which are used by
> > both the host driver and the endpoint driver (which is added
> > immediately afterwards) into a separate file.
> >
> > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > ---
> > drivers/pci/controller/dwc/Kconfig | 10 +
> > drivers/pci/controller/dwc/Makefile | 2 +
> > .../controller/dwc/pcie-rcar-gen4-host-drv.c | 135 +++++++++++
> > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 227 ++++++++++++++++++
> > drivers/pci/controller/dwc/pcie-rcar-gen4.h | 44 ++++
> > 5 files changed, 418 insertions(+)
> > create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c
>
> Is "pcie-rcar-gen4-host-drv.c" following some pattern? I don't see
> "-drv" in any nearby filenames. Typical names are "-host.c" for host
> driver and "-ep.c" for endpoint driver.
This is not following some pattern on pcie subsystem. But, some other subsystems
have "*drv.c" filenames. Manivannan suggested the filenames to rename the module
filenames [1].
< Now >
The source code filenames : pcie-rcar-gen4-{host,ep}-drv.c
The module filenames : pcie-rcar-gen4-{host,ep}.ko
< Previous >
The source code filenames : pcie-rcar-gen4-{host,ep}.c
The module filenames : pcie-rcar-gen4-{host,ep}-drv.ko
[1]
https://lore.kernel.org/linux-pci/20230724122820.GM6291@thinkpad/
I don't have a strong opinion on which filenames are good.
> > create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4.c
> > create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4.h
>
> > +config PCIE_RCAR_GEN4
>
> If you look through drivers/pci/controller/dwc/Kconfig, it's typical
> to use a "_HOST" suffix on the symbol to enable host controller
> drivers. Similarly, "_EP" suffix for endpoint drivers.
I got it. I'll rename this to PCIE_RCAR_GEN4_HOST.
> > + tristate "Renesas R-Car Gen4 PCIe Host controller"
> > + depends on ARCH_RENESAS || COMPILE_TEST
> > + depends on PCI_MSI
> > + select PCIE_DW_HOST
>
> > +static int rcar_gen4_pcie_host_init(struct dw_pcie_rp *pp)
> > +{
> > + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> > + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> > + int ret;
> > + u32 val;
> > +
> > + gpiod_set_value_cansleep(dw->pe_rst, 1);
> > +
> > + ret = rcar_gen4_pcie_common_init(rcar);
> > + if (ret)
> > + return ret;
> > +
> > + /*
> > + * According to the section 3.5.7.2 "RC Mode" in DWC PCIe Dual Mode
> > + * Rev.5.20a, we should disable two BARs to avoid unnecessary memory
> > + * assignment during device enumeration.
> > + */
> > + dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_0, 0x0);
> > + dw_pcie_writel_dbi2(dw, PCI_BASE_ADDRESS_1, 0x0);
> > +
> > + /* Enable MSI interrupt signal */
> > + val = readl(rcar->base + PCIEINTSTS0EN);
> > + val |= MSI_CTRL_INT;
> > + writel(val, rcar->base + PCIEINTSTS0EN);
> > +
> > + msleep(100); /* pe_rst requires 100msec delay */
>
> Can we include a spec reference for this delay? Ideally this would be
> a #define and likely shared across drivers.
I think so. Some other PCIe drivers also call "msleep(100)".
So, I'll add a #define into drivers/pci/pci.h.
> > + gpiod_set_value_cansleep(dw->pe_rst, 0);
> > +
> > + return 0;
> > +}
>
> > + * Manually initiate the speed change. Return true if the change succeeded,
> > + * false if the change didn't finish within certain periods.
> > + */
> > +static bool rcar_gen4_pcie_speed_change(struct dw_pcie *dw)
>
> This looks like it should return int, e.g., 0 for success, negative
> for failure. Boolean functions ideally would not have side effects
> and the name would be a condition that can be true or false.
I got it. I'll fix it.
> > +{
> > + u32 val;
> > + int i;
> > +
> > + val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
> > + val &= ~PORT_LOGIC_SPEED_CHANGE;
> > + dw_pcie_writel_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> > +
> > + val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
> > + val |= PORT_LOGIC_SPEED_CHANGE;
> > + dw_pcie_writel_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL, val);
> > +
> > + for (i = 0; i < RCAR_NUM_SPEED_CHANGE_RETRIES; i++) {
> > + val = dw_pcie_readl_dbi(dw, PCIE_LINK_WIDTH_SPEED_CONTROL);
> > + if (!(val & PORT_LOGIC_SPEED_CHANGE))
> > + return true;
> > + usleep_range(10000, 11000);
>
> Where did these values (num retries and sleep duration) come from?
> Can we include a spec citation for them?
These values came from my investigation. I could not find any spec
from the databook.
> > + }
> > +
> > + return false;
> > +}
> > +
> > +/*
> > + * Enable LTSSM of this controller and manually initiate the speed change.
> > + * Always return true.
>
> This doesn't return "true". It returns *0*, which is a perfectly good
> "success" value, but it isn't "true", which would be a non-zero value.
Oops. I'll fix the comment.
> > + */
> > +static int rcar_gen4_pcie_start_link(struct dw_pcie *dw)
> > +{
> > + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> > + int i, changes;
> > +
> > + rcar_gen4_pcie_ltssm_enable(rcar, true);
> > +
> > + /*
> > + * Require direct speed change with retrying here if the link_gen is
> > + * PCIe Gen2 or higher.
> > + */
> > + changes = min_not_zero(dw->link_gen, RCAR_MAX_LINK_SPEED) - 1;
> > +
> > + /*
> > + * Since dw_pcie_setup_rc() sets it once, PCIe Gen2 will be trained.
> > + * So, this needs remaining times for up to PCIe Gen4 if RC mode.
> > + */
> > + if (changes && rcar->mode == DW_PCIE_RC_TYPE)
> > + changes--;
> > +
> > + for (i = 0; i < changes; i++) {
> > + if (!rcar_gen4_pcie_speed_change(dw))
> > + break; /* No error because possible disconnected here if EP mode */
>
> Rest of the file fits in 80 columns, it'd be nice if the comment did
> too.
I got it. I'll fix this somehow.
> > + }
> > +
> > + return 0;
> > +}
>
> > +#define PCIEMSR0 0x0000
> > +#define BIFUR_MOD_SET_ON BIT(0)
> > +#define DEVICE_TYPE_EP 0
> > +#define DEVICE_TYPE_RC BIT(4)
> > +
> > +#define PCIEINTSTS0 0x0084
> > +#define PCIEINTSTS0EN 0x0310
> > +#define MSI_CTRL_INT BIT(26)
> > +#define SMLH_LINK_UP BIT(7)
> > +#define RDLH_LINK_UP BIT(6)
> > +#define PCIEDMAINTSTSEN 0x0314
> > +#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
>
> These register offsets are hard to decode whenthey'reallruntogether.
Unfortunately, these registers' offset names are from the datasheet.
Perhaps, adding full register names as comments like below are helpful:
-----
/* PCIe Interrupt Status 0 */
+#define PCIEINTSTS0 0x0084
/* PCIe DMA Interrupt Status Enable */
#define PCIEDMAINTSTSEN 0x0314
#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
-----
Best regards,
Yoshihiro Shimoda
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
2023-09-15 9:37 ` Yoshihiro Shimoda
@ 2023-09-15 20:38 ` Bjorn Helgaas
2023-09-19 7:03 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-15 20:38 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
On Fri, Sep 15, 2023 at 09:37:15AM +0000, Yoshihiro Shimoda wrote:
> > From: Bjorn Helgaas, Sent: Friday, September 15, 2023 1:35 AM
> > On Fri, Aug 25, 2023 at 06:32:16PM +0900, Yoshihiro Shimoda wrote:
> > > Add R-Car Gen4 PCIe Host support. This controller is based on
> > > Synopsys DesignWare PCIe, but this controller has vendor-specific
> > > registers so that requires initialization code like mode setting
> > > and retraining and so on.
> > >
> > > To reduce code delta, adds some helper functions which are used by
> > > both the host driver and the endpoint driver (which is added
> > > immediately afterwards) into a separate file.
> > >
> > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > > ---
> > > drivers/pci/controller/dwc/Kconfig | 10 +
> > > drivers/pci/controller/dwc/Makefile | 2 +
> > > .../controller/dwc/pcie-rcar-gen4-host-drv.c | 135 +++++++++++
> > > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 227 ++++++++++++++++++
> > > drivers/pci/controller/dwc/pcie-rcar-gen4.h | 44 ++++
> > > 5 files changed, 418 insertions(+)
> > > create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c
> >
> > Is "pcie-rcar-gen4-host-drv.c" following some pattern? I don't see
> > "-drv" in any nearby filenames. Typical names are "-host.c" for host
> > driver and "-ep.c" for endpoint driver.
>
> This is not following some pattern on pcie subsystem. But, some
> other subsystems have "*drv.c" filenames. Manivannan suggested the
> filenames to rename the module filenames [1].
>
> < Now >
> The source code filenames : pcie-rcar-gen4-{host,ep}-drv.c
> The module filenames : pcie-rcar-gen4-{host,ep}.ko
>
> < Previous >
> The source code filenames : pcie-rcar-gen4-{host,ep}.c
> The module filenames : pcie-rcar-gen4-{host,ep}-drv.ko
>
> [1]
> https://lore.kernel.org/linux-pci/20230724122820.GM6291@thinkpad/
>
> I don't have a strong opinion on which filenames are good.
I have an opinion :) I think splitting this up into four files is way
more complicated than it needs to be. This is all for driving a
single piece of hardware, and I don't think there's enough benefit to
split it into separate files.
Most drivers, even those that support both host and endpoint mode, are
in a single file, e.g., pcie-artpec6.c, pci-imx6.c, pcie-keembay.c,
pcie-tegra194.c, pci-dra7xx.c, pci-keystone.c.
That makes the Makefile very simple and there's only one module name
to worry about.
> > > + msleep(100); /* pe_rst requires 100msec delay */
> >
> > Can we include a spec reference for this delay? Ideally this would be
> > a #define and likely shared across drivers.
>
> I think so. Some other PCIe drivers also call "msleep(100)".
> So, I'll add a #define into drivers/pci/pci.h.
Yes. I'm trying to move away from "msleep(100)" for everybody so we
can make sure all the drivers include the appropriate delays and
they're all based on the same reasoning.
> > > +#define PCIEDMAINTSTSEN 0x0314
> > > +#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
> >
> > These register offsets are hard to decode whenthey'reallruntogether.
>
> Unfortunately, these registers' offset names are from the datasheet.
> Perhaps, adding full register names as comments like below are helpful:
> -----
> /* PCIe Interrupt Status 0 */
> +#define PCIEINTSTS0 0x0084
>
> /* PCIe DMA Interrupt Status Enable */
> #define PCIEDMAINTSTSEN 0x0314
> #define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
It's good to use names from the datasheet. The comments should be
enough.
Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
2023-09-15 20:38 ` Bjorn Helgaas
@ 2023-09-19 7:03 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-19 7:03 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hello Bjorn,
> From: Bjorn Helgaas, Sent: Saturday, September 16, 2023 5:39 AM
>
> On Fri, Sep 15, 2023 at 09:37:15AM +0000, Yoshihiro Shimoda wrote:
> > > From: Bjorn Helgaas, Sent: Friday, September 15, 2023 1:35 AM
> > > On Fri, Aug 25, 2023 at 06:32:16PM +0900, Yoshihiro Shimoda wrote:
> > > > Add R-Car Gen4 PCIe Host support. This controller is based on
> > > > Synopsys DesignWare PCIe, but this controller has vendor-specific
> > > > registers so that requires initialization code like mode setting
> > > > and retraining and so on.
> > > >
> > > > To reduce code delta, adds some helper functions which are used by
> > > > both the host driver and the endpoint driver (which is added
> > > > immediately afterwards) into a separate file.
> > > >
> > > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > > > Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
> > > > ---
> > > > drivers/pci/controller/dwc/Kconfig | 10 +
> > > > drivers/pci/controller/dwc/Makefile | 2 +
> > > > .../controller/dwc/pcie-rcar-gen4-host-drv.c | 135 +++++++++++
> > > > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 227 ++++++++++++++++++
> > > > drivers/pci/controller/dwc/pcie-rcar-gen4.h | 44 ++++
> > > > 5 files changed, 418 insertions(+)
> > > > create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c
> > >
> > > Is "pcie-rcar-gen4-host-drv.c" following some pattern? I don't see
> > > "-drv" in any nearby filenames. Typical names are "-host.c" for host
> > > driver and "-ep.c" for endpoint driver.
> >
> > This is not following some pattern on pcie subsystem. But, some
> > other subsystems have "*drv.c" filenames. Manivannan suggested the
> > filenames to rename the module filenames [1].
> >
> > < Now >
> > The source code filenames : pcie-rcar-gen4-{host,ep}-drv.c
> > The module filenames : pcie-rcar-gen4-{host,ep}.ko
> >
> > < Previous >
> > The source code filenames : pcie-rcar-gen4-{host,ep}.c
> > The module filenames : pcie-rcar-gen4-{host,ep}-drv.ko
> >
> > [1]
> > https://lore.kernel.org/linux-pci/20230724122820.GM6291@thinkpad/
> >
> > I don't have a strong opinion on which filenames are good.
>
> I have an opinion :) I think splitting this up into four files is way
> more complicated than it needs to be. This is all for driving a
> single piece of hardware, and I don't think there's enough benefit to
> split it into separate files.
Thank you for your suggestion! :)
> Most drivers, even those that support both host and endpoint mode, are
> in a single file, e.g., pcie-artpec6.c, pci-imx6.c, pcie-keembay.c,
> pcie-tegra194.c, pci-dra7xx.c, pci-keystone.c.
I got it. I realized that pcie-tegra194.c and pci-dra7xx.c support
both host and endpoint modes without "-host.c" and "-ep.c" files.
So, I'll merge all four files into one file.
> That makes the Makefile very simple and there's only one module name
> to worry about.
I got it.
> > > > + msleep(100); /* pe_rst requires 100msec delay */
> > >
> > > Can we include a spec reference for this delay? Ideally this would be
> > > a #define and likely shared across drivers.
> >
> > I think so. Some other PCIe drivers also call "msleep(100)".
> > So, I'll add a #define into drivers/pci/pci.h.
>
> Yes. I'm trying to move away from "msleep(100)" for everybody so we
> can make sure all the drivers include the appropriate delays and
> they're all based on the same reasoning.
I got it.
> > > > +#define PCIEDMAINTSTSEN 0x0314
> > > > +#define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
> > >
> > > These register offsets are hard to decode whenthey'reallruntogether.
> >
> > Unfortunately, these registers' offset names are from the datasheet.
> > Perhaps, adding full register names as comments like below are helpful:
> > -----
> > /* PCIe Interrupt Status 0 */
> > +#define PCIEINTSTS0 0x0084
> >
> > /* PCIe DMA Interrupt Status Enable */
> > #define PCIEDMAINTSTSEN 0x0314
> > #define PCIEDMAINTSTSEN_INIT GENMASK(15, 0)
>
> It's good to use names from the datasheet. The comments should be
> enough.
I got it.
Best regards,
Yoshihiro Shimoda
> Bjorn
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
2023-08-25 9:32 ` [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support Yoshihiro Shimoda
2023-09-14 16:34 ` Bjorn Helgaas
@ 2023-09-14 16:58 ` Bjorn Helgaas
2023-09-15 9:37 ` Yoshihiro Shimoda
1 sibling, 1 reply; 57+ messages in thread
From: Bjorn Helgaas @ 2023-09-14 16:58 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc
On Fri, Aug 25, 2023 at 06:32:16PM +0900, Yoshihiro Shimoda wrote:
> Add R-Car Gen4 PCIe Host support. This controller is based on
> Synopsys DesignWare PCIe, but this controller has vendor-specific
> registers so that requires initialization code like mode setting
> and retraining and so on.
> +config PCIE_RCAR_GEN4
> + tristate "Renesas R-Car Gen4 PCIe Host controller"
The config prompt that matches the other drivers would be:
tristate "Renesas R-Car Gen4 PCIe controller (host mode)"
Similarly for the endpoint driver.
^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
2023-09-14 16:58 ` Bjorn Helgaas
@ 2023-09-15 9:37 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-15 9:37 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, bhelgaas@google.com,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hi Bjorn,
> From: Bjorn Helgaas, Sent: Friday, September 15, 2023 1:59 AM
>
> On Fri, Aug 25, 2023 at 06:32:16PM +0900, Yoshihiro Shimoda wrote:
> > Add R-Car Gen4 PCIe Host support. This controller is based on
> > Synopsys DesignWare PCIe, but this controller has vendor-specific
> > registers so that requires initialization code like mode setting
> > and retraining and so on.
>
> > +config PCIE_RCAR_GEN4
> > + tristate "Renesas R-Car Gen4 PCIe Host controller"
>
> The config prompt that matches the other drivers would be:
>
> tristate "Renesas R-Car Gen4 PCIe controller (host mode)"
>
> Similarly for the endpoint driver.
I got it. I'll fix them.
Best regards,
Yoshihiro Shimoda
^ permalink raw reply [flat|nested] 57+ messages in thread
* [PATCH v20 17/19] PCI: rcar-gen4-ep: Add R-Car Gen4 PCIe Endpoint support
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (15 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 18/19] MAINTAINERS: Update PCI DRIVER FOR RENESAS R-CAR for R-Car Gen4 Yoshihiro Shimoda
` (3 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda
Add R-Car Gen4 PCIe Endpoint support. This controller is based on
Synopsys DesignWare PCIe.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
---
drivers/pci/controller/dwc/Kconfig | 10 +
drivers/pci/controller/dwc/Makefile | 2 +
.../controller/dwc/pcie-rcar-gen4-ep-drv.c | 173 ++++++++++++++++++
3 files changed, 185 insertions(+)
create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4-ep-drv.c
diff --git a/drivers/pci/controller/dwc/Kconfig b/drivers/pci/controller/dwc/Kconfig
index 3884a67e4d56..65a7c56e64bd 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -425,4 +425,14 @@ config PCIE_RCAR_GEN4
To compile this driver as a module, choose M here: the module will be
called pcie-rcar-gen4-host.ko. This uses the DesignWare core.
+config PCIE_RCAR_GEN4_EP
+ tristate "Renesas R-Car Gen4 PCIe Endpoint controller"
+ depends on ARCH_RENESAS || COMPILE_TEST
+ depends on PCI_ENDPOINT
+ select PCIE_DW_EP
+ help
+ Say Y here if you want PCIe endpoint controller support on R-Car Gen4
+ SoCs. To compile this driver as a module, choose M here: the module
+ will be called pcie-rcar-gen4-ep.ko. This uses the DesignWare core.
+
endmenu
diff --git a/drivers/pci/controller/dwc/Makefile b/drivers/pci/controller/dwc/Makefile
index ab2c6bc16216..4d53d660e4fe 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -28,6 +28,8 @@ obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
obj-$(CONFIG_PCIE_VISCONTI_HOST) += pcie-visconti.o
pcie-rcar-gen4-host-objs := pcie-rcar-gen4.o pcie-rcar-gen4-host-drv.o
obj-$(CONFIG_PCIE_RCAR_GEN4) += pcie-rcar-gen4-host.o
+pcie-rcar-gen4-ep-objs := pcie-rcar-gen4.o pcie-rcar-gen4-ep-drv.o
+obj-$(CONFIG_PCIE_RCAR_GEN4_EP) += pcie-rcar-gen4-ep.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4-ep-drv.c b/drivers/pci/controller/dwc/pcie-rcar-gen4-ep-drv.c
new file mode 100644
index 000000000000..b85c290db3da
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4-ep-drv.c
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PCIe Endpoint driver for Renesas R-Car Gen4 Series SoCs
+ * Copyright (C) 2022-2023 Renesas Electronics Corporation
+ */
+
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/pci.h>
+#include <linux/platform_device.h>
+
+#include "pcie-rcar-gen4.h"
+#include "pcie-designware.h"
+
+#define RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET 0x1000
+#define RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET 0x800
+
+static void rcar_gen4_pcie_ep_pre_init(struct dw_pcie_ep *ep)
+{
+ struct dw_pcie *dw = to_dw_pcie_from_ep(ep);
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+ int ret;
+
+ ret = rcar_gen4_pcie_common_init(rcar);
+ if (ret)
+ return;
+
+ writel(PCIEDMAINTSTSEN_INIT, rcar->base + PCIEDMAINTSTSEN);
+}
+
+static void rcar_gen4_pcie_ep_init(struct dw_pcie_ep *ep)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ enum pci_barno bar;
+
+ for (bar = 0; bar < PCI_STD_NUM_BARS; bar++)
+ dw_pcie_ep_reset_bar(pci, bar);
+}
+
+static void rcar_gen4_pcie_ep_deinit(struct dw_pcie_ep *ep)
+{
+ struct dw_pcie *dw = to_dw_pcie_from_ep(ep);
+ struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
+
+ writel(0, rcar->base + PCIEDMAINTSTSEN);
+ rcar_gen4_pcie_common_deinit(rcar);
+}
+
+static int rcar_gen4_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
+ unsigned int type, u16 interrupt_num)
+{
+ struct dw_pcie *dw = to_dw_pcie_from_ep(ep);
+
+ switch (type) {
+ case PCI_IRQ_LEGACY:
+ return dw_pcie_ep_raise_legacy_irq(ep, func_no);
+ case PCI_IRQ_MSI:
+ return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
+ default:
+ dev_err(dw->dev, "Unknown IRQ type\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static const struct pci_epc_features rcar_gen4_pcie_epc_features = {
+ .linkup_notifier = false,
+ .msi_capable = true,
+ .msix_capable = false,
+ .reserved_bar = 1 << BAR_1 | 1 << BAR_3 | 1 << BAR_5,
+ .align = SZ_1M,
+};
+
+static const struct pci_epc_features*
+rcar_gen4_pcie_ep_get_features(struct dw_pcie_ep *ep)
+{
+ return &rcar_gen4_pcie_epc_features;
+}
+
+static unsigned int rcar_gen4_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
+ u8 func_no)
+{
+ return func_no * RCAR_GEN4_PCIE_EP_FUNC_DBI_OFFSET;
+}
+
+static unsigned int rcar_gen4_pcie_ep_get_dbi2_offset(struct dw_pcie_ep *ep,
+ u8 func_no)
+{
+ return func_no * RCAR_GEN4_PCIE_EP_FUNC_DBI2_OFFSET;
+}
+
+static const struct dw_pcie_ep_ops pcie_ep_ops = {
+ .pre_init = rcar_gen4_pcie_ep_pre_init,
+ .ep_init = rcar_gen4_pcie_ep_init,
+ .deinit = rcar_gen4_pcie_ep_deinit,
+ .raise_irq = rcar_gen4_pcie_ep_raise_irq,
+ .get_features = rcar_gen4_pcie_ep_get_features,
+ .func_conf_select = rcar_gen4_pcie_ep_func_conf_select,
+ .get_dbi2_offset = rcar_gen4_pcie_ep_get_dbi2_offset,
+};
+
+static int rcar_gen4_add_pcie_ep(struct rcar_gen4_pcie *rcar)
+{
+ struct dw_pcie_ep *ep = &rcar->dw.ep;
+
+ rcar->mode = DW_PCIE_EP_TYPE;
+ ep->ops = &pcie_ep_ops;
+
+ return dw_pcie_ep_init(ep);
+}
+
+static void rcar_gen4_remove_pcie_ep(struct rcar_gen4_pcie *rcar)
+{
+ dw_pcie_ep_exit(&rcar->dw.ep);
+}
+
+static int rcar_gen4_pcie_ep_probe(struct platform_device *pdev)
+{
+ struct rcar_gen4_pcie *rcar;
+ int err;
+
+ rcar = rcar_gen4_pcie_devm_alloc(pdev);
+ if (IS_ERR(rcar))
+ return PTR_ERR(rcar);
+
+ err = rcar_gen4_pcie_get_resources(rcar);
+ if (err)
+ return err;
+
+ err = rcar_gen4_pcie_prepare(rcar);
+ if (err)
+ return err;
+
+ err = rcar_gen4_add_pcie_ep(rcar);
+ if (err)
+ goto err_unprepare;
+
+ return 0;
+
+err_unprepare:
+ rcar_gen4_pcie_unprepare(rcar);
+
+ return err;
+}
+
+static void rcar_gen4_pcie_ep_remove(struct platform_device *pdev)
+{
+ struct rcar_gen4_pcie *rcar = platform_get_drvdata(pdev);
+
+ rcar_gen4_remove_pcie_ep(rcar);
+ rcar_gen4_pcie_unprepare(rcar);
+}
+
+static const struct of_device_id rcar_gen4_pcie_of_match[] = {
+ { .compatible = "renesas,rcar-gen4-pcie-ep", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rcar_gen4_pcie_of_match);
+
+static struct platform_driver rcar_gen4_pcie_ep_driver = {
+ .driver = {
+ .name = "pcie-rcar-gen4-ep",
+ .of_match_table = rcar_gen4_pcie_of_match,
+ },
+ .probe = rcar_gen4_pcie_ep_probe,
+ .remove_new = rcar_gen4_pcie_ep_remove,
+};
+module_platform_driver(rcar_gen4_pcie_ep_driver);
+
+MODULE_DESCRIPTION("Renesas R-Car Gen4 PCIe endpoint controller driver");
+MODULE_LICENSE("GPL");
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 18/19] MAINTAINERS: Update PCI DRIVER FOR RENESAS R-CAR for R-Car Gen4
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (16 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 17/19] PCI: rcar-gen4-ep: Add R-Car Gen4 PCIe Endpoint support Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 9:32 ` [PATCH v20 19/19] misc: pci_endpoint_test: Add Device ID for R-Car S4-8 PCIe controller Yoshihiro Shimoda
` (2 subsequent siblings)
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda, Manivannan Sadhasivam
Update this entry for R-Car Gen4's source code.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Serge Semin <fancer.lancer@gmail.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3be1bdfe8ecc..d12ec66f5098 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16273,6 +16273,7 @@ L: linux-renesas-soc@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/pci/*rcar*
F: drivers/pci/controller/*rcar*
+F: drivers/pci/controller/dwc/*rcar*
PCI DRIVER FOR SAMSUNG EXYNOS
M: Jingoo Han <jingoohan1@gmail.com>
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* [PATCH v20 19/19] misc: pci_endpoint_test: Add Device ID for R-Car S4-8 PCIe controller
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (17 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 18/19] MAINTAINERS: Update PCI DRIVER FOR RENESAS R-CAR for R-Car Gen4 Yoshihiro Shimoda
@ 2023-08-25 9:32 ` Yoshihiro Shimoda
2023-08-25 18:27 ` [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Serge Semin
2023-08-27 16:27 ` Krzysztof Wilczyński
20 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-25 9:32 UTC (permalink / raw)
To: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt, kw,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt
Cc: marek.vasut+renesas, fancer.lancer, linux-pci, devicetree,
linux-renesas-soc, Yoshihiro Shimoda, Manivannan Sadhasivam
Add Renesas R8A779F0 in pci_device_id table so that pci-epf-test
can be used for testing PCIe EP on R-Car S4-8.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
---
drivers/misc/pci_endpoint_test.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index ed4d0ef5e5c3..150083dab71a 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -81,6 +81,7 @@
#define PCI_DEVICE_ID_RENESAS_R8A774B1 0x002b
#define PCI_DEVICE_ID_RENESAS_R8A774C0 0x002d
#define PCI_DEVICE_ID_RENESAS_R8A774E1 0x0025
+#define PCI_DEVICE_ID_RENESAS_R8A779F0 0x0031
static DEFINE_IDA(pci_endpoint_test_ida);
@@ -990,6 +991,9 @@ static const struct pci_device_id pci_endpoint_test_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774B1),},
{ PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774C0),},
{ PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A774E1),},
+ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, PCI_DEVICE_ID_RENESAS_R8A779F0),
+ .driver_data = (kernel_ulong_t)&default_data,
+ },
{ PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_J721E),
.driver_data = (kernel_ulong_t)&j721e_data,
},
--
2.25.1
^ permalink raw reply related [flat|nested] 57+ messages in thread* Re: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (18 preceding siblings ...)
2023-08-25 9:32 ` [PATCH v20 19/19] misc: pci_endpoint_test: Add Device ID for R-Car S4-8 PCIe controller Yoshihiro Shimoda
@ 2023-08-25 18:27 ` Serge Semin
2023-08-27 6:59 ` Krzysztof Wilczyński
2023-08-27 16:27 ` Krzysztof Wilczyński
20 siblings, 1 reply; 57+ messages in thread
From: Serge Semin @ 2023-08-25 18:27 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring
Cc: Yoshihiro Shimoda, jingoohan1, gustavo.pimentel, robh+dt,
manivannan.sadhasivam, kishon, krzysztof.kozlowski+dt, conor+dt,
marek.vasut+renesas, linux-pci, devicetree, linux-renesas-soc
Hi Mani, Bjorn, Lorenzo, Krzysztof, Rob
On Fri, Aug 25, 2023 at 06:32:00PM +0900, Yoshihiro Shimoda wrote:
> Add R-Car S4-8 (R-Car Gen4) PCIe Host and Endpoint support.
> To support them, modify PCIe DesignWare common codes.
No more comments from my side for this series. It looks good to me
now. If you have nothing to note too please merge it in especially
seeing it's already v20.)
-Serge(y)
>
> Changes from v19:
> https://lore.kernel.org/linux-pci/20230823091153.2578417-1-yoshihiro.shimoda.uh@renesas.com/
> - Based on the latest pci.git / next branch and the following patches:
> [PATCH v3 0/2] Cleanup IRQ type definitions
> https://lore.kernel.org/linux-pci/20230802094036.1052472-1-dlemoal@kernel.org/
> - Rename PCI_MSG_TYPE_R_* macros in the patch 01/19.
> - Fix the comment in the patch 04/19.
> - Add Reviewed-by in the patch {06,1[2678]/19.
> - Modify common functions for the same method of clock handling in the patch
> 1[78]/19.
> - Remove redundant gpio handling in the patch 16/19.
>
> Changes from v18:
> https://lore.kernel.org/linux-pci/20230721074452.65545-1-yoshihiro.shimoda.uh@renesas.com/
> - Based on the latest pci.git / next branch and the following patches:
> [PATCH v3 0/2] Cleanup IRQ type definitions
> https://lore.kernel.org/linux-pci/20230802094036.1052472-1-dlemoal@kernel.org/
> - Drop some patches about converting "legacy" to "INTx".
> - Add detailed description in the patch 0[26]/19.
> - Add a new patch "Expose dw_pcie_write_dbi2" in the patch 11/19.
> - Revise typo in the patch 12/19.
> - Fix calling order of deinit in the patch 12/19.
> - Revise Kconfig about kernel module names in the patch 1[67]/19.
> - Rename drivers' file names in the patch 1[67]/19.
> - Some other minor change/fix in the patch 1[67]/19.
>
> Yoshihiro Shimoda (19):
> PCI: Add INTx Mechanism Messages macros
> PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
> PCI: dwc: Add outbound MSG TLPs support
> PCI: designware-ep: Add INTx IRQs support
> PCI: dwc: endpoint: Add multiple PFs support for dbi2
> PCI: dwc: Add dw_pcie_link_set_max_link_width()
> PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling
> PCI: tegra194: Drop PCI_EXP_LNKSTA_NLW setting
> PCI: dwc: Add EDMA_UNROLL capability flag
> PCI: dwc: Expose dw_pcie_ep_exit() to module
> PCI: dwc: Expose dw_pcie_write_dbi2() to module
> PCI: dwc: endpoint: Introduce .pre_init() and .deinit()
> dt-bindings: PCI: dwc: Update maxItems of reg and reg-names
> dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host
> dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint
> PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
> PCI: rcar-gen4-ep: Add R-Car Gen4 PCIe Endpoint support
> MAINTAINERS: Update PCI DRIVER FOR RENESAS R-CAR for R-Car Gen4
> misc: pci_endpoint_test: Add Device ID for R-Car S4-8 PCIe controller
>
> .../bindings/pci/rcar-gen4-pci-ep.yaml | 106 ++++++++
> .../bindings/pci/rcar-gen4-pci-host.yaml | 123 ++++++++++
> .../bindings/pci/snps,dw-pcie-ep.yaml | 4 +-
> .../devicetree/bindings/pci/snps,dw-pcie.yaml | 4 +-
> MAINTAINERS | 1 +
> drivers/misc/pci_endpoint_test.c | 4 +
> drivers/pci/controller/dwc/Kconfig | 20 ++
> drivers/pci/controller/dwc/Makefile | 4 +
> .../pci/controller/dwc/pcie-designware-ep.c | 136 +++++++++--
> .../pci/controller/dwc/pcie-designware-host.c | 52 ++--
> drivers/pci/controller/dwc/pcie-designware.c | 156 ++++++------
> drivers/pci/controller/dwc/pcie-designware.h | 29 ++-
> .../controller/dwc/pcie-rcar-gen4-ep-drv.c | 173 +++++++++++++
> .../controller/dwc/pcie-rcar-gen4-host-drv.c | 135 +++++++++++
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 227 ++++++++++++++++++
> drivers/pci/controller/dwc/pcie-rcar-gen4.h | 44 ++++
> drivers/pci/controller/dwc/pcie-tegra194.c | 6 -
> drivers/pci/pci.h | 18 ++
> 18 files changed, 1111 insertions(+), 131 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/rcar-gen4-pci-ep.yaml
> create mode 100644 Documentation/devicetree/bindings/pci/rcar-gen4-pci-host.yaml
> create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4-ep-drv.c
> create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4-host-drv.c
> create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4.c
> create mode 100644 drivers/pci/controller/dwc/pcie-rcar-gen4.h
>
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-25 18:27 ` [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Serge Semin
@ 2023-08-27 6:59 ` Krzysztof Wilczyński
2023-08-28 1:19 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Krzysztof Wilczyński @ 2023-08-27 6:59 UTC (permalink / raw)
To: Serge Semin
Cc: Manivannan Sadhasivam, Bjorn Helgaas, Lorenzo Pieralisi,
Rob Herring, Yoshihiro Shimoda, jingoohan1, gustavo.pimentel,
robh+dt, manivannan.sadhasivam, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, linux-pci, devicetree,
linux-renesas-soc
Hello everyone!
> > Add R-Car S4-8 (R-Car Gen4) PCIe Host and Endpoint support.
> > To support them, modify PCIe DesignWare common codes.
>
> No more comments from my side for this series. It looks good to me
> now. If you have nothing to note too please merge it in especially
> seeing it's already v20.)
Yes, it's about time we pull it. Thank you everyone involved in the work
here, especially reviews (Sergey and Manivannan), as the series looks
amazing.
That said, some patches in the series do not apply cleanly against 6.5-rc1,
so I need to have a closer look a little bit later, hopefully I will be
able to get it in time before Bjorn sends his Pull Request.
シモダさん、
一連のシリーズお疲れ様でした！
特に、作業が少し前に開始され、レビューされるまでに時間がかかった点お手数をおかけいたしました
全ての要求変更の追加にご協力いただき、ありがとうございます。 個人的にも本当に有難いです。
ご担当いただいた仕事は素晴らしいものでした。 重ねてにはなりますが、どうもありがとう！
Thank you!
Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-27 6:59 ` Krzysztof Wilczyński
@ 2023-08-28 1:19 ` Yoshihiro Shimoda
2023-08-28 6:37 ` manivannan.sadhasivam
` (2 more replies)
0 siblings, 3 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-28 1:19 UTC (permalink / raw)
To: Krzysztof Wilczyński, Serge Semin
Cc: Manivannan Sadhasivam, Bjorn Helgaas, Lorenzo Pieralisi,
Rob Herring, jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
robh+dt@kernel.org, manivannan.sadhasivam@linaro.org,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
Hello Krzysztof, Serge, Manivannan,
> From: Krzysztof Wilczyński, Sent: Sunday, August 27, 2023 3:59 PM
>
> Hello everyone!
>
> > > Add R-Car S4-8 (R-Car Gen4) PCIe Host and Endpoint support.
> > > To support them, modify PCIe DesignWare common codes.
> >
> > No more comments from my side for this series. It looks good to me
> > now. If you have nothing to note too please merge it in especially
> > seeing it's already v20.)
>
> Yes, it's about time we pull it. Thank you everyone involved in the work
> here, especially reviews (Sergey and Manivannan), as the series looks
> amazing.
Thank you very much for your support!
> That said, some patches in the series do not apply cleanly against 6.5-rc1,
> so I need to have a closer look a little bit later, hopefully I will be
> able to get it in time before Bjorn sends his Pull Request.
I'm sorry for bothering you about the conflict because my patch set is based on pci.git / next,
not 6.5-rc1... But, anyway, thank you for applying to controller/rcar!
> シモダさん、
>
> 一連のシリーズお疲れ様でした！
> 特に、作業が少し前に開始され、レビューされるまでに時間がかかった点お手数をおかけいたしました
> 全ての要求変更の追加にご協力いただき、ありがとうございます。 個人的にも本当に有難いです。
> ご担当いただいた仕事は素晴らしいものでした。 重ねてにはなりますが、どうもありがとう！
Thank you for your comment in Japanese!
こちらこそ、ありがとうございました！
Best regards,
Yoshihiro Shimoda
> Thank you!
>
> Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread* Re: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-28 1:19 ` Yoshihiro Shimoda
@ 2023-08-28 6:37 ` manivannan.sadhasivam
2023-08-28 13:58 ` Serge Semin
2023-08-28 16:07 ` Krzysztof Wilczyński
2 siblings, 0 replies; 57+ messages in thread
From: manivannan.sadhasivam @ 2023-08-28 6:37 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Krzysztof Wilczyński, Serge Semin, Manivannan Sadhasivam,
Bjorn Helgaas, Lorenzo Pieralisi, Rob Herring,
jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
robh+dt@kernel.org, kishon@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
On Mon, Aug 28, 2023 at 01:19:17AM +0000, Yoshihiro Shimoda wrote:
> Hello Krzysztof, Serge, Manivannan,
>
> > From: Krzysztof Wilczyński, Sent: Sunday, August 27, 2023 3:59 PM
> >
> > Hello everyone!
> >
> > > > Add R-Car S4-8 (R-Car Gen4) PCIe Host and Endpoint support.
> > > > To support them, modify PCIe DesignWare common codes.
> > >
> > > No more comments from my side for this series. It looks good to me
> > > now. If you have nothing to note too please merge it in especially
> > > seeing it's already v20.)
> >
> > Yes, it's about time we pull it. Thank you everyone involved in the work
> > here, especially reviews (Sergey and Manivannan), as the series looks
> > amazing.
>
> Thank you very much for your support!
>
Thanks for your patience and perseverance! And thanks a lot Sergey for helping
with the review.
- Mani
> > That said, some patches in the series do not apply cleanly against 6.5-rc1,
> > so I need to have a closer look a little bit later, hopefully I will be
> > able to get it in time before Bjorn sends his Pull Request.
>
> I'm sorry for bothering you about the conflict because my patch set is based on pci.git / next,
> not 6.5-rc1... But, anyway, thank you for applying to controller/rcar!
>
> > シモダさん、
> >
> > 一連のシリーズお疲れ様でした！
> > 特に、作業が少し前に開始され、レビューされるまでに時間がかかった点お手数をおかけいたしました
> > 全ての要求変更の追加にご協力いただき、ありがとうございます。 個人的にも本当に有難いです。
> > ご担当いただいた仕事は素晴らしいものでした。 重ねてにはなりますが、どうもありがとう！
>
> Thank you for your comment in Japanese!
> こちらこそ、ありがとうございました！
>
> Best regards,
> Yoshihiro Shimoda
>
> > Thank you!
> >
> > Krzysztof
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-28 1:19 ` Yoshihiro Shimoda
2023-08-28 6:37 ` manivannan.sadhasivam
@ 2023-08-28 13:58 ` Serge Semin
2023-08-29 12:02 ` Yoshihiro Shimoda
2023-08-28 16:07 ` Krzysztof Wilczyński
2 siblings, 1 reply; 57+ messages in thread
From: Serge Semin @ 2023-08-28 13:58 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Lorenzo Pieralisi, Rob Herring, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, robh+dt@kernel.org,
manivannan.sadhasivam@linaro.org, kishon@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hi Yoshihiro,
On Mon, Aug 28, 2023 at 01:19:17AM +0000, Yoshihiro Shimoda wrote:
> Hello Krzysztof, Serge, Manivannan,
>
> > From: Krzysztof Wilczyński, Sent: Sunday, August 27, 2023 3:59 PM
> >
> > Hello everyone!
> >
> > > > Add R-Car S4-8 (R-Car Gen4) PCIe Host and Endpoint support.
> > > > To support them, modify PCIe DesignWare common codes.
> > >
> > > No more comments from my side for this series. It looks good to me
> > > now. If you have nothing to note too please merge it in especially
> > > seeing it's already v20.)
> >
> > Yes, it's about time we pull it. Thank you everyone involved in the work
> > here, especially reviews (Sergey and Manivannan), as the series looks
> > amazing.
>
> Thank you very much for your support!
It was my pleasure to be reviewing your patchset. Thanks you very much
for the patience and strong eagerness to complete the turned out to be
such a long-time procedure. I'm sorry if sometimes I acted too
meticulous.) It was always done from out of reaching greater good.
Regards
-Serge(y)
>
> > That said, some patches in the series do not apply cleanly against 6.5-rc1,
> > so I need to have a closer look a little bit later, hopefully I will be
> > able to get it in time before Bjorn sends his Pull Request.
>
> I'm sorry for bothering you about the conflict because my patch set is based on pci.git / next,
> not 6.5-rc1... But, anyway, thank you for applying to controller/rcar!
>
> > シモダさん、
> >
> > 一連のシリーズお疲れ様でした！
> > 特に、作業が少し前に開始され、レビューされるまでに時間がかかった点お手数をおかけいたしました
> > 全ての要求変更の追加にご協力いただき、ありがとうございます。 個人的にも本当に有難いです。
> > ご担当いただいた仕事は素晴らしいものでした。 重ねてにはなりますが、どうもありがとう！
>
> Thank you for your comment in Japanese!
> こちらこそ、ありがとうございました！
>
> Best regards,
> Yoshihiro Shimoda
>
> > Thank you!
> >
> > Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-28 13:58 ` Serge Semin
@ 2023-08-29 12:02 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-29 12:02 UTC (permalink / raw)
To: Serge Semin
Cc: Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Lorenzo Pieralisi, Rob Herring, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, robh+dt@kernel.org,
manivannan.sadhasivam@linaro.org, kishon@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hi Serge,
> From: Serge Semin, Sent: Monday, August 28, 2023 10:58 PM
>
> Hi Yoshihiro,
>
> On Mon, Aug 28, 2023 at 01:19:17AM +0000, Yoshihiro Shimoda wrote:
> > Hello Krzysztof, Serge, Manivannan,
> >
> > > From: Krzysztof Wilczyński, Sent: Sunday, August 27, 2023 3:59 PM
> > >
> > > Hello everyone!
> > >
> > > > > Add R-Car S4-8 (R-Car Gen4) PCIe Host and Endpoint support.
> > > > > To support them, modify PCIe DesignWare common codes.
> > > >
> > > > No more comments from my side for this series. It looks good to me
> > > > now. If you have nothing to note too please merge it in especially
> > > > seeing it's already v20.)
> > >
> > > Yes, it's about time we pull it. Thank you everyone involved in the work
> > > here, especially reviews (Sergey and Manivannan), as the series looks
> > > amazing.
> >
> > Thank you very much for your support!
>
> It was my pleasure to be reviewing your patchset. Thanks you very much
> for the patience and strong eagerness to complete the turned out to be
> such a long-time procedure. I'm sorry if sometimes I acted too
> meticulous.) It was always done from out of reaching greater good.
I appreciate your support. My patch set became quite better by your kindly review!
Best regards,
Yoshihiro Shimoda
> Regards
> -Serge(y)
>
> >
> > > That said, some patches in the series do not apply cleanly against 6.5-rc1,
> > > so I need to have a closer look a little bit later, hopefully I will be
> > > able to get it in time before Bjorn sends his Pull Request.
> >
> > I'm sorry for bothering you about the conflict because my patch set is based on pci.git / next,
> > not 6.5-rc1... But, anyway, thank you for applying to controller/rcar!
> >
> > > シモダさん、
> > >
> > > 一連のシリーズお疲れ様でした！
> > > 特に、作業が少し前に開始され、レビューされるまでに時間がかかった点お手数をおかけいたしました
> > > 全ての要求変更の追加にご協力いただき、ありがとうございます。 個人的にも本当に有難いです。
> > > ご担当いただいた仕事は素晴らしいものでした。 重ねてにはなりますが、どうもありがとう！
> >
> > Thank you for your comment in Japanese!
> > こちらこそ、ありがとうございました！
> >
> > Best regards,
> > Yoshihiro Shimoda
> >
> > > Thank you!
> > >
> > > Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-28 1:19 ` Yoshihiro Shimoda
2023-08-28 6:37 ` manivannan.sadhasivam
2023-08-28 13:58 ` Serge Semin
@ 2023-08-28 16:07 ` Krzysztof Wilczyński
2023-08-29 12:13 ` Yoshihiro Shimoda
2 siblings, 1 reply; 57+ messages in thread
From: Krzysztof Wilczyński @ 2023-08-28 16:07 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: Serge Semin, Manivannan Sadhasivam, Bjorn Helgaas,
Lorenzo Pieralisi, Rob Herring, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, robh+dt@kernel.org,
manivannan.sadhasivam@linaro.org, kishon@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hello,
[...]
> > That said, some patches in the series do not apply cleanly against 6.5-rc1,
> > so I need to have a closer look a little bit later, hopefully I will be
> > able to get it in time before Bjorn sends his Pull Request.
>
> I'm sorry for bothering you about the conflict because my patch set is based on pci.git / next,
> not 6.5-rc1... But, anyway, thank you for applying to controller/rcar!
No problem!
That said, it's always a good idea to check the main branch from the
following the repository to see which version to work against if
possible. PCI development lives at:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > シモダさん、
> >
> > 一連のシリーズお疲れ様でした！
> > 特に、作業が少し前に開始され、レビューされるまでに時間がかかった点お手数をおかけいたしました
> > 全ての要求変更の追加にご協力いただき、ありがとうございます。 個人的にも本当に有難いです。
> > ご担当いただいた仕事は素晴らしいものでした。 重ねてにはなりますが、どうもありがとう！
>
> Thank you for your comment in Japanese!
> こちらこそ、ありがとうございました！
Sure thing! Greetings from Yokohama. :)
Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-28 16:07 ` Krzysztof Wilczyński
@ 2023-08-29 12:13 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-29 12:13 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: Serge Semin, Manivannan Sadhasivam, Bjorn Helgaas,
Lorenzo Pieralisi, Rob Herring, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, robh+dt@kernel.org,
manivannan.sadhasivam@linaro.org, kishon@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hello Krzysztof,
> From: Krzysztof Wilczyński, Sent: Tuesday, August 29, 2023 1:07 AM
>
> Hello,
>
> [...]
> > > That said, some patches in the series do not apply cleanly against 6.5-rc1,
> > > so I need to have a closer look a little bit later, hopefully I will be
> > > able to get it in time before Bjorn sends his Pull Request.
> >
> > I'm sorry for bothering you about the conflict because my patch set is based on pci.git / next,
> > not 6.5-rc1... But, anyway, thank you for applying to controller/rcar!
>
> No problem!
>
> That said, it's always a good idea to check the main branch from the
> following the repository to see which version to work against if
> possible. PCI development lives at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
I checked that v6.5-rc1 + controller/rcar + the following dtsi/dts patches
I have submitted [1] worked correctly. Thank you for your support!
[1]
https://lore.kernel.org/all/20230828041434.2747699-1-yoshihiro.shimoda.uh@renesas.com/
> > > シモダさん、
> > >
> > > 一連のシリーズお疲れ様でした！
> > > 特に、作業が少し前に開始され、レビューされるまでに時間がかかった点お手数をおかけいたしました
> > > 全ての要求変更の追加にご協力いただき、ありがとうございます。 個人的にも本当に有難いです。
> > > ご担当いただいた仕事は素晴らしいものでした。 重ねてにはなりますが、どうもありがとう！
> >
> > Thank you for your comment in Japanese!
> > こちらこそ、ありがとうございました！
>
> Sure thing! Greetings from Yokohama. :)
Oh! Yokohama! It's a nice city :)
Best regards,
Yoshihiro Shimoda
> Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-25 9:32 [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Yoshihiro Shimoda
` (19 preceding siblings ...)
2023-08-25 18:27 ` [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support Serge Semin
@ 2023-08-27 16:27 ` Krzysztof Wilczyński
2023-08-31 1:34 ` Yoshihiro Shimoda
20 siblings, 1 reply; 57+ messages in thread
From: Krzysztof Wilczyński @ 2023-08-27 16:27 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: jingoohan1, gustavo.pimentel, lpieralisi, robh+dt,
manivannan.sadhasivam, bhelgaas, kishon, krzysztof.kozlowski+dt,
conor+dt, marek.vasut+renesas, fancer.lancer, linux-pci,
devicetree, linux-renesas-soc
Hello,
> Add R-Car S4-8 (R-Car Gen4) PCIe Host and Endpoint support.
> To support them, modify PCIe DesignWare common codes.
Applied to controller/rcar, thank you!
[01/19] PCI: Add INTx Mechanism Messages macros
https://git.kernel.org/pci/pci/c/b6dc5750a17a
[02/19] PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
https://git.kernel.org/pci/pci/c/6cbd4d406cb0
[03/19] PCI: dwc: Add outbound MSG TLPs support
https://git.kernel.org/pci/pci/c/6ab660b25520
[04/19] PCI: designware-ep: Add INTx IRQs support
https://git.kernel.org/pci/pci/c/b788d6fd273e
[05/19] PCI: dwc: endpoint: Add multiple PFs support for dbi2
https://git.kernel.org/pci/pci/c/6e4db9846cf4
[06/19] PCI: dwc: Add dw_pcie_link_set_max_link_width()
https://git.kernel.org/pci/pci/c/d0f961f40da8
[07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling
https://git.kernel.org/pci/pci/c/a0473c77b4c1
[08/19] PCI: tegra194: Drop PCI_EXP_LNKSTA_NLW setting
https://git.kernel.org/pci/pci/c/e45ff874cede
[09/19] PCI: dwc: Add EDMA_UNROLL capability flag
https://git.kernel.org/pci/pci/c/2424c3ddbd4c
[10/19] PCI: dwc: Expose dw_pcie_ep_exit() to module
https://git.kernel.org/pci/pci/c/3f937c80eb8e
[11/19] PCI: dwc: Expose dw_pcie_write_dbi2() to module
https://git.kernel.org/pci/pci/c/a986f6fd339e
[12/19] PCI: dwc: endpoint: Introduce .pre_init() and .deinit()
https://git.kernel.org/pci/pci/c/6504d294399e
[13/19] dt-bindings: PCI: dwc: Update maxItems of reg and reg-names
https://git.kernel.org/pci/pci/c/5ca157f7d36c
[14/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host
https://git.kernel.org/pci/pci/c/af285bc39885
[15/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint
https://git.kernel.org/pci/pci/c/738bded11aaa
[16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
https://git.kernel.org/pci/pci/c/943a310da907
[17/19] PCI: rcar-gen4-ep: Add R-Car Gen4 PCIe Endpoint support
https://git.kernel.org/pci/pci/c/db4499d11f46
[18/19] MAINTAINERS: Update PCI DRIVER FOR RENESAS R-CAR for R-Car Gen4
https://git.kernel.org/pci/pci/c/2e0ef5776946
[19/19] misc: pci_endpoint_test: Add Device ID for R-Car S4-8 PCIe controller
https://git.kernel.org/pci/pci/c/33fa67818fe7
Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread* RE: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-27 16:27 ` Krzysztof Wilczyński
@ 2023-08-31 1:34 ` Yoshihiro Shimoda
2023-08-31 14:04 ` Krzysztof Wilczyński
0 siblings, 1 reply; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-08-31 1:34 UTC (permalink / raw)
To: bhelgaas@google.com
Cc: jingoohan1@gmail.com, gustavo.pimentel@synopsys.com,
lpieralisi@kernel.org, robh+dt@kernel.org,
manivannan.sadhasivam@linaro.org, kishon@kernel.org,
krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
marek.vasut+renesas@gmail.com, fancer.lancer@gmail.com,
linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, Krzysztof Wilczyński
Hello Bjorn,
> From: Krzysztof Wilczyński, Sent: Monday, August 28, 2023 1:27 AM
>
> Hello,
>
> > Add R-Car S4-8 (R-Car Gen4) PCIe Host and Endpoint support.
> > To support them, modify PCIe DesignWare common codes.
>
> Applied to controller/rcar, thank you!
I should have asked you before, but is it possible to merge this for Linux v6.6?
Today I realized that "[GIT PULL] PCI changes for v6.6" [1] didn't have the controller/rcar...
[1]
https://lore.kernel.org/linux-pci/20230830190642.GA10547@bhelgaas/
Best regards,
Yoshihiro Shimoda
> [01/19] PCI: Add INTx Mechanism Messages macros
> https://git.kernel.org/pci/pci/c/b6dc5750a17a
> [02/19] PCI: dwc: Change arguments of dw_pcie_prog_outbound_atu()
> https://git.kernel.org/pci/pci/c/6cbd4d406cb0
> [03/19] PCI: dwc: Add outbound MSG TLPs support
> https://git.kernel.org/pci/pci/c/6ab660b25520
> [04/19] PCI: designware-ep: Add INTx IRQs support
> https://git.kernel.org/pci/pci/c/b788d6fd273e
> [05/19] PCI: dwc: endpoint: Add multiple PFs support for dbi2
> https://git.kernel.org/pci/pci/c/6e4db9846cf4
> [06/19] PCI: dwc: Add dw_pcie_link_set_max_link_width()
> https://git.kernel.org/pci/pci/c/d0f961f40da8
> [07/19] PCI: dwc: Add missing PCI_EXP_LNKCAP_MLW handling
> https://git.kernel.org/pci/pci/c/a0473c77b4c1
> [08/19] PCI: tegra194: Drop PCI_EXP_LNKSTA_NLW setting
> https://git.kernel.org/pci/pci/c/e45ff874cede
> [09/19] PCI: dwc: Add EDMA_UNROLL capability flag
> https://git.kernel.org/pci/pci/c/2424c3ddbd4c
> [10/19] PCI: dwc: Expose dw_pcie_ep_exit() to module
> https://git.kernel.org/pci/pci/c/3f937c80eb8e
> [11/19] PCI: dwc: Expose dw_pcie_write_dbi2() to module
> https://git.kernel.org/pci/pci/c/a986f6fd339e
> [12/19] PCI: dwc: endpoint: Introduce .pre_init() and .deinit()
> https://git.kernel.org/pci/pci/c/6504d294399e
> [13/19] dt-bindings: PCI: dwc: Update maxItems of reg and reg-names
> https://git.kernel.org/pci/pci/c/5ca157f7d36c
> [14/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Host
> https://git.kernel.org/pci/pci/c/af285bc39885
> [15/19] dt-bindings: PCI: renesas: Add R-Car Gen4 PCIe Endpoint
> https://git.kernel.org/pci/pci/c/738bded11aaa
> [16/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe Host support
> https://git.kernel.org/pci/pci/c/943a310da907
> [17/19] PCI: rcar-gen4-ep: Add R-Car Gen4 PCIe Endpoint support
> https://git.kernel.org/pci/pci/c/db4499d11f46
> [18/19] MAINTAINERS: Update PCI DRIVER FOR RENESAS R-CAR for R-Car Gen4
> https://git.kernel.org/pci/pci/c/2e0ef5776946
> [19/19] misc: pci_endpoint_test: Add Device ID for R-Car S4-8 PCIe controller
> https://git.kernel.org/pci/pci/c/33fa67818fe7
>
> Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-31 1:34 ` Yoshihiro Shimoda
@ 2023-08-31 14:04 ` Krzysztof Wilczyński
2023-09-01 0:20 ` Yoshihiro Shimoda
0 siblings, 1 reply; 57+ messages in thread
From: Krzysztof Wilczyński @ 2023-08-31 14:04 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: bhelgaas@google.com, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, lpieralisi@kernel.org,
robh+dt@kernel.org, manivannan.sadhasivam@linaro.org,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hello,
[...]
> > Applied to controller/rcar, thank you!
>
> I should have asked you before, but is it possible to merge this for Linux v6.6?
> Today I realized that "[GIT PULL] PCI changes for v6.6" [1] didn't have the controller/rcar...
Bjorn chosen not to include the series as the scope of the changes also
spans across the DWC code base, not only adding a new driver, and he wanted
for it to remain a little bit longer on the -next, so that if there are
issues, we can catch things...
... like the dt-bindings issues that Geert is asking about.
That said, there will be no need to send an entire series again, if you
have anything to fix there in the dt-bindings or the dts patches, and just
send a new patches for these - I will pull and squash everything later.
We are getting there. :)
Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: [PATCH v20 00/19] PCI: rcar-gen4: Add R-Car Gen4 PCIe support
2023-08-31 14:04 ` Krzysztof Wilczyński
@ 2023-09-01 0:20 ` Yoshihiro Shimoda
0 siblings, 0 replies; 57+ messages in thread
From: Yoshihiro Shimoda @ 2023-09-01 0:20 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: bhelgaas@google.com, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, lpieralisi@kernel.org,
robh+dt@kernel.org, manivannan.sadhasivam@linaro.org,
kishon@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, marek.vasut+renesas@gmail.com,
fancer.lancer@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Hello Krzysztof,
> From: Krzysztof Wilczyński, Sent: Thursday, August 31, 2023 11:04 PM
>
> Hello,
>
> [...]
> > > Applied to controller/rcar, thank you!
> >
> > I should have asked you before, but is it possible to merge this for Linux v6.6?
> > Today I realized that "[GIT PULL] PCI changes for v6.6" [1] didn't have the controller/rcar...
>
> Bjorn chosen not to include the series as the scope of the changes also
> spans across the DWC code base, not only adding a new driver, and he wanted
> for it to remain a little bit longer on the -next, so that if there are
> issues, we can catch things...
>
> ... like the dt-bindings issues that Geert is asking about.
I got it.
> That said, there will be no need to send an entire series again, if you
> have anything to fix there in the dt-bindings or the dts patches, and just
> send a new patches for these - I will pull and squash everything later.
Thank you for explanation about how to fix it. I'll submit new patches for these.
Best regards,
Yoshihiro Shimoda
> We are getting there. :)
>
> Krzysztof
^ permalink raw reply [flat|nested] 57+ messages in thread