[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

The example does not work on real hardware with the PCIe HIP [1].
The problem is with incorrect "ranges" property in the example, so
one cannot just copy-paste the example into his DT and expect this
to work. This patches aligns the "ranges" in the example with the
reference FPGA design.

[1] http://rocketboards.org/foswiki/view/Projects/PCIeRootPortWithMSI

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/pci/altera-pcie.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt b/Documentation/devicetree/bindings/pci/altera-pcie.txt
index 2951a6a..d2427c1 100644
--- a/Documentation/devicetree/bindings/pci/altera-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt
@@ -44,6 +44,6 @@ Example
 			            <0 0 0 2 &pcie_0 2>,
 			            <0 0 0 3 &pcie_0 3>,
 			            <0 0 0 4 &pcie_0 4>;
-		ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x10000000
-			    0x82000000 0x00000000 0x10000000 0xd0000000 0x00000000 0x10000000>;
+		ranges = <0x82000000 0x00000000 0xc0000000 0xc0000000 0x00000000 0x10000000
+			  0x82000000 0x00000000 0xd0000000 0xd0000000 0x00000000 0x10000000>;
 	};
-- 
2.1.4

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> The example does not work on real hardware with the PCIe HIP [1].
> The problem is with incorrect "ranges" property in the example, so
> one cannot just copy-paste the example into his DT and expect this
> to work. This patches aligns the "ranges" in the example with the
> reference FPGA design.
Hi Marek

The original "ranges" is working for me. What error did you encounter?

Thanks.

> 
> [1] http://rocketboards.org/foswiki/view/Projects/PCIeRootPortWithMSI
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Ley Foon Tan <lftan@altera.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Cc: Rob Herring <robh@kernel.org>
> ---
>  Documentation/devicetree/bindings/pci/altera-pcie.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt b/Documentation/devicetree/bindings/pci/altera-pcie.txt
> index 2951a6a..d2427c1 100644
> --- a/Documentation/devicetree/bindings/pci/altera-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt
> @@ -44,6 +44,6 @@ Example
>  			            <0 0 0 2 &pcie_0 2>,
>  			            <0 0 0 3 &pcie_0 3>,
>  			            <0 0 0 4 &pcie_0 4>;
> -		ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x10000000
> -			    0x82000000 0x00000000 0x10000000 0xd0000000 0x00000000 0x10000000>;
> +		ranges = <0x82000000 0x00000000 0xc0000000 0xc0000000 0x00000000 0x10000000
> +			  0x82000000 0x00000000 0xd0000000 0xd0000000 0x00000000 0x10000000>;
>  	};

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> > The example does not work on real hardware with the PCIe HIP [1].
> > The problem is with incorrect "ranges" property in the example, so
> > one cannot just copy-paste the example into his DT and expect this
> > to work. This patches aligns the "ranges" in the example with the
> > reference FPGA design.
> 
> Hi Marek

Hi Ley,

> The original "ranges" is working for me. What error did you encounter?

Every time a driver accessed the Txs range, the system got stuck hard.
The Cra access always worked fine though, so the PCIe devices were always
detected.

I checked with signaltap and my impression is that the wrong address
propagated into the request passed to the Txs port of the HardIP block,
unless I change the range configuration.

Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi
card. The intel in particular uses both the Txs and even MSI , so to use
the intel, the whole PCIe block has to work properly ; with this change,
it does and I can use the intel card just fine.

> Thanks.
> 
> > [1] http://rocketboards.org/foswiki/view/Projects/PCIeRootPortWithMSI
> > 
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Ley Foon Tan <lftan@altera.com>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
> > Cc: Rob Herring <robh@kernel.org>
> > ---
> > 
> >  Documentation/devicetree/bindings/pci/altera-pcie.txt | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt
> > b/Documentation/devicetree/bindings/pci/altera-pcie.txt index
> > 2951a6a..d2427c1 100644
> > --- a/Documentation/devicetree/bindings/pci/altera-pcie.txt
> > +++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt
> > @@ -44,6 +44,6 @@ Example
> > 
> >  			            <0 0 0 2 &pcie_0 2>,
> >  			            <0 0 0 3 &pcie_0 3>,
> >  			            <0 0 0 4 &pcie_0 4>;
> > 
> > -		ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000
> > 0x10000000 -			    0x82000000 0x00000000 0x10000000 
0xd0000000
> > 0x00000000 0x10000000>; +		ranges = <0x82000000 0x00000000 
0xc0000000
> > 0xc0000000 0x00000000 0x10000000 +			  0x82000000 0x00000000 
0xd0000000
> > 0xd0000000 0x00000000 0x10000000>;
> > 
> >  	};

Best regards,
Marek Vasut

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote:
> On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
>> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
>> > The example does not work on real hardware with the PCIe HIP [1].
>> > The problem is with incorrect "ranges" property in the example, so
>> > one cannot just copy-paste the example into his DT and expect this
>> > to work. This patches aligns the "ranges" in the example with the
>> > reference FPGA design.
>>
>> Hi Marek
>
> Hi Ley,
>
>> The original "ranges" is working for me. What error did you encounter?
>
> Every time a driver accessed the Txs range, the system got stuck hard.
> The Cra access always worked fine though, so the PCIe devices were always
> detected.
>
> I checked with signaltap and my impression is that the wrong address
> propagated into the request passed to the Txs port of the HardIP block,
> unless I change the range configuration.
>
> Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi
> card. The intel in particular uses both the Txs and even MSI , so to use
> the intel, the whole PCIe block has to work properly ; with this change,
> it does and I can use the intel card just fine.
>
>> Thanks.
>>
Hi Marek

