From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>,
Clark Laughlin <clark.laughlin@linaro.org>,
tim@xen.org, stefano.stabellini@eu.citrix.com,
xen-devel@lists.xen.org
Subject: Re: [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties
Date: Wed, 18 Feb 2015 15:16:55 +0000 [thread overview]
Message-ID: <54E4ACE7.4040106@linaro.org> (raw)
In-Reply-To: <54E4AA4E.3080501@linaro.org>
On 18/02/2015 15:05, 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.
>
>> 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 = "...";
> }
> }
> }
Actually the device tree of the x-gene board has something similar.
/ {
soc {
ranges;
pcie {
ranges = "...";
}
}
"ranges;" means there is not translation necessary. But nothing prevent
to have a the property "ranges" set.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-02-18 15:16 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-24 9:58 [PATCH for-4.6 0/5] xen: arm: Parse PCI DT nodes' ranges and interrupt-map Ian Campbell
2014-10-24 9:58 ` [PATCH 1/5] xen: arm: propagate gic's #address-cells property to dom0 Ian Campbell
2014-10-29 19:03 ` Julien Grall
2014-10-30 10:06 ` Ian Campbell
2014-10-30 10:31 ` Julien Grall
2014-11-04 10:23 ` Ian Campbell
2014-11-04 17:11 ` Konrad Rzeszutek Wilk
2014-11-05 10:47 ` Ian Campbell
2014-10-24 9:58 ` [PATCH 2/5] xen: device-tree: add accessors for the addr/size-cells of a node's children Ian Campbell
2014-10-24 9:58 ` [PATCH 3/5] xen: arm: Add DT_NR_GIC_INTERRUPT_CELLS rather than hardcoding 3 Ian Campbell
2014-10-24 9:58 ` [PATCH 4/5] xen: refactor irq_set_type out of platform_get_irq Ian Campbell
2014-10-24 9:58 ` [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties Ian Campbell
2015-02-17 17:33 ` Julien Grall
2015-02-18 13:50 ` Ian Campbell
2015-02-18 14:19 ` Julien Grall
2015-02-18 14:37 ` Ian Campbell
2015-02-18 15:05 ` Julien Grall
2015-02-18 15:16 ` Julien Grall [this message]
2015-03-05 12:43 ` Ian Campbell
2015-03-05 15:59 ` Julien Grall
2015-02-18 15:18 ` Ian Campbell
2015-02-18 15:31 ` Julien Grall
2015-02-18 15:44 ` Ian Campbell
2015-02-18 15:13 ` Julien Grall
2015-02-18 15:21 ` Ian Campbell
2015-02-16 3:49 ` [PATCH for-4.6 0/5] xen: arm: Parse PCI DT nodes' ranges and interrupt-map Suravee Suthikulpanit
2015-02-16 10:12 ` Julien Grall
[not found] ` <54E2AFCC.3090302@amd.com>
2015-02-17 13:43 ` Julien Grall
2015-02-17 13:50 ` Andrew Cooper
2015-02-17 22:35 ` Suravee Suthikulanit
2015-02-18 0:31 ` Suravee Suthikulanit
2015-02-18 5:28 ` Suravee Suthikulanit
2015-02-18 12:48 ` Julien Grall
2015-02-18 20:13 ` Suravee Suthikulanit
2015-02-19 5:16 ` Manish
2015-02-19 8:14 ` Jan Beulich
2015-02-19 8:47 ` Manish
2015-02-19 13:46 ` Julien Grall
2015-02-18 7:58 ` Jan Beulich
2015-02-18 13:52 ` Ian Campbell
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=54E4ACE7.4040106@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=clark.laughlin@linaro.org \
--cc=pranavkumar@linaro.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).