* debugging nm256: some results, many questions
@ 2006-02-23 18:52 Florian Schlichting
2006-02-24 18:15 ` Takashi Iwai
0 siblings, 1 reply; 14+ messages in thread
From: Florian Schlichting @ 2006-02-23 18:52 UTC (permalink / raw)
To: alsa-devel
[-- Attachment #1: Type: text/plain, Size: 5007 bytes --]
Hi,
spurred by the upcoming removal of the OSS audio drivers and a post on
LKML saying ALSA developers lack access to hardware / testers, I thought
I should get a little more active and find out about the reasons for
frequent hangs when booting my Dell Latitude LS (the 500 MHz version
with 2MB video RAM) - the issue looks similar to
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328
ie setting another workaround than the default (=1) doesn't have any
effect.
I was able to narrow down where exactly it hangs (most of the time), but
have as yet no idea why this doesn't occur with the OSS driver or why my
ideas for workarounds weren't successful. I must say that this is the
first time I'm looking at kernel code and I'm pretty inexperienced with
C, so I hope that some of you who are much more experienced with the
sound architecture have some pointers and ideas for me...
I'm not sure about what "is known" about this problem (or where that
would be documented), so what I write now is fairly extensive...
hangs occur at initialization, more precisely when both snd-nm256 and
snd-ac97-codec are loaded (repeated loading and unloading of snd-nm256
alone is fine) - it never died on me during ordinary use. nm256 is being
initialized via snd_nm256_probe calling snd_nm256_mixer on line 1648
calling snd_ac97_mixer on line 1249. This is identical for all hangs.
snd_ac97_mixer and snd_ac97_mixer_build in ac97_codec.c is a bit more
complicated, as hangs occur in various places when the different
registers are initialized; for me, most occur when initializing the
volume of Phone, Mic, Line-In, CD, Video and Aux. As far as I can tell
there's no pattern what register it hangs at. All eventually call
snd_ac97_read, which returns ac97->bus->ops->read(ac97, reg) which is
snd_nm256_ac97_read which, after some delays and waiting, returns
readw(chip->cport + offset) in snd_nm256_readw. This is as far as I
could trace it, and ALL hangs during initialization occur here.
Is that as far as tracing the source of the problem can go? So what can
be done about this, and why doesn't it occur with the OSS driver?
I did a little searching and found the web pages of the original OSS
driver author, where he says among other things (at
http://web.archive.org/web/20020830005020/www.uglx.org/sony-nm256av-notes.html)
> (However, I've run into problems with hanging the laptop while writing
> to some of the optional registers; you have been warned. The safest
> approach is to stick with the standard set of registers.)
>
> Also, if you attempt to read too quickly from the mixer, it will also
> cause hangs. Bad juju. The driver caches a copy of the mixer contents,
> and it seems to be successful at avoiding the hanging problem.
I haven't understood how the OSS driver is doing this caching, and
whether the ALSA driver is doing it, too. There are a lot of reads, and
during tracing the hang I had the impression that an increasing number of
printk's is not just slowing down the whole process but also slightly reducing
the likelihood of crashes. I thus added massive udelay's before and
after the read in an attempt to come up with a fix, but nothing changed
(I couldn't even bring the delays to a point where I'd notice them), so
I aborted this.
The other idea I came up with is that nearly all the hangs occur at
registers I don't need (recording from the mic gets heavily distorted by
the hard drive spinning, and I've never noticed Phone, Line-In, Video or
Aux to do anything, so I really only need Master_Stereo and PCM) and
could perhaps be avoided by telling the driver not to use them. So in
the array mixer_regs at nm256.c:1229 I commented out everything apart
from AC97_MASTER, AC97_PCM, AC97_GENERAL_PURPOSE (which seemed important
for many things in ac97_codec.c) and the apparently indispensable
AC97_VENDOR_ID1, AC97_VENDOR_ID2. Booting with the resulting modules got
me through the initialization very smoothly (I tried at least 10 times),
but it always crashes shortly after completing snd_nm256_probe (on the
console, I still get the new bash prompt before it hangs; on bootup, I
sometimes get a line from the next driver)
What on earth is happening _after_ initialization that's not happening
during normal initialization??? (anything to do with
concurrency/interrupts, and how would I test for that? - notice that in
the above mentioned bug report, the reporter claims that the driver
worked well with kernel 2.6.7, so perhaps it's not the driver but
another subsection, like pci?)
I'm confused, but I hope some of you are still with me and can tell me
whether I've done some things right and what else I could try... I'm
still not familiar enough with ALSA and AC97 to have any idea about what
the OSS driver is really doing differently here (but isn't it
implementing its own mixer??), but since we've got working code it must
be possible to find a solution...
Florian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: debugging nm256: some results, many questions 2006-02-23 18:52 debugging nm256: some results, many questions Florian Schlichting @ 2006-02-24 18:15 ` Takashi Iwai 2006-03-11 17:44 ` Florian Schlichting 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2006-02-24 18:15 UTC (permalink / raw) To: Florian Schlichting; +Cc: alsa-devel At Fri, 24 Feb 2006 02:52:54 +0800, Florian Schlichting wrote: > > Hi, > > spurred by the upcoming removal of the OSS audio drivers and a post on > LKML saying ALSA developers lack access to hardware / testers, I thought > I should get a little more active and find out about the reasons for > frequent hangs when booting my Dell Latitude LS (the 500 MHz version > with 2MB video RAM) - the issue looks similar to > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328 > ie setting another workaround than the default (=1) doesn't have any > effect. > > I was able to narrow down where exactly it hangs (most of the time), but > have as yet no idea why this doesn't occur with the OSS driver or why my > ideas for workarounds weren't successful. I must say that this is the > first time I'm looking at kernel code and I'm pretty inexperienced with > C, so I hope that some of you who are much more experienced with the > sound architecture have some pointers and ideas for me... > > I'm not sure about what "is known" about this problem (or where that > would be documented), so what I write now is fairly extensive... > > > hangs occur at initialization, more precisely when both snd-nm256 and > snd-ac97-codec are loaded (repeated loading and unloading of snd-nm256 > alone is fine) - it never died on me during ordinary use. nm256 is being > initialized via snd_nm256_probe calling snd_nm256_mixer on line 1648 > calling snd_ac97_mixer on line 1249. This is identical for all hangs. > > snd_ac97_mixer and snd_ac97_mixer_build in ac97_codec.c is a bit more > complicated, as hangs occur in various places when the different > registers are initialized; for me, most occur when initializing the > volume of Phone, Mic, Line-In, CD, Video and Aux. As far as I can tell > there's no pattern what register it hangs at. All eventually call > snd_ac97_read, which returns ac97->bus->ops->read(ac97, reg) which is > snd_nm256_ac97_read which, after some delays and waiting, returns > readw(chip->cport + offset) in snd_nm256_readw. This is as far as I > could trace it, and ALL hangs during initialization occur here. > > Is that as far as tracing the source of the problem can go? So what can > be done about this, and why doesn't it occur with the OSS driver? The OSS driver doesn't use the common ac97 codec module but its own one. I bet OSS nm256 would hang, too, if it were to use ac97_codec.c. Perhaps it's good to trace and record what accesses OSS driver does, so that we can comapre the sequence. It might be the buffer address calculation. But I remember that I got crash even with exactly same address as OSS driver uses, too. Anyway, it's better to reduce any hang-possibilities. > I did a little searching and found the web pages of the original OSS > driver author, where he says among other things (at > http://web.archive.org/web/20020830005020/www.uglx.org/sony-nm256av-notes.html) > > > (However, I've run into problems with hanging the laptop while writing > > to some of the optional registers; you have been warned. The safest > > approach is to stick with the standard set of registers.) > > > > Also, if you attempt to read too quickly from the mixer, it will also > > cause hangs. Bad juju. The driver caches a copy of the mixer contents, > > and it seems to be successful at avoiding the hanging problem. > > I haven't understood how the OSS driver is doing this caching, and > whether the ALSA driver is doing it, too. There are a lot of reads, and > during tracing the hang I had the impression that an increasing number of > printk's is not just slowing down the whole process but also slightly reducing > the likelihood of crashes. I thus added massive udelay's before and > after the read in an attempt to come up with a fix, but nothing changed > (I couldn't even bring the delays to a point where I'd notice them), so > I aborted this. > > The other idea I came up with is that nearly all the hangs occur at > registers I don't need (recording from the mic gets heavily distorted by > the hard drive spinning, and I've never noticed Phone, Line-In, Video or > Aux to do anything, so I really only need Master_Stereo and PCM) and > could perhaps be avoided by telling the driver not to use them. So in > the array mixer_regs at nm256.c:1229 I commented out everything apart > from AC97_MASTER, AC97_PCM, AC97_GENERAL_PURPOSE (which seemed important > for many things in ac97_codec.c) and the apparently indispensable > AC97_VENDOR_ID1, AC97_VENDOR_ID2. Booting with the resulting modules got > me through the initialization very smoothly (I tried at least 10 times), > but it always crashes shortly after completing snd_nm256_probe (on the > console, I still get the new bash prompt before it hangs; on bootup, I > sometimes get a line from the next driver) Yeah, the table was introduced excatly from the same idea. It improved a bit, but not solves the problem entirely. > What on earth is happening _after_ initialization that's not happening > during normal initialization??? (anything to do with > concurrency/interrupts, and how would I test for that? - notice that in > the above mentioned bug report, the reporter claims that the driver > worked well with kernel 2.6.7, so perhaps it's not the driver but > another subsection, like pci?) It's not like a typical interrupt storm. If so, we could capture it (and the recent kernel has a mechanism to disable such irq automatically). > I'm confused, but I hope some of you are still with me and can tell me > whether I've done some things right and what else I could try... I'm > still not familiar enough with ALSA and AC97 to have any idea about what > the OSS driver is really doing differently here (but isn't it > implementing its own mixer??), but since we've got working code it must > be possible to find a solution... This problem is really tough. What we can do is just a shot in the dark... BTW, can the hang be avoided if you remove the whole mixer section? i.e. let snd_nm256_mixer() simplly return 0 without doing anything, and try PCM playback/capture. What about if you skip the whole snd_nm256_ac97_reset() sequence? Takashi ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-02-24 18:15 ` Takashi Iwai @ 2006-03-11 17:44 ` Florian Schlichting 2006-03-13 6:46 ` Florian Schlichting 0 siblings, 1 reply; 14+ messages in thread From: Florian Schlichting @ 2006-03-11 17:44 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1: Type: text/plain, Size: 4436 bytes --] Hi Takashi, thanks for your reply, and sorry for not coming back to it in two weeks. Here's some more about nm256: On Fri, Feb 24, 2006 at 07:15:55PM +0100, Takashi Iwai wrote: > At Fri, 24 Feb 2006 02:52:54 +0800, > Florian Schlichting wrote: > > there's no pattern what register it hangs at. All eventually call > > snd_ac97_read, which returns ac97->bus->ops->read(ac97, reg) which is > > snd_nm256_ac97_read which, after some delays and waiting, returns > > readw(chip->cport + offset) in snd_nm256_readw. This is as far as I > > could trace it, and ALL hangs during initialization occur here. > > > > Is that as far as tracing the source of the problem can go? So what can > > be done about this, and why doesn't it occur with the OSS driver? > > The OSS driver doesn't use the common ac97 codec module but its own > one. I bet OSS nm256 would hang, too, if it were to use > ac97_codec.c. > > Perhaps it's good to trace and record what accesses OSS driver does, > so that we can comapre the sequence. I don't entirely understand what the OSS driver does; it certainly does make some use of the ac97 codec, eg in nm256_resetAC97() it uses ac97_put_register() to preload mixer settings into the codec's mixer cache. A comment in the source says: /* * Initial register values to be written to the AC97 mixer. * While most of these are identical to the reset values, we do this * so that we have most of the register contents cached--this avoids * reading from the mixer directly (which seems to be problematic, * probably due to ignorance). */ I noticed that ac97_get_register() will ALWAYS check and return the cached value, if it's valid. For ALSA, there's snd_ac97_read() and snd_ac97_read_cache(), and the mixer initialisation makes heavy use of the latter: While during OSS initialisation, there occurs ONE (1) read to the mixer registers (namely, AC97_RESET), ALSA initialisation performs a total of NINETY-TWO (92) mixer register reads, namely (in the order they occur): AC97_VENDOR_ID1 once AC97_VENDOR_ID2 once AC97_MASTER eight times AC97_MASTER_MONO ten times AC97_PC_BEEP once AC97_PHONE ten times (this one's a popular hang) AC97_MIC ten times AC97_LINE eight times AC97_CD eight times AC97_VIDEO eight times AC97_AUX eight times AC97_PCM eight times AC97_REC_GAIN three times AC97_GENERAL_PURPOSE ten times I think this is clearly a bit excessive - I didn't trace where these reads occur, but why would you need to read the same register value ten times in a row - especially since OSS doesn't read them _ever_ and just gives back the previously written value? So, given that reading mixer registers is what's problematic with this piece of hardware, I think this is where to start doing things differently. One question is why the ALSA ac97 codec doesn't use snd_ac97_read_cache() during initialisation. Would you be willing to change that? Or should I rather come up with caching in the callback function, so that the changes/workaround can be limited to nm256.c? (And, more fundamentally, do you agree that this is a valid analysis of the problem?) > > It might be the buffer address calculation. But I remember that I got > crash even with exactly same address as OSS driver uses, too. > Anyway, it's better to reduce any hang-possibilities. I didn't fiddle around with that, but I noticed that the OSS author's web page gives a different address for the mixer status offset (=0 if safe to write to the mixer) than what is currently used in both OSS and ALSA driver; I played around a bit, and its value (offset 0xa04 or 0xa06 or 0xa08) doesn't seem to have any effect on hangs... > BTW, can the hang be avoided if you remove the whole mixer section? > i.e. let snd_nm256_mixer() simplly return 0 without doing anything, > and try PCM playback/capture. If I remove the mixer, there are no hangs any more, but I can't play music (no errors, but no sound either - as if the master mixer was muted) > > What about if you skip the whole snd_nm256_ac97_reset() sequence? this doesn't do any harm, and I've got the impression that it considerably improves the likelihood that initialisation will complete - from 1/5 to 3/5, I'd say. unless anybody has got other suggestions, I would try to implement some mandatory caching for reads from the mixer next... Florian [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-11 17:44 ` Florian Schlichting @ 2006-03-13 6:46 ` Florian Schlichting 2006-03-13 11:58 ` Takashi Iwai 0 siblings, 1 reply; 14+ messages in thread From: Florian Schlichting @ 2006-03-13 6:46 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1.1: Type: text/plain, Size: 1133 bytes --] I went ahead implementing caching of reads to the ac97 mixer registers inside the nm256 driver, and also included "preloading" of the cache, just as the OSS driver does. And it works like a charm: no reads to the mixers, no crashes any more! Alas, this improvement has taught me what some of the reads were for - detection of volume resolution, for example: I suddenly had two maxima on the PCM mixer. As all my mixers have a resolution of 31, I customized the values being written to the cache so that the ac97_codec would "detect" the correct value. Now the only difference to the non-patched state (according to alsactl) is that a few mixers are stereo instead of mono - but up to now this doesn't seem to have any effect on anything I do, everything works fine... The question is: how portable is this to other users of nm256? Will we need a detect for this workaround? I've attached a patch against 1.0.10rc3 - I just saw that in 1.0.11rc3 there has been a cleanup in nm256, and my patch doesn't apply cleanly any more... although I don't think it will need to be changed. Perhaps I could have some feedback first? Florian [-- Attachment #1.2: nm256-patch --] [-- Type: text/plain, Size: 3404 bytes --] --- /usr/src/linux/sound/pci/nm256/nm256.c.orig 2006-03-13 13:46:23.000000000 +0800 +++ /usr/src/linux/sound/pci/nm256/nm256.c.cleaned_up 2006-03-13 14:13:28.000000000 +0800 @@ -1152,22 +1152,33 @@ } /* + * some nm256 easily crash when reading from mixer registers + * thus we're caching both read and written values for reading */ static unsigned short snd_nm256_ac97_read(ac97_t *ac97, unsigned short reg) { nm256_t *chip = ac97->private_data; - int res; if (reg >= 128) return 0; if (! snd_nm256_ac97_ready(chip)) return 0; - res = snd_nm256_readw(chip, chip->mixer_base + reg); + + if (! test_bit(reg, ac97->reg_accessed)) { /* ! read_workaround && */ + /* we should never get here, really, as all regs have been + * loaded into the cache, and the cached-flags in reg_accessed + * are never cleared. Thus we could also test for + * ! read_workaround (once introduced and properly set) + */ + ac97->regs[reg] = snd_nm256_readw(chip, chip->mixer_base + reg); + set_bit(reg, ac97->reg_accessed); + } + /* Magic delay. Bleah yucky. */ msleep(1); - return res; + return ac97->regs[reg]; } /* @@ -1188,17 +1199,62 @@ while (tries-- > 0) { snd_nm256_writew(chip, base + reg, val); msleep(1); /* a little delay here seems better.. */ - if (snd_nm256_ac97_ready(chip)) + if (snd_nm256_ac97_ready(chip)) { + /* successful write: set cache */ + ac97->regs[reg] = (val & 0xdfdf); /* we don't do this volume resolution */ + set_bit(reg, ac97->reg_accessed); return; + } } snd_printd("nm256: ac97 codec not ready..\n"); } +/* + * below copied from OSS driver + * this list could perhaps be fused with mixer_regs[] ?? + * + * Initial register values to be written to the AC97 mixer. + * While most of these are identical to the reset values, we do this + * so that we have most of the register contents cached--this avoids + * reading from the mixer directly (which seems to be problematic, + * probably due to ignorance). + */ + +struct initialValues +{ + unsigned int reg; + unsigned short value; +}; + +static struct initialValues nm256_ac97_initial_values[] = +{ + { AC97_MASTER, 0x8000 }, + { AC97_HEADPHONE, 0x8000 }, + { AC97_MASTER_MONO, 0x0000 }, + { AC97_PC_BEEP, 0x0000 }, + { AC97_PHONE, 0x0008 }, + { AC97_MIC, 0x8000 }, + { AC97_LINE, 0x8808 }, + { AC97_CD, 0x8808 }, + { AC97_VIDEO, 0x8808 }, + { AC97_AUX, 0x8808 }, + { AC97_PCM, 0x0808 }, + { AC97_REC_SEL, 0x0000 }, + { AC97_REC_GAIN, 0x0B0B }, + { AC97_GENERAL_PURPOSE, 0x0000 }, + { AC97_3D_CONTROL, 0x8000 }, + { AC97_VENDOR_ID1, 0x8384 }, + { AC97_VENDOR_ID2, 0x7609 }, + { 0xffff, 0xffff } +}; + + /* initialize the ac97 into a known state */ static void snd_nm256_ac97_reset(ac97_t *ac97) { nm256_t *chip = ac97->private_data; + int x; /* Reset the mixer. 'Tis magic! */ snd_nm256_writeb(chip, 0x6c0, 1); @@ -1211,6 +1267,12 @@ snd_nm256_writeb(chip, 0x6cc, 0x80); snd_nm256_writeb(chip, 0x6cc, 0x0); } + for (x = 0; nm256_ac97_initial_values[x].reg != 0xffff; x++) { + /* preload the cache, so as to avoid even a single read of the mixer regs */ + snd_ac97_write_cache(ac97, + nm256_ac97_initial_values[x].reg, + nm256_ac97_initial_values[x].value); + } } /* create an ac97 mixer interface */ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-13 6:46 ` Florian Schlichting @ 2006-03-13 11:58 ` Takashi Iwai 2006-03-13 14:55 ` Florian Schlichting 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2006-03-13 11:58 UTC (permalink / raw) To: Florian Schlichting; +Cc: alsa-devel At Mon, 13 Mar 2006 14:46:28 +0800, Florian Schlichting wrote: > > I went ahead implementing caching of reads to the ac97 mixer registers > inside the nm256 driver, and also included "preloading" of the cache, > just as the OSS driver does. And it works like a charm: no reads to the > mixers, no crashes any more! Great, thanks for nailing it down. > Alas, this improvement has taught me what some of the reads were for - > detection of volume resolution, for example: I suddenly had two maxima > on the PCM mixer. As all my mixers have a resolution of 31, I customized > the values being written to the cache so that the ac97_codec would > "detect" the correct value. Now the only difference to the non-patched > state (according to alsactl) is that a few mixers are stereo instead of > mono - but up to now this doesn't seem to have any effect on anything I > do, everything works fine... > > The question is: how portable is this to other users of nm256? Will we > need a detect for this workaround? I don't think so. The read cache should work in general. > I've attached a patch against 1.0.10rc3 - I just saw that in 1.0.11rc3 > there has been a cleanup in nm256, and my patch doesn't apply cleanly > any more... although I don't think it will need to be changed. Perhaps I > could have some feedback first? The writes in snd_nm256_ac97_reset() break the PM resume. You should check reg_accessed[] and use the cached value if already written. Also, it's simpler to call snd_nm256_ac97_write() directly there instead of snd_ac97_write_cache(). Additionally, we may use a static resolution table to skip the volume resolution detection with the latest ac97_codec. Takashi ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-13 11:58 ` Takashi Iwai @ 2006-03-13 14:55 ` Florian Schlichting 2006-03-13 15:50 ` Takashi Iwai 0 siblings, 1 reply; 14+ messages in thread From: Florian Schlichting @ 2006-03-13 14:55 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1: Type: text/plain, Size: 1628 bytes --] On Mon, Mar 13, 2006 at 12:58:46PM +0100, Takashi Iwai wrote: > > The writes in snd_nm256_ac97_reset() break the PM resume. You should > check reg_accessed[] and use the cached value if already written. Yes, I just noticed the broken PM resume... The following is just to check that I don't misunderstand things: I originally wanted to write the initial values in snd_nm256_mixer(), but there ac97 is still an ac97_template_t and doesn't have a register cache. Still, reg_accessed[] is set there, meaning "register may be touched". Consequently, in snd_nm256_ac97_reset() all usable reg_accessed[] are already set, which the first time means nothing (and all registers should be written), but during a resume means the value shouldn't be touched... So there needs to be another way to distinguish between these two states. (I couldn't find any documentation about reg_accessed[], which to me seems to indicate both "register can be accessed" and later "register value is cached" - which really are two different things and I wonder whether they should be kept apart?) Assuming that when first initialized, all cache registers are set to 0x0000, which is also a valid volume setting, I could probably test for a non-zero value in AC97_VENDOR_ID1, which would mean I've already done the initial writing to the cache and it's a resume; otherwise all registers are to be written. > Additionally, we may use a static resolution table to skip the volume > resolution detection with the latest ac97_codec. I couldn't find any indication of that in 1.0.11rc3. Can you give me a hint? Florian [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-13 14:55 ` Florian Schlichting @ 2006-03-13 15:50 ` Takashi Iwai 2006-03-14 19:59 ` Florian Schlichting 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2006-03-13 15:50 UTC (permalink / raw) To: Florian Schlichting; +Cc: alsa-devel At Mon, 13 Mar 2006 22:55:34 +0800, Florian Schlichting wrote: > > On Mon, Mar 13, 2006 at 12:58:46PM +0100, Takashi Iwai wrote: > > > > The writes in snd_nm256_ac97_reset() break the PM resume. You should > > check reg_accessed[] and use the cached value if already written. > > Yes, I just noticed the broken PM resume... The following is just to > check that I don't misunderstand things: > > I originally wanted to write the initial values in snd_nm256_mixer(), > but there ac97 is still an ac97_template_t and doesn't have a register > cache. Still, reg_accessed[] is set there, meaning "register may be > touched". Consequently, in snd_nm256_ac97_reset() all usable > reg_accessed[] are already set, which the first time means nothing (and > all registers should be written), but during a resume means the value > shouldn't be touched... So there needs to be another way to distinguish > between these two states. > > (I couldn't find any documentation about reg_accessed[], which to me > seems to indicate both "register can be accessed" and later "register > value is cached" - which really are two different things and I wonder > whether they should be kept apart?) Well, practically this check is used only by NM256, so it's OK to change that interface. IMO, we can implement the filtering more cleanly in the accessor side, i.e. filtering the register in snd_nm256_ac97_read/write. In that way, we can clean up ac97_code.c, too. How about the patch below? (It's only for CVS version) > Assuming that when first initialized, all cache registers are set to > 0x0000, which is also a valid volume setting, I could probably test for > a non-zero value in AC97_VENDOR_ID1, which would mean I've already done > the initial writing to the cache and it's a resume; otherwise all > registers are to be written. > > > Additionally, we may use a static resolution table to skip the volume > > resolution detection with the latest ac97_codec. > > I couldn't find any indication of that in 1.0.11rc3. Can you give me a > hint? It's newly added in the CVS version. Look at ac97_patch.c:patch_lm4550() Takashi Index: alsa-kernel/include/ac97_codec.h =================================================================== RCS file: /home/iwai/cvs/alsa/alsa-kernel/include/ac97_codec.h,v retrieving revision 1.75 diff -u -r1.75 ac97_codec.h --- alsa-kernel/include/ac97_codec.h 9 Feb 2006 11:43:01 -0000 1.75 +++ alsa-kernel/include/ac97_codec.h 13 Mar 2006 15:49:22 -0000 @@ -433,6 +433,12 @@ struct snd_info_entry *proc; }; +/* static resolution table */ +struct snd_ac97_res_table { + unsigned short reg; /* register */ + unsigned short bits; /* resolution bitmask */ +}; + struct snd_ac97_template { void *private_data; void (*private_free) (struct snd_ac97 *ac97); @@ -440,14 +446,7 @@ unsigned short num; /* number of codec: 0 = primary, 1 = secondary */ unsigned short addr; /* physical address of codec [0-3] */ unsigned int scaps; /* driver capabilities */ - unsigned int limited_regs; /* allow limited registers only */ - DECLARE_BITMAP(reg_accessed, 0x80); /* bit flags */ -}; - -/* static resolution table */ -struct snd_ac97_res_table { - unsigned short reg; /* register */ - unsigned short bits; /* resolution bitmask */ + const struct snd_ac97_res_table *res_table; /* static resolution */ }; struct snd_ac97 { @@ -476,7 +475,6 @@ unsigned int rates[6]; /* see AC97_RATES_* defines */ unsigned int spdif_status; unsigned short regs[0x80]; /* register cache */ - unsigned int limited_regs; /* allow limited registers only */ DECLARE_BITMAP(reg_accessed, 0x80); /* bit flags */ union { /* vendor specific code */ struct { Index: alsa-kernel/pci/ac97/ac97_codec.c =================================================================== RCS file: /home/iwai/cvs/alsa/alsa-kernel/pci/ac97/ac97_codec.c,v retrieving revision 1.202 diff -u -r1.202 ac97_codec.c --- alsa-kernel/pci/ac97/ac97_codec.c 9 Feb 2006 11:46:47 -0000 1.202 +++ alsa-kernel/pci/ac97/ac97_codec.c 13 Mar 2006 15:49:22 -0000 @@ -192,9 +192,6 @@ static int snd_ac97_valid_reg(struct snd_ac97 *ac97, unsigned short reg) { - if (ac97->limited_regs && ! test_bit(reg, ac97->reg_accessed)) - return 0; - /* filter some registers for buggy codecs */ switch (ac97->id) { case AC97_ID_AK4540: @@ -1008,9 +1005,6 @@ break; } - if (ac97->limited_regs && test_bit(reg, ac97->reg_accessed)) - return 1; /* allow without check */ - val = snd_ac97_read(ac97, reg); if (!(val & mask)) { /* nothing seems to be here - mute flag is not set */ @@ -1866,8 +1860,7 @@ ac97->num = template->num; ac97->addr = template->addr; ac97->scaps = template->scaps; - ac97->limited_regs = template->limited_regs; - memcpy(ac97->reg_accessed, template->reg_accessed, sizeof(ac97->reg_accessed)); + ac97->res_table = template->res_table; bus->codec[ac97->num] = ac97; mutex_init(&ac97->reg_mutex); mutex_init(&ac97->page_mutex); Index: alsa-kernel/pci/nm256/nm256.c =================================================================== RCS file: /home/iwai/cvs/alsa/alsa-kernel/pci/nm256/nm256.c,v retrieving revision 1.81 diff -u -r1.81 nm256.c --- alsa-kernel/pci/nm256/nm256.c 16 Jan 2006 16:40:06 -0000 1.81 +++ alsa-kernel/pci/nm256/nm256.c 13 Mar 2006 15:49:22 -0000 @@ -228,6 +228,7 @@ unsigned int use_cache: 1; /* use one big coef. table */ unsigned int reset_workaround: 1; /* Workaround for some laptops to avoid freeze */ unsigned int reset_workaround_2: 1; /* Extended workaround for some other laptops to avoid freeze */ + unsigned int in_resume: 1; int mixer_base; /* register offset of ac97 mixer */ int mixer_status_offset; /* offset of mixer status reg. */ @@ -242,6 +243,7 @@ struct nm256_stream streams[2]; struct snd_ac97 *ac97; + DECLARE_BITMAP(allowed_regs, 128); struct snd_pcm *pcm; @@ -1154,22 +1156,17 @@ } /* + * some nm256 easily crash when reading from mixer registers + * thus we're caching both read and written values for reading */ static unsigned short snd_nm256_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { struct nm256 *chip = ac97->private_data; - int res; - if (reg >= 128) + if (! test_bit(reg, chip->allowed_regs)) return 0; - - if (! snd_nm256_ac97_ready(chip)) - return 0; - res = snd_nm256_readw(chip, chip->mixer_base + reg); - /* Magic delay. Bleah yucky. */ - msleep(1); - return res; + return ac97->regs[reg]; } /* @@ -1182,6 +1179,9 @@ int tries = 2; u32 base; + if (! test_bit(reg, chip->allowed_regs)) + return; + base = chip->mixer_base; snd_nm256_ac97_ready(chip); @@ -1190,12 +1190,71 @@ while (tries-- > 0) { snd_nm256_writew(chip, base + reg, val); msleep(1); /* a little delay here seems better.. */ - if (snd_nm256_ac97_ready(chip)) + if (snd_nm256_ac97_ready(chip)) { + /* successful write: set cache */ + ac97->regs[reg] = val; return; + } } snd_printd("nm256: ac97 codec not ready..\n"); } +/* + * below copied from OSS driver + * this list could perhaps be fused with mixer_regs[] ?? + * + * Initial register values to be written to the AC97 mixer. + * While most of these are identical to the reset values, we do this + * so that we have most of the register contents cached--this avoids + * reading from the mixer directly (which seems to be problematic, + * probably due to ignorance). + */ + +struct initialValues +{ + unsigned short reg; + unsigned short value; +}; + +static struct initialValues nm256_ac97_init_val[] = +{ + { AC97_MASTER, 0x8000 }, + { AC97_HEADPHONE, 0x8000 }, + { AC97_MASTER_MONO, 0x8000 }, + { AC97_PC_BEEP, 0x8000 }, + { AC97_PHONE, 0x8008 }, + { AC97_MIC, 0x8000 }, + { AC97_LINE, 0x8808 }, + { AC97_CD, 0x8808 }, + { AC97_VIDEO, 0x8808 }, + { AC97_AUX, 0x8808 }, + { AC97_PCM, 0x8808 }, + { AC97_REC_SEL, 0x0000 }, + { AC97_REC_GAIN, 0x0B0B }, + { AC97_GENERAL_PURPOSE, 0x0000 }, + { AC97_3D_CONTROL, 0x8000 }, + { AC97_VENDOR_ID1, 0x8384 }, + { AC97_VENDOR_ID2, 0x7609 }, + { 0xffff, 0xffff } +}; + +/* static resolution table */ +static struct snd_ac97_res_table nm256_res_table[] = { + { AC97_MASTER, 0x1f1f }, + { AC97_HEADPHONE, 0x1f1f }, + { AC97_MASTER_MONO, 0x001f }, + { AC97_PC_BEEP, 0x001f }, + { AC97_PHONE, 0x001f }, + { AC97_MIC, 0x001f }, + { AC97_LINE, 0x1f1f }, + { AC97_CD, 0x1f1f }, + { AC97_VIDEO, 0x1f1f }, + { AC97_AUX, 0x1f1f }, + { AC97_PCM, 0x1f1f }, + { AC97_REC_GAIN, 0x0f0f }, + { } /* terminator */ +}; + /* initialize the ac97 into a known state */ static void snd_nm256_ac97_reset(struct snd_ac97 *ac97) @@ -1213,6 +1272,16 @@ snd_nm256_writeb(chip, 0x6cc, 0x80); snd_nm256_writeb(chip, 0x6cc, 0x0); } + if (! chip->in_resume) { + struct initialValues *x; + for (x = nm256_ac97_init_val; x->reg != 0xffff; x++) { + /* preload the cache, so as to avoid even a single + * read of the mixer regs + */ + set_bit(x->reg, chip->allowed_regs); + snd_nm256_ac97_write(ac97, x->reg, x->value); + } + } } /* create an ac97 mixer interface */ @@ -1221,32 +1290,20 @@ { struct snd_ac97_bus *pbus; struct snd_ac97_template ac97; - int i, err; + int err; static struct snd_ac97_bus_ops ops = { .reset = snd_nm256_ac97_reset, .write = snd_nm256_ac97_write, .read = snd_nm256_ac97_read, }; - /* looks like nm256 hangs up when unexpected registers are touched... */ - static int mixer_regs[] = { - AC97_MASTER, AC97_HEADPHONE, AC97_MASTER_MONO, - AC97_PC_BEEP, AC97_PHONE, AC97_MIC, AC97_LINE, AC97_CD, - AC97_VIDEO, AC97_AUX, AC97_PCM, AC97_REC_SEL, - AC97_REC_GAIN, AC97_GENERAL_PURPOSE, AC97_3D_CONTROL, - /*AC97_EXTENDED_ID,*/ - AC97_VENDOR_ID1, AC97_VENDOR_ID2, - -1 - }; if ((err = snd_ac97_bus(chip->card, 0, &ops, NULL, &pbus)) < 0) return err; memset(&ac97, 0, sizeof(ac97)); ac97.scaps = AC97_SCAP_AUDIO; /* we support audio! */ - ac97.limited_regs = 1; - for (i = 0; mixer_regs[i] >= 0; i++) - set_bit(mixer_regs[i], ac97.reg_accessed); ac97.private_data = chip; + ac97.res_table = nm256_res_table; pbus->no_vra = 1; err = snd_ac97_mixer(pbus, &ac97, &chip->ac97); if (err < 0) @@ -1331,6 +1388,7 @@ int i; /* Perform a full reset on the hardware */ + chip->in_resume = 1; pci_restore_state(pci); pci_enable_device(pci); snd_nm256_init_chip(chip); @@ -1348,6 +1406,7 @@ } snd_power_change_state(card, SNDRV_CTL_POWER_D0); + chip->in_resume = 0; return 0; } #endif /* CONFIG_PM */ ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-13 15:50 ` Takashi Iwai @ 2006-03-14 19:59 ` Florian Schlichting 2006-03-14 20:16 ` Takashi Iwai 0 siblings, 1 reply; 14+ messages in thread From: Florian Schlichting @ 2006-03-14 19:59 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1: Type: text/plain, Size: 2191 bytes --] On Mon, Mar 13, 2006 at 04:50:31PM +0100, Takashi Iwai wrote: > How about the patch below? (It's only for CVS version) very good. It makes the larger changes that I didn't dare to think of for lack of insight. There's just another tiny cosmetical change, to the comments: --- nm256.c.orig 2006-03-15 00:50:55.000000000 +0800 +++ nm256.c 2006-03-15 00:59:28.000000000 +0800 @@ -1157,7 +1157,8 @@ /* * some nm256 easily crash when reading from mixer registers - * thus we're caching both read and written values for reading + * thus we're treating it as a write-only mixer and cache the + * written values */ static unsigned short snd_nm256_ac97_read(struct snd_ac97 *ac97, unsigned short reg) @@ -1200,9 +1201,6 @@ } /* - * below copied from OSS driver - * this list could perhaps be fused with mixer_regs[] ?? - * * Initial register values to be written to the AC97 mixer. * While most of these are identical to the reset values, we do this * so that we have most of the register contents cached--this avoids NB: while trying to compile from CVS with ./cvscompile [...] ----------- patching file usbaudio.c Hunk #2 FAILED at 70. ----------- Running the command again it aparently ignored this problem Also, there are some warnings during compile and a problem with depmod loops at install ---------- Building modules, stage 2. MODPOST *** Warning: "snd_minor_info_oss_init" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! *** Warning: "snd_lookup_oss_minor_data" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! *** Warning: "snd_info_minor_unregister" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! *** Warning: "snd_minor_info_oss_done" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! *** Warning: "snd_info_minor_register" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! [...] WARNING: Loop detected: /lib/modules/2.6.15-max/kernel/sound/acore/snd.ko which needs snd.ko again! ---------- (and the rest of the ALSA modules is ignored), so although I could build things, it wouldn't "make install" and I can't make a final smoke test :-( Florian [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-14 19:59 ` Florian Schlichting @ 2006-03-14 20:16 ` Takashi Iwai 2006-03-15 6:09 ` Florian Schlichting 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2006-03-14 20:16 UTC (permalink / raw) To: Florian Schlichting; +Cc: alsa-devel At Wed, 15 Mar 2006 03:59:46 +0800, Florian Schlichting wrote: > > On Mon, Mar 13, 2006 at 04:50:31PM +0100, Takashi Iwai wrote: > > How about the patch below? (It's only for CVS version) > > very good. It makes the larger changes that I didn't dare to think of > for lack of insight. > > There's just another tiny cosmetical change, to the comments: > > --- nm256.c.orig 2006-03-15 00:50:55.000000000 +0800 > +++ nm256.c 2006-03-15 00:59:28.000000000 +0800 > @@ -1157,7 +1157,8 @@ > > /* > * some nm256 easily crash when reading from mixer registers > - * thus we're caching both read and written values for reading > + * thus we're treating it as a write-only mixer and cache the > + * written values > */ > static unsigned short > snd_nm256_ac97_read(struct snd_ac97 *ac97, unsigned short reg) > @@ -1200,9 +1201,6 @@ > } > > /* > - * below copied from OSS driver > - * this list could perhaps be fused with mixer_regs[] ?? > - * > * Initial register values to be written to the AC97 mixer. > * While most of these are identical to the reset values, we do this > * so that we have most of the register contents cached--this avoids Looks fine. I'll fix them. > NB: while trying to compile from CVS with ./cvscompile [...] > ----------- > patching file usbaudio.c > Hunk #2 FAILED at 70. Oops, forgot to commit. Fixed now. > ----------- > Running the command again it aparently ignored this problem > > Also, there are some warnings during compile and a problem with depmod > loops at install > ---------- > Building modules, stage 2. > MODPOST > *** Warning: "snd_minor_info_oss_init" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > *** Warning: "snd_lookup_oss_minor_data" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > *** Warning: "snd_info_minor_unregister" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > *** Warning: "snd_minor_info_oss_done" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > *** Warning: "snd_info_minor_register" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > [...] > > WARNING: Loop detected: > /lib/modules/2.6.15-max/kernel/sound/acore/snd.ko which needs snd.ko > again! > ---------- > (and the rest of the ALSA modules is ignored), so although I could > build things, it wouldn't "make install" and I can't make a final smoke > test :-( Hm, it sounds like CONFIG_PROC_FS isn't defined properly. Please check alsa-driver/include/linux/autoconf.h. It's generated by configure script. Takashi ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-14 20:16 ` Takashi Iwai @ 2006-03-15 6:09 ` Florian Schlichting 2006-03-15 9:55 ` Takashi Iwai 0 siblings, 1 reply; 14+ messages in thread From: Florian Schlichting @ 2006-03-15 6:09 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1: Type: text/plain, Size: 2510 bytes --] On Tue, Mar 14, 2006 at 09:16:28PM +0100, Takashi Iwai wrote: > At Wed, 15 Mar 2006 03:59:46 +0800, > Florian Schlichting wrote: > > Also, there are some warnings during compile and a problem with depmod > > loops at install > > ---------- > > Building modules, stage 2. > > MODPOST > > *** Warning: "snd_minor_info_oss_init" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > *** Warning: "snd_lookup_oss_minor_data" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > *** Warning: "snd_info_minor_unregister" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > *** Warning: "snd_minor_info_oss_done" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > *** Warning: "snd_info_minor_register" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > [...] > > > > WARNING: Loop detected: > > /lib/modules/2.6.15-max/kernel/sound/acore/snd.ko which needs snd.ko > > again! > > ---------- > > (and the rest of the ALSA modules is ignored), so although I could > > build things, it wouldn't "make install" and I can't make a final smoke > > test :-( > > Hm, it sounds like CONFIG_PROC_FS isn't defined properly. > Please check alsa-driver/include/linux/autoconf.h. It's generated by > configure script. hmmm... do you mean this: #define CONFIG_ACPI_SLEEP_PROC_FS 1 #undef CONFIG_ACPI_SLEEP_PROC_SLEEP [...] #undef CONFIG_PCI_LEGACY_PROC [...] #define CONFIG_SCSI_PROC_FS 1 [...] #define CONFIG_PROC_FS 1 #define CONFIG_PROC_KCORE 1 [...] #define CONFIG_SND_VERBOSE_PROCFS 1 -.- I noticed the errors said something with oss. My compile commmand line was './cvscompile --with-isapnp=no --with-sequencer=no --with-oss=no --with-cards=nm256' and that still gives the above errors. I just recompiled with just './cvscompile --with-cards=nm256' and there are no errors, depmod runs fine, I can insert the module... perfect! The mixer settings also survive a suspend, apart from Master Volume which becomes muted (but I guess that's intented? I can't confirm bug#1532) Thus, are we done fixing an issue that has bugged poor nm256 owners for years?? bug#328, bug#914 and kbug#3719 look like their submitters/contributors might be interested in giving it a try... Summary: treat the nm256 mixer as a write-only device so as to avoid hangs on initialisation (fixes: bug#....[when confirmed]) and clean up an older workaround in ac97_codec Signed-off-by: Florian Schlichting <Florian.Schlichting@gmx.de> [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-15 6:09 ` Florian Schlichting @ 2006-03-15 9:55 ` Takashi Iwai 2006-03-15 13:23 ` Florian Schlichting 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2006-03-15 9:55 UTC (permalink / raw) To: Florian Schlichting; +Cc: alsa-devel At Wed, 15 Mar 2006 14:09:22 +0800, Florian Schlichting wrote: > > On Tue, Mar 14, 2006 at 09:16:28PM +0100, Takashi Iwai wrote: > > At Wed, 15 Mar 2006 03:59:46 +0800, > > Florian Schlichting wrote: > > > Also, there are some warnings during compile and a problem with depmod > > > loops at install > > > ---------- > > > Building modules, stage 2. > > > MODPOST > > > *** Warning: "snd_minor_info_oss_init" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > *** Warning: "snd_lookup_oss_minor_data" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > *** Warning: "snd_info_minor_unregister" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > *** Warning: "snd_minor_info_oss_done" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > *** Warning: "snd_info_minor_register" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > > > [...] > > > > > > WARNING: Loop detected: > > > /lib/modules/2.6.15-max/kernel/sound/acore/snd.ko which needs snd.ko > > > again! > > > ---------- > > > (and the rest of the ALSA modules is ignored), so although I could > > > build things, it wouldn't "make install" and I can't make a final smoke > > > test :-( > > > > Hm, it sounds like CONFIG_PROC_FS isn't defined properly. > > Please check alsa-driver/include/linux/autoconf.h. It's generated by > > configure script. > > hmmm... do you mean this: > > #define CONFIG_ACPI_SLEEP_PROC_FS 1 > #undef CONFIG_ACPI_SLEEP_PROC_SLEEP > [...] > #undef CONFIG_PCI_LEGACY_PROC > [...] > #define CONFIG_SCSI_PROC_FS 1 > [...] > #define CONFIG_PROC_FS 1 > #define CONFIG_PROC_KCORE 1 > [...] > #define CONFIG_SND_VERBOSE_PROCFS 1 > > -.- > > I noticed the errors said something with oss. My compile commmand line > was './cvscompile --with-isapnp=no --with-sequencer=no --with-oss=no > --with-cards=nm256' and that still gives the above errors. I just > recompiled with just './cvscompile --with-cards=nm256' and there are no > errors, depmod runs fine, I can insert the module... perfect! Then something conflicts. Could you check CONFIG_SND_OSSEMUL in autoconfig.h? > The mixer > settings also survive a suspend, apart from Master Volume which becomes > muted (but I guess that's intented? I can't confirm bug#1532) Hm, no, it's not intended. I think this is the side effect of using ac97->regs[]. The ac97 codec routine mutes the master volume to avoid noise at suspend, and resumes it with the cache value. Please try the newer patch below. > Thus, are we done fixing an issue that has bugged poor nm256 owners for > years?? bug#328, bug#914 and kbug#3719 look like their > submitters/contributors might be interested in giving it a try... > > Summary: treat the nm256 mixer as a write-only device so as to avoid > hangs on initialisation (fixes: bug#....[when confirmed]) and clean up > an older workaround in ac97_codec > Signed-off-by: Florian Schlichting <Florian.Schlichting@gmx.de> Thanks, I'll apply the patch once after you confirm the newer one. Takashi Index: alsa-kernel/include/ac97_codec.h =================================================================== RCS file: /home/iwai/cvs/alsa/alsa-kernel/include/ac97_codec.h,v retrieving revision 1.75 diff -u -r1.75 ac97_codec.h --- alsa-kernel/include/ac97_codec.h 9 Feb 2006 11:43:01 -0000 1.75 +++ alsa-kernel/include/ac97_codec.h 15 Mar 2006 09:54:37 -0000 @@ -433,6 +433,12 @@ struct snd_info_entry *proc; }; +/* static resolution table */ +struct snd_ac97_res_table { + unsigned short reg; /* register */ + unsigned short bits; /* resolution bitmask */ +}; + struct snd_ac97_template { void *private_data; void (*private_free) (struct snd_ac97 *ac97); @@ -440,14 +446,7 @@ unsigned short num; /* number of codec: 0 = primary, 1 = secondary */ unsigned short addr; /* physical address of codec [0-3] */ unsigned int scaps; /* driver capabilities */ - unsigned int limited_regs; /* allow limited registers only */ - DECLARE_BITMAP(reg_accessed, 0x80); /* bit flags */ -}; - -/* static resolution table */ -struct snd_ac97_res_table { - unsigned short reg; /* register */ - unsigned short bits; /* resolution bitmask */ + const struct snd_ac97_res_table *res_table; /* static resolution */ }; struct snd_ac97 { @@ -476,7 +475,6 @@ unsigned int rates[6]; /* see AC97_RATES_* defines */ unsigned int spdif_status; unsigned short regs[0x80]; /* register cache */ - unsigned int limited_regs; /* allow limited registers only */ DECLARE_BITMAP(reg_accessed, 0x80); /* bit flags */ union { /* vendor specific code */ struct { Index: alsa-kernel/pci/ac97/ac97_codec.c =================================================================== RCS file: /home/iwai/cvs/alsa/alsa-kernel/pci/ac97/ac97_codec.c,v retrieving revision 1.202 diff -u -r1.202 ac97_codec.c --- alsa-kernel/pci/ac97/ac97_codec.c 9 Feb 2006 11:46:47 -0000 1.202 +++ alsa-kernel/pci/ac97/ac97_codec.c 15 Mar 2006 09:54:37 -0000 @@ -192,9 +192,6 @@ static int snd_ac97_valid_reg(struct snd_ac97 *ac97, unsigned short reg) { - if (ac97->limited_regs && ! test_bit(reg, ac97->reg_accessed)) - return 0; - /* filter some registers for buggy codecs */ switch (ac97->id) { case AC97_ID_AK4540: @@ -1008,9 +1005,6 @@ break; } - if (ac97->limited_regs && test_bit(reg, ac97->reg_accessed)) - return 1; /* allow without check */ - val = snd_ac97_read(ac97, reg); if (!(val & mask)) { /* nothing seems to be here - mute flag is not set */ @@ -1866,8 +1860,7 @@ ac97->num = template->num; ac97->addr = template->addr; ac97->scaps = template->scaps; - ac97->limited_regs = template->limited_regs; - memcpy(ac97->reg_accessed, template->reg_accessed, sizeof(ac97->reg_accessed)); + ac97->res_table = template->res_table; bus->codec[ac97->num] = ac97; mutex_init(&ac97->reg_mutex); mutex_init(&ac97->page_mutex); Index: alsa-kernel/pci/nm256/nm256.c =================================================================== RCS file: /home/iwai/cvs/alsa/alsa-kernel/pci/nm256/nm256.c,v retrieving revision 1.81 diff -u -r1.81 nm256.c --- alsa-kernel/pci/nm256/nm256.c 16 Jan 2006 16:40:06 -0000 1.81 +++ alsa-kernel/pci/nm256/nm256.c 15 Mar 2006 09:54:37 -0000 @@ -228,6 +228,7 @@ unsigned int use_cache: 1; /* use one big coef. table */ unsigned int reset_workaround: 1; /* Workaround for some laptops to avoid freeze */ unsigned int reset_workaround_2: 1; /* Extended workaround for some other laptops to avoid freeze */ + unsigned int in_resume: 1; int mixer_base; /* register offset of ac97 mixer */ int mixer_status_offset; /* offset of mixer status reg. */ @@ -242,6 +243,7 @@ struct nm256_stream streams[2]; struct snd_ac97 *ac97; + unsigned short *ac97_regs; /* register caches, only for valid regs */ struct snd_pcm *pcm; @@ -1153,23 +1155,63 @@ return 0; } +/* + * Initial register values to be written to the AC97 mixer. + * While most of these are identical to the reset values, we do this + * so that we have most of the register contents cached--this avoids + * reading from the mixer directly (which seems to be problematic, + * probably due to ignorance). + */ + +struct initialValues { + unsigned short reg; + unsigned short value; +}; + +static struct initialValues nm256_ac97_init_val[] = +{ + { AC97_MASTER, 0x8000 }, + { AC97_HEADPHONE, 0x8000 }, + { AC97_MASTER_MONO, 0x8000 }, + { AC97_PC_BEEP, 0x8000 }, + { AC97_PHONE, 0x8008 }, + { AC97_MIC, 0x8000 }, + { AC97_LINE, 0x8808 }, + { AC97_CD, 0x8808 }, + { AC97_VIDEO, 0x8808 }, + { AC97_AUX, 0x8808 }, + { AC97_PCM, 0x8808 }, + { AC97_REC_SEL, 0x0000 }, + { AC97_REC_GAIN, 0x0B0B }, + { AC97_GENERAL_PURPOSE, 0x0000 }, + { AC97_3D_CONTROL, 0x8000 }, + { AC97_VENDOR_ID1, 0x8384 }, + { AC97_VENDOR_ID2, 0x7609 }, +}; + +static int nm256_ac97_idx(unsigned short reg) +{ + int i; + for (i = 0; i < ARRAY_SIZE(nm256_ac97_init_val); i++) + if (nm256_ac97_init_val[i].reg == reg) + return i; + return -1; +} + /* + * some nm256 easily crash when reading from mixer registers + * thus we're treating it as a write-only mixer and cache the + * written values */ static unsigned short snd_nm256_ac97_read(struct snd_ac97 *ac97, unsigned short reg) { struct nm256 *chip = ac97->private_data; - int res; - - if (reg >= 128) - return 0; + int idx = nm256_ac97_idx(reg); - if (! snd_nm256_ac97_ready(chip)) + if (idx < 0) return 0; - res = snd_nm256_readw(chip, chip->mixer_base + reg); - /* Magic delay. Bleah yucky. */ - msleep(1); - return res; + return chip->ac97_regs[idx]; } /* @@ -1180,8 +1222,12 @@ { struct nm256 *chip = ac97->private_data; int tries = 2; + int idx = nm256_ac97_idx(reg); u32 base; + if (idx < 0) + return; + base = chip->mixer_base; snd_nm256_ac97_ready(chip); @@ -1190,12 +1236,32 @@ while (tries-- > 0) { snd_nm256_writew(chip, base + reg, val); msleep(1); /* a little delay here seems better.. */ - if (snd_nm256_ac97_ready(chip)) + if (snd_nm256_ac97_ready(chip)) { + /* successful write: set cache */ + chip->ac97_regs[idx] = val; return; + } } snd_printd("nm256: ac97 codec not ready..\n"); } +/* static resolution table */ +static struct snd_ac97_res_table nm256_res_table[] = { + { AC97_MASTER, 0x1f1f }, + { AC97_HEADPHONE, 0x1f1f }, + { AC97_MASTER_MONO, 0x001f }, + { AC97_PC_BEEP, 0x001f }, + { AC97_PHONE, 0x001f }, + { AC97_MIC, 0x001f }, + { AC97_LINE, 0x1f1f }, + { AC97_CD, 0x1f1f }, + { AC97_VIDEO, 0x1f1f }, + { AC97_AUX, 0x1f1f }, + { AC97_PCM, 0x1f1f }, + { AC97_REC_GAIN, 0x0f0f }, + { } /* terminator */ +}; + /* initialize the ac97 into a known state */ static void snd_nm256_ac97_reset(struct snd_ac97 *ac97) @@ -1213,6 +1279,16 @@ snd_nm256_writeb(chip, 0x6cc, 0x80); snd_nm256_writeb(chip, 0x6cc, 0x0); } + if (! chip->in_resume) { + int i; + for (i = 0; i < ARRAY_SIZE(nm256_ac97_init_val); i++) { + /* preload the cache, so as to avoid even a single + * read of the mixer regs + */ + snd_nm256_ac97_write(ac97, nm256_ac97_init_val[i].reg, + nm256_ac97_init_val[i].value); + } + } } /* create an ac97 mixer interface */ @@ -1221,32 +1297,25 @@ { struct snd_ac97_bus *pbus; struct snd_ac97_template ac97; - int i, err; + int err; static struct snd_ac97_bus_ops ops = { .reset = snd_nm256_ac97_reset, .write = snd_nm256_ac97_write, .read = snd_nm256_ac97_read, }; - /* looks like nm256 hangs up when unexpected registers are touched... */ - static int mixer_regs[] = { - AC97_MASTER, AC97_HEADPHONE, AC97_MASTER_MONO, - AC97_PC_BEEP, AC97_PHONE, AC97_MIC, AC97_LINE, AC97_CD, - AC97_VIDEO, AC97_AUX, AC97_PCM, AC97_REC_SEL, - AC97_REC_GAIN, AC97_GENERAL_PURPOSE, AC97_3D_CONTROL, - /*AC97_EXTENDED_ID,*/ - AC97_VENDOR_ID1, AC97_VENDOR_ID2, - -1 - }; + + chip->ac97_regs = kcalloc(sizeof(short), + ARRAY_SIZE(nm256_ac97_init_val), GFP_KERNEL); + if (! chip->ac97_regs) + return -ENOMEM; if ((err = snd_ac97_bus(chip->card, 0, &ops, NULL, &pbus)) < 0) return err; memset(&ac97, 0, sizeof(ac97)); ac97.scaps = AC97_SCAP_AUDIO; /* we support audio! */ - ac97.limited_regs = 1; - for (i = 0; mixer_regs[i] >= 0; i++) - set_bit(mixer_regs[i], ac97.reg_accessed); ac97.private_data = chip; + ac97.res_table = nm256_res_table; pbus->no_vra = 1; err = snd_ac97_mixer(pbus, &ac97, &chip->ac97); if (err < 0) @@ -1331,6 +1400,7 @@ int i; /* Perform a full reset on the hardware */ + chip->in_resume = 1; pci_restore_state(pci); pci_enable_device(pci); snd_nm256_init_chip(chip); @@ -1348,6 +1418,7 @@ } snd_power_change_state(card, SNDRV_CTL_POWER_D0); + chip->in_resume = 0; return 0; } #endif /* CONFIG_PM */ @@ -1372,6 +1443,7 @@ free_irq(chip->irq, chip); pci_disable_device(chip->pci); + kfree(chip->ac97_regs); kfree(chip); return 0; } ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-15 9:55 ` Takashi Iwai @ 2006-03-15 13:23 ` Florian Schlichting 2006-03-15 15:42 ` Takashi Iwai 0 siblings, 1 reply; 14+ messages in thread From: Florian Schlichting @ 2006-03-15 13:23 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1.1: Type: text/plain, Size: 3341 bytes --] On Wed, Mar 15, 2006 at 10:55:36AM +0100, Takashi Iwai wrote: > At Wed, 15 Mar 2006 14:09:22 +0800, > Florian Schlichting wrote: > > > > On Tue, Mar 14, 2006 at 09:16:28PM +0100, Takashi Iwai wrote: > > > At Wed, 15 Mar 2006 03:59:46 +0800, > > > Florian Schlichting wrote: > > > > Also, there are some warnings during compile and a problem with depmod > > > > loops at install > > > > ---------- > > > > Building modules, stage 2. > > > > MODPOST > > > > *** Warning: "snd_minor_info_oss_init" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > *** Warning: "snd_lookup_oss_minor_data" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > *** Warning: "snd_info_minor_unregister" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > *** Warning: "snd_minor_info_oss_done" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > *** Warning: "snd_info_minor_register" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > > > > > [...] > > > > > > > > WARNING: Loop detected: > > > > /lib/modules/2.6.15-max/kernel/sound/acore/snd.ko which needs snd.ko > > > > again! > > > > ---------- > > > > (and the rest of the ALSA modules is ignored), so although I could > > > > build things, it wouldn't "make install" and I can't make a final smoke > > > > test :-( > > > > > > Hm, it sounds like CONFIG_PROC_FS isn't defined properly. > > > Please check alsa-driver/include/linux/autoconf.h. It's generated by > > > configure script. > > > > hmmm... do you mean this: > > > > #define CONFIG_ACPI_SLEEP_PROC_FS 1 > > #undef CONFIG_ACPI_SLEEP_PROC_SLEEP > > [...] > > #undef CONFIG_PCI_LEGACY_PROC > > [...] > > #define CONFIG_SCSI_PROC_FS 1 > > [...] > > #define CONFIG_PROC_FS 1 > > #define CONFIG_PROC_KCORE 1 > > [...] > > #define CONFIG_SND_VERBOSE_PROCFS 1 > > > > -.- > > > > I noticed the errors said something with oss. My compile commmand line > > was './cvscompile --with-isapnp=no --with-sequencer=no --with-oss=no > > --with-cards=nm256' and that still gives the above errors. I just > > recompiled with just './cvscompile --with-cards=nm256' and there are no > > errors, depmod runs fine, I can insert the module... perfect! > > Then something conflicts. Could you check CONFIG_SND_OSSEMUL in > autoconfig.h? I did a few tests with different options, and it's clearly the --with-oss=no that causes the errors during compile and install #define CONFIG_SND_OSSEMUL 1 - with the working options, /* #undef CONFIG_SND_OSSEMUL */ when the errors occur - but it's in there twice, at line 1276 and 1300, in sections "include/autoconf-extra.h." and "include/config1.h"! I'm attaching the whole file for a ./cvscompile --with-cards=nm256 --with-oss=no > > > The mixer > > settings also survive a suspend, apart from Master Volume which becomes > > muted (but I guess that's intented? I can't confirm bug#1532) > > Hm, no, it's not intended. I think this is the side effect of using > ac97->regs[]. The ac97 codec routine mutes the master volume to avoid > noise at suspend, and resumes it with the cache value. > > Please try the newer patch below. I've tried it, it works well and all the registers including Master Volume are restored to their pre-suspend values. Florian [-- Attachment #1.2: autoconf.h --] [-- Type: text/x-chdr, Size: 33597 bytes --] /* * Automatically generated C config: don't edit * Linux kernel version: 2.6.15-max * Mon Mar 13 12:41:33 2006 */ #define AUTOCONF_INCLUDED #define CONFIG_X86_32 1 #define CONFIG_SEMAPHORE_SLEEPERS 1 #define CONFIG_X86 1 #define CONFIG_MMU 1 #define CONFIG_UID16 1 #define CONFIG_GENERIC_ISA_DMA 1 #define CONFIG_GENERIC_IOMAP 1 #define CONFIG_ARCH_MAY_HAVE_PC_FDC 1 /* * Code maturity level options */ #define CONFIG_EXPERIMENTAL 1 #define CONFIG_CLEAN_COMPILE 1 #define CONFIG_BROKEN_ON_SMP 1 #define CONFIG_LOCK_KERNEL 1 #define CONFIG_INIT_ENV_ARG_LIMIT 32 /* * General setup */ #define CONFIG_LOCALVERSION "" #define CONFIG_LOCALVERSION_AUTO 1 #define CONFIG_SWAP 1 #define CONFIG_SYSVIPC 1 #undef CONFIG_POSIX_MQUEUE #define CONFIG_BSD_PROCESS_ACCT 1 #undef CONFIG_BSD_PROCESS_ACCT_V3 #define CONFIG_SYSCTL 1 #undef CONFIG_AUDIT #define CONFIG_HOTPLUG 1 #define CONFIG_KOBJECT_UEVENT 1 #undef CONFIG_IKCONFIG #define CONFIG_INITRAMFS_SOURCE "" #undef CONFIG_CC_OPTIMIZE_FOR_SIZE #undef CONFIG_EMBEDDED #define CONFIG_KALLSYMS 1 #undef CONFIG_KALLSYMS_EXTRA_PASS #define CONFIG_PRINTK 1 #define CONFIG_BUG 1 #define CONFIG_BASE_FULL 1 #define CONFIG_FUTEX 1 #define CONFIG_EPOLL 1 #define CONFIG_SHMEM 1 #define CONFIG_CC_ALIGN_FUNCTIONS 0 #define CONFIG_CC_ALIGN_LABELS 0 #define CONFIG_CC_ALIGN_LOOPS 0 #define CONFIG_CC_ALIGN_JUMPS 0 #undef CONFIG_TINY_SHMEM #define CONFIG_BASE_SMALL 0 /* * Loadable module support */ #define CONFIG_MODULES 1 #define CONFIG_MODULE_UNLOAD 1 #undef CONFIG_MODULE_FORCE_UNLOAD #define CONFIG_OBSOLETE_MODPARM 1 #undef CONFIG_MODVERSIONS #undef CONFIG_MODULE_SRCVERSION_ALL #define CONFIG_KMOD 1 /* * Block layer */ #undef CONFIG_LBD /* * IO Schedulers */ #define CONFIG_IOSCHED_NOOP 1 #define CONFIG_IOSCHED_AS 1 #define CONFIG_IOSCHED_DEADLINE 1 #define CONFIG_IOSCHED_CFQ 1 #define CONFIG_DEFAULT_AS 1 #undef CONFIG_DEFAULT_DEADLINE #undef CONFIG_DEFAULT_CFQ #undef CONFIG_DEFAULT_NOOP #define CONFIG_DEFAULT_IOSCHED "anticipatory" /* * Processor type and features */ #define CONFIG_X86_PC 1 #undef CONFIG_X86_ELAN #undef CONFIG_X86_VOYAGER #undef CONFIG_X86_NUMAQ #undef CONFIG_X86_SUMMIT #undef CONFIG_X86_BIGSMP #undef CONFIG_X86_VISWS #undef CONFIG_X86_GENERICARCH #undef CONFIG_X86_ES7000 #undef CONFIG_M386 #undef CONFIG_M486 #undef CONFIG_M586 #undef CONFIG_M586TSC #undef CONFIG_M586MMX #undef CONFIG_M686 #undef CONFIG_MPENTIUMII #define CONFIG_MPENTIUMIII 1 #undef CONFIG_MPENTIUMM #undef CONFIG_MPENTIUM4 #undef CONFIG_MK6 #undef CONFIG_MK7 #undef CONFIG_MK8 #undef CONFIG_MCRUSOE #undef CONFIG_MEFFICEON #undef CONFIG_MWINCHIPC6 #undef CONFIG_MWINCHIP2 #undef CONFIG_MWINCHIP3D #undef CONFIG_MGEODEGX1 #undef CONFIG_MCYRIXIII #undef CONFIG_MVIAC3_2 #undef CONFIG_X86_GENERIC #define CONFIG_X86_CMPXCHG 1 #define CONFIG_X86_XADD 1 #define CONFIG_X86_L1_CACHE_SHIFT 5 #define CONFIG_RWSEM_XCHGADD_ALGORITHM 1 #define CONFIG_GENERIC_CALIBRATE_DELAY 1 #define CONFIG_X86_WP_WORKS_OK 1 #define CONFIG_X86_INVLPG 1 #define CONFIG_X86_BSWAP 1 #define CONFIG_X86_POPAD_OK 1 #define CONFIG_X86_CMPXCHG64 1 #define CONFIG_X86_GOOD_APIC 1 #define CONFIG_X86_INTEL_USERCOPY 1 #define CONFIG_X86_USE_PPRO_CHECKSUM 1 #define CONFIG_X86_TSC 1 #define CONFIG_HPET_TIMER 1 #define CONFIG_HPET_EMULATE_RTC 1 #undef CONFIG_SMP #undef CONFIG_PREEMPT_NONE #undef CONFIG_PREEMPT_VOLUNTARY #define CONFIG_PREEMPT 1 #define CONFIG_PREEMPT_BKL 1 #undef CONFIG_X86_UP_APIC #define CONFIG_X86_MCE 1 #undef CONFIG_X86_MCE_NONFATAL #undef CONFIG_TOSHIBA #undef CONFIG_I8K #undef CONFIG_X86_REBOOTFIXUPS #undef CONFIG_MICROCODE #undef CONFIG_X86_MSR #undef CONFIG_X86_CPUID /* * Firmware Drivers */ #undef CONFIG_EDD #undef CONFIG_DELL_RBU #undef CONFIG_DCDBAS #define CONFIG_NOHIGHMEM 1 #undef CONFIG_HIGHMEM4G #undef CONFIG_HIGHMEM64G #define CONFIG_SELECT_MEMORY_MODEL 1 #define CONFIG_FLATMEM_MANUAL 1 #undef CONFIG_DISCONTIGMEM_MANUAL #undef CONFIG_SPARSEMEM_MANUAL #define CONFIG_FLATMEM 1 #define CONFIG_FLAT_NODE_MEM_MAP 1 #undef CONFIG_SPARSEMEM_STATIC #define CONFIG_SPLIT_PTLOCK_CPUS 4 #undef CONFIG_MATH_EMULATION #define CONFIG_MTRR 1 #undef CONFIG_EFI #undef CONFIG_REGPARM #define CONFIG_SECCOMP 1 #undef CONFIG_HZ_100 #define CONFIG_HZ_250 1 #undef CONFIG_HZ_1000 #define CONFIG_HZ 250 #define CONFIG_PHYSICAL_START 0x100000 #undef CONFIG_KEXEC /* * Power management options (ACPI, APM) */ #define CONFIG_PM 1 #undef CONFIG_PM_LEGACY #undef CONFIG_PM_DEBUG #define CONFIG_SOFTWARE_SUSPEND 1 #define CONFIG_PM_STD_PARTITION "/dev/hda2" /* * ACPI (Advanced Configuration and Power Interface) Support */ #define CONFIG_ACPI 1 #define CONFIG_ACPI_SLEEP 1 #define CONFIG_ACPI_SLEEP_PROC_FS 1 #undef CONFIG_ACPI_SLEEP_PROC_SLEEP #define CONFIG_ACPI_AC 1 #define CONFIG_ACPI_BATTERY 1 #define CONFIG_ACPI_BUTTON 1 #define CONFIG_ACPI_VIDEO 1 #undef CONFIG_ACPI_HOTKEY #define CONFIG_ACPI_FAN 1 #define CONFIG_ACPI_PROCESSOR 1 #define CONFIG_ACPI_THERMAL 1 #undef CONFIG_ACPI_ASUS #undef CONFIG_ACPI_IBM #undef CONFIG_ACPI_TOSHIBA #define CONFIG_ACPI_BLACKLIST_YEAR 0 #undef CONFIG_ACPI_DEBUG #define CONFIG_ACPI_EC 1 #define CONFIG_ACPI_POWER 1 #define CONFIG_ACPI_SYSTEM 1 #define CONFIG_X86_PM_TIMER 1 #undef CONFIG_ACPI_CONTAINER /* * APM (Advanced Power Management) BIOS Support */ /* * CPU Frequency scaling */ #undef CONFIG_CPU_FREQ /* * Bus options (PCI, PCMCIA, EISA, MCA, ISA) */ #define CONFIG_PCI 1 #undef CONFIG_PCI_GOBIOS #undef CONFIG_PCI_GOMMCONFIG #undef CONFIG_PCI_GODIRECT #define CONFIG_PCI_GOANY 1 #define CONFIG_PCI_BIOS 1 #define CONFIG_PCI_DIRECT 1 #define CONFIG_PCI_MMCONFIG 1 #undef CONFIG_PCIEPORTBUS #undef CONFIG_PCI_LEGACY_PROC #define CONFIG_ISA_DMA_API 1 #undef CONFIG_ISA #undef CONFIG_MCA #undef CONFIG_SCx200 /* * PCCARD (PCMCIA/CardBus) support */ #define CONFIG_PCCARD_MODULE 1 #undef CONFIG_PCMCIA_DEBUG #define CONFIG_PCMCIA_MODULE 1 #define CONFIG_PCMCIA_LOAD_CIS 1 #define CONFIG_PCMCIA_IOCTL 1 #define CONFIG_CARDBUS 1 /* * PC-card bridges */ #define CONFIG_YENTA_MODULE 1 #undef CONFIG_PD6729 #undef CONFIG_I82092 #define CONFIG_PCCARD_NONSTATIC_MODULE 1 /* * PCI Hotplug Support */ #define CONFIG_HOTPLUG_PCI_MODULE 1 #undef CONFIG_HOTPLUG_PCI_FAKE #undef CONFIG_HOTPLUG_PCI_COMPAQ #undef CONFIG_HOTPLUG_PCI_ACPI #undef CONFIG_HOTPLUG_PCI_CPCI #define CONFIG_HOTPLUG_PCI_SHPC_MODULE 1 #undef CONFIG_HOTPLUG_PCI_SHPC_POLL_EVENT_MODE /* * Executable file formats */ #define CONFIG_BINFMT_ELF 1 #undef CONFIG_BINFMT_AOUT #undef CONFIG_BINFMT_MISC /* * Networking */ #define CONFIG_NET 1 /* * Networking options */ #define CONFIG_PACKET 1 #define CONFIG_PACKET_MMAP 1 #define CONFIG_UNIX 1 #undef CONFIG_NET_KEY #define CONFIG_INET 1 #undef CONFIG_IP_MULTICAST #undef CONFIG_IP_ADVANCED_ROUTER #define CONFIG_IP_FIB_HASH 1 #undef CONFIG_IP_PNP #undef CONFIG_NET_IPIP #undef CONFIG_NET_IPGRE #undef CONFIG_ARPD #undef CONFIG_SYN_COOKIES #undef CONFIG_INET_AH #undef CONFIG_INET_ESP #undef CONFIG_INET_IPCOMP #undef CONFIG_INET_TUNNEL #define CONFIG_INET_DIAG 1 #define CONFIG_INET_TCP_DIAG 1 #undef CONFIG_TCP_CONG_ADVANCED #define CONFIG_TCP_CONG_BIC 1 #undef CONFIG_IPV6 #undef CONFIG_NETFILTER /* * DCCP Configuration (EXPERIMENTAL) */ #undef CONFIG_IP_DCCP /* * SCTP Configuration (EXPERIMENTAL) */ #undef CONFIG_IP_SCTP #undef CONFIG_ATM #undef CONFIG_BRIDGE #undef CONFIG_VLAN_8021Q #undef CONFIG_DECNET #undef CONFIG_LLC2 #undef CONFIG_IPX #undef CONFIG_ATALK #undef CONFIG_X25 #undef CONFIG_LAPB #undef CONFIG_NET_DIVERT #undef CONFIG_ECONET #undef CONFIG_WAN_ROUTER /* * QoS and/or fair queueing */ #undef CONFIG_NET_SCHED /* * Network testing */ #undef CONFIG_NET_PKTGEN #undef CONFIG_HAMRADIO #undef CONFIG_IRDA #undef CONFIG_BT #undef CONFIG_IEEE80211 /* * Device Drivers */ /* * Generic Driver Options */ #define CONFIG_STANDALONE 1 #define CONFIG_PREVENT_FIRMWARE_BUILD 1 #define CONFIG_FW_LOADER_MODULE 1 /* * Connector - unified userspace <-> kernelspace linker */ #undef CONFIG_CONNECTOR /* * Memory Technology Devices (MTD) */ #undef CONFIG_MTD /* * Parallel port support */ #undef CONFIG_PARPORT /* * Plug and Play support */ #undef CONFIG_PNP /* * Block devices */ #define CONFIG_BLK_DEV_FD_MODULE 1 #undef CONFIG_BLK_CPQ_DA #undef CONFIG_BLK_CPQ_CISS_DA #undef CONFIG_BLK_DEV_DAC960 #undef CONFIG_BLK_DEV_UMEM #undef CONFIG_BLK_DEV_COW_COMMON #undef CONFIG_BLK_DEV_LOOP #undef CONFIG_BLK_DEV_NBD #undef CONFIG_BLK_DEV_SX8 #undef CONFIG_BLK_DEV_UB #undef CONFIG_BLK_DEV_RAM #define CONFIG_BLK_DEV_RAM_COUNT 16 #undef CONFIG_CDROM_PKTCDVD #undef CONFIG_ATA_OVER_ETH /* * ATA/ATAPI/MFM/RLL support */ #define CONFIG_IDE 1 #define CONFIG_BLK_DEV_IDE 1 /* * Please see Documentation/ide.txt for help/info on IDE drives */ #undef CONFIG_BLK_DEV_IDE_SATA #undef CONFIG_BLK_DEV_HD_IDE #define CONFIG_BLK_DEV_IDEDISK 1 #undef CONFIG_IDEDISK_MULTI_MODE #undef CONFIG_BLK_DEV_IDECS #undef CONFIG_BLK_DEV_IDECD #undef CONFIG_BLK_DEV_IDETAPE #undef CONFIG_BLK_DEV_IDEFLOPPY #undef CONFIG_BLK_DEV_IDESCSI #undef CONFIG_IDE_TASK_IOCTL /* * IDE chipset support/bugfixes */ #define CONFIG_IDE_GENERIC 1 #undef CONFIG_BLK_DEV_CMD640 #define CONFIG_BLK_DEV_IDEPCI 1 #undef CONFIG_IDEPCI_SHARE_IRQ #undef CONFIG_BLK_DEV_OFFBOARD #undef CONFIG_BLK_DEV_GENERIC #undef CONFIG_BLK_DEV_OPTI621 #undef CONFIG_BLK_DEV_RZ1000 #define CONFIG_BLK_DEV_IDEDMA_PCI 1 #undef CONFIG_BLK_DEV_IDEDMA_FORCED #define CONFIG_IDEDMA_PCI_AUTO 1 #undef CONFIG_IDEDMA_ONLYDISK #undef CONFIG_BLK_DEV_AEC62XX #undef CONFIG_BLK_DEV_ALI15X3 #undef CONFIG_BLK_DEV_AMD74XX #undef CONFIG_BLK_DEV_ATIIXP #undef CONFIG_BLK_DEV_CMD64X #undef CONFIG_BLK_DEV_TRIFLEX #undef CONFIG_BLK_DEV_CY82C693 #undef CONFIG_BLK_DEV_CS5520 #undef CONFIG_BLK_DEV_CS5530 #undef CONFIG_BLK_DEV_CS5535 #undef CONFIG_BLK_DEV_HPT34X #undef CONFIG_BLK_DEV_HPT366 #undef CONFIG_BLK_DEV_SC1200 #undef CONFIG_BLK_DEV_PIIX #undef CONFIG_BLK_DEV_IT821X #undef CONFIG_BLK_DEV_NS87415 #undef CONFIG_BLK_DEV_PDC202XX_OLD #undef CONFIG_BLK_DEV_PDC202XX_NEW #undef CONFIG_BLK_DEV_SVWKS #undef CONFIG_BLK_DEV_SIIMAGE #undef CONFIG_BLK_DEV_SIS5513 #undef CONFIG_BLK_DEV_SLC90E66 #undef CONFIG_BLK_DEV_TRM290 #undef CONFIG_BLK_DEV_VIA82CXXX #undef CONFIG_IDE_ARM #define CONFIG_BLK_DEV_IDEDMA 1 #undef CONFIG_IDEDMA_IVB #define CONFIG_IDEDMA_AUTO 1 #undef CONFIG_BLK_DEV_HD /* * SCSI device support */ #undef CONFIG_RAID_ATTRS #define CONFIG_SCSI_MODULE 1 #define CONFIG_SCSI_PROC_FS 1 /* * SCSI support type (disk, tape, CD-ROM) */ #define CONFIG_BLK_DEV_SD_MODULE 1 #undef CONFIG_CHR_DEV_ST #undef CONFIG_CHR_DEV_OSST #undef CONFIG_BLK_DEV_SR #undef CONFIG_CHR_DEV_SG #undef CONFIG_CHR_DEV_SCH /* * Some SCSI devices (e.g. CD jukebox) support multiple LUNs */ #undef CONFIG_SCSI_MULTI_LUN #undef CONFIG_SCSI_CONSTANTS #undef CONFIG_SCSI_LOGGING /* * SCSI Transport Attributes */ #undef CONFIG_SCSI_SPI_ATTRS #undef CONFIG_SCSI_FC_ATTRS #undef CONFIG_SCSI_ISCSI_ATTRS #undef CONFIG_SCSI_SAS_ATTRS /* * SCSI low-level drivers */ #undef CONFIG_ISCSI_TCP #undef CONFIG_BLK_DEV_3W_XXXX_RAID #undef CONFIG_SCSI_3W_9XXX #undef CONFIG_SCSI_ACARD #undef CONFIG_SCSI_AACRAID #undef CONFIG_SCSI_AIC7XXX #undef CONFIG_SCSI_AIC7XXX_OLD #undef CONFIG_SCSI_AIC79XX #undef CONFIG_SCSI_DPT_I2O #undef CONFIG_MEGARAID_MM #undef CONFIG_MEGARAID_LEGACY #undef CONFIG_MEGARAID_SAS #undef CONFIG_SCSI_SATA #undef CONFIG_SCSI_BUSLOGIC #undef CONFIG_SCSI_DMX3191D #undef CONFIG_SCSI_EATA #undef CONFIG_SCSI_FUTURE_DOMAIN #undef CONFIG_SCSI_GDTH #undef CONFIG_SCSI_IPS #undef CONFIG_SCSI_INITIO #undef CONFIG_SCSI_INIA100 #undef CONFIG_SCSI_SYM53C8XX_2 #undef CONFIG_SCSI_IPR #undef CONFIG_SCSI_QLOGIC_FC #undef CONFIG_SCSI_QLOGIC_1280 #define CONFIG_SCSI_QLA2XXX_MODULE 1 #undef CONFIG_SCSI_QLA21XX #undef CONFIG_SCSI_QLA22XX #undef CONFIG_SCSI_QLA2300 #undef CONFIG_SCSI_QLA2322 #undef CONFIG_SCSI_QLA6312 #undef CONFIG_SCSI_QLA24XX #undef CONFIG_SCSI_LPFC #undef CONFIG_SCSI_DC395x #undef CONFIG_SCSI_DC390T #undef CONFIG_SCSI_NSP32 #undef CONFIG_SCSI_DEBUG /* * PCMCIA SCSI adapter support */ #undef CONFIG_PCMCIA_AHA152X #undef CONFIG_PCMCIA_FDOMAIN #undef CONFIG_PCMCIA_NINJA_SCSI #undef CONFIG_PCMCIA_QLOGIC #undef CONFIG_PCMCIA_SYM53C500 /* * Multi-device support (RAID and LVM) */ #undef CONFIG_MD /* * Fusion MPT device support */ #undef CONFIG_FUSION #undef CONFIG_FUSION_SPI #undef CONFIG_FUSION_FC #undef CONFIG_FUSION_SAS /* * IEEE 1394 (FireWire) support */ #undef CONFIG_IEEE1394 /* * I2O device support */ #undef CONFIG_I2O /* * Network device support */ #define CONFIG_NETDEVICES 1 #undef CONFIG_DUMMY #undef CONFIG_BONDING #undef CONFIG_EQUALIZER #undef CONFIG_TUN /* * ARCnet devices */ #undef CONFIG_ARCNET /* * PHY device support */ #undef CONFIG_PHYLIB /* * Ethernet (10 or 100Mbit) */ #define CONFIG_NET_ETHERNET 1 #define CONFIG_MII 1 #undef CONFIG_HAPPYMEAL #undef CONFIG_SUNGEM #undef CONFIG_CASSINI #define CONFIG_NET_VENDOR_3COM 1 #define CONFIG_VORTEX 1 #undef CONFIG_TYPHOON /* * Tulip family network device support */ #undef CONFIG_NET_TULIP #undef CONFIG_HP100 #undef CONFIG_NET_PCI /* * Ethernet (1000 Mbit) */ #undef CONFIG_DL2K #undef CONFIG_E1000 #undef CONFIG_NS83820 #undef CONFIG_HAMACHI #undef CONFIG_YELLOWFIN #undef CONFIG_R8169 #undef CONFIG_SIS190 #undef CONFIG_SKGE #undef CONFIG_SK98LIN #undef CONFIG_TIGON3 #undef CONFIG_BNX2 /* * Ethernet (10000 Mbit) */ #undef CONFIG_CHELSIO_T1 #undef CONFIG_IXGB #undef CONFIG_S2IO /* * Token Ring devices */ #undef CONFIG_TR /* * Wireless LAN (non-hamradio) */ #define CONFIG_NET_RADIO 1 /* * Obsolete Wireless cards support (pre-802.11) */ #undef CONFIG_STRIP #undef CONFIG_PCMCIA_WAVELAN #undef CONFIG_PCMCIA_NETWAVE /* * Wireless 802.11 Frequency Hopping cards support */ #undef CONFIG_PCMCIA_RAYCS /* * Wireless 802.11b ISA/PCI cards support */ #undef CONFIG_AIRO #undef CONFIG_HERMES #undef CONFIG_ATMEL /* * Wireless 802.11b Pcmcia/Cardbus cards support */ #undef CONFIG_AIRO_CS #undef CONFIG_PCMCIA_WL3501 /* * Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support */ #undef CONFIG_PRISM54 #undef CONFIG_HOSTAP #define CONFIG_NET_WIRELESS 1 /* * PCMCIA network device support */ #undef CONFIG_NET_PCMCIA /* * Wan interfaces */ #undef CONFIG_WAN #undef CONFIG_FDDI #undef CONFIG_HIPPI #undef CONFIG_PPP #undef CONFIG_SLIP #undef CONFIG_NET_FC #undef CONFIG_SHAPER #undef CONFIG_NETCONSOLE #undef CONFIG_NETPOLL #undef CONFIG_NET_POLL_CONTROLLER /* * ISDN subsystem */ #undef CONFIG_ISDN /* * Telephony Support */ #undef CONFIG_PHONE /* * Input device support */ #define CONFIG_INPUT 1 /* * Userland interfaces */ #define CONFIG_INPUT_MOUSEDEV 1 #define CONFIG_INPUT_MOUSEDEV_PSAUX 1 #define CONFIG_INPUT_MOUSEDEV_SCREEN_X 800 #define CONFIG_INPUT_MOUSEDEV_SCREEN_Y 600 #undef CONFIG_INPUT_JOYDEV #undef CONFIG_INPUT_TSDEV #define CONFIG_INPUT_EVDEV 1 #undef CONFIG_INPUT_EVBUG /* * Input Device Drivers */ #define CONFIG_INPUT_KEYBOARD 1 #define CONFIG_KEYBOARD_ATKBD 1 #undef CONFIG_KEYBOARD_SUNKBD #undef CONFIG_KEYBOARD_LKKBD #undef CONFIG_KEYBOARD_XTKBD #undef CONFIG_KEYBOARD_NEWTON #define CONFIG_INPUT_MOUSE 1 #define CONFIG_MOUSE_PS2 1 #undef CONFIG_MOUSE_SERIAL #undef CONFIG_MOUSE_VSXXXAA #undef CONFIG_INPUT_JOYSTICK #undef CONFIG_INPUT_TOUCHSCREEN #undef CONFIG_INPUT_MISC /* * Hardware I/O ports */ #define CONFIG_SERIO 1 #define CONFIG_SERIO_I8042 1 #undef CONFIG_SERIO_SERPORT #undef CONFIG_SERIO_CT82C710 #define CONFIG_SERIO_PCIPS2 1 #define CONFIG_SERIO_LIBPS2 1 #undef CONFIG_SERIO_RAW #undef CONFIG_GAMEPORT /* * Character devices */ #define CONFIG_VT 1 #define CONFIG_VT_CONSOLE 1 #define CONFIG_HW_CONSOLE 1 #undef CONFIG_SERIAL_NONSTANDARD /* * Serial drivers */ #undef CONFIG_SERIAL_8250 /* * Non-8250 serial port support */ #undef CONFIG_SERIAL_JSM #define CONFIG_UNIX98_PTYS 1 #undef CONFIG_LEGACY_PTYS /* * IPMI */ #undef CONFIG_IPMI_HANDLER /* * Watchdog Cards */ #undef CONFIG_WATCHDOG #undef CONFIG_HW_RANDOM #undef CONFIG_NVRAM #define CONFIG_RTC 1 #undef CONFIG_DTLK #undef CONFIG_R3964 #undef CONFIG_APPLICOM #undef CONFIG_SONYPI /* * Ftape, the floppy tape device driver */ #undef CONFIG_FTAPE #undef CONFIG_AGP #undef CONFIG_DRM /* * PCMCIA character devices */ #undef CONFIG_SYNCLINK_CS #undef CONFIG_CARDMAN_4000 #undef CONFIG_CARDMAN_4040 #undef CONFIG_MWAVE #undef CONFIG_RAW_DRIVER #undef CONFIG_HPET #undef CONFIG_HANGCHECK_TIMER /* * TPM devices */ #undef CONFIG_TCG_TPM #undef CONFIG_TELCLOCK /* * I2C support */ #undef CONFIG_I2C /* * Dallas's 1-wire bus */ #undef CONFIG_W1 /* * Hardware Monitoring support */ #undef CONFIG_HWMON #undef CONFIG_HWMON_VID /* * Misc devices */ #undef CONFIG_IBM_ASM /* * Multimedia Capabilities Port drivers */ /* * Multimedia devices */ #undef CONFIG_VIDEO_DEV /* * Digital Video Broadcasting Devices */ #undef CONFIG_DVB /* * Graphics support */ #undef CONFIG_FB #define CONFIG_VIDEO_SELECT 1 /* * Console display driver support */ #define CONFIG_VGA_CONSOLE 1 #define CONFIG_DUMMY_CONSOLE 1 /* * Sound */ #define CONFIG_SOUND_MODULE 1 /* * Advanced Linux Sound Architecture */ /* * Generic devices */ /* * PCI devices */ /* * USB devices */ /* * PCMCIA devices */ /* * Open Sound System */ #undef CONFIG_SOUND_PRIME /* * USB support */ #define CONFIG_USB_ARCH_HAS_HCD 1 #define CONFIG_USB_ARCH_HAS_OHCI 1 #define CONFIG_USB_MODULE 1 #undef CONFIG_USB_DEBUG /* * Miscellaneous USB options */ #define CONFIG_USB_DEVICEFS 1 #undef CONFIG_USB_BANDWIDTH #undef CONFIG_USB_DYNAMIC_MINORS #undef CONFIG_USB_SUSPEND #undef CONFIG_USB_OTG /* * USB Host Controller Drivers */ #undef CONFIG_USB_EHCI_HCD #undef CONFIG_USB_ISP116X_HCD #undef CONFIG_USB_OHCI_HCD #define CONFIG_USB_UHCI_HCD_MODULE 1 #undef CONFIG_USB_SL811_HCD /* * USB Device Class drivers */ #undef CONFIG_OBSOLETE_OSS_USB_DRIVER #undef CONFIG_USB_ACM #undef CONFIG_USB_PRINTER /* * NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' */ /* * may also be needed; see USB_STORAGE Help for more information */ #define CONFIG_USB_STORAGE_MODULE 1 #undef CONFIG_USB_STORAGE_DEBUG #undef CONFIG_USB_STORAGE_DATAFAB #undef CONFIG_USB_STORAGE_FREECOM #undef CONFIG_USB_STORAGE_ISD200 #undef CONFIG_USB_STORAGE_DPCM #undef CONFIG_USB_STORAGE_USBAT #undef CONFIG_USB_STORAGE_SDDR09 #undef CONFIG_USB_STORAGE_SDDR55 #undef CONFIG_USB_STORAGE_JUMPSHOT /* * USB Input Devices */ #undef CONFIG_USB_HID /* * USB HID Boot Protocol drivers */ #undef CONFIG_USB_KBD #undef CONFIG_USB_MOUSE #undef CONFIG_USB_AIPTEK #undef CONFIG_USB_WACOM #undef CONFIG_USB_ACECAD #undef CONFIG_USB_KBTAB #undef CONFIG_USB_POWERMATE #undef CONFIG_USB_MTOUCH #undef CONFIG_USB_ITMTOUCH #undef CONFIG_USB_EGALAX #undef CONFIG_USB_YEALINK #undef CONFIG_USB_XPAD #undef CONFIG_USB_ATI_REMOTE #undef CONFIG_USB_KEYSPAN_REMOTE #undef CONFIG_USB_APPLETOUCH /* * USB Imaging devices */ #undef CONFIG_USB_MDC800 #undef CONFIG_USB_MICROTEK /* * USB Multimedia devices */ /* * Video4Linux support is needed for USB Multimedia device support */ /* * USB Network Adapters */ #undef CONFIG_USB_CATC #undef CONFIG_USB_KAWETH #undef CONFIG_USB_PEGASUS #undef CONFIG_USB_RTL8150 #undef CONFIG_USB_USBNET #undef CONFIG_USB_ZD1201 #define CONFIG_USB_MON 1 /* * USB port drivers */ /* * USB Serial Converter support */ #define CONFIG_USB_SERIAL_MODULE 1 #undef CONFIG_USB_SERIAL_GENERIC #undef CONFIG_USB_SERIAL_AIRPRIME #undef CONFIG_USB_SERIAL_ANYDATA #undef CONFIG_USB_SERIAL_BELKIN #undef CONFIG_USB_SERIAL_WHITEHEAT #undef CONFIG_USB_SERIAL_DIGI_ACCELEPORT #undef CONFIG_USB_SERIAL_CP2101 #undef CONFIG_USB_SERIAL_CYPRESS_M8 #undef CONFIG_USB_SERIAL_EMPEG #undef CONFIG_USB_SERIAL_FTDI_SIO #define CONFIG_USB_SERIAL_VISOR_MODULE 1 #undef CONFIG_USB_SERIAL_IPAQ #undef CONFIG_USB_SERIAL_IR #undef CONFIG_USB_SERIAL_EDGEPORT #undef CONFIG_USB_SERIAL_EDGEPORT_TI #undef CONFIG_USB_SERIAL_GARMIN #undef CONFIG_USB_SERIAL_IPW #undef CONFIG_USB_SERIAL_KLSI #undef CONFIG_USB_SERIAL_KOBIL_SCT #undef CONFIG_USB_SERIAL_MCT_U232 #undef CONFIG_USB_SERIAL_PL2303 #undef CONFIG_USB_SERIAL_HP4X #undef CONFIG_USB_SERIAL_SAFE #undef CONFIG_USB_SERIAL_TI #undef CONFIG_USB_SERIAL_CYBERJACK #undef CONFIG_USB_SERIAL_XIRCOM #undef CONFIG_USB_SERIAL_OMNINET /* * USB Miscellaneous drivers */ #undef CONFIG_USB_EMI26 #undef CONFIG_USB_AUERSWALD #undef CONFIG_USB_RIO500 #undef CONFIG_USB_LEGOTOWER #undef CONFIG_USB_LCD #undef CONFIG_USB_LED #undef CONFIG_USB_CYTHERM #undef CONFIG_USB_PHIDGETKIT #undef CONFIG_USB_PHIDGETSERVO #undef CONFIG_USB_IDMOUSE #undef CONFIG_USB_LD #undef CONFIG_USB_TEST /* * USB DSL modem support */ /* * USB Gadget Support */ #undef CONFIG_USB_GADGET /* * MMC/SD Card support */ #undef CONFIG_MMC /* * InfiniBand support */ #undef CONFIG_INFINIBAND /* * SN Devices */ /* * File systems */ #define CONFIG_EXT2_FS 1 #undef CONFIG_EXT2_FS_XATTR #undef CONFIG_EXT2_FS_XIP #define CONFIG_EXT3_FS 1 #undef CONFIG_EXT3_FS_XATTR #define CONFIG_JBD 1 #undef CONFIG_JBD_DEBUG #undef CONFIG_REISERFS_FS #undef CONFIG_JFS_FS #undef CONFIG_FS_POSIX_ACL #undef CONFIG_XFS_FS #undef CONFIG_MINIX_FS #undef CONFIG_ROMFS_FS #define CONFIG_INOTIFY 1 #undef CONFIG_QUOTA #define CONFIG_DNOTIFY 1 #undef CONFIG_AUTOFS_FS #undef CONFIG_AUTOFS4_FS #undef CONFIG_FUSE_FS /* * CD-ROM/DVD Filesystems */ #undef CONFIG_ISO9660_FS #undef CONFIG_UDF_FS /* * DOS/FAT/NT Filesystems */ #define CONFIG_FAT_FS 1 #undef CONFIG_MSDOS_FS #define CONFIG_VFAT_FS 1 #define CONFIG_FAT_DEFAULT_CODEPAGE 850 #define CONFIG_FAT_DEFAULT_IOCHARSET "iso8859-1" #undef CONFIG_NTFS_FS /* * Pseudo filesystems */ #define CONFIG_PROC_FS 1 #define CONFIG_PROC_KCORE 1 #define CONFIG_SYSFS 1 #define CONFIG_TMPFS 1 #undef CONFIG_HUGETLBFS #undef CONFIG_HUGETLB_PAGE #define CONFIG_RAMFS 1 #undef CONFIG_RELAYFS_FS /* * Miscellaneous filesystems */ #undef CONFIG_ADFS_FS #undef CONFIG_AFFS_FS #undef CONFIG_ASFS_FS #undef CONFIG_HFS_FS #undef CONFIG_HFSPLUS_FS #undef CONFIG_BEFS_FS #undef CONFIG_BFS_FS #undef CONFIG_EFS_FS #undef CONFIG_CRAMFS #undef CONFIG_VXFS_FS #undef CONFIG_HPFS_FS #undef CONFIG_QNX4FS_FS #undef CONFIG_SYSV_FS #undef CONFIG_UFS_FS /* * Network File Systems */ #undef CONFIG_NFS_FS #undef CONFIG_NFSD #undef CONFIG_SMB_FS #undef CONFIG_CIFS #undef CONFIG_NCP_FS #undef CONFIG_CODA_FS #undef CONFIG_AFS_FS #undef CONFIG_9P_FS /* * Partition Types */ #define CONFIG_PARTITION_ADVANCED 1 #undef CONFIG_ACORN_PARTITION #undef CONFIG_OSF_PARTITION #undef CONFIG_AMIGA_PARTITION #undef CONFIG_ATARI_PARTITION #undef CONFIG_MAC_PARTITION #define CONFIG_MSDOS_PARTITION 1 #undef CONFIG_BSD_DISKLABEL #undef CONFIG_MINIX_SUBPARTITION #undef CONFIG_SOLARIS_X86_PARTITION #undef CONFIG_UNIXWARE_DISKLABEL #undef CONFIG_LDM_PARTITION #undef CONFIG_SGI_PARTITION #undef CONFIG_ULTRIX_PARTITION #undef CONFIG_SUN_PARTITION #undef CONFIG_EFI_PARTITION /* * Native Language Support */ #define CONFIG_NLS 1 #define CONFIG_NLS_DEFAULT "cp850" #define CONFIG_NLS_CODEPAGE_437_MODULE 1 #undef CONFIG_NLS_CODEPAGE_737 #undef CONFIG_NLS_CODEPAGE_775 #define CONFIG_NLS_CODEPAGE_850_MODULE 1 #undef CONFIG_NLS_CODEPAGE_852 #undef CONFIG_NLS_CODEPAGE_855 #undef CONFIG_NLS_CODEPAGE_857 #undef CONFIG_NLS_CODEPAGE_860 #undef CONFIG_NLS_CODEPAGE_861 #undef CONFIG_NLS_CODEPAGE_862 #undef CONFIG_NLS_CODEPAGE_863 #undef CONFIG_NLS_CODEPAGE_864 #undef CONFIG_NLS_CODEPAGE_865 #undef CONFIG_NLS_CODEPAGE_866 #undef CONFIG_NLS_CODEPAGE_869 #undef CONFIG_NLS_CODEPAGE_936 #undef CONFIG_NLS_CODEPAGE_950 #undef CONFIG_NLS_CODEPAGE_932 #undef CONFIG_NLS_CODEPAGE_949 #undef CONFIG_NLS_CODEPAGE_874 #undef CONFIG_NLS_ISO8859_8 #undef CONFIG_NLS_CODEPAGE_1250 #undef CONFIG_NLS_CODEPAGE_1251 #define CONFIG_NLS_ASCII_MODULE 1 #define CONFIG_NLS_ISO8859_1_MODULE 1 #undef CONFIG_NLS_ISO8859_2 #undef CONFIG_NLS_ISO8859_3 #undef CONFIG_NLS_ISO8859_4 #undef CONFIG_NLS_ISO8859_5 #undef CONFIG_NLS_ISO8859_6 #undef CONFIG_NLS_ISO8859_7 #undef CONFIG_NLS_ISO8859_9 #undef CONFIG_NLS_ISO8859_13 #undef CONFIG_NLS_ISO8859_14 #define CONFIG_NLS_ISO8859_15_MODULE 1 #undef CONFIG_NLS_KOI8_R #undef CONFIG_NLS_KOI8_U #define CONFIG_NLS_UTF8_MODULE 1 /* * Instrumentation Support */ #undef CONFIG_PROFILING #undef CONFIG_KPROBES /* * Kernel hacking */ #undef CONFIG_PRINTK_TIME #undef CONFIG_DEBUG_KERNEL #define CONFIG_LOG_BUF_SHIFT 14 #define CONFIG_DEBUG_BUGVERBOSE 1 #define CONFIG_EARLY_PRINTK 1 /* * Security options */ #undef CONFIG_KEYS #undef CONFIG_SECURITY /* * Cryptographic options */ #define CONFIG_CRYPTO 1 #undef CONFIG_CRYPTO_HMAC #undef CONFIG_CRYPTO_NULL #undef CONFIG_CRYPTO_MD4 #undef CONFIG_CRYPTO_MD5 #undef CONFIG_CRYPTO_SHA1 #undef CONFIG_CRYPTO_SHA256 #undef CONFIG_CRYPTO_SHA512 #undef CONFIG_CRYPTO_WP512 #undef CONFIG_CRYPTO_TGR192 #undef CONFIG_CRYPTO_DES #undef CONFIG_CRYPTO_BLOWFISH #undef CONFIG_CRYPTO_TWOFISH #undef CONFIG_CRYPTO_SERPENT #define CONFIG_CRYPTO_AES_586_MODULE 1 #undef CONFIG_CRYPTO_CAST5 #undef CONFIG_CRYPTO_CAST6 #undef CONFIG_CRYPTO_TEA #undef CONFIG_CRYPTO_ARC4 #undef CONFIG_CRYPTO_KHAZAD #undef CONFIG_CRYPTO_ANUBIS #undef CONFIG_CRYPTO_DEFLATE #undef CONFIG_CRYPTO_MICHAEL_MIC #undef CONFIG_CRYPTO_CRC32C #undef CONFIG_CRYPTO_TEST /* * Hardware crypto devices */ #undef CONFIG_CRYPTO_DEV_PADLOCK /* * Library routines */ #undef CONFIG_CRC_CCITT #undef CONFIG_CRC16 #define CONFIG_CRC32_MODULE 1 #undef CONFIG_LIBCRC32C #define CONFIG_GENERIC_HARDIRQS 1 #define CONFIG_GENERIC_IRQ_PROBE 1 #define CONFIG_X86_BIOS_REBOOT 1 /* include/autoconf-extra.h. Generated by configure. */ /* * external ALSA section by alsa-driver */ #define CONFIG_SND_MODULE 1 /* #undef CONFIG_SND_BIT32_EMUL_MODULE */ #define CONFIG_SND_RTCTIMER_MODULE 1 /* #undef CONFIG_SND_HPET_MODULE */ #define CONFIG_SND_SEQUENCER_MODULE 1 #define CONFIG_SND_SEQ_DUMMY_MODULE 1 /* #undef CONFIG_SND_OSSEMUL */ /* #undef CONFIG_SND_MIXER_OSS_MODULE */ /* #undef CONFIG_SND_PCM_OSS_MODULE */ /* #undef CONFIG_SND_SEQUENCER_OSS */ /* #undef CONFIG_SND_DYNAMIC_MINORS */ /* #undef CONFIG_SND_DEBUG */ /* #undef CONFIG_SND_DEBUG_MEMORY */ /* #undef CONFIG_SND_DEBUG_FULL */ /* #undef CONFIG_SND_DEBUG_DETECT */ #define CONFIG_SND_VERBOSE_PRINTK 1 /* include/config1.h. Generated by configure. */ /* Soundcard configuration for ALSA driver */ /* Copyright (c) by Jaroslav Kysela <perex@suse.cz>, */ /* Anders Semb Hermansen <ahermans@vf.telia.no> */ /* #undef CONFIG_SOUND_MODULE */ #define CONFIG_SND_MODULE 1 #define CONFIG_SND_TIMER_MODULE 1 #define CONFIG_SND_PCM_MODULE 1 /* #undef CONFIG_SND_HWDEP_MODULE */ /* #undef CONFIG_SND_RAWMIDI_MODULE */ #define CONFIG_SND_SEQUENCER_MODULE 1 #define CONFIG_SND_SEQ_DUMMY_MODULE 1 /* #undef CONFIG_SND_OSSEMUL */ /* #undef CONFIG_SND_MIXER_OSS_MODULE */ /* #undef CONFIG_SND_PCM_OSS_MODULE */ /* #undef CONFIG_SND_PCM_OSS_PLUGINS */ /* #undef CONFIG_SND_SEQUENCER_OSS */ #define CONFIG_SND_RTCTIMER_MODULE 1 /* #undef CONFIG_RTC_MODULE */ #define CONFIG_SND_SEQ_RTCTIMER_DEFAULT 1 /* #undef CONFIG_SND_DYNAMIC_MINORS */ /* #undef CONFIG_EXPERIMENTAL_MODULE */ #define CONFIG_SND_SUPPORT_OLD_API 1 #define CONFIG_SND_VERBOSE_PROCFS 1 #define CONFIG_SND_VERBOSE_PRINTK 1 /* #undef CONFIG_SND_DEBUG */ /* #undef CONFIG_SND_DEBUG_DETECT */ /* #undef CONFIG_SND_BIT32_EMUL_MODULE */ /* #undef CONFIG_SND_DEBUG_MEMORY */ /* #undef CONFIG_SND_HPET_MODULE */ /* #undef CONFIG_HPET_MODULE */ /* #undef CONFIG_SND_MPU401_UART_MODULE */ /* #undef CONFIG_SND_OPL3_LIB_MODULE */ /* #undef CONFIG_SND_OPL4_LIB_MODULE */ /* #undef CONFIG_SND_VX_LIB_MODULE */ #define CONFIG_SND_AC97_CODEC_MODULE 1 #define CONFIG_SND_AC97_BUS_MODULE 1 /* #undef CONFIG_SND_DUMMY_MODULE */ /* #undef CONFIG_SND_VIRMIDI_MODULE */ /* #undef CONFIG_SND_MTPAV_MODULE */ /* #undef CONFIG_SND_SERIAL_U16550_MODULE */ /* #undef CONFIG_SND_MPU401_MODULE */ /* #undef CONFIG_SND_SERIALMIDI_MODULE */ /* #undef CONFIG_SND_LOOPBACK_MODULE */ /* #undef CONFIG_SND_PORTMAN2X4_MODULE */ /* #undef CONFIG_PARPORT_MODULE */ /* #undef CONFIG_SND_PCSP_MODULE */ /* #undef CONFIG_X86_MODULE */ /* #undef CONFIG_HAVE_PCSP_HOOK_MODULE */ /* #undef CONFIG_ISA_MODULE */ /* #undef CONFIG_ISA_DMA_API_MODULE */ /* #undef CONFIG_SND_AD1848_LIB_MODULE */ /* #undef CONFIG_SND_CS4231_LIB_MODULE */ /* #undef CONFIG_SND_AD1816A_MODULE */ /* #undef CONFIG_PNP_MODULE */ /* #undef CONFIG_ISAPNP_MODULE */ /* #undef CONFIG_SND_AD1848_MODULE */ /* #undef CONFIG_SND_ALS100_MODULE */ /* #undef CONFIG_SND_AZT2320_MODULE */ /* #undef CONFIG_SND_CMI8330_MODULE */ /* #undef CONFIG_SND_CS4231_MODULE */ /* #undef CONFIG_SND_CS4232_MODULE */ /* #undef CONFIG_SND_CS4236_MODULE */ /* #undef CONFIG_SND_DT019X_MODULE */ /* #undef CONFIG_SND_ES968_MODULE */ /* #undef CONFIG_SND_ES1688_MODULE */ /* #undef CONFIG_SND_ES18XX_MODULE */ /* #undef CONFIG_SND_GUS_SYNTH_MODULE */ /* #undef CONFIG_SND_GUSCLASSIC_MODULE */ /* #undef CONFIG_SND_GUSEXTREME_MODULE */ /* #undef CONFIG_SND_GUSMAX_MODULE */ /* #undef CONFIG_SND_INTERWAVE_MODULE */ /* #undef CONFIG_SND_INTERWAVE_STB_MODULE */ /* #undef CONFIG_SND_OPL3SA2_MODULE */ /* #undef CONFIG_SND_OPTI92X_AD1848_MODULE */ /* #undef CONFIG_SND_OPTI92X_CS4231_MODULE */ /* #undef CONFIG_SND_OPTI93X_MODULE */ /* #undef CONFIG_SND_SB8_MODULE */ /* #undef CONFIG_SND_SB16_MODULE */ /* #undef CONFIG_SND_SBAWE_MODULE */ /* #undef CONFIG_SND_SB16_CSP */ /* #undef CONFIG_BROKEN_MODULE */ /* #undef CONFIG_PPC_MODULE */ /* #undef CONFIG_SND_SGALAXY_MODULE */ /* #undef CONFIG_SND_SSCAPE_MODULE */ /* #undef CONFIG_SND_WAVEFRONT_MODULE */ /* #undef CONFIG_SND_PC98_CS4232_MODULE */ /* #undef CONFIG_X86_PC9800_MODULE */ /* #undef CONFIG_SND_MIRO_MODULE */ /* #undef CONFIG_SND_MSND_PINNACLE_MODULE */ /* #undef CONFIG_PCI_MODULE */ /* #undef CONFIG_SND_AD1889_MODULE */ /* #undef CONFIG_SND_ALS4000_MODULE */ /* #undef CONFIG_SND_ALI5451_MODULE */ /* #undef CONFIG_SND_ATIIXP_MODULE */ /* #undef CONFIG_SND_ATIIXP_MODEM_MODULE */ /* #undef CONFIG_SND_AU8810_MODULE */ /* #undef CONFIG_SND_AU8820_MODULE */ /* #undef CONFIG_SND_AU8830_MODULE */ /* #undef CONFIG_SND_AZT3328_MODULE */ /* #undef CONFIG_SND_BT87X_MODULE */ /* #undef CONFIG_SND_BT87X_OVERCLOCK */ /* #undef CONFIG_SND_CA0106_MODULE */ /* #undef CONFIG_SND_CMIPCI_MODULE */ /* #undef CONFIG_SND_CS4281_MODULE */ /* #undef CONFIG_SND_CS46XX_MODULE */ /* #undef CONFIG_SND_CS46XX_NEW_DSP */ /* #undef CONFIG_SND_CS5535AUDIO_MODULE */ /* #undef CONFIG_X86_64_MODULE */ /* #undef CONFIG_SND_EMU10K1_MODULE */ /* #undef CONFIG_SND_EMU10K1X_MODULE */ /* #undef CONFIG_SND_ENS1370_MODULE */ /* #undef CONFIG_SND_ENS1371_MODULE */ /* #undef CONFIG_SND_ES1938_MODULE */ /* #undef CONFIG_SND_ES1968_MODULE */ /* #undef CONFIG_SND_FM801_MODULE */ /* #undef CONFIG_SND_FM801_TEA575X_MODULE */ /* #undef CONFIG_VIDEO_DEV_MODULE */ /* #undef CONFIG_SND_HDA_INTEL_MODULE */ /* #undef CONFIG_SND_HDSP_MODULE */ /* #undef CONFIG_SND_HDSPM_MODULE */ /* #undef CONFIG_SND_ICE1712_MODULE */ /* #undef CONFIG_SND_ICE1724_MODULE */ /* #undef CONFIG_SND_INTEL8X0_MODULE */ /* #undef CONFIG_SND_INTEL8X0M_MODULE */ /* #undef CONFIG_SND_KORG1212_MODULE */ /* #undef CONFIG_SND_MAESTRO3_MODULE */ /* #undef CONFIG_SND_MIXART_MODULE */ #define CONFIG_SND_NM256_MODULE 1 /* #undef CONFIG_SND_PCXHR_MODULE */ /* #undef CONFIG_SND_RME32_MODULE */ /* #undef CONFIG_SND_RME96_MODULE */ /* #undef CONFIG_SND_RME9652_MODULE */ /* #undef CONFIG_SND_SONICVIBES_MODULE */ /* #undef CONFIG_SND_TRIDENT_MODULE */ /* #undef CONFIG_SND_VIA82XX_MODULE */ /* #undef CONFIG_SND_VIA82XX_MODEM_MODULE */ /* #undef CONFIG_SND_VX222_MODULE */ /* #undef CONFIG_SND_YMFPCI_MODULE */ /* #undef CONFIG_SND_PDPLUS_MODULE */ /* #undef CONFIG_SND_ASIHPI_MODULE */ /* #undef CONFIG_FW_LOADER_MODULE */ /* #undef CONFIG_SND_DARLA20_MODULE */ /* #undef CONFIG_SND_GINA20_MODULE */ /* #undef CONFIG_SND_LAYLA20_MODULE */ /* #undef CONFIG_SND_DARLA24_MODULE */ /* #undef CONFIG_SND_GINA24_MODULE */ /* #undef CONFIG_SND_LAYLA24_MODULE */ /* #undef CONFIG_SND_MONA_MODULE */ /* #undef CONFIG_SND_MIA_MODULE */ /* #undef CONFIG_SND_ECHO3G_MODULE */ /* #undef CONFIG_SND_INDIGO_MODULE */ /* #undef CONFIG_SND_INDIGOIO_MODULE */ /* #undef CONFIG_SND_INDIGODJ_MODULE */ /* #undef CONFIG_SND_RIPTIDE_MODULE */ /* #undef CONFIG_SND_ALS300_MODULE */ /* #undef CONFIG_SND_POWERMAC_MODULE */ /* #undef CONFIG_I2C_MODULE */ /* #undef CONFIG_INPUT_MODULE */ /* #undef CONFIG_PPC_PMAC_MODULE */ /* #undef CONFIG_SND_POWERMAC_AUTO_DRC */ /* #undef CONFIG_ARM_MODULE */ /* #undef CONFIG_SND_SA11XX_UDA1341_MODULE */ /* #undef CONFIG_ARCH_SA1100_MODULE */ /* #undef CONFIG_L3_MODULE */ /* #undef CONFIG_SND_ARMAACI_MODULE */ /* #undef CONFIG_ARM_AMBA_MODULE */ /* #undef CONFIG_SND_PXA2XX_PCM_MODULE */ /* #undef CONFIG_SND_PXA2XX_AC97_MODULE */ /* #undef CONFIG_ARCH_PXA_MODULE */ /* #undef CONFIG_SND_S3C2410_MODULE */ /* #undef CONFIG_ARCH_S3C2410_MODULE */ /* #undef CONFIG_I2C_SENSOR_MODULE */ /* #undef CONFIG_SND_PXA2XX_I2SOUND_MODULE */ /* #undef CONFIG_MIPS_MODULE */ /* #undef CONFIG_SND_AU1X00_MODULE */ /* #undef CONFIG_SOC_AU1000_MODULE */ /* #undef CONFIG_SOC_AU1100_MODULE */ /* #undef CONFIG_SOC_AU1500_MODULE */ /* #undef CONFIG_USB_MODULE */ /* #undef CONFIG_SND_USB_AUDIO_MODULE */ /* #undef CONFIG_SND_USB_USX2Y_MODULE */ /* #undef CONFIG_ALPHA_MODULE */ /* #undef CONFIG_PCMCIA_MODULE */ /* #undef CONFIG_SND_VXPOCKET_MODULE */ /* #undef CONFIG_SND_PDAUDIOCF_MODULE */ /* #undef CONFIG_SPARC_MODULE */ /* #undef CONFIG_SND_SUN_AMD7930_MODULE */ /* #undef CONFIG_SBUS_MODULE */ /* #undef CONFIG_SND_SUN_CS4231_MODULE */ /* #undef CONFIG_SND_SUN_DBRI_MODULE */ /* #undef CONFIG_GSC_MODULE */ /* #undef CONFIG_SND_HARMONY_MODULE */ /* #undef CONFIG_SOUND_PRIME_MODULE */ [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: debugging nm256: some results, many questions 2006-03-15 13:23 ` Florian Schlichting @ 2006-03-15 15:42 ` Takashi Iwai 2006-03-16 1:42 ` thanks Florian Schlichting 0 siblings, 1 reply; 14+ messages in thread From: Takashi Iwai @ 2006-03-15 15:42 UTC (permalink / raw) To: Florian Schlichting; +Cc: alsa-devel At Wed, 15 Mar 2006 21:23:30 +0800, Florian Schlichting wrote: > > On Wed, Mar 15, 2006 at 10:55:36AM +0100, Takashi Iwai wrote: > > At Wed, 15 Mar 2006 14:09:22 +0800, > > Florian Schlichting wrote: > > > > > > On Tue, Mar 14, 2006 at 09:16:28PM +0100, Takashi Iwai wrote: > > > > At Wed, 15 Mar 2006 03:59:46 +0800, > > > > Florian Schlichting wrote: > > > > > Also, there are some warnings during compile and a problem with depmod > > > > > loops at install > > > > > ---------- > > > > > Building modules, stage 2. > > > > > MODPOST > > > > > *** Warning: "snd_minor_info_oss_init" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > > *** Warning: "snd_lookup_oss_minor_data" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > > *** Warning: "snd_info_minor_unregister" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > > *** Warning: "snd_minor_info_oss_done" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > > *** Warning: "snd_info_minor_register" [/usr/src/cvs/alsa/alsa-driver/acore/snd.ko] undefined! > > > > > > > > > > [...] > > > > > > > > > > WARNING: Loop detected: > > > > > /lib/modules/2.6.15-max/kernel/sound/acore/snd.ko which needs snd.ko > > > > > again! > > > > > ---------- > > > > > (and the rest of the ALSA modules is ignored), so although I could > > > > > build things, it wouldn't "make install" and I can't make a final smoke > > > > > test :-( > > > > > > > > Hm, it sounds like CONFIG_PROC_FS isn't defined properly. > > > > Please check alsa-driver/include/linux/autoconf.h. It's generated by > > > > configure script. > > > > > > hmmm... do you mean this: > > > > > > #define CONFIG_ACPI_SLEEP_PROC_FS 1 > > > #undef CONFIG_ACPI_SLEEP_PROC_SLEEP > > > [...] > > > #undef CONFIG_PCI_LEGACY_PROC > > > [...] > > > #define CONFIG_SCSI_PROC_FS 1 > > > [...] > > > #define CONFIG_PROC_FS 1 > > > #define CONFIG_PROC_KCORE 1 > > > [...] > > > #define CONFIG_SND_VERBOSE_PROCFS 1 > > > > > > -.- > > > > > > I noticed the errors said something with oss. My compile commmand line > > > was './cvscompile --with-isapnp=no --with-sequencer=no --with-oss=no > > > --with-cards=nm256' and that still gives the above errors. I just > > > recompiled with just './cvscompile --with-cards=nm256' and there are no > > > errors, depmod runs fine, I can insert the module... perfect! > > > > Then something conflicts. Could you check CONFIG_SND_OSSEMUL in > > autoconfig.h? > > I did a few tests with different options, and it's clearly the > --with-oss=no that causes the errors during compile and install > > #define CONFIG_SND_OSSEMUL 1 - with the working options, > /* #undef CONFIG_SND_OSSEMUL */ when the errors occur - but it's in there > twice, at line 1276 and 1300, in sections "include/autoconf-extra.h." and > "include/config1.h"! > I'm attaching the whole file for a ./cvscompile --with-cards=nm256 > --with-oss=no I got it. This problem is fixed on CVS now. > > > The mixer > > > settings also survive a suspend, apart from Master Volume which becomes > > > muted (but I guess that's intented? I can't confirm bug#1532) > > > > Hm, no, it's not intended. I think this is the side effect of using > > ac97->regs[]. The ac97 codec routine mutes the master volume to avoid > > noise at suspend, and resumes it with the cache value. > > > > Please try the newer patch below. > > I've tried it, it works well and all the registers including Master > Volume are restored to their pre-suspend values. Thanks for confirmation. I applied the patches to CVS. Takashi ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ^ permalink raw reply [flat|nested] 14+ messages in thread
* thanks 2006-03-15 15:42 ` Takashi Iwai @ 2006-03-16 1:42 ` Florian Schlichting 0 siblings, 0 replies; 14+ messages in thread From: Florian Schlichting @ 2006-03-16 1:42 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- Attachment #1: Type: text/plain, Size: 1783 bytes --] On Wed, Mar 15, 2006 at 04:42:39PM +0100, Takashi Iwai wrote: > > Thanks for confirmation. I applied the patches to CVS. thanks to you for your patience, quick and helpful replies, and ongoing work. And to Lee for providing initial pointers. This was the first time that I looked into kernel code deeply enough to actually understand something and make some modifications. And it was surprisingly easy! (well, it took some time and persistance, but C doesn't read that different from Java, and putting lots of printk's in suspicious places really isn't that difficult) I was thinking that I might have done this much earlier, had I known that developers lacked access to hardware and thus couldn't possibly do much debugging. I've been checking the ALSA website since at least 2002, saw that it's a known issue, that there are bug reports filed to which people answer, and went away again thinking that there are more knowledgeable and able people working on it, and it's just a matter of time and a hard problem... Thus I was thinking whether it might help in such cases to post a note on the driver page that people with access to a certain type of hardware are needed to do debugging? And perhaps have a page somewhere explaining how easy it is to start doing this, for people with some background in programming languages? I realize now that there are probably similar bugs everywhere, and it's just a matter of going for one - but I've been thinking for years that the kernel is such a monster that I'll never understand how it works, anyway (and I still don't, but I found out that it doesn't necessarily matter as long as one understands just the tiny part that's concerned) Anyway, it's been a joy working with you on this! Florian [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2006-03-16 1:42 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-02-23 18:52 debugging nm256: some results, many questions Florian Schlichting 2006-02-24 18:15 ` Takashi Iwai 2006-03-11 17:44 ` Florian Schlichting 2006-03-13 6:46 ` Florian Schlichting 2006-03-13 11:58 ` Takashi Iwai 2006-03-13 14:55 ` Florian Schlichting 2006-03-13 15:50 ` Takashi Iwai 2006-03-14 19:59 ` Florian Schlichting 2006-03-14 20:16 ` Takashi Iwai 2006-03-15 6:09 ` Florian Schlichting 2006-03-15 9:55 ` Takashi Iwai 2006-03-15 13:23 ` Florian Schlichting 2006-03-15 15:42 ` Takashi Iwai 2006-03-16 1:42 ` thanks Florian Schlichting
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.