hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Roger Gammans]

[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]

Hi

I'm fighting a problem with my (new) Acer laptop.  (Aspire 9303)

In 2.6.18 the audio worked fine, but now I've upgraded to 2.6.22
it has stopped working. 

I note that there is a acer specific quirk mode in patch_realtek.c
enabled for all acer devices introduced in the timeframe. Disabling
the quirk so that the driver uses it auot mode makes playback work
fine again.

To be clear this pathc seems to work for me:-

--- /usr/src/linux-source-2.6.22/sound/pci/hda/patch_realtek.c 2007-07-09 00:32:17.000000000 +0100
+++ linux-source-2.6.22/sound/pci/hda/patch_realtek.c   2007-08-20 22:21:37.000000000 +0100
@@ -6392,7 +6392,7 @@
        SND_PCI_QUIRK(0x1462, 0x4319, "MSI", ALC883_TARGA_DIG),
        SND_PCI_QUIRK(0x1462, 0x4324, "MSI", ALC883_TARGA_DIG),
        SND_PCI_QUIRK(0x1462, 0xa422, "MSI", ALC883_TARGA_2ch_DIG),
-       SND_PCI_QUIRK(0x1025, 0, "Acer laptop", ALC883_ACER),
+/*     SND_PCI_QUIRK(0x1025, 0, "Acer laptop", ALC883_ACER) , */
        SND_PCI_QUIRK(0x15d9, 0x8780, "Supermicro PDSBA", ALC883_3ST_6ch),
        SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_MEDION),
        SND_PCI_QUIRK(0x1071, 0x8258, "Evesham Voyaeger", ALC883_LAPTOP_EAPD), 


Unfortunately I think it's pretty clear it will break for others.

The lspci reports the following on the appropriate device:-
  00:10.1 0403: 10de:026c (rev a2)
        Subsystem: 1025:0112
        Flags: 66MHz, fast devsel, IRQ 19
        Memory at c0000000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>




TTFN
-- 
Roger. 	                        Home| http://www.sandman.uklinux.net/
Master of Peng Shui.      (Ancient oriental art of Penguin Arranging)
Work|Independent Sys Consultant | http://www.computer-surgery.co.uk/
 New key Fpr: 72AF 0ACC 9A53 E59F B1B6  DC14 1983 A13E 5C3D 3CEB 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Andrew Morton]

> On Wed, 22 Aug 2007 23:29:02 +0100 Roger Gammans <roger@computer-surgery.co.uk> wrote:
> Hi

A distinct regression, a confirmed fix, yet no reply after more than two weeks.

> I'm fighting a problem with my (new) Acer laptop.  (Aspire 9303)
> 
> In 2.6.18 the audio worked fine, but now I've upgraded to 2.6.22
> it has stopped working. 
> 
> I note that there is a acer specific quirk mode in patch_realtek.c
> enabled for all acer devices introduced in the timeframe. Disabling
> the quirk so that the driver uses it auot mode makes playback work
> fine again.
> 
> To be clear this pathc seems to work for me:-
> 
> --- /usr/src/linux-source-2.6.22/sound/pci/hda/patch_realtek.c 2007-07-09 00:32:17.000000000 +0100
> +++ linux-source-2.6.22/sound/pci/hda/patch_realtek.c   2007-08-20 22:21:37.000000000 +0100
> @@ -6392,7 +6392,7 @@
>         SND_PCI_QUIRK(0x1462, 0x4319, "MSI", ALC883_TARGA_DIG),
>         SND_PCI_QUIRK(0x1462, 0x4324, "MSI", ALC883_TARGA_DIG),
>         SND_PCI_QUIRK(0x1462, 0xa422, "MSI", ALC883_TARGA_2ch_DIG),
> -       SND_PCI_QUIRK(0x1025, 0, "Acer laptop", ALC883_ACER),
> +/*     SND_PCI_QUIRK(0x1025, 0, "Acer laptop", ALC883_ACER) , */
>         SND_PCI_QUIRK(0x15d9, 0x8780, "Supermicro PDSBA", ALC883_3ST_6ch),
>         SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_MEDION),
>         SND_PCI_QUIRK(0x1071, 0x8258, "Evesham Voyaeger", ALC883_LAPTOP_EAPD), 
> 
> 
> Unfortunately I think it's pretty clear it will break for others.
> 
> The lspci reports the following on the appropriate device:-
>   00:10.1 0403: 10de:026c (rev a2)
>         Subsystem: 1025:0112
>         Flags: 66MHz, fast devsel, IRQ 19
>         Memory at c0000000 (32-bit, non-prefetchable) [size=16K]
>         Capabilities: <access denied>
> 

Jaroslav, Takashi: can you please comment on this?

Thanks.

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Takashi Iwai]

At Wed, 5 Sep 2007 08:38:44 -0700,
Andrew Morton wrote:
> 
> > On Wed, 22 Aug 2007 23:29:02 +0100 Roger Gammans <roger@computer-surgery.co.uk> wrote:
> > Hi
> 
> A distinct regression, a confirmed fix, yet no reply after more than two weeks.

Sorry, I've overseen this report (as I'm obviously no akpm ;-)


> > I'm fighting a problem with my (new) Acer laptop.  (Aspire 9303)
> > 
> > In 2.6.18 the audio worked fine, but now I've upgraded to 2.6.22
> > it has stopped working. 
> > 
> > I note that there is a acer specific quirk mode in patch_realtek.c
> > enabled for all acer devices introduced in the timeframe. Disabling
> > the quirk so that the driver uses it auot mode makes playback work
> > fine again.
> > 
> > To be clear this pathc seems to work for me:-
> > 
> > --- /usr/src/linux-source-2.6.22/sound/pci/hda/patch_realtek.c 2007-07-09 00:32:17.000000000 +0100
> > +++ linux-source-2.6.22/sound/pci/hda/patch_realtek.c   2007-08-20 22:21:37.000000000 +0100
> > @@ -6392,7 +6392,7 @@
> >         SND_PCI_QUIRK(0x1462, 0x4319, "MSI", ALC883_TARGA_DIG),
> >         SND_PCI_QUIRK(0x1462, 0x4324, "MSI", ALC883_TARGA_DIG),
> >         SND_PCI_QUIRK(0x1462, 0xa422, "MSI", ALC883_TARGA_2ch_DIG),
> > -       SND_PCI_QUIRK(0x1025, 0, "Acer laptop", ALC883_ACER),
> > +/*     SND_PCI_QUIRK(0x1025, 0, "Acer laptop", ALC883_ACER) , */
> >         SND_PCI_QUIRK(0x15d9, 0x8780, "Supermicro PDSBA", ALC883_3ST_6ch),
> >         SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_MEDION),
> >         SND_PCI_QUIRK(0x1071, 0x8258, "Evesham Voyaeger", ALC883_LAPTOP_EAPD), 
> > 
> > 
> > Unfortunately I think it's pretty clear it will break for others.
> > 
> > The lspci reports the following on the appropriate device:-
> >   00:10.1 0403: 10de:026c (rev a2)
> >         Subsystem: 1025:0112
> >         Flags: 66MHz, fast devsel, IRQ 19
> >         Memory at c0000000 (32-bit, non-prefetchable) [size=16K]
> >         Capabilities: <access denied>
> > 
> 
> Jaroslav, Takashi: can you please comment on this?

