linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jgunthorpe@obsidianresearch.com (Jason Gunthorpe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 01/10] PCI: host: rcar: Add Renesas R-Car PCIe driver
Date: Mon, 28 Apr 2014 14:35:01 -0600	[thread overview]
Message-ID: <20140428203501.GA3016@obsidianresearch.com> (raw)
In-Reply-To: <CAErSpo6Autto4n4A4wHtXQNJzD3RKevkVcLZHUods-2-eiRDYQ@mail.gmail.com>

On Mon, Apr 28, 2014 at 01:11:08PM -0600, Bjorn Helgaas wrote:

> >> That bus number should be a property of the host bridge, i.e.,
> >> it's either hard-wired into the bridge, or it's programmable somewhere.
> >> But root_bus_nr comes from sys->busnr, which is apparently from some
> >> generic code that knows nothing about this particular host bridge.

> > The manual for this hardware says that the HW doesn't care what the bus number
> > is set to. The only thing the HW needs to know is that when sending config
> > accesses, we need to indicate whether it's a TYPE0 or TYPE1 header; so we use
> > root_bus_nr to determine this. The generic code that sets up sys->busnr (ARM
> > bios32 in this case), just increments bus number for each controller.

I went back and looked at the lspci posted for this hardware and this
use of busnr is kinda sketch..

You should use use bus 0 as the root complex integrated bus number and
ensure every instance of your driver creates a new PCI domain, and
generally use 0-> FF as the subordinate bus number range.

FWIW, your HW does care, and does have a programmable field for
this.

You set the value of the integrated bus based on the bus number in the
TYPE0 accesses the driver performs and it shows up in the PCI config
space of the root port bridge:

root at koelsch:~# lspci -vv
00:00.0 PCI bridge: Renesas Technology Corp. Device 001f (prog-if 00
[Normal decode])
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0

The value here will be also be exported on-the-wire in certain PCI-E
TLPs.

So it is important, and must be set properly.

> Yeah, I guess.  If the HW really doesn't look at the bus number at
> all, it sounds like the range is effectively 00-ff, and each host
> bridge should be in its own domain.

This is where some of the other implementations have used some SW to
route config space in a single domain to the proper controller
per-port register set.

But, IMHO, that is mainly worth doing if the HW can implement the PCI
bridge windows according to the spec, and it looks like rcar requires
a 128MB alignment on the bridge windows, which makes it fairly
pointless.

Jason

  reply	other threads:[~2014-04-28 20:35 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-31 10:30 [PATCH v7 00/10] R-Car Gen2 PCIe host driver Phil Edworthy
2014-03-31 10:30 ` [PATCH v7 01/10] PCI: host: rcar: Add Renesas R-Car PCIe driver Phil Edworthy
2014-04-24 19:19   ` Bjorn Helgaas
2014-04-28 10:03     ` Phil Edworthy
2014-04-28 19:11       ` Bjorn Helgaas
2014-04-28 20:35         ` Jason Gunthorpe [this message]
2014-04-30 10:33           ` Phil Edworthy
2014-04-30 15:43             ` Jason Gunthorpe
2014-05-01  9:50               ` Phil Edworthy
2014-05-01 16:50                 ` Jason Gunthorpe
2014-05-06 10:46                   ` Phil Edworthy
2014-05-01 17:31                 ` Bjorn Helgaas
2014-05-06 12:49                   ` Phil Edworthy
2014-04-30 10:20         ` Phil Edworthy
2014-03-31 10:30 ` [PATCH v7 02/10] PCI: host: rcar: Add MSI support Phil Edworthy
2014-04-04  8:53   ` Lucas Stach
2014-03-31 10:30 ` [PATCH v7 03/10] ARM: shmobile: r8a7790: Add PCIe clock device tree nodes Phil Edworthy
2014-03-31 10:30 ` [PATCH v7 04/10] ARM: shmobile: r8a7791: " Phil Edworthy
2014-03-31 10:30 ` [PATCH v7 05/10] dt-bindings: pci: rcar pcie device tree bindings Phil Edworthy
2014-04-04  9:08   ` Lucas Stach
2014-03-31 10:30 ` [PATCH v7 06/10] ARM: shmobile: r8a7790: Add PCIe device nodes Phil Edworthy
2014-03-31 10:30 ` [PATCH v7 07/10] ARM: shmobile: lager: " Phil Edworthy
2014-03-31 10:30 ` [PATCH v7 08/10] ARM: shmobile: r8a7791: " Phil Edworthy
2014-03-31 10:30 ` [PATCH v7 09/10] ARM: shmobile: koelsch: " Phil Edworthy
2014-03-31 10:30 ` [PATCH v7 10/10] ARM: shmobile: koelsch: Add PCIe to defconfig Phil Edworthy
2014-04-04  8:22 ` [PATCH v7 00/10] R-Car Gen2 PCIe host driver Phil Edworthy
2014-04-04  8:30 ` Phil Edworthy

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=20140428203501.GA3016@obsidianresearch.com \
    --to=jgunthorpe@obsidianresearch.com \
    --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).