From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754986AbcIAD1i (ORCPT ); Wed, 31 Aug 2016 23:27:38 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:20896 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754052AbcIAD1g (ORCPT ); Wed, 31 Aug 2016 23:27:36 -0400 Subject: Re: [RFC PATCH V2 3/3] PCI/ACPI: hisi: Add ACPI support for HiSilicon SoCs Host Controllers To: "Rafael J. Wysocki" References: <1472644094-82731-1-git-send-email-liudongdong3@huawei.com> <1472644094-82731-4-git-send-email-liudongdong3@huawei.com> <2194589.LrAdKSkzcT@vostro.rjw.lan> CC: , , , , , , , , , , , , , , From: Dongdong Liu Message-ID: <57C79F3E.4050405@huawei.com> Date: Thu, 1 Sep 2016 11:23:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <2194589.LrAdKSkzcT@vostro.rjw.lan> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.61.21.156] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57C79F4B.016C,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0e79f7effca3e7ec92383641845876a9 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/9/1 6:56, Rafael J. Wysocki 写道: > On Wednesday, August 31, 2016 07:48:14 PM Dongdong Liu wrote: >> Add specific quirks for PCI config space accessors.This involves: >> 1. New initialization call hisi_pcie_acpi_init() to get RC config resource >> with hardcoded range address and setup ecam mapping. >> 2. New entry in common quirk array. >> >> Signed-off-by: Dongdong Liu >> Signed-off-by: Gabriele Paoloni > > Well, what exactly is the ACPI support you're adding? Is it the ECAM part only > or is there anything more to it? > Hi Rafael, thanks for replying. Our host bridge is non ECAM only for the RC bus config space; for any other bus underneath the root bus we support ECAM access. In our case we cannot use the standard MCFG object to pass the RC itself config space addresses. The more discuss information can be found: https://lkml.org/lkml/2016/2/22/1087 [...] I have looked into this and in our case we cannot use the standard MCFG object to pass the RC config space addresses. The reason is that in our HW we have the config base addresses of the root complex ports that are less than 0x100000 byte distant one from the other as we only map the first 0x10000 bytes. Now the MCFG acpi framework always fix the MCFG resource size to 0x100000 for each bus; therefore if we pass our RC addresses through MCFG we end up with a resource conflict. To give you a practical example we are in a situation where we have: port0: [0x00000000b0080000 - 0x00000000b0080000 + 0x10000] port1: [0x00000000b0090000 - 0x00000000b0090000 + 0x10000] port2: [0x00000000b00A0000 - 0x00000000b00A0000 + 0x10000] port3: [0x00000000b00B0000 - 0x00000000b00B0000 + 0x10000] So if we pass the base addresses through MCFG the resources will overlap as MCFG will consider 0x100000 size for each base address of the root complex (only the RC bus uses that address) So far I do not see many option other than using _DSD to pass these RC config base addresses. Thanks and Regards Gab [...] and https://patchwork.kernel.org/patch/9178791/ [...] Furthermore, I suspect we do not even need a way to pass the non-ECAM compliant config space resources to the OS (ie we can't change FW anymore anyway in some platforms) so the quirks hooks are likely to hardcode the required config space addresses for the respective MCFG match. ...... Thanks ! Lorenzo [...] So we hard code with our RC itself config resource. Thanks Dongdong > Thanks, > Rafael > > > . >