On Fri, Jun 08, 2012 at 11:37:54AM -0600, Stephen Warren wrote:
This problem can be triggered by fully initializing an audio card, then removing and re-inserting the machine driver module. This would leave mic detection enabled in HW, and mic_jack set to a stale value.
This isn't a good fix for this issue, - the fact that it works is more a sign that nobody got round to moving the interrupt registration to the I2C probe() function than anything else.
As an aside, I wondered instead about modifying wm8903_remove() to disable mic detection, and clear any status. However, even if we do that, I think we still want to make this change too, since I think we want probe() to work the first time without relying on previous HW state?
It does currently work without relying on previous hardware state, the first thing that we do with the chip as soon as we get control of it is a hard reset.
In terms of the mic detection itself it's really the responsibility of the machine driver to say that the jack doesn't exist any more when it's being removed - it should be calling wm8903_mic_detect() again during unregistration to disable the interrupt. Otherwise there's always going to be an interval where the jack object has been discarded but the CODEC driver is still active and could get an interrupt. That fix should be enough for 3.5.
Normally nobody cares about this because for most systems there's no realistic use case for removing a driver like this, it's something you're only going to run into during driver development.