Re: [PATCH 1/8] bindings: PCI: designware: Example update

[Gustavo Pimentel <gustavo.pimentel@synopsys.com>]

Hi Kishon,

On 02/04/2018 06:23, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote:
>> Changes the IP registers size to accommodate the ATU unroll space.
>>
>> Replaces "ctrlreg" reg-name by "dbi" to be coherent with similar drivers.
>>
>> Replaces the pcie base address example by a real pcie base address in use.
>>
>> Signed-off-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>
>> ---
>>  Documentation/devicetree/bindings/pci/designware-pcie.txt | 12 ++++++------
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> index 1da7ade..6300762 100644
>> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>> @@ -1,7 +1,8 @@
>>  * Synopsys DesignWare PCIe interface
>>  
>>  Required properties:
>> -- compatible: should contain "snps,dw-pcie" to identify the core.
>> +- compatible:
>> +	"snps,dw-pcie" for RC mode;
> 
> I think irrespective of RC mode or EP mode, "snps,dw-pcie" can be used to
> identify the pcie core?

I guess so. What you suggest? I was just folling the same guideline present
here: https://lkml.org/lkml/2017/11/3/310

>>  - reg: Should contain the configuration address space.
>>  - reg-names: Must be "config" for the PCIe configuration space.
>>      (The old way of getting the configuration address space from "ranges"
>> @@ -41,11 +42,11 @@ EP mode:
>>  
>>  Example configuration:
>>  
>> -	pcie: pcie@dffff000 {
>> +	pcie: pcie@dfc00000 {
>>  		compatible = "snps,dw-pcie";
>> -		reg = <0xdffff000 0x1000>, /* Controller registers */
>> -		      <0xd0000000 0x2000>; /* PCI config space */
>> -		reg-names = "ctrlreg", "config";
>> +		reg = <0xdfc00000 0x302000>, /* IP registers */
> 
> which version of synopsys IP is this. I think the ideal thing to do here is to
> have a separate register space for iATU.

I also agree with that. The unroll iATU was introduced on Synopsys IP version
4.80 and the kernel patch was release on 2016-08-10
https://patchwork.ozlabs.org/patch/657796/
However a separate register space for iATU implies some extra code do handle it
(and of course some tests) that don't fit into this patch series, in my point of
view. Can this task enter in the backlog in order to be done in another patch
series?

> 
> Thanks
> Kishon
>