[alsa-devel] [PATCH] Revert "ASoC: core: Try to use regmap if the driver doesn't set up any I/O"
Some codec driver can not have regmap implementation so core should not assume that codecs without control_data have implemented regmap of it's own.
This reverts commit 38cbf9598feba97de9f9b43efa9153fd7c1a2ec9.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com ---
Hi Mark,
the reverted patch broke the audio on OMAP based board using twl4030, twl6040 as codec. We can not have regmap implementaion within these codec drivers since they rely on the MFD core to do the IO towards the chip.
Regards, Peter
sound/soc/soc-core.c | 4 ---- 1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index f219b2f..da31aa4 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -1095,10 +1095,6 @@ static int soc_probe_codec(struct snd_soc_card *card, } }
- /* If the driver didn't set I/O up try regmap */ - if (!codec->control_data) - snd_soc_codec_set_cache_io(codec, 0, 0, SND_SOC_REGMAP); - if (driver->controls) snd_soc_add_codec_controls(codec, driver->controls, driver->num_controls);
On Wed, Aug 01, 2012 at 04:50:22PM +0300, Peter Ujfalusi wrote:
Some codec driver can not have regmap implementation so core should not assume that codecs without control_data have implemented regmap of it's own.
This reverts commit 38cbf9598feba97de9f9b43efa9153fd7c1a2ec9.
No, this isn't constructive - it just shoves things onto the drivers that are relying on the implicit functionality. Why not just change the criteria we use to check, for example looking for the ops instead?
At Wed, 1 Aug 2012 16:22:48 +0100, Mark Brown wrote:
On Wed, Aug 01, 2012 at 04:50:22PM +0300, Peter Ujfalusi wrote:
Some codec driver can not have regmap implementation so core should not assume that codecs without control_data have implemented regmap of it's own.
This reverts commit 38cbf9598feba97de9f9b43efa9153fd7c1a2ec9.
No, this isn't constructive - it just shoves things onto the drivers that are relying on the implicit functionality. Why not just change the criteria we use to check, for example looking for the ops instead?
Well, the NULL check of dev_get_regmap() looks necessary, but I find it was done in a wrong place in Peter's first patch, too. It could be rather in the caller side, e.g.
/* If the driver didn't set I/O up try regmap */ if (!codec->control_data) { codec->control_data = dev_get_regmap(codec->dev, NULL); if (codec->control_data) snd_soc_codec_set_cache_io(codec, 0, 0, SND_SOC_REGMAP); }
Takashi
On Wed, Aug 01, 2012 at 06:13:28PM +0200, Takashi Iwai wrote:
Mark Brown wrote:
No, this isn't constructive - it just shoves things onto the drivers that are relying on the implicit functionality. Why not just change the criteria we use to check, for example looking for the ops instead?
Well, the NULL check of dev_get_regmap() looks necessary, but I find it was done in a wrong place in Peter's first patch, too. It could be rather in the caller side, e.g.
Yes, this is exactly the sort of change I'm talking about above. We need to take a better decision about deciding to use regmap for the device I/O, this seems like a useful input. Checking for ops should be even better, though - one could potentially use regmap but want to wrap it for some reason (can't think of one right now though).
What I *don't* think is a good idea is trying to bodge this in the I/O code.
participants (3)
-
Mark Brown -
Peter Ujfalusi -
Takashi Iwai