From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by mx.groups.io with SMTP id smtpd.web11.137341.1669683827877965075 for ; Mon, 28 Nov 2022 17:03:48 -0800 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@quicinc.com header.s=qcppdkim1 header.b=m+U32LG4; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: quicinc.com, ip: 205.220.180.131, mailfrom: quic_rcran@quicinc.com) Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2ASN02ni021789; Tue, 29 Nov 2022 01:03:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=QggMXizrRMd9SZsc4PP91l1/u8TAbfycE7VQiPBMflM=; b=m+U32LG4ZiIqPixqfUvkiDUdkJQmMthFMVMqtJ6SqFui+IENxC/zdGowRXzlYOPazYE3 qllINXYg4kmQhZzlYGGOw7w9OiDCNByN9/tTBHQ4LhlNxqRRDO7QCvmGEOo1LD5furTY CrUeh098ZdFfcRI+PJ1mJgGeqmRrdP4qxvseUiQSnVnBHZSmiqUdSoWpje0rsQR3jZvj OjsKTPYDVL+lOVskR0TaXqrqmC72y+/obBd/PqWmVeD4YmxY0DiM+NSjBrWFqN1XuyB3 hpmheBPM6kDWaQkHrqc1cpYshlealIVJfzJoKS4MFRtEbZhdlnytLvfasewykQcAA/Zp oA== Received: from nasanppmta05.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3m513sgupk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Nov 2022 01:03:42 +0000 Received: from nasanex01b.na.qualcomm.com (nasanex01b.na.qualcomm.com [10.46.141.250]) by NASANPPMTA05.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 2AT13ftk009406 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Nov 2022 01:03:41 GMT Received: from [10.110.4.140] (10.80.80.8) by nasanex01b.na.qualcomm.com (10.46.141.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.36; Mon, 28 Nov 2022 17:03:40 -0800 Message-ID: Date: Mon, 28 Nov 2022 18:03:40 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [edk2-devel] On RPi4 and Juno, gBS->Stall(1) takes 10us and 100us respectively To: , , Rebecca Cran References: <8e122797-71cc-401c-62c5-b8515050939a@quicinc.com> <89D8ED77-DA1D-48A7-8FC3-6ED5E402537F@apple.com> From: "Rebecca Cran" In-Reply-To: <89D8ED77-DA1D-48A7-8FC3-6ED5E402537F@apple.com> X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01b.na.qualcomm.com (10.46.141.250) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: mYgH0ORG6aS4MKbSdSbrbUYt2fU3uvby X-Proofpoint-ORIG-GUID: mYgH0ORG6aS4MKbSdSbrbUYt2fU3uvby X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-28_17,2022-11-28_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 spamscore=0 mlxlogscore=999 clxscore=1015 phishscore=0 priorityscore=1501 mlxscore=0 adultscore=0 bulkscore=0 malwarescore=0 suspectscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211290005 X-MIME-Autoconverted: from 8bit to quoted-printable by mx0a-0031df01.pphosted.com id 2ASN02ni021789 Content-Language: en-US Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Thanks. RPi4 and Juno use EmbeddedPkg/MetronomeDxe=20 (https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/MetronomeDxe/Met= ronome.c#L54)=20 which uses the PCD PcdMetronomeTickPeriod. JunoPkg overrides that to 1000, while RPi4 uses the default of 100.=20 Given that the clocks run at 50MHz and 54MHz, I think the tick period=20 should be 1 (1 100-ns unit, giving a clock frequency of 10MHz)? --=20 Rebecca Cran On 11/28/22 12:51, Andrew Fish via groups.io wrote: > Rebecca, >=20 > gBS->Stall() is built on top [1] of the Metronome Architectural Protocol= =20 > [2]. You should look at how the platform implements the Metronome=20 > Architectural Protocol. >=20 > It looks like most platform implement a generic Metronome Driver[3] that= =20 > just sits on top of the platforms TimerLib [4] implementation. >=20 > You can find the TimerLib implementations via: >=20 > $ git grep TimerLib -- \*.inf | grep LIBRARY_CLASS >=20 > ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf:14:=C2=A0 LIBRARY_CLAS= S =20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D TimerLib >=20 > EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf:19:= =C2=A0 LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =3D DebugAgentTimerLib|SEC BASE DXE_CORE >=20 > EmulatorPkg/Library/DxeCoreTimerLib/DxeCoreTimerLib.inf:22: =20 > LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D TimerLib|DXE_CORE DXE_DRIVER=20 > DXE_RUNTIME_DRIVER UEFI_DRIVER UEFI_APPLICATION >=20 > EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.inf:22:=C2=A0 LIBRARY_CLASS = =20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D TimerLib|DXE_DRIVER DXE_RU= NTIME_DRIVER UEFI_DRIVER=20 > UEFI_APPLICATION >=20 > EmulatorPkg/Library/PeiTimerLib/PeiTimerLib.inf:22:=C2=A0 LIBRARY_CLASS = =20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D TimerLib|PEIM PEI_CORE SEC >=20 > MdePkg/Library/BaseTimerLibNullTemplate/BaseTimerLibNullTemplate.inf:23:= =C2=A0 LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =3D TimerLib >=20 > MdePkg/Library/SecPeiDxeTimerLibCpu/SecPeiDxeTimerLibCpu.inf:30: =20 > LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D TimerLib >=20 > OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf:17:=C2=A0 LIBRARY_CLASS= =C2=A0 =3D=20 > TimerLib|PEI_CORE PEIM DXE_CORE >=20 > OvmfPkg/Library/AcpiTimerLib/BaseAcpiTimerLibBhyve.inf:18: =20 > LIBRARY_CLASS=C2=A0 =3D TimerLib >=20 > OvmfPkg/Library/AcpiTimerLib/BaseRomAcpiTimerLib.inf:16:=C2=A0 LIBRARY_CL= ASS =20 > =3D TimerLib|SEC >=20 > OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf:17:=C2=A0 LIBRARY_CLASS= =C2=A0 =3D=20 > TimerLib|DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_DRIVER=20 > UEFI_APPLICATION SMM_CORE >=20 > PcAtChipsetPkg/Library/AcpiTimerLib/BaseAcpiTimerLib.inf:21: =20 > LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D TimerLib|SEC PEI_CORE PEIM >=20 > PcAtChipsetPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf:21: =20 > LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D TimerLib|DXE_CORE DXE_DRIVER=20 > DXE_RUNTIME_DRIVER DXE_SMM_DRIVER UEFI_APPLICATION UEFI_DRIVER SMM_CORE >=20 > PcAtChipsetPkg/Library/AcpiTimerLib/PeiAcpiTimerLib.inf:21: =20 > LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D TimerLib|PEI_CORE PEIM >=20 > PcAtChipsetPkg/Library/AcpiTimerLib/StandaloneMmAcpiTimerLib.inf:23: =20 > LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D TimerLib|MM_CORE_STANDALONE MM_STANDALONE >=20 > UefiCpuPkg/Library/CpuTimerLib/BaseCpuTimerLib.inf:18:=C2=A0 LIBRARY_CLAS= S =20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D TimerLib >=20 > UefiCpuPkg/Library/SecPeiDxeTimerLibUefiCpu/SecPeiDxeTimerLibUefiCpu.inf:= 30:=C2=A0 LIBRARY_CLASS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =3D TimerLib >=20 > UefiPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.inf:15:=C2=A0 LIBRARY_CL= ASS =20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D TimerLib >=20 >=20 > So I=E2=80=99d guess your platform is using the ArmArchTimerLi [5]. If th= at is=20 > the case I=E2=80=99d look at the value of PcdArmArchTimerFreqInHz=C2=A0if= it is zero=20 > then I think you are running on the default ARM timer value. >=20 > If you are using the stock stuff and all your TimerLib instances are the= =20 > same in all your drivers then the TimerLib is also abstraction the=20 > performance measure. >=20 > This is probably not helpful but the UEFI Spec defines that Stall()=20 > delays for at least the requested amount of time, with no upper bound on= =20 > how long it can take. >=20 > [1]=20 > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Misc/= Stall.c#L49 > [2]=20 > https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Protocol/Met= ronome.h#L25 > [3]=20 > https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Universal/Metr= onome/Metronome.c#L61 > [4]=20 > https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/Time= rLib.h > [5]=20 > https://github.com/tianocore/edk2/blob/master/ArmPkg/Library/ArmArchTimer= Lib/ArmArchTimerLib.c#L18 >=20 > Thanks, >=20 > Andrew Fish >=20 >=20 >> On Nov 28, 2022, at 11:02 AM, Rebecca Cran wrot= e: >> >> I've been doing some work on USB and ended up realizing that=20 >> gBS->Stall(1) is taking much longer than it should: on my Juno R2 it's= =20 >> stalling for 100 us, while on my Raspberry Pi 4 it's 10 us. >> >> This appears to be causing a USB bulk transfer request that asks for a= =20 >> 1ms timeout taking 100ms on the Juno. >> >> I'm measuring the delay with the following code: >> >> >> UINT64 First =3D GetPerformanceCounter (); >> >> gBS->Stall (XHC_1_MICROSECOND); >> >> UINT64 Second =3D GetPerformanceCounter (); >> >> UINT64 FirstNs =3D GetTimeInNanoSecond (First); >> UINT64 SecondNs =3D GetTimeInNanoSecond (Second); >> >> DEBUG ((DEBUG_INFO, "Stalled for %llu ns (%llu ms)\n", (SecondNs -=20 >> FirstNs), (SecondNs - FirstNs) / 1024 / 1024)); >> >> >> >> I see output such as: >> >> Stalled for 10500 ns (0 ms) >> >> >> --=20 >> Rebecca Cran >> >> >> >> >> >=20 >=20