From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:400c:c09::241; helo=mail-wm0-x241.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 99A18210DF765 for ; Wed, 8 Aug 2018 05:53:10 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id w24-v6so2661522wmc.1 for ; Wed, 08 Aug 2018 05:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=uS9hU1t+caqhIqxYOVr1viaBvXPejHkjRN1AJalqpcI=; b=W7N9wY72eI8QkGYDn9yQRYGk97IowgYIi8uIfNUoZ2QZU2DAbcZzaRMezzBXLOCRzm PGvu7g8bOeCM7x/8HhBzW7aXv1xY8bGPNwGSSYFIXuFaTs/fHbvbS3iugdJAtOLXD4o8 y3/NIaE0l2e1gsQfIGBqfQ/m5aHhvJw/CCd1k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=uS9hU1t+caqhIqxYOVr1viaBvXPejHkjRN1AJalqpcI=; b=hUcy2Ubepqy9T7s7irsEjceBMJLUcCiBfHBzzkIessd7iV/LXBGk1eHvTr+CaHlX8v iPI5WcUJEndtHGu9jsZDaX06MayK4vU3Nd7AaUxKVOL94agt6LknxNM+4YS4M166QEHo GKLR+NU4s5DOZwhgzxhtzb8dwb4HJDeOx0NYA2qyNR1H0HzkDvSFXhU/xZYGf8JTmJMK WR3KNkHGhv73Vbj4lw+yPbE1v9zRg6Kv492fHXfd+MEaP0HhH/NdCBDaDxFw6SO5tZCd JR2f4lu5xyBX1lMFG2wKAkW6S6BLUxd+YR6lBlZ/41bLtmgWr5AsnkqvDEMpA6vMtWIU EFbA== X-Gm-Message-State: AOUpUlH74rZfwc1vRy8Ox0dlljYh/gX3M2SoE1zS/1rhRMly39zKz5mr r/KqiNPJCzTcbLFf2JXZnxstlw== X-Google-Smtp-Source: AA+uWPwEv/P6hDDnfilgHxT4zt73zalGuto8vy7JU/EzzCYJqHPtp/YBFbas8N26H+KWK+L5owIItw== X-Received: by 2002:a1c:ee5d:: with SMTP id m90-v6mr1821437wmh.107.1533732788857; Wed, 08 Aug 2018 05:53:08 -0700 (PDT) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id z14-v6sm3239826wma.18.2018.08.08.05.53.07 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Aug 2018 05:53:07 -0700 (PDT) Date: Wed, 8 Aug 2018 13:53:06 +0100 From: Leif Lindholm To: Ming Cc: linaro-uefi@lists.linaro.org, edk2-devel@lists.01.org, graeme.gregory@linaro.org, ard.biesheuvel@linaro.org, guoheyi@huawei.com, wanghuiqiang@huawei.com, huangming23@huawei.com, zhangjinsong2@huawei.com, huangdaode@hisilicon.com, john.garry@huawei.com, xinliang.liu@linaro.org, Heyi Guo Message-ID: <20180808125306.nllzdcfbnbc57wt7@bivouac.eciton.net> References: <20180724070922.63362-1-ming.huang@linaro.org> <20180724070922.63362-8-ming.huang@linaro.org> <20180802173647.paepialtuopbe6y5@bivouac.eciton.net> <22f0c26b-0666-82b5-2b1c-f71af63526a4@linaro.org> <20180808095909.tavnft3vmycftxc7@bivouac.eciton.net> <12d71306-5d19-837c-3827-8be1883b693a@linaro.org> MIME-Version: 1.0 In-Reply-To: <12d71306-5d19-837c-3827-8be1883b693a@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH edk2-platforms v1 07/38] Silicon/Hisilicon/D06: Wait for all disk ready X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2018 12:53:11 -0000 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Wed, Aug 08, 2018 at 07:44:36PM +0800, Ming wrote: > > > 在 8/8/2018 5:59 PM, Leif Lindholm 写道: > > On Wed, Aug 08, 2018 at 05:02:15PM +0800, Ming wrote: > >> 在 8/3/2018 1:36 AM, Leif Lindholm 写道: > >>> On Tue, Jul 24, 2018 at 03:08:51PM +0800, Ming Huang wrote: > >>>> This patch is relative to D06 SasDxe driver. The SasDxe set a > >>>> variable to notice this libray. Here Wait for all disk ready > >>>> for 30S at most. > >>>> > >>>> Contributed-under: TianoCore Contribution Agreement 1.1 > >>>> Signed-off-by: Ming Huang > >>>> Signed-off-by: Heyi Guo > >>>> --- > >>>> Silicon/Hisilicon/HisiPkg.dec | 1 + > >>>> Silicon/Hisilicon/Library/PlatformBootManagerLib/PlatformBm.c | 43 ++++++++++++++++++++ > >>>> Silicon/Hisilicon/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 2 + > >>>> 3 files changed, 46 insertions(+) > >>>> > >>>> diff --git a/Silicon/Hisilicon/HisiPkg.dec b/Silicon/Hisilicon/HisiPkg.dec > >>>> index 35bea970ec..b56a6a6af7 100644 > >>>> --- a/Silicon/Hisilicon/HisiPkg.dec > >>>> +++ b/Silicon/Hisilicon/HisiPkg.dec > >>>> @@ -45,6 +45,7 @@ > >>>> > >>>> gHisiEfiMemoryMapGuid = {0xf8870015, 0x6994, 0x4b98, {0x95, 0xa2, 0xbd, 0x56, 0xda, 0x91, 0xc0, 0x7f}} > >>>> gVersionInfoHobGuid = {0xe13a14c, 0x859c, 0x4f22, {0x82, 0xbd, 0x18, 0xe, 0xe1, 0x42, 0x12, 0xbf}} > >>>> + gHisiOemVariableGuid = {0xac62b9a5, 0x9939, 0x41d3, {0xff, 0x5c, 0xc5, 0x80, 0x32, 0x7d, 0x9b, 0x29}} > >>>> gOemBootVariableGuid = {0xb7784577, 0x5aaf, 0x4557, {0xa1, 0x99, 0xd4, 0xa4, 0x2f, 0x45, 0x06, 0xf8}} > >>> > >>> What is the difference between gHisiOemVariableGuid and gOemBootVariableGuid? > >>> > >> > >> Just a guid using to a variable. > >> Do you suggest to use the old one? > > > > Well, I am unsure about the intended scope for either. So I don't > > know. How is HisiOem different from Oem? Can you explain the structure? > > HisiOem and Oem are the same scope, just need a guid for SetVariable. The only purpose for the GUID is so that you can have variables of the same name in different modules without risking clashes. Sharing the same variable GUID across multiple modules is perfectly fine (and often preferable) when those modules are closely related. But as I think this was only used for the communication with the SAS controller driver, I think maybe this one can just go. > >>>> gEfiHisiSocControllerGuid = {0xee369cc3, 0xa743, 0x5382, {0x75, 0x64, 0x53, 0xe4, 0x31, 0x19, 0x38, 0x35}} > >>>> > >>>> diff --git a/Silicon/Hisilicon/Library/PlatformBootManagerLib/PlatformBm.c b/Silicon/Hisilicon/Library/PlatformBootManagerLib/PlatformBm.c > >>>> index 7dd5ba615c..f7536bfea3 100644 > >>>> --- a/Silicon/Hisilicon/Library/PlatformBootManagerLib/PlatformBm.c > >>>> +++ b/Silicon/Hisilicon/Library/PlatformBootManagerLib/PlatformBm.c > >>>> @@ -20,6 +20,7 @@ > >>>> #include > >>>> #include > >>>> #include > >>>> +#include > >>>> #include > >>>> #include > >>>> #include > >>>> @@ -554,6 +555,47 @@ PlatformBootManagerBeforeConsole ( > >>>> PlatformRegisterOptionsAndKeys (); > >>>> } > >>>> > >>>> +STATIC > >>>> +VOID > >>>> +WaitForDiskReady ( > >>>> + ) > >>>> +{ > >>>> + EFI_STATUS Status; > >>>> + UINT32 Index; > >>>> + UINTN DataSize; > >>>> + UINT32 DiskInfo; > >>>> + UINT8 IsFinished; > >>>> + > >>>> + Status = EFI_NOT_FOUND; > >>>> + DataSize = sizeof (UINT32); > >>>> + // Wait for 30 seconds at most. > >>>> + for (Index=0; Index<30; Index++) { > >>> > >>> Spaces around '=' and '<'. > >>> > >>>> + Status = gRT->GetVariable ( > >>>> + L"SASDiskInfo", > >>>> + &gHisiOemVariableGuid, > >>>> + NULL, > >>>> + &DataSize, > >>>> + &DiskInfo > >>>> + ); > >>> > >>> Wait... > >>> Are we synchronizing against the storage controller driver using an > >>> environment variable and looping over it for 30 seconds? > >>> > >> D06: > >> For using hard disk backboard, some disk need 15 seconds to ready. > >> Actually, wait less 15 seconds here(minus the time from end of SAS > >> driver to here). > >> For using expander, wait less 6 seconds here(minus the time from end of SAS > >> driver to here). > >> > >> D03/D05: > >> no waiting here. > >> > >> Maybe I should change 30 to 15, it will never loop over for 30 seconds. > >> > >>> That can't go in. > >>> Please look into implementing an event in the SAS driver which you can > >>> wait for here. > >> > >> I don't really understand what differece between implementing with variable > >> and implementing with event. > > > > One is using the mechanism explicitly designed for this sort of > > thing. (And hence making the code a lot more clear and avoiding > > unintended side effects.) > > It also mean you would wait exactly as long as you needed, and not > > need to worry about how long. > > In this case, it don't want to wait exactly time, the time depand on > SAS driver and which backboard is used. After optimizing SAS driver, > wait time is reduced. Here,30 just for avoiding dead loop. Which is exactly what an event is for. At the point where the SAS controller driver is currently updating the variable, it can instead call SignalEvent (). The WaitForDiskReady () function can be changed to wait/check for that event. > >>> Why not call WaitForDiskReady() before EfiBootManagerConnectAll () in > >>> PlatformBootManagerAfterConsole ()? > >>> > >> > >> The Sas controller of D06 is a pci device, SAS driver (Start functio) run after > >> pci enumeration. WaitForDiskReady should be called after SAS driver and before > >> creating boot options. > > > > OK, but EfiBootManagerConnectAll () is a bit of a sledge hammer, and > > will affect boot times. > > > > The SAS controller is onboard (so always present), right? > > If so, you could connect it manually. > > Yes, it's always present. > I intend to optimize SAS driver in future. It's not enouth time to do > this before 18.08. > Thanks. OK. / Leif