Apollo Lake seems to also suffer from IRQ timing issues. After being up for ~4
minutes, a Pentium N4200 system ends up falling back to workqueue-based IRQ
handling:

[  208.019906] snd_hda_intel 0000:00:0e.0: IRQ timing workaround is activated
for card #0. Suggest a bigger bdl_pos_adj.

Unfortunately, the Baytrail and Braswell workaround value of 32 samples isn't
enough to fix the issue here. Default to 64 samples.

Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
---
 sound/pci/hda/hda_intel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 2276adc84478..9fb54813693c 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1732,6 +1732,8 @@ static int default_bdl_pos_adj(struct azx *chip)
 		case 0x0f04: /* Baytrail */
 		case 0x2284: /* Braswell */
 			return 32;
+		case 0x5a98: /* Apollo Lake */
+			return 64;
 		}
 	}
 
-- 
2.43.0

On 1/22/2024 10:23 AM, Rui Salvaterra wrote:
> Apollo Lake seems to also suffer from IRQ timing issues. After being up for ~4
> minutes, a Pentium N4200 system ends up falling back to workqueue-based IRQ
> handling:
> 
> [  208.019906] snd_hda_intel 0000:00:0e.0: IRQ timing workaround is activated
> for card #0. Suggest a bigger bdl_pos_adj.
> 
> Unfortunately, the Baytrail and Braswell workaround value of 32 samples isn't
> enough to fix the issue here. Default to 64 samples.
> 
> Signed-off-by: Rui Salvaterra <rsalvaterra@gmail.com>
> ---
>   sound/pci/hda/hda_intel.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
> index 2276adc84478..9fb54813693c 100644
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1732,6 +1732,8 @@ static int default_bdl_pos_adj(struct azx *chip)
>   		case 0x0f04: /* Baytrail */
>   		case 0x2284: /* Braswell */
>   			return 32;
> +		case 0x5a98: /* Apollo Lake */
> +			return 64;
>   		}
>   	}
>   

And seems like I've missed some IDs, when doing PCI IDs conversion. 
Anyway, can you use PCI_DEVICE_ID_INTEL_HDA_APL instead of 0x5a98 as it 
is self describing (no need for comment)?

And if you want more patches in kernel - convert first 0x0f04 & 0x2284 
to PCI_DEVICE_ID_INTEL_HDA_BYT & PCI_DEVICE_ID_INTEL_HDA_BSW and then do 
the above change ;)

Hi, Amadeusz,

On Mon, 22 Jan 2024 at 11:05, Amadeusz Sławiński
<amadeuszx.slawinski@linux.intel.com> wrote:
>

[snipped]

> And seems like I've missed some IDs, when doing PCI IDs conversion.
> Anyway, can you use PCI_DEVICE_ID_INTEL_HDA_APL instead of 0x5a98 as it
> is self describing (no need for comment)?

Oh, of course! I would have done it if I knew we had those constants defined. :)

> And if you want more patches in kernel - convert first 0x0f04 & 0x2284
> to PCI_DEVICE_ID_INTEL_HDA_BYT & PCI_DEVICE_ID_INTEL_HDA_BSW and then do
> the above change ;)

Killing magic numbers is always a worthwhile goal. Expect a two-patch
series soon, then. ;)

Cheers,
Rui