The patch would definitely break many other machines, so no, it can't
be applied as is.  Note that there is an equivalent workaround by
adding "model=auto" module option.

The support for Acer Aspire was already improved in mm tree.  At
least, we have the support for Aspire 9810 and co.  If it's the
compatible one, the chance is high.

Roger, could you try git-alsa patch in the latest mm together with
model=acer-aspiore option?  If it works, I can easily add your device
ID to the table.


thanks,

Takashi

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Andrew Morton]

> On Wed, 05 Sep 2007 18:05:44 +0200 Takashi Iwai <tiwai@suse.de> wrote:
> Roger, could you try git-alsa patch in the latest mm together with
> model=acer-aspiore option?  If it works, I can easily add your device
> ID to the table.

http://userweb.kernel.org/~akpm/git-alsa.patch is a copy of the alsa git
tree as of two minutes ago.  That applies against current Linus mainline,
but should apply OK on 2.6.23-rc5 as well.  Please test that, thanks.

Takashi, perhaps that is 2.6.23 material?

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Takashi Iwai]

At Wed, 5 Sep 2007 09:16:33 -0700,
Andrew Morton wrote:
> 
> > On Wed, 05 Sep 2007 18:05:44 +0200 Takashi Iwai <tiwai@suse.de> wrote:
> > Roger, could you try git-alsa patch in the latest mm together with
> > model=acer-aspiore option?  If it works, I can easily add your device
> > ID to the table.
> 
> http://userweb.kernel.org/~akpm/git-alsa.patch is a copy of the alsa git
> tree as of two minutes ago.  That applies against current Linus mainline,
> but should apply OK on 2.6.23-rc5 as well.  Please test that, thanks.
> 
> Takashi, perhaps that is 2.6.23 material?

The changes for Acer Aspire is quite big, surely not for 2.6.23.
Let's fix in 2.6.24 in a better way than a temporary hack (that
would work only in a very limited way).


Takashi

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Romano Giannetti]

On Wed, 2007-09-05 at 18:44 +0200, Takashi Iwai wrote:
> At Wed, 5 Sep 2007 09:16:33 -0700,
> Andrew Morton wrote:
> >
> > > On Wed, 05 Sep 2007 18:05:44 +0200 Takashi Iwai <tiwai@suse.de> wrote:
> > > Roger, could you try git-alsa patch in the latest mm together with
> > > model=acer-aspiore option?  If it works, I can easily add your device
> > > ID to the table.
> >
> > http://userweb.kernel.org/~akpm/git-alsa.patch is a copy of the alsa git
> > tree as of two minutes ago.  That applies against current Linus mainline,
> > but should apply OK on 2.6.23-rc5 as well.  Please test that, thanks.
> >
> > Takashi, perhaps that is 2.6.23 material?
>
> The changes for Acer Aspire is quite big, surely not for 2.6.23.
> Let's fix in 2.6.24 in a better way than a temporary hack (that
> would work only in a very limited way).

Just one hand up: I haven't tested the patch pointed to by Andrew, will
do asap, but it seems that contains the changes from

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104

which are needed to have sound at all on my toshiba (although with some
remaining problems). I am not able to say if it's .23 material or not,
nor if it's a regression or not, being this a quite new laptop... but
maybe it's better to have a release with some sound and then fix it
properly after?

Thanks for your hard work,

	Romano




--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Takashi Iwai]

At Thu, 06 Sep 2007 17:09:50 +0200,
Romano Giannetti wrote:
> 
> On Wed, 2007-09-05 at 18:44 +0200, Takashi Iwai wrote:
> > At Wed, 5 Sep 2007 09:16:33 -0700,
> > Andrew Morton wrote:
> > >
> > > > On Wed, 05 Sep 2007 18:05:44 +0200 Takashi Iwai <tiwai@suse.de> wrote:
> > > > Roger, could you try git-alsa patch in the latest mm together with
> > > > model=acer-aspiore option?  If it works, I can easily add your device
> > > > ID to the table.
> > >
> > > http://userweb.kernel.org/~akpm/git-alsa.patch is a copy of the alsa git
> > > tree as of two minutes ago.  That applies against current Linus mainline,
> > > but should apply OK on 2.6.23-rc5 as well.  Please test that, thanks.
> > >
> > > Takashi, perhaps that is 2.6.23 material?
> >
> > The changes for Acer Aspire is quite big, surely not for 2.6.23.
> > Let's fix in 2.6.24 in a better way than a temporary hack (that
> > would work only in a very limited way).
> 
> Just one hand up: I haven't tested the patch pointed to by Andrew, will
> do asap, but it seems that contains the changes from
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104
> 
> which are needed to have sound at all on my toshiba (although with some
> remaining problems).

No, it's a different one.  This Toshiba model is still not supported
well.  The patch in mm tree is basically equivalent with the latest
ALSA HG tree, so if you tested ALSA HG version (or daily snapshot),
it should be same.

I'm still waiting for a patch from pshou for the latest version, but
no reply yet.


Takashi

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Romano Giannetti]

On Thu, 2007-09-06 at 17:25 +0200, Takashi Iwai wrote:
> At Thu, 06 Sep 2007 17:09:50 +0200,
> Romano Giannetti wrote:
> >
> >
> > Just one hand up: I haven't tested the patch pointed to by Andrew, will
> > do asap, but it seems that contains the changes from
> >
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104
> >
> > which are needed to have sound at all on my toshiba (although with some
> > remaining problems).
>
> No, it's a different one.  This Toshiba model is still not supported
> well.  The patch in mm tree is basically equivalent with the latest
> ALSA HG tree, so if you tested ALSA HG version (or daily snapshot),
> it should be same.

Unfortunately you're right. The patch I posted to the alsa bugtrack,
extracted from the pshou files, works for me. The alsa-git patch gives
me a system without sound.

>
> I'm still waiting for a patch from pshou for the latest version, but
> no reply yet.	m here. I can  try to "merge" pshou patch with the
> alsa-git, but I'm not so confident about my understanding of the
> thing...

Thanks again
	Romano


--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Romano Giannetti]

Takashi: good news!

