From: Tony Lindgren <tony@atomide.com>
To: Mark Brown <broonie@kernel.org>
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 13:50:10 -0800 [thread overview]
Message-ID: <20180112215010.GG4821@atomide.com> (raw)
In-Reply-To: <20180112211535.GH21458@sirena.org.uk>
* Mark Brown <broonie@kernel.org> [180112 21:15]:
> On Fri, Jan 12, 2018 at 01:07:06PM -0800, Tony Lindgren wrote:
>
> > (twl4030_dummy_read [snd_soc_twl4030]) from [<bf1cc3b4>]
> > (snd_soc_codec_drv_read+0x1c/0x28 [snd_soc_core])
> > (snd_soc_codec_drv_read [snd_soc_core]) from [<bf1da1cc>]
> > (snd_soc_dapm_new_widgets+0x29c/0x578 [snd_soc_core])
> > (snd_soc_dapm_new_widgets [snd_soc_core]) from [<bf1d2f30>]
> > (snd_soc_register_card+0xad0/0xe30 [snd_soc_core])
> > (snd_soc_register_card [snd_soc_core]) from [<bf1e1850>]
> > (devm_snd_soc_register_card+0x30/0x70 [snd_soc_core])
> > (devm_snd_soc_register_card [snd_soc_core]) from [<bf234364>]
> > (omap_twl4030_probe+0x100/0x1d0 [snd_soc_omap_twl4030])
> > (omap_twl4030_probe [snd_soc_omap_twl4030]) from [<c0606660>]
> > (platform_drv_probe+0x50/0xb0)
>
> So does the read not happen otherwise? Or is it failing somehow and the
> error getting ignored?
All the snd_soc_dapm_new_widgets() related reads go missing
without the .read being there. Probably the same story for
writes.
> > So probably there are other asoc drivers broken too with these
> > kind of patches until snd_soc_codec_drv_write() and
> > snd_soc_codec_drv_read() are fixed?
>
> 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..
Based on a quick grep these have .read and .write removed in next
so they may all be broken now:
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?
Regards,
Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: PM regression in next
Date: Fri, 12 Jan 2018 13:50:10 -0800 [thread overview]
Message-ID: <20180112215010.GG4821@atomide.com> (raw)
In-Reply-To: <20180112211535.GH21458@sirena.org.uk>
* Mark Brown <broonie@kernel.org> [180112 21:15]:
> On Fri, Jan 12, 2018 at 01:07:06PM -0800, Tony Lindgren wrote:
>
> > (twl4030_dummy_read [snd_soc_twl4030]) from [<bf1cc3b4>]
> > (snd_soc_codec_drv_read+0x1c/0x28 [snd_soc_core])
> > (snd_soc_codec_drv_read [snd_soc_core]) from [<bf1da1cc>]
> > (snd_soc_dapm_new_widgets+0x29c/0x578 [snd_soc_core])
> > (snd_soc_dapm_new_widgets [snd_soc_core]) from [<bf1d2f30>]
> > (snd_soc_register_card+0xad0/0xe30 [snd_soc_core])
> > (snd_soc_register_card [snd_soc_core]) from [<bf1e1850>]
> > (devm_snd_soc_register_card+0x30/0x70 [snd_soc_core])
> > (devm_snd_soc_register_card [snd_soc_core]) from [<bf234364>]
> > (omap_twl4030_probe+0x100/0x1d0 [snd_soc_omap_twl4030])
> > (omap_twl4030_probe [snd_soc_omap_twl4030]) from [<c0606660>]
> > (platform_drv_probe+0x50/0xb0)
>
> So does the read not happen otherwise? Or is it failing somehow and the
> error getting ignored?
All the snd_soc_dapm_new_widgets() related reads go missing
without the .read being there. Probably the same story for
writes.
> > So probably there are other asoc drivers broken too with these
> > kind of patches until snd_soc_codec_drv_write() and
> > snd_soc_codec_drv_read() are fixed?
>
> 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..
Based on a quick grep these have .read and .write removed in next
so they may all be broken now:
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?
Regards,
Tony
next prev parent reply other threads:[~2018-01-12 21:50 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-12 0:01 PM regression in next Tony Lindgren
2018-01-12 0:01 ` Tony Lindgren
2018-01-12 0:18 ` Andrew Morton
2018-01-12 0:18 ` Andrew Morton
2018-01-12 0:23 ` Tony Lindgren
2018-01-12 0:23 ` Tony Lindgren
2018-01-12 0:45 ` Andrew Morton
2018-01-12 0:45 ` Andrew Morton
2018-01-12 0:45 ` Andrew Morton
2018-01-12 1:20 ` Tony Lindgren
2018-01-12 1:20 ` Tony Lindgren
2018-01-12 1:32 ` Tony Lindgren
2018-01-12 1:32 ` Tony Lindgren
2018-01-12 12:23 ` Rafael J. Wysocki
2018-01-12 12:23 ` Rafael J. Wysocki
2018-01-12 12:30 ` Rafael J. Wysocki
2018-01-12 12:30 ` Rafael J. Wysocki
2018-01-12 13:01 ` Lars-Peter Clausen
2018-01-12 13:01 ` Lars-Peter Clausen
2018-01-12 13:16 ` Andrew Lunn
2018-01-12 13:16 ` Andrew Lunn
2018-01-12 13:52 ` Tony Lindgren
2018-01-12 13:52 ` Tony Lindgren
2018-01-12 13:55 ` Andrew Lunn
2018-01-12 13:55 ` Andrew Lunn
2018-01-12 14:14 ` Tony Lindgren
2018-01-12 14:14 ` Tony Lindgren
2018-01-12 19:00 ` Tony Lindgren
2018-01-12 19:00 ` Tony Lindgren
2018-01-12 19:12 ` Mark Brown
2018-01-12 19:12 ` Mark Brown
2018-01-12 21:07 ` Tony Lindgren
2018-01-12 21:07 ` Tony Lindgren
2018-01-12 21:15 ` Mark Brown
2018-01-12 21:15 ` Mark Brown
2018-01-12 21:50 ` Tony Lindgren [this message]
2018-01-12 21:50 ` Tony Lindgren
2018-01-12 22:11 ` Mark Brown
2018-01-12 22:11 ` Mark Brown
2018-01-12 22:49 ` Tony Lindgren
2018-01-12 22:49 ` Tony Lindgren
2018-01-12 22:59 ` Mark Brown
2018-01-12 22:59 ` Mark Brown
2018-01-15 1:45 ` Kuninori Morimoto
2018-01-15 1:45 ` Kuninori Morimoto
2018-01-15 16:50 ` Tony Lindgren
2018-01-15 16:50 ` Tony Lindgren
2018-01-15 17:19 ` Mark Brown
2018-01-15 17:19 ` Mark Brown
2018-01-15 17:52 ` Tony Lindgren
2018-01-15 17:52 ` Tony Lindgren
2018-01-15 17:56 ` Mark Brown
2018-01-15 17:56 ` Mark Brown
2018-01-15 17:56 ` Mark Brown
2018-01-15 18:06 ` Tony Lindgren
2018-01-15 18:06 ` Tony Lindgren
2018-01-15 18:13 ` Mark Brown
2018-01-15 18:13 ` Mark Brown
2018-01-15 18:55 ` Tony Lindgren
2018-01-15 18:55 ` Tony Lindgren
2018-01-16 0:38 ` Kuninori Morimoto
2018-01-16 0:38 ` Kuninori Morimoto
2018-01-16 0:38 ` Kuninori Morimoto
2018-01-17 9:47 ` Peter Ujfalusi
2018-01-17 9:47 ` Peter Ujfalusi
2018-01-17 9:47 ` Peter Ujfalusi
2018-01-15 23:22 ` Kuninori Morimoto
2018-01-15 23:22 ` Kuninori Morimoto
2018-01-16 0:36 ` Tony Lindgren
2018-01-16 0:36 ` Tony Lindgren
2018-01-12 21:38 ` Mark Brown
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=20180112215010.GG4821@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.