[PATCH v3 0/3] PCI: iproc: Add fixes to pcie iproc
This patch series contains fixes and improvements to pcie iproc driver. This patch set is based on Linux-5.9.0-rc2. Changes from v2: - Addressed Bjorn's review comments - Corrected subject line and commit message of Patches 1 and 2. Changes from v1: - Addressed Bjorn's review comments - pcie_print_link_status is used to print Link information. - Added IARR1/IMAP1 window map definition. Bharat Gooty (1): PCI: iproc: Fix out-of-bound array accesses Roman Bacik (1): PCI: iproc: Invalidate correct PAXB inbound windows Srinath Mannam (1): PCI: iproc: Display PCIe Link information drivers/pci/controller/pcie-iproc.c | 29 ++--- 1 file changed, 22 insertions(+), 7 deletions(-) -- 2.17.1 smime.p7s Description: S/MIME Cryptographic Signature
[PATCH v3 3/3] PCI: iproc: Display PCIe Link information
After successful linkup more comprehensive information about PCIe link
speed and link width will be displayed to the console.
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index cc5b7823edeb..8ef2d1fe392c 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1479,6 +1479,7 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct
list_head *res)
{
struct device *dev;
int ret;
+ struct pci_dev *pdev;
struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
dev = pcie->dev;
@@ -1542,6 +1543,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct
list_head *res)
goto err_power_off_phy;
}
+ for_each_pci_bridge(pdev, host->bus) {
+ if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
+ pcie_print_link_status(pdev);
+ }
+
return 0;
err_power_off_phy:
--
2.17.1
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH v3 1/3] PCI: iproc: Fix out-of-bound array accesses
From: Bharat Gooty
Declare the full size array for all revisions of PAX register sets
to avoid potentially out of bound access of the register array
when they are being initialized in iproc_pcie_rev_init().
Fixes: 06324ede76cdf ("PCI: iproc: Improve core register population")
Signed-off-by: Bharat Gooty
---
drivers/pci/controller/pcie-iproc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index 905e93808243..d901b9d392b8 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -307,7 +307,7 @@ enum iproc_pcie_reg {
};
/* iProc PCIe PAXB BCMA registers */
-static const u16 iproc_pcie_reg_paxb_bcma[] = {
+static const u16 iproc_pcie_reg_paxb_bcma[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_CLK_CTRL] = 0x000,
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
@@ -318,7 +318,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
};
/* iProc PCIe PAXB registers */
-static const u16 iproc_pcie_reg_paxb[] = {
+static const u16 iproc_pcie_reg_paxb[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_CLK_CTRL] = 0x000,
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
@@ -334,7 +334,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
};
/* iProc PCIe PAXB v2 registers */
-static const u16 iproc_pcie_reg_paxb_v2[] = {
+static const u16 iproc_pcie_reg_paxb_v2[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_CLK_CTRL] = 0x000,
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
@@ -363,7 +363,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
};
/* iProc PCIe PAXC v1 registers */
-static const u16 iproc_pcie_reg_paxc[] = {
+static const u16 iproc_pcie_reg_paxc[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_CLK_CTRL] = 0x000,
[IPROC_PCIE_CFG_IND_ADDR] = 0x1f0,
[IPROC_PCIE_CFG_IND_DATA] = 0x1f4,
@@ -372,7 +372,7 @@ static const u16 iproc_pcie_reg_paxc[] = {
};
/* iProc PCIe PAXC v2 registers */
-static const u16 iproc_pcie_reg_paxc_v2[] = {
+static const u16 iproc_pcie_reg_paxc_v2[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_MSI_GIC_MODE] = 0x050,
[IPROC_PCIE_MSI_BASE_ADDR] = 0x074,
[IPROC_PCIE_MSI_WINDOW_SIZE]= 0x078,
--
2.17.1
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH v3 2/3] PCI: iproc: Invalidate correct PAXB inbound windows
From: Roman Bacik
Second stage bootloader prior to Linux boot may use all inbound windows
including IARR1/IMAP1. We need to ensure all previous configuration of
inbound windows are invalidated during the initialization stage of the
Linux iProc PCIe driver. Add fix to define and invalidate IARR1/IMAP1
because it was missed in previous patch.
Fixes: 9415743e4c8a ("PCI: iproc: Invalidate PAXB address mapping")
Signed-off-by: Roman Bacik
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index d901b9d392b8..cc5b7823edeb 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -192,8 +192,15 @@ static const struct iproc_pcie_ib_map paxb_v2_ib_map[] = {
.imap_window_offset = 0x4,
},
{
- /* IARR1/IMAP1 (currently unused) */
- .type = IPROC_PCIE_IB_MAP_INVALID,
+ /* IARR1/IMAP1 */
+ .type = IPROC_PCIE_IB_MAP_MEM,
+ .size_unit = SZ_1M,
+ .region_sizes = { 8 },
+ .nr_sizes = 1,
+ .nr_windows = 8,
+ .imap_addr_offset = 0x4,
+ .imap_window_offset = 0x8,
+
},
{
/* IARR2/IMAP2 */
@@ -351,6 +358,8 @@ static const u16
iproc_pcie_reg_paxb_v2[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_OMAP3] = 0xdf8,
[IPROC_PCIE_IARR0] = 0xd00,
[IPROC_PCIE_IMAP0] = 0xc00,
+ [IPROC_PCIE_IARR1] = 0xd08,
+ [IPROC_PCIE_IMAP1] = 0xd70,
[IPROC_PCIE_IARR2] = 0xd10,
[IPROC_PCIE_IMAP2] = 0xcc0,
[IPROC_PCIE_IARR3] = 0xe00,
--
2.17.1
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [PATCH v2 3/3] PCI: iproc: Display PCIe Link information
On Thu, Sep 17, 2020 at 7:22 AM Rob Herring wrote:
>
Hi Rob,
Thanks for review.
> On Tue, Sep 15, 2020 at 07:15:41PM +0530, Srinath Mannam wrote:
> > After successful linkup more comprehensive information about PCIe link
> > speed and link width will be displayed to the console.
> >
> > Signed-off-by: Srinath Mannam
> > ---
> > drivers/pci/controller/pcie-iproc.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c
> > b/drivers/pci/controller/pcie-iproc.c
> > index cc5b7823edeb..8ef2d1fe392c 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -1479,6 +1479,7 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct
> > list_head *res)
> > {
> > struct device *dev;
> > int ret;
> > + struct pci_dev *pdev;
> > struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
> >
> > dev = pcie->dev;
> > @@ -1542,6 +1543,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct
> > list_head *res)
> > goto err_power_off_phy;
> > }
> >
> > + for_each_pci_bridge(pdev, host->bus) {
> > + if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
> > + pcie_print_link_status(pdev);
> > + }
>
> If this information is useful for 1 host implementation, why not all of
> them and put this in a common spot.
In common, pcie_print_link_status() is called during pci device caps
initialization, if the available link bandwidth is less than capabilities
of devices. Few EP drivers also used this function to print link
bandwidth info. This host can be configured for different link
speeds and link widths on different platforms so we thought
displaying link bandwidth after successful linkup is helpful to
know link details.
Thanks & Regards,
Srinath.
>
> Rob
Re: [PATCH v2 0/3] PCI: iproc: Add fixes to pcie iproc
On Thu, Sep 17, 2020 at 3:38 AM Bjorn Helgaas wrote: > Hi Bjorn, Thanks for review. > On Tue, Sep 15, 2020 at 07:15:38PM +0530, Srinath Mannam wrote: > > This patch series contains fixes and improvements to pcie iproc driver. > > > > This patch set is based on Linux-5.9.0-rc2. > > > > Changes from v1: > > - Addressed Bjorn's review comments > > - pcie_print_link_status is used to print Link information. > > - Added IARR1/IMAP1 window map definition. > > > > Bharat Gooty (1): > > PCI: iproc: fix out of bound array access > > > > Roman Bacik (1): > > PCI: iproc: fix invalidating PAXB address mapping > > You didn't update thest subject lines so they match. > https://lore.kernel.org/r/20200326194810.ga11...@google.com Yes this patchset is the latest version to the patches in the link. My apologies that I missed to address your review comment about the commit message of "PCI: iproc: fix out of bound array access" in this patchset. Thanks & Regards, Srinath. > > > Srinath Mannam (1): > > PCI: iproc: Display PCIe Link information > > > > drivers/pci/controller/pcie-iproc.c | 29 ++--- > > 1 file changed, 22 insertions(+), 7 deletions(-) > > > > -- > > 2.17.1 > >
[PATCH v2 0/3] PCI: iproc: Add fixes to pcie iproc
This patch series contains fixes and improvements to pcie iproc driver. This patch set is based on Linux-5.9.0-rc2. Changes from v1: - Addressed Bjorn's review comments - pcie_print_link_status is used to print Link information. - Added IARR1/IMAP1 window map definition. Bharat Gooty (1): PCI: iproc: fix out of bound array access Roman Bacik (1): PCI: iproc: fix invalidating PAXB address mapping Srinath Mannam (1): PCI: iproc: Display PCIe Link information drivers/pci/controller/pcie-iproc.c | 29 ++--- 1 file changed, 22 insertions(+), 7 deletions(-) -- 2.17.1
[PATCH v2 3/3] PCI: iproc: Display PCIe Link information
After successful linkup more comprehensive information about PCIe link
speed and link width will be displayed to the console.
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index cc5b7823edeb..8ef2d1fe392c 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1479,6 +1479,7 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct
list_head *res)
{
struct device *dev;
int ret;
+ struct pci_dev *pdev;
struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
dev = pcie->dev;
@@ -1542,6 +1543,11 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct
list_head *res)
goto err_power_off_phy;
}
+ for_each_pci_bridge(pdev, host->bus) {
+ if (pci_pcie_type(pdev) == PCI_EXP_TYPE_ROOT_PORT)
+ pcie_print_link_status(pdev);
+ }
+
return 0;
err_power_off_phy:
--
2.17.1
[PATCH v2 1/3] PCI: iproc: fix out of bound array access
From: Bharat Gooty
Declare the full size array for all revisions of PAX register sets
to avoid potentially out of bound access of the register array
when they are being initialized in the 'iproc_pcie_rev_init'
function.
Fixes: 06324ede76cdf ("PCI: iproc: Improve core register population")
Signed-off-by: Bharat Gooty
---
drivers/pci/controller/pcie-iproc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index 905e93808243..d901b9d392b8 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -307,7 +307,7 @@ enum iproc_pcie_reg {
};
/* iProc PCIe PAXB BCMA registers */
-static const u16 iproc_pcie_reg_paxb_bcma[] = {
+static const u16 iproc_pcie_reg_paxb_bcma[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_CLK_CTRL] = 0x000,
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
@@ -318,7 +318,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
};
/* iProc PCIe PAXB registers */
-static const u16 iproc_pcie_reg_paxb[] = {
+static const u16 iproc_pcie_reg_paxb[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_CLK_CTRL] = 0x000,
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
@@ -334,7 +334,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
};
/* iProc PCIe PAXB v2 registers */
-static const u16 iproc_pcie_reg_paxb_v2[] = {
+static const u16 iproc_pcie_reg_paxb_v2[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_CLK_CTRL] = 0x000,
[IPROC_PCIE_CFG_IND_ADDR] = 0x120,
[IPROC_PCIE_CFG_IND_DATA] = 0x124,
@@ -363,7 +363,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
};
/* iProc PCIe PAXC v1 registers */
-static const u16 iproc_pcie_reg_paxc[] = {
+static const u16 iproc_pcie_reg_paxc[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_CLK_CTRL] = 0x000,
[IPROC_PCIE_CFG_IND_ADDR] = 0x1f0,
[IPROC_PCIE_CFG_IND_DATA] = 0x1f4,
@@ -372,7 +372,7 @@ static const u16 iproc_pcie_reg_paxc[] = {
};
/* iProc PCIe PAXC v2 registers */
-static const u16 iproc_pcie_reg_paxc_v2[] = {
+static const u16 iproc_pcie_reg_paxc_v2[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_MSI_GIC_MODE] = 0x050,
[IPROC_PCIE_MSI_BASE_ADDR] = 0x074,
[IPROC_PCIE_MSI_WINDOW_SIZE]= 0x078,
--
2.17.1
[PATCH v2 2/3] PCI: iproc: fix invalidating PAXB address mapping
From: Roman Bacik
Second stage bootloader prior to Linux boot may use all inbound windows
including IARR1/IMAP1. We need to ensure all previous configuration of
inbound windows are invalidated during the initialization stage of the
Linux iProc PCIe driver. Add fix to define and invalidate IARR1/IMAP1
because it was missed in previous patch.
Fixes: 9415743e4c8a ("PCI: iproc: Invalidate PAXB address mapping")
Signed-off-by: Roman Bacik
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index d901b9d392b8..cc5b7823edeb 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -192,8 +192,15 @@ static const struct iproc_pcie_ib_map paxb_v2_ib_map[] = {
.imap_window_offset = 0x4,
},
{
- /* IARR1/IMAP1 (currently unused) */
- .type = IPROC_PCIE_IB_MAP_INVALID,
+ /* IARR1/IMAP1 */
+ .type = IPROC_PCIE_IB_MAP_MEM,
+ .size_unit = SZ_1M,
+ .region_sizes = { 8 },
+ .nr_sizes = 1,
+ .nr_windows = 8,
+ .imap_addr_offset = 0x4,
+ .imap_window_offset = 0x8,
+
},
{
/* IARR2/IMAP2 */
@@ -351,6 +358,8 @@ static const u16
iproc_pcie_reg_paxb_v2[IPROC_PCIE_MAX_NUM_REG] = {
[IPROC_PCIE_OMAP3] = 0xdf8,
[IPROC_PCIE_IARR0] = 0xd00,
[IPROC_PCIE_IMAP0] = 0xc00,
+ [IPROC_PCIE_IARR1] = 0xd08,
+ [IPROC_PCIE_IMAP1] = 0xd70,
[IPROC_PCIE_IARR2] = 0xd10,
[IPROC_PCIE_IMAP2] = 0xcc0,
[IPROC_PCIE_IARR3] = 0xe00,
--
2.17.1
[PATCH v3] iommu/dma: Fix IOVA reserve dma ranges
Fix IOVA reserve failure in the case when address of first memory region
listed in dma-ranges is equal to 0x0.
Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
address")
Signed-off-by: Srinath Mannam
---
Changes from v2:
Modify error message with useful information based on Bjorn's comments.
Changes from v1:
Removed unnecessary changes based on Robin's review comments.
drivers/iommu/dma-iommu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5141d49a046b..5b9791f35c5e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -217,9 +217,11 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
lo = iova_pfn(iovad, start);
hi = iova_pfn(iovad, end);
reserve_iova(iovad, lo, hi);
- } else {
+ } else if (end < start) {
/* dma_ranges list should be sorted */
- dev_err(>dev, "Failed to reserve IOVA\n");
+ dev_err(>dev,
+ "Failed to reserve IOVA [%#010llx-%#010llx]\n",
+ start, end);
return -EINVAL;
}
--
2.17.1
Re: [PATCH v2] iommu/dma: Fix IOVA reserve dma ranges
On Fri, Sep 11, 2020 at 8:47 PM Bjorn Helgaas wrote:
>
Hi Bjorn,
Thanks for review.
> On Fri, Sep 11, 2020 at 03:55:34PM +0530, Srinath Mannam wrote:
> > Fix IOVA reserve failure in the case when address of first memory region
> > listed in dma-ranges is equal to 0x0.
> >
> > Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
> > address")
> > Signed-off-by: Srinath Mannam
> > ---
> > Changes from v1:
> >Removed unnecessary changes based on Robin's review comments.
> >
> > drivers/iommu/dma-iommu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 5141d49a046b..682068a9aae7 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -217,7 +217,7 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
> > lo = iova_pfn(iovad, start);
> > hi = iova_pfn(iovad, end);
> > reserve_iova(iovad, lo, hi);
> > - } else {
> > + } else if (end < start) {
> > /* dma_ranges list should be sorted */
> > dev_err(>dev, "Failed to reserve IOVA\n");
>
It is very unlikely to come to this error, dma_ranges list is sorted
in "devm_of_pci_get_host_bridge_resources" function.
> You didn't actually change the error message, but the message would be
> way more useful if it included the IOVA address range, e.g., the
> format used in pci_register_host_bridge():
>
> bus address [%#010llx-%#010llx]
I will add this change and send the next patchset.
Thanks & Regards,
Srinath.
>
> Incidentally, the pr_err() in copy_reserved_iova() looks bogus; it
> prints iova->pfn_low twice, when it should probably print the base and
> size or (my preference) something like the above:
>
> pr_err("Reserve iova range %lx@%lx failed\n",
>iova->pfn_lo, iova->pfn_lo);
>
> > return -EINVAL;
> > --
> > 2.17.1
> >
[PATCH v2] iommu/dma: Fix IOVA reserve dma ranges
Fix IOVA reserve failure in the case when address of first memory region
listed in dma-ranges is equal to 0x0.
Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
address")
Signed-off-by: Srinath Mannam
---
Changes from v1:
Removed unnecessary changes based on Robin's review comments.
drivers/iommu/dma-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5141d49a046b..682068a9aae7 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -217,7 +217,7 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
lo = iova_pfn(iovad, start);
hi = iova_pfn(iovad, end);
reserve_iova(iovad, lo, hi);
- } else {
+ } else if (end < start) {
/* dma_ranges list should be sorted */
dev_err(>dev, "Failed to reserve IOVA\n");
return -EINVAL;
--
2.17.1
Re: [PATCH] iommu/dma: Fix IOVA reserve dma ranges
On Wed, Sep 9, 2020 at 5:35 PM Robin Murphy wrote:
>
Hi Robin,
Thanks for review
> On 2020-09-09 06:32, Srinath Mannam wrote:
> > Fix IOVA reserve failure for memory regions listed in dma-ranges in the
> > following cases.
> >
> > - start address of memory region is 0x0.
>
> That's fair enough, and in fact generalises to the case of zero-sized
> gaps between regions, which is indeed an oversight.
Yes this is the main reason for the requirement of this fix.
>
> > - end address of a memory region is equal to start address of next memory
> >region.
>
> This part doesn't make much sense, however - if the regions described in
> bridge->dma_ranges overlap, that's a bug in whoever created a malformed
> list to begin with. Possibly it's just poor wording, and you're using
> "memory regions" to refer to any or all of the dma_ranges, the reserved
> IOVA ranges, and what "start" and "end" in this function represent which
> isn't quite either of those.
You are right, this case is very unlikely that nobody lists regions with zero
gap, in such a case they will combine both the regions. Reason for highlighting
this point is, the same fix will handle this case also. Here I used memory
regions to refer entries of dma-ranges(allowed IOVA addresses range) not
reserved IOVA ranges. start and end variables in this function refers to
start and end addresses of reserved IOVA ranges which are derived from
dma ranges resources start and end values.
>
> > Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
> > address")
> > Signed-off-by: Srinath Mannam
> > ---
> > drivers/iommu/dma-iommu.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 5141d49a046b..0a3f67a4f9ae 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -213,14 +213,21 @@ static int iova_reserve_pci_windows(struct pci_dev
> > *dev,
> > resource_list_for_each_entry(window, >dma_ranges) {
> > end = window->res->start - window->offset;
> > resv_iova:
> > + if (end < start) {
> > + /* dma_ranges list should be sorted */
> > + dev_err(>dev, "Failed to reserve IOVA\n");
> > + return -EINVAL;
> > + }
> > + /*
> > + * Skip the cases when start address of first memory region is
> > + * 0x0 and end address of one memory region and start address
> > + * of next memory region are equal. Reserve IOVA for rest of
> > + * addresses fall in between given memory ranges.
> > + */
> > if (end > start) {
> > lo = iova_pfn(iovad, start);
> > hi = iova_pfn(iovad, end);
> > reserve_iova(iovad, lo, hi);
> > - } else {
>
> Surely this only needs to be a one-liner?
Yes I agree with you this one line is sufficient.
>
> - } else {
> + } else if (end < start) {
>
> (or possibly "end != start"; I can't quite decide which expresses the
> semantic intent better)
I think "end < start" is better choice because it tells list is not sorted
and "!=" contradicts previous condition "end > start".
>
> The rest just looks like unnecessary churn - I don't think it needs
> commenting that a sorted list may simply not have gaps between entries,
> and as above I think the wording of that comment is actively misleading.
I agree with you, these lines were added to explain the issue and fix with
more details.
I will send a new patch with a single line change as you said.
" } else if (end < start) {"
Thanks & Regards,
Srinath.
>
> Robin.
>
> > - /* dma_ranges list should be sorted */
> > - dev_err(>dev, "Failed to reserve IOVA\n");
> > - return -EINVAL;
> > }
> >
> > start = window->res->end - window->offset + 1;
> >
[PATCH] iommu/dma: Fix IOVA reserve dma ranges
Fix IOVA reserve failure for memory regions listed in dma-ranges in the
following cases.
- start address of memory region is 0x0.
- end address of a memory region is equal to start address of next memory
region.
Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA
address")
Signed-off-by: Srinath Mannam
---
drivers/iommu/dma-iommu.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 5141d49a046b..0a3f67a4f9ae 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -213,14 +213,21 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
resource_list_for_each_entry(window, >dma_ranges) {
end = window->res->start - window->offset;
resv_iova:
+ if (end < start) {
+ /* dma_ranges list should be sorted */
+ dev_err(>dev, "Failed to reserve IOVA\n");
+ return -EINVAL;
+ }
+ /*
+* Skip the cases when start address of first memory region is
+* 0x0 and end address of one memory region and start address
+* of next memory region are equal. Reserve IOVA for rest of
+* addresses fall in between given memory ranges.
+*/
if (end > start) {
lo = iova_pfn(iovad, start);
hi = iova_pfn(iovad, end);
reserve_iova(iovad, lo, hi);
- } else {
- /* dma_ranges list should be sorted */
- dev_err(>dev, "Failed to reserve IOVA\n");
- return -EINVAL;
}
start = window->res->end - window->offset + 1;
--
2.17.1
Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address
On Wed, May 27, 2020 at 11:00 PM Robin Murphy wrote:
>
Thanks Robin for your quick response.
> On 2020-05-27 17:03, Srinath Mannam wrote:
> > This patch gives the provision to change default value of MSI IOVA base
> > to platform's suitable IOVA using module parameter. The present
> > hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform.
>
> That in itself doesn't seem entirely unreasonable; IIRC the current
> address is just an arbitrary choice to fit nicely into Qemu's memory
> map, and there was always the possibility that it wouldn't suit everything.
>
> > Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible
> > DMA address"), inaccessible IOVA address ranges parsed from dma-ranges
> > property are reserved.
>
> That, however, doesn't seem to fit here; iommu-dma maps MSI doorbells
> dynamically, so they aren't affected by reserved regions any more than
> regular DMA pages are. In fact, it explicitly ignores the software MSI
> region, since as the comment says, it *is* the software that manages those.
Yes you are right, we don't see any issues with kernel drivers(PCI EP) because
MSI IOVA allocated dynamically by honouring reserved regions same as DMA pages.
>
> The MSI_IOVA_BASE region exists for VFIO, precisely because in that case
> the kernel *doesn't* control the address space, but still needs some way
> to steal a bit of it for MSIs that the guest doesn't necessarily know
> about, and give userspace a fighting chance of knowing what it's taken.
> I think at the time we discussed the idea of adding something to the
> VFIO uapi such that userspace could move this around if it wanted or
> needed to, but decided we could live without that initially. Perhaps now
> the time has come?
Yes, we see issues only with user-space drivers(DPDK) in which MSI_IOVA_BASE
region is considered to map MSI registers. This patch helps us to fix the issue.
Thanks,
Srinath.
>
> Robin.
>
> > If any platform has the limitaion to access default MSI IOVA, then it can
> > be changed using "arm-smmu.msi_iova_base=0xa000" command line argument.
> >
> > Signed-off-by: Srinath Mannam
> > ---
> > drivers/iommu/arm-smmu.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index 4f1a350..5e59c9d 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -72,6 +72,9 @@ static bool disable_bypass =
> > module_param(disable_bypass, bool, S_IRUGO);
> > MODULE_PARM_DESC(disable_bypass,
> > "Disable bypass streams such that incoming transactions from devices
> > that are not attached to an iommu domain will report an abort back to the
> > device and will not be allowed to pass through the SMMU.");
> > +static unsigned long msi_iova_base = MSI_IOVA_BASE;
> > +module_param(msi_iova_base, ulong, S_IRUGO);
> > +MODULE_PARM_DESC(msi_iova_base, "msi iova base address.");
> >
> > struct arm_smmu_s2cr {
> > struct iommu_group *group;
> > @@ -1566,7 +1569,7 @@ static void arm_smmu_get_resv_regions(struct device
> > *dev,
> > struct iommu_resv_region *region;
> > int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
> >
> > - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
> > + region = iommu_alloc_resv_region(msi_iova_base, MSI_IOVA_LENGTH,
> >prot, IOMMU_RESV_SW_MSI);
> > if (!region)
> > return;
> >
[RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address
This patch gives the provision to change default value of MSI IOVA base
to platform's suitable IOVA using module parameter. The present
hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform.
Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible
DMA address"), inaccessible IOVA address ranges parsed from dma-ranges
property are reserved.
If any platform has the limitaion to access default MSI IOVA, then it can
be changed using "arm-smmu.msi_iova_base=0xa000" command line argument.
Signed-off-by: Srinath Mannam
---
drivers/iommu/arm-smmu.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 4f1a350..5e59c9d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -72,6 +72,9 @@ static bool disable_bypass =
module_param(disable_bypass, bool, S_IRUGO);
MODULE_PARM_DESC(disable_bypass,
"Disable bypass streams such that incoming transactions from devices
that are not attached to an iommu domain will report an abort back to the
device and will not be allowed to pass through the SMMU.");
+static unsigned long msi_iova_base = MSI_IOVA_BASE;
+module_param(msi_iova_base, ulong, S_IRUGO);
+MODULE_PARM_DESC(msi_iova_base, "msi iova base address.");
struct arm_smmu_s2cr {
struct iommu_group *group;
@@ -1566,7 +1569,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
struct iommu_resv_region *region;
int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
- region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+ region = iommu_alloc_resv_region(msi_iova_base, MSI_IOVA_LENGTH,
prot, IOMMU_RESV_SW_MSI);
if (!region)
return;
--
2.7.4
Re: [PATCH 2/2] gpio: iproc-gpio: Handle interrupts for multiple instances
Hi Linus,
We have tested patch with your changes, it works fine.
Thanks a lot for all the help.
Regards,
Srinath.
On Wed, Sep 11, 2019 at 3:13 PM Linus Walleij wrote:
>
> On Thu, Aug 29, 2019 at 5:52 AM Srinath Mannam
> wrote:
>
> > From: Rayagonda Kokatanur
> >
> > When multiple instance of iproc-gpio chips are present, a fix up
> > message[1] is printed during the probe of second and later instances.
> >
> > This issue is because driver sharing same irq_chip data structure
> > among multiple instances of driver.
> >
> > Fix this by allocating irq_chip data structure per instance of
> > iproc-gpio.
> >
> > [1] fix up message addressed by this patch
> > [ 7.862208] gpio gpiochip2: (689d.gpio): detected irqchip that
> >is shared with multiple gpiochips: please fix the driver.
> >
> > Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
> > Signed-off-by: Rayagonda Kokatanur
>
> Patch applied, I had to rewrite it a bit to fit the new code that
> set up the irqchip when adding the gpio_chip, please check that
> the result works.
>
> Yours,
> Linus Walleij
Re: [PATCH] PCI: Add PCIE ACS quirk for IPROC PAXB
Hi Bjorn,
Thank you for the improvements. With the changes, comments and commit
message exactly describes the purpose.
I tested the code changes and works fine.
Thanks again,
Srinath
On Fri, Sep 6, 2019 at 3:56 AM Bjorn Helgaas wrote:
>
> [+cc Alex]
>
> On Tue, Aug 20, 2019 at 10:09:45AM +0530, Srinath Mannam wrote:
> > From: Abhinav Ratna
> >
> > IPROC PAXB RC doesn't support ACS capabilities and control registers.
> > Add quirk to have separate IOMMU groups for all EPs and functions connected
> > to root port, by masking RR/CR/SV/UF bits.
> >
> > Signed-off-by: Abhinav Ratna
> > Signed-off-by: Srinath Mannam
>
> I tentatively applied this to pci/misc with Scott's ack for v5.4.
>
> I tweaked the patch itself to follow the style of similar quirks
> (interdiff is below, plus a diff of the commit log). Please make sure
> I didn't break it.
>
> I also went out on a limb and reworded the comment to give what I
> *think* is the justification for this patch, as opposed to merely a
> description of the code. I'm making a lot of assumptions there, so
> please confirm that they're correct, or supply alternate justification
> if they're not.
>
> > ---
> > drivers/pci/quirks.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 0f16acc..f9584c0 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -4466,6 +4466,21 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev
> > *dev, u16 acs_flags)
> > return acs_flags ? 0 : 1;
> > }
> >
> > +static int pcie_quirk_brcm_bridge_acs(struct pci_dev *dev, u16 acs_flags)
> > +{
> > + /*
> > + * IPROC PAXB RC doesn't support ACS capabilities and control
> > registers.
> > + * Add quirk to to have separate IOMMU groups for all EPs and
> > functions
> > + * connected to root port, by masking RR/CR/SV/UF bits.
> > + */
> > +
> > + u16 flags = (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_SV);
> > + int ret = acs_flags & ~flags ? 0 : 1;
> > +
> > + return ret;
> > +}
> > +
> > +
> > static const struct pci_dev_acs_enabled {
> > u16 vendor;
> > u16 device;
> > @@ -4559,6 +4574,7 @@ static const struct pci_dev_acs_enabled {
> > { PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs },
> > { PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs },
> > { PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs },
> > + { PCI_VENDOR_ID_BROADCOM, 0xD714, pcie_quirk_brcm_bridge_acs },
> > { 0 }
> > };
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 77c0330ac922..2edbce35e8c5 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -4466,21 +4466,19 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev
> *dev, u16 acs_flags)
> return acs_flags ? 0 : 1;
> }
>
> -static int pcie_quirk_brcm_bridge_acs(struct pci_dev *dev, u16 acs_flags)
> +static int pci_quirk_brcm_acs(struct pci_dev *dev, u16 acs_flags)
> {
> /*
> -* IPROC PAXB RC doesn't support ACS capabilities and control
> registers.
> -* Add quirk to to have separate IOMMU groups for all EPs and
> functions
> -* connected to root port, by masking RR/CR/SV/UF bits.
> +* iProc PAXB Root Ports don't advertise an ACS capability, but
> +* they do not allow peer-to-peer transactions between Root Ports.
> +* Allow each Root Port to be in a separate IOMMU group by masking
> +* SV/RR/CR/UF bits.
> */
> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF);
>
> - u16 flags = (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_SV);
> - int ret = acs_flags & ~flags ? 0 : 1;
> -
> - return ret;
> + return acs_flags ? 0 : 1;
> }
>
> -
> static const struct pci_dev_acs_enabled {
> u16 vendor;
> u16 device;
> @@ -4574,7 +4572,7 @@ static const struct pci_dev_acs_enabled {
> { PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs },
> { PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs },
> { PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs },
> - { PCI_VENDOR_ID_BROADCOM, 0xD714, pcie_quirk_brcm_bridge_acs },
> + { PCI_VENDOR_ID_BROADCOM, 0xD714, pci_quirk_brcm_acs },
> { 0 }
> };
>
>
>
>
> @@ -1,49 +1,49 @@
> -commit b50ae502eff0
> +commit 46b2c32df7a4
> Author: Abhinav Ratna
> Date: Tue Aug 20 10:09:45 2019 +0530
>
> -PCI: Add P
Re: [PATCH v2 0/4] Reset xHCI port PHY on disconnect
Hi Mathias, Could you please help to review this patch series? Regards, Srinath. On Wed, Jul 31, 2019 at 3:50 PM Srinath Mannam wrote: > > This patch set adds a quirk in xHCI driver to reset PHY of xHCI port on > its disconnect event. > > This patch set is based on Linux-5.2-rc4. > > Changes from v1: > - Addressed Mathias's comments > - Modified mapping of HC ports and their corresponding PHYs > - Addressed Rob's comments > - Removed usb-phy-port-reset DT property. > - Added quirk in platform data using HCI compatible string. > - Add phy ports in phy attr structure to have enabled ports bitmask. > - Modified #phy-cells of sr-phy to pass phy ports bitmask. > > Srinath Mannam (4): > phy: Add phy ports in attrs > dt-bindings: phy: Modify Stingray USB PHY #phy-cells > phy: sr-usb: Set phy ports > dt-bindings: usb-xhci: Add platform specific compatible for Stingray > xHCI > drivers: xhci: Add quirk to reset xHCI port PHY > > .../devicetree/bindings/phy/brcm,stingray-usb-phy.txt | 14 -- > Documentation/devicetree/bindings/usb/usb-xhci.txt| 1 + > drivers/phy/broadcom/phy-bcm-sr-usb.c | 9 - > drivers/usb/core/hcd.c| 6 ++ > drivers/usb/core/phy.c| 19 > +++ > drivers/usb/core/phy.h| 1 + > drivers/usb/host/xhci-plat.c | 10 ++ > drivers/usb/host/xhci-plat.h | 1 + > drivers/usb/host/xhci-ring.c | 9 ++--- > drivers/usb/host/xhci.h | 1 + > include/linux/phy/phy.h | 10 ++ > include/linux/usb/hcd.h | 1 + > 12 files changed, 72 insertions(+), 10 deletions(-) > > -- > 2.7.4 >
[PATCH 2/2] gpio: iproc-gpio: Handle interrupts for multiple instances
From: Rayagonda Kokatanur
When multiple instance of iproc-gpio chips are present, a fix up
message[1] is printed during the probe of second and later instances.
This issue is because driver sharing same irq_chip data structure
among multiple instances of driver.
Fix this by allocating irq_chip data structure per instance of
iproc-gpio.
[1] fix up message addressed by this patch
[ 7.862208] gpio gpiochip2: (689d.gpio): detected irqchip that
is shared with multiple gpiochips: please fix the driver.
Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
Signed-off-by: Rayagonda Kokatanur
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index 20b9864..8729f47 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -114,6 +114,7 @@ struct iproc_gpio {
raw_spinlock_t lock;
+ struct irq_chip irqchip;
struct gpio_chip gc;
unsigned num_banks;
@@ -302,14 +303,6 @@ static int iproc_gpio_irq_set_type(struct irq_data *d,
unsigned int type)
return 0;
}
-static struct irq_chip iproc_gpio_irq_chip = {
- .name = "bcm-iproc-gpio",
- .irq_ack = iproc_gpio_irq_ack,
- .irq_mask = iproc_gpio_irq_mask,
- .irq_unmask = iproc_gpio_irq_unmask,
- .irq_set_type = iproc_gpio_irq_set_type,
-};
-
/*
* Request the Iproc IOMUX pinmux controller to mux individual pins to GPIO
*/
@@ -875,14 +868,22 @@ static int iproc_gpio_probe(struct platform_device *pdev)
/* optional GPIO interrupt support */
irq = platform_get_irq(pdev, 0);
if (irq) {
- ret = gpiochip_irqchip_add(gc, _gpio_irq_chip, 0,
+ chip->irqchip.name = "bcm-iproc-gpio";
+ chip->irqchip.irq_ack = iproc_gpio_irq_ack;
+ chip->irqchip.irq_mask = iproc_gpio_irq_mask;
+ chip->irqchip.irq_unmask = iproc_gpio_irq_unmask;
+ chip->irqchip.irq_set_type = iproc_gpio_irq_set_type;
+ chip->irqchip.irq_enable = iproc_gpio_irq_unmask;
+ chip->irqchip.irq_disable = iproc_gpio_irq_mask;
+
+ ret = gpiochip_irqchip_add(gc, >irqchip, 0,
handle_simple_irq, IRQ_TYPE_NONE);
if (ret) {
dev_err(dev, "no GPIO irqchip\n");
goto err_rm_gpiochip;
}
- gpiochip_set_chained_irqchip(gc, _gpio_irq_chip, irq,
+ gpiochip_set_chained_irqchip(gc, >irqchip, irq,
iproc_gpio_irq_handler);
}
--
2.7.4
[PATCH 1/2] gpio: iproc-gpio: Fix incorrect pinconf configurations
From: Li Jin
Fix drive strength for AON/CRMU controller; fix pull-up/down setting
for CCM/CDRU controller.
Fixes: 616043d58a89 ("pinctrl: Rename gpio driver from cygnus to iproc")
Signed-off-by: Li Jin
---
drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 96 +---
1 file changed, 77 insertions(+), 19 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index b70058c..20b9864 100644
--- a/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -54,8 +54,12 @@
/* drive strength control for ASIU GPIO */
#define IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
-/* drive strength control for CCM/CRMU (AON) GPIO */
-#define IPROC_GPIO_DRV0_CTRL_OFFSET 0x00
+/* pinconf for CCM GPIO */
+#define IPROC_GPIO_PULL_DN_OFFSET 0x10
+#define IPROC_GPIO_PULL_UP_OFFSET 0x14
+
+/* pinconf for CRMU(aon) GPIO and CCM GPIO*/
+#define IPROC_GPIO_DRV_CTRL_OFFSET 0x00
#define GPIO_BANK_SIZE 0x200
#define NGPIOS_PER_BANK 32
@@ -76,6 +80,12 @@ enum iproc_pinconf_param {
IPROC_PINCON_MAX,
};
+enum iproc_pinconf_ctrl_type {
+ IOCTRL_TYPE_AON = 1,
+ IOCTRL_TYPE_CDRU,
+ IOCTRL_TYPE_INVALID,
+};
+
/*
* Iproc GPIO core
*
@@ -100,6 +110,7 @@ struct iproc_gpio {
void __iomem *base;
void __iomem *io_ctrl;
+ enum iproc_pinconf_ctrl_type io_ctrl_type;
raw_spinlock_t lock;
@@ -461,20 +472,44 @@ static const struct pinctrl_ops iproc_pctrl_ops = {
static int iproc_gpio_set_pull(struct iproc_gpio *chip, unsigned gpio,
bool disable, bool pull_up)
{
+ void __iomem *base;
unsigned long flags;
+ unsigned int shift;
+ u32 val_1, val_2;
raw_spin_lock_irqsave(>lock, flags);
-
- if (disable) {
- iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio, false);
+ if (chip->io_ctrl_type == IOCTRL_TYPE_CDRU) {
+ base = chip->io_ctrl;
+ shift = IPROC_GPIO_SHIFT(gpio);
+
+ val_1 = readl(base + IPROC_GPIO_PULL_UP_OFFSET);
+ val_2 = readl(base + IPROC_GPIO_PULL_DN_OFFSET);
+ if (disable) {
+ /* no pull-up or pull-down */
+ val_1 &= ~BIT(shift);
+ val_2 &= ~BIT(shift);
+ } else if (pull_up) {
+ val_1 |= BIT(shift);
+ val_2 &= ~BIT(shift);
+ } else {
+ val_1 &= ~BIT(shift);
+ val_2 |= BIT(shift);
+ }
+ writel(val_1, base + IPROC_GPIO_PULL_UP_OFFSET);
+ writel(val_2, base + IPROC_GPIO_PULL_DN_OFFSET);
} else {
- iproc_set_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio,
- pull_up);
- iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio, true);
+ if (disable) {
+ iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio,
+ false);
+ } else {
+ iproc_set_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio,
+ pull_up);
+ iproc_set_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio,
+ true);
+ }
}
raw_spin_unlock_irqrestore(>lock, flags);
-
dev_dbg(chip->dev, "gpio:%u set pullup:%d\n", gpio, pull_up);
return 0;
@@ -483,14 +518,35 @@ static int iproc_gpio_set_pull(struct iproc_gpio *chip,
unsigned gpio,
static void iproc_gpio_get_pull(struct iproc_gpio *chip, unsigned gpio,
bool *disable, bool *pull_up)
{
+ void __iomem *base;
unsigned long flags;
+ unsigned int shift;
+ u32 val_1, val_2;
raw_spin_lock_irqsave(>lock, flags);
- *disable = !iproc_get_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio);
- *pull_up = iproc_get_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio);
+ if (chip->io_ctrl_type == IOCTRL_TYPE_CDRU) {
+ base = chip->io_ctrl;
+ shift = IPROC_GPIO_SHIFT(gpio);
+
+ val_1 = readl(base + IPROC_GPIO_PULL_UP_OFFSET) & BIT(shift);
+ val_2 = readl(base + IPROC_GPIO_PULL_DN_OFFSET) & BIT(shift);
+
+ *pull_up = val_1 ? true : false;
+ *disable = (val_1 | val_2) ? false : true;
+
+ } else {
+ *disable = !iproc_get_bit(chip, IPROC_GPIO_RES_EN_OFFSET, gpio);
+ *pull_up = iproc_get_bit(chip, IPROC_GPIO_PAD_RES_OFFSET, gpio);
+ }
raw_spin_unlock_irqrestore(>lock, flags);
}
+#define DRV_STRENGTH_OFFSET(gpio, bit, type) ((type) == IOCTRL_TYPE_AON ? \
+ ((2 - (bit)) * 4 + IPROC_GPIO_DRV_CTRL_OFFSET) : \
+ ((type) == IOCTRL_TYPE_CDRU) ? \
+ ((bit) * 4 + IPROC_GPIO_DRV_CTRL_OFFSET) : \
+ ((bit) * 4 +
[PATCH 0/2] Add fixes to iProc GPIO driver
This patch series adds the following fixes to the iProc GPIO driver - Fix Warning message given for shared irqchip data structure - Fix pinconfig of pull-up/down and drive strength for AON/CRMU GPIOs This patch set is based on Linux-5.2-rc4. Changes from v1: - Add Fixes tags in both patches Li Jin (1): gpio: iproc-gpio: Fix incorrect pinconf configurations Rayagonda Kokatanur (1): gpio: iproc-gpio: Handle interrupts for multiple instances drivers/pinctrl/bcm/pinctrl-iproc-gpio.c | 117 +++ 1 file changed, 88 insertions(+), 29 deletions(-) -- 2.7.4
[PATCH v2 6/6] arm64: dts: Change PCIe INTx mapping for NS2
From: Ray Jui
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui
Signed-off-by: Srinath Mannam
---
arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 28
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
index 15f7b0e..d639928 100644
--- a/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
@@ -117,8 +117,11 @@
dma-coherent;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 0 GIC_SPI 281
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <0>;
@@ -140,6 +143,13 @@
phy-names = "pcie-phy";
msi-parent = <>;
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
pcie4: pcie@5002 {
@@ -148,8 +158,11 @@
dma-coherent;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 0 GIC_SPI 305
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <4>;
@@ -171,6 +184,13 @@
phy-names = "pcie-phy";
msi-parent = <>;
+ pcie4_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
pcie8: pcie@60c0 {
--
2.7.4
[PATCH v2 5/6] arm: dts: Change PCIe INTx mapping for HR2
From: Ray Jui
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui
Signed-off-by: Srinath Mannam
---
arch/arm/boot/dts/bcm-hr2.dtsi | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-hr2.dtsi b/arch/arm/boot/dts/bcm-hr2.dtsi
index e4d4973..eb449d0 100644
--- a/arch/arm/boot/dts/bcm-hr2.dtsi
+++ b/arch/arm/boot/dts/bcm-hr2.dtsi
@@ -299,8 +299,11 @@
reg = <0x18012000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <0>;
@@ -328,6 +331,14 @@
;
brcm,pcie-msi-inten;
};
+
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
pcie1: pcie@18013000 {
@@ -335,8 +346,11 @@
reg = <0x18013000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <1>;
@@ -364,5 +378,13 @@
;
brcm,pcie-msi-inten;
};
+
+ pcie1_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
};
--
2.7.4
[PATCH v2 2/6] PCI: iproc: Add INTx support with better modeling
From: Ray Jui
Add PCIe legacy interrupt INTx support to the iProc PCIe driver by
modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC,
INTD share the same interrupt line connected to the GIC in the system,
while the status of each INTx can be obtained through the INTX CSR
register
Signed-off-by: Ray Jui
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 100 +++-
drivers/pci/controller/pcie-iproc.h | 6 +++
2 files changed, 104 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index e3ca464..f8edd28 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -270,6 +271,7 @@ enum iproc_pcie_reg {
/* enable INTx */
IPROC_PCIE_INTX_EN,
+ IPROC_PCIE_INTX_CSR,
/* outbound address mapping */
IPROC_PCIE_OARR0,
@@ -314,6 +316,7 @@ static const u16 iproc_pcie_reg_paxb_bcma[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN]= 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_LINK_STATUS]= 0xf0c,
};
@@ -325,6 +328,7 @@ static const u16 iproc_pcie_reg_paxb[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN]= 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_OARR0] = 0xd20,
[IPROC_PCIE_OMAP0] = 0xd40,
[IPROC_PCIE_OARR1] = 0xd28,
@@ -341,6 +345,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_CFG_ADDR] = 0x1f8,
[IPROC_PCIE_CFG_DATA] = 0x1fc,
[IPROC_PCIE_INTX_EN]= 0x330,
+ [IPROC_PCIE_INTX_CSR] = 0x334,
[IPROC_PCIE_OARR0] = 0xd20,
[IPROC_PCIE_OMAP0] = 0xd40,
[IPROC_PCIE_OARR1] = 0xd28,
@@ -846,9 +851,95 @@ static int iproc_pcie_check_link(struct iproc_pcie *pcie)
return link_is_active ? 0 : -ENODEV;
}
-static void iproc_pcie_enable(struct iproc_pcie *pcie)
+static int iproc_pcie_intx_map(struct irq_domain *domain, unsigned int irq,
+ irq_hw_number_t hwirq)
{
+ irq_set_chip_and_handler(irq, _irq_chip, handle_simple_irq);
+ irq_set_chip_data(irq, domain->host_data);
+
+ return 0;
+}
+
+static const struct irq_domain_ops intx_domain_ops = {
+ .map = iproc_pcie_intx_map,
+};
+
+static void iproc_pcie_isr(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct iproc_pcie *pcie;
+ struct device *dev;
+ unsigned long status;
+ u32 bit, virq;
+
+ chained_irq_enter(chip, desc);
+ pcie = irq_desc_get_handler_data(desc);
+ dev = pcie->dev;
+
+ /* go through INTx A, B, C, D until all interrupts are handled */
+ do {
+ status = iproc_pcie_read_reg(pcie, IPROC_PCIE_INTX_CSR);
+ for_each_set_bit(bit, , PCI_NUM_INTX) {
+ virq = irq_find_mapping(pcie->irq_domain, bit + 1);
+ if (virq)
+ generic_handle_irq(virq);
+ else
+ dev_err(dev, "unexpected INTx%u\n", bit);
+ }
+ } while ((status & SYS_RC_INTX_MASK) != 0);
+
+ chained_irq_exit(chip, desc);
+}
+
+static int iproc_pcie_intx_enable(struct iproc_pcie *pcie)
+{
+ struct device *dev = pcie->dev;
+ struct device_node *node;
+ int ret;
+
iproc_pcie_write_reg(pcie, IPROC_PCIE_INTX_EN, SYS_RC_INTX_MASK);
+ /*
+* BCMA devices do not map INTx the same way as platform devices. All
+* BCMA needs is the above code to enable INTx
+*/
+
+ node = of_get_compatible_child(dev->of_node, "brcm,iproc-intc");
+ if (node)
+ pcie->irq = of_irq_get(node, 0);
+
+ if (!node || pcie->irq <= 0)
+ return 0;
+
+ /* set IRQ handler */
+ irq_set_chained_handler_and_data(pcie->irq, iproc_pcie_isr, pcie);
+
+ /* add IRQ domain for INTx */
+ pcie->irq_domain = irq_domain_add_linear(node, PCI_NUM_INTX + 1,
+_domain_ops, pcie);
+ if (!pcie->irq_domain) {
+ dev_err(dev, "failed to add INTx IRQ domain\n");
+ ret = -ENOMEM;
+ goto err_rm_handler_data;
+ }
+
+ return 0;
+
+err_rm_handler_data:
+ of_node_put(node);
+ irq_set_chained_handler_and_data(pcie->irq, NULL, NULL);
+
+ return ret;
+}
+
+static void iproc_pcie_intx
[PATCH v2 4/6] arm: dts: Change PCIe INTx mapping for NSP
From: Ray Jui
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui
Signed-off-by: Srinath Mannam
---
arch/arm/boot/dts/bcm-nsp.dtsi | 45 --
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 6925b30..0e28817 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -532,8 +532,11 @@
reg = <0x18012000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <0>;
@@ -562,6 +565,14 @@
;
brcm,pcie-msi-inten;
};
+
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
pcie1: pcie@18013000 {
@@ -569,8 +580,11 @@
reg = <0x18013000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 137 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <1>;
@@ -599,6 +613,14 @@
;
brcm,pcie-msi-inten;
};
+
+ pcie1_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
pcie2: pcie@18014000 {
@@ -606,8 +628,11 @@
reg = <0x18014000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <2>;
@@ -636,6 +661,14 @@
;
brcm,pcie-msi-inten;
};
+
+ pcie2_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
thermal-zones {
--
2.7.4
[PATCH v2 0/6] PAXB INTx support with proper model
This patch series adds PCIe legacy interrupt (INTx) support to the iProc PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA, INTB, INTC, INTD share the same interrupt line connected to the GIC in the system. This is now modeled by using its own IRQ domain. Also update all relevant devicetree files to adapt to the new model. This patch set is based on Linux-5.2-rc4. Changes from v1: - Addressed Rob, Lorenzo, Arnd's comments - Used child node for interrupt controller. - Addressed Andy Shevchenko's comments - Replaced while loop with do-while. Ray Jui (6): dt-bindings: pci: Update iProc PCI binding for INTx support PCI: iproc: Add INTx support with better modeling arm: dts: Change PCIe INTx mapping for Cygnus arm: dts: Change PCIe INTx mapping for NSP arm: dts: Change PCIe INTx mapping for HR2 arm64: dts: Change PCIe INTx mapping for NS2 .../devicetree/bindings/pci/brcm,iproc-pcie.txt| 48 -- arch/arm/boot/dts/bcm-cygnus.dtsi | 30 ++- arch/arm/boot/dts/bcm-hr2.dtsi | 30 ++- arch/arm/boot/dts/bcm-nsp.dtsi | 45 -- arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 28 +- drivers/pci/controller/pcie-iproc.c| 100 - drivers/pci/controller/pcie-iproc.h| 6 ++ 7 files changed, 260 insertions(+), 27 deletions(-) -- 2.7.4
[PATCH v2 1/6] dt-bindings: pci: Update iProc PCI binding for INTx support
From: Ray Jui
Update the iProc PCIe binding document for better modeling of the legacy
interrupt (INTx) support
Signed-off-by: Ray Jui
Signed-off-by: Srinath Mannam
---
.../devicetree/bindings/pci/brcm,iproc-pcie.txt| 48 ++
1 file changed, 41 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
index df065aa..f23decb 100644
--- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt
@@ -13,9 +13,6 @@ controller, used in Stingray
PAXB-based root complex is used for external endpoint devices. PAXC-based
root complex is connected to emulated endpoint devices internal to the ASIC
- reg: base address and length of the PCIe controller I/O register space
-- #interrupt-cells: set to <1>
-- interrupt-map-mask and interrupt-map, standard PCI properties to define the
- mapping of the PCIe interface to interrupt numbers
- linux,pci-domain: PCI domain ID. Should be unique for each host controller
- bus-range: PCI bus numbers covered
- #address-cells: set to <3>
@@ -41,6 +38,21 @@ Required:
- brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal
address used by the iProc PCIe core (not the PCIe address)
+Legacy interrupt (INTx) support (optional):
+
+Note INTx is for PAXB only.
+- interrupt-map-mask and interrupt-map, standard PCI properties to define
+the mapping of the PCIe interface to interrupt numbers
+
+In addition, a sub-node that describes the legacy interrupt controller built
+into the PCIe controller.
+This sub-node must have the following properties:
+ - compatible: must be "brcm,iproc-intc"
+ - interrupt-controller: claims itself as an interrupt controller for INTx
+ - #interrupt-cells: set to <1>
+ - interrupts: interrupt line wired to the generic GIC for INTx support
+ - interrupt-parent: Phandle to the parent interrupt controller
+
MSI support (optional):
For older platforms without MSI integrated in the GIC, iProc PCIe core provides
@@ -77,8 +89,11 @@ Example:
reg = <0x18012000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 100 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <0>;
@@ -98,6 +113,14 @@ Example:
msi-parent = <>;
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
+
/* iProc event queue based MSI */
msi0: msi@18012000 {
compatible = "brcm,iproc-msi";
@@ -115,8 +138,11 @@ Example:
reg = <0x18013000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 106 IRQ_TYPE_NONE>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <1>;
@@ -130,4 +156,12 @@ Example:
phys = < 1 6>;
phy-names = "pcie-phy";
+
+ pcie1_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
--
2.7.4
[PATCH v2 3/6] arm: dts: Change PCIe INTx mapping for Cygnus
From: Ray Jui
Change the PCIe INTx mapping to model the 4 INTx interrupts in the
IRQ domain of the iProc PCIe controller itself
Signed-off-by: Ray Jui
Signed-off-by: Srinath Mannam
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 5f7b465..9d3d9ef 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -264,8 +264,11 @@
reg = <0x18012000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 100
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <0>;
@@ -292,6 +295,14 @@
,
;
};
+
+ pcie0_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
pcie1: pcie@18013000 {
@@ -299,8 +310,11 @@
reg = <0x18013000 0x1000>;
#interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0 0 0 0 GIC_SPI 106
IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 1>,
+ <0 0 0 2 _intc 2>,
+ <0 0 0 3 _intc 3>,
+ <0 0 0 4 _intc 4>;
linux,pci-domain = <1>;
@@ -327,6 +341,14 @@
,
;
};
+
+ pcie1_intc: interrupt-controller {
+ compatible = "brcm,iproc-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <>;
+ interrupts = ;
+ };
};
dma0: dma@18018000 {
--
2.7.4
Re: [PATCH v2 2/5] dt-bindings: phy: Modify Stingray USB PHY #phy-cells
Hi Rob,
Thanks for the review.
I will modify commit message and send new patch set.
We have a plan to upstream DTS files. We will send DTS changes in
different patch set once this is done.
Regards,
Srinath.
On Wed, Aug 21, 2019 at 11:51 PM Rob Herring wrote:
>
> On Wed, Jul 31, 2019 at 03:49:52PM +0530, Srinath Mannam wrote:
> > Increase #phy-cells from 1 to 2 to have bitmask of PHY enabled ports.
>
> And from 0 to 1...
>
> Are you going to update all the dts files so when we convert this to
> schema we don't get a bunch of warnings? (Feel free to convert this
> to schema too).
>
> >
> > Signed-off-by: Srinath Mannam
> > ---
> > .../devicetree/bindings/phy/brcm,stingray-usb-phy.txt | 14
> > --
> > 1 file changed, 8 insertions(+), 6 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > index 4ba2989..aeb0568 100644
> > --- a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > +++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > @@ -6,9 +6,11 @@ Required properties:
> > - "brcm,sr-usb-hs-phy" is a single HS PHY.
> > - reg: offset and length of the PHY blocks registers
> > - #phy-cells:
> > - - Must be 1 for brcm,sr-usb-combo-phy as it expects one argument to
> > indicate
> > - the PHY number of two PHYs. 0 for HS PHY and 1 for SS PHY.
> > - - Must be 0 for brcm,sr-usb-hs-phy.
> > + - Must be 2 for brcm,sr-usb-combo-phy.
> > + - Cell 1 - PHY Number, 0 for HS PHY and 1 for SS PHY.
> > + - Cell 2 - Bitmask of enabled ports connected to USB Host controller.
> > + - Must be 1 for brcm,sr-usb-hs-phy to indicate Bit mask of ports
> > connected
> > + to USB Host controller.
> >
> > Refer to phy/phy-bindings.txt for the generic PHY binding properties
> >
> > @@ -16,17 +18,17 @@ Example:
> > usbphy0: usb-phy@0 {
> > compatible = "brcm,sr-usb-combo-phy";
> > reg = <0x 0x100>;
> > - #phy-cells = <1>;
> > + #phy-cells = <2>;
> > };
> >
> > usbphy1: usb-phy@1 {
> > compatible = "brcm,sr-usb-combo-phy";
> > reg = <0x0001 0x100>,
> > - #phy-cells = <1>;
> > + #phy-cells = <2>;
> > };
> >
> > usbphy2: usb-phy@2 {
> > compatible = "brcm,sr-usb-hs-phy";
> > reg = <0x0002 0x100>,
> > - #phy-cells = <0>;
> > + #phy-cells = <1>;
> > };
> > --
> > 2.7.4
> >
[PATCH] PCI: Add PCIE ACS quirk for IPROC PAXB
From: Abhinav Ratna
IPROC PAXB RC doesn't support ACS capabilities and control registers.
Add quirk to have separate IOMMU groups for all EPs and functions connected
to root port, by masking RR/CR/SV/UF bits.
Signed-off-by: Abhinav Ratna
Signed-off-by: Srinath Mannam
---
drivers/pci/quirks.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 0f16acc..f9584c0 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4466,6 +4466,21 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev
*dev, u16 acs_flags)
return acs_flags ? 0 : 1;
}
+static int pcie_quirk_brcm_bridge_acs(struct pci_dev *dev, u16 acs_flags)
+{
+ /*
+* IPROC PAXB RC doesn't support ACS capabilities and control registers.
+* Add quirk to to have separate IOMMU groups for all EPs and functions
+* connected to root port, by masking RR/CR/SV/UF bits.
+*/
+
+ u16 flags = (PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_SV);
+ int ret = acs_flags & ~flags ? 0 : 1;
+
+ return ret;
+}
+
+
static const struct pci_dev_acs_enabled {
u16 vendor;
u16 device;
@@ -4559,6 +4574,7 @@ static const struct pci_dev_acs_enabled {
{ PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs },
{ PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs },
{ PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs },
+ { PCI_VENDOR_ID_BROADCOM, 0xD714, pcie_quirk_brcm_bridge_acs },
{ 0 }
};
--
2.7.4
Re: [PATCH v4 0/3] PCIe Host request to reserve IOVA
Hi Lorenzo, Thanks a lot. Please see my reply below. On Wed, May 1, 2019 at 7:24 PM Lorenzo Pieralisi wrote: > > On Wed, May 01, 2019 at 02:20:56PM +0100, Robin Murphy wrote: > > On 2019-05-01 1:55 pm, Bjorn Helgaas wrote: > > > On Wed, May 01, 2019 at 12:30:38PM +0100, Lorenzo Pieralisi wrote: > > > > On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath Mannam wrote: > > > > > Few SOCs have limitation that their PCIe host can't allow few inbound > > > > > address ranges. Allowed inbound address ranges are listed in > > > > > dma-ranges > > > > > DT property and this address ranges are required to do IOVA mapping. > > > > > Remaining address ranges have to be reserved in IOVA mapping. > > > > > > > > > > PCIe Host driver of those SOCs has to list resource entries of allowed > > > > > address ranges given in dma-ranges DT property in sorted order. This > > > > > sorted list of resources will be processed and reserve IOVA address > > > > > for > > > > > inaccessible address holes while initializing IOMMU domain. > > > > > > > > > > This patch set is based on Linux-5.0-rc2. > > > > > > > > > > Changes from v3: > > > > >- Addressed Robin Murphy review comments. > > > > > - pcie-iproc: parse dma-ranges and make sorted resource list. > > > > > - dma-iommu: process list and reserve gaps between entries > > > > > > > > > > Changes from v2: > > > > >- Patch set rebased to Linux-5.0-rc2 > > > > > > > > > > Changes from v1: > > > > >- Addressed Oza review comments. > > > > > > > > > > Srinath Mannam (3): > > > > >PCI: Add dma_ranges window list > > > > >iommu/dma: Reserve IOVA for PCIe inaccessible DMA address > > > > >PCI: iproc: Add sorted dma ranges resource entries to host bridge > > > > > > > > > > drivers/iommu/dma-iommu.c | 19 > > > > > drivers/pci/controller/pcie-iproc.c | 44 > > > > > - > > > > > drivers/pci/probe.c | 3 +++ > > > > > include/linux/pci.h | 1 + > > > > > 4 files changed, 66 insertions(+), 1 deletion(-) > > > > > > > > Bjorn, Joerg, > > > > > > > > this series should not affect anything in the mainline other than its > > > > consumer (ie patch 3); if that's the case should we consider it for v5.2 > > > > and if yes how are we going to merge it ? > > > > > > I acked the first one > > > > > > Robin reviewed the second > > > (https://lore.kernel.org/lkml/e6c812d6-0cad-4cfd-defd-d7ec427a6...@arm.com) > > > (though I do agree with his comment about DMA_BIT_MASK()), Joerg was OK > > > with it if Robin was > > > (https://lore.kernel.org/lkml/20190423145721.gh29...@8bytes.org). > > > > > > Eric reviewed the third (and pointed out a typo). > > > > > > My Kconfiggery never got fully answered -- it looks to me as though it's > > > possible to build pcie-iproc without the DMA hole support, and I thought > > > the whole point of this series was to deal with those holes > > > (https://lore.kernel.org/lkml/20190418234241.gf126...@google.com). I > > > would > > > have expected something like making pcie-iproc depend on IOMMU_SUPPORT. > > > But Srinath didn't respond to that, so maybe it's not an issue and it > > > should only affect pcie-iproc anyway. > > > > Hmm, I'm sure I had at least half-written a reply on that point, but I > > can't seem to find it now... anyway, the gist is that these inbound > > windows are generally set up to cover the physical address ranges of DRAM > > and anything else that devices might need to DMA to. Thus if you're not > > using an IOMMU, the fact that devices can't access the gaps in between > > doesn't matter because there won't be anything there anyway; it only > > needs mitigating if you do use an IOMMU and start giving arbitrary > > non-physical addresses to the endpoint. > > So basically there is no strict IOMMU_SUPPORT dependency. Yes, without IOMMU_SUPPORT, all inbound addresses will fall inside dma-ranges. Issue is only in the case of IOMMU enable, this patch will address by reserving non-allowed address (holes of dma-ranges) by reserving them. > > > > So bottom line, I'm fine with merging it for v5.2. Do you want to merge > > > it, Lorenzo, or ...? > > > > This doesn't look like it will conflict with the other DMA ops and MSI > > mapping changes currently in-flight for iommu-dma, so I have no > > objection to it going through the PCI tree for 5.2. > > I will update the DMA_BIT_MASK() according to your review and fix the > typo Eric pointed out and push out a branch - we shall see if we can > include it for v5.2. I will send new patches with the change DMA_BIT_MASK() and typo along with Bjorn's comment in PATCH-1. Regards, Srinath. > > Thanks, > Lorenzo
[PATCH] thermal: broadcom: Remove ACPI support
Unlike DT framework, thermal-zones and its parameters can't be parsed
using ACPI framework. So that ACPI support is removed in this driver.
Signed-off-by: Srinath Mannam
Reported-by: David Woodhouse
---
drivers/thermal/broadcom/sr-thermal.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/thermal/broadcom/sr-thermal.c
b/drivers/thermal/broadcom/sr-thermal.c
index 2284cbe..475ce29 100644
--- a/drivers/thermal/broadcom/sr-thermal.c
+++ b/drivers/thermal/broadcom/sr-thermal.c
@@ -3,7 +3,6 @@
* Copyright (C) 2018 Broadcom
*/
-#include
#include
#include
#include
@@ -100,18 +99,11 @@ static const struct of_device_id sr_thermal_of_match[] = {
};
MODULE_DEVICE_TABLE(of, sr_thermal_of_match);
-static const struct acpi_device_id sr_thermal_acpi_ids[] = {
- { .id = "BRCM0500" },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(acpi, sr_thermal_acpi_ids);
-
static struct platform_driver sr_thermal_driver = {
.probe = sr_thermal_probe,
.driver = {
.name = "sr-thermal",
.of_match_table = sr_thermal_of_match,
- .acpi_match_table = ACPI_PTR(sr_thermal_acpi_ids),
},
};
module_platform_driver(sr_thermal_driver);
--
2.7.4
Re: [PATCH 3/3] thermal: broadcom: Add Stingray thermal driver
Hi David, Thank you for notifying.. Hi Sudeep, I will send a patch to remove ACPI support. Regards, Srinath. On Mon, Apr 29, 2019 at 8:54 PM Sudeep Holla wrote: > > On Mon, Apr 29, 2019 at 06:07:12PM +0300, David Woodhouse wrote: > > On Mon, 2018-05-28 at 11:11 +0530, Srinath Mannam wrote: > > > From: Pramod Kumar > > > > > > This commit adds stingray thermal driver to monitor six > > > thermal zones temperature and trips at critical temperature. > > > > This matches an ACPI "BRCM0500" device but then calls > > devm_thermal_zone_of_sensor_register(), which AFAICT is going to fail > > on an ACPI system because the first thing that does is call > > of_find_node_by_name(NULL, "thermal-zones") which isn't going to find a > > match. > > > > Thanks David for bringing this up. I hadn't noticed that this driver is > cheekily trying to do thermal management in ACPI using crafty > acpi_device_id match. ACPI thermal objects/methods must be used in the > firmware to do thermal management. > > Pramod, can you remove the ACPI support or I can go ahead and post the > patch to do the same ? > > > How does this work in the ACPI case? > > It can't and shouldn't work if one can make it happen :) > > -- > Regards, > Sudeep
[PATCH] PCI: iproc: Enable iProc config read for PAXBv2
iProc config read flag has to enable for PAXBv2 instead of PAXB.
Fixes: f78e60a29d4ff ("PCI: iproc: Reject unconfigured physical functions from
PAXC")
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index c20fd6b..9d5cbc7 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1347,7 +1347,6 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
break;
case IPROC_PCIE_PAXB:
regs = iproc_pcie_reg_paxb;
- pcie->iproc_cfg_read = true;
pcie->has_apb_err_disable = true;
if (pcie->need_ob_cfg) {
pcie->ob_map = paxb_ob_map;
@@ -1356,6 +1355,7 @@ static int iproc_pcie_rev_init(struct iproc_pcie *pcie)
break;
case IPROC_PCIE_PAXB_V2:
regs = iproc_pcie_reg_paxb_v2;
+ pcie->iproc_cfg_read = true;
pcie->has_apb_err_disable = true;
if (pcie->need_ob_cfg) {
pcie->ob_map = paxb_v2_ob_map;
--
2.7.4
[PATCH v4 2/3] iommu/dma: Reserve IOVA for PCIe inaccessible DMA address
dma_ranges field of PCI host bridge structure has resource entries in
sorted order of address range given through dma-ranges DT property. This
list is the accessible DMA address range. So that this resource list will
be processed and reserve IOVA address to the inaccessible address holes in
the list.
This method is similar to PCI IO resources address ranges reserving in
IOMMU for each EP connected to host bridge.
Signed-off-by: Srinath Mannam
Based-on-patch-by: Oza Pawandeep
Reviewed-by: Oza Pawandeep
---
drivers/iommu/dma-iommu.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d19f3d6..fb42d7c 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -212,6 +212,7 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
struct resource_entry *window;
unsigned long lo, hi;
+ phys_addr_t start = 0, end;
resource_list_for_each_entry(window, >windows) {
if (resource_type(window->res) != IORESOURCE_MEM)
@@ -221,6 +222,24 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+ /* Get reserved DMA windows from host bridge */
+ resource_list_for_each_entry(window, >dma_ranges) {
+ end = window->res->start - window->offset;
+resv_iova:
+ if (end - start) {
+ lo = iova_pfn(iovad, start);
+ hi = iova_pfn(iovad, end);
+ reserve_iova(iovad, lo, hi);
+ }
+ start = window->res->end - window->offset + 1;
+ /* If window is last entry */
+ if (window->node.next == >dma_ranges &&
+ end != DMA_BIT_MASK(sizeof(dma_addr_t) * BITS_PER_BYTE)) {
+ end = DMA_BIT_MASK(sizeof(dma_addr_t) * BITS_PER_BYTE);
+ goto resv_iova;
+ }
+ }
}
static int iova_reserve_iommu_regions(struct device *dev,
--
2.7.4
[PATCH v4 0/3] PCIe Host request to reserve IOVA
Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those SOCs has to list resource entries of allowed address ranges given in dma-ranges DT property in sorted order. This sorted list of resources will be processed and reserve IOVA address for inaccessible address holes while initializing IOMMU domain. This patch set is based on Linux-5.0-rc2. Changes from v3: - Addressed Robin Murphy review comments. - pcie-iproc: parse dma-ranges and make sorted resource list. - dma-iommu: process list and reserve gaps between entries Changes from v2: - Patch set rebased to Linux-5.0-rc2 Changes from v1: - Addressed Oza review comments. Srinath Mannam (3): PCI: Add dma_ranges window list iommu/dma: Reserve IOVA for PCIe inaccessible DMA address PCI: iproc: Add sorted dma ranges resource entries to host bridge drivers/iommu/dma-iommu.c | 19 drivers/pci/controller/pcie-iproc.c | 44 - drivers/pci/probe.c | 3 +++ include/linux/pci.h | 1 + 4 files changed, 66 insertions(+), 1 deletion(-) -- 2.7.4
Re: [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
Hi Lorenzo,
I am sorry, I took your long time. In my commit log I gave details
about purpose of feature instead of implementation.
Thanks a lot for all inputs and knowledge. I will remember and follow
these notes while writing commit log.
commit log re-written by you is very much impressive and have detailed
description of feature and implementation.
Thank again for you patience.
Regards,
Srinath.
On Wed, Apr 3, 2019 at 5:01 PM Lorenzo Pieralisi
wrote:
>
> On Wed, Apr 03, 2019 at 08:41:44AM +0530, Srinath Mannam wrote:
> > Hi Lorenzo,
> >
> > Please see my reply below,
> >
> > On Tue, Apr 2, 2019 at 7:08 PM Lorenzo Pieralisi
> > wrote:
> > >
> > > On Tue, Apr 02, 2019 at 04:16:13PM +0530, Srinath Mannam wrote:
> > >
> > > [...]
> > >
> > > > > Ok - I start to understand. What does it mean in HW terms that your
> > > > > 32bit AXI address region size is 32MB ? Please explain to me in
> > > > > details.
> > > > >
> > > > In our PCIe controller HW, AXI address from 0x4200 to 0x4400
> > > > of 32MB size and .
> > > > AXI address from 0x4 to 0x48000 of 2GB size are provided
> > > > to map ob address.
> > > > First IO region is inside 32bit address and second IO region is
> > > > outside 32bit address.
> > > > This code change is to map first IO region(0x4200 to 0x4400).
> > > >
> > > > > IIUC you are using an OARR0 of 128MB in size to map a 32MB address
> > > > > region, that's what I understand this patch does (and the lowest index
> > > > > corresponds to the smallest possible size - it is far from clear by
> > > > > looking at the patch).
> > > > Yes, lowest index corresponds to smallest possible size (128MB).
> > > > In our controller we have multiple windows like OARR0, OARR1, OARR2,
> > > > OARR3 all supports multiple sizes from 128MB to 1024MB.
> > > > These details are given at the top of this driver file, as shown
> > > > below. all windows supports 128MB size still we must use OARR0 window
> > > > to configure first IO region(0x4200 to 0x4400).
> > > >
> > > > static const struct iproc_pcie_ob_map paxb_v2_ob_map[] = {
> > > > {
> > > > /* OARR0/OMAP0 */
> > > > .window_sizes = { 128, 256 },
> > > > .nr_sizes = 2,
> > > > },
> > > > {
> > > > /* OARR1/OMAP1 */
> > > > .window_sizes = { 128, 256 },
> > > > .nr_sizes = 2,
> > > > },
> > > > {
> > > > /* OARR2/OMAP2 */
> > > > .window_sizes = { 128, 256, 512, 1024 },
> > > > .nr_sizes = 4,
> > > > },
> > > > {
> > > > /* OARR3/OMAP3 */
> > > > .window_sizes = { 128, 256, 512, 1024 },
> > > > .nr_sizes = 4,
> > > > },
> > > > };
> > >
> > > Ok so this patch allows mapping an AXI I/O window that is smaller
> > > than OARR possible sizes, why it was not done from the beginning
> > > I really do not know.
> > >
> > Same Iproc driver we use for multiple SOCs, in previous SOCs does not
> > have 32-bit AXI address region to map ob.
> > In the present SOC, 32-bit AXI address region is available so that
> > this change is added.
> >
> > > Now explain this to me please:
> > >
> > > > This patch add outbound window configuration to map below 32-bit I/O
> > > > range
> > > > with corresponding PCI memory, which helps to access I/O region in ARM
> > > > 32-bit and one to one mapping of I/O region to PCI memory.
> > > >
> > > > Ex:
> > > > 1. ranges DT property given for current driver is,
> > > > ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>;
> > > > I/O region address is 0x4
> > > > 2. ranges DT property can be given after this patch,
> > > > ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>;
> > > > I/O region address is 0x4200
> > >
> > > Why 1:1 AXI<->PCI address mapping is not possible in (1), how does the
> > > current code works on 32-bit systems and what's the benefit your change
> > > is bringing.
> > non-prefetchable memory range can only support 32-bit addresses, so
> > that we have taken 32-bit PCI bus address in (1).
> > current code does not work in 32-bit systems. In the present SOC with
> > this new change we can access from 32-bit CPU.
>
> Thank you. I rewrote the log and pushed patches to pci/iproc, please
> have a look (Ray/Scott please do have a look too) and report back
> if that's fine.
>
> Do you agree that the initial commit was lacking _significant_
> information ? Please remember that the commit log plays a fundamental
> part in understanding a change and this one is a very important one
> so I am being pedantic on it.
>
> Thanks,
> Lorenzo
Re: [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
Hi Lorenzo,
Please see my reply below,
On Tue, Apr 2, 2019 at 7:08 PM Lorenzo Pieralisi
wrote:
>
> On Tue, Apr 02, 2019 at 04:16:13PM +0530, Srinath Mannam wrote:
>
> [...]
>
> > > Ok - I start to understand. What does it mean in HW terms that your
> > > 32bit AXI address region size is 32MB ? Please explain to me in details.
> > >
> > In our PCIe controller HW, AXI address from 0x4200 to 0x4400
> > of 32MB size and .
> > AXI address from 0x4 to 0x48000 of 2GB size are provided
> > to map ob address.
> > First IO region is inside 32bit address and second IO region is
> > outside 32bit address.
> > This code change is to map first IO region(0x4200 to 0x4400).
> >
> > > IIUC you are using an OARR0 of 128MB in size to map a 32MB address
> > > region, that's what I understand this patch does (and the lowest index
> > > corresponds to the smallest possible size - it is far from clear by
> > > looking at the patch).
> > Yes, lowest index corresponds to smallest possible size (128MB).
> > In our controller we have multiple windows like OARR0, OARR1, OARR2,
> > OARR3 all supports multiple sizes from 128MB to 1024MB.
> > These details are given at the top of this driver file, as shown
> > below. all windows supports 128MB size still we must use OARR0 window
> > to configure first IO region(0x4200 to 0x4400).
> >
> > static const struct iproc_pcie_ob_map paxb_v2_ob_map[] = {
> > {
> > /* OARR0/OMAP0 */
> > .window_sizes = { 128, 256 },
> > .nr_sizes = 2,
> > },
> > {
> > /* OARR1/OMAP1 */
> > .window_sizes = { 128, 256 },
> > .nr_sizes = 2,
> > },
> > {
> > /* OARR2/OMAP2 */
> > .window_sizes = { 128, 256, 512, 1024 },
> > .nr_sizes = 4,
> > },
> > {
> > /* OARR3/OMAP3 */
> > .window_sizes = { 128, 256, 512, 1024 },
> > .nr_sizes = 4,
> > },
> > };
>
> Ok so this patch allows mapping an AXI I/O window that is smaller
> than OARR possible sizes, why it was not done from the beginning
> I really do not know.
>
Same Iproc driver we use for multiple SOCs, in previous SOCs does not
have 32-bit AXI address region to map ob.
In the present SOC, 32-bit AXI address region is available so that
this change is added.
> Now explain this to me please:
>
> > This patch add outbound window configuration to map below 32-bit I/O range
> > with corresponding PCI memory, which helps to access I/O region in ARM
> > 32-bit and one to one mapping of I/O region to PCI memory.
> >
> > Ex:
> > 1. ranges DT property given for current driver is,
> > ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>;
> > I/O region address is 0x4
> > 2. ranges DT property can be given after this patch,
> > ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>;
> > I/O region address is 0x4200
>
> Why 1:1 AXI<->PCI address mapping is not possible in (1), how does the
> current code works on 32-bit systems and what's the benefit your change
> is bringing.
non-prefetchable memory range can only support 32-bit addresses, so
that we have taken 32-bit PCI bus address in (1).
current code does not work in 32-bit systems. In the present SOC with
this new change we can access from 32-bit CPU.
Regards,
Srinath.
>
> Thanks,
> Lorenzo
Re: [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
Hi Lorenzo, Please see my reply below, On Tue, Apr 2, 2019 at 3:56 PM Lorenzo Pieralisi wrote: > > On Tue, Apr 02, 2019 at 03:20:21PM +0530, Srinath Mannam wrote: > > Hi Ray, > > > > Thanks for detailed explanation. > > Please see some more details below. > > > > On Tue, Apr 2, 2019 at 3:33 AM Ray Jui wrote: > > > > > > Hi Lorenzo/Srinath, > > > > > > I look at the commit message again and indeed it looks quite confusing. > > > > > > I'll add my comment inline in the code section. I hope that will help to > > > make it more clear. > > > > > > On 4/1/2019 9:44 AM, Lorenzo Pieralisi wrote: > > > > On Mon, Apr 01, 2019 at 11:04:48AM +0530, Srinath Mannam wrote: > > > >> Hi Lorenzo, > > > >> > > > >> Please see my reply below, > > > >> > > > >> On Fri, Mar 29, 2019 at 11:06 PM Lorenzo Pieralisi > > > >> wrote: > > > >>> > > > >>> On Fri, Mar 01, 2019 at 10:22:16AM +0530, Srinath Mannam wrote: > > > >>>> In the present driver outbound window configuration is done to map > > > >>>> above > > > >>>> 32-bit address I/O regions with corresponding PCI memory range given > > > >>>> in > > > >>>> ranges DT property. > > > >>>> > > > >>>> This patch add outbound window configuration to map below 32-bit I/O > > > >>>> range > > > >>>> with corresponding PCI memory, which helps to access I/O region in > > > >>>> ARM > > > >>>> 32-bit and one to one mapping of I/O region to PCI memory. > > > >>>> > > > >>>> Ex: > > > >>>> 1. ranges DT property given for current driver is, > > > >>>> ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>; > > > >>>> I/O region address is 0x4 > > > >>>> 2. ranges DT property can be given after this patch, > > > >>>> ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>; > > > >>>> I/O region address is 0x4200 > > > >>> > > > >>> I was applying this patch but I don't understand the commit log and > > > >>> how it matches the code, please explain it to me and I will reword > > > >>> it. > > > >> Iproc PCIe host controller supports outbound address translation > > > >> feature to translate AXI address to PCI bus address. > > > >> IO address ranges (AXI and PCI) given through ranges DT property have > > > >> to program to controller outbound window registers. > > > >> Present driver has the support for only 64bit AXI address. so that > > > >> ranges DT property has given as 64bit AXI address and 32 bit > > > >> PCI bus address. > > > >> But with this patch 32-bit AXI address also could be programmed to > > > >> Iproc host controller outbound window registers. so that ranges > > > >> DT property can have 32bit AXI address which can map to 32-bit PCI bus > > > >> address. > > > > > > > > The code change seems to add a check for the window size, I see no > > > > notion of 64 vs 32 bit addressing there so I am pretty sure there is > > > > something you are not telling me that is implicit in the IProc outbound > > > > window configuration, for instance why is the lowest index window > > > > considered for 32-bit. > > > > > > > > AFAICS you are adding code to allow a window whose size is < than > > > > the lowest index in the ob_map array. How this relates to 64 vs > > > > 32 bit addresses is not clear but it should be. > > > > > > > > When I read your commit log it is impossible to understand how it > > > > correlates to the code you are changing - I still have not figured it > > > > out myself. > > > > > > > > Please explain in detail to me how this works, forget DT changes I > > > > want to understand how HW works. > > > > > > > > Lorenzo > > > > > > > >> Example given in commit log is describing ranges DT property changes > > > >> with and without this patch. > > > >> In the case, without this patch AXI address is mo
Re: [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
Hi Ray, Thanks for detailed explanation. Please see some more details below. On Tue, Apr 2, 2019 at 3:33 AM Ray Jui wrote: > > Hi Lorenzo/Srinath, > > I look at the commit message again and indeed it looks quite confusing. > > I'll add my comment inline in the code section. I hope that will help to > make it more clear. > > On 4/1/2019 9:44 AM, Lorenzo Pieralisi wrote: > > On Mon, Apr 01, 2019 at 11:04:48AM +0530, Srinath Mannam wrote: > >> Hi Lorenzo, > >> > >> Please see my reply below, > >> > >> On Fri, Mar 29, 2019 at 11:06 PM Lorenzo Pieralisi > >> wrote: > >>> > >>> On Fri, Mar 01, 2019 at 10:22:16AM +0530, Srinath Mannam wrote: > >>>> In the present driver outbound window configuration is done to map above > >>>> 32-bit address I/O regions with corresponding PCI memory range given in > >>>> ranges DT property. > >>>> > >>>> This patch add outbound window configuration to map below 32-bit I/O > >>>> range > >>>> with corresponding PCI memory, which helps to access I/O region in ARM > >>>> 32-bit and one to one mapping of I/O region to PCI memory. > >>>> > >>>> Ex: > >>>> 1. ranges DT property given for current driver is, > >>>> ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>; > >>>> I/O region address is 0x4 > >>>> 2. ranges DT property can be given after this patch, > >>>> ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>; > >>>> I/O region address is 0x4200 > >>> > >>> I was applying this patch but I don't understand the commit log and > >>> how it matches the code, please explain it to me and I will reword > >>> it. > >> Iproc PCIe host controller supports outbound address translation > >> feature to translate AXI address to PCI bus address. > >> IO address ranges (AXI and PCI) given through ranges DT property have > >> to program to controller outbound window registers. > >> Present driver has the support for only 64bit AXI address. so that > >> ranges DT property has given as 64bit AXI address and 32 bit > >> PCI bus address. > >> But with this patch 32-bit AXI address also could be programmed to > >> Iproc host controller outbound window registers. so that ranges > >> DT property can have 32bit AXI address which can map to 32-bit PCI bus > >> address. > > > > The code change seems to add a check for the window size, I see no > > notion of 64 vs 32 bit addressing there so I am pretty sure there is > > something you are not telling me that is implicit in the IProc outbound > > window configuration, for instance why is the lowest index window > > considered for 32-bit. > > > > AFAICS you are adding code to allow a window whose size is < than > > the lowest index in the ob_map array. How this relates to 64 vs > > 32 bit addresses is not clear but it should be. > > > > When I read your commit log it is impossible to understand how it > > correlates to the code you are changing - I still have not figured it > > out myself. > > > > Please explain in detail to me how this works, forget DT changes I > > want to understand how HW works. > > > > Lorenzo > > > >> Example given in commit log is describing ranges DT property changes > >> with and without this patch. > >> In the case, without this patch AXI address is more than 32bit > >> "0x4". and with this patch AXI address is 32-bit "0x4200". > >> PCI bus address is 32 bit address in both the cases "0x4000" and > >> 0x4200. > >> > >> Regards, > >> Srinath. > >>> Thanks, > >>> Lorenzo > >>> > >>>> Signed-off-by: Srinath Mannam > >>>> Signed-off-by: Abhishek Shah > >>>> Signed-off-by: Ray Jui > >>>> --- > >>>> drivers/pci/controller/pcie-iproc.c | 21 +++-- > >>>> 1 file changed, 19 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/drivers/pci/controller/pcie-iproc.c > >>>> b/drivers/pci/controller/pcie-iproc.c > >>>> index b882255..080f142 100644 > >>>> --- a/drivers/pci/controller/pcie-iproc.c > >>>> +++ b/drivers/pci/controller/pcie-iproc.c > >>>> @@ -955,8 +955,25 @@ static int ipro
Re: [PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
Hi Lorenzo,
Please see my reply below,
On Fri, Mar 29, 2019 at 11:06 PM Lorenzo Pieralisi
wrote:
>
> On Fri, Mar 01, 2019 at 10:22:16AM +0530, Srinath Mannam wrote:
> > In the present driver outbound window configuration is done to map above
> > 32-bit address I/O regions with corresponding PCI memory range given in
> > ranges DT property.
> >
> > This patch add outbound window configuration to map below 32-bit I/O range
> > with corresponding PCI memory, which helps to access I/O region in ARM
> > 32-bit and one to one mapping of I/O region to PCI memory.
> >
> > Ex:
> > 1. ranges DT property given for current driver is,
> > ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>;
> > I/O region address is 0x4
> > 2. ranges DT property can be given after this patch,
> > ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>;
> > I/O region address is 0x4200
>
> I was applying this patch but I don't understand the commit log and
> how it matches the code, please explain it to me and I will reword
> it.
Iproc PCIe host controller supports outbound address translation
feature to translate AXI address to PCI bus address.
IO address ranges (AXI and PCI) given through ranges DT property have
to program to controller outbound window registers.
Present driver has the support for only 64bit AXI address. so that
ranges DT property has given as 64bit AXI address and 32 bit
PCI bus address.
But with this patch 32-bit AXI address also could be programmed to
Iproc host controller outbound window registers. so that ranges
DT property can have 32bit AXI address which can map to 32-bit PCI bus address.
Example given in commit log is describing ranges DT property changes
with and without this patch.
In the case, without this patch AXI address is more than 32bit
"0x4". and with this patch AXI address is 32-bit "0x4200".
PCI bus address is 32 bit address in both the cases "0x4000" and 0x4200.
Regards,
Srinath.
> Thanks,
> Lorenzo
>
> > Signed-off-by: Srinath Mannam
> > Signed-off-by: Abhishek Shah
> > Signed-off-by: Ray Jui
> > ---
> > drivers/pci/controller/pcie-iproc.c | 21 +++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c
> > b/drivers/pci/controller/pcie-iproc.c
> > index b882255..080f142 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie
> > *pcie, u64 axi_addr,
> > resource_size_t window_size =
> > ob_map->window_sizes[size_idx] * SZ_1M;
> >
> > - if (size < window_size)
> > - continue;
> > + /*
> > + * Keep iterating until we reach the last window and
> > + * with the minimal window size at index zero. In this
> > + * case, we take a compromise by mapping it using the
> > + * minimum window size that can be supported
> > + */
> > + if (size < window_size) {
> > + if (size_idx > 0 || window_idx > 0)
> > + continue;
> > +
> > + /*
> > + * For the corner case of reaching the minimal
> > + * window size that can be supported on the
> > + * last window
> > + */
> > + axi_addr = ALIGN_DOWN(axi_addr, window_size);
> > + pci_addr = ALIGN_DOWN(pci_addr, window_size);
> > + size = window_size;
> > + }
> >
> > if (!IS_ALIGNED(axi_addr, window_size) ||
> > !IS_ALIGNED(pci_addr, window_size)) {
> > --
> > 2.7.4
> >
Re: linux-next: build warning after merge of the phy-next tree
Hi Stephen,
Thanks for the notice.
I sent patch to fix this warning.
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1964942.html
Regards,
Srinath.
On Thu, Mar 28, 2019 at 5:59 AM Stephen Rothwell wrote:
>
> Hi Kishon,
>
> After merging the phy-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> In file included from include/linux/phy/phy.h:19,
> from drivers/phy/broadcom/phy-bcm-sr-usb.c:10:
> drivers/phy/broadcom/phy-bcm-sr-usb.c: In function 'bcm_usb_phy_probe':
> include/linux/device.h:1138:19: warning: 'phy_cfg' may be used uninitialized
> in this function [-Wmaybe-uninitialized]
> dev->driver_data = data;
> ~^~
> drivers/phy/broadcom/phy-bcm-sr-usb.c:289:26: note: 'phy_cfg' was declared
> here
> struct bcm_usb_phy_cfg *phy_cfg;
> ^~~
>
> Introduced by commit
>
> a3b96057577c ("phy: sr-usb: Add Stingray USB PHY driver")
>
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH v4 0/2] Add IPROC PCIe new features
Hi Lorenzo, Thanks for feedback, I will talk to our HW engineer. Regards, Srinath. On Wed, Mar 27, 2019 at 6:01 PM Lorenzo Pieralisi wrote: > > On Wed, Mar 27, 2019 at 02:08:46PM +0530, Srinath Mannam wrote: > > Hi Lorenzo/Bjorn, > > > > Could you please help to review this patch series when you have time? > > I believe I have addressed all your review comments. > > I will shortly keeping in mind that you should really ask HW designers > to get to grips with a proper design because there are ways too many HW > quirks this driver has to fix-up, it has become an unmanageable > collection of work arounds. > > Lorenzo > > > Thanks, > > Srinath. > > > > On Fri, Mar 1, 2019 at 10:22 AM Srinath Mannam > > wrote: > > > > > > This patch set extends support of new IPROC PCIe host controller features > > > - Add CRS check using controller register status flags > > > - Add outbound window mapping configuration for 32-bit I/O region > > > > > > This patch set is based on Linux-5.0-rc2. > > > > > > Changes from v3: > > > - Addressed Lorenzo Pieralisi comments. > > > > > > Changes from v2: > > > - Based on Lorenzo Pieralisi comments, commit logs are expanded. > > > > > > Changes from v1: > > > - Addressed Bjorn Helgaas comments. > > > - Removed set order mode patch from patchset. > > > > > > Srinath Mannam (2): > > > PCI: iproc: Add CRS check in config read > > > PCI: iproc: Add outbound configuration for 32-bit I/O region > > > > > > drivers/pci/controller/pcie-iproc.c | 44 > > > + > > > 1 file changed, 40 insertions(+), 4 deletions(-) > > > > > > -- > > > 2.7.4 > > >
[PATCH] phy: sr-usb: fix build warning
Add invalid version check to fix below warning reported for stingray usb phy driver. The kbuild robot reports: drivers/phy/broadcom/phy-bcm-sr-usb.c: In function 'bcm_usb_phy_probe': warning: 'phy_cfg' may be used uninitialized in this function Fixes: a3b96057577 (phy: sr-usb: Add Stingray USB PHY driver) Reported-by: kbuild test robot Signed-off-by: Srinath Mannam --- drivers/phy/broadcom/phy-bcm-sr-usb.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c b/drivers/phy/broadcom/phy-bcm-sr-usb.c index bfe8237..fe6c589 100644 --- a/drivers/phy/broadcom/phy-bcm-sr-usb.c +++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c @@ -328,7 +328,8 @@ static int bcm_usb_phy_create(struct device *dev, struct device_node *node, return PTR_ERR(phy_cfg->phy); phy_set_drvdata(phy_cfg->phy, phy_cfg); - } + } else + return -ENODEV; dev_set_drvdata(dev, phy_cfg); -- 2.7.4
Re: [PATCH v4 0/2] Add IPROC PCIe new features
Hi Lorenzo/Bjorn, Could you please help to review this patch series when you have time? I believe I have addressed all your review comments. Thanks, Srinath. On Fri, Mar 1, 2019 at 10:22 AM Srinath Mannam wrote: > > This patch set extends support of new IPROC PCIe host controller features > - Add CRS check using controller register status flags > - Add outbound window mapping configuration for 32-bit I/O region > > This patch set is based on Linux-5.0-rc2. > > Changes from v3: > - Addressed Lorenzo Pieralisi comments. > > Changes from v2: > - Based on Lorenzo Pieralisi comments, commit logs are expanded. > > Changes from v1: > - Addressed Bjorn Helgaas comments. > - Removed set order mode patch from patchset. > > Srinath Mannam (2): > PCI: iproc: Add CRS check in config read > PCI: iproc: Add outbound configuration for 32-bit I/O region > > drivers/pci/controller/pcie-iproc.c | 44 > + > 1 file changed, 40 insertions(+), 4 deletions(-) > > -- > 2.7.4 >
Re: [PATCH v6 0/3] Stingray USB PHY driver support
On Tue, Mar 26, 2019 at 1:00 PM Kishon Vijay Abraham I wrote: > > > > On 22/03/19 10:12 PM, Florian Fainelli wrote: > > On 3/19/19 11:38 AM, Scott Branden wrote: > >> Thanks Srinath and Rob - patch series looks good now. > >> > >> patch series, > >> > >> Acked-by: Scott Branden > >> > > > > Kishon, can you let me know when you apply patches 1 and 2 so I can > > queue up patch 3 for inclusion the 5.2 ARM SoC pull request? Thanks! > > merged the dt-binding and sr-usb driver, thanks. Thanks a lot Kishon. Regards, Srinath. > > -Kishon > > > >> > >> On 2019-03-19 2:15 a.m., Srinath Mannam wrote: > >>> These patches add Stingray USB PHY driver and its corresponding > >>> DT nodes with documentation. > >>> > >>> This patch set is based on Linux-5.0-rc2. > >>> > >>> Changes from v5: > >>>- Removed redundant address and size cells in DT nodes. > >>> > >>> Changes from v4: > >>>- Addressed Rob Herring review comments > >>> - Removed child nodes and added #phy-cells 1 > >>> - Added xlate function to get phy using phandle argument. > >>> > >>> Changes from v3: > >>>- Addressed Rob Herring review comments > >>> - Changed compatible strings. > >>> - updated driver based on new compatible strings. > >>> > >>> Changes from v2: > >>>- Addressed Kishon review comments > >>>- Updated patchset to Linux-5.0-rc2 > >>> > >>> Changes from v1: > >>>- Addressed Kishon review comments > >>>- phy init call return value handle > >>>Srinath Mannam (3): > >>>dt-bindings: phy: Add Stingray USB PHY binding document > >>>phy: sr-usb: Add Stingray USB PHY driver > >>>arm64: dts: Add USB DT nodes for Stingray SoC > >>> > >>> .../bindings/phy/brcm,stingray-usb-phy.txt | 32 ++ > >>> .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 72 > >>> .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + > >>> drivers/phy/broadcom/Kconfig | 11 + > >>> drivers/phy/broadcom/Makefile | 1 + > >>> drivers/phy/broadcom/phy-bcm-sr-usb.c | 393 > >>> + > >>> 6 files changed, 510 insertions(+) > >>> create mode 100644 > >>> Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt > >>> create mode 100644 > >>> arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi > >>> create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c > >>> > > > >
[PATCH v6 2/3] phy: sr-usb: Add Stingray USB PHY driver
USB PHY driver supports two types of stingray USB PHYs
- Type 1 is a combo PHY contains two PHYs, one SS and one HS.
- Type 2 is a single HS PHY.
These two PHY versons support both Generic xHCI host controller driver
and BDC Broadcom device controller driver.
Signed-off-by: Srinath Mannam
---
drivers/phy/broadcom/Kconfig | 11 +
drivers/phy/broadcom/Makefile | 1 +
drivers/phy/broadcom/phy-bcm-sr-usb.c | 393 ++
3 files changed, 405 insertions(+)
create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index aa917a6..f30f481 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -10,6 +10,17 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_BCM_SR_USB
+ tristate "Broadcom Stingray USB PHY driver"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Stingray USB PHY
+ driver. It supports all versions of Superspeed and
+ Highspeed PHYs.
+ If unsure, say N.
+
config BCM_KONA_USB2_PHY
tristate "Broadcom Kona USB2 PHY Driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/broadcom/Makefile b/drivers/phy/broadcom/Makefile
index 0f60184..f453c7d 100644
--- a/drivers/phy/broadcom/Makefile
+++ b/drivers/phy/broadcom/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PHY_BRCM_USB)+= phy-brcm-usb-dvr.o
phy-brcm-usb-dvr-objs := phy-brcm-usb.o phy-brcm-usb-init.o
obj-$(CONFIG_PHY_BCM_SR_PCIE) += phy-bcm-sr-pcie.o
+obj-$(CONFIG_PHY_BCM_SR_USB) += phy-bcm-sr-usb.o
diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c
b/drivers/phy/broadcom/phy-bcm-sr-usb.c
new file mode 100644
index 000..bfe8237
--- /dev/null
+++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c
@@ -0,0 +1,393 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum bcm_usb_phy_version {
+ BCM_SR_USB_COMBO_PHY,
+ BCM_SR_USB_HS_PHY,
+};
+
+enum bcm_usb_phy_reg {
+ PLL_NDIV_FRAC,
+ PLL_NDIV_INT,
+ PLL_CTRL,
+ PHY_CTRL,
+ PHY_PLL_CTRL,
+};
+
+/* USB PHY registers */
+
+static const u8 bcm_usb_combo_phy_ss[] = {
+ [PLL_CTRL] = 0x18,
+ [PHY_CTRL] = 0x14,
+};
+
+static const u8 bcm_usb_combo_phy_hs[] = {
+ [PLL_NDIV_FRAC] = 0x04,
+ [PLL_NDIV_INT] = 0x08,
+ [PLL_CTRL] = 0x0c,
+ [PHY_CTRL] = 0x10,
+};
+
+#define HSPLL_NDIV_INT_VAL 0x13
+#define HSPLL_NDIV_FRAC_VAL0x1005
+
+static const u8 bcm_usb_hs_phy[] = {
+ [PLL_NDIV_FRAC] = 0x0,
+ [PLL_NDIV_INT] = 0x4,
+ [PLL_CTRL] = 0x8,
+ [PHY_CTRL] = 0xc,
+};
+
+enum pll_ctrl_bits {
+ PLL_RESETB,
+ SSPLL_SUSPEND_EN,
+ PLL_SEQ_START,
+ PLL_LOCK,
+ PLL_PDIV,
+};
+
+static const u8 u3pll_ctrl[] = {
+ [PLL_RESETB]= 0,
+ [SSPLL_SUSPEND_EN] = 1,
+ [PLL_SEQ_START] = 2,
+ [PLL_LOCK] = 3,
+};
+
+#define HSPLL_PDIV_MASK0xF
+#define HSPLL_PDIV_VAL 0x1
+
+static const u8 u2pll_ctrl[] = {
+ [PLL_PDIV] = 1,
+ [PLL_RESETB]= 5,
+ [PLL_LOCK] = 6,
+};
+
+enum bcm_usb_phy_ctrl_bits {
+ CORERDY,
+ AFE_LDO_PWRDWNB,
+ AFE_PLL_PWRDWNB,
+ AFE_BG_PWRDWNB,
+ PHY_ISO,
+ PHY_RESETB,
+ PHY_PCTL,
+};
+
+#define PHY_PCTL_MASK 0x
+/*
+ * 0x0806 of PCTL_VAL has below bits set
+ * BIT-8 : refclk divider 1
+ * BIT-3:2: device mode; mode is not effect
+ * BIT-1: soft reset active low
+ */
+#define HSPHY_PCTL_VAL 0x0806
+#define SSPHY_PCTL_VAL 0x0006
+
+static const u8 u3phy_ctrl[] = {
+ [PHY_RESETB]= 1,
+ [PHY_PCTL] = 2,
+};
+
+static const u8 u2phy_ctrl[] = {
+ [CORERDY] = 0,
+ [AFE_LDO_PWRDWNB] = 1,
+ [AFE_PLL_PWRDWNB] = 2,
+ [AFE_BG_PWRDWNB]= 3,
+ [PHY_ISO] = 4,
+ [PHY_RESETB]= 5,
+ [PHY_PCTL] = 6,
+};
+
+struct bcm_usb_phy_cfg {
+ uint32_t type;
+ uint32_t version;
+ void __iomem *regs;
+ struct phy *phy;
+ const u8 *offset;
+};
+
+#define PLL_LOCK_RETRY_COUNT 1000
+
+enum bcm_usb_phy_type {
+ USB_HS_PHY,
+ USB_SS_PHY,
+};
+
+#define NUM_BCM_SR_USB_COMBO_PHYS 2
+
+static inline void bcm_usb_reg32_clrbits(void __iomem *addr, uint32_t clear)
+{
+ writel(readl(addr) & ~clear, addr);
+}
+
+static inline void bcm_usb_reg32_setbits(void __iomem *addr, uint32_t set)
+{
+ writel(readl(addr) | set, addr);
+}
+
+static int bcm_usb_pll_lock_check(void __iomem *add
[PATCH v6 3/3] arm64: dts: Add USB DT nodes for Stingray SoC
Add DT nodes for
- Two xHCI host controllers
- Two BDC Broadcom USB device controller
- Five USB PHY controllers
[xHCI0] [BDC0][xHCI1][BDC1]
| | | |
--- ---
| | | | |
[SS-PHY0] [HS-PHY0][SS-PHY1] [HS-PHY2] [HS-PHY1]
[SS-PHY0/HS-PHY0] and [SS-PHY1/HS-PHY1] are combo PHYs has one SS and
one HS PHYs. [HS-PHY2] is a single HS PHY.
xHCI use SS-PHY to detect SS devices and HS-PHY to detect HS/FS/LS
devices. BDC use SS-PHY in SS mode and HS-PHY in HS mode.
xHCI0 port1 is SS-PHY0, port2 is HS-PHY0.
xHCI1 port1 is SS-PHY1, port2 is HS-PHY2 and port3 is HS-PHY1.
Signed-off-by: Srinath Mannam
---
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 72 ++
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
2 files changed, 73 insertions(+)
create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
new file mode 100644
index 000..55259f9
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ *Copyright(c) 2018 Broadcom
+ */
+ usb {
+ compatible = "simple-bus";
+ dma-ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x6850 0x0040>;
+
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x 0x100>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+
+ xhci0: usb@1000 {
+ compatible = "generic-xhci";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ phys = < 1>, < 0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc0: usb@2000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x2000 0x1000>;
+ interrupts = ;
+ phys = < 0>, < 1>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x0001 0x100>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x0002 0x100>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ xhci1: usb@11000 {
+ compatible = "generic-xhci";
+ reg = <0x00011000 0x1000>;
+ interrupts = ;
+ phys = < 1>, <>, < 0>;
+ phy-names = "phy0", "phy1", "phy2";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc1: usb@21000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x00021000 0x1000>;
+ interrupts = ;
+ phys = <>;
+ phy-names = "phy0";
+ dma-coherent;
+ status = "disabled";
+ };
+ };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index cfeaa85..21dbb12 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -287,6 +287,7 @@
#include "stingray-fs4.dtsi"
#include "stingray-sata.dtsi"
#include "stingray-pcie.dtsi"
+ #include "stingray-usb.dtsi"
hsls {
compatible = "simple-bus";
--
2.7.4
[PATCH v6 0/3] Stingray USB PHY driver support
These patches add Stingray USB PHY driver and its corresponding DT nodes with documentation. This patch set is based on Linux-5.0-rc2. Changes from v5: - Removed redundant address and size cells in DT nodes. Changes from v4: - Addressed Rob Herring review comments - Removed child nodes and added #phy-cells 1 - Added xlate function to get phy using phandle argument. Changes from v3: - Addressed Rob Herring review comments - Changed compatible strings. - updated driver based on new compatible strings. Changes from v2: - Addressed Kishon review comments - Updated patchset to Linux-5.0-rc2 Changes from v1: - Addressed Kishon review comments - phy init call return value handle Srinath Mannam (3): dt-bindings: phy: Add Stingray USB PHY binding document phy: sr-usb: Add Stingray USB PHY driver arm64: dts: Add USB DT nodes for Stingray SoC .../bindings/phy/brcm,stingray-usb-phy.txt | 32 ++ .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 72 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + drivers/phy/broadcom/Kconfig | 11 + drivers/phy/broadcom/Makefile | 1 + drivers/phy/broadcom/phy-bcm-sr-usb.c | 393 + 6 files changed, 510 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c -- 2.7.4
[PATCH v6 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Add DT binding document for Stingray USB PHY.
Signed-off-by: Srinath Mannam
Reviewed-by: Rob Herring
---
.../bindings/phy/brcm,stingray-usb-phy.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
new file mode 100644
index 000..4ba2989
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
@@ -0,0 +1,32 @@
+Broadcom Stingray USB PHY
+
+Required properties:
+ - compatible : should be one of the listed compatibles
+ - "brcm,sr-usb-combo-phy" is combo PHY has two PHYs, one SS and one HS.
+ - "brcm,sr-usb-hs-phy" is a single HS PHY.
+ - reg: offset and length of the PHY blocks registers
+ - #phy-cells:
+ - Must be 1 for brcm,sr-usb-combo-phy as it expects one argument to indicate
+ the PHY number of two PHYs. 0 for HS PHY and 1 for SS PHY.
+ - Must be 0 for brcm,sr-usb-hs-phy.
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x 0x100>;
+ #phy-cells = <1>;
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x0001 0x100>,
+ #phy-cells = <1>;
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x0002 0x100>,
+ #phy-cells = <0>;
+ };
--
2.7.4
[PATCH v5 3/3] arm64: dts: Add USB DT nodes for Stingray SoC
Add DT nodes for
- Two xHCI host controllers
- Two BDC Broadcom USB device controller
- Five USB PHY controllers
[xHCI0] [BDC0][xHCI1][BDC1]
| | | |
--- ---
| | | | |
[SS-PHY0] [HS-PHY0][SS-PHY1] [HS-PHY2] [HS-PHY1]
[SS-PHY0/HS-PHY0] and [SS-PHY1/HS-PHY1] are combo PHYs has one SS and
one HS PHYs. [HS-PHY2] is a single HS PHY.
xHCI use SS-PHY to detect SS devices and HS-PHY to detect HS/FS/LS
devices. BDC use SS-PHY in SS mode and HS-PHY in HS mode.
xHCI0 port1 is SS-PHY0, port2 is HS-PHY0.
xHCI1 port1 is SS-PHY1, port2 is HS-PHY2 and port3 is HS-PHY1.
Signed-off-by: Srinath Mannam
---
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 78 ++
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
2 files changed, 79 insertions(+)
create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
new file mode 100644
index 000..a5d3354
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ *Copyright(c) 2018 Broadcom
+ */
+ usb {
+ compatible = "simple-bus";
+ dma-ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x6850 0x0040>;
+
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+
+ xhci0: usb@1000 {
+ compatible = "generic-xhci";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ phys = < 1>, < 0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc0: usb@2000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x2000 0x1000>;
+ interrupts = ;
+ phys = < 0>, < 1>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x0001 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x0002 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ xhci1: usb@11000 {
+ compatible = "generic-xhci";
+ reg = <0x00011000 0x1000>;
+ interrupts = ;
+ phys = < 1>, <>, < 0>;
+ phy-names = "phy0", "phy1", "phy2";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc1: usb@21000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x00021000 0x1000>;
+ interrupts = ;
+ phys = <>;
+ phy-names = "phy0";
+ dma-coherent;
+ status = "disabled";
+ };
+ };
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
index cfeaa85..21dbb12 100644
--- a/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray.dtsi
@@ -287,6 +287,7 @@
#include "stingray-fs4.dtsi"
#include "stingray-sata.dtsi"
#include "stingray-pcie.dtsi"
+ #include "stingray-usb.dtsi"
hsls {
compatible = "simple-bus";
--
2.7.4
[PATCH v5 2/3] phy: sr-usb: Add Stingray USB PHY driver
USB PHY driver supports two types of stingray USB PHYs
- Type 1 is a combo PHY contains two PHYs, one SS and one HS.
- Type 2 is a single HS PHY.
These two PHY versons support both Generic xHCI host controller driver
and BDC Broadcom device controller driver.
Signed-off-by: Srinath Mannam
---
drivers/phy/broadcom/Kconfig | 11 +
drivers/phy/broadcom/Makefile | 1 +
drivers/phy/broadcom/phy-bcm-sr-usb.c | 393 ++
3 files changed, 405 insertions(+)
create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index aa917a6..f30f481 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -10,6 +10,17 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_BCM_SR_USB
+ tristate "Broadcom Stingray USB PHY driver"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Stingray USB PHY
+ driver. It supports all versions of Superspeed and
+ Highspeed PHYs.
+ If unsure, say N.
+
config BCM_KONA_USB2_PHY
tristate "Broadcom Kona USB2 PHY Driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/broadcom/Makefile b/drivers/phy/broadcom/Makefile
index 0f60184..f453c7d 100644
--- a/drivers/phy/broadcom/Makefile
+++ b/drivers/phy/broadcom/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PHY_BRCM_USB)+= phy-brcm-usb-dvr.o
phy-brcm-usb-dvr-objs := phy-brcm-usb.o phy-brcm-usb-init.o
obj-$(CONFIG_PHY_BCM_SR_PCIE) += phy-bcm-sr-pcie.o
+obj-$(CONFIG_PHY_BCM_SR_USB) += phy-bcm-sr-usb.o
diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c
b/drivers/phy/broadcom/phy-bcm-sr-usb.c
new file mode 100644
index 000..bfe8237
--- /dev/null
+++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c
@@ -0,0 +1,393 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum bcm_usb_phy_version {
+ BCM_SR_USB_COMBO_PHY,
+ BCM_SR_USB_HS_PHY,
+};
+
+enum bcm_usb_phy_reg {
+ PLL_NDIV_FRAC,
+ PLL_NDIV_INT,
+ PLL_CTRL,
+ PHY_CTRL,
+ PHY_PLL_CTRL,
+};
+
+/* USB PHY registers */
+
+static const u8 bcm_usb_combo_phy_ss[] = {
+ [PLL_CTRL] = 0x18,
+ [PHY_CTRL] = 0x14,
+};
+
+static const u8 bcm_usb_combo_phy_hs[] = {
+ [PLL_NDIV_FRAC] = 0x04,
+ [PLL_NDIV_INT] = 0x08,
+ [PLL_CTRL] = 0x0c,
+ [PHY_CTRL] = 0x10,
+};
+
+#define HSPLL_NDIV_INT_VAL 0x13
+#define HSPLL_NDIV_FRAC_VAL0x1005
+
+static const u8 bcm_usb_hs_phy[] = {
+ [PLL_NDIV_FRAC] = 0x0,
+ [PLL_NDIV_INT] = 0x4,
+ [PLL_CTRL] = 0x8,
+ [PHY_CTRL] = 0xc,
+};
+
+enum pll_ctrl_bits {
+ PLL_RESETB,
+ SSPLL_SUSPEND_EN,
+ PLL_SEQ_START,
+ PLL_LOCK,
+ PLL_PDIV,
+};
+
+static const u8 u3pll_ctrl[] = {
+ [PLL_RESETB]= 0,
+ [SSPLL_SUSPEND_EN] = 1,
+ [PLL_SEQ_START] = 2,
+ [PLL_LOCK] = 3,
+};
+
+#define HSPLL_PDIV_MASK0xF
+#define HSPLL_PDIV_VAL 0x1
+
+static const u8 u2pll_ctrl[] = {
+ [PLL_PDIV] = 1,
+ [PLL_RESETB]= 5,
+ [PLL_LOCK] = 6,
+};
+
+enum bcm_usb_phy_ctrl_bits {
+ CORERDY,
+ AFE_LDO_PWRDWNB,
+ AFE_PLL_PWRDWNB,
+ AFE_BG_PWRDWNB,
+ PHY_ISO,
+ PHY_RESETB,
+ PHY_PCTL,
+};
+
+#define PHY_PCTL_MASK 0x
+/*
+ * 0x0806 of PCTL_VAL has below bits set
+ * BIT-8 : refclk divider 1
+ * BIT-3:2: device mode; mode is not effect
+ * BIT-1: soft reset active low
+ */
+#define HSPHY_PCTL_VAL 0x0806
+#define SSPHY_PCTL_VAL 0x0006
+
+static const u8 u3phy_ctrl[] = {
+ [PHY_RESETB]= 1,
+ [PHY_PCTL] = 2,
+};
+
+static const u8 u2phy_ctrl[] = {
+ [CORERDY] = 0,
+ [AFE_LDO_PWRDWNB] = 1,
+ [AFE_PLL_PWRDWNB] = 2,
+ [AFE_BG_PWRDWNB]= 3,
+ [PHY_ISO] = 4,
+ [PHY_RESETB]= 5,
+ [PHY_PCTL] = 6,
+};
+
+struct bcm_usb_phy_cfg {
+ uint32_t type;
+ uint32_t version;
+ void __iomem *regs;
+ struct phy *phy;
+ const u8 *offset;
+};
+
+#define PLL_LOCK_RETRY_COUNT 1000
+
+enum bcm_usb_phy_type {
+ USB_HS_PHY,
+ USB_SS_PHY,
+};
+
+#define NUM_BCM_SR_USB_COMBO_PHYS 2
+
+static inline void bcm_usb_reg32_clrbits(void __iomem *addr, uint32_t clear)
+{
+ writel(readl(addr) & ~clear, addr);
+}
+
+static inline void bcm_usb_reg32_setbits(void __iomem *addr, uint32_t set)
+{
+ writel(readl(addr) | set, addr);
+}
+
+static int bcm_usb_pll_lock_check(void __iomem *add
[PATCH v5 0/3] Stingray USB PHY driver support
These patches add Stingray USB PHY driver and its corresponding DT nodes with documentation. This patch set is based on Linux-5.0-rc2. Changes from v4: - Addressed Rob Herring review comments - Removed child nodes and added #phy-cells 1 - Added xlate function to get phy using phandle argument. Changes from v3: - Addressed Rob Herring review comments - Changed compatible strings. - updated driver based on new compatible strings. Changes from v2: - Addressed Kishon review comments - Updated patchset to Linux-5.0-rc2 Changes from v1: - Addressed Kishon review comments - phy init call return value handle Srinath Mannam (3): dt-bindings: phy: Add Stingray USB PHY binding document phy: sr-usb: Add Stingray USB PHY driver arm64: dts: Add USB DT nodes for Stingray SoC .../bindings/phy/brcm,stingray-usb-phy.txt | 40 +++ .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 78 .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + drivers/phy/broadcom/Kconfig | 11 + drivers/phy/broadcom/Makefile | 1 + drivers/phy/broadcom/phy-bcm-sr-usb.c | 393 + 6 files changed, 524 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c -- 2.7.4
[PATCH v5 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Add DT binding document for Stingray USB PHY.
Signed-off-by: Srinath Mannam
---
.../bindings/phy/brcm,stingray-usb-phy.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
new file mode 100644
index 000..51c3d73
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
@@ -0,0 +1,40 @@
+Broadcom Stingray USB PHY
+
+Required properties:
+ - compatible : should be one of the listed compatibles
+ - "brcm,sr-usb-combo-phy" is combo PHY has two PHYs, one SS and one HS.
+ - "brcm,sr-usb-hs-phy" is a single HS PHY.
+ - reg: offset and length of the PHY blocks registers
+ - address-cells: should be 1
+ - size-cells: should be 0
+ - #phy-cells:
+ - Must be 1 for brcm,sr-usb-combo-phy as it expects one argument to indicate
+ the PHY number of two PHYs. 0 for HS PHY and 1 for SS PHY.
+ - Must be 0 for brcm,sr-usb-hs-phy.
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x0001 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <1>;
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x0002 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ };
--
2.7.4
Re: [PATCH v4 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Hi Rob,
Thank you, I will send next patch set with the changes as you suggested.
Regards,
Srinath.
On Tue, Mar 12, 2019 at 3:00 AM Rob Herring wrote:
>
> On Sun, Mar 10, 2019 at 10:32 PM Srinath Mannam
> wrote:
> >
> > Hi Rob,
> >
> > Please find my comments below,
> >
> > On Sat, Feb 23, 2019 at 1:05 AM Rob Herring wrote:
> > >
> > > On Fri, Feb 22, 2019 at 11:29 AM Srinath Mannam
> > > wrote:
> > > >
> > > > Hi Rob,
> > > >
> > > > Thanks for the review, Please find my comments below in line.
> > > >
> > > > On Fri, Feb 22, 2019 at 10:50 PM Rob Herring wrote:
> > > > >
> > > > > On Wed, Feb 20, 2019 at 04:04:00PM +0530, Srinath Mannam wrote:
> > > > > > Add DT binding document for Stingray USB PHY.
> > > > > >
> > > > > > Signed-off-by: Srinath Mannam
> > > > > > Reviewed-by: Florian Fainelli
> > > > > > Reviewed-by: Scott Branden
> > > > > > ---
> > > > > > .../bindings/phy/brcm,stingray-usb-phy.txt | 62
> > > > > > ++
> > > > > > 1 file changed, 62 insertions(+)
> > > > > > create mode 100644
> > > > > > Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > > > > > b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > > > > > new file mode 100644
> > > > > > index 000..da19236
> > > > > > --- /dev/null
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > > > > > @@ -0,0 +1,62 @@
> > > > > > +Broadcom Stingray USB PHY
> > > > > > +
> > > > > > +Required properties:
> > > > > > + - compatible : should be one of the listed compatibles
> > > > > > + - "brcm,sr-usb-combo-phy" is a combo PHY has one SS PHY and
> > > > > > one HS PHY.
> > > > > > + - "brcm,sr-usb-hs-phy" has a single HS PHY.
> > > > > > + - reg: offset and length of the PHY blocks registers
> > > > > > + - address-cells: should be 1
> > > > > > + - size-cells: should be 0
> > > > > > +
> > > > > > +Sub-nodes:
> > > > > > + brcm,sr-usb-combo-phy have two sub-nodes for one SS PHY and one
> > > > > > HS PHY.
> > > > > > +
> > > > > > +Sub-nodes required properties:
> > > > > > + - reg: required for brcm,sr-usb-phy model PHY.
> > > > > > + reg value 0 is HS PHY and 1 is SS PHY.
> > > > > > + - phy-cells: generic PHY binding; must be 0
> > > > > > +
> > > > > > +Refer to phy/phy-bindings.txt for the generic PHY binding
> > > > > > properties
> > > > > > +
> > > > > > +Example:
> > > > > > + usbphy0: usb-phy@0 {
> > > > > > + compatible = "brcm,sr-usb-combo-phy";
> > > > > > + reg = <0x 0x100>;
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + usb0_phy0: phy@0 {
> > > > > > + reg = <0>;
> > > > > > + #phy-cells = <0>;
> > > > > > + };
> > > > > > +
> > > > > > + usb0_phy1: phy@1 {
> > > > > > + reg = <1>;
> > > > > > + #phy-cells = <0>;
> > > > > > + };
> > > > >
> > > > > Again, you don't need child nodes here. There are not any per child
> > > > > resources. Clients can refer to < 1> just as easily as
> > > > > <_phy1>. This is why we have #phy-cells.
> > > > This phy controller is combo PHY it has one Super Speed USB PHY and
> > > > one High Speed USB PHY.
> > > > We required to create two PHY devices inside driver to initialize and
> > > > service(reset) both SS and HS PHYs separately.
> > > > That is the reason we used two child nodes.
> > >
> > > What you do in the driver is your business. That is independent of the
> > > binding. Go look at other phy drivers which use #phy-cells=1.
> > > .of_xlate() function is what converts the phy cells to a struct phy.
> > >
> > I have followed exactly same pattern available in open source.
> > ex: Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
> > In this also, two child nodes are used with #phy-cells 0.
>
> You'll notice DT maintainers did not review that binding (only changes
> to it). There's no shortage of DT examples of how not to do things.
>
> Rob
Re: [PATCH v4 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Hi Rob,
Please find my comments below,
On Sat, Feb 23, 2019 at 1:05 AM Rob Herring wrote:
>
> On Fri, Feb 22, 2019 at 11:29 AM Srinath Mannam
> wrote:
> >
> > Hi Rob,
> >
> > Thanks for the review, Please find my comments below in line.
> >
> > On Fri, Feb 22, 2019 at 10:50 PM Rob Herring wrote:
> > >
> > > On Wed, Feb 20, 2019 at 04:04:00PM +0530, Srinath Mannam wrote:
> > > > Add DT binding document for Stingray USB PHY.
> > > >
> > > > Signed-off-by: Srinath Mannam
> > > > Reviewed-by: Florian Fainelli
> > > > Reviewed-by: Scott Branden
> > > > ---
> > > > .../bindings/phy/brcm,stingray-usb-phy.txt | 62
> > > > ++
> > > > 1 file changed, 62 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > > > b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > > > new file mode 100644
> > > > index 000..da19236
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > > > @@ -0,0 +1,62 @@
> > > > +Broadcom Stingray USB PHY
> > > > +
> > > > +Required properties:
> > > > + - compatible : should be one of the listed compatibles
> > > > + - "brcm,sr-usb-combo-phy" is a combo PHY has one SS PHY and one
> > > > HS PHY.
> > > > + - "brcm,sr-usb-hs-phy" has a single HS PHY.
> > > > + - reg: offset and length of the PHY blocks registers
> > > > + - address-cells: should be 1
> > > > + - size-cells: should be 0
> > > > +
> > > > +Sub-nodes:
> > > > + brcm,sr-usb-combo-phy have two sub-nodes for one SS PHY and one HS
> > > > PHY.
> > > > +
> > > > +Sub-nodes required properties:
> > > > + - reg: required for brcm,sr-usb-phy model PHY.
> > > > + reg value 0 is HS PHY and 1 is SS PHY.
> > > > + - phy-cells: generic PHY binding; must be 0
> > > > +
> > > > +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> > > > +
> > > > +Example:
> > > > + usbphy0: usb-phy@0 {
> > > > + compatible = "brcm,sr-usb-combo-phy";
> > > > + reg = <0x 0x100>;
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + usb0_phy0: phy@0 {
> > > > + reg = <0>;
> > > > + #phy-cells = <0>;
> > > > + };
> > > > +
> > > > + usb0_phy1: phy@1 {
> > > > + reg = <1>;
> > > > + #phy-cells = <0>;
> > > > + };
> > >
> > > Again, you don't need child nodes here. There are not any per child
> > > resources. Clients can refer to < 1> just as easily as
> > > <_phy1>. This is why we have #phy-cells.
> > This phy controller is combo PHY it has one Super Speed USB PHY and
> > one High Speed USB PHY.
> > We required to create two PHY devices inside driver to initialize and
> > service(reset) both SS and HS PHYs separately.
> > That is the reason we used two child nodes.
>
> What you do in the driver is your business. That is independent of the
> binding. Go look at other phy drivers which use #phy-cells=1.
> .of_xlate() function is what converts the phy cells to a struct phy.
>
I have followed exactly same pattern available in open source.
ex: Documentation/devicetree/bindings/phy/brcm-sata-phy.txt
In this also, two child nodes are used with #phy-cells 0.
> Rob
[PATCH v4 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
In the present driver outbound window configuration is done to map above
32-bit address I/O regions with corresponding PCI memory range given in
ranges DT property.
This patch add outbound window configuration to map below 32-bit I/O range
with corresponding PCI memory, which helps to access I/O region in ARM
32-bit and one to one mapping of I/O region to PCI memory.
Ex:
1. ranges DT property given for current driver is,
ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>;
I/O region address is 0x4
2. ranges DT property can be given after this patch,
ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>;
I/O region address is 0x4200
Signed-off-by: Srinath Mannam
Signed-off-by: Abhishek Shah
Signed-off-by: Ray Jui
---
drivers/pci/controller/pcie-iproc.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index b882255..080f142 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie *pcie,
u64 axi_addr,
resource_size_t window_size =
ob_map->window_sizes[size_idx] * SZ_1M;
- if (size < window_size)
- continue;
+ /*
+* Keep iterating until we reach the last window and
+* with the minimal window size at index zero. In this
+* case, we take a compromise by mapping it using the
+* minimum window size that can be supported
+*/
+ if (size < window_size) {
+ if (size_idx > 0 || window_idx > 0)
+ continue;
+
+ /*
+* For the corner case of reaching the minimal
+* window size that can be supported on the
+* last window
+*/
+ axi_addr = ALIGN_DOWN(axi_addr, window_size);
+ pci_addr = ALIGN_DOWN(pci_addr, window_size);
+ size = window_size;
+ }
if (!IS_ALIGNED(axi_addr, window_size) ||
!IS_ALIGNED(pci_addr, window_size)) {
--
2.7.4
[PATCH v4 0/2] Add IPROC PCIe new features
This patch set extends support of new IPROC PCIe host controller features - Add CRS check using controller register status flags - Add outbound window mapping configuration for 32-bit I/O region This patch set is based on Linux-5.0-rc2. Changes from v3: - Addressed Lorenzo Pieralisi comments. Changes from v2: - Based on Lorenzo Pieralisi comments, commit logs are expanded. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed set order mode patch from patchset. Srinath Mannam (2): PCI: iproc: Add CRS check in config read PCI: iproc: Add outbound configuration for 32-bit I/O region drivers/pci/controller/pcie-iproc.c | 44 + 1 file changed, 40 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH v4 1/2] PCI: iproc: Add CRS check in config read
In the current implementation, config read output data 0x0001 is
assumed as CRS completion. But sometimes 0x0001 can be a valid data.
IPROC PCIe host controller PAXB v2 has a register to show config read
status flags like SC, UR, CRS and CA. So that extra check is added to
confirm the CRS using status flags before reissue config read.
Signed-off-by: Srinath Mannam
---
drivers/pci/controller/pcie-iproc.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index c20fd6b..b882255 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -60,6 +60,10 @@
#define APB_ERR_EN_SHIFT 0
#define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
+#define CFG_RD_SUCCESS 0
+#define CFG_RD_UR 1
+#define CFG_RD_CRS 2
+#define CFG_RD_CA 3
#define CFG_RETRY_STATUS 0x0001
#define CFG_RETRY_STATUS_TIMEOUT_US50 /* 500 milliseconds */
@@ -289,6 +293,9 @@ enum iproc_pcie_reg {
IPROC_PCIE_IARR4,
IPROC_PCIE_IMAP4,
+ /* config read status */
+ IPROC_PCIE_CFG_RD_STATUS,
+
/* link status */
IPROC_PCIE_LINK_STATUS,
@@ -350,6 +357,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_IMAP3] = 0xe08,
[IPROC_PCIE_IARR4] = 0xe68,
[IPROC_PCIE_IMAP4] = 0xe70,
+ [IPROC_PCIE_CFG_RD_STATUS] = 0xee0,
[IPROC_PCIE_LINK_STATUS]= 0xf0c,
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
};
@@ -474,10 +482,12 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct
iproc_pcie *pcie,
return (pcie->base + offset);
}
-static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
+void __iomem *cfg_data_p)
{
int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
unsigned int data;
+ u32 status;
/*
* As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
@@ -498,6 +508,15 @@ static unsigned int iproc_pcie_cfg_retry(void __iomem
*cfg_data_p)
*/
data = readl(cfg_data_p);
while (data == CFG_RETRY_STATUS && timeout--) {
+ /*
+* CRS state is set in CFG_RD status register
+* This will handle the case where CFG_RETRY_STATUS is
+* valid config data.
+*/
+ status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
+ if (status != CFG_RD_CRS)
+ return data;
+
udelay(1);
data = readl(cfg_data_p);
}
@@ -576,7 +595,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus,
unsigned int devfn,
if (!cfg_data_p)
return PCIBIOS_DEVICE_NOT_FOUND;
- data = iproc_pcie_cfg_retry(cfg_data_p);
+ data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
*val = data;
if (size <= 2)
--
2.7.4
Re: [PATCH v3 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
Hi Lorenzo,
Thanks for the review.. Please see my comments below in line..
Regards,
Srinath.
On Thu, Feb 28, 2019 at 9:43 PM Lorenzo Pieralisi
wrote:
>
> On Wed, Feb 20, 2019 at 10:03:55PM +0530, Srinath Mannam wrote:
> > In the present driver outbound window configuration is done to map above
> > 32-bit address I/O regions with corresponding PCI memory range given in
> > ranges DT property.
> >
> > This patch add outbound window configuration to map below 32-bit I/O range
> > with corresponding PCI memory, which helps to access I/O region in IA32
>
> I think you mean ARM 32-bit here, not IA32.
Yes ARM 32 bit.. Thank you.
>
> > and one to one mapping of I/O region to PCI memory.
> >
> > Ex:
> > 1. ranges DT property given for current driver is,
> > ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>;
> > I/O region address is 0x4
> > 2. ranges DT property can be given after this patch,
> > ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>;
> > I/O region address is 0x4200
> >
> > Signed-off-by: Srinath Mannam
> > Signed-off-by: Abhishek Shah
> > Signed-off-by: Ray Jui
> > Reviewed-by: Scott Branden
> > Reviewed-by: Vikram Prakash
>
> I asked you before, please point me at mailing list discussions where
> these review tags were given, v1 was already carrying them but that's
> not how the process works, they have to be given on mailing lists.
Sorry I missed your comment. These tags are our internal review list.
Many Thanks for sharing knowledge.
I will follow the process from next time onward. I will modify and
send next patch set.
>
> Lorenzo
>
> > ---
> > drivers/pci/controller/pcie-iproc.c | 21 +++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c
> > b/drivers/pci/controller/pcie-iproc.c
> > index b882255..080f142 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie
> > *pcie, u64 axi_addr,
> > resource_size_t window_size =
> > ob_map->window_sizes[size_idx] * SZ_1M;
> >
> > - if (size < window_size)
> > - continue;
> > + /*
> > + * Keep iterating until we reach the last window and
> > + * with the minimal window size at index zero. In this
> > + * case, we take a compromise by mapping it using the
> > + * minimum window size that can be supported
> > + */
> > + if (size < window_size) {
> > + if (size_idx > 0 || window_idx > 0)
> > + continue;
> > +
> > + /*
> > + * For the corner case of reaching the minimal
> > + * window size that can be supported on the
> > + * last window
> > + */
> > + axi_addr = ALIGN_DOWN(axi_addr, window_size);
> > + pci_addr = ALIGN_DOWN(pci_addr, window_size);
> > + size = window_size;
> > + }
> >
> > if (!IS_ALIGNED(axi_addr, window_size) ||
> > !IS_ALIGNED(pci_addr, window_size)) {
> > --
> > 2.7.4
> >
Re: [PATCH 1/2] dt-bindings: usb-xhci: Add usb-phy-port-reset property
Hi Rob, Thanks for the information. Please find my comments below. Regards, Srinath. On Tue, Feb 26, 2019 at 11:33 PM Rob Herring wrote: > > On Mon, Feb 25, 2019 at 10:57 PM Srinath Mannam > wrote: > > > > Hi Rob, > > Thanks for the review, Please see my comments below in line. > > > > Regards, > > Srinath. > > On Tue, Feb 26, 2019 at 3:08 AM Rob Herring wrote: > > > > > > On Tue, Feb 05, 2019 at 11:48:53AM +0530, Srinath Mannam wrote: > > > > Add usb-phy-port-reset optional property to set quirk in xhci platform > > > > driver which forces USB port PHY reset on port disconnect event. > > > > > > > > Signed-off-by: Srinath Mannam > > > > Reviewed-by: Ray Jui > > > > --- > > > > Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt > > > > b/Documentation/devicetree/bindings/usb/usb-xhci.txt > > > > index fea8b15..ecbdb15 100644 > > > > --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt > > > > +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt > > > > @@ -40,6 +40,7 @@ Optional properties: > > > >- usb3-lpm-capable: determines if platform is USB3 LPM capable > > > >- quirk-broken-port-ped: set if the controller has broken port > > > > disable mechanism > > > >- imod-interval-ns: default interrupt moderation interval is 5000ns > > > > + - usb-phy-port-reset: set this to do USB PORT PHY reset while > > > > disconnect > > > >- phys : see usb-hcd.txt in the current directory > > > > > > This should be implied by the HCI or phy compatible string (depending > > > on who exactly needs the quirky behavior). > > Stingray USB HS PHY connected to xHCI port has an issue, if full speed > > devices connected to this port then > > after all High Speed devices connected to this port are detected at > > full speed instead of high speed. > > So that we need to do PHY (which is connected to port) reset on xHCI > > port disconnect event. > > That is the reason we required to add quirk in xHCI. > > So, by looking at the xhci host and phy compatible strings (or maybe > just the phy) you can determine whether you need to reset the port or > not. All the information you need is in DT already. xHCI controller in our SOC has three ports each port has one PHY(SS/HS) connected to it. HS PHY has to reset on its corresponding port disconnect event. port disconnect event is captured in xHCI host framework so, quirk has to be registered in xHCI framework only. But we are using "generic-xhci" generic compatible string for our xHCI controller. As per your advice, we will add new compatible string in xhci-plat.c driver for our xHCI controller and will add quirk part of that. Thank you. > > Rob
Re: [PATCH 1/2] dt-bindings: usb-xhci: Add usb-phy-port-reset property
Hi Rob, Thanks for the review, Please see my comments below in line. Regards, Srinath. On Tue, Feb 26, 2019 at 3:08 AM Rob Herring wrote: > > On Tue, Feb 05, 2019 at 11:48:53AM +0530, Srinath Mannam wrote: > > Add usb-phy-port-reset optional property to set quirk in xhci platform > > driver which forces USB port PHY reset on port disconnect event. > > > > Signed-off-by: Srinath Mannam > > Reviewed-by: Ray Jui > > --- > > Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt > > b/Documentation/devicetree/bindings/usb/usb-xhci.txt > > index fea8b15..ecbdb15 100644 > > --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt > > +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt > > @@ -40,6 +40,7 @@ Optional properties: > >- usb3-lpm-capable: determines if platform is USB3 LPM capable > >- quirk-broken-port-ped: set if the controller has broken port disable > > mechanism > >- imod-interval-ns: default interrupt moderation interval is 5000ns > > + - usb-phy-port-reset: set this to do USB PORT PHY reset while disconnect > >- phys : see usb-hcd.txt in the current directory > > This should be implied by the HCI or phy compatible string (depending > on who exactly needs the quirky behavior). Stingray USB HS PHY connected to xHCI port has an issue, if full speed devices connected to this port then after all High Speed devices connected to this port are detected at full speed instead of high speed. So that we need to do PHY (which is connected to port) reset on xHCI port disconnect event. That is the reason we required to add quirk in xHCI. > > Rob
Re: [PATCH v4 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Hi Rob,
Thanks for the review, Please find my comments below in line.
On Fri, Feb 22, 2019 at 10:50 PM Rob Herring wrote:
>
> On Wed, Feb 20, 2019 at 04:04:00PM +0530, Srinath Mannam wrote:
> > Add DT binding document for Stingray USB PHY.
> >
> > Signed-off-by: Srinath Mannam
> > Reviewed-by: Florian Fainelli
> > Reviewed-by: Scott Branden
> > ---
> > .../bindings/phy/brcm,stingray-usb-phy.txt | 62
> > ++
> > 1 file changed, 62 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > new file mode 100644
> > index 000..da19236
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > @@ -0,0 +1,62 @@
> > +Broadcom Stingray USB PHY
> > +
> > +Required properties:
> > + - compatible : should be one of the listed compatibles
> > + - "brcm,sr-usb-combo-phy" is a combo PHY has one SS PHY and one HS
> > PHY.
> > + - "brcm,sr-usb-hs-phy" has a single HS PHY.
> > + - reg: offset and length of the PHY blocks registers
> > + - address-cells: should be 1
> > + - size-cells: should be 0
> > +
> > +Sub-nodes:
> > + brcm,sr-usb-combo-phy have two sub-nodes for one SS PHY and one HS PHY.
> > +
> > +Sub-nodes required properties:
> > + - reg: required for brcm,sr-usb-phy model PHY.
> > + reg value 0 is HS PHY and 1 is SS PHY.
> > + - phy-cells: generic PHY binding; must be 0
> > +
> > +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> > +
> > +Example:
> > + usbphy0: usb-phy@0 {
> > + compatible = "brcm,sr-usb-combo-phy";
> > + reg = <0x 0x100>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + usb0_phy0: phy@0 {
> > + reg = <0>;
> > + #phy-cells = <0>;
> > + };
> > +
> > + usb0_phy1: phy@1 {
> > + reg = <1>;
> > + #phy-cells = <0>;
> > + };
>
> Again, you don't need child nodes here. There are not any per child
> resources. Clients can refer to < 1> just as easily as
> <_phy1>. This is why we have #phy-cells.
This phy controller is combo PHY it has one Super Speed USB PHY and
one High Speed USB PHY.
We required to create two PHY devices inside driver to initialize and
service(reset) both SS and HS PHYs separately.
That is the reason we used two child nodes.
Regards,
Srinath.
>
> Rob
Re: [PATCH v3 0/3] PCIe Host request to reserve IOVA
Hi Bjorn, Please help to review this patch series. Thank you. Regards, Srinath. On Fri, Jan 25, 2019 at 3:44 PM Srinath Mannam wrote: > > Few SOCs have limitation that their PCIe host can't allow few inbound > address ranges. Allowed inbound address ranges are listed in dma-ranges > DT property and this address ranges are required to do IOVA mapping. > Remaining address ranges have to be reserved in IOVA mapping. > > PCIe Host driver of those SOCs has to list all address ranges which have > to reserve their IOVA address into PCIe host bridge resource entry list. > IOMMU framework will reserve these IOVAs while initializing IOMMU domain. > > This patch set is based on Linux-5.0-rc2. > > Changes from v2: > - Patch set rebased to Linux-5.0-rc2 > > Changes from v1: > - Addressed Oza review comments. > > Srinath Mannam (3): > PCI: Add dma-resv window list > iommu/dma: Reserve IOVA for PCI host reserve address list > PCI: iproc: Add dma reserve resources to host > > drivers/iommu/dma-iommu.c | 8 ++ > drivers/pci/controller/pcie-iproc.c | 51 > - > drivers/pci/probe.c | 3 +++ > include/linux/pci.h | 1 + > 4 files changed, 62 insertions(+), 1 deletion(-) > > -- > 2.7.4 >
[PATCH v3 2/2] PCI: iproc: Add outbound configuration for 32-bit I/O region
In the present driver outbound window configuration is done to map above
32-bit address I/O regions with corresponding PCI memory range given in
ranges DT property.
This patch add outbound window configuration to map below 32-bit I/O range
with corresponding PCI memory, which helps to access I/O region in IA32
and one to one mapping of I/O region to PCI memory.
Ex:
1. ranges DT property given for current driver is,
ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>;
I/O region address is 0x4
2. ranges DT property can be given after this patch,
ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>;
I/O region address is 0x4200
Signed-off-by: Srinath Mannam
Signed-off-by: Abhishek Shah
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Vikram Prakash
---
drivers/pci/controller/pcie-iproc.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index b882255..080f142 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie *pcie,
u64 axi_addr,
resource_size_t window_size =
ob_map->window_sizes[size_idx] * SZ_1M;
- if (size < window_size)
- continue;
+ /*
+* Keep iterating until we reach the last window and
+* with the minimal window size at index zero. In this
+* case, we take a compromise by mapping it using the
+* minimum window size that can be supported
+*/
+ if (size < window_size) {
+ if (size_idx > 0 || window_idx > 0)
+ continue;
+
+ /*
+* For the corner case of reaching the minimal
+* window size that can be supported on the
+* last window
+*/
+ axi_addr = ALIGN_DOWN(axi_addr, window_size);
+ pci_addr = ALIGN_DOWN(pci_addr, window_size);
+ size = window_size;
+ }
if (!IS_ALIGNED(axi_addr, window_size) ||
!IS_ALIGNED(pci_addr, window_size)) {
--
2.7.4
[PATCH v3 1/2] PCI: iproc: Add CRS check in config read
In the current implementation, config read output data 0x0001 is
assumed as CRS completion. But sometimes 0x0001 can be a valid data.
IPROC PCIe host controller PAXB v2 has a register to show config read
status flags like SC, UR, CRS and CA. So that extra check is added to
confirm the CRS using status flags before reissue config read.
Signed-off-by: Srinath Mannam
Reviewed-by: Ray Jui
---
drivers/pci/controller/pcie-iproc.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index c20fd6b..b882255 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -60,6 +60,10 @@
#define APB_ERR_EN_SHIFT 0
#define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
+#define CFG_RD_SUCCESS 0
+#define CFG_RD_UR 1
+#define CFG_RD_CRS 2
+#define CFG_RD_CA 3
#define CFG_RETRY_STATUS 0x0001
#define CFG_RETRY_STATUS_TIMEOUT_US50 /* 500 milliseconds */
@@ -289,6 +293,9 @@ enum iproc_pcie_reg {
IPROC_PCIE_IARR4,
IPROC_PCIE_IMAP4,
+ /* config read status */
+ IPROC_PCIE_CFG_RD_STATUS,
+
/* link status */
IPROC_PCIE_LINK_STATUS,
@@ -350,6 +357,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_IMAP3] = 0xe08,
[IPROC_PCIE_IARR4] = 0xe68,
[IPROC_PCIE_IMAP4] = 0xe70,
+ [IPROC_PCIE_CFG_RD_STATUS] = 0xee0,
[IPROC_PCIE_LINK_STATUS]= 0xf0c,
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
};
@@ -474,10 +482,12 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct
iproc_pcie *pcie,
return (pcie->base + offset);
}
-static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
+void __iomem *cfg_data_p)
{
int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
unsigned int data;
+ u32 status;
/*
* As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
@@ -498,6 +508,15 @@ static unsigned int iproc_pcie_cfg_retry(void __iomem
*cfg_data_p)
*/
data = readl(cfg_data_p);
while (data == CFG_RETRY_STATUS && timeout--) {
+ /*
+* CRS state is set in CFG_RD status register
+* This will handle the case where CFG_RETRY_STATUS is
+* valid config data.
+*/
+ status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
+ if (status != CFG_RD_CRS)
+ return data;
+
udelay(1);
data = readl(cfg_data_p);
}
@@ -576,7 +595,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus,
unsigned int devfn,
if (!cfg_data_p)
return PCIBIOS_DEVICE_NOT_FOUND;
- data = iproc_pcie_cfg_retry(cfg_data_p);
+ data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
*val = data;
if (size <= 2)
--
2.7.4
[PATCH v3 0/2] Add IPROC PCIe new features
This patch set extends support of new IPROC PCIe host controller features - Add CRS check using controller register status flags - Add outbound window mapping configuration for 32-bit I/O region This patch set is based on Linux-5.0-rc2. Changes from v2: - Based on Lorenzo Pieralisi comments, commit logs are expanded. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed set order mode patch from patchset. Srinath Mannam (2): PCI: iproc: Add CRS check in config read PCI: iproc: Add outbound configuration for 32-bit I/O region drivers/pci/controller/pcie-iproc.c | 44 + 1 file changed, 40 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH v4 0/3] Stingray USB PHY driver support
These patches add Stingray USB PHY driver and its corresponding DT nodes with documentation. This patch set is based on Linux-5.0-rc2. Changes from v3: - Addressed Rob Herring review comments - Changed compatible strings. - updated driver based on new compatible strings. Changes from v2: - Addressed Kishon review comments - Updated patchset to Linux-5.0-rc2 Changes from v1: - Addressed Kishon review comments - phy init call return value handle Srinath Mannam (3): dt-bindings: phy: Add Stingray USB PHY binding document phy: sr-usb: Add Stingray USB PHY driver arm64: dts: Add USB DT nodes for Stingray SoC .../bindings/phy/brcm,stingray-usb-phy.txt | 62 .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++ .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + drivers/phy/broadcom/Kconfig | 11 + drivers/phy/broadcom/Makefile | 1 + drivers/phy/broadcom/phy-bcm-sr-usb.c | 371 + 6 files changed, 541 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c -- 2.7.4
[PATCH v4 3/3] arm64: dts: Add USB DT nodes for Stingray SoC
Add DT nodes for
- Two xHCI host controllers
- Two BDC Broadcom USB device controller
- Five USB PHY controllers
[xHCI0] [BDC0][xHCI1][BDC1]
| | | |
--- ---
| | | | |
[SS-PHY0] [HS-PHY0][SS-PHY1] [HS-PHY2] [HS-PHY1]
[SS-PHY0/HS-PHY0] and [SS-PHY1/HS-PHY1] are combo PHYs has one SS and
one HS PHYs. [HS-PHY2] is a single HS PHY.
xHCI use SS-PHY to detect SS devices and HS-PHY to detect HS/FS/LS
devices. BDC use SS-PHY in SS mode and HS-PHY in HS mode.
xHCI0 port1 is SS-PHY0, port2 is HS-PHY0.
xHCI1 port1 is SS-PHY1, port2 is HS-PHY2 and port3 is HS-PHY1.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
2 files changed, 96 insertions(+)
create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
new file mode 100644
index 000..c0748ee
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ *Copyright(c) 2018 Broadcom
+ */
+ usb {
+ compatible = "simple-bus";
+ dma-ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x6850 0x0040>;
+
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ usb0_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+ usb0_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ };
+
+ xhci0: usb@1000 {
+ compatible = "generic-xhci";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <_phy0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc0: usb@2000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x2000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <_phy0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x0001 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ usb1_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+ usb1_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x0002 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ xhci1: usb@11000 {
+ compatible = "generic-xhci";
+ reg = <0x00011000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <>, <_phy0>;
+ phy-names = "phy0", "phy1", "phy2";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc1: usb@21000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x00021000 0x1000>;
+
[PATCH v4 2/3] phy: sr-usb: Add Stingray USB PHY driver
USB PHY driver supports two versions of stingray USB PHYs
- Version 1 is a combo PHY contains one SS and one HS PHYs.
- Version 2 is a single HS PHY.
These two PHY versons support both Generic xHCI host controller driver
and BDC Broadcom device controller driver.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
drivers/phy/broadcom/Kconfig | 11 +
drivers/phy/broadcom/Makefile | 1 +
drivers/phy/broadcom/phy-bcm-sr-usb.c | 371 ++
3 files changed, 383 insertions(+)
create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index aa917a6..f30f481 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -10,6 +10,17 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_BCM_SR_USB
+ tristate "Broadcom Stingray USB PHY driver"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Stingray USB PHY
+ driver. It supports all versions of Superspeed and
+ Highspeed PHYs.
+ If unsure, say N.
+
config BCM_KONA_USB2_PHY
tristate "Broadcom Kona USB2 PHY Driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/broadcom/Makefile b/drivers/phy/broadcom/Makefile
index 0f60184..f453c7d 100644
--- a/drivers/phy/broadcom/Makefile
+++ b/drivers/phy/broadcom/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PHY_BRCM_USB)+= phy-brcm-usb-dvr.o
phy-brcm-usb-dvr-objs := phy-brcm-usb.o phy-brcm-usb-init.o
obj-$(CONFIG_PHY_BCM_SR_PCIE) += phy-bcm-sr-pcie.o
+obj-$(CONFIG_PHY_BCM_SR_USB) += phy-bcm-sr-usb.o
diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c
b/drivers/phy/broadcom/phy-bcm-sr-usb.c
new file mode 100644
index 000..3b70d28
--- /dev/null
+++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum bcm_usb_phy_version {
+ BCM_SR_USB_COMBO_PHY,
+ BCM_SR_USB_HS_PHY,
+};
+
+enum bcm_usb_phy_reg {
+ PLL_NDIV_FRAC,
+ PLL_NDIV_INT,
+ PLL_CTRL,
+ PHY_CTRL,
+ PHY_PLL_CTRL,
+};
+
+/* USB PHY registers */
+
+static const u8 bcm_usb_combo_phy_ss[] = {
+ [PLL_CTRL] = 0x18,
+ [PHY_CTRL] = 0x14,
+};
+
+static const u8 bcm_usb_combo_phy_hs[] = {
+ [PLL_NDIV_FRAC] = 0x04,
+ [PLL_NDIV_INT] = 0x08,
+ [PLL_CTRL] = 0x0c,
+ [PHY_CTRL] = 0x10,
+};
+
+#define HSPLL_NDIV_INT_VAL 0x13
+#define HSPLL_NDIV_FRAC_VAL0x1005
+
+static const u8 bcm_usb_hs_phy[] = {
+ [PLL_NDIV_FRAC] = 0x0,
+ [PLL_NDIV_INT] = 0x4,
+ [PLL_CTRL] = 0x8,
+ [PHY_CTRL] = 0xc,
+};
+
+enum pll_ctrl_bits {
+ PLL_RESETB,
+ SSPLL_SUSPEND_EN,
+ PLL_SEQ_START,
+ PLL_LOCK,
+ PLL_PDIV,
+};
+
+static const u8 u3pll_ctrl[] = {
+ [PLL_RESETB]= 0,
+ [SSPLL_SUSPEND_EN] = 1,
+ [PLL_SEQ_START] = 2,
+ [PLL_LOCK] = 3,
+};
+
+#define HSPLL_PDIV_MASK0xF
+#define HSPLL_PDIV_VAL 0x1
+
+static const u8 u2pll_ctrl[] = {
+ [PLL_PDIV] = 1,
+ [PLL_RESETB]= 5,
+ [PLL_LOCK] = 6,
+};
+
+enum bcm_usb_phy_ctrl_bits {
+ CORERDY,
+ AFE_LDO_PWRDWNB,
+ AFE_PLL_PWRDWNB,
+ AFE_BG_PWRDWNB,
+ PHY_ISO,
+ PHY_RESETB,
+ PHY_PCTL,
+};
+
+#define PHY_PCTL_MASK 0x
+/*
+ * 0x0806 of PCTL_VAL has below bits set
+ * BIT-8 : refclk divider 1
+ * BIT-3:2: device mode; mode is not effect
+ * BIT-1: soft reset active low
+ */
+#define HSPHY_PCTL_VAL 0x0806
+#define SSPHY_PCTL_VAL 0x0006
+
+static const u8 u3phy_ctrl[] = {
+ [PHY_RESETB]= 1,
+ [PHY_PCTL] = 2,
+};
+
+static const u8 u2phy_ctrl[] = {
+ [CORERDY] = 0,
+ [AFE_LDO_PWRDWNB] = 1,
+ [AFE_PLL_PWRDWNB] = 2,
+ [AFE_BG_PWRDWNB]= 3,
+ [PHY_ISO] = 4,
+ [PHY_RESETB]= 5,
+ [PHY_PCTL] = 6,
+};
+
+struct bcm_usb_phy_cfg {
+ uint32_t type;
+ uint32_t version;
+ void __iomem *regs;
+ struct phy *phy;
+ const u8 *offset;
+};
+
+#define PLL_LOCK_RETRY_COUNT 1000
+
+enum bcm_usb_phy_type {
+ USB_HS_PHY,
+ USB_SS_PHY,
+};
+
+static inline void bcm_usb_reg32_clrbits(void __iomem *addr, uint32_t clear)
+{
+ writel(readl(addr) & ~clear, addr);
+}
+
+static inline void bcm_usb_reg32_setbits(void __iomem *addr, uint32_t set)
+{
+ writel(readl(addr) | set, addr);
+}
+
+static int bcm_usb_pll_lock_c
[PATCH v4 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Add DT binding document for Stingray USB PHY.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
.../bindings/phy/brcm,stingray-usb-phy.txt | 62 ++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
new file mode 100644
index 000..da19236
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
@@ -0,0 +1,62 @@
+Broadcom Stingray USB PHY
+
+Required properties:
+ - compatible : should be one of the listed compatibles
+ - "brcm,sr-usb-combo-phy" is a combo PHY has one SS PHY and one HS PHY.
+ - "brcm,sr-usb-hs-phy" has a single HS PHY.
+ - reg: offset and length of the PHY blocks registers
+ - address-cells: should be 1
+ - size-cells: should be 0
+
+Sub-nodes:
+ brcm,sr-usb-combo-phy have two sub-nodes for one SS PHY and one HS PHY.
+
+Sub-nodes required properties:
+ - reg: required for brcm,sr-usb-phy model PHY.
+ reg value 0 is HS PHY and 1 is SS PHY.
+ - phy-cells: generic PHY binding; must be 0
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb0_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ usb0_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-combo-phy";
+ reg = <0x0001 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb1_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ usb1_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-hs-phy";
+ reg = <0x0002 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ };
--
2.7.4
Re: [PATCH v3 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Hi Rob,
Thanks for review, please see my comments below inline.
On Mon, Feb 18, 2019 at 10:52 PM Rob Herring wrote:
>
> On Wed, Feb 06, 2019 at 11:02:25PM +0530, Srinath Mannam wrote:
> > Add DT binding document for Stingray USB PHY.
> >
> > Signed-off-by: Srinath Mannam
> > Reviewed-by: Florian Fainelli
> > Reviewed-by: Scott Branden
> > ---
> > .../bindings/phy/brcm,stingray-usb-phy.txt | 62
> > ++
> > 1 file changed, 62 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > new file mode 100644
> > index 000..bfe1367
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
> > @@ -0,0 +1,62 @@
> > +Broadcom Stingray USB PHY
> > +
> > +Required properties:
> > + - compatible : should be one of the listed compatibles
> > + - "brcm,sr-usb-phy"
> > + - "brcm,sr-usb-phy-v2"
>
> SoC specific compatibles are preferred. Version numbers can be used but
> should follow some documented scheme and be meaningful. What we don't
> want is just Linux developers making up numbering.
>
Both versions are different phy controllers and also have separate
register offsets.
I will provide more meaningful compatible IDs and their documentation
in next patchset.
> > + - reg: offset and length of the PHY blocks registers
> > + - address-cells: should be 1
> > + - size-cells: should be 0
> > +
> > +Sub-nodes:
> > + Each port's PHY should be represented as a sub-node.
> > +
> > +Sub-nodes required properties:
> > + - reg: required for brcm,sr-usb-phy model phy.
> > + reg value 0 is HS phy and 1 is SS phy.
> > + - phy-cells: generic PHY binding; must be 0
> > +
> > +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> > +
> > +Example:
> > + usbphy0: usb-phy@0 {
> > + compatible = "brcm,sr-usb-phy";
> > + reg = <0x 0x100>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + usb0_phy0: phy@0 {
> > + reg = <0>;
> > + #phy-cells = <0>;
>
> Unless there's DT resources for each child node, you don't need these.
> Just make #phy-cells 1 in the parent.
With the use of phy-cell, PHY argument is available with xlate
function, But controller specific assignments required
to be done while probe. So I will take your first option given in
previous comment.
Regards,
Srinath.
>
> Rob
Re: [PATCH v3 0/3] Stingray USB PHY driver support
Hi Kishon, Could you please help to review and provide your comments to this patch series when you have time? Regards, Srinath. On Wed, Feb 6, 2019 at 11:03 PM Srinath Mannam wrote: > > These patches add Stingray USB PHY driver and its corresponding > DT nodes with documentation. > > This patch set is based on Linux-5.0-rc2. > > Changes from v2: > - Addressed Kishon review comments > - Updated patchset to Linux-5.0-rc2 > > Changes from v1: > - Addressed Kishon review comments > - phy init call return value handle > > Srinath Mannam (3): > dt-bindings: phy: Add Stingray USB PHY binding document > phy: sr-usb: Add Stingray USB PHY driver > arm64: dts: Add USB DT nodes for Stingray SoC > > .../bindings/phy/brcm,stingray-usb-phy.txt | 62 > .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++ > .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + > drivers/phy/broadcom/Kconfig | 11 + > drivers/phy/broadcom/Makefile | 1 + > drivers/phy/broadcom/phy-bcm-sr-usb.c | 371 > + > 6 files changed, 541 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt > create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi > create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c > > -- > 2.7.4 >
Re: [PATCH v6 0/3] Stingray thermal driver support
Hi Eduardo, Could you please provide your review comments? Regards, Srinath. On Wed, Feb 6, 2019 at 5:28 AM Eduardo Valentin wrote: > > Hello, > > On Mon, Feb 04, 2019 at 04:16:19PM -0800, Ray Jui wrote: > > Hi Zhang/Eduardo, > > > > Can this patch series be merged? It looks like Srinath has addressed all > > review comments? > > I will take a look. Side note, thermal patches are reviewed on > linux...@vger.kernel.org. Copying that list it does help because that > is how the patches get assigned in patchwork.kernel.org. > > > > > The following tag should be added to the binding document patch: > > > > Reviewed-by: Rob Herring > > > > Thanks, > > > > Ray > > > > On 1/3/2019 12:55 AM, Srinath Mannam wrote: > > > These patches adds the stingray thermal driver and its > > > corresponding DT nodes with documentation. > > > > > > Changes from v5 > > > - Addressed Eduardo Valentin comments. > > > > > > Changes from v4 > > > - Addressed Rob Herring comments on DT parameters and > > > thermal driver architecture. > > > - Removed brcm,max-crit-temp DT parameter > > > - Changed driver to thermal sensor registration model. > > > - Added trip DT properties. > > > > > > Changes from v3 > > > - Addressed Daniel lezcano comments. > > > - Elaborated commit description of thermal driver patch. > > > - Added brcm,max-crit-temp DT parameter. > > > > > > Changes from v2: > > > - All stingray TMON DT nodes are combine together into single. > > > Temperature registers are combined into one mem resource. > > > brcm,tmon-mask parameter has available TMONs mask value. > > > - All available TMONs are initialized together in single > > > instance of driver probe call. > > > > > > Changes from v1: > > > - Fixed auto build sparce warning. > > > > > > Pramod Kumar (3): > > > dt-bindings: thermal: Add binding document for SR thermal > > > thermal: broadcom: Add Stingray thermal driver > > > arm64: dts: stingray: Add Stingray Thermal DT support. > > > > > > .../bindings/thermal/brcm,sr-thermal.txt | 105 > > > ++ > > > .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 89 +++ > > > drivers/thermal/Kconfig| 3 +- > > > drivers/thermal/broadcom/Kconfig | 9 ++ > > > drivers/thermal/broadcom/Makefile | 1 + > > > drivers/thermal/broadcom/sr-thermal.c | 122 > > > + > > > 6 files changed, 328 insertions(+), 1 deletion(-) > > > create mode 100644 > > > Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt > > > create mode 100644 drivers/thermal/broadcom/sr-thermal.c > > >
Re: [PATCH v2 2/2] PCI: iproc: Add PCIe 32bit outbound memory configuration
Hi Lorenzo,
Thanks for review, please see my comments below inline.
On Wed, Feb 13, 2019 at 12:07 AM Lorenzo Pieralisi
wrote:
>
> On Tue, Feb 05, 2019 at 10:27:01AM +0530, Srinath Mannam wrote:
> > Add configuration to support IPROC PCIe host controller outbound memory
> > window mapping with SOC address range inside 4GB boundary, which is 32 bit
> > AXI address.
>
> I do not understand what this means, explain it to me and rewrite the
> commit log accordingly.
>
This is about "I/O regions" addressing given through ranges DT property.
In the current driver "I/O regions" address mapping to corresponding
PCI memory address in controller outbound registers
is supports above 32-bit address.
> What does this solve ? Why do we need this patch or rephrased, what
> is missing in the current driver ?
With this patch, If ranges DT property has below 32-bit I/O regions
address then it will be added in the outbound mapping.
This will help to access I/O region from CPU in 32-bit.
I will update commit log and send next patch set.
Ex:
1. ranges DT property for current driver is,
ranges = <0x8300 0x0 0x4000 0x4 0x 0 0x4000>;
I/O region address is 0x4
2. ranges DT property with this patch,
ranges = <0x8300 0x0 0x4200 0x0 0x4200 0 0x200>;
I/O region address is 0x4200
Regards,
Srinath.
>
> > Signed-off-by: Srinath Mannam
> > Signed-off-by: Abhishek Shah
> > Signed-off-by: Ray Jui
> > Reviewed-by: Scott Branden
> > Reviewed-by: Vikram Prakash
>
> Review tags should be given on public mailing lists, these ones seem
> to come from non-public review cycles in which case you must drop
> them.
>
> > drivers/pci/controller/pcie-iproc.c | 21 +++--
> > 1 file changed, 19 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c
> > b/drivers/pci/controller/pcie-iproc.c
> > index b882255..080f142 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie
> > *pcie, u64 axi_addr,
> > resource_size_t window_size =
> > ob_map->window_sizes[size_idx] * SZ_1M;
> >
> > - if (size < window_size)
> > - continue;
> > + /*
> > + * Keep iterating until we reach the last window and
> > + * with the minimal window size at index zero. In this
> > + * case, we take a compromise by mapping it using the
> > + * minimum window size that can be supported
>
> See above, I do not understand clearly what this means.
>
> Lorenzo
>
> > + */
> > + if (size < window_size) {
> > + if (size_idx > 0 || window_idx > 0)
> > + continue;
> > +
> > + /*
> > + * For the corner case of reaching the minimal
> > + * window size that can be supported on the
> > + * last window
> > + */
> > + axi_addr = ALIGN_DOWN(axi_addr, window_size);
> > + pci_addr = ALIGN_DOWN(pci_addr, window_size);
> > + size = window_size;
> > + }
> >
> > if (!IS_ALIGNED(axi_addr, window_size) ||
> > !IS_ALIGNED(pci_addr, window_size)) {
> > --
> > 2.7.4
> >
Re: [PATCH v2 1/2] PCI: iproc: Add CRS check in config read
Hi Lorenzo,
Thanks for review, please see my comments below inline.
On Tue, Feb 12, 2019 at 11:42 PM Lorenzo Pieralisi
wrote:
>
> On Tue, Feb 05, 2019 at 10:27:00AM +0530, Srinath Mannam wrote:
> > In the current implementation, config read output data 0x0001 is
> > assumed as CRS completion. But sometimes 0x0001 can be a valid data.
> >
> > IPROC PCIe host controller has a register to show config read request
> > status flags like SC, UR, CRS and CA. So that extra check is added to
> > confirm the CRS using status flags before reissue config read.
> >
> > Signed-off-by: Srinath Mannam
> > Reviewed-by: Ray Jui
> > ---
> > drivers/pci/controller/pcie-iproc.c | 23 +--
> > 1 file changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-iproc.c
> > b/drivers/pci/controller/pcie-iproc.c
> > index c20fd6b..b882255 100644
> > --- a/drivers/pci/controller/pcie-iproc.c
> > +++ b/drivers/pci/controller/pcie-iproc.c
> > @@ -60,6 +60,10 @@
> > #define APB_ERR_EN_SHIFT 0
> > #define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
> >
> > +#define CFG_RD_SUCCESS 0
> > +#define CFG_RD_UR1
> > +#define CFG_RD_CRS 2
> > +#define CFG_RD_CA3
> > #define CFG_RETRY_STATUS 0x0001
> > #define CFG_RETRY_STATUS_TIMEOUT_US 50 /* 500 milliseconds */
> >
> > @@ -289,6 +293,9 @@ enum iproc_pcie_reg {
> > IPROC_PCIE_IARR4,
> > IPROC_PCIE_IMAP4,
> >
> > + /* config read status */
> > + IPROC_PCIE_CFG_RD_STATUS,
> > +
> > /* link status */
> > IPROC_PCIE_LINK_STATUS,
> >
> > @@ -350,6 +357,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
> > [IPROC_PCIE_IMAP3] = 0xe08,
> > [IPROC_PCIE_IARR4] = 0xe68,
> > [IPROC_PCIE_IMAP4] = 0xe70,
> > + [IPROC_PCIE_CFG_RD_STATUS] = 0xee0,
>
> So, with the *current* code, on controllers that does not support this
> register you won't be able to get any HW whose config space register
> value reads 0x0001 to work, is that correct ?
>
Yes, this feature(register) is available only in "iProc PCIe PAXB v2"
controller for other controllers it will not applicable.
Regards,
Srinath.
> Lorenzo
>
> > [IPROC_PCIE_LINK_STATUS]= 0xf0c,
> > [IPROC_PCIE_APB_ERR_EN] = 0xf40,
> > };
> > @@ -474,10 +482,12 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct
> > iproc_pcie *pcie,
> > return (pcie->base + offset);
> > }
> >
> > -static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
> > +static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
> > + void __iomem *cfg_data_p)
> > {
> > int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
> > unsigned int data;
> > + u32 status;
> >
> > /*
> >* As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
> > @@ -498,6 +508,15 @@ static unsigned int iproc_pcie_cfg_retry(void __iomem
> > *cfg_data_p)
> >*/
> > data = readl(cfg_data_p);
> > while (data == CFG_RETRY_STATUS && timeout--) {
> > + /*
> > + * CRS state is set in CFG_RD status register
> > + * This will handle the case where CFG_RETRY_STATUS is
> > + * valid config data.
> > + */
> > + status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
> > + if (status != CFG_RD_CRS)
> > + return data;
> > +
> > udelay(1);
> > data = readl(cfg_data_p);
> > }
> > @@ -576,7 +595,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus,
> > unsigned int devfn,
> > if (!cfg_data_p)
> > return PCIBIOS_DEVICE_NOT_FOUND;
> >
> > - data = iproc_pcie_cfg_retry(cfg_data_p);
> > + data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
> >
> > *val = data;
> > if (size <= 2)
> > --
> > 2.7.4
> >
Re: [PATCH 2/2] drivers: xhci: Add quirk to reset xHCI port PHY
Hi Mathias,
Thanks for comments, Please find my comments below inline.
On Fri, Feb 8, 2019 at 6:00 PM Mathias Nyman
wrote:
>
> On 07.02.2019 17:17, Srinath Mannam wrote:
> > Hi Mathias,
> >
> > Thanks for review, please see my comments below inline.
> >
> > On Thu, Feb 7, 2019 at 8:32 PM Mathias Nyman
> > wrote:
> >>
> >> On 05.02.2019 08:18, Srinath Mannam wrote:
> >>> Add a quirk to reset xHCI port PHY on port disconnect event.
> >>> Stingray USB HS PHY has an issue, that USB High Speed device detected
> >>> at Full Speed after the same port has connected to Full speed device.
> >>> This problem can be resolved with that port PHY reset on disconnect.
> >>>
> >>> Signed-off-by: Srinath Mannam
> >>> Reviewed-by: Ray Jui
> >>> ---
> >>>drivers/usb/core/hcd.c | 6 ++
> >>>drivers/usb/core/phy.c | 21 +
> >>>drivers/usb/core/phy.h | 1 +
> >>>drivers/usb/host/xhci-plat.c | 3 +++
> >>>drivers/usb/host/xhci-ring.c | 9 ++---
> >>>drivers/usb/host/xhci.h | 1 +
> >>>include/linux/usb/hcd.h | 1 +
> >>>7 files changed, 39 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> >>> index 015b126..e2b87a6 100644
> >>> --- a/drivers/usb/core/hcd.c
> >>> +++ b/drivers/usb/core/hcd.c
> >>> @@ -2663,6 +2663,12 @@ int usb_hcd_find_raw_port_number(struct usb_hcd
> >>> *hcd, int port1)
> >>>return hcd->driver->find_raw_port_number(hcd, port1);
> >>>}
> >>>
> >>> +int usb_hcd_phy_port_reset(struct usb_hcd *hcd, int port)
> >>> +{
> >>> + return usb_phy_roothub_port_reset(hcd->phy_roothub, port);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(usb_hcd_phy_port_reset);
> >>> +
> >>>static int usb_hcd_request_irqs(struct usb_hcd *hcd,
> >>>unsigned int irqnum, unsigned long irqflags)
> >>>{
> >>> diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
> >>> index 38b2c77..c64767d 100644
> >>> --- a/drivers/usb/core/phy.c
> >>> +++ b/drivers/usb/core/phy.c
> >>> @@ -162,6 +162,27 @@ void usb_phy_roothub_power_off(struct
> >>> usb_phy_roothub *phy_roothub)
> >>>}
> >>>EXPORT_SYMBOL_GPL(usb_phy_roothub_power_off);
> >>>
> >>> +int usb_phy_roothub_port_reset(struct usb_phy_roothub *phy_roothub, int
> >>> port)
> >>> +{
> >>> + struct usb_phy_roothub *roothub_entry;
> >>> + struct list_head *head;
> >>> + int i = 0;
> >>> +
> >>> + if (!phy_roothub)
> >>> + return -EINVAL;
> >>> +
> >>> + head = _roothub->list;
> >>> +
> >>> + list_for_each_entry(roothub_entry, head, list) {
> >>> + if (i == port)
> >>> + return phy_reset(roothub_entry->phy);
> >>> + i++;
> >>> + }
> >>
> >> I'm not that familiar with SoC's that have several PHYs per controller,
> >> but this looks odd.
> >>
> >> For the above code to work wouldn't it require that each port has their
> >> own PHY,
> >> and the PHYs are added to the list of usb_phy_roothub is in the same order
> >> as usb ports?
> >>
> >> Or is there something I don't understand here?
> >>
> > In our SOC (Stingray), xHCI controller has three ports and each port
> > connected to separate PHY.
> > Stingray xHCI controller supports both SS and HS ports and connected
> > separate PHYs.
> > We passed PHY phandlers in xHCI DT node in the order of port numbers.
> > as shown below xHCI DT node.
> > So that all PHYs added to usb_phy_roothub are in order of port numbers.
> > xhci1: usb@11000 {
> > compatible = "generic-xhci";
> > reg = <0x00011000 0x1000>;
> > interrupts = ;
> > phys = <_phy1>, <>, <_phy0>;
> > phy-names = "phy0", "phy1", "phy2";
> > dma-coherent;
> > status = "disabled";
> > };
> >
Re: [PATCH 2/2] drivers: xhci: Add quirk to reset xHCI port PHY
Hi Mathias,
Thanks for review, please see my comments below inline.
On Thu, Feb 7, 2019 at 8:32 PM Mathias Nyman
wrote:
>
> On 05.02.2019 08:18, Srinath Mannam wrote:
> > Add a quirk to reset xHCI port PHY on port disconnect event.
> > Stingray USB HS PHY has an issue, that USB High Speed device detected
> > at Full Speed after the same port has connected to Full speed device.
> > This problem can be resolved with that port PHY reset on disconnect.
> >
> > Signed-off-by: Srinath Mannam
> > Reviewed-by: Ray Jui
> > ---
> > drivers/usb/core/hcd.c | 6 ++
> > drivers/usb/core/phy.c | 21 +
> > drivers/usb/core/phy.h | 1 +
> > drivers/usb/host/xhci-plat.c | 3 +++
> > drivers/usb/host/xhci-ring.c | 9 ++---
> > drivers/usb/host/xhci.h | 1 +
> > include/linux/usb/hcd.h | 1 +
> > 7 files changed, 39 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> > index 015b126..e2b87a6 100644
> > --- a/drivers/usb/core/hcd.c
> > +++ b/drivers/usb/core/hcd.c
> > @@ -2663,6 +2663,12 @@ int usb_hcd_find_raw_port_number(struct usb_hcd
> > *hcd, int port1)
> > return hcd->driver->find_raw_port_number(hcd, port1);
> > }
> >
> > +int usb_hcd_phy_port_reset(struct usb_hcd *hcd, int port)
> > +{
> > + return usb_phy_roothub_port_reset(hcd->phy_roothub, port);
> > +}
> > +EXPORT_SYMBOL_GPL(usb_hcd_phy_port_reset);
> > +
> > static int usb_hcd_request_irqs(struct usb_hcd *hcd,
> > unsigned int irqnum, unsigned long irqflags)
> > {
> > diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
> > index 38b2c77..c64767d 100644
> > --- a/drivers/usb/core/phy.c
> > +++ b/drivers/usb/core/phy.c
> > @@ -162,6 +162,27 @@ void usb_phy_roothub_power_off(struct usb_phy_roothub
> > *phy_roothub)
> > }
> > EXPORT_SYMBOL_GPL(usb_phy_roothub_power_off);
> >
> > +int usb_phy_roothub_port_reset(struct usb_phy_roothub *phy_roothub, int
> > port)
> > +{
> > + struct usb_phy_roothub *roothub_entry;
> > + struct list_head *head;
> > + int i = 0;
> > +
> > + if (!phy_roothub)
> > + return -EINVAL;
> > +
> > + head = _roothub->list;
> > +
> > + list_for_each_entry(roothub_entry, head, list) {
> > + if (i == port)
> > + return phy_reset(roothub_entry->phy);
> > + i++;
> > + }
>
> I'm not that familiar with SoC's that have several PHYs per controller,
> but this looks odd.
>
> For the above code to work wouldn't it require that each port has their own
> PHY,
> and the PHYs are added to the list of usb_phy_roothub is in the same order as
> usb ports?
>
> Or is there something I don't understand here?
>
In our SOC (Stingray), xHCI controller has three ports and each port
connected to separate PHY.
Stingray xHCI controller supports both SS and HS ports and connected
separate PHYs.
We passed PHY phandlers in xHCI DT node in the order of port numbers.
as shown below xHCI DT node.
So that all PHYs added to usb_phy_roothub are in order of port numbers.
xhci1: usb@11000 {
compatible = "generic-xhci";
reg = <0x00011000 0x1000>;
interrupts = ;
phys = <_phy1>, <>, <_phy0>;
phy-names = "phy0", "phy1", "phy2";
dma-coherent;
status = "disabled";
};
But we have issue with HS PHYs, so that those PHYs are required to reset.
Regards,
Srinath.
> -Mathias
>
[PATCH v3 2/3] phy: sr-usb: Add Stingray USB PHY driver
USB PHY driver supports all versions of stingray SS and HS USB PHYs.
- Version 1 is a combo PHY contains both SS and HS PHYs.
- Version 2 is a single HS PHY.
These PHYs support both Generic xHCI host controller driver and BDC
Broadcom device controller driver.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
drivers/phy/broadcom/Kconfig | 11 +
drivers/phy/broadcom/Makefile | 1 +
drivers/phy/broadcom/phy-bcm-sr-usb.c | 371 ++
3 files changed, 383 insertions(+)
create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index aa917a6..f30f481 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -10,6 +10,17 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_BCM_SR_USB
+ tristate "Broadcom Stingray USB PHY driver"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Stingray USB PHY
+ driver. It supports all versions of Superspeed and
+ Highspeed PHYs.
+ If unsure, say N.
+
config BCM_KONA_USB2_PHY
tristate "Broadcom Kona USB2 PHY Driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/broadcom/Makefile b/drivers/phy/broadcom/Makefile
index 0f60184..f453c7d 100644
--- a/drivers/phy/broadcom/Makefile
+++ b/drivers/phy/broadcom/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PHY_BRCM_USB)+= phy-brcm-usb-dvr.o
phy-brcm-usb-dvr-objs := phy-brcm-usb.o phy-brcm-usb-init.o
obj-$(CONFIG_PHY_BCM_SR_PCIE) += phy-bcm-sr-pcie.o
+obj-$(CONFIG_PHY_BCM_SR_USB) += phy-bcm-sr-usb.o
diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c
b/drivers/phy/broadcom/phy-bcm-sr-usb.c
new file mode 100644
index 000..abf801d
--- /dev/null
+++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum bcm_usb_phy_version {
+ BCM_USB_PHY_V1,
+ BCM_USB_PHY_V2,
+};
+
+enum bcm_usb_phy_reg {
+ PLL_NDIV_FRAC,
+ PLL_NDIV_INT,
+ PLL_CTRL,
+ PHY_CTRL,
+ PHY_PLL_CTRL,
+};
+
+/* USB PHY registers */
+
+static const u8 bcm_usb_u3phy_v1[] = {
+ [PLL_CTRL] = 0x18,
+ [PHY_CTRL] = 0x14,
+};
+
+static const u8 bcm_usb_u2phy_v1[] = {
+ [PLL_NDIV_FRAC] = 0x04,
+ [PLL_NDIV_INT] = 0x08,
+ [PLL_CTRL] = 0x0c,
+ [PHY_CTRL] = 0x10,
+};
+
+#define HSPLL_NDIV_INT_VAL 0x13
+#define HSPLL_NDIV_FRAC_VAL0x1005
+
+static const u8 bcm_usb_u2phy_v2[] = {
+ [PLL_NDIV_FRAC] = 0x0,
+ [PLL_NDIV_INT] = 0x4,
+ [PLL_CTRL] = 0x8,
+ [PHY_CTRL] = 0xc,
+};
+
+enum pll_ctrl_bits {
+ PLL_RESETB,
+ SSPLL_SUSPEND_EN,
+ PLL_SEQ_START,
+ PLL_LOCK,
+ PLL_PDIV,
+};
+
+static const u8 u3pll_ctrl[] = {
+ [PLL_RESETB]= 0,
+ [SSPLL_SUSPEND_EN] = 1,
+ [PLL_SEQ_START] = 2,
+ [PLL_LOCK] = 3,
+};
+
+#define HSPLL_PDIV_MASK0xF
+#define HSPLL_PDIV_VAL 0x1
+
+static const u8 u2pll_ctrl[] = {
+ [PLL_PDIV] = 1,
+ [PLL_RESETB]= 5,
+ [PLL_LOCK] = 6,
+};
+
+enum bcm_usb_phy_ctrl_bits {
+ CORERDY,
+ AFE_LDO_PWRDWNB,
+ AFE_PLL_PWRDWNB,
+ AFE_BG_PWRDWNB,
+ PHY_ISO,
+ PHY_RESETB,
+ PHY_PCTL,
+};
+
+#define PHY_PCTL_MASK 0x
+/*
+ * 0x0806 of PCTL_VAL has below bits set
+ * BIT-8 : refclk divider 1
+ * BIT-3:2: device mode; mode is not effect
+ * BIT-1: soft reset active low
+ */
+#define HSPHY_PCTL_VAL 0x0806
+#define SSPHY_PCTL_VAL 0x0006
+
+static const u8 u3phy_ctrl[] = {
+ [PHY_RESETB]= 1,
+ [PHY_PCTL] = 2,
+};
+
+static const u8 u2phy_ctrl[] = {
+ [CORERDY] = 0,
+ [AFE_LDO_PWRDWNB] = 1,
+ [AFE_PLL_PWRDWNB] = 2,
+ [AFE_BG_PWRDWNB]= 3,
+ [PHY_ISO] = 4,
+ [PHY_RESETB]= 5,
+ [PHY_PCTL] = 6,
+};
+
+struct bcm_usb_phy_cfg {
+ uint32_t type;
+ uint32_t ver;
+ void __iomem *regs;
+ struct phy *phy;
+ const u8 *offset;
+};
+
+#define PLL_LOCK_RETRY_COUNT 1000
+
+enum bcm_usb_phy_type {
+ USB_HS_PHY,
+ USB_SS_PHY,
+};
+
+static inline void bcm_usb_reg32_clrbits(void __iomem *addr, uint32_t clear)
+{
+ writel(readl(addr) & ~clear, addr);
+}
+
+static inline void bcm_usb_reg32_setbits(void __iomem *addr, uint32_t set)
+{
+ writel(readl(addr) | set, addr);
+}
+
+static int bcm_usb_pll_lock_check(void __iomem *addr, u32 bit)
+
[PATCH v3 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Add DT binding document for Stingray USB PHY.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
.../bindings/phy/brcm,stingray-usb-phy.txt | 62 ++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
new file mode 100644
index 000..bfe1367
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
@@ -0,0 +1,62 @@
+Broadcom Stingray USB PHY
+
+Required properties:
+ - compatible : should be one of the listed compatibles
+ - "brcm,sr-usb-phy"
+ - "brcm,sr-usb-phy-v2"
+ - reg: offset and length of the PHY blocks registers
+ - address-cells: should be 1
+ - size-cells: should be 0
+
+Sub-nodes:
+ Each port's PHY should be represented as a sub-node.
+
+Sub-nodes required properties:
+ - reg: required for brcm,sr-usb-phy model phy.
+ reg value 0 is HS phy and 1 is SS phy.
+ - phy-cells: generic PHY binding; must be 0
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb0_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ usb0_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-phy";
+ reg = <0x0001 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb1_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ usb1_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-phy-v2";
+ reg = <0x0002 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ };
--
2.7.4
[PATCH v3 0/3] Stingray USB PHY driver support
These patches add Stingray USB PHY driver and its corresponding DT nodes with documentation. This patch set is based on Linux-5.0-rc2. Changes from v2: - Addressed Kishon review comments - Updated patchset to Linux-5.0-rc2 Changes from v1: - Addressed Kishon review comments - phy init call return value handle Srinath Mannam (3): dt-bindings: phy: Add Stingray USB PHY binding document phy: sr-usb: Add Stingray USB PHY driver arm64: dts: Add USB DT nodes for Stingray SoC .../bindings/phy/brcm,stingray-usb-phy.txt | 62 .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++ .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + drivers/phy/broadcom/Kconfig | 11 + drivers/phy/broadcom/Makefile | 1 + drivers/phy/broadcom/phy-bcm-sr-usb.c | 371 + 6 files changed, 541 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c -- 2.7.4
[PATCH v3 3/3] arm64: dts: Add USB DT nodes for Stingray SoC
Add DT nodes for
- Two xHCI host controllers
- Two BDC Broadcom USB device controller
- Five USB PHY controllers
[xHCI0] [BDC0][xHCI1][BDC1]
| | | |
--- ---
| | | | |
[SS-PHY0] [HS-PHY0][SS-PHY1] [HS-PHY2] [HS-PHY1]
[SS-PHY0/HS-PHY0] and [SS-PHY1/HS-PHY1] are combo PHYs of
version1 category has both SS and HS PHYs..
[HS-PHY2] is HS PHY of version2 category.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
2 files changed, 96 insertions(+)
create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
new file mode 100644
index 000..164a1de
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ *Copyright(c) 2018 Broadcom
+ */
+ usb {
+ compatible = "simple-bus";
+ dma-ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x6850 0x0040>;
+
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ usb0_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+ usb0_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ };
+
+ xhci0: usb@1000 {
+ compatible = "generic-xhci";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <_phy0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc0: usb@2000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x2000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <_phy0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-phy";
+ reg = <0x0001 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ usb1_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+ usb1_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-phy-v2";
+ reg = <0x0002 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ xhci1: usb@11000 {
+ compatible = "generic-xhci";
+ reg = <0x00011000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <>, <_phy0>;
+ phy-names = "phy0", "phy1", "phy2";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc1: usb@21000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x00021000 0x1000>;
+ interrupts = ;
+ phys = <>;
+ phy-names = "phy0";
+ dma-coherent;
+ status = "disab
[PATCH v3 3/3] arm64: dts: Add USB DT nodes for Stingray SoC
Add DT nodes for
- Two xHCI host controllers
- Two BDC Broadcom USB device controller
- Five USB PHY controllers
[xHCI0] [BDC0][xHCI1][BDC1]
| | | |
--- ---
| | | | |
[SS-PHY0] [HS-PHY0][SS-PHY1] [HS-PHY2] [HS-PHY1]
[SS-PHY0/HS-PHY0] and [SS-PHY1/HS-PHY1] are combo PHYs of
version1 category has both SS and HS PHYs..
[HS-PHY2] is HS PHY of version2 category.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
.../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++
.../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 +
2 files changed, 96 insertions(+)
create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
new file mode 100644
index 000..164a1de
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: (GPL-2.0 or BSD-3-Clause)
+/*
+ *Copyright(c) 2018 Broadcom
+ */
+ usb {
+ compatible = "simple-bus";
+ dma-ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x6850 0x0040>;
+
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ usb0_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+ usb0_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+
+ };
+
+ xhci0: usb@1000 {
+ compatible = "generic-xhci";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <_phy0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc0: usb@2000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x2000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <_phy0>;
+ phy-names = "phy0", "phy1";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-phy";
+ reg = <0x0001 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ usb1_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+ usb1_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-phy-v2";
+ reg = <0x0002 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
+ xhci1: usb@11000 {
+ compatible = "generic-xhci";
+ reg = <0x00011000 0x1000>;
+ interrupts = ;
+ phys = <_phy1>, <>, <_phy0>;
+ phy-names = "phy0", "phy1", "phy2";
+ dma-coherent;
+ status = "disabled";
+ };
+
+ bdc1: usb@21000 {
+ compatible = "brcm,bdc-v0.16";
+ reg = <0x00021000 0x1000>;
+ interrupts = ;
+ phys = <>;
+ phy-names = "phy0";
+ dma-coherent;
+ status = "disab
[PATCH v3 0/3] Stingray USB PHY driver support
These patches add Stingray USB PHY driver and its corresponding DT nodes with documentation. This patch set is based on Linux-5.0-rc2. Changes from v2: - Addressed Kishon review comments - Updated patchset to Linux-5.0-rc2 Changes from v1: - Addressed Kishon review comments - phy init call return value handle Srinath Mannam (3): dt-bindings: phy: Add Stingray USB PHY binding document phy: sr-usb: Add Stingray USB PHY driver arm64: dts: Add USB DT nodes for Stingray SoC .../bindings/phy/brcm,stingray-usb-phy.txt | 62 .../boot/dts/broadcom/stingray/stingray-usb.dtsi | 95 ++ .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 1 + drivers/phy/broadcom/Kconfig | 11 + drivers/phy/broadcom/Makefile | 1 + drivers/phy/broadcom/phy-bcm-sr-usb.c | 371 + 6 files changed, 541 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-usb.dtsi create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c -- 2.7.4
[PATCH v3 2/3] phy: sr-usb: Add Stingray USB PHY driver
USB PHY driver supports all versions of stingray SS and HS USB PHYs.
- Version 1 is a combo PHY contains both SS and HS PHYs.
- Version 2 is a single HS PHY.
These PHYs support both Generic xHCI host controller driver and BDC
Broadcom device controller driver.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
drivers/phy/broadcom/Kconfig | 11 +
drivers/phy/broadcom/Makefile | 1 +
drivers/phy/broadcom/phy-bcm-sr-usb.c | 371 ++
3 files changed, 383 insertions(+)
create mode 100644 drivers/phy/broadcom/phy-bcm-sr-usb.c
diff --git a/drivers/phy/broadcom/Kconfig b/drivers/phy/broadcom/Kconfig
index aa917a6..f30f481 100644
--- a/drivers/phy/broadcom/Kconfig
+++ b/drivers/phy/broadcom/Kconfig
@@ -10,6 +10,17 @@ config PHY_CYGNUS_PCIE
Enable this to support the Broadcom Cygnus PCIe PHY.
If unsure, say N.
+config PHY_BCM_SR_USB
+ tristate "Broadcom Stingray USB PHY driver"
+ depends on OF && (ARCH_BCM_IPROC || COMPILE_TEST)
+ select GENERIC_PHY
+ default ARCH_BCM_IPROC
+ help
+ Enable this to support the Broadcom Stingray USB PHY
+ driver. It supports all versions of Superspeed and
+ Highspeed PHYs.
+ If unsure, say N.
+
config BCM_KONA_USB2_PHY
tristate "Broadcom Kona USB2 PHY Driver"
depends on HAS_IOMEM
diff --git a/drivers/phy/broadcom/Makefile b/drivers/phy/broadcom/Makefile
index 0f60184..f453c7d 100644
--- a/drivers/phy/broadcom/Makefile
+++ b/drivers/phy/broadcom/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_PHY_BRCM_USB)+= phy-brcm-usb-dvr.o
phy-brcm-usb-dvr-objs := phy-brcm-usb.o phy-brcm-usb-init.o
obj-$(CONFIG_PHY_BCM_SR_PCIE) += phy-bcm-sr-pcie.o
+obj-$(CONFIG_PHY_BCM_SR_USB) += phy-bcm-sr-usb.o
diff --git a/drivers/phy/broadcom/phy-bcm-sr-usb.c
b/drivers/phy/broadcom/phy-bcm-sr-usb.c
new file mode 100644
index 000..abf801d
--- /dev/null
+++ b/drivers/phy/broadcom/phy-bcm-sr-usb.c
@@ -0,0 +1,371 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum bcm_usb_phy_version {
+ BCM_USB_PHY_V1,
+ BCM_USB_PHY_V2,
+};
+
+enum bcm_usb_phy_reg {
+ PLL_NDIV_FRAC,
+ PLL_NDIV_INT,
+ PLL_CTRL,
+ PHY_CTRL,
+ PHY_PLL_CTRL,
+};
+
+/* USB PHY registers */
+
+static const u8 bcm_usb_u3phy_v1[] = {
+ [PLL_CTRL] = 0x18,
+ [PHY_CTRL] = 0x14,
+};
+
+static const u8 bcm_usb_u2phy_v1[] = {
+ [PLL_NDIV_FRAC] = 0x04,
+ [PLL_NDIV_INT] = 0x08,
+ [PLL_CTRL] = 0x0c,
+ [PHY_CTRL] = 0x10,
+};
+
+#define HSPLL_NDIV_INT_VAL 0x13
+#define HSPLL_NDIV_FRAC_VAL0x1005
+
+static const u8 bcm_usb_u2phy_v2[] = {
+ [PLL_NDIV_FRAC] = 0x0,
+ [PLL_NDIV_INT] = 0x4,
+ [PLL_CTRL] = 0x8,
+ [PHY_CTRL] = 0xc,
+};
+
+enum pll_ctrl_bits {
+ PLL_RESETB,
+ SSPLL_SUSPEND_EN,
+ PLL_SEQ_START,
+ PLL_LOCK,
+ PLL_PDIV,
+};
+
+static const u8 u3pll_ctrl[] = {
+ [PLL_RESETB]= 0,
+ [SSPLL_SUSPEND_EN] = 1,
+ [PLL_SEQ_START] = 2,
+ [PLL_LOCK] = 3,
+};
+
+#define HSPLL_PDIV_MASK0xF
+#define HSPLL_PDIV_VAL 0x1
+
+static const u8 u2pll_ctrl[] = {
+ [PLL_PDIV] = 1,
+ [PLL_RESETB]= 5,
+ [PLL_LOCK] = 6,
+};
+
+enum bcm_usb_phy_ctrl_bits {
+ CORERDY,
+ AFE_LDO_PWRDWNB,
+ AFE_PLL_PWRDWNB,
+ AFE_BG_PWRDWNB,
+ PHY_ISO,
+ PHY_RESETB,
+ PHY_PCTL,
+};
+
+#define PHY_PCTL_MASK 0x
+/*
+ * 0x0806 of PCTL_VAL has below bits set
+ * BIT-8 : refclk divider 1
+ * BIT-3:2: device mode; mode is not effect
+ * BIT-1: soft reset active low
+ */
+#define HSPHY_PCTL_VAL 0x0806
+#define SSPHY_PCTL_VAL 0x0006
+
+static const u8 u3phy_ctrl[] = {
+ [PHY_RESETB]= 1,
+ [PHY_PCTL] = 2,
+};
+
+static const u8 u2phy_ctrl[] = {
+ [CORERDY] = 0,
+ [AFE_LDO_PWRDWNB] = 1,
+ [AFE_PLL_PWRDWNB] = 2,
+ [AFE_BG_PWRDWNB]= 3,
+ [PHY_ISO] = 4,
+ [PHY_RESETB]= 5,
+ [PHY_PCTL] = 6,
+};
+
+struct bcm_usb_phy_cfg {
+ uint32_t type;
+ uint32_t ver;
+ void __iomem *regs;
+ struct phy *phy;
+ const u8 *offset;
+};
+
+#define PLL_LOCK_RETRY_COUNT 1000
+
+enum bcm_usb_phy_type {
+ USB_HS_PHY,
+ USB_SS_PHY,
+};
+
+static inline void bcm_usb_reg32_clrbits(void __iomem *addr, uint32_t clear)
+{
+ writel(readl(addr) & ~clear, addr);
+}
+
+static inline void bcm_usb_reg32_setbits(void __iomem *addr, uint32_t set)
+{
+ writel(readl(addr) | set, addr);
+}
+
+static int bcm_usb_pll_lock_check(void __iomem *addr, u32 bit)
+
[PATCH v3 1/3] dt-bindings: phy: Add Stingray USB PHY binding document
Add DT binding document for Stingray USB PHY.
Signed-off-by: Srinath Mannam
Reviewed-by: Florian Fainelli
Reviewed-by: Scott Branden
---
.../bindings/phy/brcm,stingray-usb-phy.txt | 62 ++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
new file mode 100644
index 000..bfe1367
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/brcm,stingray-usb-phy.txt
@@ -0,0 +1,62 @@
+Broadcom Stingray USB PHY
+
+Required properties:
+ - compatible : should be one of the listed compatibles
+ - "brcm,sr-usb-phy"
+ - "brcm,sr-usb-phy-v2"
+ - reg: offset and length of the PHY blocks registers
+ - address-cells: should be 1
+ - size-cells: should be 0
+
+Sub-nodes:
+ Each port's PHY should be represented as a sub-node.
+
+Sub-nodes required properties:
+ - reg: required for brcm,sr-usb-phy model phy.
+ reg value 0 is HS phy and 1 is SS phy.
+ - phy-cells: generic PHY binding; must be 0
+
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+ usbphy0: usb-phy@0 {
+ compatible = "brcm,sr-usb-phy";
+ reg = <0x 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb0_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ usb0_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy1: usb-phy@1 {
+ compatible = "brcm,sr-usb-phy";
+ reg = <0x0001 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb1_phy0: phy@0 {
+ reg = <0>;
+ #phy-cells = <0>;
+ };
+
+ usb1_phy1: phy@1 {
+ reg = <1>;
+ #phy-cells = <0>;
+ };
+ };
+
+ usbphy2: usb-phy@2 {
+ compatible = "brcm,sr-usb-phy-v2";
+ reg = <0x0002 0x100>,
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #phy-cells = <0>;
+ };
--
2.7.4
[PATCH 2/2] drivers: xhci: Add quirk to reset xHCI port PHY
Add a quirk to reset xHCI port PHY on port disconnect event.
Stingray USB HS PHY has an issue, that USB High Speed device detected
at Full Speed after the same port has connected to Full speed device.
This problem can be resolved with that port PHY reset on disconnect.
Signed-off-by: Srinath Mannam
Reviewed-by: Ray Jui
---
drivers/usb/core/hcd.c | 6 ++
drivers/usb/core/phy.c | 21 +
drivers/usb/core/phy.h | 1 +
drivers/usb/host/xhci-plat.c | 3 +++
drivers/usb/host/xhci-ring.c | 9 ++---
drivers/usb/host/xhci.h | 1 +
include/linux/usb/hcd.h | 1 +
7 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 015b126..e2b87a6 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2663,6 +2663,12 @@ int usb_hcd_find_raw_port_number(struct usb_hcd *hcd,
int port1)
return hcd->driver->find_raw_port_number(hcd, port1);
}
+int usb_hcd_phy_port_reset(struct usb_hcd *hcd, int port)
+{
+ return usb_phy_roothub_port_reset(hcd->phy_roothub, port);
+}
+EXPORT_SYMBOL_GPL(usb_hcd_phy_port_reset);
+
static int usb_hcd_request_irqs(struct usb_hcd *hcd,
unsigned int irqnum, unsigned long irqflags)
{
diff --git a/drivers/usb/core/phy.c b/drivers/usb/core/phy.c
index 38b2c77..c64767d 100644
--- a/drivers/usb/core/phy.c
+++ b/drivers/usb/core/phy.c
@@ -162,6 +162,27 @@ void usb_phy_roothub_power_off(struct usb_phy_roothub
*phy_roothub)
}
EXPORT_SYMBOL_GPL(usb_phy_roothub_power_off);
+int usb_phy_roothub_port_reset(struct usb_phy_roothub *phy_roothub, int port)
+{
+ struct usb_phy_roothub *roothub_entry;
+ struct list_head *head;
+ int i = 0;
+
+ if (!phy_roothub)
+ return -EINVAL;
+
+ head = _roothub->list;
+
+ list_for_each_entry(roothub_entry, head, list) {
+ if (i == port)
+ return phy_reset(roothub_entry->phy);
+ i++;
+ }
+
+ return -ENODEV;
+}
+EXPORT_SYMBOL_GPL(usb_phy_roothub_port_reset);
+
int usb_phy_roothub_suspend(struct device *controller_dev,
struct usb_phy_roothub *phy_roothub)
{
diff --git a/drivers/usb/core/phy.h b/drivers/usb/core/phy.h
index 88a3c03..e8be444 100644
--- a/drivers/usb/core/phy.h
+++ b/drivers/usb/core/phy.h
@@ -18,6 +18,7 @@ int usb_phy_roothub_exit(struct usb_phy_roothub *phy_roothub);
int usb_phy_roothub_power_on(struct usb_phy_roothub *phy_roothub);
void usb_phy_roothub_power_off(struct usb_phy_roothub *phy_roothub);
+int usb_phy_roothub_port_reset(struct usb_phy_roothub *phy_roothub, int port);
int usb_phy_roothub_suspend(struct device *controller_dev,
struct usb_phy_roothub *phy_roothub);
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index ef09cb0..5a3b486 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -289,6 +289,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (device_property_read_bool(tmpdev, "quirk-broken-port-ped"))
xhci->quirks |= XHCI_BROKEN_PORT_PED;
+ if (device_property_read_bool(tmpdev, "usb-phy-port-reset"))
+ xhci->quirks |= XHCI_RESET_PHY_ON_DISCONNECT;
+
device_property_read_u32(tmpdev, "imod-interval-ns",
>imod_interval);
}
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 40fa25c..2dc3116 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1685,9 +1685,12 @@ static void handle_port_status(struct xhci_hcd *xhci,
if (hcd->speed < HCD_USB3) {
xhci_test_and_clear_bit(xhci, port, PORT_PLC);
- if ((xhci->quirks & XHCI_RESET_PLL_ON_DISCONNECT) &&
- (portsc & PORT_CSC) && !(portsc & PORT_CONNECT))
- xhci_cavium_reset_phy_quirk(xhci);
+ if ((portsc & PORT_CSC) && !(portsc & PORT_CONNECT)) {
+ if (xhci->quirks & XHCI_RESET_PLL_ON_DISCONNECT)
+ xhci_cavium_reset_phy_quirk(xhci);
+ else if (xhci->quirks & XHCI_RESET_PHY_ON_DISCONNECT)
+ usb_hcd_phy_port_reset(hcd, port_id - 1);
+ }
}
cleanup:
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 652dc36..530c5ff 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1846,6 +1846,7 @@ struct xhci_hcd {
#define XHCI_DEFAULT_PM_RUNTIME_ALLOW BIT_ULL(33)
#define XHCI_RESET_PLL_ON_DISCONNECT BIT_ULL(34)
#define XHCI_SNPS_BROKEN_SUSPENDBIT_ULL(35)
+#define XHCI_RESET_PHY_ON_DISCONNECT BIT_ULL(36)
unsigned intn
[PATCH 1/2] dt-bindings: usb-xhci: Add usb-phy-port-reset property
Add usb-phy-port-reset optional property to set quirk in xhci platform driver which forces USB port PHY reset on port disconnect event. Signed-off-by: Srinath Mannam Reviewed-by: Ray Jui --- Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt index fea8b15..ecbdb15 100644 --- a/Documentation/devicetree/bindings/usb/usb-xhci.txt +++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt @@ -40,6 +40,7 @@ Optional properties: - usb3-lpm-capable: determines if platform is USB3 LPM capable - quirk-broken-port-ped: set if the controller has broken port disable mechanism - imod-interval-ns: default interrupt moderation interval is 5000ns + - usb-phy-port-reset: set this to do USB PORT PHY reset while disconnect - phys : see usb-hcd.txt in the current directory additionally the properties from usb-hcd.txt (in the current directory) are -- 2.7.4
[PATCH 0/2] Reset xHCI port PHY on disconnect
This patch set adds a quirk in xHCI driver to reset PHY of xHCI port on its disconnect event. This patch set is based on Linux-5.0-rc2. Srinath Mannam (2): dt-bindings: usb-xhci: Add usb-phy-port-reset property drivers: xhci: Add quirk to reset xHCI port PHY Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + drivers/usb/core/hcd.c | 6 ++ drivers/usb/core/phy.c | 21 + drivers/usb/core/phy.h | 1 + drivers/usb/host/xhci-plat.c | 3 +++ drivers/usb/host/xhci-ring.c | 9 ++--- drivers/usb/host/xhci.h| 1 + include/linux/usb/hcd.h| 1 + 8 files changed, 40 insertions(+), 3 deletions(-) -- 2.7.4
[PATCH v2 2/2] PCI: iproc: Add PCIe 32bit outbound memory configuration
Add configuration to support IPROC PCIe host controller outbound memory
window mapping with SOC address range inside 4GB boundary, which is 32 bit
AXI address.
Signed-off-by: Srinath Mannam
Signed-off-by: Abhishek Shah
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Reviewed-by: Vikram Prakash
---
drivers/pci/controller/pcie-iproc.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index b882255..080f142 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -955,8 +955,25 @@ static int iproc_pcie_setup_ob(struct iproc_pcie *pcie,
u64 axi_addr,
resource_size_t window_size =
ob_map->window_sizes[size_idx] * SZ_1M;
- if (size < window_size)
- continue;
+ /*
+* Keep iterating until we reach the last window and
+* with the minimal window size at index zero. In this
+* case, we take a compromise by mapping it using the
+* minimum window size that can be supported
+*/
+ if (size < window_size) {
+ if (size_idx > 0 || window_idx > 0)
+ continue;
+
+ /*
+* For the corner case of reaching the minimal
+* window size that can be supported on the
+* last window
+*/
+ axi_addr = ALIGN_DOWN(axi_addr, window_size);
+ pci_addr = ALIGN_DOWN(pci_addr, window_size);
+ size = window_size;
+ }
if (!IS_ALIGNED(axi_addr, window_size) ||
!IS_ALIGNED(pci_addr, window_size)) {
--
2.7.4
[PATCH v2 0/2] Add IPROC PCIe new features
This patch set extends support of new IPROC PCIe host controller features - Add CRS check using controller register status flags - Add 32bit outbound window mapping configuration This patch set is based on Linux-5.0-rc2. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed set order mode patch from patchset. Srinath Mannam (2): PCI: iproc: Add CRS check in config read PCI: iproc: Add PCIe 32bit outbound memory configuration drivers/pci/controller/pcie-iproc.c | 44 + 1 file changed, 40 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH v2 1/2] PCI: iproc: Add CRS check in config read
In the current implementation, config read output data 0x0001 is
assumed as CRS completion. But sometimes 0x0001 can be a valid data.
IPROC PCIe host controller has a register to show config read request
status flags like SC, UR, CRS and CA. So that extra check is added to
confirm the CRS using status flags before reissue config read.
Signed-off-by: Srinath Mannam
Reviewed-by: Ray Jui
---
drivers/pci/controller/pcie-iproc.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index c20fd6b..b882255 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -60,6 +60,10 @@
#define APB_ERR_EN_SHIFT 0
#define APB_ERR_EN BIT(APB_ERR_EN_SHIFT)
+#define CFG_RD_SUCCESS 0
+#define CFG_RD_UR 1
+#define CFG_RD_CRS 2
+#define CFG_RD_CA 3
#define CFG_RETRY_STATUS 0x0001
#define CFG_RETRY_STATUS_TIMEOUT_US50 /* 500 milliseconds */
@@ -289,6 +293,9 @@ enum iproc_pcie_reg {
IPROC_PCIE_IARR4,
IPROC_PCIE_IMAP4,
+ /* config read status */
+ IPROC_PCIE_CFG_RD_STATUS,
+
/* link status */
IPROC_PCIE_LINK_STATUS,
@@ -350,6 +357,7 @@ static const u16 iproc_pcie_reg_paxb_v2[] = {
[IPROC_PCIE_IMAP3] = 0xe08,
[IPROC_PCIE_IARR4] = 0xe68,
[IPROC_PCIE_IMAP4] = 0xe70,
+ [IPROC_PCIE_CFG_RD_STATUS] = 0xee0,
[IPROC_PCIE_LINK_STATUS]= 0xf0c,
[IPROC_PCIE_APB_ERR_EN] = 0xf40,
};
@@ -474,10 +482,12 @@ static void __iomem *iproc_pcie_map_ep_cfg_reg(struct
iproc_pcie *pcie,
return (pcie->base + offset);
}
-static unsigned int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+static unsigned int iproc_pcie_cfg_retry(struct iproc_pcie *pcie,
+void __iomem *cfg_data_p)
{
int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
unsigned int data;
+ u32 status;
/*
* As per PCIe spec r3.1, sec 2.3.2, CRS Software Visibility only
@@ -498,6 +508,15 @@ static unsigned int iproc_pcie_cfg_retry(void __iomem
*cfg_data_p)
*/
data = readl(cfg_data_p);
while (data == CFG_RETRY_STATUS && timeout--) {
+ /*
+* CRS state is set in CFG_RD status register
+* This will handle the case where CFG_RETRY_STATUS is
+* valid config data.
+*/
+ status = iproc_pcie_read_reg(pcie, IPROC_PCIE_CFG_RD_STATUS);
+ if (status != CFG_RD_CRS)
+ return data;
+
udelay(1);
data = readl(cfg_data_p);
}
@@ -576,7 +595,7 @@ static int iproc_pcie_config_read(struct pci_bus *bus,
unsigned int devfn,
if (!cfg_data_p)
return PCIBIOS_DEVICE_NOT_FOUND;
- data = iproc_pcie_cfg_retry(cfg_data_p);
+ data = iproc_pcie_cfg_retry(pcie, cfg_data_p);
*val = data;
if (size <= 2)
--
2.7.4
[PATCH v2 0/2] Add IPROC PCIe new features
This patch set extends support of new IPROC PCIe host controller features - Add CRS state check using controller register status flags - Add 32bit outbound window mapping configuration This patch set is based on Linux-5.0-rc2. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed set order mode patch from patchset. Srinath Mannam (2): PCI: iproc: Add CRS state check in config read PCI: iproc: Add PCIe 32bit outbound memory configuration drivers/pci/controller/pcie-iproc.c | 44 + 1 file changed, 40 insertions(+), 4 deletions(-) -- 2.7.4
[PATCH v3 2/3] iommu/dma: Reserve IOVA for PCI host reserve address list
PCI host bridge has list of resource entries contain address ranges for
which IOVA address mapping has to be reserve. These address ranges are
the address holes in dma-ranges DT property.
It is similar to PCI IO resources address ranges reserving in IOMMU for
each EP connected to host bridge.
Signed-off-by: Srinath Mannam
Based-on-patch-by: Oza Pawandeep
Reviewed-by: Oza Pawandeep
---
drivers/iommu/dma-iommu.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d19f3d6..81b591b 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -221,6 +221,14 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
hi = iova_pfn(iovad, window->res->end - window->offset);
reserve_iova(iovad, lo, hi);
}
+
+ /* Get reserved DMA windows from host bridge */
+ resource_list_for_each_entry(window, >dma_resv) {
+
+ lo = iova_pfn(iovad, window->res->start - window->offset);
+ hi = iova_pfn(iovad, window->res->end - window->offset);
+ reserve_iova(iovad, lo, hi);
+ }
}
static int iova_reserve_iommu_regions(struct device *dev,
--
2.7.4
[PATCH v3 0/3] PCIe Host request to reserve IOVA
Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those SOCs has to list all address ranges which have to reserve their IOVA address into PCIe host bridge resource entry list. IOMMU framework will reserve these IOVAs while initializing IOMMU domain. This patch set is based on Linux-5.0-rc2. Changes from v2: - Patch set rebased to Linux-5.0-rc2 Changes from v1: - Addressed Oza review comments. Srinath Mannam (3): PCI: Add dma-resv window list iommu/dma: Reserve IOVA for PCI host reserve address list PCI: iproc: Add dma reserve resources to host drivers/iommu/dma-iommu.c | 8 ++ drivers/pci/controller/pcie-iproc.c | 51 - drivers/pci/probe.c | 3 +++ include/linux/pci.h | 1 + 4 files changed, 62 insertions(+), 1 deletion(-) -- 2.7.4
[PATCH v3 1/3] PCI: Add dma-resv window list
Add a dma_resv parameter in PCI host bridge structure to hold resource
entries list of memory regions for which IOVAs have to reserve.
PCIe host driver will add resource entries to this list based on its
requirements. Few inbound address ranges can't be allowed by few PCIe host,
so those address ranges will be add to this list to avoid IOMMU mapping.
While initializing IOMMU domain of PCI EPs connected to that host bridge
IOVAs for this given list of address ranges will be reserved.
Signed-off-by: Srinath Mannam
Based-on-patch-by: Oza Pawandeep
Reviewed-by: Oza Pawandeep
---
drivers/pci/probe.c | 3 +++
include/linux/pci.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 257b9f6..fd4b143 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -544,6 +544,7 @@ struct pci_host_bridge *pci_alloc_host_bridge(size_t priv)
return NULL;
INIT_LIST_HEAD(>windows);
+ INIT_LIST_HEAD(>dma_resv);
bridge->dev.release = pci_release_host_bridge_dev;
/*
@@ -572,6 +573,7 @@ struct pci_host_bridge *devm_pci_alloc_host_bridge(struct
device *dev,
return NULL;
INIT_LIST_HEAD(>windows);
+ INIT_LIST_HEAD(>dma_resv);
bridge->dev.release = devm_pci_release_host_bridge_dev;
return bridge;
@@ -581,6 +583,7 @@ EXPORT_SYMBOL(devm_pci_alloc_host_bridge);
void pci_free_host_bridge(struct pci_host_bridge *bridge)
{
pci_free_resource_list(>windows);
+ pci_free_resource_list(>dma_resv);
kfree(bridge);
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 65f1d8c..aa06105 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -487,6 +487,7 @@ struct pci_host_bridge {
void*sysdata;
int busnr;
struct list_head windows; /* resource_entry */
+ struct list_head dma_resv; /* reserv dma ranges */
u8 (*swizzle_irq)(struct pci_dev *, u8 *); /* Platform IRQ swizzler */
int (*map_irq)(const struct pci_dev *, u8, u8);
void (*release_fn)(struct pci_host_bridge *);
--
2.7.4
[PATCH v3 3/3] PCI: iproc: Add dma reserve resources to host
IPROC host has the limitation that it can use only those address ranges
given by dma-ranges property as inbound address. So that the memory
address holes in dma-ranges should be reserved to allocate as DMA address.
Inbound address of host accessed by PCIe devices will not be translated
before it comes to IOMMU or directly to PE. But the limitation of this
host is, access to few address ranges are ignored. So that IOVA ranges
for these address ranges have to be reserved.
All such addresses ranges are created as resource entries by parsing
dma-ranges DT parameter and add to dma_resv list of PCI host bridge.
Ex:
dma-ranges = < \
0x4300 0x00 0x8000 0x00 0x8000 0x00 0x8000 \
0x4300 0x08 0x 0x08 0x 0x08 0x \
0x4300 0x80 0x 0x80 0x 0x40 0x>
In the above example of dma-ranges, memory address from
0x0 - 0x8000,
0x1 - 0x8,
0x10 - 0x80 and
0x100 - 0x.
are not allowed to use as inbound addresses.
So that we need to add these address ranges to dma_resv list to reserve
corresponding IOVA address ranges.
Signed-off-by: Srinath Mannam
Based-on-patch-by: Oza Pawandeep
Reviewed-by: Oza Pawandeep
---
drivers/pci/controller/pcie-iproc.c | 51 -
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-iproc.c
b/drivers/pci/controller/pcie-iproc.c
index c20fd6b..b7bef1c 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1146,25 +1146,74 @@ static int iproc_pcie_setup_ib(struct iproc_pcie *pcie,
return ret;
}
+static int
+iproc_pcie_add_dma_resv_range(struct device *dev, struct list_head *resources,
+ uint64_t start, uint64_t end)
+{
+ struct resource *res;
+
+ res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL);
+ if (!res)
+ return -ENOMEM;
+
+ res->start = (resource_size_t)start;
+ res->end = (resource_size_t)end;
+ pci_add_resource_offset(resources, res, 0);
+
+ return 0;
+}
+
static int iproc_pcie_map_dma_ranges(struct iproc_pcie *pcie)
{
+ struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
struct of_pci_range range;
struct of_pci_range_parser parser;
int ret;
+ uint64_t start, end;
+ LIST_HEAD(resources);
/* Get the dma-ranges from DT */
ret = of_pci_dma_range_parser_init(, pcie->dev->of_node);
if (ret)
return ret;
+ start = 0;
for_each_of_pci_range(, ) {
+ end = range.pci_addr;
+ /* dma-ranges list expected in sorted order */
+ if (end < start) {
+ ret = -EINVAL;
+ goto out;
+ }
/* Each range entry corresponds to an inbound mapping region */
ret = iproc_pcie_setup_ib(pcie, , IPROC_PCIE_IB_MAP_MEM);
if (ret)
- return ret;
+ goto out;
+
+ if (end - start) {
+ ret = iproc_pcie_add_dma_resv_range(pcie->dev,
+ ,
+ start, end);
+ if (ret)
+ goto out;
+ }
+ start = range.pci_addr + range.size;
}
+ end = DMA_BIT_MASK(sizeof(dma_addr_t) * BITS_PER_BYTE);
+ if (end - start) {
+ ret = iproc_pcie_add_dma_resv_range(pcie->dev, ,
+ start, end);
+ if (ret)
+ goto out;
+ }
+
+ list_splice_init(, >dma_resv);
+
return 0;
+out:
+ pci_free_resource_list();
+ return ret;
}
static int iproce_pcie_get_msi(struct iproc_pcie *pcie,
--
2.7.4
Re: [PATCH 1/3] PCI: iproc: Add feature to set order mode
Hi Bjorn, Thank you, Please see my comments below inline. On Fri, Jan 25, 2019 at 1:01 AM Bjorn Helgaas wrote: > > On Thu, Jan 24, 2019 at 02:10:18PM +0530, Srinath Mannam wrote: > > On Fri, Jan 18, 2019 at 8:37 PM Bjorn Helgaas wrote: > > > On Fri, Jan 18, 2019 at 09:53:21AM +0530, Srinath Mannam wrote: > > > > Order mode in RX header of incoming pcie packets can be override to > > > > strict or loose order based on requirement. > > > > Sysfs entry is provided to set dynamic and default order modes of > > > > upstream > > > > traffic. > > > ... > > > Are you talking about the Relaxed Ordering bit in the TLP Attributes > > > field? If so, please use the exact language used in the spec and > > > include a reference, e.g., to PCIe r4.0, sec 2.2.6.4, 2.4, etc. > > > > > Yes Relax ordering bit in TLP. I will use spec reference. Thanks. > > > I'm hesitant about a new sysfs file for this. That automatically > > > creates a user-space dependency on this iProc feature. Who would use > > > this file? > > > > > This is the specific feature given in iProc, used to improve > > performance for the endpoints which does not support > > ordering configuration at its end. > > This is the reason we used sysfs file, which allows user to change > > ordering based on endpoint used and requirement. > > we are using these sysfs files to configure ordering to improve > > performance in NVMe endpoints with SPDK/DPDK drivers. > > If we enable this default in kernel, then it is applicable to all > > endpoints connected. But it may not required for all endpoints. > > Normally, relaxed ordering is used only when an endpoint sets the > "Relaxed Ordering" attribute bit in a TLP. The endpoint is only > allowed to do that if relaxed ordering is enabled in the Device > Control register. Yes, endpoint has to set RO attribute in up-streaming TLPs. But in most of NVMe SSDs even Relax ordering bit in device controller register is set, still it send TLPs with RO attribute disable (strict order). > > If I understand correctly, this sysfs knob would let you configure the > iProc RC so it handles *all* TLPs (or just those in certain address > ranges) with relaxed ordering, regardless of whether the endpoint has > relaxed ordering, or even whether it supports relaxed ordering at all. Yes, iProc can enable/disable RO attribute in given address range regardless of endpoint settings. > > My gut feeling is that this is a messy hack, and if you want the > performance benefits of relaxed ordering, you should just choose an > NVMe endpoint that supports it correctly. Most of the NVMe endpoints available in market are sending TLPs in strict order even Relax ordering bit in device controller register is set. This is the reason to add this dynamic ordering feature in iProc IP. > > I assume the iProc RC does actually have the smarts to pay attention > to the Relaxed Ordering bit in TLPs if the endpoint sets it? Yes, iProc IP scan all TLPs and modify RO attributes as requested. if suppose endpoint set RO attribute in TLP, but user need it as strict order then iProc disable it. > > > > > To improve performance in few endpoints we required to modify the > > > > ordering attributes. Using this feature we can override order modes of > > > > RX > > > > packets at IPROC RC. > > > > > > > > Ex: > > > > In PCIe based NVMe SSD endpoints data read/writes from disk is using > > > > Queue pairs (submit/completion). After completion of block read/write, > > > > EP writes completion command to completion queue to notify RC. > > > > So that all data transfers before completion command write are not > > > > required to strict order except completion command. It means previous > > > > all > > > > packets before completion command write to RC should be written to > > > > memory > > > > and acknowledged. > > > > > > IIUC, if Enable Relaxed Ordering in the endpoint's Device Control > > > register is set, the device is permitted to set the Relaxed Ordering > > > bit in TLPs it initiates. So I would think that if we set Enable > > > Relaxed Ordering correctly, the NVMe endpoint should be able to > > > use Relaxed Ordering for the data transfers and strict ordering (the > > > default) for the completion command. What am I missing? > > > > > As per NVMe spec Enable Relaxed ordering is implementation specific all > > cards > > may not support. > > Relaxed ordering support is optional for *every* PCIe endpoint, not
