On Thu, Aug 11, 2011 at 03:50:33AM +0200, Lars-Peter Clausen wrote:
On 08/11/2011 02:33 AM, Mark Brown wrote:
Like I say I'm really not happy about adding further non-standard driver specifics to the Analog drivers, they're already not the best and they don't really seem to be getting much attention from anyone so I'm not confident anyone will come along and reverse any temporary bodges. I'd be reasonably happy with something temporary for 3.1 if we already have a fix in place for 3.2 but I don't have much confidence that anyone will work on that.
So, just switch the ad193x driver to a rbcache.
That's one of the suggestions I made earlier, obviously it's painful for the register default table at present though.
And if we have to add our own read function we could as very well add our own write function which simply reinstates the old caching behavior.
If the driver needs its own custom I/O it should do both read and write.
We don't need reads if we cache writes. In the old ASoC IO code there wasn't even SPI read support.
Yeah, that's for the volatile case where we skip having a cache at all.
Yes, I had a look at the rbcache the other day. The current code doesn't seem to be optimal. For example adjacent don't seem to be joined, so for example if I have 3 registers and write them in the order 0,2,1 I'll still end up with 2 blocks. But that's of course something that can be fixed. And I had almost been sold on it, if there wasn't the default register issue.
None of the current ASoC code will coalesce register writes at all, and in the case where you're doing writes to registers that aren't actually adjacent it's going to be marginal if it's better to transmit the intervening register or transmit another register address. That only really makes a difference during cache sync anyway.
If we also provide a more compact way of representing the defaults that devices with sparse registers can use then that problem will go away too.
What do you have in mind for this? An array of pairs of register and value?
Yes, as I said in one of the earlier messages in this thread. It seems like a good combination of being writable/legible and compact.