Re: [PATCH] ASoC: da7219: Fix pole orientation detection on OMTP headsets when playing music

[Guenter Roeck]

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. 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

---