devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robert Richter <robert.richter@caviumnetworks.com>
To: Liviu Dudau <Liviu.Dudau@arm.com>, Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Robert Richter <rric@kernel.org>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <Pawel.Moll@arm.com>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Catalin Marinas <Catalin.Marinas@arm.com>,
	Will Deacon <Will.Deacon@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Sunil Goutham <sgoutham@cavium.com>
Subject: Re: [PATCH 3/6] pci, thunder: Add PCIe host controller devicetree bindings
Date: Wed, 8 Oct 2014 10:49:27 +0200	[thread overview]
Message-ID: <20141008084927.GH31556@rric.localhost> (raw)
In-Reply-To: <20141007150149.GW4652@e106497-lin.cambridge.arm.com>

On 07.10.14 16:01:49, Liviu Dudau wrote:
> On Tue, Oct 07, 2014 at 03:27:44PM +0100, Robert Richter wrote:
> > On 24.09.14 18:06:04, Arnd Bergmann wrote:
> > > > +               compatible = "cavium,thunder-pcie";
> > > > +               device_type = "pci";
> > > > +               msi-parent = <&its>;
> > > > +               bus-range = <0 255>;
> > > > +               #size-cells = <2>;
> > > > +               #address-cells = <3>;
> > > > +               reg = <0x8480 0x00000000 0 0x10000000>;  /* Configuration space */
> > > > +               ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>, /* mem ranges */
> > > > +                       <0x03000000 0x8300 0x00000000 0x8300 0x00000000 0x80 0x00000000>,
> > > > +                       <0x03000000 0x87e0 0x00000000 0x87e0 0x00000000 0x01 0x00000000>;
> > > > +        };
> > > 
> > > If you claim the entire 0-255 bus range, I think you should also
> > > specify a domain, otherwise it's not predictable which domain you
> > > get.
> > 
> > Liviu's code assigns a unique id to the domain if missing, see
> > of_pci_get_domain_nr(). So I don't think we need to add a "pci-domain"
> > property here.
> 
> Not anymore! That function is gone in v12 onwards. What is in -next has
> a new function called of_get_pci_domain_nr() (slight name change) but
> that only gets the value set in the "linux,pci-domain" property of the
> device node. It is the choice of the host bridge driver to use that
> function or to use pci_get_new_domain_nr() which *does* generate an
> unique id every time it gets called.

I am quite confused a bit on which is the latest code base now. I was
looking into Bjorn's pci/host-generic and there is a different
implemetation:

----
/**
 * This function will try to obtain the host bridge domain number by
 * using of_alias_get_id() call with "pci-domain" as a stem.  If that
 * fails, a local allocator will be used.  The local allocator can
 * be requested to return a new domain_nr if the information is missing
 * from the device tree.
 *
 * @node: device tree node with the domain information
 * @allocate_if_missing: if DT lacks information about the domain nr,
 * allocate a new number.
 *
 * Returns the associated domain number from DT, or a new domain number
 * if DT information is missing and @allocate_if_missing is true.  If
 * @allocate_if_missing is false then the last allocated domain number
 * will be returned.
 */
int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
{
        int domain;

        domain = atomic_read(&of_domain_nr);
        if (domain == -1) {
                /* first run, get max defined domain nr in device tree */
                domain = of_get_max_pci_domain_nr();
                /* then set the start value for allocator to be max + 1 */
                atomic_set(&of_domain_nr, domain + 1);
        }
        domain = of_alias_get_id(node, "pci-domain");
        if (domain == -ENODEV) {
                domain = atomic_read(&of_domain_nr);
                if (allocate_if_missing)
                        atomic_inc(&of_domain_nr);
        }

        return domain;
}
EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
----

This differs also from v13. Please check.

It would be good to have a stable code base to work with, so I would
prefer incremental patches on top of Bjorn's pci/host-generic.

> > Liviu's DT implementation that assigns a unique number differs a bit
> > from ACPI which states: "If _SEG [aka domain number] does not exist,
> > OSPM assumes that all PCI bus segments are in PCI Segment Group 0."
> > 
> > Maybe of_pci_get_domain_nr() should be similar to ACPI. If there are
> > multiple root bridges, the "pci-domain" property could be forced
> > instead.
> 
> Indeed. But the enforcing is left as an exercise to the host bridge
> implementor for the moment.

Right, can be added later.

Thanks,

-Robert

  reply	other threads:[~2014-10-08  8:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1411573068-12952-1-git-send-email-rric@kernel.org>
2014-09-24 15:37 ` [PATCH 1/6] pci, thunder: Add support for Thunder PCIe host controller Robert Richter
2014-09-24 16:12   ` Arnd Bergmann
2014-09-24 16:49     ` Will Deacon
2014-09-30  9:14       ` Sunil Kovvuri
2014-09-24 15:37 ` [PATCH 2/6] GICv3: Add ITS entry to THUNDER dts Robert Richter
2015-06-25 23:19   ` Chalamarla, Tirumalesh
2015-06-26  9:00     ` Marc Zyngier
2014-09-24 15:37 ` [PATCH 3/6] pci, thunder: Add PCIe host controller devicetree bindings Robert Richter
2014-09-24 16:06   ` Arnd Bergmann
2014-09-24 18:04     ` Sunil Kovvuri
     [not found]       ` <CA+sq2Ce8sb=YGma05qEk_992Mc9M92TxCk+RWsyi6tY-FVOCXw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-24 18:34         ` Arnd Bergmann
2014-09-24 19:07           ` Sunil Kovvuri
2014-09-25  7:31             ` Arnd Bergmann
2014-09-25 16:16               ` Bjorn Helgaas
2014-09-25 19:26                 ` Arnd Bergmann
     [not found]                   ` <201409252126.38945.arnd-r2nGTMty4D4@public.gmane.org>
2014-09-25 20:10                     ` Bjorn Helgaas
     [not found]                       ` <CAErSpo5rhL7pLha-yWt7sZUBmAnwA6FkacL+sWXBKkSzsuC7Sg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-09-25 20:22                         ` Arnd Bergmann
2014-09-25 20:49                           ` Bjorn Helgaas
2014-09-26 18:26     ` Rob Herring
2014-09-30  9:11       ` Sunil Kovvuri
2014-10-07 14:27     ` Robert Richter
     [not found]       ` <20141007142744.GE31556-vWBEXY7mpu73kLQC+b9v0A@public.gmane.org>
2014-10-07 15:01         ` Liviu Dudau
2014-10-08  8:49           ` Robert Richter [this message]
2014-10-08 16:44             ` Liviu Dudau
     [not found]               ` <20141008164432.GC15382-2JSQmVVBSi7ZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org>
2014-10-09  6:23                 ` Robert Richter
2014-09-24 15:37 ` [PATCH 4/6] pci, thunder: Document " Robert Richter

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=20141008084927.GH31556@rric.localhost \
    --to=robert.richter@caviumnetworks.com \
    --cc=Catalin.Marinas@arm.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Pawel.Moll@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=rric@kernel.org \
    --cc=sgoutham@cavium.com \
    /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).