Received: by 10.213.65.68 with SMTP id h4csp3363069imn; Tue, 3 Apr 2018 03:41:48 -0700 (PDT) X-Google-Smtp-Source: AIpwx49nl1pa9qlCynj3U/Xpm9OJfQd7iaj/K26B502ZqjjsvtDDsRK9GJaMubo3I71Uhqcx16Rt X-Received: by 2002:a17:902:2943:: with SMTP id g61-v6mr13791915plb.238.1522752108084; Tue, 03 Apr 2018 03:41:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522752108; cv=none; d=google.com; s=arc-20160816; b=KErHsAyUlggHo400LBQ551qO5ldCtrsZEokn2CJZAEV/tYhDHvfcOz03Hezgz+zy+r t2vD4JlG9cGHKNEEbGehbWj55nt0n5Ho5L7Mq/gNRxaaTP7lC7Dki6fkkA1Gyl/vh9Lh MPvGt931I5CKzwI0Fiyx3GoZ+RZP7B+cXfq/UWQFtPPRZmQsN5Q2tg0nohqNvM/SzbjQ HWMcPPruErwUHSXnDQAS968HgrcvJV6JvQjuhPpjHfX4v52+5rCY+nZ2edSk59QJ+d8l pcQBUDqZryaLHVR1h2UhG5pbHZI3F5VzCI5sIeNSRb+75JO9gjfNRpxKVyM+8CNn1xfE tfGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=m8bLwz4dCMMNTRqvbsvER/2hRmdiBH5GfT7OpwPZ8LA=; b=ZO1Q6CZscZIKGvpsx5hXChMU5CYadmRGgSVJd6iCe+kiF5KAMNtkkVFROI9VYfNSUW qxSNgjmK61fek1KMZ8BQf21TJecxuLyZQJ7tFQuJp8X5Ca+m+nHBDMtKfG8V8pl90+8t aTLkwwUUKWdiB1y45AIEwZJv9pIH4JsnN2aH0sELBreN8C+kRA7/0NF7wKriOHE3e1r3 o4y4/boRKpNFxYfltJloO+U/ZWgbtwUKRoKmTBvwBapSM+slJJNMkx+KWIUb+8VF/BSJ 8AgHy8+psS2Acj76fAhNLw9/Iaq0p8kdb4MoAf0c1DnIs81fk1zlcWXDnpF8GQkFJTFb GQfQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k191si1781082pgd.449.2018.04.03.03.41.04; Tue, 03 Apr 2018 03:41:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=synopsys.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755132AbeDCKdz (ORCPT + 99 others); Tue, 3 Apr 2018 06:33:55 -0400 Received: from us01smtprelay-2.synopsys.com ([198.182.60.111]:49344 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754183AbeDCKdy (ORCPT ); Tue, 3 Apr 2018 06:33:54 -0400 Received: from mailhost.synopsys.com (mailhost3.synopsys.com [10.12.238.238]) by smtprelay.synopsys.com (Postfix) with ESMTP id 7F3A310C0F81; Tue, 3 Apr 2018 03:33:53 -0700 (PDT) Received: from mailhost.synopsys.com (localhost [127.0.0.1]) by mailhost.synopsys.com (Postfix) with ESMTP id 5C2D636B6; Tue, 3 Apr 2018 03:33:53 -0700 (PDT) Received: from pt02.synopsys.com (pt02.synopsys.com [10.107.23.240]) by mailhost.synopsys.com (Postfix) with ESMTP id 02F7136B3; Tue, 3 Apr 2018 03:33:52 -0700 (PDT) Received: from [127.0.0.1] (gustavo-e7480.internal.synopsys.com [10.107.25.102]) by pt02.synopsys.com (Postfix) with ESMTP id 2E0CE3E678; Tue, 3 Apr 2018 11:33:52 +0100 (WEST) Subject: Re: [PATCH 1/8] bindings: PCI: designware: Example update To: Kishon Vijay Abraham I , "bhelgaas@google.com" , "lorenzo.pieralisi@arm.com" , "Joao.Pinto@synopsys.com" , "jingoohan1@gmail.com" , "robh+dt@kernel.org" , "mark.rutland@arm.com" Cc: "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" References: <33aa86ee667e8b435db080b8c683cb5df1bd6544.1522235224.git.gustavo.pimentel@synopsys.com> From: Gustavo Pimentel Message-ID: <36a36857-2d79-2c2d-198d-a3b65cafc768@synopsys.com> Date: Tue, 3 Apr 2018 11:33:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> --- >> 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 >