On 2/6/23 18:42, David Rau wrote:
-----Original Message-----
From: Guenter Roeck <groeck7@xxxxxxxxx> On Behalf Of Guenter Roeck
Sent: Monday, February 6, 2023 22:05
To: David Rau <david.rau.zg@xxxxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>
Cc: perex@xxxxxxxx; lgirdwood@xxxxxxxxx; tiwai@xxxxxxxx; support.opensource@xxxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH] ASoC: da7219: Fix pole orientation detection on OMTP headsets when playing music
On 2/5/23 21:38, David Rau wrote:
-----Original Message-----
From: Guenter Roeck <groeck7@xxxxxxxxx> On Behalf Of Guenter Roeck
Sent: Saturday, February 4, 2023 23:42
To: Mark Brown <broonie@xxxxxxxxxx>
Cc: David Rau <david.rau.zg@xxxxxxxxxxx>; perex@xxxxxxxx;
lgirdwood@xxxxxxxxx; tiwai@xxxxxxxx; support.opensource@xxxxxxxxxxx;
alsa-devel@xxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH] ASoC: da7219: Fix pole orientation detection on
OMTP headsets when playing music
On Thu, Feb 02, 2023 at 07:36:42PM +0000, Mark Brown wrote:
they have the potential to actually lock up are the
cancel_work_sync() calls but they were unchanged and the backtrace
you showed was showing the thread in the msleep(). My guess would
be that you've got systems where there are very frequent jack
detection events (potentiallly with broken accessories, or possibly
due to the ground switch putting things into the wrong
priority) and that the interrupt is firing again as soon as the
thread unmasks the primary interrupt which means it never actually stops running.
That is what I strongly suspect is happening. I don't know why
exactly the interrupt is firing continuously, but the hang is always in msleep().
One possibility might be that the event is actually a disconnect
event, and that enabling and immediately disabling the ground switch
causes another interrupt, which is then handled immediately, causing the hang.
Could be. I'd be willing to guess that it's not just one event but
rather a stream of events of some kind. Possibly if it's due to the
ground switch it's spuriously detecting a constant stream of button
presses for the affected systems, which don't produce any UI visible
result which would cause users to pull the accessory for whatever
reason? Whatever's going on I bet it's broken accessories triggering it.
That seems to be unlikely. The average number of crashes per affected system is 1.92, which points to something the users are doing and less to a broken accessory.
We do observe crashes due to broken accessories, but in those cases the number of crashes per system tends to be much > higher.
Anyway, below is a patch with a possible fix. Of course, I still don't know what the patch originally tried to fix, so it might not do much if anything good.
I added the software debouncing before insertion task to ensue the better compatibility of OMTP Jack.
For example, it keeps button detection in the interrupt handler to avoid dropping button events, so if spurious button detection as you suspected is indeed (part of) the problem we might still see a large number of interrupts.
Guenter
Thanks a lot for your big efforts to implement the temporary fix and verifications.
Would you please let me know the average number of crashes per affected system if you rollback to the pervious fix?
Ref:
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2
Fcommit%2Fsound%2Fsoc%2Fcodecs%3Fid%3D2d969e8f35b1849a43156029a7a6e294
3b89d0c0&data=05%7C01%7Cdavid.rau.zg%40renesas.com%7Cae6910f8ff4e4e299
bc408db084b1a2a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638112890
873388020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8KgHP%2FOD%2BTDcr
rUVSATFkDCDDmhiCu7d5%2FKhyOszThA%3D&reserved=0
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2
Fcommit%2Fsound%2Fsoc%2Fcodecs%3Fid%3D06f5882122e3faa183d76c4ec2c92f4c
38e2c7bb&data=05%7C01%7Cdavid.rau.zg%40renesas.com%7Cae6910f8ff4e4e299
bc408db084b1a2a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C638112890
873388020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WosfvANk0YxeJD5PG
%2FnAuAWVqt7m4U3mMaYXefLLdS4%3D&reserved=0
You mean just keep the above two patches and revert 969357ec94e6 ?
Sure, I can do that, but feedback from the field would take some
2-3 months. Is that what you recommend to do for now ?
Thanks,
Guenter
Thanks for the feedback.
What I mean is just do rollback to remove the "sleep" patch I did in your repository.
After the rollback, could you please let me know the average number of crashes per affected system with the same test conditions?
Will it still take some 2-3 months?
Yes, due to our rollout schedules. Those are crashes observed in the field,
after all.
Guenter