I tested two Ethernet adapters, one SSD NVMe and our custom endpoint
without the problem.
Can you please send me your dts file if possible?

Do you use the latest Altera pcie driver in v4.4?

Thanks.

Regards
Ley Foon

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote:
> On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote:
> > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> >> > The example does not work on real hardware with the PCIe HIP [1].
> >> > The problem is with incorrect "ranges" property in the example, so
> >> > one cannot just copy-paste the example into his DT and expect this
> >> > to work. This patches aligns the "ranges" in the example with the
> >> > reference FPGA design.
> >> 
> >> Hi Marek
> > 
> > Hi Ley,
> > 
> >> The original "ranges" is working for me. What error did you encounter?
> > 
> > Every time a driver accessed the Txs range, the system got stuck hard.
> > The Cra access always worked fine though, so the PCIe devices were always
> > detected.
> > 
> > I checked with signaltap and my impression is that the wrong address
> > propagated into the request passed to the Txs port of the HardIP block,
> > unless I change the range configuration.
> > 
> > Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi
> > card. The intel in particular uses both the Txs and even MSI , so to use
> > the intel, the whole PCIe block has to work properly ; with this change,
> > it does and I can use the intel card just fine.
> > 
> >> Thanks.
> 
> Hi Marek
> 
> I tested two Ethernet adapters, one SSD NVMe and our custom endpoint
> without the problem.
> Can you please send me your dts file if possible?
> 
> Do you use the latest Altera pcie driver in v4.4?

I'm using next from 20151223, crude patch is attached.

Best regards,
Marek Vasut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-socfpga-Enable-PCIe-support.patch
Type: text/x-patch
Size: 2018 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151228/5a3c326f/attachment.bin>

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote:
> On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote:
> > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote:
> > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> > >> > The example does not work on real hardware with the PCIe HIP [1].
> > >> > The problem is with incorrect "ranges" property in the example, so
> > >> > one cannot just copy-paste the example into his DT and expect this
> > >> > to work. This patches aligns the "ranges" in the example with the
> > >> > reference FPGA design.
> > >> 
> > >> Hi Marek
> > > 
> > > Hi Ley,
> > > 
> > >> The original "ranges" is working for me. What error did you encounter?
> > > 
> > > Every time a driver accessed the Txs range, the system got stuck hard.
> > > The Cra access always worked fine though, so the PCIe devices were always
> > > detected.
> > > 
> > > I checked with signaltap and my impression is that the wrong address
> > > propagated into the request passed to the Txs port of the HardIP block,
> > > unless I change the range configuration.
> > > 
> > > Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006 WiFi
> > > card. The intel in particular uses both the Txs and even MSI , so to use
> > > the intel, the whole PCIe block has to work properly ; with this change,
> > > it does and I can use the intel card just fine.
> > > 
> > >> Thanks.
> > 
> > Hi Marek
> > 
> > I tested two Ethernet adapters, one SSD NVMe and our custom endpoint
> > without the problem.
> > Can you please send me your dts file if possible?
> > 
> > Do you use the latest Altera pcie driver in v4.4?
> 
> I'm using next from 20151223, crude patch is attached.
> 
Hi Marek

Your dts looks fine, same as mine; except the 'ranges' parameter. Not
sure why it is not working on your side.

I may try again with the linux-next later.

Regards
Ley Foon

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote:
> On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote:
> > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote:
> > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote:
> > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> > > >> > The example does not work on real hardware with the PCIe HIP [1].
> > > >> > The problem is with incorrect "ranges" property in the example, so
> > > >> > one cannot just copy-paste the example into his DT and expect this
> > > >> > to work. This patches aligns the "ranges" in the example with the
> > > >> > reference FPGA design.
> > > >> 
> > > >> Hi Marek
> > > > 
> > > > Hi Ley,
> > > > 
> > > >> The original "ranges" is working for me. What error did you
> > > >> encounter?
> > > > 
> > > > Every time a driver accessed the Txs range, the system got stuck
> > > > hard. The Cra access always worked fine though, so the PCIe devices
> > > > were always detected.
> > > > 
> > > > I checked with signaltap and my impression is that the wrong address
> > > > propagated into the request passed to the Txs port of the HardIP
> > > > block, unless I change the range configuration.
> > > > 
> > > > Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006
> > > > WiFi card. The intel in particular uses both the Txs and even MSI ,
> > > > so to use the intel, the whole PCIe block has to work properly ;
> > > > with this change, it does and I can use the intel card just fine.
> > > > 
> > > >> Thanks.
> > > 
> > > Hi Marek
> > > 
> > > I tested two Ethernet adapters, one SSD NVMe and our custom endpoint
> > > without the problem.
> > > Can you please send me your dts file if possible?
> > > 
> > > Do you use the latest Altera pcie driver in v4.4?
> > 
> > I'm using next from 20151223, crude patch is attached.
> 
> Hi Marek
> 
> Your dts looks fine, same as mine; except the 'ranges' parameter. Not
> sure why it is not working on your side.
> 
> I may try again with the linux-next later.

