From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 5/5] xen: arm: handle PCI DT node ranges and interrupt-map properties Date: Wed, 18 Feb 2015 15:31:03 +0000 Message-ID: <54E4B037.2000308@linaro.org> References: <1414144694.15687.31.camel@citrix.com> <1414144717-32328-5-git-send-email-ian.campbell@citrix.com> <54E37B62.4020101@linaro.org> <1424267412.27775.62.camel@citrix.com> <54E49F55.2010402@linaro.org> <1424270232.27775.83.camel@citrix.com> <54E4AA4E.3080501@linaro.org> <1424272693.20761.13.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1424272693.20761.13.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xen.org, Clark Laughlin , tim@xen.org, stefano.stabellini@eu.citrix.com, Pranavkumar Sawargaonkar List-Id: xen-devel@lists.xenproject.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