On Wednesday 26 May 2010 09:35:00 ext Mark Brown wrote: > On Wed, May 26, 2010 at 09:28:49AM +0300, Peter Ujfalusi wrote: > > Better thing to do is: > > restore the registers in these cases: > > if (!setup || (setup && setup->reset_registers)) > > > > So if the machine does not provide setup data, than we can assume, than > > no one taken a time to tune the platform, so we need to restore to be on > > the safe side. > > > > What do you think? > > This sounds like a sensible optimisation. May also be an idea to > explicitly do a reset of the registers on unload - I guess nobody will > ever do that if they're not developing, and that'd probably mean that > many of the people who might actually need to reset the registers purely > for development will get the benefit of it without the risk of leaving > the option on in production by mistake. I can add the restore also to the unload path, good idea. > > I can't remember if you're doing this already (and don't even know if > it's possible with the hardware) but if you can do a bulk read of the > registers rather than reading register by register then the overhead > from the I/O should be noticably reduced if you do do the reset. No I'm not doing that, but at least the twl core (and HW) supports burst write, and burst read as well. To add the burst restore support needs a bit bigger change here, and there in the codec driver from the first look. For now, I'm planning to put back the 'old' for (...) style of register restore. Is it OK if I add the burst support later, not in this series? Also is it OK, if I add the restore support as a new patch in the series (so the restore will be gone for 3 commits)? Thanks, Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