On Thu, 2007-09-06 at 23:48 +0200, Romano Giannetti wrote:
> On Thu, 2007-09-06 at 17:25 +0200, Takashi Iwai wrote:
> > At Thu, 06 Sep 2007 17:09:50 +0200,
> > Romano Giannetti wrote:
> > >
> > >
> > > Just one hand up: I haven't tested the patch pointed to by Andrew, will
> > > do asap, but it seems that contains the changes from
> > >
> > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104
> > >
> > > which are needed to have sound at all on my toshiba (although with some
> > > remaining problems).
> >
> > No, it's a different one.  This Toshiba model is still not supported
> > well.  The patch in mm tree is basically equivalent with the latest
> > ALSA HG tree, so if you tested ALSA HG version (or daily snapshot),
> > it should be same.
>
> Unfortunately you're right. The patch I posted to the alsa bugtrack,
> extracted from the pshou files, works for me. The alsa-git patch gives
> me a system without sound.

I stand corrected: by loading snd-hda-intel with model=toshiba sound
works (output and input) with my toshiba A305. So, I think that the only
patch needed to make it works out of the box on top of current alsa-git
is:

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 3557865..496d119 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = {
 static struct snd_pci_quirk alc268_cfg_tbl[] = {
        SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST),
        SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA),
+       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
        SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA),
        SND_PCI_QUIRK(0x1025, 0x0126, "Acer", ALC268_ACER),
        SND_PCI_QUIRK(0x1025, 0x0130, "Acer Extensa 5210", ALC268_ACER),






--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Takashi Iwai]

At Fri, 07 Sep 2007 10:22:27 +0200,
Romano Giannetti wrote:
> 
> Takashi: good news!
> 
> On Thu, 2007-09-06 at 23:48 +0200, Romano Giannetti wrote:
> > On Thu, 2007-09-06 at 17:25 +0200, Takashi Iwai wrote:
> > > At Thu, 06 Sep 2007 17:09:50 +0200,
> > > Romano Giannetti wrote:
> > > >
> > > >
> > > > Just one hand up: I haven't tested the patch pointed to by Andrew, will
> > > > do asap, but it seems that contains the changes from
> > > >
> > > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104
> > > >
> > > > which are needed to have sound at all on my toshiba (although with some
> > > > remaining problems).
> > >
> > > No, it's a different one.  This Toshiba model is still not supported
> > > well.  The patch in mm tree is basically equivalent with the latest
> > > ALSA HG tree, so if you tested ALSA HG version (or daily snapshot),
> > > it should be same.
> >
> > Unfortunately you're right. The patch I posted to the alsa bugtrack,
> > extracted from the pshou files, works for me. The alsa-git patch gives
> > me a system without sound.
> 
> I stand corrected: by loading snd-hda-intel with model=toshiba sound
> works (output and input) with my toshiba A305. So, I think that the only
> patch needed to make it works out of the box on top of current alsa-git
> is:
> 
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 3557865..496d119 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = {
>  static struct snd_pci_quirk alc268_cfg_tbl[] = {
>         SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST),
>         SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA),
> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
>         SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA),
>         SND_PCI_QUIRK(0x1025, 0x0126, "Acer", ALC268_ACER),
>         SND_PCI_QUIRK(0x1025, 0x0130, "Acer Extensa 5210", ALC268_ACER),

Ah good.  I added it to ALSA HG tree now.
Thanks!


Takashi

easy alsa patches for the stable kernel? (was: Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22)

[Thorsten Leemhuis]

On 07.09.2007 12:21, Takashi Iwai wrote:
> At Fri, 07 Sep 2007 10:22:27 +0200,
> Romano Giannetti wrote:
>> Takashi: good news!
>>
>> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
>> index 3557865..496d119 100644
>> --- a/sound/pci/hda/patch_realtek.c
>> +++ b/sound/pci/hda/patch_realtek.c
>> @@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = {
>>  static struct snd_pci_quirk alc268_cfg_tbl[] = {
>>         SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST),
>>         SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA),
>> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
>>         SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA),
>>         SND_PCI_QUIRK(0x1025, 0x0126, "Acer", ALC268_ACER),
>>         SND_PCI_QUIRK(0x1025, 0x0130, "Acer Extensa 5210", ALC268_ACER),
> 
> Ah good.  I added it to ALSA HG tree now.

Just wondering: should easy-and-obvious and less-risky patches like this
one be send to the stable-kernel-maintainers in parallel to adding them
to the HG-Tree (or shortly afterwards)? It could safe users lots of
trouble if such improvements make it quickly into production-ready
kernel-releases (and from there they might even find their way into some
distribution kernels quickly). Hardware then would "just work".

Sure, before the stable-maintainer will take such patches they needs to
be added to linus git-tree beforehand as well. And sure, patches like
the one above are not fixing a regression (at least in this case if I
read the thread correctly; the old subject thus is misleading afaics),
but it's similar to a new PCI-ID that gets added to a existing driver --
and that's done now in the stable-series afaics (¹).

The alsa-maintainers seem to be in the best position to do this, but it
seems they rarely do it. I for example was hit by a regression (sound
worked in 2.6.20 and broke afterwards; was fixed in 2.6.23-git by the
following patch in case anybody is wondering:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a4eed138add1018846d17e813560b0c7c0ae8e01
), but the alsa-developers did not submit it for stable afaics. Sure, I
could do that myself, but as I said: the alsa-maintainers really have
the best overview over the alsa-patches and should know which patches
are safe to apply for older kernels.

CU
knurd

(¹) -- see for example
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=fd2efeae63567dde934bb54772bb1b991275b04a
or
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=3443d563dc53875b15d919c4bece391f1ffd4776
which made in into
http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.22.3

Re: easy alsa patches for the stable kernel? (was: Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22)

[Takashi Iwai]

At Fri, 07 Sep 2007 14:04:01 +0200,
Thorsten Leemhuis wrote:
> 
> On 07.09.2007 12:21, Takashi Iwai wrote:
> > At Fri, 07 Sep 2007 10:22:27 +0200,
> > Romano Giannetti wrote:
> >> Takashi: good news!
> >>
> >> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> >> index 3557865..496d119 100644
> >> --- a/sound/pci/hda/patch_realtek.c
> >> +++ b/sound/pci/hda/patch_realtek.c
> >> @@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = {
> >>  static struct snd_pci_quirk alc268_cfg_tbl[] = {
> >>         SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST),
> >>         SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA),
> >> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
> >>         SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA),
> >>         SND_PCI_QUIRK(0x1025, 0x0126, "Acer", ALC268_ACER),
> >>         SND_PCI_QUIRK(0x1025, 0x0130, "Acer Extensa 5210", ALC268_ACER),
> > 
> > Ah good.  I added it to ALSA HG tree now.
> 
> Just wondering: should easy-and-obvious and less-risky patches like this
> one be send to the stable-kernel-maintainers in parallel to adding them
> to the HG-Tree (or shortly afterwards)? It could safe users lots of
> trouble if such improvements make it quickly into production-ready
> kernel-releases (and from there they might even find their way into some
> distribution kernels quickly). Hardware then would "just work".

