On Fri, May 15, 2015 at 10:40:59PM +0200, Lars-Peter Clausen wrote:
I think the proper way to support this is come up with the concept of jack detection providers and consumers. A component can register a jack detection provider just like it can register a DAI. And then in the board driver you'd just link the jack detection logic to the jack using the usual approach, which is also used for DAIs (e.g. of node or device name). The core would then take care of calling a enable callback or whatever is required to setup the jack detection logic in the driver.
Yes, nobody has really cared about it since we started pushing things out of the card init into the device level. We would also need to add a way to force microphone biases on for devices where that's not a part of the jack detection IP.
This would also nicely solve the issue with the GPIO jack detectors, where we currently can't really handle -EPROBE_DEFER. The GPIO would be requested by a jack detection provider which can request them before the card is registered rather than having to do the requesting in the card's init callback.
Cards should be able to do their requesting in their probe function prior to registering with the core even without anything else, though that needs a bit or refactoring too.