From: "Pali Rohár" <pali@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Mauri Sandberg" <maukka@ext.kapsi.fi>,
linux-pci <linux-pci@vger.kernel.org>,
DTML <devicetree@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Andrew Lunn" <andrew@lunn.ch>,
"Sebastian Hesselbarth" <sebastian.hesselbarth@gmail.com>,
"Gregory CLEMENT" <gregory.clement@bootlin.com>,
"Russell King - ARM Linux" <linux@armlinux.org.uk>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH 2/2] PCI: mvebu: add support for orion5x
Date: Tue, 19 Jul 2022 11:46:49 +0200 [thread overview]
Message-ID: <20220719094649.pzyrqdvm3fm5fqh2@pali> (raw)
In-Reply-To: <CAK8P3a042yoLR0eqt4Bm0KH4X9SJhUsjKDh1S9M+MF6mU1mPNw@mail.gmail.com>
Hello!
On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> >
> > Add support for orion5x PCIe controller.
> >
> > There is Orion-specific errata that config space via CF8/CFC registers
> > is broken. Workaround documented in errata documented (linked from above
> > documentation) does not work when DMA is used and instead other
> > undocumented workaround is needed which maps config space to memory
> > (and therefore avoids usage of broken CF8/CFC memory mapped registers).
> >
> > Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> > Cc: Pali Rohár <pali@kernel.org>
>
> Nice job, glad you managed to figure this out!
>
> > diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> > index 7bcb41137bbf..9d8be5ce1266 100644
> > --- a/arch/arm/mach-orion5x/common.c
> > +++ b/arch/arm/mach-orion5x/common.c
> > @@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
> >
> > void orion5x_setup_wins(void)
> > {
> > - /*
> > - * The PCIe windows will no longer be statically allocated
> > - * here once Orion5x is migrated to the pci-mvebu driver.
> > - */
> > - mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> > - ORION_MBUS_PCIE_IO_ATTR,
> > - ORION5X_PCIE_IO_PHYS_BASE,
> > - ORION5X_PCIE_IO_SIZE,
> > - ORION5X_PCIE_IO_BUS_BASE);
> > - mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> > - ORION_MBUS_PCIE_MEM_ATTR,
> > - ORION5X_PCIE_MEM_PHYS_BASE,
> > - ORION5X_PCIE_MEM_SIZE);
> > mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
> > ORION_MBUS_PCI_IO_ATTR,
> > ORION5X_PCI_IO_PHYS_BASE,
>
> If the idea is to have the PCI_MVEBU driver only used for the DT based orion5x
> machines, but not the legacy board files, I suspect this breaks the legacy
> pci driver, unless you move the mbus configuration into the pcie_setup()
> function.
>
> > +/* Relevant only for Orion-1/Orion-NAS */
> > +#define ORION5X_PCIE_WA_PHYS_BASE 0xf0000000
> > +#define ORION5X_PCIE_WA_VIRT_BASE IOMEM(0xfd000000)
>
> You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> should already be part of the DT binding.
Of course! But the issue is that we do not know how to do this DT
binding. I have already wrote email with asking for help in which
property and which format should be this config range defined, but no
answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/
> There is little practical difference
> here, but I see no value in taking the shortcut here either.
>
> For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
>
> Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> implementation on ARM is smart enough to reuse the address from the static
> mapping in common.c, but will also keep working if that should go away.
I'm planning to work with Mauri on this, but current blocker is DT.
> > +#define ORION5X_PCIE_WA_SIZE SZ_16M
> > +#define ORION_MBUS_PCIE_WA_TARGET 0x04
> > +#define ORION_MBUS_PCIE_WA_ATTR 0x79
> > +
> > +static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
> > +{
> > + struct mvebu_pcie *pcie = bus->sysdata;
> > + struct mvebu_pcie_port *port;
> > +
> > + port = mvebu_pcie_find_port(pcie, bus, devfn);
> > + if (!port)
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > + if (!mvebu_pcie_link_up(port))
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > + /*
> > + * We only support access to the non-extended configuration
> > + * space when using the WA access method (or we would have to
> > + * sacrifice 256M of CPU virtual address space.)
> > + */
> > + if (where >= 0x100) {
> > + *val = 0xffffffff;
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > + }
> > +
> > + return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
> > +}
> > +
>
> This is probably good enough here, though I think you could also use
> the trick from drivers/pci/ecam.c and map each bus at a time.
>
> Arnd
Yes, there are also helper functions like map bus and etc. which could
simplify this code. I'm planning to do cleanups once we have fully
working driver for Orion.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-07-19 9:47 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 20:28 [PATCH 0/2] PCI: mvebu: add support for orion soc Mauri Sandberg
2022-07-18 20:28 ` [PATCH 1/2] dt-bindings: PCI: mvebu: Add orion5x compatible Mauri Sandberg
2022-07-22 0:27 ` Rob Herring
2022-07-18 20:28 ` [PATCH 1/6] dt-bindings: PCI: mvebu: Add orion compatible Mauri Sandberg
2022-07-18 20:33 ` Mauri Sandberg
2022-07-18 20:28 ` [PATCH 2/2] PCI: mvebu: add support for orion5x Mauri Sandberg
2022-07-19 8:05 ` Arnd Bergmann
2022-07-19 9:46 ` Pali Rohár [this message]
2022-07-19 10:16 ` Arnd Bergmann
2022-07-20 16:13 ` Pali Rohár
2022-07-20 16:43 ` Andrew Lunn
2022-07-20 17:11 ` Arnd Bergmann
2022-07-20 17:40 ` Rob Herring
2022-07-20 17:53 ` Pali Rohár
2022-07-20 11:36 ` [PATCH 0/2] PCI: mvebu: add support for orion soc Arnd Bergmann
2022-07-29 17:22 ` Bjorn Helgaas
2022-07-30 13:21 ` Mauri Sandberg
2022-08-02 17:34 ` [PATCH v2 " Mauri Sandberg
2022-08-02 17:34 ` [PATCH v2 1/2] dt-bindings: PCI: mvebu: Add orion5x compatible Mauri Sandberg
2022-08-02 17:34 ` [PATCH v2 2/2] PCI: mvebu: add support for orion5x Mauri Sandberg
2022-08-25 15:15 ` Lorenzo Pieralisi
2022-08-25 16:00 ` Pali Rohár
2022-08-26 8:42 ` Lorenzo Pieralisi
2022-08-02 17:49 ` [PATCH v2 0/2] PCI: mvebu: add support for orion soc Pali Rohár
2022-09-05 19:23 ` [PATCH v3 0/7] " Pali Rohár
2022-09-05 19:23 ` [PATCH v3 1/7] ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to pcie_setup() Pali Rohár
2022-09-05 19:23 ` [PATCH v3 2/7] bus: mvebu-mbus: add configuration space aperture Pali Rohár
2022-09-05 19:23 ` [PATCH v3 3/7] dt-bindings: PCI: mvebu: Add orion5x compatible Pali Rohár
2022-09-06 16:20 ` Rob Herring
2022-09-05 19:23 ` [PATCH v3 4/7] PCI: mvebu: Remove unused busn member Pali Rohár
2022-09-05 19:23 ` [PATCH v3 5/7] PCI: mvebu: Cleanup error handling in mvebu_pcie_probe() Pali Rohár
2022-09-05 19:23 ` [PATCH v3 6/7] PCI: mvebu: Add support for Orion PCIe controller Pali Rohár
2022-09-05 19:23 ` [PATCH v3 7/7] ARM: dts: orion5x: Add PCIe node Pali Rohár
2022-09-16 12:25 ` [PATCH v3 0/7] PCI: mvebu: add support for orion soc Lorenzo Pieralisi
2022-10-27 14:10 ` Lorenzo Pieralisi
2022-11-06 23:28 ` Pali Rohár
2022-11-11 12:49 ` Lorenzo Pieralisi
2022-11-11 16:54 ` Pali Rohár
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=20220719094649.pzyrqdvm3fm5fqh2@pali \
--to=pali@kernel.org \
--cc=andrew@lunn.ch \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=gregory.clement@bootlin.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=lpieralisi@kernel.org \
--cc=maukka@ext.kapsi.fi \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
/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