From: jsarha@ti•com (Jyri Sarha)
To: linux-arm-kernel@lists•infradead.org
Subject: OMAP 4430 SDP: rather sick with recent kernels
Date: Thu, 18 Dec 2014 15:12:10 +0200 [thread overview]
Message-ID: <5492D2AA.6090701@ti.com> (raw)
In-Reply-To: <0625abeb83cd4ed88fdb38754b6a3086@EMAIL.axentia.se>
On 12/18/2014 01:48 PM, Peter Rosin wrote:
> Russel King wrote:
> *snip*
>> Now, we have this call to snd_soc_of_parse_audio_routing(), which
>> allocates some memory, copies the old routes into it, and then adds
>> to them from DT. That explains why the pointer and number of routes
>> are different - there's 19 routes in omap4-sdp.dts - 17 + 19 = 36.
>> So that doesn't work - but importantly, it does point towards a
>> possible culpret - snd_soc_of_parse_audio_routing().
>>
>> This is obvious when you stop and think about what it's doing, this is
>> truely where this bug lies, and it /is/ in generic ASoC code.
>>
>> The problem is that this function doesn't consider the implications of
>> deferred probing. Let's see what happens if we defer, and re-do the
>> ABE initialisation, including calling this function:
>>
>> 17 + 19 = 36. - first probe
>> 17 + 19 + 19 = 55. - second probe
>>
>> Oh - that works in terms of the number, and it would also explain why
>> the table has been screwed - because the second time we memcpy(), we're
>> memcpy()ing from data which was allocated via devm_kzalloc(), and thus
>> would have been freed after the first failed probe.
>>
>> Mark - this is a core ASoC problem.
>
> Sorry about this, I wasn't even aware of deferred probing when I wrote
> f8781db8aeb1. From my point of view, it is certainly possible to solve this
> in the card driver which needs to add card dapm routes instead. So, a
> revert is fine by me, if no better solution comes up.
>
Looks to me that for this feature we would need a separate function,
something like:
int snd_soc_of_parse_audio_routing_append(struct snd_soc_card *card,
const char *propname);
even if the implementation behind would be the same. But I guess it is
little late for new designs at this phase.
Best regards,
Jyri
next prev parent reply other threads:[~2014-12-18 13:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-17 9:52 OMAP 4430 SDP: rather sick with recent kernels Russell King - ARM Linux
2014-12-17 17:23 ` Tony Lindgren
2014-12-17 17:33 ` Nishanth Menon
2014-12-17 17:34 ` Tony Lindgren
2014-12-17 18:51 ` Russell King - ARM Linux
2014-12-17 19:09 ` Tony Lindgren
2014-12-17 20:44 ` Tony Lindgren
2014-12-17 21:08 ` Jyri Sarha
2014-12-18 10:16 ` Russell King - ARM Linux
2014-12-18 11:48 ` Peter Rosin
2014-12-18 13:12 ` Jyri Sarha [this message]
2014-12-18 11:49 ` Mark Brown
2014-12-31 14:00 ` Peter Ujfalusi
2014-12-31 18:52 ` Mark Brown
2014-12-18 16:41 ` Tony Lindgren
2014-12-31 12:59 ` Peter Ujfalusi
2015-01-14 17:51 ` Russell King - ARM Linux
2015-01-14 19:09 ` Tony Lindgren
2015-01-14 22:27 ` Tony Lindgren
2015-01-14 23:10 ` Russell King - ARM Linux
2015-01-15 10:48 ` Russell King - ARM Linux
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=5492D2AA.6090701@ti.com \
--to=jsarha@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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