[alsa-devel] iec958 regression with alsa 1.0.22 and kernel 2.6.33 on Intel DG45FC motherboard

[Wu Fengguang]

On Thu, May 06, 2010 at 03:42:27PM +0800, David Härdeman wrote:
> On Thu, May 6, 2010 02:55, Wu Fengguang wrote:
> > On Thu, May 06, 2010 at 07:05:16AM +0800, David Härdeman wrote:
> >> A recent upgrade to kernel 2.6.33.x and alsa 1.0.22 broke spdif (iec958)
> >
> > Upgraded from which kernel?
> 
> 2.6.32.something, can check exact version later if you want. alsa
> userspace bits were upgraded at the same time (can also check from which
> version later if necessary).

Yes, should be OK in 2.6.32, and broken by this commit:

commit 52dc438606d1ef78b96f56cc04dbea9242005730
Author: Alexey Fisher <bug-track at fisher-privat.net>
Date:   Sat Dec 12 11:16:41 2009 +0200

    ALSA: hda - Overwrite pin config on intel DG45ID board.
    
    The pin config provided by BIOS have some problems:
    0x0221401f: [Jack] HP Out at Ext Front  <-- other association and sequence
    0x02a19020: [Jack] Mic at Ext Front     <-- other association
    0x01113014: [Jack] Speaker at Ext Rear  <-- line out (not speaker)
    0x01114010: [Jack] Speaker at Ext Rear  <-- line out
    0x01a19030: [Jack] Mic at Ext Rear      <-- other association
    0x01111012: [Jack] Speaker at Ext Rear  <-- line out
    0x01116011: [Jack] Speaker at Ext Rear  <-- line out
    0x40f000f0: [N/A] Other at Ext N/A
    0x40f000f0: [N/A] Other at Ext N/A
    0x40f000f0: [N/A] Other at Ext N/A
    0x40f000f0: [N/A] Other at Ext N/A
    0x40f000f0: [N/A] Other at Ext N/A
    0x01451140: [Jack] SPDIF Out at Ext Rear
    0x40f000f0: [N/A] Other at Ext N/A
    
    just overwrite it.
    
    Signed-off-by: Alexey Fisher <bug-track at fisher-privat.net>
    Signed-off-by: Takashi Iwai <tiwai at suse.de>

> 
> >> output on my Intel DG45FC motherboard (IDT 92HD73E1X5 codec,
> >> snd-hda-intel driver).
> >>
> >> After playing around a bit with module params, it turns out that loading
> >> snd-hda-intel with model=no-jd fixes this problem (previously the module
> >> worked without any model option at all, note also that model=intel does
> >> not work which is kinda weird).
> >
> > You mean model=intel never worked?
> 
> No, I mean that I've never used a model= parameter before, and in trying
> to debug this new problem I tried model=intel which did not fix it but
> model=no-jd does. So model=intel might have worked before.

Yes, model=intel worked before.
 
> On a related note, why is model=intel even there (and why is the end-user
> expected to set it)? The docs says it's for DG45FC and DG45ID
> motherboards, but shouldn't those motherboards be possible to autodetect
> in the driver via DMI info?

It has to be assigned case by case, since we never know whether the
current settings will apply automatically to future Intel boards..

Thanks,
Fengguang