[PATCH v3] powerpc: fsl_pci: Add forced PCI Agent enumeration

2014-08-26 Thread Aaron Sierra 
The following commit prevents the MPC8548E on the XPedite5200 PrPMC
module from enumerating its PCI/PCI-X bus:

powerpc/fsl-pci: use 'Header Type' to identify PCIE mode

The previous patch prevents any Freescale PCI-X bridge from enumerating
the bus, if it is hardware strapped into Agent mode.

In PCI-X, the Host is responsible for driving the PCI-X initialization
pattern to devices on the bus, so that they know whether to operate in
conventional PCI or PCI-X mode as well as what the bus timing will be.
For a PCI-X PrPMC, the pattern is driven by the mezzanine carrier it is
installed onto. Therefore, PrPMCs are PCI-X Agents, but one per system
may still enumerate the bus.

This patch causes the device node of any PCI/PCI-X bridge strapped into
Agent mode to be checked for the fsl,pci-agent-force-enum property. If
the property is present in the node, the bridge will be allowed to
enumerate the bus.

Cc: Minghuan Lian 
Signed-off-by: Aaron Sierra 
---
 Documentation/devicetree/bindings/pci/fsl,pci.txt | 27 +++
 arch/powerpc/sysdev/fsl_pci.c |  3 ++-
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/pci/fsl,pci.txt

diff --git a/Documentation/devicetree/bindings/pci/fsl,pci.txt 
b/Documentation/devicetree/bindings/pci/fsl,pci.txt
new file mode 100644
index 000..d8ac4a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,pci.txt
@@ -0,0 +1,27 @@
+* Bus Enumeration by Freescale PCI-X Agent
+
+Typically any Freescale PCI-X bridge hardware strapped into Agent mode
+is prevented from enumerating the bus. The PrPMC form-factor requires
+all mezzanines to be PCI-X Agents, but one per system may still
+enumerate the bus.
+
+The property defined below will allow a PCI-X bridge to be used for bus
+enumeration despite being strapped into Agent mode.
+
+Required properties:
+- fsl,pci-agent-force-enum : There is no value associated with this
+  property. The property itself is treated as a boolean.
+
+Example:
+
+   /* PCI-X bridge known to be PrPMC Monarch */
+   pci0: pci@ef008000 {
+   fsl,pci-agent-force-enum;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
+   device_type = "pci";
+   ...
+   ...
+   };
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4bd091a..d13663f 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -522,7 +522,8 @@ int fsl_add_bridge(struct platform_device *pdev, int 
is_primary)
} else {
/* For PCI read PROG to identify controller mode */
early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
-   if ((progif & 1) == 1)
+   if ((progif & 1) &&
+   !of_property_read_bool(dev, "fsl,pci-agent-force-enum"))
goto no_bridge;
}
 
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] fsl_ifc: Support all 8 IFC chip selects

