Hi Pierre-Louis,
On 8/2/21 3:45 PM, Pierre-Louis Bossart wrote:
On 8/1/21 4:04 PM, Hans de Goede wrote:
Some devices (HP Elitepad 1000 G2) have a second headphones output (1 on the dock, 2nd on the tablet itself) which is implemented through the line-out output of the codec combined with an external hp-amp which gets enabled through the codec's GPIO1 pin.
Add support for this through a new BYT_RT5640_LINEOUT_AS_HP2 quirk.
Signed-off-by: Hans de Goede hdegoede@redhat.com
sound/soc/intel/boards/bytcr_rt5640.c | 36 +++++++++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 70faba13450c..51fb44ad9b4b 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -74,6 +74,7 @@ enum { #define BYT_RT5640_MCLK_25MHZ BIT(23) #define BYT_RT5640_NO_SPEAKERS BIT(24) #define BYT_RT5640_LINEOUT BIT(25) +#define BYT_RT5640_LINEOUT_AS_HP2 BIT(26)
The definitions aren't fully clear to me. It seems that the two quirks above are mutually exclusive if I read the code below
- if (byt_rt5640_quirk & BYT_RT5640_LINEOUT_AS_HP2)
lineout_string = " cfg-hp2:lineout";
- else if (byt_rt5640_quirk & BYT_RT5640_LINEOUT) lineout_string = " cfg-lineout:1";
But in the following patch the two are mixed:
.driver_data = (void *)(BYT_RT5640_DMIC2_MAP |
BYT_RT5640_MCLK_EN |
BYT_RT5640_LINEOUT |
BYT_RT5640_LINEOUT_AS_HP2 |
BYT_RT5640_HSMIC2_ON_IN1),
so maybe the test above should be
if (byt_rt5640_quirk & BYT_RT5640_LINEOUT) { if (byt_rt5640_quirk & BYT_RT5640_LINEOUT_AS_HP2) lineout_string = " cfg-hp2:lineout"; else lineout_string = " cfg-lineout:1"; }
Right, I decided to first add plain line-out support (which may be useful elsewhere) and then to build the hp2-out using external-amp connected to lineout on top of that. So your suggestion to change the test to set the lineout_string makes sense. I'll fix that for v2 of the patch-series.
I am also not very clear on the hp2 support, is there any sort of jack detection or will this require always an explicit user choice?
Quoting from:
""" I've also figured out how jack-detect works, since the codec's GPIO1 is used for the external-hp-amp enable, the jack-detect signals are directly connected to the Bay Trail SoC's GPIOs:
-gpioget 'INT33FC:02' 14 && gpioget 'INT33FC:00' 0 && gpioget 'INT33FC:00' 3 Nothing inserted: 1 1 0 Headset in dock: 0 1 0 Headphon in dock: 0 1 1 Headset in tabl: 1 0 0 Headphon in tabl: 1 0 0 Conclusion: GPO2 pin 14: !jack in dock GPO0 pin 0: !jack in tablet GPO0 pin 3: 1 when jack in dock with no mic
And I believe that the mic on the tablet jack can be detected using the normal micBIAS over current detection which is normally also used.
This will require some special jack-detect handling inside the machine driver for this model. I plan to also add support for this when I have some time to work on this. """
So ATM this requires an explicit user-choice, but I plan to add support for jack-detect on both jacks when I've some more time to work on this.
Regards,
Hans