Well, this patch is defenitely not for 2.6.23 or stable kernel.
It's for 2.6.24.


> Sure, before the stable-maintainer will take such patches they needs to
> be added to linus git-tree beforehand as well. And sure, patches like
> the one above are not fixing a regression (at least in this case if I
> read the thread correctly; the old subject thus is misleading afaics),
> but it's similar to a new PCI-ID that gets added to a existing driver --
> and that's done now in the stable-series afaics (¹).
> 
> The alsa-maintainers seem to be in the best position to do this, but it
> seems they rarely do it. I for example was hit by a regression (sound
> worked in 2.6.20 and broke afterwards; was fixed in 2.6.23-git by the
> following patch in case anybody is wondering:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a4eed138add1018846d17e813560b0c7c0ae8e01
> ), but the alsa-developers did not submit it for stable afaics. Sure, I
> could do that myself, but as I said: the alsa-maintainers really have
> the best overview over the alsa-patches and should know which patches
> are safe to apply for older kernels.

I occasionally do but sometimes forget.  The problem is often that I
want first the merge to Linus tree, and then I forget to submit to
stable tree when the merge takes long time in the end.  (Ther merge of
alsa.git is too spotty, and that's another big problem for me.  In
short, I do NOT maintain alsa.git tree at all...)

Another problem I see is that we have little chance for testing the
target patches with stable kernels.  Even it looks OK and works for
the later kernels, it often doesn't work or break magically with the
older kernels.  Usually, I have no affected hardware, and bug
reporters test only with the recent version (partly because developers
ask first to try the latest version -- if it works, why to downgrade
again?) 


thanks,

Takashi

Re: easy alsa patches for the stable kernel?

[Thorsten Leemhuis]

On 07.09.2007 14:58, Takashi Iwai wrote:
> At Fri, 07 Sep 2007 14:04:01 +0200,
> Thorsten Leemhuis wrote:
>> On 07.09.2007 12:21, Takashi Iwai wrote:
>>> At Fri, 07 Sep 2007 10:22:27 +0200,
>>> Romano Giannetti wrote:
>>>> Takashi: good news!
>>>>
>>>> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
>>>> index 3557865..496d119 100644
>>>> --- a/sound/pci/hda/patch_realtek.c
>>>> +++ b/sound/pci/hda/patch_realtek.c
>>>> @@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = {
>>>>  static struct snd_pci_quirk alc268_cfg_tbl[] = {
>>>>         SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST),
>>>>         SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA),
>>>> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
>>>>         SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA),
>>>>         SND_PCI_QUIRK(0x1025, 0x0126, "Acer", ALC268_ACER),
>>>>         SND_PCI_QUIRK(0x1025, 0x0130, "Acer Extensa 5210", ALC268_ACER),
>>> Ah good.  I added it to ALSA HG tree now.
>> Just wondering: should easy-and-obvious and less-risky patches like this
>> one be send to the stable-kernel-maintainers in parallel to adding them
>> to the HG-Tree (or shortly afterwards)? It could safe users lots of
>> trouble if such improvements make it quickly into production-ready
>> kernel-releases (and from there they might even find their way into some
>> distribution kernels quickly). Hardware then would "just work".
> Well, this patch is defenitely not for 2.6.23 or stable kernel.
> It's for 2.6.24.

Sorry, but why?

It's just this line afaics...
+       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
...which afaics is doing nothing more then "if DMI-Data matches FOO then
apply know workaround BAR". Is that correct or am I missing something
here (another patch that this one depends on that isn't in 2.6.23 yet
maybe?)?

If my above analyze is correct (which IMHO is at least correct for some
of all those alsa-patches that get applied) then I'd say: it's worth
applying them to linus-git tree even after the merge-window, as the risk
that something is wrong is small (¹) and the benefit for users is big
enough to be worth the risk, as users get the fix in their hands 60 - 80
days (round about the time a typical devel cycle takes these days
afaics) earlier that way.

60 - 80 days might sound like not that much to some people, but if we
want to make Linux compatible to todays hardware (and not only
yesterdays) we imho can't wait nearly 1/4 of a year (or longer, as it
takes some time until such a fix hits the distributions, but that's
another part of the problem), as a typical market-lifetime of a modern
notebook is often not much longer then a year in total afaics.

(¹) -- sure, typos or stupid side-effects can happen always -- but
that's not enough a reasons to stand still

>> Sure, before the stable-maintainer will take such patches they needs to
>> be added to linus git-tree beforehand as well. And sure, patches like
>> the one above are not fixing a regression (at least in this case if I
>> read the thread correctly; the old subject thus is misleading afaics),
>> but it's similar to a new PCI-ID that gets added to a existing driver --
>> and that's done now in the stable-series afaics (¹).
>>
>> The alsa-maintainers seem to be in the best position to do this, but it
>> seems they rarely do it. I for example was hit by a regression (sound
>> worked in 2.6.20 and broke afterwards; was fixed in 2.6.23-git by the
>> following patch in case anybody is wondering:
>> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a4eed138add1018846d17e813560b0c7c0ae8e01
>> ), but the alsa-developers did not submit it for stable afaics. Sure, I
>> could do that myself, but as I said: the alsa-maintainers really have
>> the best overview over the alsa-patches and should know which patches
>> are safe to apply for older kernels.
> 
> I occasionally do but sometimes forget. 

Nevertheless let me use to use this moment and say: thx for all your
work Takashi!

> The problem is often that I
> want first the merge to Linus tree, and then I forget to submit to
> stable tree when the merge takes long time in the end.  (Ther merge of
> alsa.git is too spotty, and that's another big problem for me.  In
> short, I do NOT maintain alsa.git tree at all...)

Then I as one of all those long-time-lkml-lurkers without programming
skills dare to say that maybe the alsa-project might need to improve its
workflow? Maybe you guys should maintain two git-trees (or multiple
branches in one tree; sorry, I'm not a git expert and not sure what the
correct terms are)?

E.g. look at how Jeff handles it for libata; he pushes big stuff during
each merge window; after that lots of small updates (new PCI-IDs) and of
course fixes make it to tree quite often (weekly normally afaics,
sometimes more often, sometimes more seldom) until nearly right before
the release of a new Linus-Kernel -- bigger stuff in parallel gets into
another branch, which gets testing in -mm and in parts gets merged
during the next merge-window.

And even better: he pushes small improvements like the PCI-IDs (see
links I gave earlier) to the stable tree as well. That, afaics, happens
in just a few days sometimes; this is how it looks to me from the outside:

- jeff prepares his tree with a patch that for example adds two new
PCI-IDs to a existing driver
- he asks linus to pull it and waits to do that
- some days after linus pulled them jeff pushes the patch to another
git-branch/tree and asks the stable-guys to pull that one, which they do
sooner or later

