My local build of v5.9.5 broke on this patch.
sound/soc/sof/intel/hda-codec.c: In function 'hda_codec_probe':
sound/soc/sof/intel/hda-codec.c:177:4: error: label 'error' used but
not defined
177 | goto error;
| ^~~~
make[4]: *** [scripts/Makefile.build:283:
sound/soc/sof/intel/h
if it
gets a error. Now copy this behavior to release resources and decrease
SOF device child_count to release SOF device.
Signed-off-by: Rander Wang
Reviewed-by: Pierre-Louis Bossart
Reviewed-by: Bard Liao
Reviewed-by: Guennadi Liakhovetski
Signed-off-by: Ranjani Sridharan
Li
sound/soc/intel/skylake/skl-topology.c: In function 'skl_tplg_complete':
sound/soc/intel/skylake/skl-topology.c:3642:1: warning: the frame size of 1256
bytes is larger than 1024 bytes [-Wframe-larger-than=]
3642 | }
| ^
vim +3642 sound/soc/intel/skylake/skl-topology.c
]
Fix this by initializing dynamically allocated sysfs attribute to keep lockdep
happy!
Fixes: bcac59029955 ("soundwire: add Slave sysfs support")
Signed-off-by: Srinivas Kandagatla
I added the exact same fix last Friday but you beat me to it.
Acked-by: Pierre-Louis Bossart
I don't think it came through in the commit message, but I wanted to mention
in the system that prompted this software does not control the LED. The LED
is actually controlled by hardware, but has circuitry to delay the hardware
mute until software mute is complete to avoid any "popping noises
Somehow this patch was filtered by alsa-devel servers?
On 11/3/20 7:12 AM, Mark Brown wrote:
On Tue, Nov 03, 2020 at 04:58:59AM -0800, Perry Yuan wrote:
From: perry_yuan
Some new Dell system is going to support audio internal micphone
privacy setting from hardware level with micmute led state
+static bool wsa_macro_adie_lb(struct snd_soc_component *component,
+ int interp_idx)
+{
+ u16 int_mux_cfg0 = 0, int_mux_cfg1 = 0;
these inits are ignored
+ u8 int_mux_cfg0_val = 0, int_mux_cfg1_val = 0;
these as well
+ u8 int_n_inp0 = 0, int_n_inp1 = 0, int_n
t for cml_rt1015_rt5682
ASoC: intel: sof_rt5682: Add quirk for Dooly
For the series
Acked-by: Pierre-Louis Bossart
Thanks Brent!
sound/soc/intel/boards/sof_rt5682.c | 65 +--
.../intel/common/soc-acpi-intel-cml-match.c | 13
2 files changed, 73 insertions(
On 10/30/20 11:44 AM, Lu, Brent wrote:
, Brent Lu wrote:
This DMI product family string of this board is "Google_Hatch" so the
DMI quirk will take place. However, this board is using rt1015 speaker
amp instead of max98357a specified in the quirk. Therefore, we need an
new DMI quirk for this b
On 10/30/20 1:36 AM, Brent Lu wrote:
This DMI product family string of this board is "Google_Hatch" so the
DMI quirk will take place. However, this board is using rt1015 speaker
amp instead of max98357a specified in the quirk. Therefore, we need an
new DMI quirk for this board.
Do you actual
+#define SDW_SDCA_CTL(fun, ent, ctl, ch)(BIT(30) |
\
+(((fun) & 0x7) << 22) | \
+(((ent) & 0x40) << 15) | \
+
diff --git a/sound/soc/codecs/lpass-va-macro.c
b/sound/soc/codecs/lpass-va-macro.c
new file mode 100644
index ..8cb23c32631d
--- /dev/null
+++ b/sound/soc/codecs/lpass-va-macro.c
@@ -0,0 +1,882 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
Missing copyright information?
[...]
+static int wsa_macro_enable_mix_path(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol *kcontrol, int event)
+{
+ struct snd_soc_component *component =
snd_soc_dapm_to_component(w->dapm);
+ u16 gain_reg;
+ int offset_val = 0;
+ int
+static int wsa_macro_set_prim_interpolator_rate(struct snd_soc_dai *dai,
+ u8 int_prim_fs_rate_reg_val,
+ u32 sample_rate)
+{
+ u8 int_1_mix1_inp;
+ u32 j, port = 0;
nit-pick: initializati
@@ -452,11 +454,11 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s
*i2s,
case SND_SOC_DAIFMT_DSP_B:
case SND_SOC_DAIFMT_LEFT_J:
case SND_SOC_DAIFMT_RIGHT_J:
- lrck_period = params_physical_width(params) * slots;
+ lrck_period = sl
On 10/27/20 5:15 AM, Srinivas Kandagatla wrote:
Thanks Pierre for review on all the patches.
On 26/10/2020 19:58, Pierre-Louis Bossart wrote:
Run cppcheck on this sort of code:
cppcheck --platform=unix32 --force --max-configs=1024 --inconclusive
--enable=all --suppress=variableScope sound
+static int wsa_macro_set_prim_interpolator_rate(struct snd_soc_dai *dai,
+ u8 int_prim_fs_rate_reg_val,
+ u32 sample_rate)
+{
+ u8 int_1_mix1_inp;
+ u32 j, port;
+ u16 int_mux_cfg0, in
On 10/23/20 11:51 PM, Keith Tzneg wrote:
From: Keith Tzeng
Machine driver to enable RT5682 on SSP0, DMIC, HDMI and RT1015 AMP on
SSP1: Enabled 4 CH TDM playback with 24 bit data.
Same comment for the third time: there is no reason to add an entire
machine driver just to replace one amplif
+static int va_dmic_clk_enable(struct snd_soc_component *component,
+ u32 dmic, bool enable)
+{
+ struct va_macro *va = snd_soc_component_get_drvdata(component);
+ u8 dmic_clk_en = 0x01;
+ u16 dmic_clk_reg = 0;
+ s32 *dmic_clk_cnt = NULL;
+
+static int wsa_macro_mclk_event(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol, int event)
+{
+ struct snd_soc_component *component =
snd_soc_dapm_to_component(w->dapm);
+ struct wsa_macro *wsa = snd_soc_component_get_drvdata(component
On 10/26/20 7:11 AM, Greg KH wrote:
On Mon, Oct 26, 2020 at 01:53:46AM -0400, Sasha Levin wrote:
This is a note to let you know that I've just added the patch titled
ASoC: topology: disable size checks for bytes_ext controls if needed
to the 4.9-stable tree which can be found at:
On 10/21/20 2:26 AM, Brent Lu wrote:
The default quirk data of sof_rt5682 is for tgl platform. For cml
platforms to reuse this driver, the flag SOF_RT5682_MCLK_24MHZ is
necessary to setup codec asrc correctly.
Signed-off-by: Brent Lu
---
sound/soc/intel/boards/sof_rt5682.c | 5 +
1 fi
On 10/19/20 10:58 AM, Keith Tzneg wrote:
From: Keith Tzeng
Machine driver to enable RT5682 on SSP0, DMIC, HDMI and RT1015 AMP on
SSP1: Enabled 4 CH TDM playback with 24 bit data.
Signed-off-by: Keith Tzeng
---
sound/soc/intel/boards/Kconfig| 17 +
sound/soc/intel/bo
On 10/18/20 8:41 PM, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 7cf726a59435301046250c42131554d9ccc566b8
commit: 285880a23d105e5d34b311b0c44061dffb07e405 ASoC: SOF: Make creation of
machine device from SOF core optional
On 10/13/20 9:56 PM, Randy Dunlap wrote:
Cc: Pierre-Louis Bossart
Cc: Liam Girdwood
Cc: Ranjani Sridharan
Cc: Kai Vehmanen
Cc: Daniel Baluta
Cc: sound-open-firmw...@alsa-project.org
Cc: alsa-de...@alsa-project.org
Some general editing of sound/soc/sof/ Kconfig files:
Thanks Randy
son 0x03
[ 16.584246] CR2: 0050
[ 16.584248] ---[ end trace c8511d090c11edff ]---
Suggested-by: Łukasz Majczak
Fixes: 2e5894d73789e ("ASoC: pcm: Add support for DAI multicodec")
Signed-off-by: Tomasz Figa
Acked-by: Pierre-Louis Bossart
Thanks!
---
sound/soc/in
On 9/25/20 4:28 AM, Srinivas Kandagatla wrote:
Usage of regmap_field_alloc becomes much overhead when number of fields
exceed more than 3.
QCOM LPASS driver has extensively converted to use regmap_fileds.
Multiple typos scattered in this patch: fileds -> fields?
Using new bluk api to allo
I think [1] should be an error instead of a warning
by default.
would the following patch be what you have in mind?
No.
error() does not exist.
merror() exists, but the difference from warn()
is just a prefix.
If any error happens, modpost should return the error code.
Sorry, I am not
Thanks for the review,
Set KBUILD_MODPOST_FAIL_ON_WARNINGS to a non-empty value to make the
kbuild fail when modpost generates any warnings. This will avoid
misses such as [1] where the SOF CI did not catch a missing module
license.
This was initially contributed in 2016 [2], rebase/clean-ups a
KERNEL BUILD + files below
scripts/ (unless mai...)
Removing parentheses and adding dash separators makes this go away.
Signed-off-by: Pierre-Louis Bossart
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d0862b19ce5..45934
: Filipe Brandenburger
Cc: Greg Thelen
Cc: Michael Davidson
Cc: Eugene Surovegin
Cc: Stephen Rothwell
Co-developed-by: Pierre-Louis Bossart
Signed-off-by: Pierre-Louis Bossart
---
Documentation/kbuild/kbuild.rst | 5 +
scripts/Makefile.modpost| 5 -
scripts/mod/modpost.c
On 9/17/20 8:50 PM, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 4cbffc461ec91287c4cb1d0e27b01b988d0b8fba
commit: 285880a23d105e5d34b311b0c44061dffb07e405 ASoC: SOF: Make creation of
machine device from SOF core optional
d
According to usage (bitfields.h) of REG_FIELDS,
Modify is:
reg &= ~REG_FIELD_C;
reg |= FIELD_PREP(REG_FIELD_C, c);
if this is indeed the case, all the code in cadence_master.c is also
broken, e.g:
dpn_config = cdns_readl(cdns, dpn_config_off);
dpn_config |= FIELD_PR
On 9/16/20 9:29 AM, Vinod Koul wrote:
On 16-09-20, 08:18, Pierre-Louis Bossart wrote:
According to usage (bitfields.h) of REG_FIELDS,
Modify is:
reg &= ~REG_FIELD_C;
reg |= FIELD_PREP(REG_FIELD_C, c);
if this is indeed the case, all the code in cadence_master.c is also br
On 9/16/20 7:35 AM, Vinod Koul wrote:
On 14-09-20, 09:44, Pierre-Louis Bossart wrote:
For LSB bits, I dont think this is an issue. I expect it to work, for example:
#define CONTROL_LSB_MASK GENMASK(2, 0)
foo |= u32_encode_bits(control, CONTROL_LSB_MASK);
would mask the control
For LSB bits, I dont think this is an issue. I expect it to work, for example:
#define CONTROL_LSB_MASK GENMASK(2, 0)
foo |= u32_encode_bits(control, CONTROL_LSB_MASK);
would mask the control value and program that in specific bitfeild.
But for MSB bits, I am not sure above will w
Hi Vinod,
+ * 25 0 (Reserved)
+ * 24:22 Function Number [2:0]
+ * 21 Entity[6]
+ * 20:19 Control Selector[5:4]
+ * 18 0 (Reserved)
+ * 17:15 Control Number[5:3]
+ * 14 Next
+ * 13
May be we could make the enumerated devices discovery bit more verbose!
Maybe adding a device number sysfs entry would help, e.g. reporting
NotAttched or a value in [0,11] would tell you if the device is actually
present.
Agreed, I cooked this patch to report verbose device status, let me k
-Louis Bossart
On 9/9/20 8:15 AM, YueHaibing wrote:
If CONFIG_PM is not set, build warns:
drivers/soundwire/intel.c:488:12: warning: 'intel_link_power_down' defined but
not used [-Wunused-function]
Move this to #ifdef block.
Yes, thanks for the report, it's a valid issue, but maybe the fix is to
add __
On 9/9/20 10:54 AM, Srinivas Kandagatla wrote:
On 09/09/2020 15:39, Pierre-Louis Bossart wrote:
Currently slave devices are only added either from device tree or acpi
entries. However lets say, there is wrong or no entry of a slave
device
in DT that is enumerated, then there is no way
On 9/9/20 3:27 AM, Srinivas Kandagatla wrote:
Currently slave devices are only added either from device tree or acpi
entries. However lets say, there is wrong or no entry of a slave device
in DT that is enumerated, then there is no way for user to know all
the enumerated devices on the bus.
Currently slave devices are only added either from device tree or acpi
entries. However lets say, there is wrong or no entry of a slave device
in DT that is enumerated, then there is no way for user to know all
the enumerated devices on the bus.
Sorry Srinivas, I don't understand your point.
Sorry, I couldn't resist adding three more comments to improve further:
-static int skylake_nau8825_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params)
+static int skylake_nau8825_trigger(struct snd_pcm_substream *substream, int
cmd)
{
struct snd_s
On 9/5/20 12:39 PM, Jonathan Marek wrote:
The driver may be used without slimbus, so don't depend on slimbus.
Signed-off-by: Jonathan Marek
---
drivers/soundwire/Kconfig | 2 +-
drivers/soundwire/qcom.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/soun
I don't have this patch and since I seem to get copied on quite a lot of
soundwire only serieses I just delete them unread mostly.
We now try to use the ASoC/SoundWire prefix for cover letters to highlight
that a patchset changes things across two trees, does this help or do we
need a diffe
Thanks for the review Vinod,
This is good, thanks for adding it in changelog. Can you also add this
description to Documentation (that can come as an individual patch),
ok
+/*
+ * v1.2 device - SDCA address mapping
+ *
+ * Spec definition
+ * BitsContents
+ * 31
On 9/8/20 12:42 PM, Radosław Biernacki wrote:
Sorry for missing the response for so long.
Somehow lost this thread in my mailbox.
That happens to all of us!
śr., 6 maj 2020 o 00:04 Pierre-Louis Bossart
napisał(a):
This single fix address two issues on machines with nau88125:
1) Audio
On 9/8/20 9:33 AM, Mark Brown wrote:
On Tue, Sep 08, 2020 at 02:28:48PM +0200, Jaroslav Kysela wrote:
Dne 08. 09. 20 v 14:11 Mark Brown napsal(a):
I don't have this patch and since I seem to get copied on quite a lot of
soundwire only serieses I just delete them unread mostly.
We now try
@@ -764,8 +786,11 @@ static int qcom_swrm_probe(struct platform_device *pdev)
if (!ctrl->regmap)
return -EINVAL;
} else {
- /* Only WCD based SoundWire controller is supported */
- return -ENOTSUPP;
+ ct
s.
Alternatively we can also split this in two, with ASoC-only and
SoundWire-only patches in separate series if it's easier for
maintainers. We would lose the rationale for the changes but that's not
essential.
Pierre-Louis Bossart (7):
ASoC: soc-dai: clarify return value for ge
ng
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Acked-by: Bard Liao
Signed-off-by: Pierre-Louis Bossart
---
drivers/base/regmap/Kconfig | 6 +-
drivers/base/regmap/Makefile | 1 +
drivers/base/regmap/regmap-sdw-mbq.c | 101 +++
include/linux/reg
Explicitly add header files used by regmap SoundWire support.
Suggested-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Signed-off-by: Pierre-Louis Bossart
---
drivers/base/regmap/regmap-sdw.c | 2 ++
1 file changed, 2
most often used parameter values are placed in the lower 16 bits
of the address. This helps to keep the paging registers constant while
updating Controls for a specific Device/Function.
Reviewed-by: Rander Wang
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Acked-by: Bard Liao
Signe
On 9/1/20 6:13 AM, Vinod Koul wrote:
mod_devicetable.h does not seem to be required for this file, so
remove it.
Signed-off-by: Vinod Koul
Reviewed-by: Pierre-Louis Bossart
---
changes in v2:
- fix typo in patch subject
drivers/base/regmap/regmap-sdw.c | 1 -
1 file changed, 1
On 9/1/20 6:07 AM, Vinod Koul wrote:
On 31-08-20, 10:15, Pierre-Louis Bossart wrote:
Detect cases where the clock is assumed to be stopped but the IP is
not in the relevant state, and add a dynamic debug trace.
you meant a debug print..and it looks like error print below (also in title
kfree(bus->defer_msg.msg->buf);
+ kfree(bus->defer_msg.msg);
+ }
I'd prefer a conditional check for each, but sdw_ml_sync_bank_switch()
has this same pattern, so it looks like the lifetime of these two
match.
Reviewed-by: Nick Desaulniers
Also looks good to me.
Reviewed-by: Pierre-Louis Bossart
Detect cases where the clock is assumed to be stopped but the IP is
not in the relevant state, and add a dynamic debug trace.
you meant a debug print..and it looks like error print below (also in title).
I don't understand the comment. Is the 'trace' confusing and are you asking
to e.g. cha
for better
understanding.
Changes in v2:
- Split patches into sdw and asoc patches. Please note that "soundwire:
fix port_ready[] dynamic allocation in mipi_disco" and "ASoC: codecs:
fix port_ready[] dynamic allocation in ASoC codecs" should be merged
at the same
typo in commit message?
On 8/29/20 5:39 AM, Vinod Koul wrote:
mod_devicetable.h does not seem to be required for this file, so
remove it.
Signed-off-by: Vinod Koul
---
drivers/base/regmap/regmap-sdw.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/base/regmap/regmap-sdw.c b/driv
+config SND_SOC_SC7180
+ tristate "SoC Machine driver for SC7180 boards"
+ depends on SND_SOC_QCOM
this depends is probably not necessary, the code is already in an if case.
+ select SND_SOC_QCOM_COMMON
+ select SND_SOC_LPASS_SC7180
+ select SND_SOC_MAX98357A
+
Detect cases where the clock is assumed to be stopped but the IP is
not in the relevant state, and add a dynamic debug trace.
you meant a debug print..and it looks like error print below (also in title).
I don't understand the comment. Is the 'trace' confusing and are you asking
to e.g. cha
+#include
Curious why do you need this header?
I'll return the question back to you, since you added this header for
regmap-sdw.c:
7c22ce6e21840 (Vinod Koul 2018-01-08 15:50:59 +0530 6) #include
Looks like it should be removed :)
I could compile it without any issues on few
Is this timeout for suspend or resume? Somehow I was under the
assumption that it is former? Or is the result seen on resume?
Rereading the race describe above in steps, I think this should be
handled in step c above. Btw is that suspend or runtime suspend which
causes this? Former would be
On 8/28/20 2:45 AM, Vinod Koul wrote:
On 28-08-20, 01:47, Liao, Bard wrote:
snd_pcm_substream *substream,
goto err;
}
- ret = sdw_prepare_stream(dma->stream);
+ /*
+* All cpu dais belong to a stream. To ensure sdw_prepare_stream
+*
If you want to change this you'd need to change it over the whole
subsystem (if not other subsystems), including the places where the
value is used.
ok, I'll drop this patch for now, keep -ENOTSUPP and deal with this
later. The only thing I really care about for now is SoundWire MBQ
suppor
check for devm_regmap_init_sdw()
ASoC: rt711: Fix return check for devm_regmap_init_sdw()
ASoC: rt715: Fix return check for devm_regmap_init_sdw()
ASoC: rt700: Fix return check for devm_regmap_init_sdw()
Thanks for the fix.
Reviewed-by: Pierre-Louis Bossart
+#include
+#include
+#include
Curious why do you need this header?
I'll return the question back to you, since you added this header for
regmap-sdw.c:
7c22ce6e21840 (Vinod Koul 2018-01-08 15:50:59 +0530 6)
#include
so I assumed it was needed here as well.
+MODULE_DESC
+/* v1.2 device - SDCA address mapping */
Can you please add description of bits used by each field here,
something like we have done for DevId
were you referring to something like this?
* Spec definition
* Register Bit Contents
* DevId_0 [7:4] 47:44 sdw_versio
On 8/26/20 7:28 AM, Vinod Koul wrote:
devm_regmap_init_sdw() returns a valid pointer on success or ERR_PTR on
failure which should be checked with IS_ERR. Also use PTR_ERR for
returning error codes.
Do you mind changing these two additional codecs that were missed in
this series? Thanks!
checkpatch is broken.
Heh, I'm not objecting it :)
OTOH, it's also true that ENOTSUPP is no good error code if returned
to user-space. Unfortunately many codes (including what I wrote) use
this code mistakenly, and they can't be changed any longer...
It's also used internally in vari
One possible objection is that this code could have been handled with
regmap-sdw.c. However this is a new spec addition not handled by every
SoundWire 1.1 and non-SDCA device, so there's no reason to load code
that will never be used.
Also in practice it's extremely unlikely that CONFIG_REG
On 8/26/20 4:48 AM, Vinod Koul wrote:
On 18-08-20, 10:41, Bard Liao wrote:
From: Pierre-Louis Bossart
Detect cases where the clock is assumed to be stopped but the IP is
not in the relevant state, and add a dynamic debug trace.
you meant a debug print..and it looks like error print below
+ * @hw_sync_min_links: Number of links used by a stream above which
+ * hardware-based synchronization is required. This value is only
+ * meaningful if multi_link is set. If set to 1, hardware-based
+ * synchronization will be used even if a stream only uses a single
+ * SoundWire segment.
- ret = sdw_prepare_stream(dma->stream);
+ /*
+* All cpu dais belong to a stream. To ensure sdw_prepare_stream
+* is called once per stream, we should call it only when
+* dai = first_cpu_dai.
+*/
+ if (first_cpu_dai == dai)
+ ret
-ENOTSUPP is not a valid error code, use recommended value instead.
What makes you say this - it's what regmap uses internally for
unsupported operations?
This was flagged by scripts/checkpatch.pl (must be a new addition).
# ENOTSUPP is not a standard error code and should be avoided in ne
ng
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Signed-off-by: Pierre-Louis Bossart
---
drivers/base/regmap/Kconfig | 6 +-
drivers/base/regmap/Makefile | 1 +
drivers/base/regmap/regmap-sdw-mbq.c | 102 +++
include/linux/regmap.h
ing is required, but
the most often used parameter values are placed in the lower 16 bits
of the address. This helps to keep the paging registers constant while
updating Controls for a specific Device/Function.
Reviewed-by: Rander Wang
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
-ENOTSUPP is not a valid error code, use recommended value instead.
Reviewed-by: Rander Wang
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Signed-off-by: Pierre-Louis Bossart
---
drivers/base/regmap/regmap-sdw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Explicitly add header files used by regmap SoundWire support.
Suggested-by: Guennadi Liakhovetski
Reviewed-by: Rander Wang
Reviewed-by: Guennadi Liakhovetski
Reviewed-by: Kai Vehmanen
Signed-off-by: Pierre-Louis Bossart
---
drivers/base/regmap/regmap-sdw.c | 2 ++
1 file changed, 2
application is going to be for volume/gain
controls.
The 3rd patch was initially suggested for inclusion in the SoundWire
tree, and was modified to add more background information in the
commit message as requested by Vinod Koul.
Pierre-Louis Bossart (4):
regmap: sdw: move to -EOPNOTSUPP
regmap: sdw
When CONFIG_PM_SLEEP is not defined, GCC throws compilation warnings:
drivers/soundwire/intel.c:1816:12: warning: ‘intel_resume’ defined but
not used [-Wunused-function]
1816 | static int intel_resume(struct device *dev)
|^~~~
drivers/soundwire/intel.c:1697:12: w
On 8/21/20 9:48 AM, Mark Brown wrote:
On Fri, Aug 21, 2020 at 09:25:53AM -0500, Pierre-Louis Bossart wrote:
On 8/21/20 6:01 AM, Mark Brown wrote:
A patch which was not sent as part of the same series and where no
dependency was mentioned :(
yes, sorry about that, i just noticed the two
cancel_work_sync() will either
a) wait until the current work completes, or
b) prevent a new one from starting.
there's no way to really 'abort' a workqueue, 'cancel' means either complete
or don't start.
Quite right, as that is how everyone deals with it. Stop the irq from
firing first and
On 8/21/20 6:01 AM, Mark Brown wrote:
On Thu, Aug 20, 2020 at 07:01:15PM -0500, Pierre-Louis Bossart wrote:
There is a companion patch 1eb629363aa35 ("ASoC: SOF: Intel: hda: import
SOUNDWIRE_INIT namespace") that does the import, not sure what causes the
warning?
A patch whi
On 8/20/20 6:39 PM, Stephen Rothwell wrote:
Hi all,
After merging the sound-asoc-fixes tree, today's linux-next build
(x86_64 allmodconfig) produced these warnings:
WARNING: modpost: module snd-sof-intel-hda-common uses symbol
sdw_intel_acpi_scan from namespace SOUNDWIRE_INTEL_INIT, but doe
On 8/19/20 4:06 AM, Vinod Koul wrote:
On 18-08-20, 06:23, Bard Liao wrote:
From: Pierre-Louis Bossart
In system suspend stress cases, the SOF CI reports timeouts. The root
cause is that an alert is generated while the system suspends. The
interrupt handling generates transactions on the
In addition, there's a WIP change to regmap to add support for SoundWire
1.2 MBQ-based register access, but this only affects regmap and ASoC
trees, all handled by Mark.
I have to take this comment back, the regmap change will depend on the
MBQ macro that should go in the SoundWire tree.
On 8/18/20 1:36 AM, Vinod Koul wrote:
On 18-08-20, 01:47, Bard Liao wrote:
From: Pierre-Louis Bossart
The existing code allocates memory for the total number of ports.
This only works if the ports are contiguous, but will break if e.g. a
Devices uses port0, 1, and 14. The port_ready
I had applied except 3 & 9 (few skipped in middle due to conflict while
applying), BUT I get a build failure on patch 2 onwards :(
drivers/soundwire/intel_init.c: In function ‘sdw_intel_cleanup’:
drivers/soundwire/intel_init.c:72:4: error: implicit declaration of
function ‘pm_runtime_disable
The upcoming SDCA (SoundWire Device Class Audio) specification defines
a hiearchical encoding to interface with Class-defined capabilities,
typo hiearchical
ok
based on which audio function, entity, control and channel being used.
Can you please elaborate on what do these terms refer to
On 8/17/20 7:08 AM, Vinod Koul wrote:
On 22-07-20, 04:37, Bard Liao wrote:
This series adds power management support for Intel soundwire links.
I had applied except 3 & 9 (few skipped in middle due to conflict while
applying), BUT I get a build failure on patch 2 onwards :(
drivers/soundwi
+ } else if (clock_stop_quirks & SDW_INTEL_CLK_STOP_BUS_RESET) {
+ ret = sdw_cdns_clock_stop(cdns, true);
+ if (ret < 0) {
+ dev_err(dev, "cannot enable clock stop on suspend\n");
+ return ret;
+ }
+
+
dsp")
Signed-off-by: Dinghao Liu
Acked-by: Pierre-Louis Bossart
Thanks for spotting this!
---
Changelog:
v2: - Add a new label 'out_power_up' to unify code style.
---
sound/soc/intel/atom/sst-mfld-platform-pcm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
di
On 8/13/20 3:45 AM, Takashi Iwai wrote:
On Thu, 13 Aug 2020 10:36:57 +0200,
Yu-Hsuan Hsu wrote:
Lu, Brent 於 2020年8月13日 週四 下午3:55寫道:
CRAS calls snd_pcm_hw_params_set_buffer_size_max() to use as large
buffer as possible. So the period size is an arbitrary number in
different platforms. At
On 8/12/20 11:08 AM, Lu, Brent wrote:
I also wonder what's really missing, too :)
BTW, I took a look back at the thread, and CRAS seems using a very
large buffer, namely:
[ 52.434791] sound pcmC1D0p: PERIOD_SIZE [240:240]
[ 52.434802] sound pcmC1D0p: BUFFER_SIZE [204480:204480]
yes
On 8/12/20 9:55 AM, Takashi Iwai wrote:
On Wed, 12 Aug 2020 16:46:40 +0200,
Pierre-Louis Bossart wrote:
After doing some experiments, I think I can identify the problem more precisely.
1. aplay can not reproduce this issue because it writes samples
immediately when there are some space in
After doing some experiments, I think I can identify the problem more precisely.
1. aplay can not reproduce this issue because it writes samples
immediately when there are some space in the buffer. However, you can
add --test-position to see how the delay grows with period size 256.
aplay -Dhw
... Why only 240? That's the next logical question.
If you have a clarification for it, it may be the rigid reason to
introduce such a hw constraint.
According to Brent, the DSP is using 240 period regardless the
hw_param. If the period size is 256, DSP will read 256 samples each
time but o
cppcheck warnings: (new ones prefixed by >>)
sound/soc/codecs/max98373-sdw.c:325:4: warning: Variable 'i' is reassigned a
value before the old one has been used. [redundantAssignment]
i = 0;
^
sound/soc/codecs/max98373-sdw.c:313:4: note: Variable 'i' is reassigned a
value b
201 - 300 of 1079 matches
Mail list logo