On Tue, Feb 18, 2014 at 02:33:53PM +0800, Yijing Wang wrote:
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +
> > +/*
> > + * Return the domain number for this bus
> > + */
> > +int pci_domain_nr(struct
On Tue, Feb 18, 2014 at 02:33:53PM +0800, Yijing Wang wrote:
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/of_pci.h
+#include linux/of_platform.h
+#include linux/slab.h
+
+#include asm/pci-bridge.h
+
+
+/*
+ *
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +
> +/*
> + * Return the domain number for this bus
> + */
> +int pci_domain_nr(struct pci_bus *bus)
> +{
> + struct pci_host_bridge *bridge = to_pci_host_bridge(bus->bridge);
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/of_pci.h
+#include linux/of_platform.h
+#include linux/slab.h
+
+#include asm/pci-bridge.h
+
+
+/*
+ * Return the domain number for this bus
+ */
+int pci_domain_nr(struct
On Tuesday 04 February 2014, Rob Herring wrote:
> > Here is how a sane person would read SBSA to create a compliant
> > implementation:
>
> s/sane/software/
> > Here is how a crazy person would read the same sentence in the SBSA:
>
> s/crazy/hardware/
Not much of a difference, apparently ...
On Tuesday 04 February 2014 12:10:55 Jason Gunthorpe wrote:
>
> For instance to support peer-to-peer IO you need to have a consisent,
> non-overlapping set of bus/device/function/tag to uniquely route TLPs
> within the chip. Cross domain TLP routing in HW is non-trivial.
Yes, that is a good
On Tue, Feb 04, 2014 at 07:34:50PM +0100, Arnd Bergmann wrote:
> Well, the way I see it, we already have support for arbitrary
> PCI domains in the kernel, and that works fine, so we can just
> as well use it. That way we don't have to partition the available
> 256 buses among the host bridges,
On Tuesday 04 February 2014 11:15:14 Jason Gunthorpe wrote:
> On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
>
> > Now I want to integrate the EHCI into my SoC and not waste one
> > of my precious PCIe root ports, so I have to create another PCI
> > domain with its own ECAM
On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
> Now I want to integrate the EHCI into my SoC and not waste one
> of my precious PCIe root ports, so I have to create another PCI
> domain with its own ECAM compliant config space to put it into.
> Fortunately SBSA lets me
On Tue, Feb 04, 2014 at 08:44:36AM +, Arnd Bergmann wrote:
> On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
> > On Mon, Feb 03, 2014 at 08:05:56PM +, Arnd Bergmann wrote:
> > > 2 MB was a compromise on arm32 to allow up to 32 PCI host bridges but not
> > > take up too much virtual
On Tuesday 04 February 2014, Andrew Murray wrote:
> On 4 February 2014 12:29, Liviu Dudau wrote:
> > On Mon, Feb 03, 2014 at 10:34:40PM +, Andrew Murray wrote:
> >> On 3 February 2014 18:43, Liviu Dudau wrote:
> >> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> >>
On Tue, Feb 4, 2014 at 3:44 AM, Arnd Bergmann wrote:
> On Monday 03 February 2014 16:31:37 Jason Gunthorpe wrote:
>> Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards
>> without clearly specifying exactly how PCI is suppose to work is
>> completely bonkers.
>>
>> What is needed
On 4 February 2014 12:29, Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 10:34:40PM +, Andrew Murray wrote:
>> On 3 February 2014 18:43, Liviu Dudau wrote:
>> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> > index 4cc813e..ce5bad2 100644
>> > ---
On Mon, Feb 03, 2014 at 10:34:40PM +, Andrew Murray wrote:
> On 3 February 2014 18:43, 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
>
On Tuesday 04 February 2014 11:09:22 Liviu Dudau wrote:
> On Tue, Feb 04, 2014 at 08:44:36AM +, Arnd Bergmann wrote:
> > Well, I/O space never starts at physical zero in reality, so it is
> > broken in practice. The CONFIG_GENERIC_IOMAP option tries to solve
> > the problem of I/O spaces that
On Tue, Feb 04, 2014 at 08:44:36AM +, Arnd Bergmann wrote:
> On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
> > On Mon, Feb 03, 2014 at 08:05:56PM +, Arnd Bergmann wrote:
> > > On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> > > > So ... defining it should mean no legacy
On Monday 03 February 2014 16:31:37 Jason Gunthorpe wrote:
> Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards
> without clearly specifying exactly how PCI is suppose to work is
> completely bonkers.
>
> What is needed is a spec that says:
> 1) Here is how you generate config
On Monday 03 February 2014 17:07:48 Rob Herring wrote:
> On Mon, Feb 3, 2014 at 2:05 PM, Arnd Bergmann wrote:
>
> You might want to re-read the SBSA. Unless ARM provides an IP block or
> there is some other standard such as EHCI or AHCI, there is no generic
> implementation. You only have to go
On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 08:05:56PM +, Arnd Bergmann wrote:
> > On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> > > So ... defining it should mean no legacy ISA devices, right?
> >
> > I would read that comment as referring to
On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
On Mon, Feb 03, 2014 at 08:05:56PM +, Arnd Bergmann wrote:
On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
So ... defining it should mean no legacy ISA devices, right?
I would read that comment as referring to systems
On Monday 03 February 2014 17:07:48 Rob Herring wrote:
On Mon, Feb 3, 2014 at 2:05 PM, Arnd Bergmann a...@arndb.de wrote:
You might want to re-read the SBSA. Unless ARM provides an IP block or
there is some other standard such as EHCI or AHCI, there is no generic
implementation. You only have
On Monday 03 February 2014 16:31:37 Jason Gunthorpe wrote:
Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards
without clearly specifying exactly how PCI is suppose to work is
completely bonkers.
What is needed is a spec that says:
1) Here is how you generate config TLPs.
On Tue, Feb 04, 2014 at 08:44:36AM +, Arnd Bergmann wrote:
On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
On Mon, Feb 03, 2014 at 08:05:56PM +, Arnd Bergmann wrote:
On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
So ... defining it should mean no legacy ISA
On Tuesday 04 February 2014 11:09:22 Liviu Dudau wrote:
On Tue, Feb 04, 2014 at 08:44:36AM +, Arnd Bergmann wrote:
Well, I/O space never starts at physical zero in reality, so it is
broken in practice. The CONFIG_GENERIC_IOMAP option tries to solve
the problem of I/O spaces that are
On Mon, Feb 03, 2014 at 10:34:40PM +, Andrew Murray wrote:
On 3 February 2014 18:43, Liviu Dudau liviu.du...@arm.com 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
+++
On 4 February 2014 12:29, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Feb 03, 2014 at 10:34:40PM +, Andrew Murray wrote:
On 3 February 2014 18:43, Liviu Dudau liviu.du...@arm.com wrote:
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 4cc813e..ce5bad2
On Tue, Feb 4, 2014 at 3:44 AM, Arnd Bergmann a...@arndb.de wrote:
On Monday 03 February 2014 16:31:37 Jason Gunthorpe wrote:
Specifying 'use EHCI, AHCI, etc' - which are all PCI based standards
without clearly specifying exactly how PCI is suppose to work is
completely bonkers.
What is
On Tuesday 04 February 2014, Andrew Murray wrote:
On 4 February 2014 12:29, Liviu Dudau liviu.du...@arm.com wrote:
On Mon, Feb 03, 2014 at 10:34:40PM +, Andrew Murray wrote:
On 3 February 2014 18:43, Liviu Dudau liviu.du...@arm.com wrote:
diff --git a/arch/arm64/include/asm/io.h
On Tue, Feb 04, 2014 at 08:44:36AM +, Arnd Bergmann wrote:
On Monday 03 February 2014 21:36:58 Liviu Dudau wrote:
On Mon, Feb 03, 2014 at 08:05:56PM +, Arnd Bergmann wrote:
2 MB was a compromise on arm32 to allow up to 32 PCI host bridges but not
take up too much virtual space. On
On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
Now I want to integrate the EHCI into my SoC and not waste one
of my precious PCIe root ports, so I have to create another PCI
domain with its own ECAM compliant config space to put it into.
Fortunately SBSA lets me add an
On Tuesday 04 February 2014 11:15:14 Jason Gunthorpe wrote:
On Tue, Feb 04, 2014 at 10:44:52AM +0100, Arnd Bergmann wrote:
Now I want to integrate the EHCI into my SoC and not waste one
of my precious PCIe root ports, so I have to create another PCI
domain with its own ECAM
On Tue, Feb 04, 2014 at 07:34:50PM +0100, Arnd Bergmann wrote:
Well, the way I see it, we already have support for arbitrary
PCI domains in the kernel, and that works fine, so we can just
as well use it. That way we don't have to partition the available
256 buses among the host bridges, and
On Tuesday 04 February 2014 12:10:55 Jason Gunthorpe wrote:
For instance to support peer-to-peer IO you need to have a consisent,
non-overlapping set of bus/device/function/tag to uniquely route TLPs
within the chip. Cross domain TLP routing in HW is non-trivial.
Yes, that is a good reason.
On Tuesday 04 February 2014, Rob Herring wrote:
Here is how a sane person would read SBSA to create a compliant
implementation:
s/sane/software/
Here is how a crazy person would read the same sentence in the SBSA:
s/crazy/hardware/
Not much of a difference, apparently ...
My money
On Mon, Feb 03, 2014 at 05:07:48PM -0600, Rob Herring wrote:
> > An interesting question however is what the transition plan is to
> > have the code shared between arm32 and arm64: We will certainly need
> > to share at least the dw-pcie and the generic SBSA compliant pci
> > implementation.
>
>
On Mon, Feb 3, 2014 at 2:05 PM, Arnd Bergmann wrote:
> On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
>> On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote:
>> > On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
[snip]
>> Agree. This is the RFC version. I didn't dare to
On 3 February 2014 18:43, 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
>
On Mon, Feb 03, 2014 at 08:05:56PM +, Arnd Bergmann wrote:
> On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> > On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote:
> > > On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
> > > > diff --git a/arch/arm64/include/asm/io.h
On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote:
> > 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
> > >
On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote:
> 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
> > +++
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
Use the generic host bridge functions to provide support for
PCI Express on arm64. There is no support for ISA memory.
Signed-off-by: Liviu Dudau
---
arch/arm64/Kconfig| 17 +++
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h | 4 ++
Use the generic host bridge functions to provide support for
PCI Express on arm64. There is no support for ISA memory.
Signed-off-by: Liviu Dudau liviu.du...@arm.com
---
arch/arm64/Kconfig| 17 +++
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h | 4 ++
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
On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote:
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
On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote:
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
---
On Mon, Feb 03, 2014 at 08:05:56PM +, Arnd Bergmann wrote:
On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote:
On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
diff --git a/arch/arm64/include/asm/io.h
On 3 February 2014 18:43, Liviu Dudau liviu.du...@arm.com 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
On Mon, Feb 3, 2014 at 2:05 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
On Mon, Feb 03, 2014 at 06:58:56PM +, Arnd Bergmann wrote:
On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
[snip]
Agree. This is the RFC version. I didn't
On Mon, Feb 03, 2014 at 05:07:48PM -0600, Rob Herring wrote:
An interesting question however is what the transition plan is to
have the code shared between arm32 and arm64: We will certainly need
to share at least the dw-pcie and the generic SBSA compliant pci
implementation.
You might
50 matches
Mail list logo
