From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, T_TVD_MIME_EPI autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 23574 invoked from network); 8 Feb 2021 02:55:06 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 8 Feb 2021 02:55:06 -0000 Received: from mail-pf1-f180.google.com ([209.85.210.180]) by 1ess; Sun Feb 7 21:03:11 -0500 2021 Received: by mail-pf1-f180.google.com with SMTP id o20so8745130pfu.0 for <9front@9front.org>; Sun, 07 Feb 2021 18:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mforney-org.20150623.gappssmtp.com; s=20150623; h=message-id:to:subject:from:date:mime-version; bh=eVCZNQjBibXwNBBL+WpVucT6TDQztRsXadhN/M7Dwxo=; b=SV5ym0SfvBSJZXljhPtgXJ90oo5QQcmJjXxn3YF6zvvGHQTH0uaaGGrAPv7pUUjNOU 0tS9LDK3BnX+JdbpWQCWz/71bFJWTj4v+tXPEwWvz6YEc97Ckxaea/QBllhcqAtogfl7 GfWNg5H/lLKrMgo8l0Kcu2L3bg/bJKR0y+RLlGrTudvo+k2TMqohYYQrtOnj3Ay25fr1 N/ISSxEE8XNP/ryuKAI+cz7EkmBsVRtIG2KP9tNIdKwPs+1Km0sC/2Dl//R9zqeX9bZp T508krvjsE8t4s8R6CPMkH2lhdcbqPHKd4YRG4XR1WCQzpqUFC52xsXnuPk/S/zlUBhX 5Bqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:to:subject:from:date:mime-version; bh=eVCZNQjBibXwNBBL+WpVucT6TDQztRsXadhN/M7Dwxo=; b=M2NGlEr7OZBaWmGGlKRR+IuixKaOeCMJaW79kcfTHDe+K7G9VR6PZbJhhXluzDP9iB qPyqRXa6o3MwWwOQR27UC0yGRKMzj1bV7A0LqfCbAPVLu0jFHY7IbSnkIm6jO07nE1Ea WWGyRr72g9GVTx4U91ymu0ztJZEwtmNLfNVFP0cs2sniWNCy9V470Sh/P+AloYVENFyy tb1saAp5QFSrmbc7yKdjv2L9hhlrHIxVfC/BoAapxy+LZLg2HXYbojIwkMT4u53EvJso gDpU0GZHCYjH+XhePMmyeEBfgGP/wczUg8TWOHDFxAvB3kLmakw5b/RmJ7oMqa0G0Nsp d+RQ== X-Gm-Message-State: AOAM5323N6XyC/Y+/oEGxF1lnHI5xG9WxXP9SZuus9SpiWrrDbztrk7J JQrM1CZEISmXojcb5zHs7eKkp5igWHCfhrIoySk= X-Google-Smtp-Source: ABdhPJwhUj0nPuN+4k6xtzF84UO1C/CTa4gOQedCmPdrDoDCCYjTJxI/Rf3GjKnVenYDupaTAZlljQ== X-Received: by 2002:a63:2d3:: with SMTP id 202mr14682064pgc.438.1612749780043; Sun, 07 Feb 2021 18:03:00 -0800 (PST) Return-Path: Received: from arrow.hsd1.ca.comcast.net (c-73-70-188-119.hsd1.ca.comcast.net. [73.70.188.119]) by smtp.gmail.com with ESMTPSA id t189sm2372980pfb.104.2021.02.07.18.02.59 for <9front@9front.org> (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sun, 07 Feb 2021 18:02:59 -0800 (PST) Message-ID: To: 9front@9front.org From: Michael Forney Date: Sun, 07 Feb 2021 18:02:58 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-zsvvfddtzmlmufywzgqogugjem" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: mobile grid WEB2.0 element standard Subject: [9front] USB isochronous endpoint with feedback Reply-To: 9front@9front.org Precedence: bulk This is a multi-part message in MIME format. --upas-zsvvfddtzmlmufywzgqogugjem Content-Disposition: inline Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Hi, I'm working on getting my USB audio DAC to work in 9front. The device implements USB audio 2.0 which is a bit different than the 1.0 supported by nusb/audio, but I made some local changes to deal with that (still WIP though). The main difference is that sampling rate is controlled through a clock source entity connected to the terminal associated with the AS interface rather than being selected through an alternate setting of the AS interface and sampling rate endpoint control. The issue I'm encountering is that the output iso endpoint is asynchronous, and this is not supported by usb(3) or nusb(2). An async iso endpoint is not synchronized to USB (μ)frames, but to some other clock. Instead, sinks use an associated feedback endpoint which provides a fixed-point number of samples to write each frame. This is updated by the device to maintain an optimal buffer level. Luckily, it seems that if I just ignore the feedback endpoint and use the existing pollival/hz/samplesz mechanism, it works well enough. However, the existence of the feedback endpoint breaks several assumptions made in nusb(2). The feedback endpoint has the same number as the data endpoint, which causes usbd to create an unusable rw iso endpoint. Attached patch 1 prevents usbd from creating rw iso endpoints (the feedback endpoint gets mapped to the 0x10|* range, just as for endpoints with different types). The other problem is that nusb(2) assumes that there is a single endpoint per Altc; the settings for the last endpoint in the alt setting take precedence. There is a bit of overlap between fields in Ep and Altc. Both have maxpkt and ntds, but only Altc has pollival. Altc contains the settings of the last endpoint in the alternate setting, and Ep contains the last alt setting of the endpoint, but neither of these is what I want (which is the alt settings of the data endpoint). nusb/audio uses the Altc to prepare the endpoint, so it ends up using the settings for the feedback endpoint to configure the data endpoint. It seems to me that the hierarchy of structures in nusb(2) is not quite right. My best idea about how to fix it is to move Altc from Iface to Ep, since it only seems to be used for endpoint settings. That way, alternate settings for *each* endpoint in the interface are available. We could then drop the maxpkt and ntds fields from Ep, using the ones from altc[0] instead. This would probably be a fairly involved change, and isn't something I want to tackle right now. My current solution is attached patch 2 to keep track of the iso usage in the Ep, and patch 3 to only update the fields in the Altc for *data* endpoints. I believe this should be sufficient for USB audio devices. Anyway, sorry for the long email. Any advice or comments on my patches would be appreciated! -Michael --upas-zsvvfddtzmlmufywzgqogugjem Content-Type: multipart/mixed; boundary="upas-kcflmmocuxcxspulyvdkoxytns" Content-Disposition: inline This is a multi-part message in MIME format. --upas-kcflmmocuxcxspulyvdkoxytns Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit from postmaster@1ess: The following attachment had content that we can't prove to be harmless. To avoid possible automatic execution, we changed the content headers. The original header was: Content-Disposition: attachment; filename=0001-nusb-don-t-create-rw-iso-endpoints.patch Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit --upas-kcflmmocuxcxspulyvdkoxytns Content-Type: application/octet-stream Content-Disposition: attachment; filename="0001-nusb-don-t-create-rw-iso-endpoints.patch.suspect" From da941b80e930c50c1d9fa0f358d2320d3a826b32 From: Michael Forney Date: Sun, 24 Jan 2021 11:27:09 +0000 Subject: nusb: don't create rw iso endpoints There may be two iso endpoints with the same ID if it is asynchronous or adaptive (one for data, one for feedback), and rw iso endpoints are unusable (error out with "iso i/o is half-duplex"). diff 4834fade31f7f2e1845993c1ad873e396e5d03f9 da941b80e930c50c1d9fa0f358d2320d3a826b32 --- a/sys/src/cmd/nusb/lib/parse.c Wed Feb 3 16:19:57 2021 +++ b/sys/src/cmd/nusb/lib/parse.c Sun Jan 24 03:27:09 2021 @@ -127,7 +127,7 @@ ep = mkep(d, epid); ep->dir = dir; }else if((ep->addr & 0x80) != (addr & 0x80)){ - if(ep->type == type) + if(ep->type == type && type != Eiso) ep->dir = Eboth; else { /* --upas-kcflmmocuxcxspulyvdkoxytns-- Content-Disposition: attachment; filename=0002-nusb-record-iso-usage-in-endpoint.patch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit From cbf7e75d538fde63d151c00a715ce89bd396dd5e From: Michael Forney Date: Sun, 24 Jan 2021 11:21:10 +0000 Subject: nusb: record iso usage in endpoint This is needed to differentiate asynchronous data endpoints from their feedback endpoints. diff da941b80e930c50c1d9fa0f358d2320d3a826b32 cbf7e75d538fde63d151c00a715ce89bd396dd5e --- a/sys/src/cmd/nusb/lib/parse.c Sun Jan 24 03:27:09 2021 +++ b/sys/src/cmd/nusb/lib/parse.c Sun Jan 24 03:21:10 2021 @@ -150,6 +150,7 @@ ep->addr = addr; ep->type = type; ep->isotype = (dep->bmAttributes>>2) & 0x03; + ep->isousage = (dep->bmAttributes>>4) & 0x03; ep->conf = c; ep->iface = ip; for(i = 0; i < nelem(ip->ep); i++) --- a/sys/src/cmd/nusb/lib/usb.h Sun Jan 24 03:27:09 2021 +++ b/sys/src/cmd/nusb/lib/usb.h Sun Jan 24 03:21:10 2021 @@ -116,6 +116,11 @@ Eadapt = 2, Esync = 3, + /* endpoint isousage */ + Edata = 0, + Efeedback = 1, + Eimplicit = 2, + /* config attrib */ Cbuspowered = 1<<7, Cselfpowered = 1<<6, @@ -210,6 +215,7 @@ uchar dir; /* direction, Ein/Eout */ uchar type; /* Econtrol, Eiso, Ebulk, Eintr */ uchar isotype; /* Eunknown, Easync, Eadapt, Esync */ + uchar isousage; /* Edata, Efeedback, Eimplicit */ int id; int maxpkt; /* max. packet size */ int ntds; /* nb. of Tds per µframe */ --upas-zsvvfddtzmlmufywzgqogugjem Content-Type: multipart/mixed; boundary="upas-hsuryeskkwrpydlkvmjwnnlxui" Content-Disposition: inline This is a multi-part message in MIME format. --upas-hsuryeskkwrpydlkvmjwnnlxui Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit from postmaster@1ess: The following attachment had content that we can't prove to be harmless. To avoid possible automatic execution, we changed the content headers. The original header was: Content-Disposition: attachment; filename=0003-nusb-only-save-settings-for-data-endpoint-in-Altc.patch Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit --upas-hsuryeskkwrpydlkvmjwnnlxui Content-Type: application/octet-stream Content-Disposition: attachment; filename="0003-nusb-only-save-settings-for-data-endpoint-in-Altc.patch.suspect" From 343d4964099a80a628b5aa6e5606bafc771240d4 From: Michael Forney Date: Sun, 07 Feb 2021 00:37:26 +0000 Subject: nusb: only save settings for data endpoint in Altc Otherwise, the last endpoint in the alternate setting takes precedence, which may be a feedback endpoint for an async iso data endpoint, which is not the one we're interested in. diff cbf7e75d538fde63d151c00a715ce89bd396dd5e 343d4964099a80a628b5aa6e5606bafc771240d4 --- a/sys/src/cmd/nusb/lib/parse.c Sun Jan 24 03:21:10 2021 +++ b/sys/src/cmd/nusb/lib/parse.c Sat Feb 6 16:37:26 2021 @@ -111,8 +111,6 @@ return -1; } dep = (DEp *)b; - altc->attrib = dep->bmAttributes; /* here? */ - altc->interval = dep->bInterval; type = dep->bmAttributes & 0x03; addr = dep->bEndpointAddress; @@ -145,14 +143,18 @@ ep->maxpkt = GET2(dep->wMaxPacketSize); ep->ntds = 1 + ((ep->maxpkt >> 11) & 3); ep->maxpkt &= 0x7FF; - altc->maxpkt = ep->maxpkt; - altc->ntds = ep->ntds; ep->addr = addr; ep->type = type; ep->isotype = (dep->bmAttributes>>2) & 0x03; ep->isousage = (dep->bmAttributes>>4) & 0x03; ep->conf = c; ep->iface = ip; + if(ep->type != Eiso || ep->isousage == Edata || ep->isousage == Eimplicit){ + altc->attrib = dep->bmAttributes; + altc->interval = dep->bInterval; + altc->maxpkt = ep->maxpkt; + altc->ntds = ep->ntds; + } for(i = 0; i < nelem(ip->ep); i++) if(ip->ep[i] == nil) break; --upas-hsuryeskkwrpydlkvmjwnnlxui--