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

[Julien Grall <julien.grall@linaro.org>]

On 18/02/2015 15:18, Ian Campbell wrote:
> 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.

The code to do it is quite complicate and hard to maintain (actually 
it's a copy of the Linux one). It would be good if you can re-use the 
functions to translate in common/device_tree.c.

I think we may have the same problem for interrupts too.

Regards,

-- 
Julien Grall