Re: [alsa-devel] [RFC] ASoC: sgtl5000: Remove cache support
Hi Mark,
On Fri, May 3, 2013 at 7:36 PM, Mark Brown broonie@sirena.org.uk wrote:
On Fri, May 03, 2013 at 04:49:09PM -0300, Fabio Estevam wrote:
.set_bias_level = sgtl5000_set_bias_level,
.reg_cache_size = ARRAY_SIZE(sgtl5000_regs),
.reg_word_size = sizeof(u16),
.reg_cache_step = 2,
.reg_cache_default = sgtl5000_regs,
So, the most obvious thing here is to convert the driver to regmap. It has a much more baked in idea of sparse register maps which should help if nothing else, and will allow the device initialisation to be moved to the normal device probe which is better practice.
Thanks for your suggestion.
I have just sent a patch converting sgtl5000 to use regmap.
Unfortunately the result is the same: the codec cannot probe after a reset.
Otherwise the normal issue with this sort of thing is a failure to power down the device properly, the LDO workaround looks suspicous here as does the fact that the driver doesn't restore the register cache when powering on the device in resume (nor does it makr the device as cache only).
I will try to investigate the power down and LDO workaround as suggested.
Thanks,
Fabio Estevam
On Sat, May 4, 2013 at 3:47 PM, Fabio Estevam festevam@gmail.com wrote:
I will try to investigate the power down and LDO workaround as suggested.
If I use a the kernel provided by Freescale the codec reset issue does not happen.
I see this commit from Freescale kernel that workarounds exactly the same issue:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/sound/soc...
It seems that caching is broking with this codec.
If this is true, should we go with the proposal of this RFC patch?
On Sat, May 04, 2013 at 05:25:45PM -0300, Fabio Estevam wrote:
I see this commit from Freescale kernel that workarounds exactly the same issue:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/sound/soc...
It seems that caching is broking with this codec.
This is nonsensical. Clearly there's something about the use of the cache that is interacting poorly with the device but we've no idea what it is. Simply having a copy of the register map in the host memory is not going to do anything to the device, there must be some other issue at work.
If this is true, should we go with the proposal of this RFC patch?
We should understand what the issue is. Looking at the commit above it's not removing the cache at all, it's both attempting to work around an issue with the cache not handling the register step size properly (this looks like it's just a bug in the current driver) and reordering some of the startup around the regulator (the comment says it's open coding cache_bypass but it's also moving blocks of code around).
participants (2)
-
Fabio Estevam
-
Mark Brown