September 2019 - Patch - mailman.alsa-project.org

[PATCH v3] ASoC: Intel: Skylake: Recover BXT FW on DSP boot timeout error
by Pawel Harlozinski 12 Sep '19

12 Sep '19

When DSP boots with timeout error try to reload firmware to keep best user expeirience. Change-Id: Ic7377da687e7441a487c443f9de1ebae5967afa2 Signed-off-by: Szymon Mielczarek <szymonx.mielczarek(a)intel.com> Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> --- sound/soc/intel/skylake/bxt-sst.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/sound/soc/intel/skylake/bxt-sst.c b/sound/soc/intel/skylake/bxt-sst.c index 92a82e6b5fe6..fdf4c198445e 100644 --- a/sound/soc/intel/skylake/bxt-sst.c +++ b/sound/soc/intel/skylake/bxt-sst.c @@ -446,14 +446,19 @@ static int bxt_set_dsp_D0(struct sst_dsp *ctx, unsigned int core_id) /* If core 1 was turned on for booting core 0, turn it off */ skl_dsp_core_power_down(ctx, SKL_DSP_CORE_MASK(1)); + /* FIXME this FW recovery applies only for BXT */ if (ret == 0) { - dev_err(ctx->dev, "%s: DSP boot timeout\n", __func__); - dev_err(ctx->dev, "Error code=0x%x: FW status=0x%x\n", + dev_warn(ctx->dev, + "DSP boot timeout: Error code=0x%x: FW status=0x%x. Reloading FW\n", sst_dsp_shim_read(ctx, BXT_ADSP_ERROR_CODE), sst_dsp_shim_read(ctx, BXT_ADSP_FW_STATUS)); - dev_err(ctx->dev, "Failed to set core0 to D0 state\n"); - ret = -EIO; - goto err; + + ret = bxt_sst_init_fw(skl->dev, skl); + if (ret < 0) { + dev_err(ctx->dev, "Reload fw failed: %d. Failed to set core0 to D0 state\n", + ret); + goto err; + } } } @@ -478,7 +483,6 @@ static int bxt_set_dsp_D0(struct sst_dsp *ctx, unsigned int core_id) if (core_id == SKL_DSP_CORE0_ID) core_mask |= SKL_DSP_CORE_MASK(1); skl_dsp_disable_core(ctx, core_mask); - return ret; } -- 2.17.1

1 0

[RFC PATCH 1/3] ALSA:hda: Simplify and clear calculating SDxFMT
by Pawel Harlozinski 06 Sep '19

06 Sep '19

Set SDxFMT based only on given format, due to maxbps not always being set. Split cases for formats 20,24,32 bits. For format SNDRV_PCM_FORMAT_FLOAT_LE width is equal 32 so it will end up with same mask. Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> --- sound/hda/hdac_device.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c index b26cc93e7e10..add758e11b85 100644 --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -759,14 +759,13 @@ unsigned int snd_hdac_calc_stream_format(unsigned int rate, val |= AC_FMT_BITS_16; break; case 20: + val |= AC_FMT_BITS_20; + break; case 24: + val |= AC_FMT_BITS_24; + break; case 32: - if (maxbps >= 32 || format == SNDRV_PCM_FORMAT_FLOAT_LE) - val |= AC_FMT_BITS_32; - else if (maxbps >= 24) - val |= AC_FMT_BITS_24; - else - val |= AC_FMT_BITS_20; + val |= AC_FMT_BITS_32; break; default: return 0; -- 2.17.1

3 7

Re: [ALSA patch] [alsa-devel] [RFC PATCH 2/3] ALSA:core: Add rate 24kHz
by Takashi Iwai 05 Sep '19

05 Sep '19

On Thu, 05 Sep 2019 16:00:51 +0200, Pierre-Louis Bossart wrote: > > > >>>> Adds SNDRV_PCM_RATE_24000 at the bottom to keep backward compability > >>>> with alsa library. > >>>> > >>>> Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> > >>> > >>> No. Such a fancy rate has to be handled inside the driver locally > >>> instead of adding to the common rate. > >> > >> It's not that crazy, this is supported in the HDaudio spec: > >> > >> Sample Base Rate Divisor (DIV): > >> 000 = Divide by 1 (48 kHz, 44.1 kHz) > >> 001 = Divide by 2 (24 kHz, 22.05 kHz) > >> > >> I am not sure why 22.05 made the cut and not 24 kHz, they are both > >> derived from common clocks with the same divider... Same for 11.025 > >> and 12... > > > > I'm not against supporting it. It'd be fine if it were the changes > > that are applied only to HD-audio driver side. What I'm against is to > > change the ALSA PCM core. It's not necessarily done there at all. > > Humm, out of curiosity what is the issue here? Would this addition > break anything? I don't personally care too much but I've never quite > understood why the ALSA core only defined a subset of 'common' rates. It's simply a policy that we don't add a thing just because one driver wants for some reason possibly no one would actually use. In general such a core stuff is changed only when it has to be and inevitably necessary, and/or it'd be benefit for all the rest and majority users. thanks, Takashi

1 0

Re: [ALSA patch] [RFC PATCH 2/3] ALSA:core: Add rate 24kHz
by Takashi Iwai 05 Sep '19

05 Sep '19

On Thu, 05 Sep 2019 15:11:43 +0200, Pierre-Louis Bossart wrote: > > On 9/5/19 12:48 AM, Takashi Iwai wrote: > > On Thu, 05 Sep 2019 07:33:00 +0200, > > Pawel Harlozinski wrote: > >> > >> Adds SNDRV_PCM_RATE_24000 at the bottom to keep backward compability > >> with alsa library. > >> > >> Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> > > > > No. Such a fancy rate has to be handled inside the driver locally > > instead of adding to the common rate. > > It's not that crazy, this is supported in the HDaudio spec: > > Sample Base Rate Divisor (DIV): > 000 = Divide by 1 (48 kHz, 44.1 kHz) > 001 = Divide by 2 (24 kHz, 22.05 kHz) > > I am not sure why 22.05 made the cut and not 24 kHz, they are both > derived from common clocks with the same divider... Same for 11.025 > and 12... I'm not against supporting it. It'd be fine if it were the changes that are applied only to HD-audio driver side. What I'm against is to change the ALSA PCM core. It's not necessarily done there at all. thanks, Takashi

1 0