From: Wesley Cheng <quic_wcheng@quicinc.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
<srinivas.kandagatla@linaro.org>, <mathias.nyman@intel.com>,
<perex@perex.cz>, <broonie@kernel.org>, <lgirdwood@gmail.com>,
<krzysztof.kozlowski+dt@linaro.org>, <agross@kernel.org>,
<Thinh.Nguyen@synopsys.com>, <bgoswami@quicinc.com>,
<andersson@kernel.org>, <robh+dt@kernel.org>,
<gregkh@linuxfoundation.org>, <tiwai@suse.com>
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: [PATCH v3 00/28] Introduce QC USB SND audio offloading support
Date: Mon, 13 Mar 2023 18:42:54 -0700 [thread overview]
Message-ID: <0810f951-f4a6-a51d-97e3-43691b05f702@quicinc.com> (raw)
In-Reply-To: <8a37ccd3-f19e-b30d-d736-04e81b49f3a0@linux.intel.com>
Hi Pierre,
On 3/13/2023 5:42 PM, Pierre-Louis Bossart wrote:
>
>
> On 3/13/23 18:43, Wesley Cheng wrote:
>> Hi Pierre,
>>
>> On 3/9/2023 4:37 PM, Pierre-Louis Bossart wrote:
>>>
>>>>>> Create vendor ops for the USB SND driver:
>>>>>> qc_audio_offload: This particular driver has several components
>>>>>> associated
>>>>>> with it:
>>>>>> - QMI stream request handler
>>>>>> - XHCI interrupter and resource management
>>>>>> - audio DSP memory management
>>>>>
>>>>> so how does this 'qc_audio_offload' interface with 'q6usb' described
>>>>> above? how are the roles different or complementary?
>>>>>
>>>> So in general you can think that the qc_audio_offload is a complement to
>>>> the USB SND USB class driver, while q6usb is to ASoC. Since the ASoC
>>>
>>> Humm, that is far from clear. I don't get how a something that interacts
>>> with the USB class driver can also be in charge of the audio DSP memory
>>> management.
>>>
>>
>> This is because the USB class driver is the entity which is going to
>> work with the USB HCD (XHCI) in this case to fetch the required
>> addresses, and map that into memory accessible by the audio DSP. It
>> would be odd to be doing that from the q6usb end, which is part of the
>> ASoC layer.
>>
>>>> framework doesn't have any communication with USB SND, the ASoC DPCM USB
>>>> backend (q6usb) will have to be the entity that maintains what is going
>>>> on in USB SND. That way, sessions initiated through the ASoC managed
>>>> sound card can evaluate what is available based on information reported
>>>> by q6usb.
>>>>
>>>> qc_audio_offload and q6usb will have some interaction between each
>>>> other. The majority of communication between qc_audio_offload and q6usb
>>>> is reporting the device connection events.
>>>
>>> It's already complicated to figure out how the DSP and USB class driver
>>> might interact and probe/timing dependencies, but with two additional
>>> drivers in the mix it's really hard to understand.
>>>
>>
>> I did test some cases based on existence of both these drivers
>> (qc_audio_offload and q6usb). If either one doesn't exist in the
>> system, then the offload path would not work. I did improve some of
>> these potential sequences in the latest revision, such as patch#28. This
>> would address scenarios where the q6usb ASoC DPCM backend wasn't probed,
>> while the USB SND (and qc_audio_offload) were still detecting device
>> connections.
>>
>> Once the Q6USB driver is probed, then the offload snd kcontrols would be
>> created, and devices would be properly identified with the rediscover api.
>>
>>> Maybe ascii-art would help describe the concepts and types of
>>> information exchanged. Maintaining a consistent state across multiple
>>> drivers is not an easy task.
>>>
>>
>> Hopefully this might help? I know its a lot to read through.
>
> It's very helpful! Thanks for spending the time to illustrate the
> different building blocks.
>
>>
>> USB | ASoC
>> --------------------------------------------------------------------
>> | _________________________
>> | |sm8250 platform card |
>> | |_________________________|
>> | | |
>> | ___V____ ____V____
>> | |Q6USB | |Q6AFE | #5
>> | |"codec" | |"cpu" |
>> | |________| |_________|
>> | ^
>> | | #6
>> | ___V____
>> | |SOC-USB |
>> ________ #1 ________ #7 | |
>> |USB SND |<--->|QC offld|<------------>|________|
>> |(card.c)| | |<---------- ^
>> |________| |________|___ #4 | | |
>> ^ ^ | | | ___V__________________
>> | #2 | #2 | | | |APR/GLINK |
>> __ V_______________V_____ | | | |______________________|
>> |USB SND (endpoint.c) | | | | ^
>> |_________________________| | | | #8 |
>> ^ | | | ___________V___________
>> | #3 | | |->|audio DSP |
>> ___________V_____________ | | |_______________________|
>> |XHCI HCD |<- |
>> |_________________________| |
>>
>>
>> #1 - USB SND and QC offload:
>> Initialization:
>> - Register platform operations, to receive connect/disconnect events
>> from USB SND.
>> - QC offload creates a QMI handle, in order to receive QMI requests
>> from the audio DSP.
>>
>> Runtime:
>> - USB SND passes along "struct snd_usb_audio" in order for QC offload
>> to reference USB UAC desc parsing/USB SND helper APIs.
>> - USB device disconnection events will result in clearing of the chip
>> entry.
>>
>> #2 - USB SND and QC offload endpoints:
>> Runtime:
>> - In the non-offloaded path, USB snd will utilize functions exposed by
>> USB SND endpoint, to help with fetching USB EP references and queuing
>> URBs.
>> - In the offload path, qc offload will utilize the functions to fetch
>> USB EP references, so that it can use that information to query the
>> XHCI HCD.
>> - Likewise, both will clean up endpoints when audio stream is not in use.
>>
>> #3 - XHCI HCD:
>> Initialization:
>> - During XHCI probe timing, when the USB HCD is added to the system, it
>> will also initialize the secondary event rings.
>>
>> Runtime:
>> - During USB device plug ins/outs, allocates device slot, assigns eps,
>> and initializes transfer rings.
>>
>> #4 - QC offload and XHCI:
>> Runtime:
>> - QC offload needs to reference the transfer ring and secondary event ring
>> addresses by executing XHCI offload management APIs.
>> - This happens when audio DSP receives a USB QMI stream request.
>>
>> #5 - ASoC components:
>> Initialization:
>> - The SM8250 platform sound card driver fetches DT node entries defining
>> the ASoC links. This chain/link has the components involved for a
>> particular Q6AFE path. (not only USB offload)
>> - "cpu" - this is the ASoC CPU DAI that handles interaction with the
>> Q6 DSP's audio protocol. (AFE ports)
>> - "codec" - the ASoC codec (backend) DAI defined
>> - Registers ASoC platform sound card based on links defined in the DT node.
>> - Probes DAI components involved, ie Q6USB and Q6AFE
>>
>> Runtime:
>> - Q6AFE has the bulk of the interaction w/ the audio DSP to start an audio
>> session, such as issuing AFE port start commands (part of the protocol
>> used to communicate the audio session info)
>> - Q6USB will be there to now check for if format requested is supported by
>> the device, and maintain offloading status.
>>
>> #6 - Q6USB and SOC-USB:
>> Initialization:
>> - Q6USB will query QC offload for USB device connection states. (through
>> soc-usb)
>> - Creates a SOC USB entry, that carries information about resources,
>> such as audio DSP memory information and requested XHCI event ring
>> index.
>>
>> Runtime:
>> - SOC-USB will receive connect/disconnect events and propagate to Q6USB.
>> - Q6USB makes devices available for offloading based on these events.
>> - Sets Q6AFE port configurations to select the USB SND card# and PCM#.
>>
>> #7 - SOC-USB and QC offload:
>> Initialization:
>> - Rediscover USB SND devices when the SOC-USB entry is created (if needed)
>> - For situations where the Q6USB DAI hasn't been probed.
>>
>> Runtime:
>> - Propagate connect/disconnect events.
>
> Is the SOC-USB module or building blocks intended to be generic or
> Qualcomm agnostic?
>
This should be generic.
> It's not clear to me how it would handle "audio DSP memory information
> and requested XHCI event ring index."
>
Each soc-usb entry that is created by the ASoC DPCM backend DAI (q6usb)
will be able to hold "private data" that, in QC case, is defined as:
struct q6usb_offload
This is passed within the snd_soc_usb_add_port() call:
snd_soc_usb_add_port(component->dev, &data->priv, q6usb_alsa_connection_cb);
So depending on the user, the private data can contain their own struct
with the information they require.
> In addition, it seems to be the "bridge" or means of communication
> between qc_audio_offload and q6usb, is this not based on custom events
> or triggers?
>
Ideally, no, it shouldn't be based on custom events. Intention for the
connect_cb() that is defined is just to receive USB device discovery
events from USB SND. From the qc_audio_offload, we call
snd_soc_usb_connect() within our platform op that we register to USB SND.
//Platform connect_cb() - called from USB SND probe (device connected)
static void qc_usb_audio_offload_probe(struct snd_usb_audio *chip)
{
...
snd_soc_usb_connect(usb_get_usb_backend(udev), chip->card->number,
chip->index, chip->pcm_devs);
In the QC situation, we used this to build a list of active devices
connected.
> Along the same lines, this SOC-USB entity interfaces with APR/GLINK
> which doesn't speak to me so it must be a QCOM interface?
>
Sorry for not labeling those in the diagram, but yes, those are QC
specific interfaces. You can just think of it as a type of IPC transport.
> I am trying to see if this design could be used for other architectures,
> and the QCOM-specific and generic parts are not obvious.
>
>> #8 - audio DSP and QC offload:
>> Runtime:
>> - Handle QMI requests coming from audio DSP. These requests come AFTER
>> the Q6AFE port is opened by the Q6AFE DAI(#6)
>> - Returns memory information about resources allocated by XHCI.
>> - Enables audio playback when this QMI transaction is completed.
>>
>>>>
>>>>>> When the audio DSP wants to enable a playback stream, the request is
>>>>>> first
>>>>>> received by the ASoC platform sound card. Depending on the selected
>>>>>> route,
>>>>>> ASoC will bring up the individual DAIs in the path. The Q6USB
>>>>>> backend DAI
>>>>>> will send an AFE port start command (with enabling the USB playback
>>>>>> path), and
>>>>>> the audio DSP will handle the request accordingly.
>>>>>>
>>>>>> Part of the AFE USB port start handling will have an exchange of
>>>>>> control
>>>>>> messages using the QMI protocol. The qc_audio_offload driver will
>>>>>> populate the
>>>>>> buffer information:
>>>>>> - Event ring base address
>>>>>> - EP transfer ring base address
>>>>>>
>>>>>> and pass it along to the audio DSP. All endpoint management will now
>>>>>> be handed
>>>>>> over to the DSP, and the main processor is not involved in transfers.
>>>>>>
>>>>>> Overall, implementing this feature will still expose separate sound
>>>>>> card and PCM
>>>>>> devices for both the platorm card and USB audio device:
>>>>>> 0 [SM8250MTPWCD938]: sm8250 - SM8250-MTP-WCD9380-WSA8810-VA-D
>>>>>> SM8250-MTP-WCD9380-WSA8810-VA-DMIC
>>>>>> 1 [Audio ]: USB-Audio - USB Audio
>>>>>> Generic USB Audio at usb-xhci-hcd.1.auto-1.4,
>>>>>> high speed
>>>>>>
>>>>>> This is to ensure that userspace ALSA entities can decide which route
>>>>>> to take
>>>>>> when executing the audio playback. In the above, if card#1 is
>>>>>> selected, then
>>>>>> USB audio data will take the legacy path over the USB PCM drivers,
>>>>>> etc...
>>>>>
>>>>> I already voiced my concerns about exposing two cards, each with their
>>>>> own set of volume controls with the same device. It would be much
>>>>> better
>>>>> to have an additional offloaded PCM device for card0...
>>>>>
>>>>> But if the consensus is to have two cards, it's still not clear how the
>>>>> routing would be selected. In the case where there are two USB audio
>>>>> devices attached, the offloaded path would only support one of the two.
>>>>> How would userspace know which of the two is selected?
>>>>>
>>>>
>>>> With patch#24:
>>>> https://lore.kernel.org/linux-usb/20230308235751.495-25-quic_wcheng@quicinc.com/T/#u
>>>>
>>>> Now, userspace can at least choose which device it wants to offload.
>>>> Part of doing that would mean userspace knows what USB SND card devices
>>>> are available, so it is aware of which devices are shared (between the
>>>> offload and USB SND path)
>>>>
>>>>> And how would userspace know the difference anyways between two
>>>>> physical
>>>>> devices attached to the platform with no offload, and one physical
>>>>> device with one additional offload path? The names you selected
>>>>> can't be
>>>>> used to identify that card1 is the optimized version of card0.
>>>>>
>>>>
>>>> Is userspace currently able to differentiate between cards that are
>>>> created by USB SND versus ASoC? How complex can the userspace card
>>>> discovery be? Can it query kcontrols at this point in time? If so,
>>>> maybe we can change the names of the newly added ones to reflect that it
>>>> is an offload device?
>>>>
>>>> SND kcontrol names are currently:
>>>> Q6USB offload status
>>>> Q6USB offload SND device select
>>>
>>> I must admit I've never seen kcontrols being used to identify what the
>>> card is, and in this case it's a pretend-card that's just an improved
>>> version of another. It might be easier to use something else, such as
>>> the component strings.
>>
>> Its not exactly a pretend card, right? This is part of the overall
>> platform sound card we have in the system. At the moment, I'm only
>> testing by adding the USB audio routing, but there can be several ASoC
>> links defined in the overall platform card.
>
> Sorry, I misunderstood the proposal. I thought there would be one card
> for "generic USB Audio", and another one for "DSP-offloaded USB Audio".
> I assumed, probably mistakenly, that all local audio endpoints
> (speaker,mics) would be exposed as a separate card.
>
Ah got it. No, that isn't the case here.
> It looks like it's more "generic USB Audio" and "DSP Audio", with the
> USB offload being exposed as a PCM device of the latter.
>
> Did I get this right? In this case, presumably there can be some sort of
Yep that's correct!
> UCM file for the "DSP Audio card" that contains the configuration or
> knows which kcontrols to look for. But my point about detection hold.
> You could perfectly well have a 'Jack control' that tells userspace when
> a device is connected. That way there's no guess work, it's similar to
> HDMI for Intel: the device is exposed but only valid when the jack
> control is set.
>
Hmm, ok. Let me see if I can switch up some things. Maybe replace the
current snd_soc_dapm_enable_pin() calls in the q6usb connection_cb and
replace that with a snd jack report. (the snd jack implementation
already takes care of updating the pin if needed)
Thanks
Wesley Cheng
>> The Q6AFE CPU DAI has multiple audio AFE "ports" they can handle. USB
>> is only one of those.
>>
>>>>
>>>>> Before we review low-level kernel plumbing, it would be good to give a
>>>>> better overview of how userspace applications are supposed to interact
>>>>> with the cards and identify the offloaded path. Testing with
>>>>> tinyplay/tinymix is fine, but that's a developer-level or CI unit test.
>>>>> we've got to see the broader picture of how a sound server would use
>>>>> this USB offload capability.
>>>>
>>>> Sure, I think that is fine. I was hoping that at least adding some of
>>>> the new kcontrols would help userspace make use of this path in general,
>>>> but we can add more information if required.
>>>
>>> Can I ask if this solution has been used with a complete userspace stack
>>> already? I could see how this might be used with a relatively fixed
>>
>> Its been used only with the Android HAL.
>
> ok, that aligns with what I was thinking.
>
>>
>>> Android HAL, where the platform and routing are relatively controlled. I
>>> don't see how a more generic audio server would deal with the discovery
>>> and routing.
>>>
>>
>> This is why your input is helpful, since it provides another use case
>> that wasn't considered. I think in our previous discussions the tagging
>> possibility was a good idea, and was hoping that it could help. Could
>> tag all USB SND cards to the platform sound card as well, and if the
>> power saving path is chosen, it would issue the playback on the platform
>> sound card. (if not in use)
>>
>> In this case, the offload path wouldn't be the default routing, and only
>> enabled for power optimized path.
>>
>> Thanks
>> Wesley Cheng
next prev parent reply other threads:[~2023-03-14 1:50 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-08 23:57 [PATCH v3 00/28] Introduce QC USB SND audio offloading support Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 01/28] xhci: Add support to allocate several interrupters Wesley Cheng
2023-03-09 10:34 ` Oliver Neukum
2023-03-09 10:51 ` Takashi Iwai
2023-03-10 15:07 ` Mathias Nyman
2023-03-13 20:08 ` Wesley Cheng
2023-04-25 1:17 ` Wesley Cheng
2023-03-13 20:32 ` Wesley Cheng
2023-06-23 22:37 ` Wesley Cheng
2023-06-26 13:55 ` Mathias Nyman
2023-06-26 15:05 ` Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 02/28] usb: xhci: Add XHCI APIs to support USB offloading Wesley Cheng
2023-03-09 6:38 ` Greg KH
2023-03-09 19:51 ` Wesley Cheng
2023-03-10 12:17 ` Claudiu.Beznea
2023-03-08 23:57 ` [PATCH v3 03/28] usb: host: xhci-mem: Cleanup pending secondary event ring events Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 04/28] ASoC: Add SOC USB APIs for adding an USB backend Wesley Cheng
2023-03-09 6:41 ` Greg KH
2023-03-08 23:57 ` [PATCH v3 05/28] ASoC: dt-bindings: qcom,q6dsp-lpass-ports: Add USB_RX port Wesley Cheng
2023-03-09 9:00 ` Srinivas Kandagatla
2023-03-08 23:57 ` [PATCH v3 06/28] ASoC: qcom: qdsp6: Introduce USB AFE port to q6dsp Wesley Cheng
2023-03-09 9:01 ` Srinivas Kandagatla
2023-03-08 23:57 ` [PATCH v3 07/28] ASoC: qdsp6: q6afe: Increase APR timeout Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 08/28] ASoC: qcom: Add USB backend ASoC driver for Q6 Wesley Cheng
2023-03-09 9:01 ` Srinivas Kandagatla
2023-03-09 19:38 ` Wesley Cheng
2023-03-10 7:21 ` Srinivas Kandagatla
2023-03-25 1:15 ` Wesley Cheng
2023-03-10 12:22 ` Claudiu.Beznea
2023-03-08 23:57 ` [PATCH v3 09/28] sound: usb: card: Introduce USB SND platform op callbacks Wesley Cheng
2023-03-09 6:44 ` Greg KH
2023-03-09 14:10 ` Takashi Iwai
2023-03-09 11:16 ` Oliver Neukum
2023-03-08 23:57 ` [PATCH v3 10/28] sound: usb: Export USB SND APIs for modules Wesley Cheng
2023-03-09 6:29 ` Greg KH
2023-03-08 23:57 ` [PATCH v3 11/28] dt-bindings: usb: dwc3: Add snps,num-hc-interrupters definition Wesley Cheng
2023-03-10 8:50 ` Krzysztof Kozlowski
2023-03-11 13:40 ` Rob Herring
2023-08-29 2:05 ` Wesley Cheng
2023-08-29 6:33 ` Krzysztof Kozlowski
2023-08-29 7:19 ` Wesley Cheng
2023-08-29 7:42 ` Krzysztof Kozlowski
2023-08-29 7:50 ` Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 12/28] usb: dwc3: Add DT parameter to specify maximum number of interrupters Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 13/28] usb: host: xhci-plat: Set XHCI max interrupters if property is present Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 14/28] sound: usb: pcm: Export fixed rate check USB SND API Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 15/28] sound: usb: Introduce QC USB SND offloading support Wesley Cheng
2023-03-09 8:29 ` Takashi Sakamoto
2023-03-09 17:54 ` Pierre-Louis Bossart
2023-03-08 23:57 ` [PATCH v3 16/28] sound: usb: card: Check for support for requested audio format Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 17/28] sound: soc: soc-usb: Add PCM format check API for USB backend Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 18/28] sound: soc: qcom: qusb6: Ensure PCM format is supported by USB audio device Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 19/28] sound: usb: Prevent starting of audio stream if in use Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 20/28] ASoC: dt-bindings: Add Q6USB backend bindings Wesley Cheng
2023-03-10 8:54 ` Krzysztof Kozlowski
2023-06-23 0:15 ` Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 21/28] ASoC: dt-bindings: Update example for enabling USB offload on SM8250 Wesley Cheng
2023-03-10 8:56 ` Krzysztof Kozlowski
2023-06-23 0:51 ` Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 22/28] ASoC: qcom: qdsp6: q6afe: Split USB AFE dev_token param into separate API Wesley Cheng
2023-03-09 9:01 ` Srinivas Kandagatla
2023-03-09 19:39 ` Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 23/28] sound: Pass USB SND card and PCM information to SOC USB Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 24/28] sound: soc: qdsp6: Add SND kcontrol to select offload device Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 25/28] sound: soc: qdsp6: Add SND kcontrol for fetching offload status Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 26/28] sound: usb: qc_audio_offload: Use card and PCM index from QMI request Wesley Cheng
2023-03-08 23:57 ` [PATCH v3 27/28] sound: usb: card: Allow for rediscovery of connected USB SND devices Wesley Cheng
2023-03-09 11:32 ` Oliver Neukum
2023-03-08 23:57 ` [PATCH v3 28/28] sound: soc: soc-usb: Rediscover USB SND devices on USB port add Wesley Cheng
2023-03-09 6:46 ` [PATCH v3 00/28] Introduce QC USB SND audio offloading support Greg KH
2023-03-09 17:13 ` Pierre-Louis Bossart
2023-03-09 21:10 ` Wesley Cheng
2023-03-10 0:37 ` Pierre-Louis Bossart
2023-03-13 23:43 ` Wesley Cheng
2023-03-14 0:42 ` Pierre-Louis Bossart
2023-03-14 1:42 ` Wesley Cheng [this message]
2023-03-14 2:22 ` Pierre-Louis Bossart
2023-03-15 0:08 ` Wesley Cheng
2023-03-15 14:30 ` Pierre-Louis Bossart
2023-03-15 16:29 ` Mark Brown
2023-03-15 19:42 ` 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=0810f951-f4a6-a51d-97e3-43691b05f702@quicinc.com \
--to=quic_wcheng@quicinc.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=pierre-louis.bossart@linux.intel.com \
--cc=quic_jackp@quicinc.com \
--cc=quic_plai@quicinc.com \
--cc=robh+dt@kernel.org \
--cc=srinivas.kandagatla@linaro.org \
--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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).