On 09/28/2016 02:04 AM, Maciej S. Szmigiero wrote: > On 28.09.2016 01:29, Marek Vasut wrote: >> On 09/28/2016 01:23 AM, Maciej S. Szmigiero wrote: >>> On 26.09.2016 21:25, Marek Vasut wrote: >>>> On 09/26/2016 09:13 PM, Mark Brown wrote: >>> (..) >>>>> So, can we get a clear decision on this after testing? The discussion >>>>> here and the discussion on IRC are a bit disjointed and I'd like to make >>>>> sure we end up with something that definitely works. >>>>> >>>> I think 1,2,3,4 are certainly harmless. I think even 5 is harmless (at >>>> least according to my testing on MX6Q and MX6SX, which is not the >>>> greatest sample), but can be safely reverted if there are concerns. >>> >>> I've tested current sound/for-next on UDOO board and was able to reproduce >>> a lockup on reloading fsl sound modules. >>> The exact test was playing 30 second sound file and reloading modules in >>> a loop. >>> The lockup would happen sometimes almost immediately and sometimes after >>> ~30 minutes of such testing. >>> >>> When I reverted commit 7de2763d9b325ee5e7e24ac513c93394406cfefa >>> (that is, number 5) it seems that it no longer locks up. >> >> Do you have an explanation how would #5 cause this problem if it was >> supposed to fix it ? ;-) Can you share the backtrace ? > > I think the reason why it locks up is similar to previous case that it > locked up in similar circumstances with hardcoded register defaults - > there is some inconsistency between register value in cache and actual > value in hardware which then gets (partially?) rewritten with cached > value. > But I don't know the exact problematic register. > > It looks like the SoC just locks up after this error: > ac97-codec ac97-codec.0: ASoC: codec DAI prepare error: -22 This looks like a different error, can you poke into this please ? >>>> I also believe the following two patches should be backported for >>>> 4.7 (they were part of tag 'regmap-fix-v4.8-rc5' of >>>> git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap): >>>> >>>> commit b2c7f5d9c939a37c1ce7f86a642de70e3033ee9e >>>> Author: Maarten ter Huurne <maarten@xxxxxxxxxxxxxx> >>>> Date: Fri Jul 29 23:42:12 2016 +0200 >>>> >>>> regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw >>>> >>>> commit 1bc8da4e143c0fd8807e061a66d91d5972601ab1 >>>> Author: Lars-Peter Clausen <lars@xxxxxxxxxx> >>>> Date: Thu Aug 4 17:22:16 2016 +0200 >>>> >>>> regmap: rbtree: Avoid overlapping nodes >>>> >>> >>> I can see that >>> "regmap: cache: Fix num_reg_defaults computation from reg_defaults_raw" is >>> present in the tree that I have tested. >> >> And the rbtree patch is also present ? > > Yes - I commented only on the first one since you said it would probably > fix the rbtree crash (which I understand is the one which > patch 5 was also trying to fix). Seems like we have more problems then, sigh. btw I also had to revert 5881826ded79cf3c3314ee2d84c3bfa94e111b42 on latest next as it made my AC97 misbehave. > Maciej > -- Best regards, Marek Vasut _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
