| xj | b04a402 | 2021-11-25 15:01:52 +0800 | [diff] [blame] | 1 | =================== |
| 2 | ASoC jack detection |
| 3 | =================== |
| 4 | |
| 5 | ALSA has a standard API for representing physical jacks to user space, |
| 6 | the kernel side of which can be seen in include/sound/jack.h. ASoC |
| 7 | provides a version of this API adding two additional features: |
| 8 | |
| 9 | - It allows more than one jack detection method to work together on one |
| 10 | user visible jack. In embedded systems it is common for multiple |
| 11 | to be present on a single jack but handled by separate bits of |
| 12 | hardware. |
| 13 | |
| 14 | - Integration with DAPM, allowing DAPM endpoints to be updated |
| 15 | automatically based on the detected jack status (eg, turning off the |
| 16 | headphone outputs if no headphones are present). |
| 17 | |
| 18 | This is done by splitting the jacks up into three things working |
| 19 | together: the jack itself represented by a struct snd_soc_jack, sets of |
| 20 | snd_soc_jack_pins representing DAPM endpoints to update and blocks of |
| 21 | code providing jack reporting mechanisms. |
| 22 | |
| 23 | For example, a system may have a stereo headset jack with two reporting |
| 24 | mechanisms, one for the headphone and one for the microphone. Some |
| 25 | systems won't be able to use their speaker output while a headphone is |
| 26 | connected and so will want to make sure to update both speaker and |
| 27 | headphone when the headphone jack status changes. |
| 28 | |
| 29 | The jack - struct snd_soc_jack |
| 30 | ============================== |
| 31 | |
| 32 | This represents a physical jack on the system and is what is visible to |
| 33 | user space. The jack itself is completely passive, it is set up by the |
| 34 | machine driver and updated by jack detection methods. |
| 35 | |
| 36 | Jacks are created by the machine driver calling snd_soc_jack_new(). |
| 37 | |
| 38 | snd_soc_jack_pin |
| 39 | ================ |
| 40 | |
| 41 | These represent a DAPM pin to update depending on some of the status |
| 42 | bits supported by the jack. Each snd_soc_jack has zero or more of these |
| 43 | which are updated automatically. They are created by the machine driver |
| 44 | and associated with the jack using snd_soc_jack_add_pins(). The status |
| 45 | of the endpoint may configured to be the opposite of the jack status if |
| 46 | required (eg, enabling a built in microphone if a microphone is not |
| 47 | connected via a jack). |
| 48 | |
| 49 | Jack detection methods |
| 50 | ====================== |
| 51 | |
| 52 | Actual jack detection is done by code which is able to monitor some |
| 53 | input to the system and update a jack by calling snd_soc_jack_report(), |
| 54 | specifying a subset of bits to update. The jack detection code should |
| 55 | be set up by the machine driver, taking configuration for the jack to |
| 56 | update and the set of things to report when the jack is connected. |
| 57 | |
| 58 | Often this is done based on the status of a GPIO - a handler for this is |
| 59 | provided by the snd_soc_jack_add_gpio() function. Other methods are |
| 60 | also available, for example integrated into CODECs. One example of |
| 61 | CODEC integrated jack detection can be see in the WM8350 driver. |
| 62 | |
| 63 | Each jack may have multiple reporting mechanisms, though it will need at |
| 64 | least one to be useful. |
| 65 | |
| 66 | Machine drivers |
| 67 | =============== |
| 68 | |
| 69 | These are all hooked together by the machine driver depending on the |
| 70 | system hardware. The machine driver will set up the snd_soc_jack and |
| 71 | the list of pins to update then set up one or more jack detection |
| 72 | mechanisms to update that jack based on their current status. |