[PATCH v4 0/5] MFD/ASoC: Add support for Intel Bay Trail boards with WM5102 codec
Hi All,
Here is v4 of my series to add support for Intel Bay Trail based devices which use a WM5102 codec for audio output/input.
This was developed and tested on a Lenovo Yoga Tablet 1051L.
The MFD and ASoC parts do not have any build-time dependencies on each other. But the follow-up jack-detect series does have patches depending on each-other and on this series. So IMHO it would be best if this entire series would be merged through the MFD tree to make merging the follow-up series easier.
Mark, if that is ok with you (and you are happy with the ASoC changes) can you please Ack this ?
Changes in v4: - Add a comment to the irq-flags override explaining that theoretically DSDTs using IRQF_TRIGGER_FALLING could be correct on boards where the IRQ controller does not support active low level interrupts
Changes in v3: - Fix compilation error when CONFIG_ACPI is not set
Changes in v2: - Split my WM5102 work into 2 series, one series adding basic support for Bay Trail boards with a WM5102 codec and a second series with the jack-detect work - Various other minor code tweaks
Hans de Goede (4): mfd: arizona: Add MODULE_SOFTDEP("pre: arizona_ldo1") mfd: arizona: Replace arizona_of_get_type() with device_get_match_data() mfd: arizona: Add support for ACPI enumeration of WM5102 connected over SPI ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr()
Pierre-Louis Bossart (1): ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102
drivers/mfd/arizona-core.c | 11 - drivers/mfd/arizona-i2c.c | 11 +- drivers/mfd/arizona-spi.c | 138 +++++- drivers/mfd/arizona.h | 9 - sound/soc/intel/boards/Kconfig | 12 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/bytcr_wm5102.c | 465 ++++++++++++++++++ .../intel/common/soc-acpi-intel-byt-match.c | 16 + sound/soc/intel/common/soc-intel-quirks.h | 25 + 9 files changed, 661 insertions(+), 28 deletions(-) create mode 100644 sound/soc/intel/boards/bytcr_wm5102.c
Regards,
Hans
The (shared) probing code of the arizona-i2c and arizona-spi modules takes the following steps during init:
1. Call mfd_add_devices() for a set of early child-devices, this includes the arizona_ldo1 device which provides one of the core-regulators.
2. Bulk enable the core-regulators.
3. Read the device id.
4. Call mfd_add_devices() for the other child-devices.
This sequence depends on 1. leading to not only the child-device being created, but also the driver for the child-device binding to it and registering its regulator.
This requires the arizona_ldo1 driver to be loaded before the shared probing code runs. Add a softdep for this to both modules to ensure that this requirement is met.
Note this mirrors the existing MODULE_SOFTDEP("pre: wm8994_regulator") in the wm8994 code, which has a similar init sequence.
Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Charles Keepax ckeepax@opensource.cirrus.com Signed-off-by: Hans de Goede hdegoede@redhat.com --- drivers/mfd/arizona-i2c.c | 1 + drivers/mfd/arizona-spi.c | 1 + 2 files changed, 2 insertions(+)
diff --git a/drivers/mfd/arizona-i2c.c b/drivers/mfd/arizona-i2c.c index 4b58e3ad6eb6..2a4a3a164d0a 100644 --- a/drivers/mfd/arizona-i2c.c +++ b/drivers/mfd/arizona-i2c.c @@ -115,6 +115,7 @@ static struct i2c_driver arizona_i2c_driver = {
module_i2c_driver(arizona_i2c_driver);
+MODULE_SOFTDEP("pre: arizona_ldo1"); MODULE_DESCRIPTION("Arizona I2C bus interface"); MODULE_AUTHOR("Mark Brown broonie@opensource.wolfsonmicro.com"); MODULE_LICENSE("GPL"); diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c index 2633e147b76c..704f214d2614 100644 --- a/drivers/mfd/arizona-spi.c +++ b/drivers/mfd/arizona-spi.c @@ -110,6 +110,7 @@ static struct spi_driver arizona_spi_driver = {
module_spi_driver(arizona_spi_driver);
+MODULE_SOFTDEP("pre: arizona_ldo1"); MODULE_DESCRIPTION("Arizona SPI bus interface"); MODULE_AUTHOR("Mark Brown broonie@opensource.wolfsonmicro.com"); MODULE_LICENSE("GPL");
On Wed, 20 Jan 2021, Hans de Goede wrote:
The (shared) probing code of the arizona-i2c and arizona-spi modules takes the following steps during init:
- Call mfd_add_devices() for a set of early child-devices, this
includes the arizona_ldo1 device which provides one of the core-regulators.
Bulk enable the core-regulators.
Read the device id.
Call mfd_add_devices() for the other child-devices.
This sequence depends on 1. leading to not only the child-device being created, but also the driver for the child-device binding to it and registering its regulator.
This requires the arizona_ldo1 driver to be loaded before the shared probing code runs. Add a softdep for this to both modules to ensure that this requirement is met.
Note this mirrors the existing MODULE_SOFTDEP("pre: wm8994_regulator") in the wm8994 code, which has a similar init sequence.
Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Charles Keepax ckeepax@opensource.cirrus.com Signed-off-by: Hans de Goede hdegoede@redhat.com
drivers/mfd/arizona-i2c.c | 1 + drivers/mfd/arizona-spi.c | 1 + 2 files changed, 2 insertions(+)
Applied, thanks.
Replace the custom arizona_of_get_type() function with the generic device_get_match_data() helper. Besides being a nice cleanup this also makes it easier to add support for binding to ACPI enumerated devices.
While at it also fix a possible NULL pointer deref of the id argument to the probe functions (this could happen on e.g. manual driver binding through sysfs).
Suggested-by: Andy Shevchenko andy.shevchenko@gmail.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Charles Keepax ckeepax@opensource.cirrus.com Signed-off-by: Hans de Goede hdegoede@redhat.com --- Changes in v2: - New patch in v2 of this patchset --- drivers/mfd/arizona-core.c | 11 ----------- drivers/mfd/arizona-i2c.c | 10 ++++++---- drivers/mfd/arizona-spi.c | 10 ++++++---- drivers/mfd/arizona.h | 9 --------- 4 files changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c index 000cb82023e3..75f1bc671d59 100644 --- a/drivers/mfd/arizona-core.c +++ b/drivers/mfd/arizona-core.c @@ -797,17 +797,6 @@ const struct dev_pm_ops arizona_pm_ops = { EXPORT_SYMBOL_GPL(arizona_pm_ops);
#ifdef CONFIG_OF -unsigned long arizona_of_get_type(struct device *dev) -{ - const struct of_device_id *id = of_match_device(arizona_of_match, dev); - - if (id) - return (unsigned long)id->data; - else - return 0; -} -EXPORT_SYMBOL_GPL(arizona_of_get_type); - static int arizona_of_get_core_pdata(struct arizona *arizona) { struct arizona_pdata *pdata = &arizona->pdata; diff --git a/drivers/mfd/arizona-i2c.c b/drivers/mfd/arizona-i2c.c index 2a4a3a164d0a..5e83b730c4ce 100644 --- a/drivers/mfd/arizona-i2c.c +++ b/drivers/mfd/arizona-i2c.c @@ -23,14 +23,16 @@ static int arizona_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { + const void *match_data; struct arizona *arizona; const struct regmap_config *regmap_config = NULL; - unsigned long type; + unsigned long type = 0; int ret;
- if (i2c->dev.of_node) - type = arizona_of_get_type(&i2c->dev); - else + match_data = device_get_match_data(&i2c->dev); + if (match_data) + type = (unsigned long)match_data; + else if (id) type = id->driver_data;
switch (type) { diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c index 704f214d2614..798b88295c77 100644 --- a/drivers/mfd/arizona-spi.c +++ b/drivers/mfd/arizona-spi.c @@ -23,14 +23,16 @@ static int arizona_spi_probe(struct spi_device *spi) { const struct spi_device_id *id = spi_get_device_id(spi); + const void *match_data; struct arizona *arizona; const struct regmap_config *regmap_config = NULL; - unsigned long type; + unsigned long type = 0; int ret;
- if (spi->dev.of_node) - type = arizona_of_get_type(&spi->dev); - else + match_data = device_get_match_data(&spi->dev); + if (match_data) + type = (unsigned long)match_data; + else if (id) type = id->driver_data;
switch (type) { diff --git a/drivers/mfd/arizona.h b/drivers/mfd/arizona.h index 995efc6d7f32..801cbbcd71cb 100644 --- a/drivers/mfd/arizona.h +++ b/drivers/mfd/arizona.h @@ -50,13 +50,4 @@ int arizona_dev_exit(struct arizona *arizona); int arizona_irq_init(struct arizona *arizona); int arizona_irq_exit(struct arizona *arizona);
-#ifdef CONFIG_OF -unsigned long arizona_of_get_type(struct device *dev); -#else -static inline unsigned long arizona_of_get_type(struct device *dev) -{ - return 0; -} -#endif - #endif
On Wed, 20 Jan 2021, Hans de Goede wrote:
Replace the custom arizona_of_get_type() function with the generic device_get_match_data() helper. Besides being a nice cleanup this also makes it easier to add support for binding to ACPI enumerated devices.
While at it also fix a possible NULL pointer deref of the id argument to the probe functions (this could happen on e.g. manual driver binding through sysfs).
Suggested-by: Andy Shevchenko andy.shevchenko@gmail.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Charles Keepax ckeepax@opensource.cirrus.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Changes in v2:
- New patch in v2 of this patchset
drivers/mfd/arizona-core.c | 11 ----------- drivers/mfd/arizona-i2c.c | 10 ++++++---- drivers/mfd/arizona-spi.c | 10 ++++++---- drivers/mfd/arizona.h | 9 --------- 4 files changed, 12 insertions(+), 28 deletions(-)
Applied, thanks.
The Intel Bay Trail (x86/ACPI) based Lenovo Yoga Tablet 2 series use a WM5102 codec connected over SPI.
Add support for ACPI enumeration to arizona-spi so that arizona-spi can bind to the codec on these tablets.
This is loosely based on an earlier attempt (for Android-x86) at this by Christian Hartmann, combined with insights in things like the speaker GPIO from the android-x86 android port for the Lenovo Yoga Tablet 2 1051F/L [1].
[1] https://github.com/Kitsune2222/Android_Yoga_Tablet_2-1051F_Kernel
Cc: Christian Hartmann cornogle@googlemail.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com --- Changes in v4: - Add a comment to the irq-flags override explaining that theoretically DSDTs using IRQF_TRIGGER_FALLING could be correct on boards where the IRQ controller does not support active low level interrupts
Changes in v3: - Fix compilation error when CONFIG_ACPI is not set
Changes in v2: - Minor coding style tweaks - Use memcpy instead of for loop to copy gpiod_lookup-s - Log a warning when the ACPI "CLKE" call fails - Drop addition of acpi_device_get_match_data() call, as the code was moved over to use the generic device_get_match_data() helper in a (new in v2) preparation patch --- drivers/mfd/arizona-spi.c | 127 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+)
diff --git a/drivers/mfd/arizona-spi.c b/drivers/mfd/arizona-spi.c index 798b88295c77..24a2c75d691a 100644 --- a/drivers/mfd/arizona-spi.c +++ b/drivers/mfd/arizona-spi.c @@ -7,7 +7,10 @@ * Author: Mark Brown broonie@opensource.wolfsonmicro.com */
+#include <linux/acpi.h> #include <linux/err.h> +#include <linux/gpio/consumer.h> +#include <linux/gpio/machine.h> #include <linux/module.h> #include <linux/pm_runtime.h> #include <linux/regmap.h> @@ -15,11 +18,128 @@ #include <linux/slab.h> #include <linux/spi/spi.h> #include <linux/of.h> +#include <uapi/linux/input-event-codes.h>
#include <linux/mfd/arizona/core.h>
#include "arizona.h"
+#ifdef CONFIG_ACPI +const struct acpi_gpio_params reset_gpios = { 1, 0, false }; +const struct acpi_gpio_params ldoena_gpios = { 2, 0, false }; + +static const struct acpi_gpio_mapping arizona_acpi_gpios[] = { + { "reset-gpios", &reset_gpios, 1, }, + { "wlf,ldoena-gpios", &ldoena_gpios, 1 }, + { } +}; + +/* + * The ACPI resources for the device only describe external GPIO-s. They do + * not provide mappings for the GPIO-s coming from the Arizona codec itself. + */ +static const struct gpiod_lookup arizona_soc_gpios[] = { + { "arizona", 2, "wlf,spkvdd-ena", 0, GPIO_ACTIVE_HIGH }, + { "arizona", 4, "wlf,micd-pol", 0, GPIO_ACTIVE_LOW }, +}; + +/* + * The AOSP 3.5 mm Headset: Accessory Specification gives the following values: + * Function A Play/Pause: 0 ohm + * Function D Voice assistant: 135 ohm + * Function B Volume Up 240 ohm + * Function C Volume Down 470 ohm + * Minimum Mic DC resistance 1000 ohm + * Minimum Ear speaker impedance 16 ohm + * Note the first max value below must be less then the min. speaker impedance, + * to allow CTIA/OMTP detection to work. The other max values are the closest + * value from extcon-arizona.c:arizona_micd_levels halfway 2 button resistances. + */ +static const struct arizona_micd_range arizona_micd_aosp_ranges[] = { + { .max = 11, .key = KEY_PLAYPAUSE }, + { .max = 186, .key = KEY_VOICECOMMAND }, + { .max = 348, .key = KEY_VOLUMEUP }, + { .max = 752, .key = KEY_VOLUMEDOWN }, +}; + +static void arizona_spi_acpi_remove_lookup(void *lookup) +{ + gpiod_remove_lookup_table(lookup); +} + +static int arizona_spi_acpi_probe(struct arizona *arizona) +{ + struct gpiod_lookup_table *lookup; + acpi_status status; + int ret; + + /* Add mappings for the 2 ACPI declared GPIOs used for reset and ldo-ena */ + devm_acpi_dev_add_driver_gpios(arizona->dev, arizona_acpi_gpios); + + /* Add lookups for the SoCs own GPIOs used for micdet-polarity and spkVDD-enable */ + lookup = devm_kzalloc(arizona->dev, + struct_size(lookup, table, ARRAY_SIZE(arizona_soc_gpios) + 1), + GFP_KERNEL); + if (!lookup) + return -ENOMEM; + + lookup->dev_id = dev_name(arizona->dev); + memcpy(lookup->table, arizona_soc_gpios, sizeof(arizona_soc_gpios)); + + gpiod_add_lookup_table(lookup); + ret = devm_add_action_or_reset(arizona->dev, arizona_spi_acpi_remove_lookup, lookup); + if (ret) + return ret; + + /* Enable 32KHz clock from SoC to codec for jack-detect */ + status = acpi_evaluate_object(ACPI_HANDLE(arizona->dev), "CLKE", NULL, NULL); + if (ACPI_FAILURE(status)) + dev_warn(arizona->dev, "Failed to enable 32KHz clk ACPI error %d\n", status); + + /* + * Some DSDTs wrongly declare the IRQ trigger-type as IRQF_TRIGGER_FALLING + * The IRQ line will stay low when a new IRQ event happens between reading + * the IRQ status flags and acknowledging them. When the IRQ line stays + * low like this the IRQ will never trigger again when its type is set + * to IRQF_TRIGGER_FALLING. Correct the IRQ trigger-type to fix this. + * + * Note theoretically it is possible that some boards are not capable + * of handling active low level interrupts. In that case setting the + * flag to IRQF_TRIGGER_FALLING would not be a bug (and we would need + * to work around this) but so far all known usages of IRQF_TRIGGER_FALLING + * are a bug in the board's DSDT. + */ + arizona->pdata.irq_flags = IRQF_TRIGGER_LOW; + + /* Wait 200 ms after jack insertion */ + arizona->pdata.micd_detect_debounce = 200; + + /* Use standard AOSP values for headset-button mappings */ + arizona->pdata.micd_ranges = arizona_micd_aosp_ranges; + arizona->pdata.num_micd_ranges = ARRAY_SIZE(arizona_micd_aosp_ranges); + + return 0; +} + +static const struct acpi_device_id arizona_acpi_match[] = { + { + .id = "WM510204", + .driver_data = WM5102, + }, + { + .id = "WM510205", + .driver_data = WM5102, + }, + { } +}; +MODULE_DEVICE_TABLE(acpi, arizona_acpi_match); +#else +static int arizona_spi_acpi_probe(struct arizona *arizona) +{ + return -ENODEV; +} +#endif + static int arizona_spi_probe(struct spi_device *spi) { const struct spi_device_id *id = spi_get_device_id(spi); @@ -77,6 +197,12 @@ static int arizona_spi_probe(struct spi_device *spi) arizona->dev = &spi->dev; arizona->irq = spi->irq;
+ if (has_acpi_companion(&spi->dev)) { + ret = arizona_spi_acpi_probe(arizona); + if (ret) + return ret; + } + return arizona_dev_init(arizona); }
@@ -104,6 +230,7 @@ static struct spi_driver arizona_spi_driver = { .name = "arizona", .pm = &arizona_pm_ops, .of_match_table = of_match_ptr(arizona_of_match), + .acpi_match_table = ACPI_PTR(arizona_acpi_match), }, .probe = arizona_spi_probe, .remove = arizona_spi_remove,
On Wed, Jan 20, 2021 at 10:49:55PM +0100, Hans de Goede wrote:
The Intel Bay Trail (x86/ACPI) based Lenovo Yoga Tablet 2 series use a WM5102 codec connected over SPI.
Add support for ACPI enumeration to arizona-spi so that arizona-spi can bind to the codec on these tablets.
This is loosely based on an earlier attempt (for Android-x86) at this by Christian Hartmann, combined with insights in things like the speaker GPIO from the android-x86 android port for the Lenovo Yoga Tablet 2 1051F/L [1].
[1] https://github.com/Kitsune2222/Android_Yoga_Tablet_2-1051F_Kernel
Cc: Christian Hartmann cornogle@googlemail.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Acked-by: Charles Keepax ckeepax@opensource.cirrus.com
Thanks, Charles
On Wed, 20 Jan 2021, Hans de Goede wrote:
The Intel Bay Trail (x86/ACPI) based Lenovo Yoga Tablet 2 series use a WM5102 codec connected over SPI.
Add support for ACPI enumeration to arizona-spi so that arizona-spi can bind to the codec on these tablets.
This is loosely based on an earlier attempt (for Android-x86) at this by Christian Hartmann, combined with insights in things like the speaker GPIO from the android-x86 android port for the Lenovo Yoga Tablet 2 1051F/L [1].
[1] https://github.com/Kitsune2222/Android_Yoga_Tablet_2-1051F_Kernel
Cc: Christian Hartmann cornogle@googlemail.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Changes in v4:
- Add a comment to the irq-flags override explaining that theoretically DSDTs using IRQF_TRIGGER_FALLING could be correct on boards where the IRQ controller does not support active low level interrupts
Changes in v3:
- Fix compilation error when CONFIG_ACPI is not set
Changes in v2:
- Minor coding style tweaks
- Use memcpy instead of for loop to copy gpiod_lookup-s
- Log a warning when the ACPI "CLKE" call fails
- Drop addition of acpi_device_get_match_data() call, as the code was moved over to use the generic device_get_match_data() helper in a (new in v2) preparation patch
drivers/mfd/arizona-spi.c | 127 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+)
Applied, thanks.
Some Bay Trail systems: 1. Use a non CR version of the Bay Trail SoC 2. Contain at least 6 interrupt resources so that the platform_get_resource(pdev, IORESOURCE_IRQ, 5) check to workaround non CR systems which list their IPC IRQ at index 0 despite being non CR does not work 3. Despite 1. and 2. still have their IPC IRQ at index 0 rather then 5
Add a DMI quirk table to check for the few known models with this issue, so that the right IPC IRQ index is used on these systems.
Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Hans de Goede hdegoede@redhat.com --- sound/soc/intel/common/soc-intel-quirks.h | 25 +++++++++++++++++++++++ 1 file changed, 25 insertions(+)
diff --git a/sound/soc/intel/common/soc-intel-quirks.h b/sound/soc/intel/common/soc-intel-quirks.h index b07df3059926..a93987ab7f4d 100644 --- a/sound/soc/intel/common/soc-intel-quirks.h +++ b/sound/soc/intel/common/soc-intel-quirks.h @@ -11,6 +11,7 @@
#if IS_ENABLED(CONFIG_X86)
+#include <linux/dmi.h> #include <asm/cpu_device_id.h> #include <asm/intel-family.h> #include <asm/iosf_mbi.h> @@ -38,12 +39,36 @@ SOC_INTEL_IS_CPU(cml, KABYLAKE_L);
static inline bool soc_intel_is_byt_cr(struct platform_device *pdev) { + /* + * List of systems which: + * 1. Use a non CR version of the Bay Trail SoC + * 2. Contain at least 6 interrupt resources so that the + * platform_get_resource(pdev, IORESOURCE_IRQ, 5) check below + * succeeds + * 3. Despite 1. and 2. still have their IPC IRQ at index 0 rather then 5 + * + * This needs to be here so that it can be shared between the SST and + * SOF drivers. We rely on the compiler to optimize this out in files + * where soc_intel_is_byt_cr is not used. + */ + static const struct dmi_system_id force_bytcr_table[] = { + { /* Lenovo Yoga Tablet 2 series */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_MATCH(DMI_PRODUCT_FAMILY, "YOGATablet2"), + }, + }, + {} + }; struct device *dev = &pdev->dev; int status = 0;
if (!soc_intel_is_byt()) return false;
+ if (dmi_check_system(force_bytcr_table)) + return true; + if (iosf_mbi_available()) { u32 bios_status;
On Wed, 20 Jan 2021, Hans de Goede wrote:
Some Bay Trail systems:
- Use a non CR version of the Bay Trail SoC
- Contain at least 6 interrupt resources so that the platform_get_resource(pdev, IORESOURCE_IRQ, 5) check to workaround non CR systems which list their IPC IRQ at index 0 despite being non CR does not work
- Despite 1. and 2. still have their IPC IRQ at index 0 rather then 5
Add a DMI quirk table to check for the few known models with this issue, so that the right IPC IRQ index is used on these systems.
Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Hans de Goede hdegoede@redhat.com
sound/soc/intel/common/soc-intel-quirks.h | 25 +++++++++++++++++++++++ 1 file changed, 25 insertions(+)
Applied, thanks.
On Thu, Feb 04, 2021 at 01:56:16PM +0000, Lee Jones wrote:
Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Applied, thanks.
While we we were just having a discussion about what to do about this stuff...
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 01:56:16PM +0000, Lee Jones wrote:
Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Applied, thanks.
While we we were just having a discussion about what to do about this stuff...
We were?
This set has all the Acks we need to proceed. What's blocking?
On Thu, Feb 04, 2021 at 03:04:56PM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 01:56:16PM +0000, Lee Jones wrote:
Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Applied, thanks.
While we we were just having a discussion about what to do about this stuff...
We were?
This set has all the Acks we need to proceed. What's blocking?
There's the subsystem maintainer...
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 03:04:56PM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 01:56:16PM +0000, Lee Jones wrote:
Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Acked-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Applied, thanks.
While we we were just having a discussion about what to do about this stuff...
We were?
This set has all the Acks we need to proceed. What's blocking?
There's the subsystem maintainer...
I assume that was a question and you meant "where's"?
Pierre is listed as the Maintainer.
What is a Subsystem [0] anyway? ;)
[0] https://lwn.net/Articles/844539/
On Thu, Feb 04, 2021 at 03:40:58PM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 03:04:56PM +0000, Lee Jones wrote:
This set has all the Acks we need to proceed. What's blocking?
There's the subsystem maintainer...
I assume that was a question and you meant "where's"?
Pierre is listed as the Maintainer.
I'm fairly sure you can see what I meant here and why there might be a concern.
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 03:40:58PM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 03:04:56PM +0000, Lee Jones wrote:
This set has all the Acks we need to proceed. What's blocking?
There's the subsystem maintainer...
I assume that was a question and you meant "where's"?
Pierre is listed as the Maintainer.
I'm fairly sure you can see what I meant here and why there might be a concern.
So that should be a Reviewed-by and not an Acked-by then. That's fine.
What do you want to happen with this set then?
You want it broken up?
On Fri, Feb 05, 2021 at 08:34:16AM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 03:40:58PM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 03:04:56PM +0000, Lee Jones wrote:
This set has all the Acks we need to proceed. What's blocking?
There's the subsystem maintainer...
I assume that was a question and you meant "where's"?
Pierre is listed as the Maintainer.
I'm fairly sure you can see what I meant here and why there might be a concern.
So that should be a Reviewed-by and not an Acked-by then. That's fine.
No, it's that there's plenty of drivers like this that are listed in MAINTAINERS but still generally go through subsystem trees - this is also true of for quite a few MFD drivers, you tend to get a bit annoyed (quite reasonably) whenever I mistakenly pull MFD changes for them into one of my trees without syncing with you.
What do you want to happen with this set then?
You want it broken up?
I guess, or at least a pull request so it's in my tree and I'll notice any coverage issues.
On Fri, 05 Feb 2021, Mark Brown wrote:
On Fri, Feb 05, 2021 at 08:34:16AM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 03:40:58PM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 03:04:56PM +0000, Lee Jones wrote:
This set has all the Acks we need to proceed. What's blocking?
There's the subsystem maintainer...
I assume that was a question and you meant "where's"?
Pierre is listed as the Maintainer.
I'm fairly sure you can see what I meant here and why there might be a concern.
So that should be a Reviewed-by and not an Acked-by then. That's fine.
No, it's that there's plenty of drivers like this that are listed in MAINTAINERS but still generally go through subsystem trees - this is also true of for quite a few MFD drivers, you tend to get a bit annoyed (quite reasonably) whenever I mistakenly pull MFD changes for them into one of my trees without syncing with you.
Driver Maintainers in MFD don't sent Acks.
What do you want to happen with this set then?
You want it broken up?
I guess, or at least a pull request so it's in my tree and I'll notice any coverage issues.
Okay, I'll process it.
On Mon, Feb 08, 2021 at 08:33:50AM +0000, Lee Jones wrote:
On Fri, 05 Feb 2021, Mark Brown wrote:
No, it's that there's plenty of drivers like this that are listed in MAINTAINERS but still generally go through subsystem trees - this is also true of for quite a few MFD drivers, you tend to get a bit annoyed (quite reasonably) whenever I mistakenly pull MFD changes for them into one of my trees without syncing with you.
Driver Maintainers in MFD don't sent Acks.
Ah, that's not the case elsewhere (and there's the case where the driver maintainer is sending patches for their own driver which causes a bit of confusion).
I guess, or at least a pull request so it's in my tree and I'll notice any coverage issues.
Okay, I'll process it.
Thanks, pulled it in now.
From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
Add a new ASoc Machine driver for Intel Baytrail platforms with a Wolfson Microelectronics WM5102 codec.
This is based on a past contributions [1] from Paulo Sergio Travaglia pstglia@gmail.com based on the Levono kernel [2] combined with insights in things like the speaker GPIO from the android-x86 android port for the Lenovo Yoga Tablet 2 1051F/L [3].
[1] https://patchwork.kernel.org/project/alsa-devel/patch/593313f5.3636c80a.50e0... [2] https://github.com/lenovo-yt2-dev/android_kernel_lenovo_baytrail/blob/cm-12.... [3] https://github.com/Kitsune2222/Android_Yoga_Tablet_2-1051F_Kernel
The original machine driver from the Android ports was a crude modified copy of bytcr_rt5640.c adjusted to work with the WM5102 codec. This version has been extensively reworked to:
1. Remove all rt5640 related quirk handling. to the best of my knowledge this setup is only used on the Lenovo Yoga Tablet 2 series (8, 10 and 13 inch models) which all use the same setup. So there is no need to deal with all the variations with which we need to deal on rt5640 boards.
2. Rework clock handling, properly turn off the FLL and the platform-clock when they are no longer necessary and don't reconfigure the FLL unnecessarily when it is already running. This fixes a number of: "Timed out waiting for lock" warnings being logged.
3. Add the GPIO controlled Speaker-VDD regulator as a DAPM_SUPPLY
This only adds the machine driver and ACPI hooks, the BYT-CR detection quirk which these devices need will be added in a separate patch.
BugLink: https://github.com/thesofproject/linux/issues/2485 Co-authored-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com --- Changes in v2: - Drop unnecessary configuring of OPCLK - Fix error-msg when setting the SYSCLK fails --- sound/soc/intel/boards/Kconfig | 12 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/bytcr_wm5102.c | 465 ++++++++++++++++++ .../intel/common/soc-acpi-intel-byt-match.c | 16 + 4 files changed, 495 insertions(+) create mode 100644 sound/soc/intel/boards/bytcr_wm5102.c
diff --git a/sound/soc/intel/boards/Kconfig b/sound/soc/intel/boards/Kconfig index b58b9b60d37e..d1d28129a32b 100644 --- a/sound/soc/intel/boards/Kconfig +++ b/sound/soc/intel/boards/Kconfig @@ -111,6 +111,18 @@ config SND_SOC_INTEL_BYTCR_RT5651_MACH Say Y or m if you have such a device. This is a recommended option. If unsure select "N".
+config SND_SOC_INTEL_BYTCR_WM5102_MACH + tristate "Baytrail and Baytrail-CR with WM5102 codec" + depends on MFD_ARIZONA && MFD_WM5102 && SPI_MASTER && ACPI + depends on X86_INTEL_LPSS || COMPILE_TEST + select SND_SOC_ACPI + select SND_SOC_WM5102 + help + This adds support for ASoC machine driver for Intel(R) Baytrail and Baytrail-CR + platforms with WM5102 audio codec. + Say Y if you have such a device. + If unsure select "N". + config SND_SOC_INTEL_CHT_BSW_RT5672_MACH tristate "Cherrytrail & Braswell with RT5672 codec" depends on I2C && ACPI diff --git a/sound/soc/intel/boards/Makefile b/sound/soc/intel/boards/Makefile index 5f03e484b215..616c5fbab7d5 100644 --- a/sound/soc/intel/boards/Makefile +++ b/sound/soc/intel/boards/Makefile @@ -10,6 +10,7 @@ snd-soc-sst-sof-wm8804-objs := sof_wm8804.o snd-soc-sst-glk-rt5682_max98357a-objs := glk_rt5682_max98357a.o hda_dsp_common.o snd-soc-sst-bytcr-rt5640-objs := bytcr_rt5640.o snd-soc-sst-bytcr-rt5651-objs := bytcr_rt5651.o +snd-soc-sst-bytcr-wm5102-objs := bytcr_wm5102.o snd-soc-sst-cht-bsw-rt5672-objs := cht_bsw_rt5672.o snd-soc-sst-cht-bsw-rt5645-objs := cht_bsw_rt5645.o snd-soc-sst-cht-bsw-max98090_ti-objs := cht_bsw_max98090_ti.o @@ -51,6 +52,7 @@ obj-$(CONFIG_SND_SOC_INTEL_BDW_RT5650_MACH) += snd-soc-sst-bdw-rt5650-mach.o obj-$(CONFIG_SND_SOC_INTEL_BDW_RT5677_MACH) += snd-soc-sst-bdw-rt5677-mach.o obj-$(CONFIG_SND_SOC_INTEL_BYTCR_RT5640_MACH) += snd-soc-sst-bytcr-rt5640.o obj-$(CONFIG_SND_SOC_INTEL_BYTCR_RT5651_MACH) += snd-soc-sst-bytcr-rt5651.o +obj-$(CONFIG_SND_SOC_INTEL_BYTCR_WM5102_MACH) += snd-soc-sst-bytcr-wm5102.o obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_RT5672_MACH) += snd-soc-sst-cht-bsw-rt5672.o obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_RT5645_MACH) += snd-soc-sst-cht-bsw-rt5645.o obj-$(CONFIG_SND_SOC_INTEL_CHT_BSW_MAX98090_TI_MACH) += snd-soc-sst-cht-bsw-max98090_ti.o diff --git a/sound/soc/intel/boards/bytcr_wm5102.c b/sound/soc/intel/boards/bytcr_wm5102.c new file mode 100644 index 000000000000..f38850eb2eaf --- /dev/null +++ b/sound/soc/intel/boards/bytcr_wm5102.c @@ -0,0 +1,465 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * bytcr_wm5102.c - ASoc Machine driver for Intel Baytrail platforms with a + * Wolfson Microelectronics WM5102 codec + * + * Copyright (C) 2020 Hans de Goede hdegoede@redhat.com + * Loosely based on bytcr_rt5640.c which is: + * Copyright (C) 2014-2020 Intel Corp + * Author: Subhransu S. Prusty subhransu.s.prusty@intel.com + */ + +#include <linux/acpi.h> +#include <linux/clk.h> +#include <linux/device.h> +#include <linux/init.h> +#include <linux/module.h> +#include <linux/moduleparam.h> +#include <linux/platform_device.h> +#include <linux/slab.h> +#include <linux/spi/spi.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> +#include <sound/soc-acpi.h> +#include "../../codecs/wm5102.h" +#include "../atom/sst-atom-controls.h" + +#define MCLK_FREQ 25000000 + +#define WM5102_MAX_SYSCLK_4K 49152000 /* max sysclk for 4K family */ +#define WM5102_MAX_SYSCLK_11025 45158400 /* max sysclk for 11.025K family */ + +struct byt_wm5102_private { + struct clk *mclk; + struct gpio_desc *spkvdd_en_gpio; +}; + +static int byt_wm5102_spkvdd_power_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct snd_soc_card *card = w->dapm->card; + struct byt_wm5102_private *priv = snd_soc_card_get_drvdata(card); + + gpiod_set_value_cansleep(priv->spkvdd_en_gpio, + !!SND_SOC_DAPM_EVENT_ON(event)); + + return 0; +} + +static int byt_wm5102_prepare_and_enable_pll1(struct snd_soc_dai *codec_dai, int rate) +{ + struct snd_soc_component *codec_component = codec_dai->component; + int sr_mult = ((rate % 4000) == 0) ? + (WM5102_MAX_SYSCLK_4K / rate) : + (WM5102_MAX_SYSCLK_11025 / rate); + int ret; + + /* Reset FLL1 */ + snd_soc_dai_set_pll(codec_dai, WM5102_FLL1_REFCLK, ARIZONA_FLL_SRC_NONE, 0, 0); + snd_soc_dai_set_pll(codec_dai, WM5102_FLL1, ARIZONA_FLL_SRC_NONE, 0, 0); + + /* Configure the FLL1 PLL before selecting it */ + ret = snd_soc_dai_set_pll(codec_dai, WM5102_FLL1, ARIZONA_CLK_SRC_MCLK1, + MCLK_FREQ, rate * sr_mult); + if (ret) { + dev_err(codec_component->dev, "Error setting PLL: %d\n", ret); + return ret; + } + + ret = snd_soc_component_set_sysclk(codec_component, ARIZONA_CLK_SYSCLK, + ARIZONA_CLK_SRC_FLL1, rate * sr_mult, + SND_SOC_CLOCK_IN); + if (ret) { + dev_err(codec_component->dev, "Error setting SYSCLK: %d\n", ret); + return ret; + } + + ret = snd_soc_dai_set_sysclk(codec_dai, ARIZONA_CLK_SYSCLK, + rate * 512, SND_SOC_CLOCK_IN); + if (ret) { + dev_err(codec_component->dev, "Error setting clock: %d\n", ret); + return ret; + } + + return 0; +} + +static int platform_clock_control(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *k, int event) +{ + struct snd_soc_dapm_context *dapm = w->dapm; + struct snd_soc_card *card = dapm->card; + struct snd_soc_dai *codec_dai; + struct byt_wm5102_private *priv = snd_soc_card_get_drvdata(card); + int ret; + + codec_dai = snd_soc_card_get_codec_dai(card, "wm5102-aif1"); + if (!codec_dai) { + dev_err(card->dev, "Error codec DAI not found\n"); + return -EIO; + } + + if (SND_SOC_DAPM_EVENT_ON(event)) { + ret = clk_prepare_enable(priv->mclk); + if (ret) { + dev_err(card->dev, "Error enabling MCLK: %d\n", ret); + return ret; + } + ret = byt_wm5102_prepare_and_enable_pll1(codec_dai, 48000); + if (ret) { + dev_err(card->dev, "Error setting codec sysclk: %d\n", ret); + return ret; + } + } else { + /* + * The WM5102 has a separate 32KHz clock for jack-detect + * so we can disable the PLL, followed by disabling the + * platform clock which is the source-clock for the PLL. + */ + snd_soc_dai_set_pll(codec_dai, WM5102_FLL1, ARIZONA_FLL_SRC_NONE, 0, 0); + clk_disable_unprepare(priv->mclk); + } + + return 0; +} + +static const struct snd_soc_dapm_widget byt_wm5102_widgets[] = { + SND_SOC_DAPM_HP("Headphone", NULL), + SND_SOC_DAPM_MIC("Headset Mic", NULL), + SND_SOC_DAPM_MIC("Internal Mic", NULL), + SND_SOC_DAPM_SPK("Speaker", NULL), + SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0, + platform_clock_control, SND_SOC_DAPM_PRE_PMU | + SND_SOC_DAPM_POST_PMD), + SND_SOC_DAPM_SUPPLY("Speaker VDD", SND_SOC_NOPM, 0, 0, + byt_wm5102_spkvdd_power_event, + SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMU), +}; + +static const struct snd_soc_dapm_route byt_wm5102_audio_map[] = { + {"Headphone", NULL, "Platform Clock"}, + {"Headset Mic", NULL, "Platform Clock"}, + {"Internal Mic", NULL, "Platform Clock"}, + {"Speaker", NULL, "Platform Clock"}, + + {"Speaker", NULL, "SPKOUTLP"}, + {"Speaker", NULL, "SPKOUTLN"}, + {"Speaker", NULL, "SPKOUTRP"}, + {"Speaker", NULL, "SPKOUTRN"}, + {"Speaker", NULL, "Speaker VDD"}, + + {"Headphone", NULL, "HPOUT1L"}, + {"Headphone", NULL, "HPOUT1R"}, + + {"Internal Mic", NULL, "MICBIAS3"}, + {"IN3L", NULL, "Internal Mic"}, + + /* + * The Headset Mix uses MICBIAS1 or 2 depending on if a CTIA/OMTP Headset + * is connected, as the MICBIAS is applied after the CTIA/OMTP cross-switch. + */ + {"Headset Mic", NULL, "MICBIAS1"}, + {"Headset Mic", NULL, "MICBIAS2"}, + {"IN1L", NULL, "Headset Mic"}, + + {"AIF1 Playback", NULL, "ssp0 Tx"}, + {"ssp0 Tx", NULL, "modem_out"}, + + {"modem_in", NULL, "ssp0 Rx"}, + {"ssp0 Rx", NULL, "AIF1 Capture"}, +}; + +static const struct snd_kcontrol_new byt_wm5102_controls[] = { + SOC_DAPM_PIN_SWITCH("Headphone"), + SOC_DAPM_PIN_SWITCH("Headset Mic"), + SOC_DAPM_PIN_SWITCH("Internal Mic"), + SOC_DAPM_PIN_SWITCH("Speaker"), +}; + +static int byt_wm5102_init(struct snd_soc_pcm_runtime *runtime) +{ + struct snd_soc_card *card = runtime->card; + struct byt_wm5102_private *priv = snd_soc_card_get_drvdata(card); + int ret; + + card->dapm.idle_bias_off = true; + + ret = snd_soc_add_card_controls(card, byt_wm5102_controls, + ARRAY_SIZE(byt_wm5102_controls)); + if (ret) { + dev_err(card->dev, "Error adding card controls: %d\n", ret); + return ret; + } + + /* + * The firmware might enable the clock at boot (this information + * may or may not be reflected in the enable clock register). + * To change the rate we must disable the clock first to cover these + * cases. Due to common clock framework restrictions that do not allow + * to disable a clock that has not been enabled, we need to enable + * the clock first. + */ + ret = clk_prepare_enable(priv->mclk); + if (!ret) + clk_disable_unprepare(priv->mclk); + + ret = clk_set_rate(priv->mclk, MCLK_FREQ); + if (ret) { + dev_err(card->dev, "Error setting MCLK rate: %d\n", ret); + return ret; + } + + return 0; +} + +static const struct snd_soc_pcm_stream byt_wm5102_dai_params = { + .formats = SNDRV_PCM_FMTBIT_S16_LE, + .rate_min = 48000, + .rate_max = 48000, + .channels_min = 2, + .channels_max = 2, +}; + +static int byt_wm5102_codec_fixup(struct snd_soc_pcm_runtime *rtd, + struct snd_pcm_hw_params *params) +{ + struct snd_interval *rate = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_RATE); + struct snd_interval *channels = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_CHANNELS); + int ret; + + /* The DSP will covert the FE rate to 48k, stereo */ + rate->min = 48000; + rate->max = 48000; + channels->min = 2; + channels->max = 2; + + /* set SSP0 to 16-bit */ + params_set_format(params, SNDRV_PCM_FORMAT_S16_LE); + + /* + * Default mode for SSP configuration is TDM 4 slot, override config + * with explicit setting to I2S 2ch 16-bit. The word length is set with + * dai_set_tdm_slot() since there is no other API exposed + */ + ret = snd_soc_dai_set_fmt(asoc_rtd_to_cpu(rtd, 0), + SND_SOC_DAIFMT_I2S | + SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_CBS_CFS); + if (ret) { + dev_err(rtd->dev, "Error setting format to I2S: %d\n", ret); + return ret; + } + + ret = snd_soc_dai_set_tdm_slot(asoc_rtd_to_cpu(rtd, 0), 0x3, 0x3, 2, 16); + if (ret) { + dev_err(rtd->dev, "Error setting I2S config: %d\n", ret); + return ret; + } + + return 0; +} + +static int byt_wm5102_aif1_startup(struct snd_pcm_substream *substream) +{ + return snd_pcm_hw_constraint_single(substream->runtime, + SNDRV_PCM_HW_PARAM_RATE, 48000); +} + +static const struct snd_soc_ops byt_wm5102_aif1_ops = { + .startup = byt_wm5102_aif1_startup, +}; + +SND_SOC_DAILINK_DEF(dummy, + DAILINK_COMP_ARRAY(COMP_DUMMY())); + +SND_SOC_DAILINK_DEF(media, + DAILINK_COMP_ARRAY(COMP_CPU("media-cpu-dai"))); + +SND_SOC_DAILINK_DEF(deepbuffer, + DAILINK_COMP_ARRAY(COMP_CPU("deepbuffer-cpu-dai"))); + +SND_SOC_DAILINK_DEF(ssp0_port, + DAILINK_COMP_ARRAY(COMP_CPU("ssp0-port"))); + +SND_SOC_DAILINK_DEF(ssp0_codec, + DAILINK_COMP_ARRAY(COMP_CODEC( + /* + * Note there is no need to overwrite the codec-name as is done in + * other bytcr machine drivers, because the codec is a MFD child-dev. + */ + "wm5102-codec", + "wm5102-aif1"))); + +SND_SOC_DAILINK_DEF(platform, + DAILINK_COMP_ARRAY(COMP_PLATFORM("sst-mfld-platform"))); + +static struct snd_soc_dai_link byt_wm5102_dais[] = { + [MERR_DPCM_AUDIO] = { + .name = "Baytrail Audio Port", + .stream_name = "Baytrail Audio", + .nonatomic = true, + .dynamic = 1, + .dpcm_playback = 1, + .dpcm_capture = 1, + .ops = &byt_wm5102_aif1_ops, + SND_SOC_DAILINK_REG(media, dummy, platform), + + }, + [MERR_DPCM_DEEP_BUFFER] = { + .name = "Deep-Buffer Audio Port", + .stream_name = "Deep-Buffer Audio", + .nonatomic = true, + .dynamic = 1, + .dpcm_playback = 1, + .ops = &byt_wm5102_aif1_ops, + SND_SOC_DAILINK_REG(deepbuffer, dummy, platform), + }, + /* back ends */ + { + /* + * This must be named SSP2-Codec even though this machine driver + * always uses SSP0. Most machine drivers support both and dynamically + * update the dailink to point to SSP0 or SSP2, while keeping the name + * as "SSP2-Codec". The SOF tplg files hardcode the "SSP2-Codec" even + * in the byt-foo-ssp0.tplg versions because the other machine-drivers + * use "SSP2-Codec" even when SSP0 is used. + */ + .name = "SSP2-Codec", + .id = 0, + .no_pcm = 1, + .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF + | SND_SOC_DAIFMT_CBS_CFS, + .be_hw_params_fixup = byt_wm5102_codec_fixup, + .nonatomic = true, + .dpcm_playback = 1, + .dpcm_capture = 1, + .init = byt_wm5102_init, + SND_SOC_DAILINK_REG(ssp0_port, ssp0_codec, platform), + }, +}; + +/* use space before codec name to simplify card ID, and simplify driver name */ +#define SOF_CARD_NAME "bytcht wm5102" /* card name will be 'sof-bytcht wm5102' */ +#define SOF_DRIVER_NAME "SOF" + +#define CARD_NAME "bytcr-wm5102" +#define DRIVER_NAME NULL /* card name will be used for driver name */ + +/* SoC card */ +static struct snd_soc_card byt_wm5102_card = { + .owner = THIS_MODULE, + .dai_link = byt_wm5102_dais, + .num_links = ARRAY_SIZE(byt_wm5102_dais), + .dapm_widgets = byt_wm5102_widgets, + .num_dapm_widgets = ARRAY_SIZE(byt_wm5102_widgets), + .dapm_routes = byt_wm5102_audio_map, + .num_dapm_routes = ARRAY_SIZE(byt_wm5102_audio_map), + .fully_routed = true, +}; + +static int snd_byt_wm5102_mc_probe(struct platform_device *pdev) +{ + char codec_name[SND_ACPI_I2C_ID_LEN]; + struct device *dev = &pdev->dev; + struct byt_wm5102_private *priv; + struct snd_soc_acpi_mach *mach; + const char *platform_name; + struct acpi_device *adev; + struct device *codec_dev; + bool sof_parent; + int ret; + + priv = devm_kzalloc(dev, sizeof(*priv), GFP_ATOMIC); + if (!priv) + return -ENOMEM; + + /* Get MCLK */ + priv->mclk = devm_clk_get(dev, "pmc_plt_clk_3"); + if (IS_ERR(priv->mclk)) + return dev_err_probe(dev, PTR_ERR(priv->mclk), "getting pmc_plt_clk_3\n"); + + /* + * Get speaker VDD enable GPIO: + * 1. Get codec-device-name + * 2. Get codec-device + * 3. Get GPIO from codec-device + */ + mach = dev->platform_data; + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); + if (!adev) { + dev_err(dev, "Error cannot find acpi-dev for codec\n"); + return -ENOENT; + } + snprintf(codec_name, sizeof(codec_name), "spi-%s", acpi_dev_name(adev)); + put_device(&adev->dev); + + codec_dev = bus_find_device_by_name(&spi_bus_type, NULL, codec_name); + if (!codec_dev) + return -EPROBE_DEFER; + + /* Note no devm_ here since we call gpiod_get on codec_dev rather then dev */ + priv->spkvdd_en_gpio = gpiod_get(codec_dev, "wlf,spkvdd-ena", GPIOD_OUT_LOW); + put_device(codec_dev); + + if (IS_ERR(priv->spkvdd_en_gpio)) + return dev_err_probe(dev, PTR_ERR(priv->spkvdd_en_gpio), "getting spkvdd-GPIO\n"); + + /* override platform name, if required */ + byt_wm5102_card.dev = dev; + platform_name = mach->mach_params.platform; + ret = snd_soc_fixup_dai_links_platform_name(&byt_wm5102_card, platform_name); + if (ret) + goto out_put_gpio; + + /* set card and driver name and pm-ops */ + sof_parent = snd_soc_acpi_sof_parent(dev); + if (sof_parent) { + byt_wm5102_card.name = SOF_CARD_NAME; + byt_wm5102_card.driver_name = SOF_DRIVER_NAME; + dev->driver->pm = &snd_soc_pm_ops; + } else { + byt_wm5102_card.name = CARD_NAME; + byt_wm5102_card.driver_name = DRIVER_NAME; + } + + snd_soc_card_set_drvdata(&byt_wm5102_card, priv); + ret = devm_snd_soc_register_card(dev, &byt_wm5102_card); + if (ret) { + dev_err_probe(dev, ret, "registering card\n"); + goto out_put_gpio; + } + + platform_set_drvdata(pdev, &byt_wm5102_card); + return 0; + +out_put_gpio: + gpiod_put(priv->spkvdd_en_gpio); + return ret; +} + +static int snd_byt_wm5102_mc_remove(struct platform_device *pdev) +{ + struct snd_soc_card *card = platform_get_drvdata(pdev); + struct byt_wm5102_private *priv = snd_soc_card_get_drvdata(card); + + gpiod_put(priv->spkvdd_en_gpio); + return 0; +} + +static struct platform_driver snd_byt_wm5102_mc_driver = { + .driver = { + .name = "bytcr_wm5102", + }, + .probe = snd_byt_wm5102_mc_probe, + .remove = snd_byt_wm5102_mc_remove, +}; + +module_platform_driver(snd_byt_wm5102_mc_driver); + +MODULE_DESCRIPTION("ASoC Baytrail with WM5102 codec machine driver"); +MODULE_AUTHOR("Hans de Goede hdegoede@redhat.com"); +MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:bytcr_wm5102"); diff --git a/sound/soc/intel/common/soc-acpi-intel-byt-match.c b/sound/soc/intel/common/soc-acpi-intel-byt-match.c index c348607b49a5..ec7932549655 100644 --- a/sound/soc/intel/common/soc-acpi-intel-byt-match.c +++ b/sound/soc/intel/common/soc-acpi-intel-byt-match.c @@ -154,6 +154,22 @@ struct snd_soc_acpi_mach snd_soc_acpi_intel_baytrail_machines[] = { .sof_fw_filename = "sof-byt.ri", .sof_tplg_filename = "sof-byt-rt5651.tplg", }, + { + .id = "WM510204", + .drv_name = "bytcr_wm5102", + .fw_filename = "intel/fw_sst_0f28.bin", + .board = "bytcr_wm5102", + .sof_fw_filename = "sof-byt.ri", + .sof_tplg_filename = "sof-byt-wm5102.tplg", + }, + { + .id = "WM510205", + .drv_name = "bytcr_wm5102", + .fw_filename = "intel/fw_sst_0f28.bin", + .board = "bytcr_wm5102", + .sof_fw_filename = "sof-byt.ri", + .sof_tplg_filename = "sof-byt-wm5102.tplg", + }, { .id = "DLGS7212", .drv_name = "bytcht_da7213",
On Wed, Jan 20, 2021 at 10:49:57PM +0100, Hans de Goede wrote:
From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
Add a new ASoc Machine driver for Intel Baytrail platforms with a Wolfson Microelectronics WM5102 codec.
This is based on a past contributions [1] from Paulo Sergio Travaglia pstglia@gmail.com based on the Levono kernel [2] combined with insights in things like the speaker GPIO from the android-x86 android port for the Lenovo Yoga Tablet 2 1051F/L [3].
[1] https://patchwork.kernel.org/project/alsa-devel/patch/593313f5.3636c80a.50e0... [2] https://github.com/lenovo-yt2-dev/android_kernel_lenovo_baytrail/blob/cm-12.... [3] https://github.com/Kitsune2222/Android_Yoga_Tablet_2-1051F_Kernel
The original machine driver from the Android ports was a crude modified copy of bytcr_rt5640.c adjusted to work with the WM5102 codec. This version has been extensively reworked to:
- Remove all rt5640 related quirk handling. to the best of my knowledge
this setup is only used on the Lenovo Yoga Tablet 2 series (8, 10 and 13 inch models) which all use the same setup. So there is no need to deal with all the variations with which we need to deal on rt5640 boards.
- Rework clock handling, properly turn off the FLL and the platform-clock
when they are no longer necessary and don't reconfigure the FLL unnecessarily when it is already running. This fixes a number of: "Timed out waiting for lock" warnings being logged.
- Add the GPIO controlled Speaker-VDD regulator as a DAPM_SUPPLY
This only adds the machine driver and ACPI hooks, the BYT-CR detection quirk which these devices need will be added in a separate patch.
BugLink: https://github.com/thesofproject/linux/issues/2485 Co-authored-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Reviewed-by: Charles Keepax ckeepax@opensource.cirrus.com
Thanks, Charles
On Wed, 20 Jan 2021, Hans de Goede wrote:
From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
Add a new ASoc Machine driver for Intel Baytrail platforms with a Wolfson Microelectronics WM5102 codec.
This is based on a past contributions [1] from Paulo Sergio Travaglia pstglia@gmail.com based on the Levono kernel [2] combined with insights in things like the speaker GPIO from the android-x86 android port for the Lenovo Yoga Tablet 2 1051F/L [3].
[1] https://patchwork.kernel.org/project/alsa-devel/patch/593313f5.3636c80a.50e0... [2] https://github.com/lenovo-yt2-dev/android_kernel_lenovo_baytrail/blob/cm-12.... [3] https://github.com/Kitsune2222/Android_Yoga_Tablet_2-1051F_Kernel
The original machine driver from the Android ports was a crude modified copy of bytcr_rt5640.c adjusted to work with the WM5102 codec. This version has been extensively reworked to:
- Remove all rt5640 related quirk handling. to the best of my knowledge
this setup is only used on the Lenovo Yoga Tablet 2 series (8, 10 and 13 inch models) which all use the same setup. So there is no need to deal with all the variations with which we need to deal on rt5640 boards.
- Rework clock handling, properly turn off the FLL and the platform-clock
when they are no longer necessary and don't reconfigure the FLL unnecessarily when it is already running. This fixes a number of: "Timed out waiting for lock" warnings being logged.
- Add the GPIO controlled Speaker-VDD regulator as a DAPM_SUPPLY
This only adds the machine driver and ACPI hooks, the BYT-CR detection quirk which these devices need will be added in a separate patch.
BugLink: https://github.com/thesofproject/linux/issues/2485 Co-authored-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com Signed-off-by: Hans de Goede hdegoede@redhat.com
Changes in v2:
- Drop unnecessary configuring of OPCLK
- Fix error-msg when setting the SYSCLK fails
sound/soc/intel/boards/Kconfig | 12 + sound/soc/intel/boards/Makefile | 2 + sound/soc/intel/boards/bytcr_wm5102.c | 465 ++++++++++++++++++ .../intel/common/soc-acpi-intel-byt-match.c | 16 + 4 files changed, 495 insertions(+) create mode 100644 sound/soc/intel/boards/bytcr_wm5102.c
Applied, thanks.
Hi all,
On 1/20/21 10:49 PM, Hans de Goede wrote:
Hi All,
Here is v4 of my series to add support for Intel Bay Trail based devices which use a WM5102 codec for audio output/input.
This was developed and tested on a Lenovo Yoga Tablet 1051L.
The MFD and ASoC parts do not have any build-time dependencies on each other. But the follow-up jack-detect series does have patches depending on each-other and on this series. So IMHO it would be best if this entire series would be merged through the MFD tree to make merging the follow-up series easier.
Mark, if that is ok with you (and you are happy with the ASoC changes) can you please Ack this ?
I believe that this series and the follow-up:
"[PATCH v4 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support"
series are both ready for merging. All patches have Reviewed-by and/or Acked-by tags now.
I guess it is too late for 5.12, but it would be nice to at least formulate a plan for getting this merged after 5.12-rc1 is out. Given the interdependencies I still believe that it is best to merge all the patches through the mfd tree and then have Lee provide an immutable branch for the other subsystems to merge.
Mark and extcon-maintainers (for the follow-up series) may we have your ack for merging these through the MFD tree ?
Regards,
Hans
On Thu, 04 Feb 2021, Hans de Goede wrote:
Hi all,
On 1/20/21 10:49 PM, Hans de Goede wrote:
Hi All,
Here is v4 of my series to add support for Intel Bay Trail based devices which use a WM5102 codec for audio output/input.
This was developed and tested on a Lenovo Yoga Tablet 1051L.
The MFD and ASoC parts do not have any build-time dependencies on each other. But the follow-up jack-detect series does have patches depending on each-other and on this series. So IMHO it would be best if this entire series would be merged through the MFD tree to make merging the follow-up series easier.
Mark, if that is ok with you (and you are happy with the ASoC changes) can you please Ack this ?
I believe that this series and the follow-up:
"[PATCH v4 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support"
series are both ready for merging. All patches have Reviewed-by and/or Acked-by tags now.
I don't think they do. You're missing ASoC and Extcon Acks.
Not sure why *this* set fell through the cracks though. However, it's now on my to-review list.
If I can work fast enough, maybe this series can get into 5.12, but the follow-up still needs reviews.
It might be best to collect the *-bys you do have and [RESEND].
I guess it is too late for 5.12, but it would be nice to at least formulate a plan for getting this merged after 5.12-rc1 is out. Given the interdependencies I still believe that it is best to merge all the patches through the mfd tree and then have Lee provide an immutable branch for the other subsystems to merge.
Yes, that's fine.
Mark and extcon-maintainers (for the follow-up series) may we have your ack for merging these through the MFD tree ?
Ah, you noticed that too!
Hi,
On 2/4/21 11:57 AM, Lee Jones wrote:
On Thu, 04 Feb 2021, Hans de Goede wrote:
Hi all,
On 1/20/21 10:49 PM, Hans de Goede wrote:
Hi All,
Here is v4 of my series to add support for Intel Bay Trail based devices which use a WM5102 codec for audio output/input.
This was developed and tested on a Lenovo Yoga Tablet 1051L.
The MFD and ASoC parts do not have any build-time dependencies on each other. But the follow-up jack-detect series does have patches depending on each-other and on this series. So IMHO it would be best if this entire series would be merged through the MFD tree to make merging the follow-up series easier.
Mark, if that is ok with you (and you are happy with the ASoC changes) can you please Ack this ?
I believe that this series and the follow-up:
"[PATCH v4 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support"
series are both ready for merging. All patches have Reviewed-by and/or Acked-by tags now.
I don't think they do. You're missing ASoC and Extcon Acks.
Right, what I meant is that the patches have been reviewed by other stake-holders, including the follow-up series being tested by the cirrus codec folks (thank you Charles).
But yes the actual subsys maintainers have not acked these yet; and I'm aware that you will need those for merging this through the MFD tree.
Note that this series only requires Mark ack, the follow-up also touches extcon code, this one is purely MFD + ASoC patches.
Not sure why *this* set fell through the cracks though. However, it's now on my to-review list.
If I can work fast enough, maybe this series can get into 5.12, but the follow-up still needs reviews.
It might be best to collect the *-bys you do have and [RESEND].
Ok, will do.
I guess it is too late for 5.12, but it would be nice to at least formulate a plan for getting this merged after 5.12-rc1 is out. Given the interdependencies I still believe that it is best to merge all the patches through the mfd tree and then have Lee provide an immutable branch for the other subsystems to merge.
Yes, that's fine.
Mark and extcon-maintainers (for the follow-up series) may we have your ack for merging these through the MFD tree ?
Ah, you noticed that too!
Ack :)
Regards,
Hans
On Thu, Feb 04, 2021 at 12:07:49PM +0100, Hans de Goede wrote:
On 2/4/21 11:57 AM, Lee Jones wrote:
On Thu, 04 Feb 2021, Hans de Goede wrote:
series are both ready for merging. All patches have Reviewed-by and/or Acked-by tags now.
I don't think they do. You're missing ASoC and Extcon Acks.
Right, what I meant is that the patches have been reviewed by other stake-holders, including the follow-up series being tested by the cirrus codec folks (thank you Charles).
But yes the actual subsys maintainers have not acked these yet; and I'm aware that you will need those for merging this through the MFD tree.
The usual pattern here is that the MFD patches get merged and then I pull a shared branch in for any dependencies - at this point the series is now on the backlog of serieses where I'm waiting for the MFD to sort itself out before I really look at it again.
Hi,
On 2/4/21 1:43 PM, Mark Brown wrote:
On Thu, Feb 04, 2021 at 12:07:49PM +0100, Hans de Goede wrote:
On 2/4/21 11:57 AM, Lee Jones wrote:
On Thu, 04 Feb 2021, Hans de Goede wrote:
series are both ready for merging. All patches have Reviewed-by and/or Acked-by tags now.
I don't think they do. You're missing ASoC and Extcon Acks.
Right, what I meant is that the patches have been reviewed by other stake-holders, including the follow-up series being tested by the cirrus codec folks (thank you Charles).
But yes the actual subsys maintainers have not acked these yet; and I'm aware that you will need those for merging this through the MFD tree.
The usual pattern here is that the MFD patches get merged and then I pull a shared branch in for any dependencies - at this point the series is now on the backlog of serieses where I'm waiting for the MFD to sort itself out before I really look at it again.
I understand. But this series is somewhat special, if you also take the follow-up series into account:
"[PATCH v4 resend 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support"
That again has some MFD bits, and some extcon patches and ASoC patches which depend on the extcon bits and this series.
So it is really hard to merge all the bits through there separate trees and just merging it all through one tree and then pulling in the end-result as a shared branch would IMHO be easier.
In the follow-up series one of the patches is moving the jackdet code from the extcon dir to sound/asoc/codecs. So that is a single commit touching 2 trees ...
Regards,
Hans
On Thu, Feb 04, 2021 at 02:18:54PM +0100, Hans de Goede wrote:
On 2/4/21 1:43 PM, Mark Brown wrote:
The usual pattern here is that the MFD patches get merged and then I pull a shared branch in for any dependencies - at this point the series is now on the backlog of serieses where I'm waiting for the MFD to sort itself out before I really look at it again.
I understand. But this series is somewhat special, if you also take the follow-up series into account:
"[PATCH v4 resend 00/13] MFD/extcon/ASoC: Rework arizona codec jack-detect support"
That again has some MFD bits, and some extcon patches and ASoC patches which depend on the extcon bits and this series.
That series is drifting along in the same way AFAICT, and it's also got the extcon dependency so it'll need to leave it a bit longer for extcon review (unless some happens sooner).
So it is really hard to merge all the bits through there separate trees and just merging it all through one tree and then pulling in the end-result as a shared branch would IMHO be easier.
Most of this for me is just about not wanting to have to repeatedly look at the same series as it goes through small changes due to changes in the dependencies.
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 12:07:49PM +0100, Hans de Goede wrote:
On 2/4/21 11:57 AM, Lee Jones wrote:
On Thu, 04 Feb 2021, Hans de Goede wrote:
series are both ready for merging. All patches have Reviewed-by and/or Acked-by tags now.
I don't think they do. You're missing ASoC and Extcon Acks.
Right, what I meant is that the patches have been reviewed by other stake-holders, including the follow-up series being tested by the cirrus codec folks (thank you Charles).
But yes the actual subsys maintainers have not acked these yet; and I'm aware that you will need those for merging this through the MFD tree.
The usual pattern here is that the MFD patches get merged and then I pull a shared branch in for any dependencies - at this point the series is now on the backlog of serieses where I'm waiting for the MFD to sort itself out before I really look at it again.
I tend to push patches awaiting Acks to the back of the queue.
Stalemate.
On Thu, Feb 04, 2021 at 01:46:06PM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
The usual pattern here is that the MFD patches get merged and then I pull a shared branch in for any dependencies - at this point the series is now on the backlog of serieses where I'm waiting for the MFD to sort itself out before I really look at it again.
I tend to push patches awaiting Acks to the back of the queue.
Stalemate.
I'm only going to ack things if I expect to see them applied via another tree, that's generally what an ack means from a maintainer. Especially with ASoC where we keep on having subsystem wide changes quite often I'm not likely to do that for things like new drivers unless it's very clear what the timelines are.
It would be enormously helpful to get the bits of the core MFDs that create dependencies committed while the rest of the series is still in process, as well as allowing things to be applied it also helps with knowing if the dependencies are stable.
On Thu, 04 Feb 2021, Mark Brown wrote:
On Thu, Feb 04, 2021 at 01:46:06PM +0000, Lee Jones wrote:
On Thu, 04 Feb 2021, Mark Brown wrote:
The usual pattern here is that the MFD patches get merged and then I pull a shared branch in for any dependencies - at this point the series is now on the backlog of serieses where I'm waiting for the MFD to sort itself out before I really look at it again.
I tend to push patches awaiting Acks to the back of the queue.
Stalemate.
I'm only going to ack things if I expect to see them applied via another tree, that's generally what an ack means from a maintainer. Especially with ASoC where we keep on having subsystem wide changes quite often I'm not likely to do that for things like new drivers unless it's very clear what the timelines are.
It would be enormously helpful to get the bits of the core MFDs that create dependencies committed while the rest of the series is still in process, as well as allowing things to be applied it also helps with knowing if the dependencies are stable.
The default point-of-view is; if a patch was submitted as part of a set, it's likely that it makes the most sense to merge it as a set.
Very often sets will have inter-dependencies (usually headers) which would otherwise require the base patches to be applied (perhaps the MFD core and the headers) in one release, followed by the accompanying child device changes during a subsequent release. This doesn't scale well and puts the contributor in an unfair position.
This is how we usually work together. Why is ASoC so different?
On Thu, Feb 04, 2021 at 03:21:24PM +0000, Lee Jones wrote:
The default point-of-view is; if a patch was submitted as part of a set, it's likely that it makes the most sense to merge it as a set.
Blocking the whole series is itself not ideal since it means the whole large series keeps on getting resent for minor changes in individual patches where it's only a small number of leaf patches that have issues, with a lot of these serieses the reason they're bundled together is that there's some constants being added in one of the early patches that gets used everywhere else, not that there's a really a particularly strong relationship.
Very often sets will have inter-dependencies (usually headers) which would otherwise require the base patches to be applied (perhaps the MFD core and the headers) in one release, followed by the accompanying child device changes during a subsequent release. This doesn't scale well and puts the contributor in an unfair position.
You had been sharing pull requests for the common bits in the past which had resolved the dependency issues?
This is how we usually work together. Why is ASoC so different?
Like I say we've got active work that ends up doing subsystem wide interface changes on a fairly frequent basis which then creates issues if a new user pops up that's still trying to use the old API. Often it's fine but coordinating near the time is safer than just acking with a potentially long lead time on things actually going through.
Enjoy!
The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e:
Linux 5.11-rc1 (2020-12-27 15:30:22 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-asoc-v5.12
for you to fetch changes up to e933836744a2606e6cd42a6a83e5e43da2a60788:
mfd: arizona: Add support for ACPI enumeration of WM5102 connected over SPI (2021-02-04 13:55:34 +0000)
---------------------------------------------------------------- Immutable branch between MFD and [XXX] due for the v5.12 merge window
---------------------------------------------------------------- Hans de Goede (3): mfd: arizona: Add MODULE_SOFTDEP("pre: arizona_ldo1") mfd: arizona: Replace arizona_of_get_type() with device_get_match_data() mfd: arizona: Add support for ACPI enumeration of WM5102 connected over SPI
drivers/mfd/arizona-core.c | 11 ---- drivers/mfd/arizona-i2c.c | 11 ++-- drivers/mfd/arizona-spi.c | 138 +++++++++++++++++++++++++++++++++++++++++++-- drivers/mfd/arizona.h | 9 --- 4 files changed, 141 insertions(+), 28 deletions(-)
On Wed, 20 Jan 2021 22:49:52 +0100, Hans de Goede wrote:
Here is v4 of my series to add support for Intel Bay Trail based devices which use a WM5102 codec for audio output/input.
This was developed and tested on a Lenovo Yoga Tablet 1051L.
The MFD and ASoC parts do not have any build-time dependencies on each other. But the follow-up jack-detect series does have patches depending on each-other and on this series. So IMHO it would be best if this entire series would be merged through the MFD tree to make merging the follow-up series easier.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[4/5] ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() commit: 8ade6d8b02b1ead741bd4f6c42921035caab6560 [5/5] ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102 commit: 9a87fc1e061900e81ab13d823e85012a78849244
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
Hi Mark,
On 2/8/21 7:38 PM, Mark Brown wrote:
On Wed, 20 Jan 2021 22:49:52 +0100, Hans de Goede wrote:
Here is v4 of my series to add support for Intel Bay Trail based devices which use a WM5102 codec for audio output/input.
This was developed and tested on a Lenovo Yoga Tablet 1051L.
The MFD and ASoC parts do not have any build-time dependencies on each other. But the follow-up jack-detect series does have patches depending on each-other and on this series. So IMHO it would be best if this entire series would be merged through the MFD tree to make merging the follow-up series easier.
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[4/5] ASoC: Intel: Add DMI quirk table to soc_intel_is_byt_cr() commit: 8ade6d8b02b1ead741bd4f6c42921035caab6560 [5/5] ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102 commit: 9a87fc1e061900e81ab13d823e85012a78849244
Thank you.
Regards,
Hans
participants (4)
-
Charles Keepax
-
Hans de Goede
-
Lee Jones
-
Mark Brown