| Message ID | 20210120214957.140232-5-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 8ade6d8b02b1ead741bd4f6c42921035caab6560 |
| Headers | show |
| Series | MFD/ASoC: Add support for Intel Bay Trail boards with WM5102 codec | expand |
On Wed, 20 Jan 2021, Hans de Goede wrote: > 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(+) 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.
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;