--- /dev/null
+From b0cb099062b0c18246c3a20caaab4c0afc303255 Mon Sep 17 00:00:00 2001
+From: Scott Bahling <sbahling@suse.com>
+Date: Mon, 18 May 2020 19:57:28 +0200
+Subject: ALSA: iec1712: Initialize STDSP24 properly when using the model=staudio option
+
+From: Scott Bahling <sbahling@suse.com>
+
+commit b0cb099062b0c18246c3a20caaab4c0afc303255 upstream.
+
+The ST Audio ADCIII is an STDSP24 card plus extension box. With commit
+e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII") we
+enabled the ADCIII ports using the model=staudio option but forgot
+this part to ensure the STDSP24 card is initialized properly.
+
+Fixes: e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII")
+Signed-off-by: Scott Bahling <sbahling@suse.com>
+Cc: <stable@vger.kernel.org>
+BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1048934
+Link: https://lore.kernel.org/r/20200518175728.28766-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/pci/ice1712/ice1712.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/sound/pci/ice1712/ice1712.c
++++ b/sound/pci/ice1712/ice1712.c
+@@ -2377,7 +2377,8 @@ static int snd_ice1712_chip_init(struct
+ pci_write_config_byte(ice->pci, 0x61, ice->eeprom.data[ICE_EEP1_ACLINK]);
+ pci_write_config_byte(ice->pci, 0x62, ice->eeprom.data[ICE_EEP1_I2SID]);
+ pci_write_config_byte(ice->pci, 0x63, ice->eeprom.data[ICE_EEP1_SPDIF]);
+- if (ice->eeprom.subvendor != ICE1712_SUBDEVICE_STDSP24) {
++ if (ice->eeprom.subvendor != ICE1712_SUBDEVICE_STDSP24 &&
++ ice->eeprom.subvendor != ICE1712_SUBDEVICE_STAUDIO_ADCIII) {
+ ice->gpio.write_mask = ice->eeprom.gpiomask;
+ ice->gpio.direction = ice->eeprom.gpiodir;
+ snd_ice1712_write(ice, ICE1712_IREG_GPIO_WRITE_MASK,
--- /dev/null
+From e7513c5786f8b33f0c107b3759e433bc6cbb2efa Mon Sep 17 00:00:00 2001
+From: Brent Lu <brent.lu@intel.com>
+Date: Mon, 18 May 2020 12:30:38 +0800
+Subject: ALSA: pcm: fix incorrect hw_base increase
+
+From: Brent Lu <brent.lu@intel.com>
+
+commit e7513c5786f8b33f0c107b3759e433bc6cbb2efa upstream.
+
+There is a corner case that ALSA keeps increasing the hw_ptr but DMA
+already stop working/updating the position for a long time.
+
+In following log we can see the position returned from DMA driver does
+not move at all but the hw_ptr got increased at some point of time so
+snd_pcm_avail() will return a large number which seems to be a buffer
+underrun event from user space program point of view. The program
+thinks there is space in the buffer and fill more data.
+
+[ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
+[ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554
+...
+[ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362
+[ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
+[ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368
+
+This is because the hw_base will be increased by runtime->buffer_size
+frames unconditionally if the hw_ptr is not updated for over half of
+buffer time. As the hw_base increases, so does the hw_ptr increased
+by the same number.
+
+The avail value returned from snd_pcm_avail() could exceed the limit
+(buffer_size) easily becase the hw_ptr itself got increased by same
+buffer_size samples when the corner case happens. In following log,
+the buffer_size is 16368 samples but the avail is 21810 samples so
+CRAS server complains about it.
+
+[ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442
+[ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810
+
+cras_server[1907]: pcm_avail returned frames larger than buf_size:
+sof-glkda7219max: :0,5: 21810 > 16368
+
+By updating runtime->hw_ptr_jiffies each time the HWSYNC is called,
+the hw_base will keep the same when buffer stall happens at long as
+the interval between each HWSYNC call is shorter than half of buffer
+time.
+
+Following is a log captured by a patched kernel. The hw_base/hw_ptr
+value is fixed in this corner case and user space program should be
+aware of the buffer stall and handle it.
+
+[ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
+[ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584
+[ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488
+[ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392
+[ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
+...
+[ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
+
+Signed-off-by: Brent Lu <brent.lu@intel.com>
+Reviewed-by: Jaroslav Kysela <perex@perex.cz>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/core/pcm_lib.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/core/pcm_lib.c
++++ b/sound/core/pcm_lib.c
+@@ -440,6 +440,7 @@ static int snd_pcm_update_hw_ptr0(struct
+
+ no_delta_check:
+ if (runtime->status->hw_ptr == new_hw_ptr) {
++ runtime->hw_ptr_jiffies = curr_jiffies;
+ update_audio_tstamp(substream, &curr_tstamp, &audio_tstamp);
+ return 0;
+ }