From: Tony Lindgren <tony@atomide.com>
To: Mark Brown <broonie@kernel.org>, Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
linux-pm@vger.kernel.org
Subject: Re: PM regression in next
Date: Fri, 12 Jan 2018 14:49:59 -0800 [thread overview]
Message-ID: <20180112224959.GH4821@atomide.com> (raw)
In-Reply-To: <20180112221126.GK21458@sirena.org.uk>
* Mark Brown <broonie@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
next prev parent reply other threads:[~2018-01-12 22:49 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 0:01 PM regression in next Tony Lindgren
2018-01-12 0:18 ` Andrew Morton
2018-01-12 0:23 ` Tony Lindgren
2018-01-12 0:45 ` Andrew Morton
2018-01-12 1:20 ` Tony Lindgren
2018-01-12 1:32 ` Tony Lindgren
2018-01-12 12:23 ` Rafael J. Wysocki
2018-01-12 12:30 ` Rafael J. Wysocki
2018-01-12 13:01 ` Lars-Peter Clausen
2018-01-12 13:16 ` Andrew Lunn
2018-01-12 13:52 ` Tony Lindgren
2018-01-12 13:55 ` Andrew Lunn
2018-01-12 14:14 ` Tony Lindgren
2018-01-12 19:00 ` Tony Lindgren
2018-01-12 19:12 ` Mark Brown
2018-01-12 21:07 ` Tony Lindgren
2018-01-12 21:15 ` Mark Brown
2018-01-12 21:50 ` Tony Lindgren
2018-01-12 22:11 ` Mark Brown
2018-01-12 22:49 ` Tony Lindgren [this message]
2018-01-12 22:59 ` Mark Brown
2018-01-15 1:45 ` Kuninori Morimoto
2018-01-15 16:50 ` Tony Lindgren
2018-01-15 17:19 ` Mark Brown
2018-01-15 17:52 ` Tony Lindgren
2018-01-15 17:56 ` Mark Brown
2018-01-15 18:06 ` Tony Lindgren
2018-01-15 18:13 ` Mark Brown
2018-01-15 18:55 ` Tony Lindgren
2018-01-16 0:38 ` Kuninori Morimoto
2018-01-17 9:47 ` Peter Ujfalusi
2018-01-15 23:22 ` Kuninori Morimoto
2018-01-16 0:36 ` Tony Lindgren
2018-01-12 21:38 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180112224959.GH4821@atomide.com \
--to=tony@atomide.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peter.ujfalusi@ti.com \
--cc=rafael.j.wysocki@intel.com \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).