2014-08-26 Thread Aaron Sierra 
- Original Message -
> From: "Scott Wood" 
> Sent: Tuesday, August 26, 2014 3:48:51 PM
> 
> On Tue, 2014-08-26 at 12:31 -0500, Aaron Sierra wrote:
> > Freescale's QorIQ T Series processors support 8 IFC chip selects
> > within a memory map backward compatible with previous P Series
> > processors which supported only 4 chip selects.
> > 
> > Signed-off-by: Aaron Sierra 
> > ---
> >  drivers/memory/fsl_ifc.c|  2 +-
> >  drivers/mtd/nand/fsl_ifc_nand.c | 17 ++---
> >  include/linux/fsl_ifc.h | 34 +-
> >  3 files changed, 36 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
> > index 3d5d792..a539dc2 100644
> > --- a/drivers/memory/fsl_ifc.c
> > +++ b/drivers/memory/fsl_ifc.c
> > @@ -61,7 +61,7 @@ int fsl_ifc_find(phys_addr_t addr_base)
> > if (!fsl_ifc_ctrl_dev || !fsl_ifc_ctrl_dev->regs)
> > return -ENODEV;
> >  
> > -   for (i = 0; i < ARRAY_SIZE(fsl_ifc_ctrl_dev->regs->cspr_cs); i++) {
> > +   for (i = 0; i < fsl_ifc_bank_count(fsl_ifc_ctrl_dev->regs); i++) {
> > u32 cspr = in_be32(&fsl_ifc_ctrl_dev->regs->cspr_cs[i].cspr);
> > if (cspr & CSPR_V && (cspr & CSPR_BA) ==
> > convert_ifc_address(addr_base))
> > diff --git a/drivers/mtd/nand/fsl_ifc_nand.c
> > b/drivers/mtd/nand/fsl_ifc_nand.c
> > index 2338124..f7b7077 100644
> > --- a/drivers/mtd/nand/fsl_ifc_nand.c
> > +++ b/drivers/mtd/nand/fsl_ifc_nand.c
> > @@ -31,7 +31,6 @@
> >  #include 
> >  #include 
> >  
> > -#define FSL_IFC_V1_1_0 0x0101
> >  #define ERR_BYTE   0xFF /* Value returned for read
> > bytes when read failed  */
> >  #define IFC_TIMEOUT_MSECS  500  /* Maximum number of mSecs to wait
> > @@ -54,7 +53,7 @@ struct fsl_ifc_mtd {
> >  /* overview of the fsl ifc controller */
> >  struct fsl_ifc_nand_ctrl {
> > struct nand_hw_control controller;
> > -   struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT];
> > +   struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT_MAX];
> 
> FSL_IFC_MAX_BANKS would be more concise.  I'm not sure we really need to
> rename this, though.

I renamed it to be sure that I found all of the places it was used and I
wanted to make clear that the FSL_IFC_BANK_COUNT doesn't refer to the
implemented number of banks. I agree that with the comment immediately above
the definition, renaming the define is redundant.

> > @@ -834,5 +843,12 @@ struct fsl_ifc_ctrl {
> >  
> >  extern struct fsl_ifc_ctrl *fsl_ifc_ctrl_dev;
> >  
> > +static inline u32 fsl_ifc_version(struct fsl_ifc_regs *regs) {
> > +   return ioread32be(®s->ifc_rev) & FSL_IFC_VERSION_MASK;
> > +}
> > +
> > +static inline int fsl_ifc_bank_count(struct fsl_ifc_regs *regs) {
> > +   return (fsl_ifc_version(regs) == FSL_IFC_VERSION_1_0_0) ? 4 : 8;
> > +}
> 
> Whitespace

Oops.

> Do we really need the bank count here, as opposed to just checking it in
> probe()?  I also don't really care for reading the registers over and
> over, even though it's not performance critical.

The bank count is used in fsl_ifc_nand.c and fsl_ifc.c, so I thought it
was a good idea to have the version to bank count mapping defined in one
place rather than two.

> The reserved bits of the version register are defined as zero for
> current versions -- I think just comparing ifc_rev to the version
> constant, as is currently done, is fine.

I wasn't sure because the manuals I have only say that reserved values
are zero at reset.

> Also, please send the patch to the mtd list and maintainer.

Ok.

-Aaron
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] powerpc: fsl_pci: Add forced PCI Agent enumeration

2014-08-26 Thread Aaron Sierra 
- Original Message -
> From: "Scott Wood" 
> Sent: Tuesday, August 26, 2014 3:52:56 PM
> 
> On Mon, 2014-08-25 at 18:54 -0500, Aaron Sierra wrote:
> > The following commit prevents the MPC8548E on the XPedite5200 PrPMC
> > module from enumerating its PCI/PCI-X bus:
> > 
> > powerpc/fsl-pci: use 'Header Type' to identify PCIE mode
> > 
> > The previous patch prevents any Freescale PCI-X bridge from enumerating
> > the bus, if it is hardware strapped into Agent mode.
> > 
> > In PCI-X, the Host is responsible for driving the PCI-X initialization
> > pattern to devices on the bus, so that they know whether to operate in
> > conventional PCI or PCI-X mode as well as what the bus timing will be.
> > For a PCI-X PrPMC, the pattern is driven by the mezzanine carrier it is
> > installed onto. Therefore, PrPMCs are PCI-X Agents, but one per system
> > may still enumerate the bus.
> > 
> > This patch causes the device node of any PCI/PCI-X bridge strapped into
> > Agent mode to be checked for the fsl,pci-agent-force-enum property. If
> > the property is present in the node, the bridge will be allowed to
> > enumerate the bus.
> > 
> > Cc: Minghuan Lian 
> > Signed-off-by: Aaron Sierra 
> > ---
> >  .../bindings/pci/fsl,pci-agent-force-enum.txt  | 27
> >  ++
> >  arch/powerpc/sysdev/fsl_pci.c  |  3 ++-
> >  2 files changed, 29 insertions(+), 1 deletion(-)
> >  create mode 100644
> >  Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt
> > 
> > diff --git
> > a/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt
> > b/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt
> > new file mode 100644
> > index 000..d8ac4a7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt
> 
> This ought to be part of a general fsl,pci binding, rather than its own
> file.  Unfortunately there isn't such a binding yet, but let's call this
> something like "fsl,pci.txt" anyway so that there's a place to add the
> rest of the binding to.

Ok, no problem.
 
> Also, CC devicet...@vger.kernel.org on all device tree patches.

Will do.

> Otherwise it looks OK.
> 
> -Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] fsl_ifc: Support all 8 IFC chip selects

2014-08-26 Thread Aaron Sierra 
Freescale's QorIQ T Series processors support 8 IFC chip selects
within a memory map backward compatible with previous P Series
processors which supported only 4 chip selects.

Signed-off-by: Aaron Sierra 
---
 drivers/memory/fsl_ifc.c|  2 +-
 drivers/mtd/nand/fsl_ifc_nand.c | 17 ++---
 include/linux/fsl_ifc.h | 34 +-
 3 files changed, 36 insertions(+), 17 deletions(-)

diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index 3d5d792..a539dc2 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -61,7 +61,7 @@ int fsl_ifc_find(phys_addr_t addr_base)
if (!fsl_ifc_ctrl_dev || !fsl_ifc_ctrl_dev->regs)
return -ENODEV;
 
-   for (i = 0; i < ARRAY_SIZE(fsl_ifc_ctrl_dev->regs->cspr_cs); i++) {
+   for (i = 0; i < fsl_ifc_bank_count(fsl_ifc_ctrl_dev->regs); i++) {
u32 cspr = in_be32(&fsl_ifc_ctrl_dev->regs->cspr_cs[i].cspr);
if (cspr & CSPR_V && (cspr & CSPR_BA) ==
convert_ifc_address(addr_base))
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 2338124..f7b7077 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 
-#define FSL_IFC_V1_1_0 0x0101
 #define ERR_BYTE   0xFF /* Value returned for read
bytes when read failed  */
 #define IFC_TIMEOUT_MSECS  500  /* Maximum number of mSecs to wait
@@ -54,7 +53,7 @@ struct fsl_ifc_mtd {
 /* overview of the fsl ifc controller */
 struct fsl_ifc_nand_ctrl {
struct nand_hw_control controller;
-   struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT];
+   struct fsl_ifc_mtd *chips[FSL_IFC_BANK_COUNT_MAX];
 
void __iomem *addr; /* Address of assigned IFC buffer   */
unsigned int page;  /* Last page written to / read from */
@@ -877,7 +876,7 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
struct fsl_ifc_regs __iomem *ifc = ctrl->regs;
struct nand_chip *chip = &priv->chip;
struct nand_ecclayout *layout;
-   u32 csor, ver;
+   u32 csor;
 
/* Fill in fsl_ifc_mtd structure */
priv->mtd.priv = chip;
@@ -984,8 +983,7 @@ static int fsl_ifc_chip_init(struct fsl_ifc_mtd *priv)
chip->ecc.mode = NAND_ECC_SOFT;
}
 
-   ver = ioread32be(&ifc->ifc_rev);
-   if (ver == FSL_IFC_V1_1_0)
+   if (fsl_ifc_version(ifc) == FSL_IFC_VERSION_1_1_0)
fsl_ifc_sram_init(priv);
 
return 0;
@@ -1044,13 +1042,18 @@ static int fsl_ifc_nand_probe(struct platform_device 
*dev)
return ret;
}
 
+   dev_info(&dev->dev, "IFC version %d.%d, %d banks\n",
+   fsl_ifc_version(ifc) >> 24,
+   (fsl_ifc_version(ifc) >> 16) & 0xf,
+   fsl_ifc_bank_count(ifc));
+
/* find which chip select it is connected to */
-   for (bank = 0; bank < FSL_IFC_BANK_COUNT; bank++) {
+   for (bank = 0; bank < fsl_ifc_bank_count(ifc); bank++) {
if (match_bank(ifc, bank, res.start))
break;
}
 
-   if (bank >= FSL_IFC_BANK_COUNT) {
+   if (bank >= fsl_ifc_bank_count(ifc)) {
dev_err(&dev->dev, "%s: address did not match any chip 
selects\n",
__func__);
return -ENODEV;
diff --git a/include/linux/fsl_ifc.h b/include/linux/fsl_ifc.h
index 84d60cb..7a92773 100644
--- a/include/linux/fsl_ifc.h
+++ b/include/linux/fsl_ifc.h
@@ -29,7 +29,16 @@
 #include 
 #include 
 
-#define FSL_IFC_BANK_COUNT 4
+/*
+ * The actual number of banks implemented depends on the IFC version
+ *- IFC version 1.0 implements 4 banks.
+ *- IFC version 1.1 onward implements 8 banks.
+ */
+#define FSL_IFC_BANK_COUNT_MAX 8
+
+#define FSL_IFC_VERSION_MASK   0x0F0F
+#define FSL_IFC_VERSION_1_0_0  0x0100
+#define FSL_IFC_VERSION_1_1_0  0x0101
 
 /*
  * CSPR - Chip Select Property Register
@@ -775,24 +784,24 @@ struct fsl_ifc_regs {
__be32 cspr_ext;
__be32 cspr;
u32 res2;
-   } cspr_cs[FSL_IFC_BANK_COUNT];
-   u32 res3[0x19];
+   } cspr_cs[FSL_IFC_BANK_COUNT_MAX];
+   u32 res3[0xd];
struct {
__be32 amask;
u32 res4[0x2];
-   } amask_cs[FSL_IFC_BANK_COUNT];
-   u32 res5[0x18];
+   } amask_cs[FSL_IFC_BANK_COUNT_MAX];
+   u32 res5[0xc];
struct {
__be32 csor;
__be32 csor_ext;
u32 res6;
-   } csor_cs[FSL_IFC_BANK_COUNT];
-   u32 res7[0x18];
+   } csor_cs[FSL_IFC_BANK_COUNT_MAX];
+   u32 res7[0xc];
struct {
__be32 ftim[4];

[PATCH v2] powerpc: fsl_pci: Add forced PCI Agent enumeration

2014-08-25 Thread Aaron Sierra 
The following commit prevents the MPC8548E on the XPedite5200 PrPMC
module from enumerating its PCI/PCI-X bus:

powerpc/fsl-pci: use 'Header Type' to identify PCIE mode

The previous patch prevents any Freescale PCI-X bridge from enumerating
the bus, if it is hardware strapped into Agent mode.

In PCI-X, the Host is responsible for driving the PCI-X initialization
pattern to devices on the bus, so that they know whether to operate in
conventional PCI or PCI-X mode as well as what the bus timing will be.
For a PCI-X PrPMC, the pattern is driven by the mezzanine carrier it is
installed onto. Therefore, PrPMCs are PCI-X Agents, but one per system
may still enumerate the bus.

This patch causes the device node of any PCI/PCI-X bridge strapped into
Agent mode to be checked for the fsl,pci-agent-force-enum property. If
the property is present in the node, the bridge will be allowed to
enumerate the bus.

Cc: Minghuan Lian 
Signed-off-by: Aaron Sierra 
---
 .../bindings/pci/fsl,pci-agent-force-enum.txt  | 27 ++
 arch/powerpc/sysdev/fsl_pci.c  |  3 ++-
 2 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt

diff --git a/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt 
b/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt
new file mode 100644
index 000..d8ac4a7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,pci-agent-force-enum.txt
@@ -0,0 +1,27 @@
+* Bus Enumeration by Freescale PCI-X Agent
+
+Typically any Freescale PCI-X bridge hardware strapped into Agent mode
+is prevented from enumerating the bus. The PrPMC form-factor requires
+all mezzanines to be PCI-X Agents, but one per system may still
+enumerate the bus.
+
+The property defined below will allow a PCI-X bridge to be used for bus
+enumeration despite being strapped into Agent mode.
+
+Required properties:
+- fsl,pci-agent-force-enum : There is no value associated with this
+  property. The property itself is treated as a boolean.
+
+Example:
+
+   /* PCI-X bridge known to be PrPMC Monarch */
+   pci0: pci@ef008000 {
+   fsl,pci-agent-force-enum;
+   #interrupt-cells = <1>;
+   #size-cells = <2>;
+   #address-cells = <3>;
+   compatible = "fsl,mpc8540-pcix", "fsl,mpc8540-pci";
+   device_type = "pci";
+   ...
+   ...
+   };
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4bd091a..d13663f 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -522,7 +522,8 @@ int fsl_add_bridge(struct platform_device *pdev, int 
is_primary)
} else {
/* For PCI read PROG to identify controller mode */
early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
-   if ((progif & 1) == 1)
+   if ((progif & 1) &&
+   !of_property_read_bool(dev, "fsl,pci-agent-force-enum"))
goto no_bridge;
}
 
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: fsl_pci: Fix PCI/PCI-X regression

2014-08-22 Thread Aaron Sierra 

- Original Message -
> From: "Scott Wood" 
> To: "Aaron Sierra" 
> Cc: linuxppc-dev@lists.ozlabs.org, "Minghuan Lian" 
> 
> Sent: Friday, August 22, 2014 1:36:31 PM
> Subject: Re: [PATCH] powerpc: fsl_pci: Fix PCI/PCI-X regression
> 
> On Fri, 2014-08-22 at 12:54 -0500, Aaron Sierra wrote:
> > - Original Message -
> > > From: "Scott Wood" 
> > > Sent: Thursday, August 21, 2014 5:01:46 PM
> > > 
> > > On Thu, 2014-08-21 at 16:54 -0500, Aaron Sierra wrote:
> > > > - Original Message -
> > > > > From: "Scott Wood" 
> > > > > Sent: Thursday, August 21, 2014 4:19:56 PM
> > > > > 
> > > > > Why wouldn't a normal PCI agent be able to bus master?
> > > > > 
> > > > > -Scott
> > > > > 
> > > > 
> > > > Short answer:
> > > > 
> > > > Simply because the hardware strapping for Host/Agent determines the
> > > > default state of the Bus Master bit in the Command register. Without
> > > > that bit being set, an Agent won't be able to send the PCI cycles
> > > > necessary to enumerate the bus.
> > > 
> > > But what if the host has already set that bit before Linux boots?
> > 
> > That's a very good point. I think that concern can be addressed by looking
> > for another telltale sign of enumeration, whether an address has been
> > assigned to the bridge's BAR 0 (PCSRBAR).
> 
> I don't see how that's any different.  The host may or may not have
> assigned an address.

I don't agree with that. If the host has enabled bus mastering for the
device, then it also surely would also have assigned an address to the
always on PCSRBAR during enumeration.

In what sort of environment would a host have enabled bus mastering for
a peripheral device _before_ assigning addresses to its BARs?

> > > I understand why you need to do this -- I just don't think this is a
> > > reliable way of detecting that you're in that situation.  How about a
> > > kernel command line setting?
> > 
> > I'd like to avoid requiring a kernel command-line option for this.
> 
> It's hardware description, so you could use a device tree property.
> 

I like this better than a command-line option, but what are you
suggesting? Would you want a device-tree property to gate the logic that
I've proposed?

-Aaron
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: fsl_pci: Fix PCI/PCI-X regression

2014-08-22 Thread Aaron Sierra 
- Original Message -
> From: "Scott Wood" 
> Sent: Thursday, August 21, 2014 5:01:46 PM
> 
> On Thu, 2014-08-21 at 16:54 -0500, Aaron Sierra wrote:
> > - Original Message -
> > > From: "Scott Wood" 
> > > Sent: Thursday, August 21, 2014 4:19:56 PM
> > > 
> > > On Wed, 2014-08-20 at 18:51 -0500, Aaron Sierra wrote:
> > > > @@ -520,9 +520,22 @@ int fsl_add_bridge(struct platform_device *pdev,
> > > > int
> > > > is_primary)
> > > > goto no_bridge;
> > > >  
> > > > } else {
> > > > -   /* For PCI read PROG to identify controller mode */
> > > > -   early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, 
> > > > &progif);
> > > > -   if ((progif & 1) == 1)
> > > > +   u16 master;
> > > > +
> > > > +   /*
> > > > +* If the controller is PCI-X, then Host mode refers to 
> > > > a
> > > > +* bridge that drives the PCI-X initialization pattern 
> > > > to
> > > > +* indicate bus operating mode/frequency to devices on 
> > > > the bus.
> > > > +* Some hardware (specifically PrPMC modules) are 
> > > > Agents, since
> > > > +* the mezzanine carrier is responsible for driving the
> > > > +* pattern, but they still may perform bus enumeration.
> > > > +*
> > > > +* Allow the bridge to be used for enumeration, if 
> > > > hardware
> > > > +* strapping (Host mode) or firmware (Agent mode) has 
> > > > enabled
> > > > +* bus mastering.
> > > > +*/
> > > > +   early_read_config_word(hose, 0, 0, PCI_COMMAND, 
> > > > &master);
> > > > +   if (!(master & PCI_COMMAND_MASTER))
> > > > goto no_bridge;
> > > > }
> > > 
> > > Why wouldn't a normal PCI agent be able to bus master?
> > > 
> > > -Scott
> > > 
> > 
> > Short answer:
> > 
> > Simply because the hardware strapping for Host/Agent determines the
> > default state of the Bus Master bit in the Command register. Without
> > that bit being set, an Agent won't be able to send the PCI cycles
> > necessary to enumerate the bus.
> 
> But what if the host has already set that bit before Linux boots?

That's a very good point. I think that concern can be addressed by looking
for another telltale sign of enumeration, whether an address has been
assigned to the bridge's BAR 0 (PCSRBAR).

> > Long answer:
> > 
> > I think there was an assumption in the patch that introduced the
> > regression that Host and Agent in conventional PCI and PCI-X are more
> > equivalent to PCIe Root Complex and Endpoint than they really are.
> > 
> > I think the purpose of Minghuan's patch was to not attempt to enumerate
> > the bus with a bridge that simply cannot do it. A PCIe Endpoint cannot
> > enumerate the bus and a PCI/PCI-X device that cannot master cycles on the
> > bus will not be able to enumerate the bus either.
> 
> No, the point is also to not enumerate the bus in cases where we
> shouldn't.  We don't want to step on the host's toes.

Agreed.
 
> > The hardware strapping for Host/Agent mode determines the default state
> > of the Bus Master bit in the Command register.
> > 
> > In our more specialized, but still industry standardized, environment our
> > firmware must detect whether our board should be the bus's sole enumerator
> > and set the Bus Master bit accordingly.
> > 
> > My comment in the code still mentions Host and Agent mode, simply because
> > the code it is replacing based its decision on the mode.
> 
> I understand why you need to do this -- I just don't think this is a
> reliable way of detecting that you're in that situation.  How about a
> kernel command line setting?

I'd like to avoid requiring a kernel command-line option for this.

Instead, I propose checking for Agent mode like Minghuan's patch, but
prohibiting enumeration only if Bus Master is not enabled OR the address
portion of PCSRBAR is non-zero (indicating another device has enumerated
the bus).

Pseudo code:
if (agent && (!master || enumerated))
goto no_bridge;

-Aaron
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: fsl_pci: Fix PCI/PCI-X regression

2014-08-21 Thread Aaron Sierra 
- Original Message -
> From: "Scott Wood" 
> Sent: Thursday, August 21, 2014 4:19:56 PM
> 
> On Wed, 2014-08-20 at 18:51 -0500, Aaron Sierra wrote:
> > @@ -520,9 +520,22 @@ int fsl_add_bridge(struct platform_device *pdev, int
> > is_primary)
> > goto no_bridge;
> >  
> > } else {
> > -   /* For PCI read PROG to identify controller mode */
> > -   early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
> > -   if ((progif & 1) == 1)
> > +   u16 master;
> > +
> > +   /*
> > +* If the controller is PCI-X, then Host mode refers to a
> > +* bridge that drives the PCI-X initialization pattern to
> > +* indicate bus operating mode/frequency to devices on the bus.
> > +* Some hardware (specifically PrPMC modules) are Agents, since
> > +* the mezzanine carrier is responsible for driving the
> > +* pattern, but they still may perform bus enumeration.
> > +*
> > +* Allow the bridge to be used for enumeration, if hardware
> > +* strapping (Host mode) or firmware (Agent mode) has enabled
> > +* bus mastering.
> > +*/
> > +   early_read_config_word(hose, 0, 0, PCI_COMMAND, &master);
> > +   if (!(master & PCI_COMMAND_MASTER))
> > goto no_bridge;
> > }
> 
> Why wouldn't a normal PCI agent be able to bus master?
> 
> -Scott
> 

Short answer:

Simply because the hardware strapping for Host/Agent determines the
default state of the Bus Master bit in the Command register. Without
that bit being set, an Agent won't be able to send the PCI cycles
necessary to enumerate the bus.


Long answer:

I think there was an assumption in the patch that introduced the
regression that Host and Agent in conventional PCI and PCI-X are more
equivalent to PCIe Root Complex and Endpoint than they really are.

I think the purpose of Minghuan's patch was to not attempt to enumerate
the bus with a bridge that simply cannot do it. A PCIe Endpoint cannot
enumerate the bus and a PCI/PCI-X device that cannot master cycles on the
bus will not be able to enumerate the bus either.

The hardware strapping for Host/Agent mode determines the default state
of the Bus Master bit in the Command register.

In our more specialized, but still industry standardized, environment our
firmware must detect whether our board should be the bus's sole enumerator
and set the Bus Master bit accordingly.

My comment in the code still mentions Host and Agent mode, simply because
the code it is replacing based its decision on the mode.

-Aaron
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc: fsl_pci: Fix PCI/PCI-X regression

2014-08-20 Thread Aaron Sierra 
The following commit prevents the MPC8548E on the XPedite5200 PrPMC
module from enumerating its PCI/PCI-X bus, though it was previously
able to:

powerpc/fsl-pci: use 'Header Type' to identify PCIE mode

The previous patch prevents any Freescale PCI-X bridge from enumerating
the bus, if it is hardware strapped into Agent mode.

In PCI-X, the Host is responsible for driving the PCI-X initialization
pattern to devices on the bus, so that they know whether to operate in
conventional PCI or PCI-X mode as well as what the bus timing will be.
For a PCI-X PrPMC, the pattern is driven by the mezzanine carrier it is
installed onto. Therefore, PrPMCs are PCI-X Agents, but they may still
enumerate the bus.

This patch depends on firmware to determine if the bridge should
perform enumeration based on factors other than the Host/Agent mode,
such as the state of the VITA 32-defined MONARCH# signal. If firmware
has determined that enumeration should be allowed, then it will set the
bridge's Bus Master bit in the Command register.

Without firmware intervention, the Bus Master bit defaults to 1 in Host
mode and 0 in Agent mode.

Cc: Minghuan Lian 
Signed-off-by: Aaron Sierra 
---
 arch/powerpc/sysdev/fsl_pci.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 4bd091a..88d8844 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -463,7 +463,7 @@ int fsl_add_bridge(struct platform_device *pdev, int 
is_primary)
struct pci_controller *hose;
struct resource rsrc;
const int *bus_range;
-   u8 hdr_type, progif;
+   u8 hdr_type;
struct device_node *dev;
struct ccsr_pci __iomem *pci;
 
@@ -520,9 +520,22 @@ int fsl_add_bridge(struct platform_device *pdev, int 
is_primary)
goto no_bridge;
 
} else {
-   /* For PCI read PROG to identify controller mode */
-   early_read_config_byte(hose, 0, 0, PCI_CLASS_PROG, &progif);
-   if ((progif & 1) == 1)
+   u16 master;
+
+   /*
+* If the controller is PCI-X, then Host mode refers to a
+* bridge that drives the PCI-X initialization pattern to
+* indicate bus operating mode/frequency to devices on the bus.
+* Some hardware (specifically PrPMC modules) are Agents, since
+* the mezzanine carrier is responsible for driving the
+* pattern, but they still may perform bus enumeration.
+*
+* Allow the bridge to be used for enumeration, if hardware
+* strapping (Host mode) or firmware (Agent mode) has enabled
+* bus mastering.
+*/
+   early_read_config_word(hose, 0, 0, PCI_COMMAND, &master);
+   if (!(master & PCI_COMMAND_MASTER))
goto no_bridge;
}
 
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: PCIe driver not working properly after upgrading to linux 3.8.13

