Re: [Xen-devel] [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Wed, 2015-02-18 at 15:05 +0000, Julien Grall wrote:
> 
> On 18/02/2015 14:37, Ian Campbell wrote:
> > On Wed, 2015-02-18 at 14:19 +0000, Julien Grall wrote:
> > I think so, and we probably should consider the two cases separately
> > since the right answer could reasonably differ for different resource
> > types.
> >
> > I am reasonably convinced that for MMIO (+IO+CFG space) we should map
> > everything as described by the ranges property of the top most node, it
> > can be considered an analogue to / extension of the reg property of that
> > node.
> 
> Agreed.
> 
> > For IRQ I'm not so sure, it's possible that routing the IRQ at
> > pci_add_device time might be better, or fit in better with e.g. the ACPI
> > architecture, but mapping everything described in interrupt-map at start
> > of day is also an option and a reasonably simple one, probably.
> 
> I agree that it's simple. Are we sure that we would be able to get a 
> "better" solution later without modifying the kernel?
> 
> If not, we may need to keep this solution forever.

True. I suppose feature flags would be one way out, but not a very
convenient one..

> > This isn't to do with IPA->PA translations but to do with translations
> > between different PA addressing regimes. i.e. the different addressing
> > schemes of difference busses.
> 
> I meant bus address. The name "intermediate address" was misused, sorry.
> 
> > Lets say we have a system with a PCI-ROOT device exposing a PCI bus,
> > which in turn contains a PCI-BRIDGE which for the sake of argument lets
> > say is a PCI-FOOBUS bridge.
> 
> > Lets just consider the MMIO hole for now, but IRQ is basically the same.
> >
> > The ranges property on a node describes a mapping from a "parent"
> > address space into a "child" address space.
> >
> > For PCI-ROOT "parent" is the host physical address space and "child" is
> > the PCI MMIO/IO/CFG address spaces.
> >
> > For PCI-BRIDGE "parent" is the PCI-ROOT's child address space (i.e. PCI
> > MMIO/IO/CFG) and "child" is the FOOBUS address space.
> >
> > The inputs ("parents") of the PCI-BRIDGE ranges property must therefore
> > by definition be valid outputs of the PCI-ROOT ranges property (i.e. be
> > "child" addresses).
> >
> > Therefore if we map all of the input/parent ranges described by
> > PCI-ROOT's ranges property we do not need to recurse further and
> > consider PCI-BRIDGE's ranges property -- we've effectively already dealt
> > with it.
> >
> > Does that make more sense?
> 
> I'm still confused, what prevents the PCI-ROOT device to not be 
> connected to another bus?
>
> In device tree format, that would give something like:
> 
> / {
> 
>    soc {
>       ranges = "...";
> 
>       pcie {
>         ranges = "...";
>       }
>    }
> }
> 
> The address retrieved from the PCI-ROOT would be a bus address and not a 
> physical address.

Hrm, nothing, I see what you are getting at now.

Either soc has a device_type property which we understand, in which case
we would handle it and stop recursing or (more likely for an soc) it
does not, in which case we would handle the pcie ranges property, but it
needs to be translated through the ranges property of soc, which the
patch doesn't do and probably it should.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel