From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) by mx.groups.io with SMTP id smtpd.web10.127144.1669662153216400360 for ; Mon, 28 Nov 2022 11:02:33 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=zajgfCap; spf=permerror, err=parse error for token &{10 18 %{ir}.%{v}.%{d}.spf.has.pphosted.com}: invalid domain name (domain: quicinc.com, ip: 199.106.114.38, mailfrom: quic_rcran@quicinc.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1669662153; x=1701198153; h=from:message-id:date:mime-version:to:subject: content-transfer-encoding; bh=fsxTN2iZr54X2pLPKeV8nPnM1/H7g0P7mJviiZOu0mM=; b=zajgfCapfNIBXpv0vKeYJum10sOxV5FZXuBW95nYzUHQW7zUvoyWWhMv nWAoXyrI9MrkY3+TzGyyGMpqUP0ZHgP0176bFCCLDJAndMzF78OC9zkMB odYXlzrXX1xuqXlqSXLXjksfEu6qclcl8tKDesRAU1Jl7A2e5+f2BDBjb c=; Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by alexa-out-sd-01.qualcomm.com with ESMTP; 28 Nov 2022 11:02:32 -0800 From: "Rebecca Cran" X-QCInternal: smtphost Received: from nasanex01b.na.qualcomm.com ([10.46.141.250]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 11:02:32 -0800 Received: from [10.110.1.110] (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 11:02:32 -0800 Message-ID: <8e122797-71cc-401c-62c5-b8515050939a@quicinc.com> Date: Mon, 28 Nov 2022 12:02:31 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 To: Subject: On RPi4 and Juno, gBS->Stall(1) takes 10us and 100us respectively Return-Path: rebecca@quicinc.com X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nasanex01b.na.qualcomm.com (10.46.141.250) Content-Language: en-US Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit I've been doing some work on USB and ended up realizing that gBS->Stall(1) is taking much longer than it should: on my Juno R2 it's 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 1ms timeout taking 100ms on the Juno. I'm measuring the delay with the following code: UINT64 First = GetPerformanceCounter (); gBS->Stall (XHC_1_MICROSECOND); UINT64 Second = GetPerformanceCounter (); UINT64 FirstNs = GetTimeInNanoSecond (First); UINT64 SecondNs = GetTimeInNanoSecond (Second); DEBUG ((DEBUG_INFO, "Stalled for %llu ns (%llu ms)\n", (SecondNs - FirstNs), (SecondNs - FirstNs) / 1024 / 1024)); I see output such as: Stalled for 10500 ns (0 ms) -- Rebecca Cran