Looking forward to your observations ;-)

btw the other difference is location of the Cra port, in my case it's at 
0xff220000 , which matches the altera reference design. The example code
uses 0xff240000 for whatever reason.

Best regards,
Marek Vasut

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote:
> On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote:
> > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote:
> > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote:
> > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote:
> > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> > > > >> > The example does not work on real hardware with the PCIe HIP [1].
> > > > >> > The problem is with incorrect "ranges" property in the example, so
> > > > >> > one cannot just copy-paste the example into his DT and expect this
> > > > >> > to work. This patches aligns the "ranges" in the example with the
> > > > >> > reference FPGA design.
> > > > >> 
> > > > >> Hi Marek
> > > > > 
> > > > > Hi Ley,
> > > > > 
> > > > >> The original "ranges" is working for me. What error did you
> > > > >> encounter?
> > > > > 
> > > > > Every time a driver accessed the Txs range, the system got stuck
> > > > > hard. The Cra access always worked fine though, so the PCIe devices
> > > > > were always detected.
> > > > > 
> > > > > I checked with signaltap and my impression is that the wrong address
> > > > > propagated into the request passed to the Txs port of the HardIP
> > > > > block, unless I change the range configuration.
> > > > > 
> > > > > Note that I tested Intel Centrino 6235 WiFi card and Atheros AR5006
> > > > > WiFi card. The intel in particular uses both the Txs and even MSI ,
> > > > > so to use the intel, the whole PCIe block has to work properly ;
> > > > > with this change, it does and I can use the intel card just fine.
> > > > > 
> > > > >> Thanks.
> > > > 
> > > > Hi Marek
> > > > 
> > > > I tested two Ethernet adapters, one SSD NVMe and our custom endpoint
> > > > without the problem.
> > > > Can you please send me your dts file if possible?
> > > > 
> > > > Do you use the latest Altera pcie driver in v4.4?
> > > 
> > > I'm using next from 20151223, crude patch is attached.
> > 
> > Hi Marek
> > 
> > Your dts looks fine, same as mine; except the 'ranges' parameter. Not
> > sure why it is not working on your side.
> > 
> > I may try again with the linux-next later.
> 
> Looking forward to your observations ;-)
Tested with 20151223 linux-next, it is working with original dts.

> 
> btw the other difference is location of the Cra port, in my case it's at 
> 0xff220000 , which matches the altera reference design. The example code
> uses 0xff240000 for whatever reason.
> 
The example code uses 0xff220000, where do you see 0xff240000?

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Thursday, December 31, 2015 at 04:09:01 AM, Ley Foon Tan wrote:
> On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote:
> > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote:
> > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote:
> > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote:
> > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote:
> > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> > > > > >> > The example does not work on real hardware with the PCIe HIP
> > > > > >> > [1]. The problem is with incorrect "ranges" property in the
> > > > > >> > example, so one cannot just copy-paste the example into his
> > > > > >> > DT and expect this to work. This patches aligns the "ranges"
> > > > > >> > in the example with the reference FPGA design.
> > > > > >> 
> > > > > >> Hi Marek
> > > > > > 
> > > > > > Hi Ley,
> > > > > > 
> > > > > >> The original "ranges" is working for me. What error did you
> > > > > >> encounter?
> > > > > > 
> > > > > > Every time a driver accessed the Txs range, the system got stuck
> > > > > > hard. The Cra access always worked fine though, so the PCIe
> > > > > > devices were always detected.
> > > > > > 
> > > > > > I checked with signaltap and my impression is that the wrong
> > > > > > address propagated into the request passed to the Txs port of
> > > > > > the HardIP block, unless I change the range configuration.
> > > > > > 
> > > > > > Note that I tested Intel Centrino 6235 WiFi card and Atheros
> > > > > > AR5006 WiFi card. The intel in particular uses both the Txs and
> > > > > > even MSI , so to use the intel, the whole PCIe block has to work
> > > > > > properly ; with this change, it does and I can use the intel
> > > > > > card just fine.
> > > > > > 
> > > > > >> Thanks.
> > > > > 
> > > > > Hi Marek
> > > > > 
> > > > > I tested two Ethernet adapters, one SSD NVMe and our custom
> > > > > endpoint without the problem.
> > > > > Can you please send me your dts file if possible?
> > > > > 
> > > > > Do you use the latest Altera pcie driver in v4.4?
> > > > 
> > > > I'm using next from 20151223, crude patch is attached.
> > > 
> > > Hi Marek
> > > 
> > > Your dts looks fine, same as mine; except the 'ranges' parameter. Not
> > > sure why it is not working on your side.
> > > 
> > > I may try again with the linux-next later.
> > 
> > Looking forward to your observations ;-)
> 
> Tested with 20151223 linux-next, it is working with original dts.

Well, do you have a good explanation why the system works with this change
and doesn't work without it on my design ? I'd really love to understand
this.

> > btw the other difference is location of the Cra port, in my case it's at
> > 0xff220000 , which matches the altera reference design. The example code
> > uses 0xff240000 for whatever reason.
> 
> The example code uses 0xff220000, where do you see 0xff240000?

