At Tue, 3 May 2011 10:43:20 +0100, Mark Brown wrote:
On Mon, May 02, 2011 at 03:58:14PM +0100, Dimitris Papastamos wrote:
On Mon, May 02, 2011 at 04:47:41PM +0200, Takashi Iwai wrote:
Dimitris Papastamos wrote:
Right. But does it buy so much, in comparison with the additional complexity of the code? That's my primary question.
For some codecs, the register maps group together registers of similar functionality. With an optimal block size or near optimal, there will be only one rbtree look up if we continually touch any of those registers. This helps primarily when we sync the register map as well as during initialization. I think the added code complexity is worth it. I could perhaps send patches incrementally to simplify this further.
The other thing which Dimitris didn't mention here but which is much more of a win is that for operations which work on large numbers of registers like register cache restore having the registers grouped together then if they're grouped together then you can normally do a block I/O. For the common case of I2C CODECs this means you can save transmitting both the I2C device address and the register address for the second and subsequent registers in a block you'll usually get more than 100% bandwidth saving.
So... when the low-level stuff updates the registers in a block manner, it'll update caches of several registers at once, too. If I understand correctly, the patches help for reducing the CPU usage because the registers looked up in such a case tend to be adjacent. Or am I missing other scenario?
Then my primary question is whether this CPU usage is really heavy. If such an improvement becomes really a big win, something is often wrong in the first stand-point; e.g. it means that RB-tree lookup can be too heavy, and some other method should be considered.
thanks,
Takashi