For alsa it's seems there is only the hg-tree which gets everything
(small and big updates) that has to wait for the next merge-window to
get into the proper kernel (but not into stable). E.g. in the worst case
it might nearly take a half a year until even a small patch gets out to
the users if that patch was made right after a merge window got closed
for a release. That's IMHO way to long.

> Another problem I see is that we have little chance for testing the
> target patches with stable kernels.

The stable maintainers release "rc" kernels before they release the
final ones. And the patch of course should have been applied in
linus-tree. Both things are not a perfect safety net, but I'd say it
should be more then enough as long as we are talking about new PCI-IDs
for existing drivers or "apply workarounds for special machines which we
detect by their DMI data" (lot's of those seems to be needed these days).

>  Even it looks OK and works for
> the later kernels, it often doesn't work or break magically with the
> older kernels.  Usually, I have no affected hardware, and bug
> reporters test only with the recent version (partly because developers
> ask first to try the latest version -- if it works, why to downgrade
> again?) 

Because he bug-reporter is likely only one that invested enough time to
analized the problem and fix it alone or together with you guys. But
there is likely a buch of other people that get hit by the same problem;
some will just say "linux sucks" and switch back to some other OS --
especially if they never have heard of alsa or don't really know what a
kernel really is or does.

CU
knurd

Re: easy alsa patches for the stable kernel?

[Romano Giannetti]

On Fri, 2007-09-07 at 21:42 +0200, Thorsten Leemhuis wrote:
> On 07.09.2007 14:58, Takashi Iwai wrote:
> >>> Ah good.  I added it to ALSA HG tree now.

Thanks. BTW, is anywhere visible the current hg tree? It seems that
http://hg-mirror.alsa-project.org/alsa-kernel/ lags a bit behind...


> It's just this line afaics...
> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
> ...which afaics is doing nothing more then "if DMI-Data matches FOO then
> apply know workaround BAR". Is that correct or am I missing something
> here (another patch that this one depends on that isn't in 2.6.23 yet
> maybe?)?
>

Your second guess is right. That line is a patch with respect to current
mercurial tree, which is quite ahead of the current kernel alsa code.
Although I'd like to know from where Andrew pulled it, because I was not
able to find that tree on git.kernel nor alsa-project.org... :-)

> Nevertheless let me use to use this moment and say: thx for all your
> work Takashi!

Seconded. I only hope I will be able to continue to find this patch for
the next releases of the 2.6.23 kernel...

Romano




--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: easy alsa patches for the stable kernel?

[Takashi Iwai]

At Fri, 07 Sep 2007 22:59:07 +0200,
Romano Giannetti wrote:
> 
> On Fri, 2007-09-07 at 21:42 +0200, Thorsten Leemhuis wrote:
> > On 07.09.2007 14:58, Takashi Iwai wrote:
> > >>> Ah good.  I added it to ALSA HG tree now.
> 
> Thanks. BTW, is anywhere visible the current hg tree? It seems that
> http://hg-mirror.alsa-project.org/alsa-kernel/ lags a bit behind...

The patch is certainly in the primary HG repo (hg.alsa-project.org).
hg-mirror seems often out of sync, unfortuantely.


> > It's just this line afaics...
> > +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
> > ...which afaics is doing nothing more then "if DMI-Data matches FOO then
> > apply know workaround BAR". Is that correct or am I missing something
> > here (another patch that this one depends on that isn't in 2.6.23 yet
> > maybe?)?
> >
> 
> Your second guess is right. That line is a patch with respect to current
> mercurial tree, which is quite ahead of the current kernel alsa code.
> Although I'd like to know from where Andrew pulled it, because I was not
> able to find that tree on git.kernel nor alsa-project.org... :-)

It's on git.kernel.org, perex/alsa.git tree mm branch.
You can find the information in the download wiki page of
alsa-project.org.


Takashi

Toshiba A305 hda-intel (Was: Re: easy alsa patches for the stablekernel?)

[Romano Giannetti]

On Sat, 2007-09-08 at 01:42 +0200, Takashi Iwai wrote:
> At Fri, 07 Sep 2007 22:59:07 +0200,
> Romano Giannetti wrote:
> >
>
> It's on git.kernel.org, perex/alsa.git tree mm branch.
> You can find the information in the download wiki page of
> alsa-project.org.
>

Ah thanks,

	found. Now, I'd like to know if anybody has any hints over the problem
of the offset in the ADC output offset [1] (which is the Mic/Front Mic
input offset, that is). I'd like to know if this is a problem of this
specific hda-intel chip or if it's a more extended problem, and I am
quite willing to help to solve it. It's quite easy to spot with
audacity.

Booting in Vista (for the third time since I bought the thing) I noticed
that there is a "offset compensation" flag in the sound control panel,
maybe it's related...

[1] https://bugtrack.alsa-project.org/alsa-bug/file_download.php?file_id=2129&type=bug

Romano

--
Romano Giannetti --- romano.giannetti@gmail.com
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

Re: easy alsa patches for the stable kernel?

[Takashi Iwai]

At Fri, 07 Sep 2007 21:42:36 +0200,
Thorsten Leemhuis wrote:
> 
> On 07.09.2007 14:58, Takashi Iwai wrote:
> > At Fri, 07 Sep 2007 14:04:01 +0200,
> > Thorsten Leemhuis wrote:
> >> On 07.09.2007 12:21, Takashi Iwai wrote:
> >>> At Fri, 07 Sep 2007 10:22:27 +0200,
> >>> Romano Giannetti wrote:
> >>>> Takashi: good news!
> >>>>
> >>>> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> >>>> index 3557865..496d119 100644
> >>>> --- a/sound/pci/hda/patch_realtek.c
> >>>> +++ b/sound/pci/hda/patch_realtek.c
> >>>> @@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = {
> >>>>  static struct snd_pci_quirk alc268_cfg_tbl[] = {
> >>>>         SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST),
> >>>>         SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA),
> >>>> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
> >>>>         SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA),
> >>>>         SND_PCI_QUIRK(0x1025, 0x0126, "Acer", ALC268_ACER),
> >>>>         SND_PCI_QUIRK(0x1025, 0x0130, "Acer Extensa 5210", ALC268_ACER),
> >>> Ah good.  I added it to ALSA HG tree now.
> >> Just wondering: should easy-and-obvious and less-risky patches like this
> >> one be send to the stable-kernel-maintainers in parallel to adding them
> >> to the HG-Tree (or shortly afterwards)? It could safe users lots of
> >> trouble if such improvements make it quickly into production-ready
> >> kernel-releases (and from there they might even find their way into some
> >> distribution kernels quickly). Hardware then would "just work".
> > Well, this patch is defenitely not for 2.6.23 or stable kernel.
> > It's for 2.6.24.
> 
> Sorry, but why?
> 
> It's just this line afaics...
> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
> ...which afaics is doing nothing more then "if DMI-Data matches FOO then
> apply know workaround BAR". Is that correct or am I missing something
> here (another patch that this one depends on that isn't in 2.6.23 yet
> maybe?)?