2014-08-20 Thread Aaron Sierra 
- Original Message -
> From: "Gokul C G" 
> Sent: Tuesday, August 19, 2014 9:43:38 AM
> 
> HI,
> 
> I am facing problem with PCIE driver in new Linux kernel compiled for powerpc
> architecture (Big endian) ,freescales P2040 processor.I was using old kernel
> Linux version 3.0.48 previously and now updated to Linux version
> 3.8.13-rt9.After updating to the new kernel, PCIe device drivers not working
> properly and i am getting some error messages in the boot-up .My intention
> is to use EXAR PCIe Multiport serial driver and add 8 serial ports in
> addition to 4 built in serial ports provided by P2040 processor. The PCIe
> driver form EXAR is compiled and loaded as kernel module . The same was
> working with linux kernel 3.0.48 and following prints observed while loading
> kernel module.
> 

Have you attempted to use the XR17V35x support present in the updated version
of the kernel that you're using (I assume it's Freescale SDK 1.4.x)?

8250 core support for Exar parts:
http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/tree/drivers/tty/serial/8250/8250.c?h=sdk-v.1.4.x#n296

PCI vendor and device IDs for 2, 4 and 8 port Exar parts:
http://git.freescale.com/git/cgit.cgi/ppc/sdk/linux.git/tree/drivers/tty/serial/8250/8250_pci.c?h=sdk-v.1.4.x#n1722

