| Message ID | 20231104142439.21983-1-hdegoede@redhat.com |
|---|---|
| Headers | show |
| Series | ASoC: Intel: bytcht_es8316: Determine quirks/routing through ACPI DSM | expand |
> This takes some of the work done to auto-configure quirks/routing for > ESS83xx codecs by getting the info from ACPI from: > https://github.com/thesofproject/linux/pull/4112 > > And then builds on top of this to add auto-configuration to > the bytcht_es8316 board driver. Sounds good, thanks for doing this Hans! I only have two minor questions, see below. > > Note compared to the pull-request, which deals with the ES8336, this > series deals with the ES8316 (for which I have several devices to test > on) and this moves all handling from the codec driver to the board > driver where this IMHO belongs. The ACPI stuff is in theory not Intel-specific, so not sure why it would belong in sound/soc/intel/boards? I initially put the code in sound/soc/codecs since the _DSM method is in the scope of the codec device HID. > After this series audio now works properly on a CHT Chuwi Hi12 tablet > without needing to add an extra quirk for that model. > > This has also been tested on the following devices, where things > are unchanged from before (the ACPI autoconfiguration gives the > same results as the old defaults) : > > Onda V80 plus (CHT) > GP-electronic T701 (BYT) > > I also tested this on a Nanote UMPC-01, here the _DSM result > for PLATFORM_SPK_TYPE_ARG wrongly returns 1 (mono) while > the device actually has 2 speakers, so this model needs to keep > its DMI quirk. What about the two others? /* Irbis NB41 */ /* Teclast X98 Plus II */ Are they part of your set of devices and could the quirks be removed?
Hi Pierre-Louis, On 11/6/23 15:51, Pierre-Louis Bossart wrote: > >> This takes some of the work done to auto-configure quirks/routing for >> ESS83xx codecs by getting the info from ACPI from: >> https://github.com/thesofproject/linux/pull/4112 >> >> And then builds on top of this to add auto-configuration to >> the bytcht_es8316 board driver. > > Sounds good, thanks for doing this Hans! I only have two minor > questions, see below. >> >> Note compared to the pull-request, which deals with the ES8336, this >> series deals with the ES8316 (for which I have several devices to test >> on) and this moves all handling from the codec driver to the board >> driver where this IMHO belongs. > > The ACPI stuff is in theory not Intel-specific, so not sure why it would > belong in sound/soc/intel/boards? I initially put the code in > sound/soc/codecs since the _DSM method is in the scope of the codec > device HID. So my thinking was that the _DSM method is something which the Windows drivers use and since Windows on ARM is all kinda special, that means that this basically is a ACPI-x86 platforms thing. The mistake which I made is that in my mind I replaced x86 with intel, so then it made sense to put this under sound/soc/intel. But of course there also is AMD (my main workstation actually uses an AMD CPU) and there also is sound/soc/amd . So thinking about this again I agree that the best place for the _DSM helpers is under sound/soc/codecs, so I'll move them back for v2. I do believe that at least for the ES8316 case the board driver is the right place to call the helpers though, since there the board driver sets up the MIC and speaker routes. >> After this series audio now works properly on a CHT Chuwi Hi12 tablet >> without needing to add an extra quirk for that model. >> >> This has also been tested on the following devices, where things >> are unchanged from before (the ACPI autoconfiguration gives the >> same results as the old defaults) : >> >> Onda V80 plus (CHT) >> GP-electronic T701 (BYT) >> >> I also tested this on a Nanote UMPC-01, here the _DSM result >> for PLATFORM_SPK_TYPE_ARG wrongly returns 1 (mono) while >> the device actually has 2 speakers, so this model needs to keep >> its DMI quirk. > > What about the two others? > > /* Irbis NB41 */ > /* Teclast X98 Plus II */ > > Are they part of your set of devices No I don't have these 2 devices in my collection. > and could the quirks be removed? Maybe, but since I cannot test I have decided to play it safe and leave the quirks in place. I'll prepare a v2 series moving the generic _DSM helpers back to sound/soc/codecs. Regards, Hans
Hi All, This takes some of the work done to auto-configure quirks/routing for ESS83xx codecs by getting the info from ACPI from: https://github.com/thesofproject/linux/pull/4112 And then builds on top of this to add auto-configuration to the bytcht_es8316 board driver. Note compared to the pull-request, which deals with the ES8336, this series deals with the ES8316 (for which I have several devices to test on) and this moves all handling from the codec driver to the board driver where this IMHO belongs. After this series audio now works properly on a CHT Chuwi Hi12 tablet without needing to add an extra quirk for that model. This has also been tested on the following devices, where things are unchanged from before (the ACPI autoconfiguration gives the same results as the old defaults) : Onda V80 plus (CHT) GP-electronic T701 (BYT) I also tested this on a Nanote UMPC-01, here the _DSM result for PLATFORM_SPK_TYPE_ARG wrongly returns 1 (mono) while the device actually has 2 speakers, so this model needs to keep its DMI quirk. Regards, Hans Hans de Goede (2): ASoC: Intel: bytcht_es8316: Add is_bytcr helper variable ASoC: Intel: bytcht_es8316: Determine quirks/routing with codec-dev ACPI DSM Pierre-Louis Bossart (2): ASoC: Intel: es83xx: add ACPI DSM helper module ASoC: Intel: bytcht_es8316: Dump basic _DSM information sound/soc/intel/boards/Kconfig | 5 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/bytcht_es8316.c | 71 +++- sound/soc/intel/boards/es83xx-dsm-common.c | 89 +++++ sound/soc/intel/boards/es83xx-dsm-common.h | 393 +++++++++++++++++++++ 5 files changed, 557 insertions(+), 3 deletions(-) create mode 100644 sound/soc/intel/boards/es83xx-dsm-common.c create mode 100644 sound/soc/intel/boards/es83xx-dsm-common.h