From: Arnd Bergmann <arnd@arndb.de>
To: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: linux-pci <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
LAKML <linux-arm-kernel@lists.infradead.org>,
linaro-kernel <linaro-kernel@lists.linaro.org>
Subject: Re: [PATCH] arm64: Add architecture support for PCI
Date: Mon, 03 Feb 2014 19:58:56 +0100 [thread overview]
Message-ID: <21596846.kVTqp7roW4@wuerfel> (raw)
In-Reply-To: <1391453028-23191-2-git-send-email-Liviu.Dudau@arm.com>
On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 4cc813e..ce5bad2 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> /*
> * I/O port access primitives.
> */
> +#define arch_has_dev_port() (0)
Why not?
> #define IO_SPACE_LIMIT 0xffff
You probably want to increase this a bit, to allow multiple host bridges
to have their own I/O space.
> #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
And modify this location: There is no particular reason to have the I/O space
mapped exactly 2MB below the loadable modules, as virtual address space is
essentially free.
> +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> +#define ioport_unmap(addr)
inline functions?
> static inline u8 inb(unsigned long addr)
> {
> return readb(addr + PCI_IOBASE);
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..dd084a3
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,35 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/dma-mapping.h>
> +
> +#include <asm/io.h>
> +#include <asm-generic/pci-bridge.h>
> +#include <asm-generic/pci-dma-compat.h>
> +
> +#define PCIBIOS_MIN_IO 0
> +#define PCIBIOS_MIN_MEM 0
PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> new file mode 100644
> index 0000000..7b652cf
> --- /dev/null
> +++ b/arch/arm64/kernel/pci.c
> @@ -0,0 +1,112 @@
None of this looks really arm64 specific, nor should it be. I think
we should try a little harder to move this as a default implementation
into common code, even if we start out by having all architectures
override it.
> +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
> +{
> + BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
> +
> + return ioremap_page_range((unsigned long)PCI_IOBASE + offset,
> + (unsigned long)PCI_IOBASE + offset + SZ_64K,
> + phys_addr,
> + __pgprot(PROT_DEVICE_nGnRE));
> +}
Not sure if we want to treat this one as architecture specific though.
It certainly won't be portable to x86, but it could be shared with
a couple of others. We may also want to redesign the interface.
I've been thinking we could make this function allocate space in the
Linux virtual I/O space aperture, and pass two resources into it
(physical I/O aperture and bus I/O range), and get the actual
io_offset as the return value, or a negative error number.
That way, you could have an arbitrary number of host bridges in the
system and each one gets a share of the virtual aperture until
it's full.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Add architecture support for PCI
Date: Mon, 03 Feb 2014 19:58:56 +0100 [thread overview]
Message-ID: <21596846.kVTqp7roW4@wuerfel> (raw)
In-Reply-To: <1391453028-23191-2-git-send-email-Liviu.Dudau@arm.com>
On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 4cc813e..ce5bad2 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> /*
> * I/O port access primitives.
> */
> +#define arch_has_dev_port() (0)
Why not?
> #define IO_SPACE_LIMIT 0xffff
You probably want to increase this a bit, to allow multiple host bridges
to have their own I/O space.
> #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
And modify this location: There is no particular reason to have the I/O space
mapped exactly 2MB below the loadable modules, as virtual address space is
essentially free.
> +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> +#define ioport_unmap(addr)
inline functions?
> static inline u8 inb(unsigned long addr)
> {
> return readb(addr + PCI_IOBASE);
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..dd084a3
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,35 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/dma-mapping.h>
> +
> +#include <asm/io.h>
> +#include <asm-generic/pci-bridge.h>
> +#include <asm-generic/pci-dma-compat.h>
> +
> +#define PCIBIOS_MIN_IO 0
> +#define PCIBIOS_MIN_MEM 0
PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> new file mode 100644
> index 0000000..7b652cf
> --- /dev/null
> +++ b/arch/arm64/kernel/pci.c
> @@ -0,0 +1,112 @@
None of this looks really arm64 specific, nor should it be. I think
we should try a little harder to move this as a default implementation
into common code, even if we start out by having all architectures
override it.
> +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
> +{
> + BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
> +
> + return ioremap_page_range((unsigned long)PCI_IOBASE + offset,
> + (unsigned long)PCI_IOBASE + offset + SZ_64K,
> + phys_addr,
> + __pgprot(PROT_DEVICE_nGnRE));
> +}
Not sure if we want to treat this one as architecture specific though.
It certainly won't be portable to x86, but it could be shared with
a couple of others. We may also want to redesign the interface.
I've been thinking we could make this function allocate space in the
Linux virtual I/O space aperture, and pass two resources into it
(physical I/O aperture and bus I/O range), and get the actual
io_offset as the return value, or a negative error number.
That way, you could have an arbitrary number of host bridges in the
system and each one gets a share of the virtual aperture until
it's full.
Arnd
next prev parent reply other threads:[~2014-02-03 18:59 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-03 18:43 [PATCH] [RFC] Add AArch64 support for PCI Liviu Dudau
2014-02-03 18:43 ` Liviu Dudau
2014-02-03 18:43 ` Liviu Dudau
2014-02-03 18:43 ` [PATCH] arm64: Add architecture " Liviu Dudau
2014-02-03 18:43 ` Liviu Dudau
2014-02-03 18:58 ` Arnd Bergmann [this message]
2014-02-03 18:58 ` Arnd Bergmann
2014-02-03 19:18 ` Liviu Dudau
2014-02-03 19:18 ` Liviu Dudau
2014-02-03 19:21 ` kodiak furr
2014-02-03 20:05 ` Arnd Bergmann
2014-02-03 20:05 ` Arnd Bergmann
2014-02-03 21:36 ` Liviu Dudau
2014-02-03 21:36 ` Liviu Dudau
2014-02-04 8:44 ` Arnd Bergmann
2014-02-04 8:44 ` Arnd Bergmann
2014-02-04 11:09 ` Liviu Dudau
2014-02-04 11:09 ` Liviu Dudau
2014-02-04 11:54 ` Arnd Bergmann
2014-02-04 11:54 ` Arnd Bergmann
2014-02-04 11:54 ` Arnd Bergmann
2014-02-04 16:41 ` Catalin Marinas
2014-02-04 16:41 ` Catalin Marinas
2014-02-03 23:07 ` Rob Herring
2014-02-03 23:07 ` Rob Herring
2014-02-03 23:31 ` Jason Gunthorpe
2014-02-03 23:31 ` Jason Gunthorpe
2014-02-04 9:44 ` Arnd Bergmann
2014-02-04 9:44 ` Arnd Bergmann
2014-02-04 9:44 ` Arnd Bergmann
2014-02-04 13:57 ` Rob Herring
2014-02-04 13:57 ` Rob Herring
2014-02-04 19:50 ` Arnd Bergmann
2014-02-04 19:50 ` Arnd Bergmann
2014-02-04 19:50 ` Arnd Bergmann
2014-02-04 18:15 ` Jason Gunthorpe
2014-02-04 18:15 ` Jason Gunthorpe
2014-02-04 18:34 ` Arnd Bergmann
2014-02-04 18:34 ` Arnd Bergmann
2014-02-04 18:34 ` Arnd Bergmann
2014-02-04 19:10 ` Jason Gunthorpe
2014-02-04 19:10 ` Jason Gunthorpe
2014-02-04 19:21 ` Arnd Bergmann
2014-02-04 19:21 ` Arnd Bergmann
2014-02-04 9:01 ` Arnd Bergmann
2014-02-04 9:01 ` Arnd Bergmann
2014-02-03 22:34 ` Andrew Murray
2014-02-03 22:34 ` Andrew Murray
2014-02-03 22:34 ` Andrew Murray
2014-02-04 12:29 ` Liviu Dudau
2014-02-04 12:29 ` Liviu Dudau
2014-02-04 13:23 ` Andrew Murray
2014-02-04 13:23 ` Andrew Murray
2014-02-04 16:18 ` Arnd Bergmann
2014-02-04 16:18 ` Arnd Bergmann
2014-02-04 16:18 ` Arnd Bergmann
2014-02-18 6:33 ` Yijing Wang
2014-02-18 6:33 ` Yijing Wang
2014-02-20 14:38 ` Liviu Dudau
2014-02-20 14:38 ` Liviu Dudau
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=21596846.kVTqp7roW4@wuerfel \
--to=arnd@arndb.de \
--cc=Catalin.Marinas@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Will.Deacon@arm.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.