IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Small series that addresses a problem where DSP status dump
for a failure case, ends up being printed as as debug print. This
is important information for any bug report. While at it, the series
contains a few cleanups to related code.
Ranjani Sridharan (3):
ASoC: SOF: Intel: hda: remove duplicated status dump
ASoC: SOF: modify the SOF_DBG flags
ASoC: SOF: Intel: hda: fix the condition passed to sof_dev_dbg_or_err
sound/soc/sof/debug.c | 2 +-
sound/soc/sof/intel/byt.c | 2 +-
sound/soc/sof/intel/hda-loader.c | 19 +++++++++++++------
sound/soc/sof/intel/hda.c | 10 ++++------
sound/soc/sof/loader.c | 4 ++--
sound/soc/sof/ops.c | 2 +-
sound/soc/sof/sof-priv.h | 13 ++++++++-----
7 files changed, 30 insertions(+), 22 deletions(-)
--
2.29.2
The condition boot_iteration == HDA_FW_BOOT_ATTEMPTS to determine
the log level for the DSP status dump would only work in the case of DSP
init failure after maximum number of attempts to initialize the DSP. If
DSP init succeeds in less than HDA_FW_BOOT_ATTEMPTS attempts and FW
loading fails, the ROM status dump would end up getting logged as debug
instead of an error.
So, add a new flag, SOF_DBG_DUMP_LOG_ERROR, to explicitly specify
the log level for DSP status dump.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201211100743.3188821-4-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The "filter" debugfs file defines the log levels used by
the firmware and reported by sof-logger.
The file contains the formatted entry list, where each entry
follows the following syntax in plain text:
log_level uuid_id pipe_id comp_id;
This file may be updated by userspace applications such sof-logger,
or directly by the user during debugging process.
An unused (wildcard) pipe_id or comp_id value should be set to -1,
uuid_id is hexadecimal value, so when unused then should be set to 0.
When the file is modified, an IPC command is sent to FW with new
trace levels for selected components in filter elements list.
Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201204165014.2697903-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The module snd-intel-dspcfg, suggested by Jaroslav last year,
currently provide the means to select a PCI driver at run-time, based
on quirks, recommendations or user selection via a kernel
parameter. This capability removed a lot of confusions in
distributions and removed the need for recompilations to select legacy
HDaudio, SST or SOF drivers.
This patchset extends the concept to ACPI devices. This was driven by
the desire to at some point deprecate the Atom/SST driver for Baytrail
and Cherrytrail, which is no longer maintained by Intel. By having the
SOF driver enabled by distributions for Baytrail/Cherrytrail, we can
enable more end-user tests and make the transition easier for
distributions (likely in 2021 at this point).
This patchset provides the same solution for Broadwell, mainly to have
a single build for all Intel platforms. SOF on Broadwell remains an
option not recommended for distributions, as long as the 'catpt'
driver is maintained there is no burning desire to make SOF the
default on the three Broadwell-based platforms with the DSP
enabled.
Pierre-Louis Bossart (14):
ASoC: Intel: broadwell: add missing pm_ops
ASoC: Intel: bdw-rt5677: add missing pm_ops
ALSA: hda: intel-dsp-config: add helper for ACPI DSP driver selection
ASoC: soc-acpi: add helper to identify parent driver.
ASoC: Intel: boards: byt/cht: set card and driver name at run time
ASoC: Intel: byt/cht: set pm ops dynamically
ASoC: SOF: acpi: add dynamic selection of DSP driver
ASoC: Intel: Atom: add dynamic selection of DSP driver
ASoC: SOF: Intel: allow for coexistence between SOF and Atom/SST
drivers
ALSA: hda: intel-dsp-config: add Broadwell ACPI DSP driver selection
ASoC: Intel: broadwell: set card and driver name dynamically
ASoC: Intel: catpt: add dynamic selection of DSP driver
ASoC: SOF: Intel: allow for coexistence between SOF and catpt drivers
ALSA: hda: intel-dsp-config: ignore dsp_driver parameter for PCI
legacy devices
include/sound/intel-dsp-config.h | 7 ++
include/sound/soc-acpi.h | 6 +
sound/hda/intel-dsp-config.c | 111 +++++++++++++++++++
sound/soc/intel/Kconfig | 2 +
sound/soc/intel/atom/sst/sst_acpi.c | 8 ++
sound/soc/intel/boards/bdw-rt5650.c | 17 ++-
sound/soc/intel/boards/bdw-rt5677.c | 18 ++-
sound/soc/intel/boards/broadwell.c | 20 ++--
sound/soc/intel/boards/bytcht_cx2072x.c | 27 +++--
sound/soc/intel/boards/bytcht_da7213.c | 27 +++--
sound/soc/intel/boards/bytcht_es8316.c | 29 +++--
sound/soc/intel/boards/bytcr_rt5640.c | 30 +++--
sound/soc/intel/boards/bytcr_rt5651.c | 27 +++--
sound/soc/intel/boards/cht_bsw_max98090_ti.c | 29 +++--
sound/soc/intel/boards/cht_bsw_nau8824.c | 29 +++--
sound/soc/intel/boards/cht_bsw_rt5645.c | 38 ++++---
sound/soc/intel/boards/cht_bsw_rt5672.c | 29 +++--
sound/soc/intel/catpt/device.c | 12 ++
sound/soc/sof/intel/Kconfig | 33 +++---
sound/soc/sof/sof-acpi-dev.c | 14 ++-
20 files changed, 392 insertions(+), 121 deletions(-)
--
2.25.1
ASoC dapm controls currently don't support more than 2 channels. This is
a problem for SOF-based devices where individual volume control cannot
be provided on the 4 DMIC input path.
If we want to provide controls for more than 2 channels, this patch
suggests a simple solution based on an override of the info callback.
For example, in the case with 4 channel DMIC PGAs, a sof_info callback
would be used. Mono and stereo cases will keep using the existing dapm
info callback.
A longer-term solution would be to remove the limits to 2 channels in
ASoC/DAPM/topology. This is a topic Intel is currently looking into,
e.g. by removing the use of 'reg' and 'rreg' fields and use arrays
instead. Such changes will be rather intrusive and touch multiple codec
and platform drivers. Removing restrictions is the right thing to do,
but this will need to be done in steps with lots of validation.
Signed-off-by: Jaska Uimonen <jaska.uimonen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20201111173105.1927466-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Current SOF implementation limits period and buffer sizes to multiples
of period_min. Period_min is defined in topology, but is in practise set
to align with the SOF DSP timer tick (typically 1ms).
While this approach helps user-space to avoid period sizes, which are
not aligned to the DSP timer tick, it causes problems to applications
which want to align data processing size to that of ALSA period size.
One example is JACK audio server, which limits period sizes to power of
two values.
Other ALSA drivers where audio data transfer is driven by a timer tick,
like USB, do not constraint period and buffer sizes to exact multiple of
the timer tick.
To align SOF to follow the same behaviour, drop the additional alignment
constraints. As a side-effect, this patch can cause irregularity to
period wakeup timing. This happens when application chooses settings
which were previously forbidden. For example, if application configures
period size to 2^14 bytes and audio config of S32_LE/2ch/48000Hz, one
period represents 42.667ms of audio. Without this patch, this
configuration is not allowed by SOF. With the patch applied,
configuration is allowed but the wakeups are paced by the DSP timer
tick, which is typically 1ms. Application will see period wakeups with a
42/43/42/43ms repeating pattern.
Both approaches are valid within ALSA context, but relaxing the
constraints is better aligned with existing applications and other ALSA
drivers like USB audio.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20201118140545.2138895-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
SND_INTEL_DSP_CONFIG is selected by the HDaudio, Skylake and SOF
drivers. When the HDaudio link is not selected as a option, this
Kconfig option is not touched and will default to whatever other
drivers selected. In the case e.g. where HDaudio is compiled as
built-in, the linker will complain:
ld: sound/soc/sof/sof-pci-dev.o: in function `sof_pci_probe':
sof-pci-dev.c:(.text+0x5c): undefined reference to
`snd_intel_dsp_driver_probe'
Adding the select for all HDaudio platforms, regardless of whether
they rely on the HDaudio link or not, solves the problem.
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Fixes: 82d9d54a6c ('ALSA: hda: add Intel DSP configuration / probe code')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20201112164425.25603-5-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Series that fixes checks for 'size' in kcontrol get/put ext_bytes methods
for SOF. The gaps in these checks were discovered via cppcheck warnings
on unused variable values.
Pierre-Louis Bossart (5):
ASoC: SOF: control: fix size checks for ext_bytes control .get()
ASoC: SOF: control: fix size checks for volatile ext_bytes control
.get()
ASoC: SOF: control: add size checks for ext_bytes control .put()
ASoC: SOF: control: remove const in sizeof()
ASoC: SOF: topology: remove const in sizeof()
sound/soc/sof/control.c | 53 +++++++++++++++++++++++++++++++---------
sound/soc/sof/topology.c | 2 +-
2 files changed, 43 insertions(+), 12 deletions(-)
--
2.27.0
To provide backward compatibility to older systems, the SOF HDA driver
allows user to specify which HDMI codec driver to use at runtime via
kernel parameter. This mechanism has a subtle flaw in that it assumes
the codec drivers not to be loaded when the SOF PCI driver is loaded.
The problem is rooted in use of the hdev->type field.
snd_hdac_ext_bus_device_init() initializes this field to HDA_DEV_ASOC.
This signals the HDA core that ASoC drivers should be considered in
driver matching (hda_bus_match()). The SOF and SST drivers continue by
overriding this field to HDA_DEV_LEGACY and proceeding to load driver
modules with request_module(). Correct drivers will get loaded and
attached.
If however the codec drivers are already loaded when
snd_hdac_ext_bus_device_init() is called, the matching will not work as
expected as device type is still set to HDA_DEV_ASOC. Specifically if
hdac-hdmi is attached when machine driver is configured to use hdac-hda,
this leads to out-of-bounds memory access in
hda_dsp_hdmi_build_controls().
Fix the issue by adding codec type as a parameter to
snd_hdac_ext_bus_device_init() and ensuring type is set correctly from
the start.
Fixes: 139c7febad ("ASoC: SOF: Intel: add support for snd-hda-codec-hdmi")
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200921100841.2882662-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
cppcheck complains twice:
sound/soc/sof/control.c:436:2: style: Assignment of function parameter
has no effect outside the function. [uselessAssignmentArg]
size -= sizeof(const struct snd_ctl_tlv);
^
sound/soc/sof/control.c:436:7: style: Variable 'size' is assigned a
value that is never used. [unreadVariable]
size -= sizeof(const struct snd_ctl_tlv);
Somehow we dropped the checks for the size argument when upstreaming
the code, somewhere between v5 and v6.
Re-add a size check to avoid providing userspace with more data that
it asked for.
Also fix all error codes, we should return -ENOSPC instead of -EINVAL.
Fixes: c3078f5397 ('ASoC: SOF: Add Sound Open Firmware KControl support')
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20200921110814.2910477-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
