At Fri, 20 Aug 2010 16:46:25 +0200, David Henningsson wrote:
2010-08-19 22:24, Takashi Iwai skrev:
At Thu, 19 Aug 2010 20:48:56 +0200, David Henningsson wrote:
2010-08-19 20:28, Takashi Iwai skrev:
At Thu, 19 Aug 2010 20:17:42 +0200, David Henningsson wrote:
This patch is helpful for tracking down bugs without having all information about the chip.
I don't want to change coef index in reading a proc file in general.
Good point. But I think the solution to that problem would be to
- read current index
- do the loop
- restore current index
...and perhaps protect that with an appropriate mutex (which one)?
If any, you should implement a codec-specific hook.
I'm sorry, but I don't really see how that would help...?
If it's specific to a codec, then you know whether reading the coef in that way can be harmful or not. It's not only about the race via proc file but also the influence of coef on the actual codec behavior.
Oh, so there are chips that are *that* broken...
Yet it could be a lifesaver so I wouldn't want to give up on the idea just yet...
As mentioned, I don't mind to add it but as a beginning, let's add it conditionally for known-working codecs. Eventually we can put it to the generic part, with a blacklisting if needed.
Do you know off the top of your head approximately what codec chips this is about, where reading a coef (or setting its index) can cause unwanted side-effects?
I don't remember exactly which one. I thought either an old Realtek or AD codec.
Takashi