From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=2607:f8b0:4864:20::12f; helo=mail-it1-x12f.google.com; envelope-from=mw@semihalf.com; receiver=edk2-devel@lists.01.org Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 E18902115C325 for ; Fri, 12 Oct 2018 09:04:28 -0700 (PDT) Received: by mail-it1-x12f.google.com with SMTP id w200-v6so18883085itc.4 for ; Fri, 12 Oct 2018 09:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=s5g47ATRh+ZnB/U3CjeYEAzxj5f8LekafYlSP3eH9EQ=; b=h0QDxDWrvsD2OIP4M2Ly8pVoiSBUZGuaQVHyIZQRmj8CunDVFALTXYFH/dIy25+Tg2 X75Ur5rAnAbNy/HoCbz0dI64Lo48+nDmffmFJA1yB4wv7nHO+8ZSt38UsYs2EhEdajdR Phcnj4pJzsOedVqV6eyAPNekqDlm9VyyrOJsr6O3yfdX9JsHdkp/V7EcBceSBMn5p56k lPgq9jCU3Bx9mqyTpoqfk5Ql1E8pYfxolCwUaM5xt/Pg1HTqVfka1IWCopXJqGrf2g11 Gbo7FWClBRqLCs/2XXArlLqAS7jvIFwqtroITwDkcyaxp9BMRm0Y3K+WaWZbSgIQtodt +7lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=s5g47ATRh+ZnB/U3CjeYEAzxj5f8LekafYlSP3eH9EQ=; b=L0jDi7RAMMEr1UC2P9vmwtDAI0rFEC/VDUhjZgifIqq//udH42v0w/fokd7moNEYEH JtdiG/FT1zgVqejqfFFy1QRL5CuLaeIWNuyfrmfaAE9b0wa1bSPe0FfMQIencyR+PxJk N8glGkTZUQHyuGY7VdqN40dXCCBQhcYPj/qiyWRxkFts7Sg9KfvDldxvZrHLIvIZHoJa hKQtWRrAssgBFRKci+n5C7fP1nBN/aLFSBMTbi2nhrG+/Oh1BusX+J6Wge2PizkSR0Jp qc/0iOo4TjiJITJygocu29qsAaItYsQMG5wb1Rr9mJxsfdI9WoTV8WNc7Dpg+4OXNlTk UkCA== X-Gm-Message-State: ABuFfoj8xSqsyoTw0Powt2KxNOw+HK94I9bBfEHDElhx2EaDGvHhH6KY JuOez4lnhYTFn0dE70Nh+QoiunF32+zKyo6aYBGz+A== X-Google-Smtp-Source: ACcGV62cnKFwOGU55wmZtiKQybKTKrb3YTyyB5FSJGr1YIL6VsiqEqsPSGry8yVBEjGEZWXSXTFlocHahKgJI3mZTdA= X-Received: by 2002:a24:a0c:: with SMTP id 12-v6mr4198196itw.145.1539360267733; Fri, 12 Oct 2018 09:04:27 -0700 (PDT) MIME-Version: 1.0 References: <1538745911-22484-1-git-send-email-mw@semihalf.com> <1538745911-22484-3-git-send-email-mw@semihalf.com> In-Reply-To: From: Marcin Wojtas Date: Fri, 12 Oct 2018 18:04:15 +0200 Message-ID: To: Ard Biesheuvel Cc: hao.a.wu@intel.com, "Ni, Ruiyu" , "Tian, Feng" , Tomasz Michalec , eric.dong@intel.com, edk2-devel-01 , "Gao, Liming" , nadavh@marvell.com, "Kinney, Michael D" , "Zeng, Star" Subject: Re: [PATCH v2 2/4] MdeModulePkg/SdMmcPciHcDxe: Add UhsSignaling to SdMmcOverride protocol X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 16:04:29 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable pt., 12 pa=C5=BA 2018 o 17:55 Ard Biesheuvel na= pisa=C5=82(a): > > On 12 October 2018 at 07:06, Marcin Wojtas wrote: > > pt., 12 pa=C5=BA 2018 o 03:41 Wu, Hao A napisa=C5= =82(a): > >> > >> > -----Original Message----- > >> > From: Marcin Wojtas [mailto:mw@semihalf.com] > >> > Sent: Thursday, October 11, 2018 11:43 PM > >> > To: Wu, Hao A > >> > Cc: Ni, Ruiyu; Ard Biesheuvel; Tian, Feng; Tomasz Michalec; Dong, Er= ic; edk2- > >> > devel-01; Gao, Liming; nadavh@marvell.com; Kinney, Michael D; Zeng, = Star > >> > Subject: Re: [edk2] [PATCH v2 2/4] MdeModulePkg/SdMmcPciHcDxe: Add > >> > UhsSignaling to SdMmcOverride protocol > >> > > >> > wt., 9 pa=C5=BA 2018 o 13:51 Marcin Wojtas napisa= =C5=82(a): > >> > > > >> > > wt., 9 pa=C5=BA 2018 o 13:45 Ard Biesheuvel > >> > napisa=C5=82(a): > >> > > > > >> > > > On 9 October 2018 at 13:32, Marcin Wojtas wrot= e: > >> > > > > wt., 9 pa=C5=BA 2018 o 13:28 Wu, Hao A na= pisa=C5=82(a): > >> > > > >> > >> > > > >> > -----Original Message----- > >> > > > >> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] O= n > >> > Behalf Of Ard > >> > > > >> > Biesheuvel > >> > > > >> > Sent: Monday, October 08, 2018 11:10 PM > >> > > > >> > To: Marcin Wojtas; Ni, Ruiyu; Wu, Hao A > >> > > > >> > Cc: Tian, Feng; Tomasz Michalec; Dong, Eric; edk2-devel-01;= Gao, > >> > Liming; > >> > > > >> > Nadav Haklai; Kinney, Michael D; Zeng, Star > >> > > > >> > Subject: Re: [edk2] [PATCH v2 2/4] MdeModulePkg/SdMmcPciHcD= xe: > >> > Add > >> > > > >> > UhsSignaling to SdMmcOverride protocol > >> > > > >> > > >> > > > ... > >> > > > >> > > >> > > > >> > I suppose this is defined by the eMMC spec. > >> > > > >> > > >> > > > >> > Ruiyu, Hao, could you clarify? Are the host control 2 regis= ter values > >> > > > >> > for HS200/HS400 defined by the eMMC spec? > >> > > > >> > >> > > > >> Hi Ard and Marcin, > >> > > > >> > >> > > > >> As far as I know, the EMMC Electrical Standard Spec 5.1 (late= st) does > >> > not > >> > > > >> mention on how to set the "UHS Mode Select" field of the Host > >> > Control 2 > >> > > > >> Register when switching to HS200/HS400. (Actually, the EMMC s= pec > >> > does not > >> > > > >> mention Host Control 2 Register at all) > >> > > > >> > >> > > > >> When it comes to setting the bus mode for EMMC devices, the c= urrent > >> > > > >> implementation of the SdMmcPciHcDxe driver does a mapping whe= n > >> > setting the > >> > > > >> Host Control 2 Register: > >> > > > >> > >> > > > >> EMMC High Speed SDR - Freq: 0-52 MHz, Data Rate: Single > >> > > > >> matches > >> > > > >> SD SDR25 - Freq: 0-50 MHz, Data Rate: Single > >> > > > >> > >> > > > >> EMMC High Speed DDR - Freq: 0-52 MHz, Data Rate: Dual > >> > > > >> matches > >> > > > >> SD DDR50 - Freq: 0-50 MHz, Data Rate: Dual > >> > > > >> > >> > > > >> EMMC HS200 - Freq: 0-200 MHz, Data Rate: Single > >> > > > >> matches > >> > > > >> SD SDR104 - Freq: 0-208 MHz, Data Rate: Single > >> > > > >> > >> > > > >> EMMC HS400 - Freq: 0-200 MHz, Data Rate: Dual > >> > > > >> matches > >> > > > >> SD None > >> > > > >> > >> > > > >> And there is no obvious counterpart for the EMMC HS400 mode i= n the > >> > SD > >> > > > >> spec. The driver currently sets the "UHS Mode Select" field t= o a > >> > reserved > >> > > > >> value 0x5. > >> > > > >> > >> > > > > > >> > > > > Thank you Hao, above is on par with what the default UhsSignal= ing > >> > > > > routine does in this patch. IMO especially in case the EMMC st= andard > >> > > > > is not unequivocal regarding UHS_MODE_SEL, I'd encourage to ac= cept > >> > > > > some way of updating HostControl2 register, depending on the > >> > > > > implementation. What is your opinion Ard? > >> > > > > > >> > > > > >> > > > I would like to know where the current values in SdMmcPciHcDxe c= ome > >> > > > from if they are not defined in any spec. > >> > > > > >> > > > How do we know which ones are the correct ones? > >> > > > >> > > Hao, can you justify used values? > >> > > > >> > > >> > Hi Hao, > >> > > >> > Can you please take a look at the UHS_MODE_SEL values source for eMM= C? > >> > >> Hi Marcin, > >> > >> Sorry for the delayed response. > >> > >> For the current implementation of the SdMmcPciHcDxe driver, the select= ing > >> of "UHS Mode Select" field value of the Host Control 2 Register is bas= ed > >> on a Max Clock Frequency & Data Rate (Single or Dual) matching > >> relationship between the: > >> > >> A. Table 3-6 of the SD Specifications Part 1 Physical Layer Simplified > >> Specification Version 4.10 > >> > >> and > >> > >> B. Table 4 of the EMMC Electrical Standard Spec 5.1 > >> > >> The matching details was included in my previous reply. The only missi= ng > >> part is there seems no matching for the EMMC HS400 mode in the SD > >> specifications. For this case, we are currently using the same approac= h > >> with the Linux implementation, that is to set the "UHS Mode Select" to= a > >> value of 0x5 (not standard). > >> > > > > Hao, > > > > Thanks a lot for the clarification. > > > > Ard, > > > > Knowing the numbers details, what is your view of the UhsSignaling hand= ling? > > > > I think it makes sense to be able to override the SD->MMC mapping for > HC2 attributes. But it seems to me that this mapping is rather ad-hoc > and so it should apply to all configuration that is inferred: > UhsSignalling does not quite cover it. > > So I think the approach is correct, but we need a better name. Do you mean to update more fields in HC2 than UHS_MODE_SEL?