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 pci_bus
> +#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);
Here
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 reaso
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, 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 c
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
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 s
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
>> > --- a/arch/arm64/includ
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 IS
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 T
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 lo
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 sy
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 p
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 b/
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
> > +++ b/arch/arm64/include/asm
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
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 ++
arch/arm64/include/asm
25 matches
Mail list logo