I thought the ccb_lw_50_to_125 was at +0x40000 in the original design, but I
can't seem to be able to find that. I've been studying multiple PCIe designs
and this notion somehow crawled into my skull. Sorry, please ignore then.

Best regards,
Marek Vasut

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Thu, 2015-12-31 at 10:04 +0100, Marek Vasut wrote:
> On Thursday, December 31, 2015 at 04:09:01 AM, Ley Foon Tan wrote:
> > On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote:
> > > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote:
> > > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote:
> > > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote:
> > > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> wrote:
> > > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> > > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> > > > > > >> > The example does not work on real hardware with the PCIe HIP
> > > > > > >> > [1]. The problem is with incorrect "ranges" property in the
> > > > > > >> > example, so one cannot just copy-paste the example into his
> > > > > > >> > DT and expect this to work. This patches aligns the "ranges"
> > > > > > >> > in the example with the reference FPGA design.
> > > > > > >> 
> > > > > > >> Hi Marek
> > > > > > > 
> > > > > > > Hi Ley,
> > > > > > > 
> > > > > > >> The original "ranges" is working for me. What error did you
> > > > > > >> encounter?
> > > > > > > 
> > > > > > > Every time a driver accessed the Txs range, the system got stuck
> > > > > > > hard. The Cra access always worked fine though, so the PCIe
> > > > > > > devices were always detected.
> > > > > > > 
> > > > > > > I checked with signaltap and my impression is that the wrong
> > > > > > > address propagated into the request passed to the Txs port of
> > > > > > > the HardIP block, unless I change the range configuration.
> > > > > > > 
> > > > > > > Note that I tested Intel Centrino 6235 WiFi card and Atheros
> > > > > > > AR5006 WiFi card. The intel in particular uses both the Txs and
> > > > > > > even MSI , so to use the intel, the whole PCIe block has to work
> > > > > > > properly ; with this change, it does and I can use the intel
> > > > > > > card just fine.
> > > > > > > 
> > > > > > >> Thanks.
> > > > > > 
> > > > > > Hi Marek
> > > > > > 
> > > > > > I tested two Ethernet adapters, one SSD NVMe and our custom
> > > > > > endpoint without the problem.
> > > > > > Can you please send me your dts file if possible?
> > > > > > 
> > > > > > Do you use the latest Altera pcie driver in v4.4?
> > > > > 
> > > > > I'm using next from 20151223, crude patch is attached.
> > > > 
> > > > Hi Marek
> > > > 
> > > > Your dts looks fine, same as mine; except the 'ranges' parameter. Not
> > > > sure why it is not working on your side.
> > > > 
> > > > I may try again with the linux-next later.
> > > 
> > > Looking forward to your observations ;-)
> > 
> > Tested with 20151223 linux-next, it is working with original dts.
> 
> Well, do you have a good explanation why the system works with this change
> and doesn't work without it on my design ? I'd really love to understand
> this.
Do you modify the driver to setup the translation table?

Regards
Ley Foon

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Monday, January 04, 2016 at 12:29:40 AM, Ley Foon Tan wrote:
> On Thu, 2015-12-31 at 10:04 +0100, Marek Vasut wrote:
> > On Thursday, December 31, 2015 at 04:09:01 AM, Ley Foon Tan wrote:
> > > On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote:
> > > > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote:
> > > > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote:
> > > > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote:
> > > > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> 
wrote:
> > > > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> > > > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> > > > > > > >> > The example does not work on real hardware with the PCIe
> > > > > > > >> > HIP [1]. The problem is with incorrect "ranges" property
> > > > > > > >> > in the example, so one cannot just copy-paste the example
> > > > > > > >> > into his DT and expect this to work. This patches aligns
> > > > > > > >> > the "ranges" in the example with the reference FPGA
> > > > > > > >> > design.
> > > > > > > >> 
> > > > > > > >> Hi Marek
> > > > > > > > 
> > > > > > > > Hi Ley,
> > > > > > > > 
> > > > > > > >> The original "ranges" is working for me. What error did you
> > > > > > > >> encounter?
> > > > > > > > 
> > > > > > > > Every time a driver accessed the Txs range, the system got
> > > > > > > > stuck hard. The Cra access always worked fine though, so the
> > > > > > > > PCIe devices were always detected.
> > > > > > > > 
> > > > > > > > I checked with signaltap and my impression is that the wrong
> > > > > > > > address propagated into the request passed to the Txs port of
> > > > > > > > the HardIP block, unless I change the range configuration.
> > > > > > > > 
> > > > > > > > Note that I tested Intel Centrino 6235 WiFi card and Atheros
> > > > > > > > AR5006 WiFi card. The intel in particular uses both the Txs
> > > > > > > > and even MSI , so to use the intel, the whole PCIe block has
> > > > > > > > to work properly ; with this change, it does and I can use
> > > > > > > > the intel card just fine.
> > > > > > > > 
> > > > > > > >> Thanks.
> > > > > > > 
> > > > > > > Hi Marek
> > > > > > > 
> > > > > > > I tested two Ethernet adapters, one SSD NVMe and our custom
> > > > > > > endpoint without the problem.
> > > > > > > Can you please send me your dts file if possible?
> > > > > > > 
> > > > > > > Do you use the latest Altera pcie driver in v4.4?
> > > > > > 
> > > > > > I'm using next from 20151223, crude patch is attached.
> > > > > 
> > > > > Hi Marek
> > > > > 
> > > > > Your dts looks fine, same as mine; except the 'ranges' parameter.
> > > > > Not sure why it is not working on your side.
> > > > > 
> > > > > I may try again with the linux-next later.
> > > > 
> > > > Looking forward to your observations ;-)
> > > 
> > > Tested with 20151223 linux-next, it is working with original dts.
> > 
> > Well, do you have a good explanation why the system works with this
> > change and doesn't work without it on my design ? I'd really love to
> > understand this.
> 
> Do you modify the driver to setup the translation table?

