public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: heyi.guo@linaro.org
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Michael D Kinney <michael.d.kinney@intel.com>,
	Haojian Zhuang <haojian.zhuang@linaro.org>
Subject: Re: [PATCH edk2-platforms 00/12] Hisilicon/D0x: Switch to generic PciHostBridge
Date: Thu, 31 May 2018 09:02:02 +0800	[thread overview]
Message-ID: <20180531010202.GA8926@ecs-e536.expressvpn> (raw)
In-Reply-To: <20180417014446.GB123329@SZX1000114654>

Hi Ard,

Have you returned from vocation? If so, could you help to continue reviewing
this patch series?

Thanks,

Heyi

On Tue, Apr 17, 2018 at 09:44:46AM +0800, Guo Heyi wrote:
> BTW, there is actually a bug with ATU configuration which will cause IO access
> failure, and we need to apply an additional patch (this patch is generated after
> PCI host bridge patch series) as attached to fix this.
> 
> Regards,
> Heyi
> 
> On Tue, Apr 17, 2018 at 09:20:44AM +0800, Guo Heyi wrote:
> > Hi Ard,
> > 
> > I tested mm -io on D05, for root bridge 4 with CPU IO address starting from
> > 0x8_abff0000, and it worked; both mm -io 0x8abff0000 and mm 0x8abff0000 provided
> > the same output. It seems there is no other limit for 64bit IO address after you
> > fixed the issue in EFI shell mm command.
> > 
> > Thanks and regards,
> > 
> > Heyi
> > 
> > On Mon, Apr 16, 2018 at 09:57:09PM +0800, Guo Heyi wrote:
> > > Thanks, I will test mm command and let you know the result.
> > > 
> > > Regards,
> > > 
> > > Heyi
> > > 
> > > On Fri, Apr 13, 2018 at 09:19:53AM +0200, Ard Biesheuvel wrote:
> > > > On 13 April 2018 at 04:05, Guo Heyi <heyi.guo@linaro.org> wrote:
> > > > > Hi Ard,
> > > > >
> > > > > Any comments?
> > > > >
> > > > 
> > > > Apologies for the delay. I have been travelling and am behind on email.
> > > > 
> > > > > Anyway we can modify the code if you insist on using an intermediate CPU IO
> > > > > address space.
> > > > >
> > > > 
> > > > I have not made up my mind yet, to be honest. I agree there is a
> > > > certain elegance to merging both translations, but I am concerned that
> > > > existing EDK2 code may deal poorly with I/O addresses that require
> > > > more than 32 bits to express.
> > > > 
> > > > Did you try the mm command in the shell for instance? As you know, I
> > > > recently removed an artificial address range limit there, but I wonder
> > > > if it uses 64-bit variables for I/O ports.

