[alsa-devel] [PATCH 10/10] wss_lib: use wss detection code instead of ad1848 one
rene.herman at keyaccess.nl
Fri Jul 25 11:59:16 CEST 2008
On 24-07-08 23:41, Krzysztof Helt wrote:
> On Thu, 24 Jul 2008 21:30:28 +0200
> Rene Herman <rene.herman at keyaccess.nl> 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.
More information about the Alsa-devel