No, I didn't change the driver. What do you refer to please ?

Best regards,

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Mon, 2016-01-04 at 00:36 +0100, Marek Vasut wrote:
> On Monday, January 04, 2016 at 12:29:40 AM, Ley Foon Tan wrote:
> > On Thu, 2015-12-31 at 10:04 +0100, Marek Vasut wrote:
> > > On Thursday, December 31, 2015 at 04:09:01 AM, Ley Foon Tan wrote:
> > > > On Tue, 2015-12-29 at 14:33 +0100, Marek Vasut wrote:
> > > > > On Tuesday, December 29, 2015 at 08:48:33 AM, Ley Foon Tan wrote:
> > > > > > On Mon, 2015-12-28 at 09:26 +0100, Marek Vasut wrote:
> > > > > > > On Monday, December 28, 2015 at 08:42:00 AM, Ley Foon Tan wrote:
> > > > > > > > On Mon, Dec 28, 2015 at 3:34 PM, Marek Vasut <marex@denx.de> 
> wrote:
> > > > > > > > > On Monday, December 28, 2015 at 07:56:15 AM, Ley Foon Tan wrote:
> > > > > > > > >> On Thu, 2015-12-24 at 10:45 +0100, Marek Vasut wrote:
> > > > > > > > >> > The example does not work on real hardware with the PCIe
> > > > > > > > >> > HIP [1]. The problem is with incorrect "ranges" property
> > > > > > > > >> > in the example, so one cannot just copy-paste the example
> > > > > > > > >> > into his DT and expect this to work. This patches aligns
> > > > > > > > >> > the "ranges" in the example with the reference FPGA
> > > > > > > > >> > design.
> > > > > > > > >> 
> > > > > > > > >> Hi Marek
> > > > > > > > > 
> > > > > > > > > Hi Ley,
> > > > > > > > > 
> > > > > > > > >> The original "ranges" is working for me. What error did you
> > > > > > > > >> encounter?
> > > > > > > > > 
> > > > > > > > > Every time a driver accessed the Txs range, the system got
> > > > > > > > > stuck hard. The Cra access always worked fine though, so the
> > > > > > > > > PCIe devices were always detected.
> > > > > > > > > 
> > > > > > > > > I checked with signaltap and my impression is that the wrong
> > > > > > > > > address propagated into the request passed to the Txs port of
> > > > > > > > > the HardIP block, unless I change the range configuration.
> > > > > > > > > 
> > > > > > > > > Note that I tested Intel Centrino 6235 WiFi card and Atheros
> > > > > > > > > AR5006 WiFi card. The intel in particular uses both the Txs
> > > > > > > > > and even MSI , so to use the intel, the whole PCIe block has
> > > > > > > > > to work properly ; with this change, it does and I can use
> > > > > > > > > the intel card just fine.
> > > > > > > > > 
> > > > > > > > >> Thanks.
> > > > > > > > 
> > > > > > > > Hi Marek
> > > > > > > > 
> > > > > > > > I tested two Ethernet adapters, one SSD NVMe and our custom
> > > > > > > > endpoint without the problem.
> > > > > > > > Can you please send me your dts file if possible?
> > > > > > > > 
> > > > > > > > Do you use the latest Altera pcie driver in v4.4?
> > > > > > > 
> > > > > > > I'm using next from 20151223, crude patch is attached.
> > > > > > 
> > > > > > Hi Marek
> > > > > > 
> > > > > > Your dts looks fine, same as mine; except the 'ranges' parameter.
> > > > > > Not sure why it is not working on your side.
> > > > > > 
> > > > > > I may try again with the linux-next later.
> > > > > 
> > > > > Looking forward to your observations ;-)
> > > > 
> > > > Tested with 20151223 linux-next, it is working with original dts.
> > > 
> > > Well, do you have a good explanation why the system works with this
> > > change and doesn't work without it on my design ? I'd really love to
> > > understand this.
> > 
> > Do you modify the driver to setup the translation table?
> 
> No, I didn't change the driver. What do you refer to please ?
> 
There is Address Translation Table at address offset 0x1000 in the IP.

Do you use the hardware design from the rocketboards.org or your own
design?

Regards
Ley Foon

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:

Hi!

> > > > Well, do you have a good explanation why the system works with this
> > > > change and doesn't work without it on my design ? I'd really love to
> > > > understand this.
> > > 
> > > Do you modify the driver to setup the translation table?
> > 
> > No, I didn't change the driver. What do you refer to please ?
> 
> There is Address Translation Table at address offset 0x1000 in the IP.

