From: Mathias Nyman <mathias.nyman@linux.intel.com> To: Wesley Cheng <quic_wcheng@quicinc.com>, srinivas.kandagatla@linaro.org, mathias.nyman@intel.com, perex@perex.cz, broonie@kernel.org, lgirdwood@gmail.com, andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org, gregkh@linuxfoundation.org, Thinh.Nguyen@synopsys.com, bgoswami@quicinc.com, tiwai@suse.com, robh+dt@kernel.org, agross@kernel.org, Alan Stern <stern@rowland.harvard.edu> Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-usb@vger.kernel.org, quic_jackp@quicinc.com, quic_plai@quicinc.com Subject: Re: [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter support Date: Tue, 10 Jan 2023 21:47:47 +0200 [thread overview] Message-ID: <cefcc5c6-6a91-c737-252a-edf596f77473@linux.intel.com> (raw) In-Reply-To: <d1334e58-1126-c068-d211-8fd3b7dcbf17@quicinc.com> On 9.1.2023 22.24, Wesley Cheng wrote: > Hi Mathias, > > On 1/2/2023 8:38 AM, Mathias Nyman wrote: >> On 29.12.2022 23.14, Wesley Cheng wrote: >>> Hi Mathias, >>> >>> On 12/28/2022 7:47 AM, Mathias Nyman wrote: >>>> On 24.12.2022 1.31, Wesley Cheng wrote: >>>>> Implement the XHCI operations for allocating and requesting for a secondary >>>>> interrupter. The secondary interrupter can allow for events for a >>>>> particular endpoint to be routed to a separate event ring. The event >>>>> routing is defined when submitting a transfer descriptor to the USB HW. >>>>> There is a specific field which denotes which interrupter ring to route the >>>>> event to when the transfer is completed. >>>>> >>>>> An example use case, such as audio packet offloading can utilize a separate >>>>> event ring, so that these events can be routed to a different processor >>>>> within the system. The processor would be able to independently submit >>>>> transfers and handle its completions without intervention from the main >>>>> processor. >>>>> >>>> >>>> Adding support for more xHCI interrupters than just the primary one make sense for >>>> both the offloading and virtualization cases. >>>> >>>> xHCI support for several interrupters was probably added to support virtualization, >>>> to hand over usb devices to virtual machines and give them their own event ring and >>>> MSI/MSI-X vector. >>>> >>>> In this offloading case you probably want to avoid xHC interrupts from this device >>>> completely, making sure it doesn't wake up the main CPU unnecessarily. >>>> >>>> So is the idea here to let xhci driver set up the new interrupter, its event ring, >>>> and the endpoint transfer rings. Then pass the address of the endpoint transfer rings >>>> and the new event ring to the separate processor. >>>> >>>> This separate processor then both polls the event ring for new events, sets its dequeue >>>> pointer, clears EHB bit, and queues new TRBs on the transfer ring. >>>> >>>> so xhci driver does not handle any events for the audio part, and no audio data URBs >>>> are sent to usb core? >>> >>> Your entire description is correct. To clarify, the interfaces which are non-audio will still be handled by the main processor. For example, a USB headset can have a HID interface as well for volume control. The HID interface will still be handled by the main processor, and events routed to the main event ring. >>> >>>> >>>> How about the control part? >>>> Is the control endpoint for this device still handled normally by usb core/xhci? >>>> >>> >>> Control transfers are always handled on the main processor. Only audio interface's endpoints. >> >> Good to know, that means interrupter should be chosen per endpoint, not per device. >> >>> >>>> For the xhci parts I think we should start start by adding generic support for several >>>> interrupters, then add parts needed for offloading. >>> >> I can split up the patchsets to add interrupters first, then adding the offloading APIs in a separate patch. >> >> >> I started looking at supporting secondary interrupters myself. >> Let me work on that part a bit first. We have a bit different end goals. >> I want to handle interrupts from a secondary interrupter, while this audio offload >> really just wants to mask some interrupts. >> > > I was looking at how we could possibly split up the XHCI secondary interrupter, and offloading parts. Since the XHCI secondary interrupter is a feature that is defined in the XHCI spec (and we aren't doing anything outside of what is defined), I was thinking of having a separate XHCI driver (ie xhci-sec.c/h) that can be used to define all APIs related to setting up the event ring and ring management. (interrupt support can be added here) This aligns a bit with what Alan suggested, and removing the APIs in the USB HCD, since this is XHCI specific stuff. ( https://lore.kernel.org/linux-usb/Y6zwZOquZOTZfnvP@rowland.harvard.edu/ ) Already started working on the interrupter, that part fits well into current driver. Code (untested, will be randomly rebased etc) can be found in my feature_interrupters branch: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git feature_interrupters https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters First step turns current event ring into a primary interrupter. last patch is a test implementation for creating and freeing new secondary interrupters. > > For the offloading part, I think this is a bit more dependent on how different platforms implement it. To use more of a generic approach like how Albert suggested here: > > https://patchwork.kernel.org/project/linux-usb/list/?series=704174 > > Basically to give vendors the ability to define their own sequences/callbacks, and from which the XHCI driver will call into. (if needed) These would need to be a separate set of XHCI drivers as well. > > Do you think this is a proper model for us to go with, so that we can allow for vendors to easily add functionality? Appreciate the inputs. I'm not convinced that overriding different xhci memory allocation functions is the best solution. I think xhci driver will need to know which endpoints are offloaded. maybe usb class driver could register an "offloader" with xhci for a usb device. Trying to figure out what this xhci offload API would look like. The dsp needs at least dma address of an event ring, and offloaded endpoint rings. Is there anything else that the dsp would directly need to take care of, or can we just export some xhci functions for starting/stopping endpoints, and update event deq? Thanks -Mathias
WARNING: multiple messages have this Message-ID (diff)
From: Mathias Nyman <mathias.nyman@linux.intel.com> To: Wesley Cheng <quic_wcheng@quicinc.com>, srinivas.kandagatla@linaro.org, mathias.nyman@intel.com, perex@perex.cz, broonie@kernel.org, lgirdwood@gmail.com, andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org, gregkh@linuxfoundation.org, Thinh.Nguyen@synopsys.com, bgoswami@quicinc.com, tiwai@suse.com, robh+dt@kernel.org, agross@kernel.org, Alan Stern <stern@rowland.harvard.edu> Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, quic_jackp@quicinc.com, quic_plai@quicinc.com Subject: Re: [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter support Date: Tue, 10 Jan 2023 21:47:47 +0200 [thread overview] Message-ID: <cefcc5c6-6a91-c737-252a-edf596f77473@linux.intel.com> (raw) In-Reply-To: <d1334e58-1126-c068-d211-8fd3b7dcbf17@quicinc.com> On 9.1.2023 22.24, Wesley Cheng wrote: > Hi Mathias, > > On 1/2/2023 8:38 AM, Mathias Nyman wrote: >> On 29.12.2022 23.14, Wesley Cheng wrote: >>> Hi Mathias, >>> >>> On 12/28/2022 7:47 AM, Mathias Nyman wrote: >>>> On 24.12.2022 1.31, Wesley Cheng wrote: >>>>> Implement the XHCI operations for allocating and requesting for a secondary >>>>> interrupter. The secondary interrupter can allow for events for a >>>>> particular endpoint to be routed to a separate event ring. The event >>>>> routing is defined when submitting a transfer descriptor to the USB HW. >>>>> There is a specific field which denotes which interrupter ring to route the >>>>> event to when the transfer is completed. >>>>> >>>>> An example use case, such as audio packet offloading can utilize a separate >>>>> event ring, so that these events can be routed to a different processor >>>>> within the system. The processor would be able to independently submit >>>>> transfers and handle its completions without intervention from the main >>>>> processor. >>>>> >>>> >>>> Adding support for more xHCI interrupters than just the primary one make sense for >>>> both the offloading and virtualization cases. >>>> >>>> xHCI support for several interrupters was probably added to support virtualization, >>>> to hand over usb devices to virtual machines and give them their own event ring and >>>> MSI/MSI-X vector. >>>> >>>> In this offloading case you probably want to avoid xHC interrupts from this device >>>> completely, making sure it doesn't wake up the main CPU unnecessarily. >>>> >>>> So is the idea here to let xhci driver set up the new interrupter, its event ring, >>>> and the endpoint transfer rings. Then pass the address of the endpoint transfer rings >>>> and the new event ring to the separate processor. >>>> >>>> This separate processor then both polls the event ring for new events, sets its dequeue >>>> pointer, clears EHB bit, and queues new TRBs on the transfer ring. >>>> >>>> so xhci driver does not handle any events for the audio part, and no audio data URBs >>>> are sent to usb core? >>> >>> Your entire description is correct. To clarify, the interfaces which are non-audio will still be handled by the main processor. For example, a USB headset can have a HID interface as well for volume control. The HID interface will still be handled by the main processor, and events routed to the main event ring. >>> >>>> >>>> How about the control part? >>>> Is the control endpoint for this device still handled normally by usb core/xhci? >>>> >>> >>> Control transfers are always handled on the main processor. Only audio interface's endpoints. >> >> Good to know, that means interrupter should be chosen per endpoint, not per device. >> >>> >>>> For the xhci parts I think we should start start by adding generic support for several >>>> interrupters, then add parts needed for offloading. >>> >> I can split up the patchsets to add interrupters first, then adding the offloading APIs in a separate patch. >> >> >> I started looking at supporting secondary interrupters myself. >> Let me work on that part a bit first. We have a bit different end goals. >> I want to handle interrupts from a secondary interrupter, while this audio offload >> really just wants to mask some interrupts. >> > > I was looking at how we could possibly split up the XHCI secondary interrupter, and offloading parts. Since the XHCI secondary interrupter is a feature that is defined in the XHCI spec (and we aren't doing anything outside of what is defined), I was thinking of having a separate XHCI driver (ie xhci-sec.c/h) that can be used to define all APIs related to setting up the event ring and ring management. (interrupt support can be added here) This aligns a bit with what Alan suggested, and removing the APIs in the USB HCD, since this is XHCI specific stuff. ( https://lore.kernel.org/linux-usb/Y6zwZOquZOTZfnvP@rowland.harvard.edu/ ) Already started working on the interrupter, that part fits well into current driver. Code (untested, will be randomly rebased etc) can be found in my feature_interrupters branch: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git feature_interrupters https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/log/?h=feature_interrupters First step turns current event ring into a primary interrupter. last patch is a test implementation for creating and freeing new secondary interrupters. > > For the offloading part, I think this is a bit more dependent on how different platforms implement it. To use more of a generic approach like how Albert suggested here: > > https://patchwork.kernel.org/project/linux-usb/list/?series=704174 > > Basically to give vendors the ability to define their own sequences/callbacks, and from which the XHCI driver will call into. (if needed) These would need to be a separate set of XHCI drivers as well. > > Do you think this is a proper model for us to go with, so that we can allow for vendors to easily add functionality? Appreciate the inputs. I'm not convinced that overriding different xhci memory allocation functions is the best solution. I think xhci driver will need to know which endpoints are offloaded. maybe usb class driver could register an "offloader" with xhci for a usb device. Trying to figure out what this xhci offload API would look like. The dsp needs at least dma address of an event ring, and offloaded endpoint rings. Is there anything else that the dsp would directly need to take care of, or can we just export some xhci functions for starting/stopping endpoints, and update event deq? Thanks -Mathias
next prev parent reply other threads:[~2023-01-10 19:46 UTC|newest] Thread overview: 171+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-12-23 23:31 [RFC PATCH 00/14] Introduce QC USB SND audio offloading support Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 01/14] ASoC: Add SOC USB APIs for adding an USB backend Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 6:48 ` Greg KH 2022-12-24 6:48 ` Greg KH 2022-12-23 23:31 ` [RFC PATCH 02/14] ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 1:37 ` kernel test robot 2023-01-04 23:33 ` Pierre-Louis Bossart 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 16:09 ` Pierre-Louis Bossart 2023-01-07 0:51 ` Wesley Cheng 2023-01-07 0:51 ` Wesley Cheng 2023-01-05 18:09 ` Krzysztof Kozlowski 2023-01-05 18:09 ` Krzysztof Kozlowski 2023-01-06 1:32 ` Wesley Cheng 2023-01-06 1:32 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 03/14] ASoC: qcom: Add USB backend ASoC driver for Q6 Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 2:17 ` kernel test robot 2022-12-24 2:17 ` kernel test robot 2022-12-24 9:02 ` Greg KH 2022-12-24 9:02 ` Greg KH 2022-12-27 13:04 ` Mark Brown 2022-12-27 13:04 ` Mark Brown 2022-12-27 13:45 ` Greg KH 2022-12-27 13:45 ` Greg KH 2022-12-27 14:02 ` Takashi Iwai 2022-12-27 14:02 ` Takashi Iwai 2022-12-27 14:11 ` Mark Brown 2022-12-27 14:11 ` Mark Brown 2022-12-27 15:11 ` Mark Brown 2022-12-27 15:11 ` Mark Brown 2022-12-27 21:06 ` Wesley Cheng 2022-12-27 21:06 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2023-01-04 23:41 ` Pierre-Louis Bossart 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 16:16 ` Pierre-Louis Bossart 2022-12-23 23:31 ` [RFC PATCH 04/14] sound: usb: card: Introduce USB SND vendor op callbacks Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 11:03 ` Dmitry Baryshkov 2022-12-24 11:03 ` Dmitry Baryshkov 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:33 ` Dmitry Baryshkov 2022-12-27 21:33 ` Dmitry Baryshkov 2022-12-29 13:49 ` Oliver Neukum 2022-12-29 13:49 ` Oliver Neukum 2022-12-29 14:20 ` Takashi Iwai 2022-12-29 14:20 ` Takashi Iwai 2022-12-30 7:10 ` Wesley Cheng 2022-12-30 7:10 ` Wesley Cheng 2023-01-03 12:20 ` Oliver Neukum 2023-01-03 12:20 ` Oliver Neukum 2023-01-03 12:49 ` Takashi Iwai 2023-01-03 12:49 ` Takashi Iwai 2023-01-03 23:45 ` Wesley Cheng 2023-01-03 23:45 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 05/14] sound: usb: Export USB SND APIs for modules Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 6:48 ` Greg KH 2022-12-24 6:48 ` Greg KH 2022-12-23 23:31 ` [RFC PATCH 06/14] usb: core: hcd: Introduce USB HCD APIs for interrupter management Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 8:54 ` Greg KH 2022-12-24 8:54 ` Greg KH 2022-12-27 21:13 ` Wesley Cheng 2022-12-27 21:13 ` Wesley Cheng 2022-12-24 15:29 ` Alan Stern 2022-12-24 15:29 ` Alan Stern 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2022-12-28 8:59 ` Oliver Neukum 2022-12-28 8:59 ` Oliver Neukum 2022-12-28 15:16 ` Alan Stern 2022-12-28 15:16 ` Alan Stern 2022-12-28 20:31 ` Wesley Cheng 2022-12-28 20:31 ` Wesley Cheng 2022-12-29 1:41 ` Alan Stern 2022-12-29 1:41 ` Alan Stern 2022-12-23 23:31 ` [RFC PATCH 07/14] usb: host: xhci: Add XHCI secondary interrupter support Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 5:59 ` kernel test robot 2022-12-24 8:55 ` Greg KH 2022-12-24 8:55 ` Greg KH 2022-12-28 15:47 ` Mathias Nyman 2022-12-28 15:47 ` Mathias Nyman 2022-12-29 21:14 ` Wesley Cheng 2022-12-29 21:14 ` Wesley Cheng 2023-01-02 16:38 ` Mathias Nyman 2023-01-02 16:38 ` Mathias Nyman 2023-01-09 20:24 ` Wesley Cheng 2023-01-09 20:24 ` Wesley Cheng 2023-01-10 19:47 ` Mathias Nyman [this message] 2023-01-10 19:47 ` Mathias Nyman 2023-01-10 20:03 ` Wesley Cheng 2023-01-10 20:03 ` Wesley Cheng 2023-01-11 3:11 ` Wesley Cheng 2023-01-11 3:11 ` Wesley Cheng 2023-01-12 9:24 ` Mathias Nyman 2023-01-12 9:24 ` Mathias Nyman 2023-01-13 0:34 ` Wesley Cheng 2023-01-13 0:34 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 08/14] usb: dwc3: Add DT parameter to specify maximum number of interrupters Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 11:13 ` Dmitry Baryshkov 2022-12-24 11:13 ` Dmitry Baryshkov 2022-12-26 12:28 ` Krzysztof Kozlowski 2022-12-26 12:28 ` Krzysztof Kozlowski 2022-12-27 21:06 ` Wesley Cheng 2022-12-27 21:06 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 09/14] sound: usb: Introduce QC USB SND offloading support Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 2:27 ` kernel test robot 2023-01-02 17:28 ` Takashi Iwai 2023-01-02 17:28 ` Takashi Iwai 2023-01-04 22:38 ` Wesley Cheng 2023-01-04 22:38 ` Wesley Cheng 2023-01-04 23:51 ` Pierre-Louis Bossart 2023-01-06 1:06 ` Wesley Cheng 2023-01-06 1:06 ` Wesley Cheng 2022-12-23 23:31 ` [RFC PATCH 10/14] sound: usb: card: Check for support for requested audio format Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 8:59 ` Greg KH 2022-12-24 8:59 ` Greg KH 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 21:07 ` Wesley Cheng 2022-12-27 20:31 ` kernel test robot 2022-12-23 23:31 ` [RFC PATCH 11/14] sound: soc: soc-usb: Add PCM format check API for USB backend Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 2:17 ` kernel test robot 2022-12-24 2:17 ` kernel test robot 2022-12-23 23:31 ` [RFC PATCH 12/14] sound: soc: qcom: qusb6: Ensure PCM format is supported by USB audio device Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-24 8:19 ` Sergey Shtylyov 2022-12-24 8:19 ` Sergey Shtylyov 2022-12-24 8:50 ` Wesley Cheng 2022-12-24 8:50 ` Wesley Cheng 2023-01-03 17:44 ` Mark Brown 2023-01-03 17:44 ` Mark Brown 2022-12-23 23:31 ` [RFC PATCH 13/14] ASoC: dt-bindings: Add Q6USB backend bindings Wesley Cheng 2022-12-23 23:31 ` Wesley Cheng 2022-12-26 12:25 ` Krzysztof Kozlowski 2022-12-26 12:25 ` Krzysztof Kozlowski 2022-12-23 23:32 ` [RFC PATCH 14/14] ASoC: dt-bindings: Update example for enabling USB offload on SM8250 Wesley Cheng 2022-12-23 23:32 ` Wesley Cheng 2022-12-26 12:27 ` Krzysztof Kozlowski 2022-12-26 12:27 ` Krzysztof Kozlowski 2023-01-03 17:46 ` Mark Brown 2023-01-03 17:46 ` Mark Brown 2023-01-05 18:09 ` Krzysztof Kozlowski 2023-01-05 18:09 ` Krzysztof Kozlowski 2023-01-04 0:46 ` Rob Herring 2023-01-04 0:46 ` Rob Herring 2022-12-24 6:45 ` [RFC PATCH 00/14] Introduce QC USB SND audio offloading support Greg KH 2022-12-24 6:45 ` Greg KH 2022-12-24 8:49 ` Wesley Cheng 2022-12-24 8:49 ` Wesley Cheng 2022-12-27 14:36 ` Mark Brown 2022-12-27 14:36 ` Mark Brown 2023-01-04 23:19 ` Pierre-Louis Bossart 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 1:05 ` Wesley Cheng 2023-01-06 15:57 ` Pierre-Louis Bossart 2023-01-07 0:46 ` Wesley Cheng 2023-01-07 0:46 ` Wesley Cheng
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cefcc5c6-6a91-c737-252a-edf596f77473@linux.intel.com \ --to=mathias.nyman@linux.intel.com \ --cc=Thinh.Nguyen@synopsys.com \ --cc=agross@kernel.org \ --cc=alsa-devel@alsa-project.org \ --cc=andersson@kernel.org \ --cc=bgoswami@quicinc.com \ --cc=broonie@kernel.org \ --cc=devicetree@vger.kernel.org \ --cc=gregkh@linuxfoundation.org \ --cc=krzysztof.kozlowski+dt@linaro.org \ --cc=lgirdwood@gmail.com \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-usb@vger.kernel.org \ --cc=mathias.nyman@intel.com \ --cc=perex@perex.cz \ --cc=quic_jackp@quicinc.com \ --cc=quic_plai@quicinc.com \ --cc=quic_wcheng@quicinc.com \ --cc=robh+dt@kernel.org \ --cc=srinivas.kandagatla@linaro.org \ --cc=stern@rowland.harvard.edu \ --cc=tiwai@suse.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.