From: thierry.reding@avionic-design•de (Thierry Reding)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs
Date: Tue, 18 Dec 2012 08:32:50 +0100 [thread overview]
Message-ID: <20121218073250.GA32572@avionic-0098.adnet.avionic-design.de> (raw)
In-Reply-To: <50CFD0B3.6030208@wwwdotorg.org>
On Mon, Dec 17, 2012 at 07:10:59PM -0700, Stephen Warren wrote:
> On 12/17/2012 12:41 PM, Thierry Reding wrote:
> > On Mon, Dec 17, 2012 at 11:29:11AM -0700, Jason Gunthorpe wrote:
> >>
> >>>> Ie route access for 00:1N.0 to the configuration space on
> >>>> bridge port N
> >>>
> >>> Is there any particular reason why you choose 0x10 as the base
> >>> slot for bridge ports? With the latest DT support patches,
> >>> mapping this should be even simpler as we associate a port
> >>> index with each port and the port array is gone.
> >>
> >> No specific reason, it similar to what intel did and clearly
> >> shows the port number in a octet of the device id. It just can't
> >> be 0.
> >
> > So I tried and implemented something along the lines of what you
> > suggested, and guess what? It does work indeed. For some reason
> > even the "imprecise external abort" goes away. Basically what I did
> > is fake the configuration space accesses to 0000:0.0 so that they
> > return semi-valid data. Nothing special yet, just basically
> > returning vendor and product ID, header type, class and other
> > static data.
> >
> > Initially the implementation was read-only and that still caused
> > the external abort, but adding nop'ed write functions apparently
> > solved that.
> >
> > What I'll do next is add some caching of written values, so that
> > reading them back actually yields something correct. After that
> > I'll post what I have so that others can look at it or even reuse
> > it.
>
> Some internal discussion implies this shouldn't be required; here's
> what they said:
>
> -----Original Message----- (from Chung-Hung Lai)
>
> All PCIE root port registers are in configuration space. To access
> them, as well as configuration registers of PCIE devices below the
> bridge, you will need to program the AXI to FPCI BAR mappings defined
> in AFI. After programmed those, the configuration register space of
> PCIE fabric are mapped to Tegra's MMIO register space. I take it back
> that T30 and [elided] have differences - that was for other units, not
> PCIE.
>
> As Mark said, all AFI's own registers are in MMIO space and can be
> accessed directly.
>
> Thanks,
> Luke
>
> -----Original Message----- (from Mark Van Nostrand)
>
> There are pci bridge registers but also registers to configure the
> PCIE wrapper. AFAIK all Tegra devices (T20/T30/[elided]) have
> compliant bridge registers but also need AFI (PCIE wrapper)
> configuration updates as well.
But none of the above matches the (sparse) documentation. The TRM
clearly states that each root port has a 4 KiB window that should be
used to access the root port's configuration space. The driver supports
that information.
I can also easily refute it by modifying the configuration space
accessor to look like this:
static int tegra_pcie_read_conf(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *value)
{
struct tegra_pcie *pcie = sys_to_pcie(bus->sysdata);
void __iomem *addr = NULL;
if (where >= 0x100)
return PCIBIOS_BAD_REGISTER_NUMBER;
addr = pcie->cs + PCIE_CONF_BUS(bus->number) +
PCIE_CONF_DEV(PCI_SLOT(devfn)) +
PCIE_CONF_FUNC(PCI_FUNC(devfn)) +
PCIE_CONF_REG(where);
*value = readl(addr);
if (size == 1)
*value = (*value >> (8 * (where & 3))) & 0xff;
else if (size == 2)
*value = (*value >> (8 * (where & 3))) & 0xffff;
return PCIBIOS_SUCCESSFUL;
}
and booting with that modification, which yields:
[ 3.097784] pci 0000:00:00.0: [1556:4711] type 01 class 0x060400
Which is the PLDA bridge within the FPGA, *not* the Tegra host bridge.
So either we're doing something really wrong when setting up the FPCI
BAR mappings or you guys need to get your information right.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121218/b78f1872/attachment.sig>
next prev parent reply other threads:[~2012-12-18 7:32 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-07 22:04 [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 01/16] lib: devres: don't enclose pcim_*() functions in CONFIG_HAS_IOPORT Thomas Petazzoni
2012-12-11 10:43 ` Arnd Bergmann
2012-12-11 16:03 ` Thomas Petazzoni
2012-12-11 16:15 ` Arnd Bergmann
2012-12-11 16:23 ` Russell King - ARM Linux
2012-12-11 16:38 ` Thomas Petazzoni
2012-12-11 16:50 ` Russell King - ARM Linux
2012-12-11 17:29 ` Alan Cox
2012-12-11 22:20 ` Arnd Bergmann
2012-12-11 22:34 ` Arnd Bergmann
2012-12-11 16:30 ` Thomas Petazzoni
2012-12-11 16:46 ` Russell King - ARM Linux
2012-12-11 17:32 ` Alan Cox
2012-12-11 22:28 ` Arnd Bergmann
2012-12-11 16:55 ` Russell King - ARM Linux
2012-12-11 16:26 ` Russell King - ARM Linux
2012-12-11 17:16 ` Alan Cox
2012-12-11 17:34 ` Russell King - ARM Linux
2012-12-11 17:45 ` Alan Cox
2012-12-11 17:51 ` Russell King - ARM Linux
2012-12-07 22:04 ` [RFC v1 02/16] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 03/16] arm: plat-orion: introduce WIN_CTRL_ENABLE in address mapping code Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 04/16] arm: plat-orion: refactor the orion_disable_wins() function Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 05/16] arm: plat-orion: introduce orion_{alloc, free}_cpu_win() functions Thomas Petazzoni
2012-12-08 11:53 ` [RFC v1 05/16] arm: plat-orion: introduce orion_{alloc,free}_cpu_win() functions Andrew Lunn
2012-12-08 12:15 ` Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 06/16] arm: mvebu: add functions to alloc/free PCIe decoding windows Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 07/16] arm: plat-orion: make common PCIe code usable on mvebu Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 08/16] arm: mvebu: the core PCIe driver Thomas Petazzoni
2012-12-10 8:28 ` Andrew Lunn
2012-12-10 8:45 ` Thomas Petazzoni
2012-12-10 19:08 ` Jason Gunthorpe
2012-12-11 10:56 ` Arnd Bergmann
2012-12-12 15:58 ` Thomas Petazzoni
2012-12-12 21:51 ` Jason Gunthorpe
2012-12-13 14:58 ` Arnd Bergmann
2012-12-13 17:40 ` Jason Gunthorpe
2012-12-13 19:09 ` Thomas Petazzoni
2012-12-14 19:34 ` Rob Herring
2012-12-13 12:19 ` Arnd Bergmann
2012-12-13 17:54 ` Jason Gunthorpe
2012-12-13 19:12 ` Thomas Petazzoni
2012-12-13 21:46 ` Arnd Bergmann
2012-12-13 22:27 ` Jason Gunthorpe
2012-12-07 22:04 ` [RFC v1 09/16] arm: mvebu: PCIe support is now available on mvebu Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 10/16] arm: mvebu: add PCIe Device Tree informations for Armada 370 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 11/16] arm: mvebu: add PCIe Device Tree informations for Armada XP Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 12/16] arm: mvebu: PCIe Device Tree informations for OpenBlocks AX3-4 Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 13/16] arm: mvebu: PCIe Device Tree informations for Armada XP DB Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 14/16] arm: mvebu: PCIe Device Tree informations for Armada 370 Mirabox Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 15/16] arm: mvebu: PCIe Device Tree informations for Armada 370 DB Thomas Petazzoni
2012-12-07 22:04 ` [RFC v1 16/16] arm: mvebu: update defconfig with PCI and USB support Thomas Petazzoni
2012-12-07 23:33 ` [RFC v1] PCIe support for the Armada 370 and Armada XP SoCs Jason Gunthorpe
2012-12-10 17:52 ` Stephen Warren
2012-12-10 18:05 ` Thomas Petazzoni
2012-12-10 18:16 ` Stephen Warren
2012-12-10 18:59 ` Thomas Petazzoni
2012-12-10 19:07 ` Jason Gunthorpe
2012-12-10 20:08 ` Stephen Warren
2012-12-10 18:44 ` Jason Gunthorpe
2012-12-10 19:03 ` Thomas Petazzoni
2012-12-10 19:18 ` Jason Gunthorpe
2012-12-12 16:04 ` Thomas Petazzoni
2012-12-12 20:09 ` Jason Gunthorpe
2012-12-16 13:02 ` Thierry Reding
2012-12-11 7:52 ` Thierry Reding
2012-12-11 21:21 ` Stephen Warren
2012-12-12 20:34 ` Thierry Reding
2012-12-12 22:30 ` Stephen Warren
2012-12-13 7:03 ` Thierry Reding
2012-12-13 8:04 ` Jason Gunthorpe
2012-12-13 8:23 ` Thierry Reding
2012-12-13 18:12 ` Stephen Warren
2012-12-13 20:42 ` Thierry Reding
2012-12-13 20:47 ` Jason Gunthorpe
2012-12-13 21:16 ` Thierry Reding
2012-12-14 10:05 ` Thierry Reding
2012-12-14 15:10 ` Thierry Reding
2012-12-14 17:27 ` Jason Gunthorpe
2012-12-16 12:33 ` Thierry Reding
2012-12-17 18:29 ` Jason Gunthorpe
2012-12-17 19:41 ` Thierry Reding
2012-12-18 2:10 ` Stephen Warren
2012-12-18 2:51 ` Jason Gunthorpe
2012-12-18 17:03 ` Stephen Warren
2012-12-20 15:32 ` Thierry Reding
2012-12-21 13:38 ` Jay Agarwal
2012-12-21 14:03 ` Thierry Reding
2012-12-22 14:50 ` Thomas Petazzoni
2012-12-28 21:06 ` Thierry Reding
2012-12-28 21:16 ` Thomas Petazzoni
2012-12-28 23:49 ` Stephen Warren
2012-12-29 8:09 ` Thomas Petazzoni
2012-12-31 16:40 ` Stephen Warren
2012-12-29 9:33 ` Thierry Reding
2012-12-31 16:44 ` Stephen Warren
2013-01-02 20:09 ` Jason Gunthorpe
2013-01-03 14:20 ` Thierry Reding
2012-12-28 23:51 ` Stephen Warren
2012-12-18 7:32 ` Thierry Reding [this message]
2013-01-03 14:39 ` Thierry Reding
2013-01-03 15:00 ` Bjorn Helgaas
2013-01-03 15:11 ` Thierry Reding
2013-01-03 15:09 ` Thomas Petazzoni
2013-01-03 15:56 ` Arnd Bergmann
2013-01-03 16:01 ` Thierry Reding
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=20121218073250.GA32572@avionic-0098.adnet.avionic-design.de \
--to=thierry.reding@avionic-design$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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