[PATCH v2 3/3] PCI: ARM: add support for generic PCI host controller

[Bjorn Helgaas]

On Wed, Feb 19, 2014 at 2:58 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Tuesday 18 February 2014 17:28:14 Bjorn Helgaas wrote:
>> On Sat, Feb 15, 2014 at 02:03:26PM +0100, Arnd Bergmann wrote:
>> > On Friday 14 February 2014 22:00:47 Liviu Dudau wrote:
>> >
>> > Can anyone with more experience on the subject than me (Bjorn,
>> > Russell, Jason, ...) think of a reason why we would not want to
>> > just use a new domain for every host bridge we find?
>>
>> With ACPI on x86 and ia64, we currently use _SEG directly as the Linux
>> PCI domain.  Are you proposing that we make the Linux PCI domain
>> independent of _SEG?
>
> I don't think we should change anything for ACPI.
> The point is that we don't currently have the equivalent of _SEG
> for DT probing. The best two options we have are:
>
> a) introduce a 'pci-segment' property with the same meaning as _SEG
> on ACPI, and use that as the domain number
>
> b) don't introduce the segment concept on DT but just give each
> host bridge its own domain.
>
> The second one seems a little easier to implement, and I don't
> see what _SEG is used for other than to avoid having domains
> when you don't need them. Is there more to it that I'm missing?

Not really, but I do have a question related to OS management of host
bridge bus number apertures.  Currently, Linux never changes a host
bridge's bus number range, but it's conceivable that we could in some
hotplug scenario.  ACPI does provide a mechanism to do so (_PRS,
_SRS), and other host bridge drivers could also do this by programming
CSRs to change the bus number range.  The PCI domain is the logical
place to manage allocation of the 00-ff range of bus numbers.

1) x86 platforms may have constraints because PCIBIOS and the 0xcf8
config access mechanism are unaware of segments.  If a platform has to
support legacy OSes that use those, it can't reuse bus numbers even in
different segment groups.  The platform might have to use multiple
segments to allow multiple ECAM regions, but use _PRS/_SRS to prevent
bus number overlaps to keep legacy config access working.  Obviously
this is only an issue if there are non-segment aware config access
methods.

2) If two host bridges share an ECAM region, I think we're forced to
put them in the same domain: if we put them in different domains,
Linux might assign [bus 00-ff] to both bridges, and ECAM config
accesses would only work for one of the bridges.  This is quite common
on x86 and is a potential issue for any architecture.

Bjorn