The patch is based on the workaround codes that have been added after
2.6.23.  Thus the patch cannot work for 2.6.23 or earlier.

> > The problem is often that I
> > want first the merge to Linus tree, and then I forget to submit to
> > stable tree when the merge takes long time in the end.  (Ther merge of
> > alsa.git is too spotty, and that's another big problem for me.  In
> > short, I do NOT maintain alsa.git tree at all...)
> 
> Then I as one of all those long-time-lkml-lurkers without programming
> skills dare to say that maybe the alsa-project might need to improve its
> workflow? Maybe you guys should maintain two git-trees (or multiple
> branches in one tree; sorry, I'm not a git expert and not sure what the
> correct terms are)?

We do have different branches, too.  Most fix patches are usually in
the branch to be pushed (although they are rarely done).  But, the
point is that I am no official subsystem maintainer.

I have an access right to add the patches to ALSA HG tree, which is
converted to git tree automatically.  So, eventually, 90% of patches
come from me.  But, the maintenance of git tree and push request are
out of my hand.  It's a frustrating situation to me, too.

> > Another problem I see is that we have little chance for testing the
> > target patches with stable kernels.
> 
> The stable maintainers release "rc" kernels before they release the
> final ones. And the patch of course should have been applied in
> linus-tree. Both things are not a perfect safety net, but I'd say it
> should be more then enough as long as we are talking about new PCI-IDs
> for existing drivers or "apply workarounds for special machines which we
> detect by their DMI data" (lot's of those seems to be needed these days).

I'm skeptical that people ever test stable rc kernels well for certain
bugs.  Also, adding new PCI ID isn't as safe as it sounds (like in
this case).  It must be tested _before_ applying.

> >  Even it looks OK and works for
> > the later kernels, it often doesn't work or break magically with the
> > older kernels.  Usually, I have no affected hardware, and bug
> > reporters test only with the recent version (partly because developers
> > ask first to try the latest version -- if it works, why to downgrade
> > again?) 
> 
> Because he bug-reporter is likely only one that invested enough time to
> analized the problem and fix it alone or together with you guys. But
> there is likely a buch of other people that get hit by the same problem;

Well, the problem is how we can find out such unlucky guys...

> some will just say "linux sucks" and switch back to some other OS --
> especially if they never have heard of alsa or don't really know what a
> kernel really is or does.

Linux will suck really if one breaks so-called stable thing easily
without actually testing.  For stable stuff, "it should be good" isn't
enough.  It must be: "it IS good."

Don't get me wrong; I'm for stable patches.  What I'm telling here is
that we have no systematic way to find testers for certain patches on
old kernels.  (Actually, a fix for a core stuff is often much easier
to test.  But a fix specific to a certain hardware is harder to test.)


Takashi

Re: easy alsa patches for the stable kernel?

[Thorsten Leemhuis]

On 08.09.2007 01:38, Takashi Iwai wrote:
> At Fri, 07 Sep 2007 21:42:36 +0200,
> Thorsten Leemhuis wrote:
> [...]
>> Sorry, but why?
>> It's just this line afaics...
>> +       SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
>> ...which afaics is doing nothing more then "if DMI-Data matches FOO then
>> apply know workaround BAR". Is that correct or am I missing something
>> here (another patch that this one depends on that isn't in 2.6.23 yet
>> maybe?)?
> The patch is based on the workaround codes that have been added after
> 2.6.23.  Thus the patch cannot work for 2.6.23 or earlier.

Yeah, that's why I said: you are in the best position to route patches
to stable and why I didn't send the patch for my particular problem to
the stable maintainers myself. ;-)

But there are now and then patches that just take care of applying
already known workarounds on specific machines automatically by adding
the proper DMI informations; here are some from 2.6.23 which might IMHO
would be of interest for 2.6.22.x as well:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8f41b56645f03e6f50407211d6f0f0627ae95e4e
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=febe3375ea690a6cf544c33fa0fea1a06ff451ee
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8481da5a8d009d9bbac3d1483b579940e6dd9d59
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f8f794ab27dd3c6d9965ec5434775ead23d3d7a2
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ef64adbbba1b215e8b523b50ef9d568b4bf2e1e3
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7d87de2db2213e6e9413532445b14c92dae42c85

>>> The problem is often that I
>>> want first the merge to Linus tree, and then I forget to submit to
>>> stable tree when the merge takes long time in the end.  (Ther merge of
>>> alsa.git is too spotty, and that's another big problem for me.  In
>>> short, I do NOT maintain alsa.git tree at all...)
>> Then I as one of all those long-time-lkml-lurkers without programming
>> skills dare to say that maybe the alsa-project might need to improve its
>> workflow? Maybe you guys should maintain two git-trees (or multiple
>> branches in one tree; sorry, I'm not a git expert and not sure what the
>> correct terms are)?
> We do have different branches, too.  Most fix patches are usually in
> the branch to be pushed (although they are rarely done).

Well, the latter is IMHO one problem.

>  But, the point is that I am no official subsystem maintainer.

Well, I suppose he reads LKML now and then as well?

> I have an access right to add the patches to ALSA HG tree, which is
> converted to git tree automatically.  So, eventually, 90% of patches
> come from me.  But, the maintenance of git tree and push request are
> out of my hand.  It's a frustrating situation to me, too.

Yeah, I can feel your pain.

>> some will just say "linux sucks" and switch back to some other OS --
>> especially if they never have heard of alsa or don't really know what a
>> kernel really is or does.
> 
> Linux will suck really if one breaks so-called stable thing easily
> without actually testing.  For stable stuff, "it should be good" isn't
> enough.  It must be: "it IS good."

Linux IMHO will suck even more if crucial pieces of hardware does not
work for people easily, because Linux won't get even used then and will
frustrate people.

Don't get me wrong; I understand and agree mostly to the points you
raised. But we nevertheless need to find a way to make todays hardware
usable more quickly, as that hardware is often on the market only for
some months or a year until the successor-model replaces it (which might
need new drivers or workarounds) -- but it sometimes even for small
alsa-fixes takes as many months to make it from the developers out to
the kernel and from there to the distributions the user uses.

It works better in some areas of the kernels (SATA and Network drivers
come to my mind) where patches make it quicker into the linus- and
stable-kernels -- in parts that is due to better cooperation with the
hardware-vendors, but it seems the sub-tree maintainers have a better
patch-/workflow, which has a strong impact as well.

> [...]

CU
knurd

Re: easy alsa patches for the stable kernel?

[Stefan Richter]

Thorsten Leemhuis wrote:
> On 08.09.2007 01:38, Takashi Iwai wrote:
[backports to -stable]
>> Linux will suck really if one breaks so-called stable thing easily
>> without actually testing.  For stable stuff, "it should be good" isn't
>> enough.  It must be: "it IS good."