-Aaron
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] fsl_ifc: Support all 8 IFC chip selects

2014-08-20 Thread Aaron Sierra 
> >> -#define FSL_IFC_BANK_COUNT 4
> >> +#define FSL_IFC_BANK_COUNT 8
> > First please modify fsl_ifc_nand.c to limit itself to the number of
> > banks it dynamically determines are present based on the IFC version.
> >
> >
> 
> Number of available bank/chip select are defined by SoC and it is
> independent of SoC.

You mean that there is no way to tell from an IFC-specific register how
many chip selects are valid for a given SoC, correct?

> It should be fix in following way
> 
> Option 1:
> u-boot:  fix device tree with number of available chip select. It may
> require IFC binding change
> Linux: Read device tree and determine the Chip Selects
> 
> or
> 
> Option 2:
> Make it static because any way IFC NAND driver polls to
> FSL_IFC_BANK_COUNT to know NAND flash chip select. This patch is doing same.

My patch is based on the assumption that it is safe to access the addresses of
the four nonexistent (unconnected?) chip selects in devices with fewer than
eight chip selects.

Also, the full FSL_IFC_BANK_COUNT range of chip selects should only be probed
when no match is not found for a chip select's DTS-defined address base within
any IFC bank. The typical case would be for the device tree to properly define
the address space prepared by the bootloader, which would result in only banks
present in the SoC being probed.

