| Message ID | 20250116154117.148915-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | usb: dwc3: Avoid using reserved EPs | expand |
On Thu, Jan 16, 2025, Andy Shevchenko wrote: > On some platforms (Intel-based and AFAIK ARM-based) the EPs in the gadget > (USB Device Controller mode) may be reserved for some special means, such as > tracing. This series extends DT schema and driver to avoid using those. > Without this the USB gadget mode won't work properly (those devices that > "luckily" allocated the reserved EPs). > > Ferry already tested the privately sent PoC of this, but I ask him again to > re-test this version which is slightly different. > > Andy Shevchenko (3): > dt-bindings: usb: dwc3: Add a property to reserve endpoints > usb: dwc3: gadget: Add support for snps,reserved-endpoints property > usb: dwc3: gadget: Skip endpoints ep[18]{in,out} on Intel Merrifield > > .../devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++ > drivers/usb/dwc3/dwc3-pci.c | 9 +++++ > drivers/usb/dwc3/gadget.c | 38 ++++++++++++++++++- > 3 files changed, 56 insertions(+), 1 deletion(-) > > -- > 2.43.0.rc1.1336.g36b5255a03ac > I'm not entirely clear on the reason for this change yet. How would this even work without dwc3 managing these endpoints (all the init/teardown/fifo allocation/start/stop flow). Can you provide more info on this hardware? Thanks, Thinh
On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote: > On Thu, Jan 16, 2025, Andy Shevchenko wrote: > > On some platforms (Intel-based and AFAIK ARM-based) the EPs in the gadget > > (USB Device Controller mode) may be reserved for some special means, such as > > tracing. This series extends DT schema and driver to avoid using those. > > Without this the USB gadget mode won't work properly (those devices that > > "luckily" allocated the reserved EPs). > > > > Ferry already tested the privately sent PoC of this, but I ask him again to > > re-test this version which is slightly different. ... > I'm not entirely clear on the reason for this change yet. > > How would this even work without dwc3 managing these endpoints (all the > init/teardown/fifo allocation/start/stop flow). You perhaps know much better how it can be done, I have access to a limited documentation and in practice if those endpoints are not skipped any gadget that allocates them simply won't work, and IIRC the entire USB transfers are stuck. > Can you provide more info on this hardware? I am afraid I can't provide more, sorry. I can look for some specifics, but I'm not that guy who know anything about in-SoC tracing.
Op 16-01-2025 om 16:40 schreef Andy Shevchenko: > On some platforms (Intel-based and AFAIK ARM-based) the EPs in the gadget > (USB Device Controller mode) may be reserved for some special means, such as > tracing. This series extends DT schema and driver to avoid using those. > Without this the USB gadget mode won't work properly (those devices that > "luckily" allocated the reserved EPs). > > Ferry already tested the privately sent PoC of this, but I ask him again to > re-test this version which is slightly different. > > Andy Shevchenko (3): > dt-bindings: usb: dwc3: Add a property to reserve endpoints > usb: dwc3: gadget: Add support for snps,reserved-endpoints property > usb: dwc3: gadget: Skip endpoints ep[18]{in,out} on Intel Merrifield > > .../devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++ > drivers/usb/dwc3/dwc3-pci.c | 9 +++++ > drivers/usb/dwc3/gadget.c | 38 ++++++++++++++++++- > 3 files changed, 56 insertions(+), 1 deletion(-) > Yes I retested this now on v6.13.0-rc7 Intel Merrifield and found no problems. Skipping the tracing end point has definitely always been needed on this platform. Thanks! Tested-by: Ferry Toth <fntoth@gmail.com>
On Fri, Jan 17, 2025 at 03:38:46PM +0200, Andy Shevchenko wrote: > On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote: > > On Thu, Jan 16, 2025, Andy Shevchenko wrote: > > > On some platforms (Intel-based and AFAIK ARM-based) the EPs in the gadget > > > (USB Device Controller mode) may be reserved for some special means, such as > > > tracing. This series extends DT schema and driver to avoid using those. > > > Without this the USB gadget mode won't work properly (those devices that > > > "luckily" allocated the reserved EPs). > > > > > > Ferry already tested the privately sent PoC of this, but I ask him again to > > > re-test this version which is slightly different. ... > > I'm not entirely clear on the reason for this change yet. > > > > How would this even work without dwc3 managing these endpoints (all the > > init/teardown/fifo allocation/start/stop flow). > > You perhaps know much better how it can be done, I have access to a limited > documentation and in practice if those endpoints are not skipped any gadget > that allocates them simply won't work, and IIRC the entire USB transfers are > stuck. > > > Can you provide more info on this hardware? > > I am afraid I can't provide more, sorry. I can look for some specifics, > but I'm not that guy who know anything about in-SoC tracing. So, here is what I found: ---8<--- However the endpoints allocated for STM and EXI debug traffic cannot be re-allocated if being used because the sideband flow control signals are hard wired to certain endpoints: • 1 High BW Bulk IN (IN#1) (RTIT) • 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8) In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System Trace Module) unit and the EXI target driver will as well configure the TRB location for EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage these endpoints and interface to OTG3 controller through EBC interface, there is no need to enable any events (such as XferComplete etc) for these end points. Does it help you to understand the required quirk better?
On Mon, Jan 20, 2025, Andy Shevchenko wrote: > On Fri, Jan 17, 2025 at 03:38:46PM +0200, Andy Shevchenko wrote: > > On Thu, Jan 16, 2025 at 11:18:45PM +0000, Thinh Nguyen wrote: > > > On Thu, Jan 16, 2025, Andy Shevchenko wrote: > > > > On some platforms (Intel-based and AFAIK ARM-based) the EPs in the gadget > > > > (USB Device Controller mode) may be reserved for some special means, such as > > > > tracing. This series extends DT schema and driver to avoid using those. > > > > Without this the USB gadget mode won't work properly (those devices that > > > > "luckily" allocated the reserved EPs). > > > > > > > > Ferry already tested the privately sent PoC of this, but I ask him again to > > > > re-test this version which is slightly different. > > ... > > > > I'm not entirely clear on the reason for this change yet. > > > > > > How would this even work without dwc3 managing these endpoints (all the > > > init/teardown/fifo allocation/start/stop flow). > > > > You perhaps know much better how it can be done, I have access to a limited > > documentation and in practice if those endpoints are not skipped any gadget > > that allocates them simply won't work, and IIRC the entire USB transfers are > > stuck. > > > > > Can you provide more info on this hardware? > > > > I am afraid I can't provide more, sorry. I can look for some specifics, > > but I'm not that guy who know anything about in-SoC tracing. > > So, here is what I found: > > ---8<--- > > However the endpoints allocated for STM and EXI debug traffic cannot be re-allocated > if being used because the sideband flow control signals are hard wired to certain > endpoints: > • 1 High BW Bulk IN (IN#1) (RTIT) > • 1 1KB BW Bulk IN (IN#8) + 1 1KB BW Bulk OUT (Run Control) (OUT#8) > > In device mode, since RTIT (EP#1) and EXI/RunControl (EP#8) uses External Buffer > Control (EBC) mode, these endpoints are to be mapped to EBC mode (to be done by > EXI target driver). Additionally TRB for RTIT and EXI are maintained in STM (System > Trace Module) unit and the EXI target driver will as well configure the TRB location for > EP #1 IN and EP#8 (IN and OUT). Since STM/PTI and EXI hardware blocks manage > these endpoints and interface to OTG3 controller through EBC interface, there is no > need to enable any events (such as XferComplete etc) for these end points. > > Does it help you to understand the required quirk better? > Thanks for looking up the info. This makes more sense now. So these endpoints use EBC. Can you also provide this info to the commit? BR, Thinh
On some platforms (Intel-based and AFAIK ARM-based) the EPs in the gadget (USB Device Controller mode) may be reserved for some special means, such as tracing. This series extends DT schema and driver to avoid using those. Without this the USB gadget mode won't work properly (those devices that "luckily" allocated the reserved EPs). Ferry already tested the privately sent PoC of this, but I ask him again to re-test this version which is slightly different. Andy Shevchenko (3): dt-bindings: usb: dwc3: Add a property to reserve endpoints usb: dwc3: gadget: Add support for snps,reserved-endpoints property usb: dwc3: gadget: Skip endpoints ep[18]{in,out} on Intel Merrifield .../devicetree/bindings/usb/snps,dwc3.yaml | 10 +++++ drivers/usb/dwc3/dwc3-pci.c | 9 +++++ drivers/usb/dwc3/gadget.c | 38 ++++++++++++++++++- 3 files changed, 56 insertions(+), 1 deletion(-)