On 24-07-08 23:41, Krzysztof Helt wrote: > On Thu, 24 Jul 2008 21:30:28 +0200 > Rene Herman <rene.herman@xxxxxxxxxxxx> wrote: >>>> *** 0005-wss_lib-use-wss-constants-instead-of-ad1848-ones.patch >>>> >>>>> --- a/sound/isa/ad1848/ad1848_lib.c >>>>> +++ b/sound/isa/ad1848/ad1848_lib.c >>>>> @@ -283,14 +283,12 @@ static int snd_ad1848_trigger(struct snd_wss *chip, unsigned char what, >>>>> return 0; >>>>> } >>>>> snd_ad1848_out(chip, AD1848_IFACE_CTRL, chip->image[AD1848_IFACE_CTRL] |= what); >>>>> - chip->mode |= AD1848_MODE_RUNNING; >>>> Is this now done in generic code? Not necessary anymore? Was no comment >>>> in the changelog. >>> The MODE_RUNNING is not used at all in the cs4231 code. I wonder what the purpose of it. >> It was used by the AD1848 code though; snd_ad1848_trigger() set/reset it >> on start/stop and it was then tested by snd_ad1848_interrupt() to decide >> whether or not to call snd_pcm_period_elapsed(). > > It is not used by the cs4231. The only difference is that ad1848 does not > call the snd_pcm_period_elapsed() after calling the snd_ad1848_open() > but before calling the snd_ad1848_trigger() (and similar restriction > after the snd_ad1848_trigger() and snd_ad1848_close(). > > The cs4231 does not use such restriction. I decided it does not really matter. > The interrupts are not enabled before and after the snd_ad1848_trigger(). > If the cs4231 driver needed this it would be already causing problems. It seems we are talking at cross purposes. I'm not talking about cs4231. I see this MODE_RUNNING thing disappear from ad1848_lib and, unless I've missed it, not resurface in wss_lib -- that library that after these patches is used to drive AD1848 chips that used to be driven by ad1848_lib. The MODE_RUNNING looks as something someone will have once added upon seeing spurious IRQs and as such, testing that it isn't needed on chip/card A, B and C doesn't tell us much. The problem may have been observed on type D, E or F and/or under condition foo or bar. Looking at snd_wss_interrupt() I dom't seem to be seeing a similar guard after these patches. If it's not needed, all for slashing it but please be convincing. Note that by now you should know a lot more about the innards of this code than I do, so please be as verbose as needed. Rene. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
