Cc the DT list for bindings please. On Thu, Aug 24, 2017 at 1:43 PM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > Describe the binding for firmware-configured instances of the Synopsys > Designware PCIe controller in RC mode. > > Cc: Rob Herring <robh@xxxxxxxxxx> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > --- > Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt | 56 ++++++++++++++++++++ > 1 file changed, 56 insertions(+) > > diff --git a/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt > new file mode 100644 > index 000000000000..b8127b19c220 > --- /dev/null > +++ b/Documentation/devicetree/bindings/pci/designware-pcie-ecam.txt > @@ -0,0 +1,56 @@ > +* Synopsys Designware PCIe root complex in ECAM mode > + > +In some cases, firmware may already have configured the Synopsys Designware > +PCIe controller in RC mode with static ATU window mappings that cover all > +config, MMIO and I/O spaces in a [mostly] ECAM compatible fashion. > +In this case, there is no need for the OS to perform any low level setup > +of clocks or device registers, nor is there any reason for the driver to > +reconfigure ATU windows for config and/or IO space accesses at runtime. > + > +Such hardware configurations should be described as "pci-host-ecam-generic" > +if they are truly ECAM compatible. Configurations that require no low-level > +setup by the OS nor any ATU window reconfiguration at runtime, but do > +require special handling for type 0 config TLPs may instead be described as > +"snps,dw-pcie-ecam". Humm, what happens when we have the next exception that's SoC specific or another vendor? Seems like perhaps "firmware initialized" should have been a separate property flag for bootloaders to add rather than a compatible string. I'd rather see this done in a way that does not require DT updates if quirks have to be handled/added later. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
