Clemens,
Thanks for your quick reply.
Maybe we should change how these functions handle timeouts. Any other error code indicates that the lock transaction failed definitely, but after a timeout, we don't know if it was the request or the response that got lost.
We could try to read the register, and, if we see that the change that we tried to do actually happend, assume that our driver's transaction did this change.
How is attached patch for this idea?
Are read transactions more reliable than locks? If not, we might need to increase the number of retries for these devices.
This quirk is applied for all of transactions to these devices. As long as I expeciment, their reliability roughly the same.
As long as I tested with this patch, the current number of retries (3 times) seemd to be enough for these devices. ALSA applications can safely use PCM character devices.
This patch (no. 52) does not change the CMP code.
I had no plan to touch CMP codes for this patch because just two models have this quirk. But now I want to add this patch into my series of patch.
Thanks
Takashi Sakamoto o-takashi@sakamocchi.jp