This applies (or should apply...) to everything that goes to Linus in
his pre -rc1 merge windows.  To post -rc1 submissions and even more so
to -stable submissions, additional criteria apply.

However, there are special kernel trees out there which accept
backports.  Linux distributors do backports, because they have the means
to do so.

> Linux IMHO will suck even more if crucial pieces of hardware does not
> work for people easily, because Linux won't get even used then and will
> frustrate people.
> 
> Don't get me wrong; I understand and agree mostly to the points you
> raised. But we nevertheless need to find a way to make todays hardware
> usable more quickly, as that hardware is often on the market only for
> some months or a year until the successor-model replaces it (which might
> need new drivers or workarounds) --

In the end there is but one solution to this:  Open specs.

> but it sometimes even for small
> alsa-fixes takes as many months to make it from the developers out to
> the kernel and from there to the distributions the user uses.
> 
> It works better in some areas of the kernels (SATA and Network drivers
> come to my mind) where patches make it quicker into the linus- and
> stable-kernels -- in parts that is due to better cooperation with the
> hardware-vendors, but it seems the sub-tree maintainers have a better
> patch-/workflow, which has a strong impact as well.

Feature additions to SATA and networking, e.g. support of additional
hardware, are not backported to -stable or merged post -rc1 either, I
presume.  Maybe they are better in getting stuff ready in time before
merge windows open --- I don't know, I don't watch these subsystems.
Maybe they have less trouble with closed or nonexisting specs...?
-- 
Stefan Richter
-=====-=-=== =--= -=---
http://arcgraph.de/sr/

Re: easy alsa patches for the stable kernel?

[Thorsten Leemhuis]

On 08.09.2007 19:49, Stefan Richter wrote:
> Thorsten Leemhuis wrote:
>> On 08.09.2007 01:38, Takashi Iwai wrote:
> [backports to -stable]
>>> Linux will suck really if one breaks so-called stable thing easily
>>> without actually testing.  For stable stuff, "it should be good" isn't
>>> enough.  It must be: "it IS good."
> This applies (or should apply...) to everything that goes to Linus in
> his pre -rc1 merge windows.  To post -rc1 submissions and even more so
> to -stable submissions, additional criteria apply.

Sure -- but new PCI-IDs for ATA-controller these days get added to
linus-tree post-rc1. They even find their way into the stable-tree since
some weeks now, and I think that's really good (due to one of those
patches my PATA-Controller in my 2 1/2 months old Laptop simply works
now and I don't have to wait until 2.6.23 is out).

But similar easy-and-small patches for the sound drivers (¹) take way
longer to get into the kernel.

(¹) -- like the patches I linked to earlier in this thread that add a
dmi-entry for another machine to the whitelist of machines to apply a
know workaround on. Or the regression for my laptop:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a4eed138add1018846d17e813560b0c7c0ae8e01

> [...]
>> Linux IMHO will suck even more if crucial pieces of hardware does not
>> work for people easily, because Linux won't get even used then and will
>> frustrate people.
>>
>> Don't get me wrong; I understand and agree mostly to the points you
>> raised. But we nevertheless need to find a way to make todays hardware
>> usable more quickly, as that hardware is often on the market only for
>> some months or a year until the successor-model replaces it (which might
>> need new drivers or workarounds) --
> In the end there is but one solution to this:  Open specs.

Sure, I suppose most of us will agree on that.

But "open specs" is only part of the solution -- in and ideal world
users IMHO should have *easy* access to the proper drivers immediately
when the hardware becomes available. And that involves multiple layers IMHO:

1. hardware vendors need to open their specs before the hardware becomes
available (some like Intel for their ATA-Stuff do that afaics); hardware
also needs to be available for testing soon enough as well in case the
hardware-vendor is not the driver author at the same time (like in the
intel-case)

2. kernel developers need to have a workflow where at least small and
easy driver enhancements (e.g. those that just add a new PCI-IDs or
similar stuff like the extend list of machines to apply known workaround
on) make it quickly out into a officially released kernel. (Even bigger
driver updates IMHO need to get way quicker to the users, but that's a
more complex topic as there the risk of breaking something is bigger)

3. Distributors need to pick those kernels up and provide them to the
users. If they don't want to ship completely new kernels they need to
cherry-pick the improvements -- that's a lot of work and for the
distribution-kernel-maintainers if the maintainer of the driver in
question does not provide informations if a patch should be safe even
for older kernels; the interdependencies with other parts of the kernel
make it more complicated.

Point "3" is solved for me, as Fedora regularly ships new stable- and
linus-kernels during the life-time of a Fedora release (for other
distributions you are often out of luck and you have to use the
devel-tree, as only those get new kernels, but that's a different
discussion). But that doesn't help much if even a in-time
one-liner-pci-addition-patch from the vendor ("1") get stuck in area "2"
for weeks or months.

>> but it sometimes even for small
>> alsa-fixes takes as many months to make it from the developers out to
>> the kernel and from there to the distributions the user uses.
>>
>> It works better in some areas of the kernels (SATA and Network drivers
>> come to my mind) where patches make it quicker into the linus- and
>> stable-kernels -- in parts that is due to better cooperation with the
>> hardware-vendors, but it seems the sub-tree maintainers have a better
>> patch-/workflow, which has a strong impact as well.
> Feature additions to SATA and networking, e.g. support of additional
> hardware, are not backported to -stable or merged post -rc1 either, I
> presume. 

They are -- no many, but a few, and that's a good start IMHO:

=== linus

2.6.23-rc1 was on "22 Jul 2007"
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f695baf2df9e0413d3521661070103711545207a

The we had things like

Wed Aug 15 02:53:39 2007 -0400 sata_mv: PCI IDs for Hightpoint
RocketRaid 1740/1742
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=cfbf723eb7928879292ee71fa0d118fc4e37b8c9

Wed Aug 22 14:28:02 2007 -0700 USB: resubmission unusual_devs
modification for Nikon D80
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=83fc8a151beda2d63e196a7ab2e12316c37a1e91

Fri Aug 31 03:48:49 2007 -0400 ata_piix: IDE mode SATA patch for Intel
Tolapai
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c5cf0ffa71d32c03607d287b76483479afb0bcd3

Fri Aug 31 04:00:19 2007 -0400 pata_marvell: Add more identifiers
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d36ee189f392ea89de85124a0b58477bb0f2e0a6

=== stable 2.6.22.y

Wed, 22 Aug 2007 23:23:26 +0000 (16:23 -0700) libata: add ATI SB700
device IDs to AHCI driver
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=3443d563dc53875b15d919c4bece391f1ffd4776

Wed, 15 Aug 2007 16:25:10 +0000 (09:25 -0700) pata_atiixp: add SB700 PCI ID
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commitdiff;h=fd2efeae63567dde934bb54772bb1b991275b04a

