From: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
To: barebox@lists.infradead.org
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Subject: Re: [PATCH RESEND 6/6] pci: mvebu: Add PCIe driver
Date: Wed, 23 Jul 2014 12:35:20 +0200 [thread overview]
Message-ID: <53CF8FE8.8010806@gmail.com> (raw)
In-Reply-To: <1406107568-8440-7-git-send-email-sebastian.hesselbarth@gmail.com>
On 07/23/2014 11:26 AM, Sebastian Hesselbarth wrote:
> This adds a PCI driver for the controllers found on Marvell MVEBU SoCs.
> Besides the functional driver itself, it also adds SoC specific PHY
> setup required for PCIe. Currently, only Armada 370 is fully supported.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
[...]
> diff --git a/drivers/pci/pci-mvebu.c b/drivers/pci/pci-mvebu.c
> new file mode 100644
> index 000000000000..6fee0800e98e
> --- /dev/null
> +++ b/drivers/pci/pci-mvebu.c
> @@ -0,0 +1,436 @@
> +/*
> + * PCIe driver for Marvell MVEBU SoCs
> + *
> + * Based on Linux drivers/pci/host/pci-mvebu.c
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
[...]
> +static int mvebu_pcie_indirect_rd_conf(struct pci_bus *bus,
> + unsigned int devfn, int where, int size, u32 *val)
> +{
> + struct pci_controller *pci = bus->sysdata;
> + struct mvebu_pcie *pcie = to_pcie(pci);
> +
> + /* Skip all requests not directed to device behind bridge */
> + if (devfn != 0x08 || !mvebu_pcie_link_up(pcie)) {
nit: this and below should be
if (devfn != pcie->devfn || !mvebu_pcie_link_up(pcie))
Still, I have no clue how link state can be determined for
individual lanes on Armada XP. But I think this has to be fixed
up when we stumble upon it on a XP board that makes use of 4x1
PCIe slots.
> + *val = 0xffffffff;
> + return PCIBIOS_DEVICE_NOT_FOUND;
> + }
> +
> + writel(PCIE_CONF_ADDR(bus->number, devfn, where),
> + pcie->base + PCIE_CONF_ADDR_OFF);
> +
> + *val = readl(pcie->base + PCIE_CONF_DATA_OFF);
> +
> + if (size == 1)
> + *val = (*val >> (8 * (where & 3))) & 0xff;
> + else if (size == 2)
> + *val = (*val >> (8 * (where & 3))) & 0xffff;
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> +static int mvebu_pcie_indirect_wr_conf(struct pci_bus *bus,
> + unsigned int devfn, int where, int size, u32 val)
> +{
> + struct pci_controller *pci = bus->sysdata;
> + struct mvebu_pcie *pcie = to_pcie(pci);
> + u32 _val, shift = 8 * (where & 3);
> +
> + /* Skip all requests not directed to device behind bridge */
> + if (devfn != 0x08 || !mvebu_pcie_link_up(pcie))
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +
> + writel(PCIE_CONF_ADDR(bus->number, devfn, where),
> + pcie->base + PCIE_CONF_ADDR_OFF);
> + _val = readl(pcie->base + PCIE_CONF_DATA_OFF);
> +
> + if (size == 4)
> + _val = val;
> + else if (size == 2)
> + _val = (_val & ~(0xffff << shift)) | ((val & 0xffff) << shift);
> + else if (size == 1)
> + _val = (_val & ~(0xff << shift)) | ((val & 0xff) << shift);
> + else
> + return PCIBIOS_BAD_REGISTER_NUMBER;
> +
> + writel(_val, pcie->base + PCIE_CONF_DATA_OFF);
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
[...]
> +static struct mvebu_pcie *mvebu_pcie_port_probe(struct device_d *dev,
> + struct device_node *np)
> +{
[...]
> + pcie->membase = mvebu_pcie_membase;
> + pcie->mem.start = 0;
> + pcie->mem.end = pcie->mem.start + SZ_32M - 1;
> + if (mvebu_mbus_add_window_remap_by_id(mem_target, mem_attr,
> + (resource_size_t)pcie->membase, resource_size(&pcie->mem), 0)) {
> + dev_err(dev, "PCIe%d.%d unable to add mbus window for mem at %08x+%08x",
> + port, lane, (u32)pcie->mem.start, resource_size(&pcie->mem));
> +
> + free(pcie);
> + return ERR_PTR(-EBUSY);
> + }
> + mvebu_pcie_membase += SZ_32M;
Thinking about the 10 possible lanes on Armada XP, this size will
collide with internal registers for the last two as we are starting
from 0xe0000000. Either we limit the MEM size to 16M now or again wait
for any board suffering from it.
I see no point in adding any dynamic window resize now.
Sebastian
> + if (io_target >= 0 && io_attr >= 0) {
> + pcie->iobase = mvebu_pcie_iobase;
> + pcie->io.start = 0;
> + pcie->io.end = pcie->io.start + SZ_64K - 1;
> +
> + mvebu_mbus_add_window_remap_by_id(io_target, io_attr,
> + (resource_size_t)pcie->iobase, resource_size(&pcie->io), 0);
> + mvebu_pcie_iobase += SZ_64K;
> + }
> +
> + clk = of_clk_get(np, 0);
> + if (!IS_ERR(clk))
> + clk_enable(clk);
> +
> + pcie->pci.pci_ops = &mvebu_pcie_indirect_ops;
> + pcie->pci.mem_resource = &pcie->mem;
> + pcie->pci.io_resource = &pcie->io;
> +
> + return pcie;
> +}
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2014-07-23 10:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-23 9:26 [PATCH RESEND 0/6] Marvell EBU " Sebastian Hesselbarth
2014-07-23 9:26 ` [PATCH RESEND 1/6] bus: mvebu: fix resource size handling Sebastian Hesselbarth
2014-07-23 9:26 ` [PATCH RESEND 2/6] pci: pci_scan_bus: respect 64b BARs Sebastian Hesselbarth
2014-07-25 8:51 ` Lucas Stach
2014-07-25 14:43 ` Sebastian Hesselbarth
2014-07-23 9:26 ` [PATCH RESEND 3/6] pci: add host controller struct to sysdata Sebastian Hesselbarth
2014-07-25 9:07 ` Lucas Stach
2014-07-25 14:54 ` Sebastian Hesselbarth
2014-07-23 9:26 ` [PATCH RESEND 4/6] pci: allow to set bus number on register_pci_controller Sebastian Hesselbarth
2014-07-23 9:26 ` [PATCH RESEND 5/6] of: pci: import of_pci_get_devfn() Sebastian Hesselbarth
2014-07-23 9:26 ` [PATCH RESEND 6/6] pci: mvebu: Add PCIe driver Sebastian Hesselbarth
2014-07-23 10:35 ` Sebastian Hesselbarth [this message]
2014-07-25 7:27 ` Sascha Hauer
2014-07-25 15:00 ` Sebastian Hesselbarth
2014-07-28 5:19 ` Sascha Hauer
2014-07-28 6:10 ` Sebastian Hesselbarth
2014-07-25 9:16 ` Lucas Stach
2014-07-25 14:57 ` Sebastian Hesselbarth
2014-07-28 13:26 ` [PATCH v2 0/5] Marvell EBU " Sebastian Hesselbarth
2014-07-28 13:26 ` [PATCH v2 1/5] bus: mvebu: fix resource size handling Sebastian Hesselbarth
2014-07-28 13:26 ` [PATCH v2 2/5] pci: pci_scan_bus: respect 64b BARs Sebastian Hesselbarth
2014-07-28 13:26 ` [PATCH v2 3/5] pci: set auto-incremented bus number Sebastian Hesselbarth
2014-07-28 13:26 ` [PATCH v2 4/5] of: pci: import of_pci_get_devfn() Sebastian Hesselbarth
2014-07-28 13:26 ` [PATCH v2 5/5] pci: mvebu: Add PCIe driver Sebastian Hesselbarth
2014-07-29 19:58 ` [PATCH v2 0/5] Marvell EBU " Sebastian Hesselbarth
2014-07-30 6:21 ` Sascha Hauer
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=53CF8FE8.8010806@gmail.com \
--to=sebastian.hesselbarth@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=thomas.petazzoni@free-electrons.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