Oh, I didn't configure that in any way. Should I or does the driver configure it 
in some way?

> Do you use the hardware design from the rocketboards.org or your own
> design?

I use the one from rocketboards, I just ported it over to the MCVEVK
(custom cyclone v soc board)

Best regards,
Marek Vasut

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:
> 
> Hi!
> 
> > > > > Well, do you have a good explanation why the system works with this
> > > > > change and doesn't work without it on my design ? I'd really love to
> > > > > understand this.
> > > > 
> > > > Do you modify the driver to setup the translation table?
> > > 
> > > No, I didn't change the driver. What do you refer to please ?
> > 
> > There is Address Translation Table at address offset 0x1000 in the IP.
> 
> Oh, I didn't configure that in any way. Should I or does the driver configure it 
> in some way?
> 
> > Do you use the hardware design from the rocketboards.org or your own
> > design?
> 
> I use the one from rocketboards, I just ported it over to the MCVEVK
> (custom cyclone v soc board)
You may check again the base addresses use in the MCVEVK board.

Regards
Ley Foon

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote:
> On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:
> > 
> > Hi!
> > 
> > > > > > Well, do you have a good explanation why the system works with
> > > > > > this change and doesn't work without it on my design ? I'd
> > > > > > really love to understand this.
> > > > > 
> > > > > Do you modify the driver to setup the translation table?
> > > > 
> > > > No, I didn't change the driver. What do you refer to please ?
> > > 
> > > There is Address Translation Table at address offset 0x1000 in the IP.
> > 
> > Oh, I didn't configure that in any way. Should I or does the driver
> > configure it in some way?
> > 
> > > Do you use the hardware design from the rocketboards.org or your own
> > > design?
> > 
> > I use the one from rocketboards, I just ported it over to the MCVEVK
> > (custom cyclone v soc board)
> 
> You may check again the base addresses use in the MCVEVK board.

The address map is attached ; I don't see anything which would differ from the 
reference design.

