Commit Graph

13 Commits

Author SHA1 Message Date
Thomas Gleixner 1802d0beec treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation this program is
  distributed in the hope that it will be useful but without any
  warranty without even the implied warranty of merchantability or
  fitness for a particular purpose see the gnu general public license
  for more details

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 655 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-30 11:26:41 -07:00
Ross Zwisler 0efa3334d6
ASoC: Intel: avoid Oops if DMA setup fails
Currently in sst_dsp_new() if we get an error return from sst_dma_new()
we just print an error message and then still complete the function
successfully.  This means that we are trying to run without sst->dma
properly set up, which will result in NULL pointer dereference when
sst->dma is later used.  This was happening for me in
sst_dsp_dma_get_channel():

        struct sst_dma *dma = dsp->dma;
	...
        dma->ch = dma_request_channel(mask, dma_chan_filter, dsp);

This resulted in:

   BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
   IP: sst_dsp_dma_get_channel+0x4f/0x125 [snd_soc_sst_firmware]

Fix this by adding proper error handling for the case where we fail to
set up DMA.

This change only affects Haswell and Broadwell systems.  Baytrail
systems explicilty opt-out of DMA via sst->pdata->resindex_dma_base
being set to -1.

Signed-off-by: Ross Zwisler <zwisler@google.com>
Cc: stable@vger.kernel.org
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-03 14:55:18 +09:00
Christoph Hellwig 3b99103849
ASoC: intel: don't pass GFP_DMA32 to dma_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-10-17 11:10:48 +01:00
Pierre-Louis Bossart ef3cb74233
ASoC: Intel: common: make sst_dma functions static
sst_dma_new and sst_dma_free are not used in any other file and don't
have a prototype. Move to static functions and remove
EXPORT_SYMBOL_GPL statement.

Reported by sparse warnings.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-25 17:21:15 +01:00
Arnd Bergmann adebc53218
ASoC: intel: include linux/module.h as needed
The MODULE_DESCRIPTION() macro is only available when including
the linux/module.h header. Apparently this is included indirectly
from sst-firmware.c in some configurations, but not in others:

sound/soc/intel/common/sst-firmware.c:1278:20: error: expected declaration specifiers or '...' before string constant
 MODULE_DESCRIPTION("Intel SST Firmware Loader");
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
sound/soc/intel/common/sst-firmware.c:1279:16: error: expected declaration specifiers or '...' before string constant

This adds the missing include line.

Fixes: a395bdd6b2 ("ASoC: intel: Fix sst-dsp dependency on dw stuff")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2017-11-02 11:20:37 +00:00
Colin Ian King 271ef65b58 ASoC: Intel: sst: remove redundant variable dma_dev_name
The pointer dma_dev_name is assigned but never read, it is redundant
and can therefore be removed.

Cleans up clang warning:
sound/soc/intel/common/sst-firmware.c:288:3: warning: Value stored to
'dma_dev_name' is never read

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2017-10-21 11:05:29 +01:00
Takashi Iwai a395bdd6b2 ASoC: intel: Fix sst-dsp dependency on dw stuff
The recent commit [a92ea59b74e2: ASoC: Intel: sst: only select
sst-firmware when DW DMAC is built-in] introduced more strict kconfig
dependency (depends on DW_DMAC_CORE=y) for avoiding the build failures
due to dependency messes in intel-sst.  This makes, however, it
impossible to use this driver with the modularized systems,
i.e. typically on Linux distros.

The problem addressed in the commit above is that sst_dsp_new() and
sst_dsp_free() includes the firmware init / finish that call dw_*()
functions.  Thus building it as built-in with DW_DMAC_CORE module
results in the missing symbols.

However, these sst_dsp functions are basically called only from the
drivers that depend on DW_DMAC_CORE already.  That is, once when these
functions are split out, the rest can be independent from dw stuff.

This patch attempts to solve the issue by the following:
- Split sst-dsp stuff into two modules: snd-soc-sst-dsp and
  snd-soc-sst-firmware.
- Move sst_dsp_new() and sst_dsp_free() to the latter module so that
  the former module can be independent from DW_DMAC_CORE.
- Add a new kconfig SND_SOC_INTEL_SST_FIRMWARE to select the latter
  module by machine drivers.

One only remaining pitfall is that each machine driver has to select
SND_SOC_INTEL_SST_FIRMWARE carefully depending on DW_DMAC_CORE.
This can't be done cleanly due to the restriction of the current
kbuild.

Bugzilla: https://bugzilla.opensuse.org/show_bug.cgi?id=988117
Fixes: a92ea59b74 ('ASoC: Intel: sst: only select sst-firmware when DW DMAC is built-in')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-11 18:19:23 +01:00
Andy Shevchenko 3a14c66d43 dmaengine: dw: pass platform data via struct dw_dma_chip
We pass struct dw_dma_chip to dw_dma_probe() anyway, thus we may use it to
pass a platform data as well.

While here, constify the source of the platform data.

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-05-02 15:31:05 +05:30
Jie Yang 1cf8dfd90f ASoC: Intel: sst: fix sst_memcpy32 wrong with non-4x bytes issue
sst_memcpy32() only copied bytes/4 32bits, which means it dropped
the remaining bytes%4 bytes wrongly.

Here add copying those missing bytes, first to a 32bits tmp, and
then write the tmp to 32bits iomem.

Signed-off-by: Jie Yang <yang.jie@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-12-16 12:28:04 +00:00
Julia Lawall 93189ea425 ASoC: Intel: constify sst_block_ops structures
The sst_block_ops structure is never modified, and is thus declared as
const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Jie Yang <yang.jie@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-11-16 17:38:54 +00:00
Andy Shevchenko b5e5a4549c ASoC: Intel: use dw_dmac autoconfiguration
Instead of hardconding a platform data for dw_dmac let's use it's own
autoconfiguration feature. Thus, remove hardcoded values.

Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-10-07 11:24:49 +01:00
Mark Brown aab0bb17ef Merge remote-tracking branch 'asoc/topic/intel' into asoc-next 2015-04-12 19:48:33 +01:00
Jie Yang 2106241a68 ASoC: Intel: create common folder and move common files in
Restructure the sound/soc/intel/ directory: create common folder, and move
sst common files here.

Signed-off-by: Jie Yang <yang.jie@intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-06 17:49:45 +01:00