PM regression in next

[Tony Lindgren]

* Mark Brown <broonie at kernel.org> [180112 22:11]:
> On Fri, Jan 12, 2018 at 01:50:10PM -0800, Tony Lindgren wrote:
> 
> > > I rather suspect someone would've noticed by now TBH - I suspect this is
> > > more likely to be an issue with the rather baroque code that the TWL
> > > drivers have possibly coupled with the whole multiple I2C devices issue.
> 
> > Hmm these calls are in sound/soc/soc-core.c though? But yeah, sure
> > it could be some legacy code issue somewhere..
> 
> Most devices have one regmap per device which can be retrieved with
> dev_get_regmap(), it's the attempt to use that which I suspect is
> broken.  Like I said snd_soc_codec_init_regmap() ought to fix things if
> that's the issue.

OK. Adding Peter to loop as it's his driver after all. Not sure
how well mixing regmap register access to the same module with
cached twl4030_read() would work :)

Maybe there should also be some big warning happening if
snd_soc_codec_init_regmap() is now needed and no regmap is
found?

> > sound/soc/codecs/cx20442.c
> > sound/soc/codecs/tlv320dac33.c
> > sound/soc/codecs/twl4030.c
> > sound/soc/codecs/twl6040.c
> > sound/soc/codecs/uda1380.c
> > sound/soc/fsl/fsl_ssi.c
> 
> > Can you confirm that some of these are still working?
> 
> Most of the non-TWL ones have no active users I'm aware of but fsl_ssi.c
> is under active development at the minute, one series was getting some
> successful testing earlier today so if it's broken I'd hope someone
> would have noticed although since it doesn't use DAPM or anything
> snd_soc_read()/write() will never get used.  cx20442 was only in a
> single archaic consumer product, uda1380 has been legacy since before I
> was ever involved in ASoC.

OK. sounds like we should just revert the read and write removal
patches for now as they are now known to be incomplete for
non-regmap cases and cause regressions. That way we can deal with
them properly after the merge window and test them.

I'm not sure if adding back just the .read and .write is a safe
revert in all cases but it might be doable.

Regards,

Tony