btw I am honestly surprised that Quartus cannot export the address map into some 
text file :-(

Best regards,
Marek Vasut
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pci.png
Type: image/png
Size: 69924 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160104/18c61804/attachment-0001.png>

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote:
> On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote:
> > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:
> > > 
> > > Hi!
> > > 
> > > > > > > Well, do you have a good explanation why the system works with
> > > > > > > this change and doesn't work without it on my design ? I'd
> > > > > > > really love to understand this.
> > > > > > 
> > > > > > Do you modify the driver to setup the translation table?
> > > > > 
> > > > > No, I didn't change the driver. What do you refer to please ?
> > > > 
> > > > There is Address Translation Table at address offset 0x1000 in the IP.
> > > 
> > > Oh, I didn't configure that in any way. Should I or does the driver
> > > configure it in some way?
> > > 
> > > > Do you use the hardware design from the rocketboards.org or your own
> > > > design?
> > > 
> > > I use the one from rocketboards, I just ported it over to the MCVEVK
> > > (custom cyclone v soc board)
> > 
> > You may check again the base addresses use in the MCVEVK board.
> 
> The address map is attached ; I don't see anything which would differ from the 
> reference design.
Address map looks fine.
> 
> btw I am honestly surprised that Quartus cannot export the address map into some 
> text file :-(
There is a *.html file in the generated directory.

Regards
Ley Foon

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote:
> On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote:
> > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote:
> > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:
> > > > 
> > > > Hi!
> > > > 
> > > > > > > > Well, do you have a good explanation why the system works
> > > > > > > > with this change and doesn't work without it on my design ?
> > > > > > > > I'd really love to understand this.
> > > > > > > 
> > > > > > > Do you modify the driver to setup the translation table?
> > > > > > 
> > > > > > No, I didn't change the driver. What do you refer to please ?
> > > > > 
> > > > > There is Address Translation Table at address offset 0x1000 in the
> > > > > IP.
> > > > 
> > > > Oh, I didn't configure that in any way. Should I or does the driver
> > > > configure it in some way?
> > > > 
> > > > > Do you use the hardware design from the rocketboards.org or your
> > > > > own design?
> > > > 
> > > > I use the one from rocketboards, I just ported it over to the MCVEVK
> > > > (custom cyclone v soc board)
> > > 
> > > You may check again the base addresses use in the MCVEVK board.
> > 
> > The address map is attached ; I don't see anything which would differ
> > from the reference design.
> 
> Address map looks fine.

Well do you have any other idea then ? I guess I should pull out the SOCDK, huh?

> > btw I am honestly surprised that Quartus cannot export the address map
> > into some text file :-(
> 
> There is a *.html file in the generated directory.

Oh, I didn't know that, thanks!

Best regards,
Marek Vasut

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote:
> On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote:
> > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote:
> > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote:
> > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:
> > > > >
> > > > > Hi!
> > > > >
> > > > > > > > > Well, do you have a good explanation why the system works
> > > > > > > > > with this change and doesn't work without it on my design ?
> > > > > > > > > I'd really love to understand this.
> > > > > > > >
> > > > > > > > Do you modify the driver to setup the translation table?
> > > > > > >
> > > > > > > No, I didn't change the driver. What do you refer to please ?
> > > > > >
> > > > > > There is Address Translation Table at address offset 0x1000 in the
> > > > > > IP.
> > > > >
> > > > > Oh, I didn't configure that in any way. Should I or does the driver
> > > > > configure it in some way?
> > > > >
> > > > > > Do you use the hardware design from the rocketboards.org or your
> > > > > > own design?
> > > > >
> > > > > I use the one from rocketboards, I just ported it over to the MCVEVK
> > > > > (custom cyclone v soc board)
> > > >
> > > > You may check again the base addresses use in the MCVEVK board.
> > >
> > > The address map is attached ; I don't see anything which would differ
> > > from the reference design.
> >
> > Address map looks fine.
>
> Well do you have any other idea then ? I guess I should pull out the SOCDK, huh?
Can't think of any other thing that impact this, I expect the bus width
used in the pipeline/bridge are same with the example design.
Do you have our CV, AV or A10 SoC devkit?
>
> > > btw I am honestly surprised that Quartus cannot export the address map
> > > into some text file :-(
> >
> > There is a *.html file in the generated directory.
>
> Oh, I didn't know that, thanks!
>


________________________________

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Tuesday, January 05, 2016 at 02:18:18 AM, Ley Foon Tan wrote:
> On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote:
> > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote:
> > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote:
> > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote:
> > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:
> > > > > > 
> > > > > > Hi!
> > > > > > 
> > > > > > > > > > Well, do you have a good explanation why the system works
> > > > > > > > > > with this change and doesn't work without it on my design
> > > > > > > > > > ? I'd really love to understand this.
> > > > > > > > > 
> > > > > > > > > Do you modify the driver to setup the translation table?
> > > > > > > > 
> > > > > > > > No, I didn't change the driver. What do you refer to please ?
> > > > > > > 
> > > > > > > There is Address Translation Table at address offset 0x1000 in
> > > > > > > the IP.
> > > > > > 
> > > > > > Oh, I didn't configure that in any way. Should I or does the
> > > > > > driver configure it in some way?
> > > > > > 
> > > > > > > Do you use the hardware design from the rocketboards.org or
> > > > > > > your own design?
> > > > > > 
> > > > > > I use the one from rocketboards, I just ported it over to the
> > > > > > MCVEVK (custom cyclone v soc board)
> > > > > 
> > > > > You may check again the base addresses use in the MCVEVK board.
> > > > 
> > > > The address map is attached ; I don't see anything which would differ
> > > > from the reference design.
> > > 
> > > Address map looks fine.
> > 
> > Well do you have any other idea then ? I guess I should pull out the
> > SOCDK, huh?
> 
> Can't think of any other thing that impact this, I expect the bus width
> used in the pipeline/bridge are same with the example design.
> Do you have our CV

yes

> AV 

yes

> A10 SoC devkit?

Not yet ;-)

I'll try to find some time to test it on CV SoCDK tomorrow.

[...]

Best regards,
Marek Vasut

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Tuesday, January 05, 2016 at 02:18:18 AM, Ley Foon Tan wrote:
> On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote:
> > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote:
> > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote:
> > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote:
> > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:
> > > > > > 
> > > > > > Hi!
> > > > > > 
> > > > > > > > > > Well, do you have a good explanation why the system works
> > > > > > > > > > with this change and doesn't work without it on my design
> > > > > > > > > > ? I'd really love to understand this.
> > > > > > > > > 
> > > > > > > > > Do you modify the driver to setup the translation table?
> > > > > > > > 
> > > > > > > > No, I didn't change the driver. What do you refer to please ?
> > > > > > > 
> > > > > > > There is Address Translation Table at address offset 0x1000 in
> > > > > > > the IP.
> > > > > > 
> > > > > > Oh, I didn't configure that in any way. Should I or does the
> > > > > > driver configure it in some way?
> > > > > > 
> > > > > > > Do you use the hardware design from the rocketboards.org or
> > > > > > > your own design?
> > > > > > 
> > > > > > I use the one from rocketboards, I just ported it over to the
> > > > > > MCVEVK (custom cyclone v soc board)
> > > > > 
> > > > > You may check again the base addresses use in the MCVEVK board.
> > > > 
> > > > The address map is attached ; I don't see anything which would differ
> > > > from the reference design.
> > > 
> > > Address map looks fine.
> > 
> > Well do you have any other idea then ? I guess I should pull out the
> > SOCDK, huh?
> 
> Can't think of any other thing that impact this, I expect the bus width
> used in the pipeline/bridge are same with the example design.
> Do you have our CV, AV or A10 SoC devkit?

I tested CV SoCDK just now and you're right, the provided quartus project
works without this change on the CV SoCDK. Do you have any suggestion for
me where I should try looking then please ?

[...]

Best regards,
Marek Vasut

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Ley Foon Tan]

On Tue, 2016-01-05 at 14:49 +0100, Marek Vasut wrote:
> On Tuesday, January 05, 2016 at 02:18:18 AM, Ley Foon Tan wrote:
> > On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote:
> > > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote:
> > > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote:
> > > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote:
> > > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> > > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan wrote:
> > > > > > > 
> > > > > > > Hi!
> > > > > > > 
> > > > > > > > > > > Well, do you have a good explanation why the system works
> > > > > > > > > > > with this change and doesn't work without it on my design
> > > > > > > > > > > ? I'd really love to understand this.
> > > > > > > > > > 
> > > > > > > > > > Do you modify the driver to setup the translation table?
> > > > > > > > > 
> > > > > > > > > No, I didn't change the driver. What do you refer to please ?
> > > > > > > > 
> > > > > > > > There is Address Translation Table at address offset 0x1000 in
> > > > > > > > the IP.
> > > > > > > 
> > > > > > > Oh, I didn't configure that in any way. Should I or does the
> > > > > > > driver configure it in some way?
> > > > > > > 
> > > > > > > > Do you use the hardware design from the rocketboards.org or
> > > > > > > > your own design?
> > > > > > > 
> > > > > > > I use the one from rocketboards, I just ported it over to the
> > > > > > > MCVEVK (custom cyclone v soc board)
> > > > > > 
> > > > > > You may check again the base addresses use in the MCVEVK board.
> > > > > 
> > > > > The address map is attached ; I don't see anything which would differ
> > > > > from the reference design.
> > > > 
> > > > Address map looks fine.
> > > 
> > > Well do you have any other idea then ? I guess I should pull out the
> > > SOCDK, huh?
> > 
> > Can't think of any other thing that impact this, I expect the bus width
> > used in the pipeline/bridge are same with the example design.
> > Do you have our CV, AV or A10 SoC devkit?
> 
> I tested CV SoCDK just now and you're right, the provided quartus project
> works without this change on the CV SoCDK. Do you have any suggestion for
> me where I should try looking then please ?

Do you check the hardware pipeline bridge in Qsys? Are they same
configuration as CV SoCDK design?

Regards
Ley Foon

[PATCH] doc: PCI: altera: Fix the 'ranges' property in example

[Marek Vasut]

On Thursday, January 07, 2016 at 09:56:06 AM, Ley Foon Tan wrote:
> On Tue, 2016-01-05 at 14:49 +0100, Marek Vasut wrote:
> > On Tuesday, January 05, 2016 at 02:18:18 AM, Ley Foon Tan wrote:
> > > On Tue, 2016-01-05 at 01:47 +0100, Marek Vasut wrote:
> > > > On Tuesday, January 05, 2016 at 01:45:45 AM, Ley Foon Tan wrote:
> > > > > On Mon, 2016-01-04 at 02:12 +0100, Marek Vasut wrote:
> > > > > > On Monday, January 04, 2016 at 01:53:22 AM, Ley Foon Tan wrote:
> > > > > > > On Mon, 2016-01-04 at 01:37 +0100, Marek Vasut wrote:
> > > > > > > > On Monday, January 04, 2016 at 01:10:13 AM, Ley Foon Tan
> > > > > > > > wrote:
> > > > > > > > 
> > > > > > > > Hi!
> > > > > > > > 
> > > > > > > > > > > > Well, do you have a good explanation why the system
> > > > > > > > > > > > works with this change and doesn't work without it
> > > > > > > > > > > > on my design ? I'd really love to understand this.
> > > > > > > > > > > 
> > > > > > > > > > > Do you modify the driver to setup the translation
> > > > > > > > > > > table?
> > > > > > > > > > 
> > > > > > > > > > No, I didn't change the driver. What do you refer to
> > > > > > > > > > please ?
> > > > > > > > > 
> > > > > > > > > There is Address Translation Table at address offset 0x1000
> > > > > > > > > in the IP.
> > > > > > > > 
> > > > > > > > Oh, I didn't configure that in any way. Should I or does the
> > > > > > > > driver configure it in some way?
> > > > > > > > 
> > > > > > > > > Do you use the hardware design from the rocketboards.org or
> > > > > > > > > your own design?
> > > > > > > > 
> > > > > > > > I use the one from rocketboards, I just ported it over to the
> > > > > > > > MCVEVK (custom cyclone v soc board)
> > > > > > > 
> > > > > > > You may check again the base addresses use in the MCVEVK board.
> > > > > > 
> > > > > > The address map is attached ; I don't see anything which would
> > > > > > differ from the reference design.
> > > > > 
> > > > > Address map looks fine.
> > > > 
> > > > Well do you have any other idea then ? I guess I should pull out the
> > > > SOCDK, huh?
> > > 
> > > Can't think of any other thing that impact this, I expect the bus width
> > > used in the pipeline/bridge are same with the example design.
> > > Do you have our CV, AV or A10 SoC devkit?
> > 
> > I tested CV SoCDK just now and you're right, the provided quartus project
> > works without this change on the CV SoCDK. Do you have any suggestion for
> > me where I should try looking then please ?
> 
> Do you check the hardware pipeline bridge in Qsys? Are they same
> configuration as CV SoCDK design?

If you mean ccb_h2f_50_to_125 , then yes, they are exactly the same.

The only difference I can think of is in altr_xcvr_reconfig_0 , where I have
2 reconfiguration interfaces instead of 5 because I am using only PCIe x1
instead of x4 as it is on the CV SoCDK. The pcie_cv_hip_avmm_0 is configured
exactly the same too (but for x1 Gen1 port instead of x4 Gen1 port).

Best regards,
Marek Vasut