I have tested this patch on P1010 and T1042 processors, which feature four and
eight chip selects respectively with no apparent ill effects.

Our P1010 product has NAND attached to chip selects 0 and 1:

ranges = <0x0 0x0 0x0 0xef80 0x001
  0x1 0x0 0x0 0xef84 0x001>;

I mangled chip-select 0 so that the DTS-defined base would not match the
address programmed by firmware, so that all eight chip selects would be
scanned on this four chip-select part:

ranges = <0x0 0x0 0x0 0xefc0 0x001
  0x1 0x0 0x0 0xef84 0x001>;

This resulted in the following kernel message:

fsl,ifc-nand efc0.nand0: fsl_ifc_nand_probe: address did not match any chip 
selects

The NAND device at chip select 1 was properly detected.

> Regards,
> Prabhakar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 2/2] fsl_ifc: Support all 8 IFC chip selects

2014-08-15 Thread Aaron Sierra 
Freescale's QorIQ T Series processors support 8 IFC chip selects
within a memory map backward compatible with previous P Series
processors which supported only 4 chip selects.

Signed-off-by: Aaron Sierra 
---
 include/linux/fsl_ifc.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/fsl_ifc.h b/include/linux/fsl_ifc.h
index 84d60cb..62762ff 100644
--- a/include/linux/fsl_ifc.h
+++ b/include/linux/fsl_ifc.h
@@ -29,7 +29,7 @@
 #include 
 #include 
 
