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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
