On Mon, Mar 13, 2017 at 02:52:56PM -0700, Brian Norris wrote:
> Sure, I can understand frustration with essentially contentless "bug
> reports." And I got frustrated by a seemingly pat response that was
> (IMO) a bit mistargeted.
It *is* a pat response, it's one of the things I find I have to sen
Hi Brian
> > The crasher was snd_dmaengine_pcm_register's platform ?
>
> No, actually it wasn't. It was spi2.0, which was a dummy, from
> snd_soc_dummy_probe(). But somehow snd_soc_platform_drv_pcm_new() got
> called for it...
Hmm.. I couldn't reproduce your issue on my system with dummy platfo
On Mon, Mar 13, 2017 at 12:50:04PM +, Mark Brown wrote:
> On Fri, Mar 10, 2017 at 04:24:07PM -0800, Brian Norris wrote:
> > On Thu, Mar 09, 2017 at 12:09:18PM +0100, Mark Brown wrote:
>
> > > Please think hard before including complete backtraces in upstream
> > > reports, they are very large
On Mon, Mar 13, 2017 at 03:46:00AM +, Kuninori Morimoto wrote:
> > There are 4 drivers calling that:
> >
> > snd_soc_dummy_probe
> > rt5514_spi_probe
> > 2 instances of snd_dmaengine_pcm_register, via rockchip_i2s_probe
> >
> > Only the latter two seem to run the assignment here:
> >
>
On Fri, Mar 10, 2017 at 04:24:07PM -0800, Brian Norris wrote:
> On Thu, Mar 09, 2017 at 12:09:18PM +0100, Mark Brown wrote:
> > Please think hard before including complete backtraces in upstream
> > reports, they are very large and contain almost no useful information
> > relative to their size so
Hi Brian
Thank you for your feedback
> There are 4 drivers calling that:
>
> snd_soc_dummy_probe
> rt5514_spi_probe
> 2 instances of snd_dmaengine_pcm_register, via rockchip_i2s_probe
>
> Only the latter two seem to run the assignment here:
>
> if (platform_drv->pcm_new)
>
Hi Kuninori,
On Thu, Mar 09, 2017 at 12:53:50AM +, Kuninori Morimoto wrote:
> > All I know is that I'm definitely hitting a NULL
> > platform->driver->pcm_new callback, and that either reverting your patch
> > or applying the patch I just sent fixes it.
>
> I want to know why this happen.
> C
On Thu, Mar 09, 2017 at 12:09:18PM +0100, Mark Brown wrote:
> On Wed, Mar 08, 2017 at 03:18:54PM -0800, Brian Norris wrote:
> > Not all platform drivers have pcm_{new,free} callbacks. Seen with a
> > "snd-soc-dummy" codec from sound/soc/rockchip/rk3399_gru_sound.c.
> >
> > Resolves an OOPS seen on
On Wed, Mar 08, 2017 at 03:18:54PM -0800, Brian Norris wrote:
> Not all platform drivers have pcm_{new,free} callbacks. Seen with a
> "snd-soc-dummy" codec from sound/soc/rockchip/rk3399_gru_sound.c.
>
> Resolves an OOPS seen on v4.11-rc1 with Google Kevin (Samsung Chromebook
> Plus):
>
> [2.
Hi Brian
> > It is a littlle bit strange for me.
>
> Yes, and honestly I'm a little confused by the inheritance in this
> framework.
Yes, I agree :)
This is 1st prepare for future ALSA SoC framework cleanup
It is Lars-Peter's idea
> I have a feeling you're checking the wrong thing below for th
Hi Brian
Thank you for your patch
> Not all platform drivers have pcm_{new,free} callbacks. Seen with a
> "snd-soc-dummy" codec from sound/soc/rockchip/rk3399_gru_sound.c.
(snip)
> Fixes: 99b04f4c4051 ("ASoC: add Component level pcm_new/pcm_free")
> Signed-off-by: Brian Norris
> ---
> I'm reall
Hi Kuninori,
On Thu, Mar 09, 2017 at 12:17:41AM +, Kuninori Morimoto wrote:
> > Not all platform drivers have pcm_{new,free} callbacks. Seen with a
> > "snd-soc-dummy" codec from sound/soc/rockchip/rk3399_gru_sound.c.
> (snip)
> > Fixes: 99b04f4c4051 ("ASoC: add Component level pcm_new/pcm_fre
Not all platform drivers have pcm_{new,free} callbacks. Seen with a
"snd-soc-dummy" codec from sound/soc/rockchip/rk3399_gru_sound.c.
Resolves an OOPS seen on v4.11-rc1 with Google Kevin (Samsung Chromebook
Plus):
[2.863304] rk3399-gru-sound sound: HiFi <-> ff88.i2s mapping ok
[2.8869
13 matches
Mail list logo
