| Message ID | 1444891672-32117-6-git-send-email-bhupesh.sharma@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thursday 15 October 2015 12:17:45 Bhupesh Sharma wrote: > > +Note that since this controller derives its clocks from the Reset > +Configuration Word (RCW) which is used to describe the PLL settings at > +the time of chip-reset, the 'clocks' and 'clock-names' properties from > +'designware-pcie.txt' are optional for this controller. If this is an option for the dw-pcie block, should this description be added to the generic binding instead? > +Also as per the available Reference Manuals, there is no specific 'version' > +register available in the Freescale PCIe controller register set, > +which can allow determining the underlying Designware PCIe controller version > +information. > + > Required properties: > -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie" > +- compatible: should contain the platform identifier such as "fsl,<soc-name>-pcie", > + "snps,dw-pcie". You should document all the strings that will be needed here, otherwise a driver write does not know what to look for. If two chips have a 100% identical PCIe implementation, just use the string of the older chip for both. Arnd
> From: Arnd Bergmann [mailto:arnd@arndb.de] > Sent: Thursday, October 15, 2015 7:47 PM > > On Thursday 15 October 2015 12:17:45 Bhupesh Sharma wrote: > > > > +Note that since this controller derives its clocks from the Reset > > +Configuration Word (RCW) which is used to describe the PLL settings > > +at the time of chip-reset, the 'clocks' and 'clock-names' properties > > +from 'designware-pcie.txt' are optional for this controller. > > If this is an option for the dw-pcie block, should this description be > added to the generic binding instead? I think this can be moved to the generic bindings for DWC3 PCIe driver. However I cannot vouch if the same is true for usage of this IP in other SoCs and it will not break existing drivers if this property is not defined in their SoC DTSI. So adding a few old ST colleagues (Pratyush, Gabriel, Fabrice), who I am sure have used this IP in ST SoCs for their comments as well. So the question would be - do you think it will be ok to make the clock related properties optional in 'designware-pcie.txt' rather than required. > > > +Also as per the available Reference Manuals, there is no specific > 'version' > > +register available in the Freescale PCIe controller register set, > > +which can allow determining the underlying Designware PCIe controller > > +version information. > > + > > Required properties: > > -- compatible: should contain the platform identifier such as > "fsl,ls1021a-pcie" > > +- compatible: should contain the platform identifier such as > > +"fsl,<soc-name>-pcie", > > + "snps,dw-pcie". > > You should document all the strings that will be needed here, otherwise a > driver write does not know what to look for. > > If two chips have a 100% identical PCIe implementation, just use the > string of the older chip for both. The chips are not 100% identical and there is no version information register available for differentiation. So, does the following seem better: +- compatible: should contain the platform identifier such as +"fsl,<soc-name>-pcie", + "snps,dw-pcie". + + where <soc-name> for e.g. can be ls2080a or ls1021a. Regards, Bhupesh
Hi Bhupesh, On Fri, Oct 16, 2015 at 1:41 AM, Sharma Bhupesh <bhupesh.sharma@freescale.com> wrote: > I think this can be moved to the generic bindings for DWC3 PCIe driver. However > I cannot vouch if the same is true for usage of this IP in other SoCs and it > will not break existing drivers if this property is not defined in their SoC DTSI. > > So adding a few old ST colleagues (Pratyush, Gabriel, Fabrice), who I am sure have used this IP in ST SoCs > for their comments as well. Sorry for delayed response. Was on leave and away from internet. > > So the question would be - do you think it will be ok to make the clock related > properties optional in 'designware-pcie.txt' rather than required. I think they should have been optional. ~Pratyush
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index 6286f04..7d918ab 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -1,10 +1,21 @@ Freescale Layerscape PCIe controller -This PCIe host controller is based on the Synopsis Designware PCIe IP +This PCIe host controller is based on the Synopsys Designware PCIe IP and thus inherits all the common properties defined in designware-pcie.txt. +Note that since this controller derives its clocks from the Reset +Configuration Word (RCW) which is used to describe the PLL settings at +the time of chip-reset, the 'clocks' and 'clock-names' properties from +'designware-pcie.txt' are optional for this controller. + +Also as per the available Reference Manuals, there is no specific 'version' +register available in the Freescale PCIe controller register set, +which can allow determining the underlying Designware PCIe controller version +information. + Required properties: -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie" +- compatible: should contain the platform identifier such as "fsl,<soc-name>-pcie", + "snps,dw-pcie". - reg: base addresses and lengths of the PCIe controller - interrupts: A list of interrupt outputs of the controller. Must contain an entry for each entry in the interrupt-names property.