Thu, 9 Aug 2007 21:27:26 +0000 (14:27 -0700) Add a PCI ID for santa
rosa's PATA controller.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=a03cf181b9c19b4e95d847cd394c7ffaf5109d06

> Maybe they are better in getting stuff ready in time before
> merge windows open --- I don't know, I don't watch these subsystems.

Well, hardware gets quickly from development over production info the
marked and we IMHO need to be quickly as well if we want to support
todays hardware and not only yesterdays.

> Maybe they have less trouble with closed or nonexisting specs...?

Hehe, I'd say you should consider yourself lucky for the OHCI-standard
in the FireWire space -- that makes sure you don't have to deal with
PCI-ID-additions. ;-) And workarounds for specific controllers seems to
be seldom in that area as well (but often needed for sound-drivers these
days; and I had wrongly thought HDA would put that to and end...)

CU
knurd

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Roger Gammans]

Thanks for picking this up again Andew.

On Wed, Sep 05, 2007 at 06:05:44PM +0200, Takashi Iwai wrote:
> The patch would definitely break many other machines, so no, it can't
> be applied as is.  Note that there is an equivalent workaround by
> adding "model=auto" module option.

Ah, I hadn't spotted that.

> The support for Acer Aspire was already improved in mm tree.  At
> least, we have the support for Aspire 9810 and co.  If it's the
> compatible one, the chance is high.

Yes, I played a little with that, looking back at what Ive got 
here the following patch worked on what I pulled about
2weeks ago byi:-
 git pull git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git/
 

> Roger, could you try git-alsa patch in the latest mm together with
> model=acer-aspiore option?  If it works, I can easily add your device
> ID to the table.

I assume youe think of somehting like this which I tried earlier -
but would have been wasier if I'd have known about the mode option..

        SND_PCI_QUIRK(0x1462, 0xa422, "MSI", ALC883_TARGA_2ch_DIG),
        SND_PCI_QUIRK(0x1025, 0x006c, "Acer Aspire 9810", ALC883_ACER_ASPIRE),
        SND_PCI_QUIRK(0x1025, 0x0110, "Acer Aspire", ALC883_ACER_ASPIRE),
+       SND_PCI_QUIRK(0x1025, 0x0112, "Acer Aspire", ALC883_ACER_ASPIRE),
        SND_PCI_QUIRK(0x15d9, 0x8780, "Supermicro PDSBA", ALC883_3ST_6ch),
        SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_MEDION),

(Patch headers removed as patch manually editted  I appeat to got onto some on 
branch mode with git and it producing odd patches (ones with '++' at the start
 of some lines)) 

This does indeed work. I'm sorry I should have replied with this sooner, 
buts since it appeared noone was listening...

TTFN
-- 
Roger. 	                        Home| http://www.sandman.uklinux.net/
Master of Peng Shui.      (Ancient oriental art of Penguin Arranging)
Work|Independent Sys Consultant | http://www.computer-surgery.co.uk/
 New key Fpr: 72AF 0ACC 9A53 E59F B1B6  DC14 1983 A13E 5C3D 3CEB 

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Takashi Iwai]

At Wed, 5 Sep 2007 17:26:50 +0100,
Roger Gammans wrote:
> 
> Thanks for picking this up again Andew.
> 
> On Wed, Sep 05, 2007 at 06:05:44PM +0200, Takashi Iwai wrote:
> > The patch would definitely break many other machines, so no, it can't
> > be applied as is.  Note that there is an equivalent workaround by
> > adding "model=auto" module option.
> 
> Ah, I hadn't spotted that.
> 
> > The support for Acer Aspire was already improved in mm tree.  At
> > least, we have the support for Aspire 9810 and co.  If it's the
> > compatible one, the chance is high.
> 
> Yes, I played a little with that, looking back at what Ive got 
> here the following patch worked on what I pulled about
> 2weeks ago byi:-
>  git pull git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git/
>  
> 
> > Roger, could you try git-alsa patch in the latest mm together with
> > model=acer-aspiore option?  If it works, I can easily add your device
> > ID to the table.
> 
> I assume youe think of somehting like this which I tried earlier -
> but would have been wasier if I'd have known about the mode option..
> 
>         SND_PCI_QUIRK(0x1462, 0xa422, "MSI", ALC883_TARGA_2ch_DIG),
>         SND_PCI_QUIRK(0x1025, 0x006c, "Acer Aspire 9810", ALC883_ACER_ASPIRE),
>         SND_PCI_QUIRK(0x1025, 0x0110, "Acer Aspire", ALC883_ACER_ASPIRE),
> +       SND_PCI_QUIRK(0x1025, 0x0112, "Acer Aspire", ALC883_ACER_ASPIRE),
>         SND_PCI_QUIRK(0x15d9, 0x8780, "Supermicro PDSBA", ALC883_3ST_6ch),
>         SND_PCI_QUIRK(0x161f, 0x2054, "Medion laptop", ALC883_MEDION),
> 
> (Patch headers removed as patch manually editted  I appeat to got onto some on 
> branch mode with git and it producing odd patches (ones with '++' at the start
>  of some lines)) 
> 
> This does indeed work. I'm sorry I should have replied with this sooner, 
> buts since it appeared noone was listening...

Great, then I'll add this entry to ALSA tree.
It's Aspire 9303, right?


thanks,

Takashi

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Roger Gammans]

On Wed, Sep 05, 2007 at 06:46:57PM +0200, Takashi Iwai wrote:
> Great, then I'll add this entry to ALSA tree.
> It's Aspire 9303, right?

That's what it says on the box.

But it also says 9300 too, if I see a different 9300 I'll check
it pci devs, but there weren't any other 93xx models  even listed at
our distributor the last time I looked.

TTFN
-- 
Roger. 	                        Home| http://www.sandman.uklinux.net/
Master of Peng Shui.      (Ancient oriental art of Penguin Arranging)
Work|Independent Sys Consultant | http://www.computer-surgery.co.uk/
 New key Fpr: 72AF 0ACC 9A53 E59F B1B6  DC14 1983 A13E 5C3D 3CEB 

Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22

[Takashi Iwai]

At Wed, 5 Sep 2007 18:01:31 +0100,
Roger Gammans wrote:
> 
> On Wed, Sep 05, 2007 at 06:46:57PM +0200, Takashi Iwai wrote:
> > Great, then I'll add this entry to ALSA tree.
> > It's Aspire 9303, right?
> 
> That's what it says on the box.
> 
> But it also says 9300 too, if I see a different 9300 I'll check
> it pci devs, but there weren't any other 93xx models  even listed at
> our distributor the last time I looked.

Well, I just want to be a bit more specific in the table entry.
The model 9303 must be enough as the information (and it's correct, at
least).

Now I added the entry to the ALSA tree.


Thanks,

Takashi