From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE9EC2B2D7 for ; Sat, 9 May 2026 01:25:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778289931; cv=none; b=NTp/Ms39C6Xfby0rhzVfiIOtRgibaCkaLyv8sKcpa1zxUOSIdb47nKYxgQFf0Pqx5RpKSVl3YTxboHUp0jyhj5RtXRQxs3EH1SUXeYiqPljHliTRz5h9/SPN0MtpA93EDuu3A2OQmJkcFbnkw6VlNFr9YskBClCghNOPXEeOYQY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778289931; c=relaxed/simple; bh=j9Lmxd0EBiOGeCJd3FinThJpBDBQmkh2gbjYsSDedp8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=O2G9/HQFXh7GqcnekfBEM779/iKhE30gz+7D0Ol44hpiEkwRbN+MMmTkiLNkPq8JeKTUlqIZ6NPcHuZACGOgah7a22mpEas/fzpbnKMBWPfY/k8+5/ohj3nZXwMTuKzDLjAlzhCH8odwldLPywhGtq2yhwZoTXOYke9+lPhonO0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu; spf=fail smtp.mailfrom=g.harvard.edu; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b=rZOv8toE; arc=none smtp.client-ip=209.85.222.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=g.harvard.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rowland.harvard.edu header.i=@rowland.harvard.edu header.b="rZOv8toE" Received: by mail-qk1-f180.google.com with SMTP id af79cd13be357-8f83efb5729so268083785a.1 for ; Fri, 08 May 2026 18:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowland.harvard.edu; s=google; t=1778289928; x=1778894728; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=VeR/PK6fy4S2fg4wo5Yl1VM2x30aTvSgB4RD9f2l5Uo=; b=rZOv8toEtJGAs4DqAfGa/nFjek9qy+VF6zgzl40a7Ogf80GKpy50KfFkY2hDKzFveO 0SaBqrQM/CKsiz1k4d9SqfKRWyehIi91CoR0Q8a/blGGG9Fo32nbUS63CM/7DT6ofHA9 WU6jIBqkOr9nvbEqyAkNAsT8oK41Ei08PsuYNz8fqW1lekx/xzmFXaYU9an22Y31hXbt fUHXxZDQn2rzXuVRHlrfgn8FSxNCwmEqV+HjR4aKfltBEialhm0oggvJspvVmGVR9ylO 7X45qen2RpDe2YBYJZY4yLRY4UK7DiQBahtQcxVqS7XfTLPzfZCc874mo7mVQcdMGrOf KUCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778289928; x=1778894728; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=VeR/PK6fy4S2fg4wo5Yl1VM2x30aTvSgB4RD9f2l5Uo=; b=ofNq5klvE+dRNEDE9mKztr6pcXIzsPQMkufme7H9bVh+MyvgJ8S12+VTj09HOuUL3W R72mgmfUBEr/P/XzYZnAuWpWIlQ2k/0PxOxnrlLttLMnivWpBsuywnKvrZ3roZIZad7v lKWm6/Dzjs7Is+q5250y0awckfjAc3b7wUjxLYHY5Gvynqg2pyyd4Ec6WaKXicP2mzjF K583/xfqfzL6GwZITvMePbhIuMG+L/2pk8Utod/092sCNDi9a3/qM9xwr06sbx07ODmi fPc5IDmYRbzUy2lg/2jLV3SWTazOkRV1xpSP8XfDh2SmGGAgitFIFvP5kCcTGIHNamTY KYJQ== X-Gm-Message-State: AOJu0Yx/hHbX36dqJNCnKTn9xo0laSCDaf81LlVflqsikCJg9fyMRN8N ZpuKFVHAGgih2dj+YNzNVUvOxnIPtsStphJERGBrlrybnIVad+dO33kTsVchdT14Ug== X-Gm-Gg: AeBDiet9BAIpzvZuGBL2ZollJpvpphewMdc6OFEsaf7tGk8CNUQfKaXWaOx3jpMy0iL E2jOwwgvXBE2GeXtQ+dzIGmfHZwO5m9hb89+ti+0GwWyK4zFkvJjF0aYK/6RkiTz8jfpQZQUsSV NT3H0EaZwJNAwcLojNqn1nwPnLKAqn+Okql4uD9TLJ1zcdHBvB7mJWJSO6B/H+pRI+syKmb3iiS 0XChM3iLguGpBRmNX8DnKX3XfrDwdW4wu2bEMes5d5uk8bXy0jryaICfh39lgOJFfAsKM7lHY/N kunZ6En2MN2wrJlTnVF/nUksGKIj/beGpiqbdKyhtBF8VfrQeHYkSwqE4fuBc2V71pq4aAzrrN+ mRumpYxWEf09OdvAZ3yulIaVKKPNTWEJFWgwbgFbEyyzvIysOgaR2fl0/3rsfEnJUOzEQNRF/cU WIDfe3y7I0JYjCRwECsNRcA4w0 X-Received: by 2002:a05:620a:4891:b0:8ef:1157:6a05 with SMTP id af79cd13be357-9090e6e24ffmr112480285a.19.1778289928236; Fri, 08 May 2026 18:25:28 -0700 (PDT) Received: from rowland.harvard.edu ([2601:19b:d01:d210::a0bd]) by smtp.gmail.com with ESMTPSA id af79cd13be357-907b87c4036sm364341085a.24.2026.05.08.18.25.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 May 2026 18:25:27 -0700 (PDT) Date: Fri, 8 May 2026 21:25:25 -0400 From: Alan Stern To: Dylan Robinson Cc: linux-usb@vger.kernel.org, mathias.nyman@intel.com Subject: Re: [Bug 220748] usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set Message-ID: <3f63207b-2e34-4b7a-875f-e7a1294ae30e@rowland.harvard.edu> References: <87d93b07-be3e-4c36-a6cb-97190560f648@rowland.harvard.edu> Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, May 08, 2026 at 01:20:04PM -0400, Dylan Robinson wrote: > Perhaps, rather than treating this as a "specified start frame", it > would be better to think of it as a "specified start service > interval". > > If a driver requests a start frame that is not specifically available > within the periodic schedule, it seems reasonable for the HCD to place > the transfer at another valid position within that same service > interval. The actual start frame used could then still be reported > back through the completed URB, which can be inspected by the driver > if it needs to know the precise scheduling decision. > > For endpoints with larger polling intervals, this "nearest valid start > frame" approach seems appropriate, since the device cannot expect > timing granularity finer than its polling interval anyway. That makes sense, and it should be doable. At least for ehci-hcd, and likely for xhci-hcd as well. > > What if the HCD only supports scheduling up to 256 ms in the future, but > > the driver asks for a start frame that is 400 ms in the future? > > On macOS and Windows the submission would fail with an error. That > seems appropriate. > > For example, macOS has the following return status: > - kIOReturnIsoTooNew (Too far in the future) > - kIOReturnIsoTooOld (Too far in the past) > > On Windows, the status of the URB is set to USBD_STATUS_BAD_START_FRAME. We ought to be able to do something similar. > > What if the periodic schedule is already full and there is no bandwidth > > remaining to schedule the new stream? How will the driver find out? By > > getting a different error code from the URB submission? > > The driver needs to know if the stream cannot start. What happens currently? Submission fails with a -ENOSPC error code. On the other hand, if the schedule is set up when the alternate setting is installed, and that can't be done, then the usb_set_interface() call fails. > We can ultimately only provide functionality within the limits of what > the host platform and HCD are capable of supporting. > > In general, the more precise and predictable the scheduling behavior > is, the lower latency and better overall performance the driver can > achieve. Falling back to unspecified scheduling may allow basic > functionality to work, but at the cost of increased buffering, reduced > synchronization accuracy and longer startup delay. All right, let's say what Mathias and Michal have to say about this. Alan Stern