> From guoheyi@huawei.com Tue Apr 17 09:40:07 2018
> Delivered-To: heyi.guo@linaro.org
> Received: by 10.103.107.2 with SMTP id g2csp1147351vsc;
>         Mon, 16 Apr 2018 18:40:07 -0700 (PDT)
> X-Google-Smtp-Source: AIpwx49xa2EjXi3IIuqoYaJ9ZR+KlZePkYWmAvMpJl534IXT0zWt/Jd5UHxMjyCgas2Aluws+S26
> X-Received: by 10.101.97.165 with SMTP id i5mr102113pgv.449.1523929207660;
>         Mon, 16 Apr 2018 18:40:07 -0700 (PDT)
> ARC-Seal: i=1; a=rsa-sha256; t=1523929207; cv=none;
>         d=google.com; s=arc-20160816;
>         b=JVhwQqc2tHJH/nbb9J4Q5EAe7efNCva8XlNdyeM1AjecnvMtalXxRiIcVSIp2CTTUb
>          RCfB400z6ay0s7SW96MDtN0D8jezfXLZXyuMQTqYAvpXu7rxEmXGJtKblXaJ303GTvgS
>          kavhZQ7QawTzXzWTjokcARGeyR+mFb9aXT8JKm3jdHVM+Ibsjl0HFYSFrMNFoeyC7EqG
>          EPMbjEvcWolADxpywSCM0s0e4EhIVpGrhi1LgdVeATsyrb6GN8sEscVfb+t0b0gMj6XI
>          Nqg7mMHnKZGJ4vmkJBRV5Gx+nnQbOWKsOCp8YZcVLFs8hyqWFokYsup3wsY1YtktovxU
>          GQUg==
> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
>         h=mime-version:message-id:date:subject:cc:to:from
>          :arc-authentication-results;
>         bh=MzafS17Rdgthy05RGe4B87hGASmPkGgjBWmjX1ExxLo=;
>         b=fj+XbZcdH1vGFsHllnQeTc3zRavri5L0Use7rHdCRemtfNojWbY1QJKD6tMVi213fj
>          J9IaKL5/Q3Uh0KLfAR848Whbuj4IiFMw1vRsT8BUvu0QjkCsdJo66ypGdQTqkysdtk2X
>          fdNfNTE+Dfa1du8Yx9RiFCetXrtgCjDXljVzd/JufSlKtC41HjgWjnqC2Jka4N0MOT1W
>          oiBtsqOCjRuVRyb5Rlf7RVstwZ7wz6jXbxj7GYkr85bUFe7LNG8HOKxJYIv1bLyOWw6q
>          KvttRU9MKaVex3HApPoMIIgg+sXj3QD1islzlobdLA/OaRKWXCH0fnXH/NuWnKZ7J1jO
>          Hl7A==
> ARC-Authentication-Results: i=1; mx.google.com;
>        spf=pass (google.com: domain of guoheyi@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=guoheyi@huawei.com
> Return-Path: <guoheyi@huawei.com>
> Received: from huawei.com ([45.249.212.32])
>         by mx.google.com with ESMTPS id t3si10564595pgt.547.2018.04.16.18.40.07
>         for <heyi.guo@linaro.org>
>         (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
>         Mon, 16 Apr 2018 18:40:07 -0700 (PDT)
> Received-SPF: pass (google.com: domain of guoheyi@huawei.com designates 45.249.212.32 as permitted sender) client-ip=45.249.212.32;
> Authentication-Results: mx.google.com;
>        spf=pass (google.com: domain of guoheyi@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=guoheyi@huawei.com
> Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58])
> 	by Forcepoint Email with ESMTP id 2B03711A12683
> 	for <heyi.guo@linaro.org>; Tue, 17 Apr 2018 09:40:04 +0800 (CST)
> Received: from HGH1000039998.huawei.com (10.184.68.188) by
>  DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id
>  14.3.361.1; Tue, 17 Apr 2018 09:39:59 +0800
> From: Heyi Guo <guoheyi@huawei.com>
> To: <heyi.guo@linaro.org>
> CC: <phoenix.liyi@huawei.com>, <mengfanrong@huawei.com>,
> 	<zhangjinsong2@huawei.com>
> Subject: [PATCH] Hisilicon/Hi161x/PcieInit: fix address overlap
> Date: Tue, 17 Apr 2018 09:35:22 +0800
> Message-ID: <1523928922-9573-1-git-send-email-guoheyi@huawei.com>
> X-Mailer: git-send-email 2.8.1
> MIME-Version: 1.0
> Content-Type: text/plain
> X-Originating-IP: [10.184.68.188]
> X-CFilter-Loop: Reflected
> Content-Length: 2888
> Lines: 55
> 
> From: Heyi Guo <heyi.guo@linaro.org>
> 
> PCIe IO address ranges are overlapped by configuration address spaces
> when we set CFG0/CFG1 address range starting from ECAM. It causes
> access to IO space is routed to configuration space and returned with
> wrong results.
> 
> So we limit address space for configuration type 0
> starting from BusBase and type 1 from (BusBase + 2), to eliminate the
> address range overlapping.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
> ---
>  Silicon/Hisilicon/Hi1610/Drivers/PcieInit1610/PcieInitAtu.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/Silicon/Hisilicon/Hi1610/Drivers/PcieInit1610/PcieInitAtu.c b/Silicon/Hisilicon/Hi1610/Drivers/PcieInit1610/PcieInitAtu.c
> index f2365b5..9a92fea 100644
> --- a/Silicon/Hisilicon/Hi1610/Drivers/PcieInit1610/PcieInitAtu.c
> +++ b/Silicon/Hisilicon/Hi1610/Drivers/PcieInit1610/PcieInitAtu.c
> @@ -96,11 +96,12 @@ SetAtuConfig0RW (
>  {
>    UINTN RbPciBase = Private->RbPciBar;
>    UINT64 MemLimit = GetPcieCfgAddress (Private->Ecam, Private->BusBase + 1, 1, 0, 0) - 1;
> +  UINT64 MemBase = GetPcieCfgAddress (Private->Ecam, Private->BusBase, 0, 0, 0);
>  
>  
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_VIEW_POINT, Index);
> -  MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_LOW, (UINT32)(Private->Ecam));
> -  MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_HIGH, (UINT32)((UINT64)(Private->Ecam) >> 32));
> +  MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_LOW, (UINT32)MemBase);
> +  MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_HIGH, (UINT32)(MemBase >> 32));
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_LIMIT, (UINT32) MemLimit);
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_TARGET_LOW, 0);
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_TARGET_HIGH, 0);
> @@ -124,12 +125,13 @@ SetAtuConfig1RW (
>  {
>    UINTN RbPciBase = Private->RbPciBar;
>    UINT64 MemLimit = GetPcieCfgAddress (Private->Ecam, Private->BusLimit + 1, 0, 0, 0) - 1;
> +  UINT64 MemBase = GetPcieCfgAddress (Private->Ecam, Private->BusBase + 2, 0, 0, 0);
>  
>  
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_VIEW_POINT, Index);
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_CTRL1, IATU_CTRL1_TYPE_CONFIG1);
> -  MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_LOW, (UINT32)(Private->Ecam));
> -  MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_HIGH, (UINT32)((UINT64)(Private->Ecam) >> 32));
> +  MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_LOW, (UINT32)MemBase);
> +  MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_HIGH, (UINT32)(MemBase >> 32));
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_BASE_LIMIT, (UINT32) MemLimit);
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_TARGET_LOW, 0);
>    MmioWrite32 (RbPciBase + IATU_OFFSET + IATU_REGION_TARGET_HIGH, 0);
> -- 
> 2.8.1
> 
> 



  reply	other threads:[~2018-05-31  1:02 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21  1:03 [PATCH edk2-platforms 00/12] Hisilicon/D0x: Switch to generic PciHostBridge Heyi Guo
2018-03-21  1:03 ` [PATCH edk2-platforms 01/12] Hisilicon: Enable WARN and INFO debug message Heyi Guo
2018-03-21  1:03 ` [PATCH edk2-platforms 02/12] Hisilicon/D05/PlatformPciLib: fix misuse of macro Heyi Guo
2018-03-21  1:03 ` [PATCH edk2-platforms 03/12] Hisilicon/Pci: move ATU configuration to PcieInitDxe Heyi Guo
2018-03-30 15:19   ` Ard Biesheuvel
2018-03-21  1:03 ` [PATCH edk2-platforms 04/12] Hisilicon/Pci: Merge PciPlatform into PcieInit Driver Heyi Guo
2018-03-21  1:03 ` [PATCH edk2-platforms 05/12] Hisilicon/Pci: Move EnlargeAtuConfig0() to PcieInitDxe Heyi Guo
2018-03-21  1:03 ` [PATCH edk2-platforms 06/12] Hisilicon/PlatformPciLib: add segment for each root bridge Heyi Guo
2018-03-21  1:03 ` [PATCH edk2-platforms 07/12] Hisilicon: add PciHostBridgeLib Heyi Guo
2018-03-30 15:28   ` Ard Biesheuvel
2018-03-21  1:03 ` [PATCH edk2-platforms 08/12] Hisilicon: add PciCpuIo2Dxe Heyi Guo
2018-03-30 15:30   ` Ard Biesheuvel
2018-03-21  1:03 ` [PATCH edk2-platforms 09/12] Hisilicon: add PciSegmentLib for Hi161x Heyi Guo
2018-03-21  1:03 ` [PATCH edk2-platforms 10/12] Hisilicon/D0x: Switch to generic PciHostBridge driver Heyi Guo
2018-03-30 15:34   ` Ard Biesheuvel
2018-03-21  1:03 ` [PATCH edk2-platforms 11/12] Hisilicon: remove platform specific PciHostBridge Heyi Guo
2018-03-30 15:37   ` Ard Biesheuvel
2018-03-21  1:03 ` [PATCH edk2-platforms 12/12] Hisilicon/PlatformPciLib: clear redundant felds in RESOURCE_APPETURE Heyi Guo
2018-03-28  1:05 ` [PATCH edk2-platforms 00/12] Hisilicon/D0x: Switch to generic PciHostBridge Guo Heyi
2018-03-28  9:43   ` Ard Biesheuvel
2018-03-29  0:20     ` Guo Heyi
2018-03-30 15:40       ` Ard Biesheuvel
2018-03-31  1:37         ` Guo Heyi
2018-04-13  2:05           ` Guo Heyi
2018-04-13  7:19             ` Ard Biesheuvel
2018-04-16 13:57               ` Guo Heyi
2018-04-17  1:20                 ` Guo Heyi
2018-04-17  1:44                   ` Guo Heyi
2018-05-31  1:02                     ` heyi.guo [this message]
2018-06-07 11:11                   ` Ard Biesheuvel
2018-06-22 12:58                     ` gary guo
2018-06-22 14:08                       ` Ard Biesheuvel
2018-06-24 11:22                         ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180531010202.GA8926@ecs-e536.expressvpn \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox