From: chihhao chen <chihhao.chen@mediatek.com>
To: Geraldo Nascimento <geraldogabriel@gmail.com>,
Takashi Iwai <tiwai@suse.de>
Cc: <alsa-devel@alsa-project.org>, <wsd_upstream@mediatek.com>,
<damien@zamaudio.com>, <tiwai@suse.com>,
<linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>, <matthias.bgg@gmail.com>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ALSA: usb-audio: fix incorrect clock source setting
Date: Mon, 26 Jul 2021 16:42:14 +0800 [thread overview]
Message-ID: <2db5d44b88ace1c25af4a45b3469a425fe1d81a5.camel@mediatek.com> (raw)
In-Reply-To: <CAEsQvcumEDOKgUB6h2-im5QabhPfaSaU63RF8pegPt5ZCPx+Pw@mail.gmail.com>
Hello,
Attach USB descriptor of clock source and selectior for this earphone.
AC Clock Source Descriptor:
------------------------------
Value Valuename
0x08 bLength
0x24 bDescriptorType
0x0A bDescriptorSubtype
0x09 bClockID
0x03 bmAttributes
0x07 bmControls
0x00 bAssocTerminal
0x00 iClockSource
Hex dump:
0x08 0x24 0x0A 0x09 0x03 0x07 0x00 0x00
AC Clock Selector Descriptor:
------------------------------
Value Valuename
0x09 bLength
0x24 bDescriptorType
0x0B bDescriptorSubtype
0x0B bClockID
0x02 bNrInPins
0x09 baCSourceID(1)
0x0A baCSourceID(2)
0x03 bmControls
0x00 iClockSelector
Hex dump:
0x09 0x24 0x0B 0x0B 0x02 0x09 0x0A 0x03 0x00
AC Clock Source Descriptor:
------------------------------
Value Valuename
0x08 bLength
0x24 bDescriptorType
0x0A bDescriptorSubtype
0x0A bClockID
0x03 bmAttributes
0x07 bmControls
0x00 bAssocTerminal
0x00 iClockSource
Hex dump:
0x08 0x24 0x0A 0x0A 0x03 0x07 0x00 0x00
AC Clock Selector Descriptor:
------------------------------
Value Valuename
0x09 bLength
0x24 bDescriptorType
0x0B bDescriptorSubtype
0x0C bClockID
0x02 bNrInPins
0x09 baCSourceID(1)
0x0A baCSourceID(2)
0x03 bmControls
0x00 iClockSelector
Hex dump:
0x09 0x24 0x0B 0x0C 0x02 0x09 0x0A 0x03 0x00
Thanks
Chihhao
On Mon, 2021-07-26 at 02:16 +0000, Geraldo Nascimento wrote:
> On Sun, Jul 25, 2021 at 7:44 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sat, 24 Jul 2021 17:04:13 +0200,
> > Geraldo Nascimento wrote:
> > >
> > > On Sat, Jul 24, 2021 at 8:05 AM Takashi Iwai <tiwai@suse.de>
> > > wrote:
> > > >
> > > > This looks like a regression introduced by the recent commit
> > > > d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
> > > > selector"), which is a fix for certain devices. Too bad that
> > > > the
> > > > behavior really depends on the device...
> > >
> > > Dr. Iwai, perhaps we could restrict the generalized fix for the
> > > Behringer UFX1604 / UFX1204 with some simple logic to devices
> > > that
> > > only have *one* clock source.
> > >
> > > In that case the clock selector must be set to the only clock
> > > source.
> > >
> > > This way we keep the generalization without breaking devices with
> > > more
> > > than one clock source.
> > >
> > > Just an idea.
> >
> > I don't think it's easy to generalize. All those bugs are more or
> > less BIOS bugs, and a logic doesn't apply always, just because it's
> > a
> > bug :) For example, setting the clock selector itself should be a
> > valid operation from the specification POV, while this leads to
> > breakage on some devices. So, even if we add a more generic
> > workaround, we need to see which side effect is more commonly seen
> > at
> > first.
> >
> >
> > Takashi
>
> Hello,
>
> Like I said in one of the other emails in this thread, it's hard to
> pinpoint a cause for the breakage of Samsung USBC Headset (AKG) with
> VID/PID (0x04e8/0xa051) without the lsusb -v of the device in
> question.
>
> But from the description Chihhao Chen gave in the original message,
> I'm *guessing* the Clock Source for the Samsung USB Headset (AKG)
> runs
> at 48000hz and that we'd see a 2x Clock Multiplier in the lsusb -v
>
> This is all a wild guess, without the lsusb -v it's impossible to be
> sure, but if I'm right then the valid setting for the Microphone's
> Clock Selector is the Clock Multiplier, not the Clock Source, which,
> remember, runs at half the clock, hence why Chihhao Chen sees half
> the
> data rate for USB IN.
>
> Unfortunately our kernel code presently *does* always set the Clock
> Selector to the Clock Source, which is a bad assumption to make in my
> humble opinion.
>
> The only valid case for setting the Clock Selector to the Clock
> Source
> is when there's precisely one Clock Selector, precisely one Clock
> Source and no Clock Multipliers.
>
> In that special case we may be able to touch the setting of the only
> Clock Selector to match the only Clock Source.
>
> And, frankly, the only reason we're forced to do that explicitly is
> because some Behringer gear (Archwave AG DACs) gets confused and
> seems
> to somehow keep the old rate on the Clock Selector upon sample rate
> change.
>
> Thank you,
> Geraldo Nascimento
WARNING: multiple messages have this Message-ID (diff)
From: chihhao chen <chihhao.chen@mediatek.com>
To: Geraldo Nascimento <geraldogabriel@gmail.com>,
Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, wsd_upstream@mediatek.com,
damien@zamaudio.com, linux-kernel@vger.kernel.org,
tiwai@suse.com, linux-mediatek@lists.infradead.org,
matthias.bgg@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ALSA: usb-audio: fix incorrect clock source setting
Date: Mon, 26 Jul 2021 16:42:14 +0800 [thread overview]
Message-ID: <2db5d44b88ace1c25af4a45b3469a425fe1d81a5.camel@mediatek.com> (raw)
In-Reply-To: <CAEsQvcumEDOKgUB6h2-im5QabhPfaSaU63RF8pegPt5ZCPx+Pw@mail.gmail.com>
Hello,
Attach USB descriptor of clock source and selectior for this earphone.
AC Clock Source Descriptor:
------------------------------
Value Valuename
0x08 bLength
0x24 bDescriptorType
0x0A bDescriptorSubtype
0x09 bClockID
0x03 bmAttributes
0x07 bmControls
0x00 bAssocTerminal
0x00 iClockSource
Hex dump:
0x08 0x24 0x0A 0x09 0x03 0x07 0x00 0x00
AC Clock Selector Descriptor:
------------------------------
Value Valuename
0x09 bLength
0x24 bDescriptorType
0x0B bDescriptorSubtype
0x0B bClockID
0x02 bNrInPins
0x09 baCSourceID(1)
0x0A baCSourceID(2)
0x03 bmControls
0x00 iClockSelector
Hex dump:
0x09 0x24 0x0B 0x0B 0x02 0x09 0x0A 0x03 0x00
AC Clock Source Descriptor:
------------------------------
Value Valuename
0x08 bLength
0x24 bDescriptorType
0x0A bDescriptorSubtype
0x0A bClockID
0x03 bmAttributes
0x07 bmControls
0x00 bAssocTerminal
0x00 iClockSource
Hex dump:
0x08 0x24 0x0A 0x0A 0x03 0x07 0x00 0x00
AC Clock Selector Descriptor:
------------------------------
Value Valuename
0x09 bLength
0x24 bDescriptorType
0x0B bDescriptorSubtype
0x0C bClockID
0x02 bNrInPins
0x09 baCSourceID(1)
0x0A baCSourceID(2)
0x03 bmControls
0x00 iClockSelector
Hex dump:
0x09 0x24 0x0B 0x0C 0x02 0x09 0x0A 0x03 0x00
Thanks
Chihhao
On Mon, 2021-07-26 at 02:16 +0000, Geraldo Nascimento wrote:
> On Sun, Jul 25, 2021 at 7:44 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sat, 24 Jul 2021 17:04:13 +0200,
> > Geraldo Nascimento wrote:
> > >
> > > On Sat, Jul 24, 2021 at 8:05 AM Takashi Iwai <tiwai@suse.de>
> > > wrote:
> > > >
> > > > This looks like a regression introduced by the recent commit
> > > > d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
> > > > selector"), which is a fix for certain devices. Too bad that
> > > > the
> > > > behavior really depends on the device...
> > >
> > > Dr. Iwai, perhaps we could restrict the generalized fix for the
> > > Behringer UFX1604 / UFX1204 with some simple logic to devices
> > > that
> > > only have *one* clock source.
> > >
> > > In that case the clock selector must be set to the only clock
> > > source.
> > >
> > > This way we keep the generalization without breaking devices with
> > > more
> > > than one clock source.
> > >
> > > Just an idea.
> >
> > I don't think it's easy to generalize. All those bugs are more or
> > less BIOS bugs, and a logic doesn't apply always, just because it's
> > a
> > bug :) For example, setting the clock selector itself should be a
> > valid operation from the specification POV, while this leads to
> > breakage on some devices. So, even if we add a more generic
> > workaround, we need to see which side effect is more commonly seen
> > at
> > first.
> >
> >
> > Takashi
>
> Hello,
>
> Like I said in one of the other emails in this thread, it's hard to
> pinpoint a cause for the breakage of Samsung USBC Headset (AKG) with
> VID/PID (0x04e8/0xa051) without the lsusb -v of the device in
> question.
>
> But from the description Chihhao Chen gave in the original message,
> I'm *guessing* the Clock Source for the Samsung USB Headset (AKG)
> runs
> at 48000hz and that we'd see a 2x Clock Multiplier in the lsusb -v
>
> This is all a wild guess, without the lsusb -v it's impossible to be
> sure, but if I'm right then the valid setting for the Microphone's
> Clock Selector is the Clock Multiplier, not the Clock Source, which,
> remember, runs at half the clock, hence why Chihhao Chen sees half
> the
> data rate for USB IN.
>
> Unfortunately our kernel code presently *does* always set the Clock
> Selector to the Clock Source, which is a bad assumption to make in my
> humble opinion.
>
> The only valid case for setting the Clock Selector to the Clock
> Source
> is when there's precisely one Clock Selector, precisely one Clock
> Source and no Clock Multipliers.
>
> In that special case we may be able to touch the setting of the only
> Clock Selector to match the only Clock Source.
>
> And, frankly, the only reason we're forced to do that explicitly is
> because some Behringer gear (Archwave AG DACs) gets confused and
> seems
> to somehow keep the old rate on the Clock Selector upon sample rate
> change.
>
> Thank you,
> Geraldo Nascimento
WARNING: multiple messages have this Message-ID (diff)
From: chihhao chen <chihhao.chen@mediatek.com>
To: Geraldo Nascimento <geraldogabriel@gmail.com>,
Takashi Iwai <tiwai@suse.de>
Cc: <alsa-devel@alsa-project.org>, <wsd_upstream@mediatek.com>,
<damien@zamaudio.com>, <tiwai@suse.com>,
<linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>, <matthias.bgg@gmail.com>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ALSA: usb-audio: fix incorrect clock source setting
Date: Mon, 26 Jul 2021 16:42:14 +0800 [thread overview]
Message-ID: <2db5d44b88ace1c25af4a45b3469a425fe1d81a5.camel@mediatek.com> (raw)
In-Reply-To: <CAEsQvcumEDOKgUB6h2-im5QabhPfaSaU63RF8pegPt5ZCPx+Pw@mail.gmail.com>
Hello,
Attach USB descriptor of clock source and selectior for this earphone.
AC Clock Source Descriptor:
------------------------------
Value Valuename
0x08 bLength
0x24 bDescriptorType
0x0A bDescriptorSubtype
0x09 bClockID
0x03 bmAttributes
0x07 bmControls
0x00 bAssocTerminal
0x00 iClockSource
Hex dump:
0x08 0x24 0x0A 0x09 0x03 0x07 0x00 0x00
AC Clock Selector Descriptor:
------------------------------
Value Valuename
0x09 bLength
0x24 bDescriptorType
0x0B bDescriptorSubtype
0x0B bClockID
0x02 bNrInPins
0x09 baCSourceID(1)
0x0A baCSourceID(2)
0x03 bmControls
0x00 iClockSelector
Hex dump:
0x09 0x24 0x0B 0x0B 0x02 0x09 0x0A 0x03 0x00
AC Clock Source Descriptor:
------------------------------
Value Valuename
0x08 bLength
0x24 bDescriptorType
0x0A bDescriptorSubtype
0x0A bClockID
0x03 bmAttributes
0x07 bmControls
0x00 bAssocTerminal
0x00 iClockSource
Hex dump:
0x08 0x24 0x0A 0x0A 0x03 0x07 0x00 0x00
AC Clock Selector Descriptor:
------------------------------
Value Valuename
0x09 bLength
0x24 bDescriptorType
0x0B bDescriptorSubtype
0x0C bClockID
0x02 bNrInPins
0x09 baCSourceID(1)
0x0A baCSourceID(2)
0x03 bmControls
0x00 iClockSelector
Hex dump:
0x09 0x24 0x0B 0x0C 0x02 0x09 0x0A 0x03 0x00
Thanks
Chihhao
On Mon, 2021-07-26 at 02:16 +0000, Geraldo Nascimento wrote:
> On Sun, Jul 25, 2021 at 7:44 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sat, 24 Jul 2021 17:04:13 +0200,
> > Geraldo Nascimento wrote:
> > >
> > > On Sat, Jul 24, 2021 at 8:05 AM Takashi Iwai <tiwai@suse.de>
> > > wrote:
> > > >
> > > > This looks like a regression introduced by the recent commit
> > > > d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
> > > > selector"), which is a fix for certain devices. Too bad that
> > > > the
> > > > behavior really depends on the device...
> > >
> > > Dr. Iwai, perhaps we could restrict the generalized fix for the
> > > Behringer UFX1604 / UFX1204 with some simple logic to devices
> > > that
> > > only have *one* clock source.
> > >
> > > In that case the clock selector must be set to the only clock
> > > source.
> > >
> > > This way we keep the generalization without breaking devices with
> > > more
> > > than one clock source.
> > >
> > > Just an idea.
> >
> > I don't think it's easy to generalize. All those bugs are more or
> > less BIOS bugs, and a logic doesn't apply always, just because it's
> > a
> > bug :) For example, setting the clock selector itself should be a
> > valid operation from the specification POV, while this leads to
> > breakage on some devices. So, even if we add a more generic
> > workaround, we need to see which side effect is more commonly seen
> > at
> > first.
> >
> >
> > Takashi
>
> Hello,
>
> Like I said in one of the other emails in this thread, it's hard to
> pinpoint a cause for the breakage of Samsung USBC Headset (AKG) with
> VID/PID (0x04e8/0xa051) without the lsusb -v of the device in
> question.
>
> But from the description Chihhao Chen gave in the original message,
> I'm *guessing* the Clock Source for the Samsung USB Headset (AKG)
> runs
> at 48000hz and that we'd see a 2x Clock Multiplier in the lsusb -v
>
> This is all a wild guess, without the lsusb -v it's impossible to be
> sure, but if I'm right then the valid setting for the Microphone's
> Clock Selector is the Clock Multiplier, not the Clock Source, which,
> remember, runs at half the clock, hence why Chihhao Chen sees half
> the
> data rate for USB IN.
>
> Unfortunately our kernel code presently *does* always set the Clock
> Selector to the Clock Source, which is a bad assumption to make in my
> humble opinion.
>
> The only valid case for setting the Clock Selector to the Clock
> Source
> is when there's precisely one Clock Selector, precisely one Clock
> Source and no Clock Multipliers.
>
> In that special case we may be able to touch the setting of the only
> Clock Selector to match the only Clock Source.
>
> And, frankly, the only reason we're forced to do that explicitly is
> because some Behringer gear (Archwave AG DACs) gets confused and
> seems
> to somehow keep the old rate on the Clock Selector upon sample rate
> change.
>
> Thank you,
> Geraldo Nascimento
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: chihhao chen <chihhao.chen@mediatek.com>
To: Geraldo Nascimento <geraldogabriel@gmail.com>,
Takashi Iwai <tiwai@suse.de>
Cc: <alsa-devel@alsa-project.org>, <wsd_upstream@mediatek.com>,
<damien@zamaudio.com>, <tiwai@suse.com>,
<linux-kernel@vger.kernel.org>,
<linux-mediatek@lists.infradead.org>, <matthias.bgg@gmail.com>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ALSA: usb-audio: fix incorrect clock source setting
Date: Mon, 26 Jul 2021 16:42:14 +0800 [thread overview]
Message-ID: <2db5d44b88ace1c25af4a45b3469a425fe1d81a5.camel@mediatek.com> (raw)
In-Reply-To: <CAEsQvcumEDOKgUB6h2-im5QabhPfaSaU63RF8pegPt5ZCPx+Pw@mail.gmail.com>
Hello,
Attach USB descriptor of clock source and selectior for this earphone.
AC Clock Source Descriptor:
------------------------------
Value Valuename
0x08 bLength
0x24 bDescriptorType
0x0A bDescriptorSubtype
0x09 bClockID
0x03 bmAttributes
0x07 bmControls
0x00 bAssocTerminal
0x00 iClockSource
Hex dump:
0x08 0x24 0x0A 0x09 0x03 0x07 0x00 0x00
AC Clock Selector Descriptor:
------------------------------
Value Valuename
0x09 bLength
0x24 bDescriptorType
0x0B bDescriptorSubtype
0x0B bClockID
0x02 bNrInPins
0x09 baCSourceID(1)
0x0A baCSourceID(2)
0x03 bmControls
0x00 iClockSelector
Hex dump:
0x09 0x24 0x0B 0x0B 0x02 0x09 0x0A 0x03 0x00
AC Clock Source Descriptor:
------------------------------
Value Valuename
0x08 bLength
0x24 bDescriptorType
0x0A bDescriptorSubtype
0x0A bClockID
0x03 bmAttributes
0x07 bmControls
0x00 bAssocTerminal
0x00 iClockSource
Hex dump:
0x08 0x24 0x0A 0x0A 0x03 0x07 0x00 0x00
AC Clock Selector Descriptor:
------------------------------
Value Valuename
0x09 bLength
0x24 bDescriptorType
0x0B bDescriptorSubtype
0x0C bClockID
0x02 bNrInPins
0x09 baCSourceID(1)
0x0A baCSourceID(2)
0x03 bmControls
0x00 iClockSelector
Hex dump:
0x09 0x24 0x0B 0x0C 0x02 0x09 0x0A 0x03 0x00
Thanks
Chihhao
On Mon, 2021-07-26 at 02:16 +0000, Geraldo Nascimento wrote:
> On Sun, Jul 25, 2021 at 7:44 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > On Sat, 24 Jul 2021 17:04:13 +0200,
> > Geraldo Nascimento wrote:
> > >
> > > On Sat, Jul 24, 2021 at 8:05 AM Takashi Iwai <tiwai@suse.de>
> > > wrote:
> > > >
> > > > This looks like a regression introduced by the recent commit
> > > > d2e8f641257d ("ALSA: usb-audio: Explicitly set up the clock
> > > > selector"), which is a fix for certain devices. Too bad that
> > > > the
> > > > behavior really depends on the device...
> > >
> > > Dr. Iwai, perhaps we could restrict the generalized fix for the
> > > Behringer UFX1604 / UFX1204 with some simple logic to devices
> > > that
> > > only have *one* clock source.
> > >
> > > In that case the clock selector must be set to the only clock
> > > source.
> > >
> > > This way we keep the generalization without breaking devices with
> > > more
> > > than one clock source.
> > >
> > > Just an idea.
> >
> > I don't think it's easy to generalize. All those bugs are more or
> > less BIOS bugs, and a logic doesn't apply always, just because it's
> > a
> > bug :) For example, setting the clock selector itself should be a
> > valid operation from the specification POV, while this leads to
> > breakage on some devices. So, even if we add a more generic
> > workaround, we need to see which side effect is more commonly seen
> > at
> > first.
> >
> >
> > Takashi
>
> Hello,
>
> Like I said in one of the other emails in this thread, it's hard to
> pinpoint a cause for the breakage of Samsung USBC Headset (AKG) with
> VID/PID (0x04e8/0xa051) without the lsusb -v of the device in
> question.
>
> But from the description Chihhao Chen gave in the original message,
> I'm *guessing* the Clock Source for the Samsung USB Headset (AKG)
> runs
> at 48000hz and that we'd see a 2x Clock Multiplier in the lsusb -v
>
> This is all a wild guess, without the lsusb -v it's impossible to be
> sure, but if I'm right then the valid setting for the Microphone's
> Clock Selector is the Clock Multiplier, not the Clock Source, which,
> remember, runs at half the clock, hence why Chihhao Chen sees half
> the
> data rate for USB IN.
>
> Unfortunately our kernel code presently *does* always set the Clock
> Selector to the Clock Source, which is a bad assumption to make in my
> humble opinion.
>
> The only valid case for setting the Clock Selector to the Clock
> Source
> is when there's precisely one Clock Selector, precisely one Clock
> Source and no Clock Multipliers.
>
> In that special case we may be able to touch the setting of the only
> Clock Selector to match the only Clock Source.
>
> And, frankly, the only reason we're forced to do that explicitly is
> because some Behringer gear (Archwave AG DACs) gets confused and
> seems
> to somehow keep the old rate on the Clock Selector upon sample rate
> change.
>
> Thank you,
> Geraldo Nascimento
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-26 8:42 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-24 4:23 [PATCH] ALSA: usb-audio: fix incorrect clock source setting chihhao.chen
2021-07-24 4:23 ` chihhao.chen
2021-07-24 4:23 ` chihhao.chen
2021-07-24 4:23 ` chihhao.chen
2021-07-24 8:04 ` Takashi Iwai
2021-07-24 8:04 ` Takashi Iwai
2021-07-24 8:04 ` Takashi Iwai
2021-07-24 8:04 ` Takashi Iwai
2021-07-24 15:04 ` Geraldo Nascimento
2021-07-24 15:04 ` Geraldo Nascimento
2021-07-24 15:04 ` Geraldo Nascimento
2021-07-24 15:04 ` Geraldo Nascimento
2021-07-24 15:20 ` Geraldo Nascimento
2021-07-24 15:20 ` Geraldo Nascimento
2021-07-24 15:20 ` Geraldo Nascimento
2021-07-24 15:20 ` Geraldo Nascimento
2021-07-24 18:42 ` Geraldo Nascimento
2021-07-24 18:42 ` Geraldo Nascimento
2021-07-24 18:42 ` Geraldo Nascimento
2021-07-24 18:42 ` Geraldo Nascimento
2021-07-25 7:44 ` Takashi Iwai
2021-07-25 7:44 ` Takashi Iwai
2021-07-25 7:44 ` Takashi Iwai
2021-07-25 7:44 ` Takashi Iwai
2021-07-26 2:16 ` Geraldo Nascimento
2021-07-26 2:16 ` Geraldo Nascimento
2021-07-26 2:16 ` Geraldo Nascimento
2021-07-26 2:16 ` Geraldo Nascimento
2021-07-26 8:42 ` chihhao chen [this message]
2021-07-26 8:42 ` chihhao chen
2021-07-26 8:42 ` chihhao chen
2021-07-26 8:42 ` chihhao chen
2021-07-26 20:57 ` Geraldo Nascimento
2021-07-26 20:57 ` Geraldo Nascimento
2021-07-26 20:57 ` Geraldo Nascimento
2021-07-26 20:57 ` Geraldo Nascimento
2021-07-27 10:27 ` chihhao.chen
2021-07-27 10:27 ` chihhao.chen
2021-07-27 10:27 ` chihhao.chen
2021-07-27 10:27 ` chihhao.chen
2021-07-27 17:56 ` Geraldo Nascimento
2021-07-27 17:56 ` Geraldo Nascimento
2021-07-27 17:56 ` Geraldo Nascimento
2021-07-27 17:56 ` Geraldo Nascimento
2021-07-28 1:19 ` Geraldo Nascimento
2021-07-28 1:19 ` Geraldo Nascimento
2021-07-28 1:19 ` Geraldo Nascimento
2021-07-28 1:19 ` Geraldo Nascimento
2021-08-05 7:54 ` chihhao.chen
2021-08-05 7:54 ` chihhao.chen
2021-08-05 7:54 ` chihhao.chen
2021-08-05 7:54 ` chihhao.chen
2021-08-05 15:50 ` Geraldo Nascimento
2021-08-05 15:50 ` Geraldo Nascimento
2021-08-05 15:50 ` Geraldo Nascimento
2021-08-05 15:50 ` Geraldo Nascimento
2021-08-05 23:31 ` Geraldo Nascimento
2021-08-05 22:03 ` Geraldo Nascimento
2021-08-05 22:03 ` Geraldo Nascimento
2021-08-05 22:03 ` Geraldo Nascimento
2021-08-05 22:03 ` Geraldo Nascimento
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=2db5d44b88ace1c25af4a45b3469a425fe1d81a5.camel@mediatek.com \
--to=chihhao.chen@mediatek.com \
--cc=alsa-devel@alsa-project.org \
--cc=damien@zamaudio.com \
--cc=geraldogabriel@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=tiwai@suse.com \
--cc=tiwai@suse.de \
--cc=wsd_upstream@mediatek.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 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.