linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] doc: PCI: altera: Fix the 'ranges' property in example
Date: Thu, 31 Dec 2015 10:04:35 +0100	[thread overview]
Message-ID: <201512311004.35234.marex@denx.de> (raw)
In-Reply-To: <1451531341.3051.4.camel@ubuntu>

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

  reply	other threads:[~2015-12-31  9:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-24  9:45 [PATCH] doc: PCI: altera: Fix the 'ranges' property in example Marek Vasut
2015-12-28  6:56 ` Ley Foon Tan
2015-12-28  7:34   ` Marek Vasut
2015-12-28  7:42     ` Ley Foon Tan
2015-12-28  8:26       ` Marek Vasut
2015-12-29  7:48         ` Ley Foon Tan
2015-12-29 13:33           ` Marek Vasut
2015-12-31  3:09             ` Ley Foon Tan
2015-12-31  9:04               ` Marek Vasut [this message]
2016-01-03 23:29                 ` Ley Foon Tan
2016-01-03 23:36                   ` Marek Vasut
2016-01-04  0:10                     ` Ley Foon Tan
2016-01-04  0:37                       ` Marek Vasut
2016-01-04  0:53                         ` Ley Foon Tan
2016-01-04  1:12                           ` Marek Vasut
2016-01-05  0:45                             ` Ley Foon Tan
2016-01-05  0:47                               ` Marek Vasut
2016-01-05  1:18                                 ` Ley Foon Tan
2016-01-05  1:53                                   ` Marek Vasut
2016-01-05 13:49                                   ` Marek Vasut
2016-01-07  8:56                                     ` Ley Foon Tan
2016-01-07 16:05                                       ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201512311004.35234.marex@denx.de \
    --to=marex@denx.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).