-#define FSL_IFC_BANK_COUNT 4
+#define FSL_IFC_BANK_COUNT 8
 
 /*
  * CSPR - Chip Select Property Register
@@ -776,23 +776,23 @@ struct fsl_ifc_regs {
__be32 cspr;
u32 res2;
} cspr_cs[FSL_IFC_BANK_COUNT];
-   u32 res3[0x19];
+   u32 res3[0xd];
struct {
__be32 amask;
u32 res4[0x2];
} amask_cs[FSL_IFC_BANK_COUNT];
-   u32 res5[0x18];
+   u32 res5[0xc];
struct {
__be32 csor;
__be32 csor_ext;
u32 res6;
} csor_cs[FSL_IFC_BANK_COUNT];
-   u32 res7[0x18];
+   u32 res7[0xc];
struct {
__be32 ftim[4];
u32 res8[0x8];
} ftim_cs[FSL_IFC_BANK_COUNT];
-   u32 res9[0x60];
+   u32 res9[0x30];
__be32 rb_stat;
u32 res10[0x2];
__be32 ifc_gcr;
-- 
1.9.1



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/2] fsl_ifc: Fix csor_ext position in fsl_ifc_regs

2014-08-15 Thread Aaron Sierra 
According to Freescale manuals, the IFC_CSORn_EXT register is located
immediately _after_ the bank's IFC_CSORn register.

This patch adjusts the csor_ext member of and reserved register arrays
immediately surrounding the csor_cs structure to provide proper access
to this register.

Signed-off-by: Aaron Sierra 
---
 include/linux/fsl_ifc.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/fsl_ifc.h b/include/linux/fsl_ifc.h
index f49ddb1..84d60cb 100644
--- a/include/linux/fsl_ifc.h
+++ b/include/linux/fsl_ifc.h
@@ -781,13 +781,13 @@ struct fsl_ifc_regs {
__be32 amask;
u32 res4[0x2];
} amask_cs[FSL_IFC_BANK_COUNT];
-   u32 res5[0x17];
+   u32 res5[0x18];
struct {
-   __be32 csor_ext;
__be32 csor;
+   __be32 csor_ext;
u32 res6;
} csor_cs[FSL_IFC_BANK_COUNT];
-   u32 res7[0x19];
+   u32 res7[0x18];
struct {
__be32 ftim[4];
u32 res8[0x8];
-- 
1.9.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev