On Fri, Jan 25, 2008 at 05:19:52PM +0100, Takashi Iwai wrote:
At Fri, 25 Jan 2008 17:07:27 +0100, Hermann Lauer wrote:
On Fri, Jan 25, 2008 at 11:44:12AM +0100, Takashi Iwai wrote:
Then a question arises - why DMAADDR isn't used as the primary source at all? Is it less stable than DMACOUNT in some cases?
I don't know and the current implementation contains only a "don't ask why - AB" comment.
To reiterate: My proposed patch is about minimising the chance that a wrong hw pointer value is given back due to garbage read from the chip. If you are interested, I can send you debugging output which shows that both DMAADDR and DMACOUNT are read out as bogus values from time to time - one or the another, or both. I tried some status flags on the chip, but alway found cases where it's not clear if and which one of the two is correct.
Yeah, it would be helpful to understand the problem more correctly.
Will put together some of the log files next week. Up to what size could/should I cc to the list without upsetting people ? I guess compressing them will yield only a few KBytes.
Not sure about the size limit, but it'd be better to attach a compressed file. Or just cut out only the interesting part.
Appended is a logfile part. The interresting parts are the diff vlaues (1 if DMACOUNT and ADDR are read correct), DMA count, addr and probably status. Status is 0xf when the DMA engine resets the DMAADDR to it's starting value, 0 in all other normal cases.
DMAADDR is reread for the debug output from the chip, so it's sometimes not the value used in the diff calculation.
Hermann