August 2016 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ALSA: hda: add AMD Bonaire AZ PCI ID with proper driver caps
by Maruthi Srinivas Bayyavarapu 03 Aug '16

03 Aug '16

This commit fixes garbled audio on Bonaire HDMI Signed-off-by: Maruthi Bayyavarapu <maruthi.bayyavarapu(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> --- sound/pci/hda/hda_intel.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 6f8ea13..89dacf9 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2265,6 +2265,8 @@ static const struct pci_device_id azx_ids[] = { { PCI_DEVICE(0x1022, 0x780d), .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB }, /* ATI HDMI */ + { PCI_DEVICE(0x1002, 0x0002), + .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS }, { PCI_DEVICE(0x1002, 0x1308), .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS }, { PCI_DEVICE(0x1002, 0x157a), -- 1.9.1

2 1

[alsa-devel] [PATCH] sound: Fix empty menuconfig SND_ARM
by Eugeniu Rosca 03 Aug '16

03 Aug '16

commit 3c8f7710c1c4 ("ASoC: fix broken pxa SoC support") has removed the SND_ARM dependency from SND_PXA2XX_LIB and SND_PXA2XX_LIB_AC97, by moving these config entries outside of the "if SND_ARM ... endif" construct. However, by placing these 2 symbols right between the SND_ARM menuconfig definition and the first SND_ARM menu entry, the side effect is that the SND_ARM menu becomes empty and all the config entries caught between "if SND_ARM ... endif" no more belong to menuconfig SND_ARM, but to its parent (menuconfig SND). Fix this. Signed-off-by: Eugeniu Rosca <rosca.eugeniu(a)gmail.com> --- sound/arm/Kconfig | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/sound/arm/Kconfig b/sound/arm/Kconfig index e040621..65171f6 100644 --- a/sound/arm/Kconfig +++ b/sound/arm/Kconfig @@ -9,14 +9,6 @@ menuconfig SND_ARM Drivers that are implemented on ASoC can be found in "ALSA for SoC audio support" section. -config SND_PXA2XX_LIB - tristate - select SND_AC97_CODEC if SND_PXA2XX_LIB_AC97 - select SND_DMAENGINE_PCM - -config SND_PXA2XX_LIB_AC97 - bool - if SND_ARM config SND_ARMAACI @@ -42,3 +34,10 @@ config SND_PXA2XX_AC97 endif # SND_ARM +config SND_PXA2XX_LIB + tristate + select SND_AC97_CODEC if SND_PXA2XX_LIB_AC97 + select SND_DMAENGINE_PCM + +config SND_PXA2XX_LIB_AC97 + bool -- 2.9.2

3 5

[alsa-devel] [PATCH v2] ASoC: simple-card-utils: add missing MODULE_xxx()
by Kuninori Morimoto 03 Aug '16

03 Aug '16

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> simple-card-utils might be used as module, but MODULE_xxx() information was missed. This patch adds it. Otherwise, we will have below error, and can't use it. Specil thanks to Kevin. > insmod simple-card-utils.ko simple_card_utils: module license 'unspecified' taints kernel. Disabling lock debugging due to kernel taint simple_card_utils: Unknown symbol snd_soc_of_parse_daifmt (err 0) simple_card_utils: Unknown symbol snd_soc_of_parse_card_name (err 0) insmod: can't insert 'simple-card-utils.ko': \ unknown symbol in module, or unknown parameter Reported-by: Kevin Hilman <khilman(a)baylibre.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- v1 -> v2 - remove MODULE_ALIAS() sound/soc/generic/Makefile | 6 +++--- sound/soc/generic/simple-card-utils.c | 6 ++++++ 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/sound/soc/generic/Makefile b/sound/soc/generic/Makefile index 45602ca..2d53c8d 100644 --- a/sound/soc/generic/Makefile +++ b/sound/soc/generic/Makefile @@ -1,5 +1,5 @@ -obj-$(CONFIG_SND_SIMPLE_CARD_UTILS) := simple-card-utils.o - +snd-soc-simple-card-utils-objs := simple-card-utils.o snd-soc-simple-card-objs := simple-card.o -obj-$(CONFIG_SND_SIMPLE_CARD) += snd-soc-simple-card.o +obj-$(CONFIG_SND_SIMPLE_CARD_UTILS) += snd-soc-simple-card-utils.o +obj-$(CONFIG_SND_SIMPLE_CARD) += snd-soc-simple-card.o diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c index d89a9a1..9599de6 100644 --- a/sound/soc/generic/simple-card-utils.c +++ b/sound/soc/generic/simple-card-utils.c @@ -7,6 +7,7 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ +#include <linux/module.h> #include <linux/of.h> #include <sound/simple_card_utils.h> @@ -95,3 +96,8 @@ int asoc_simple_card_parse_card_name(struct snd_soc_card *card, return 0; } EXPORT_SYMBOL_GPL(asoc_simple_card_parse_card_name); + +/* Module information */ +MODULE_AUTHOR("Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>"); +MODULE_DESCRIPTION("ALSA SoC Simple Card Utils"); +MODULE_LICENSE("GPL v2"); -- 1.9.1

1 0

[alsa-devel] [PATCH 1/2] ASoC: cs42l73: Constify cs42l73_mclk_coeffs and cs42l73_mclkx_coeffs tables
by Axel Lin 02 Aug '16

02 Aug '16

Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/cs42l73.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/cs42l73.c b/sound/soc/codecs/cs42l73.c index 42a8fd4..8524e22 100644 --- a/sound/soc/codecs/cs42l73.c +++ b/sound/soc/codecs/cs42l73.c @@ -794,7 +794,7 @@ struct cs42l73_mclk_div { u8 mmcc; }; -static struct cs42l73_mclk_div cs42l73_mclk_coeffs[] = { +static const struct cs42l73_mclk_div cs42l73_mclk_coeffs[] = { /* MCLK, Sample Rate, xMMCC[5:0] */ {5644800, 11025, 0x30}, {5644800, 22050, 0x20}, @@ -844,7 +844,7 @@ struct cs42l73_mclkx_div { u8 mclkdiv; }; -static struct cs42l73_mclkx_div cs42l73_mclkx_coeffs[] = { +static const struct cs42l73_mclkx_div cs42l73_mclkx_coeffs[] = { {5644800, 1, 0}, /* 5644800 */ {6000000, 1, 0}, /* 6000000 */ {6144000, 1, 0}, /* 6144000 */ -- 2.7.4

3 3

[alsa-devel] Improving status timestamp accuracy
by Alan Young 02 Aug '16

02 Aug '16

I am looking at ways to get more accurate status timestamp information for various SoC drivers. The data that is obtained by snd_pcm_status(). One route would be to implement the more accurate timestamp mechanisms that currently are only available for HDA and Skylake (which I think is the SoC version of HDA). Looking at the code however, I think that may be unnecessary, at least for my purposes. It may not actually be practical in many cases. A call to snd_pcm_status() result in snd_pcm_update_hw_ptr0() being called. This gets the current output position (pos) via substream->ops->pointer(substream) and then makes all the other calculations based on the result. In theory, the result of substream->ops->pointer() could be sample accurate but in practice it is very unlikely to be better than period accurate. In fact, if I read it right, it will just about always be accurate to the point of the last period interrupt. Even when a DMA driver claims support of DMA_RESIDUE_GRANULARITY_BURST, it is often the case that the actual granularity is a period. The consequence of all that is that, for most drivers, the accuracy of a status report is period time. The result values, tstamp & audio_tstamp, are calculated using the current time and the pos estimate from above. snd_pcm_update_hw_ptr0() is also called when there is a DMA interrupt. At that time the calculate results will be accurate, or at worst consistently inaccurate (there could be a constant offset). It would be useful if a snd_pcm_status() call would simply return the results from the point of the last interrupt, and not try to estimate a current value based on the inaccurate substream->ops->pointer() result. It could either: (a) return the result from the time of the last interrupt, in which case tstamp would be in the past and driver_tstamp would be now; or (b) update audio_tstamp based on the elapsed time since it was recorded. (b) effectively abandons the idea that a current position report will be accurate outside of an interrupt callback but, even if it is, doing so is unlikely to result in any loss of accuracy in practice (assuming a drift of better than 40ppm and period time < 100ms). Any comments on either of these approaches? I guess (b) is more compatible with the current model. Alan.

6 24

[alsa-devel] [PATCH 1170/1285] Replace numeric parameter like 0444 with macro
by Baole Ni 02 Aug '16

02 Aug '16

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu <chuansheng.liu(a)intel.com> Signed-off-by: Baole Ni <baolex.ni(a)intel.com> --- sound/firewire/fireworks/fireworks.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/firewire/fireworks/fireworks.c b/sound/firewire/fireworks/fireworks.c index 71a0613..3390b4e 100644 --- a/sound/firewire/fireworks/fireworks.c +++ b/sound/firewire/fireworks/fireworks.c @@ -27,16 +27,16 @@ static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP; unsigned int snd_efw_resp_buf_size = 1024; bool snd_efw_resp_buf_debug = false; -module_param_array(index, int, NULL, 0444); +module_param_array(index, int, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(index, "card index"); -module_param_array(id, charp, NULL, 0444); +module_param_array(id, charp, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(id, "ID string"); -module_param_array(enable, bool, NULL, 0444); +module_param_array(enable, bool, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(enable, "enable Fireworks sound card"); -module_param_named(resp_buf_size, snd_efw_resp_buf_size, uint, 0444); +module_param_named(resp_buf_size, snd_efw_resp_buf_size, uint, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(resp_buf_size, "response buffer size (max 4096, default 1024)"); -module_param_named(resp_buf_debug, snd_efw_resp_buf_debug, bool, 0444); +module_param_named(resp_buf_debug, snd_efw_resp_buf_debug, bool, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(resp_buf_debug, "store all responses to buffer"); static DEFINE_MUTEX(devices_mutex); -- 2.9.2

2 1

[alsa-devel] [PATCH 1169/1285] Replace numeric parameter like 0444 with macro
by Baole Ni 02 Aug '16

02 Aug '16

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu <chuansheng.liu(a)intel.com> Signed-off-by: Baole Ni <baolex.ni(a)intel.com> --- sound/firewire/bebob/bebob.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/firewire/bebob/bebob.c b/sound/firewire/bebob/bebob.c index f7e2cbd..ec67fc6 100644 --- a/sound/firewire/bebob/bebob.c +++ b/sound/firewire/bebob/bebob.c @@ -22,11 +22,11 @@ static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP; -module_param_array(index, int, NULL, 0444); +module_param_array(index, int, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(index, "card index"); -module_param_array(id, charp, NULL, 0444); +module_param_array(id, charp, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(id, "ID string"); -module_param_array(enable, bool, NULL, 0444); +module_param_array(enable, bool, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(enable, "enable BeBoB sound card"); static DEFINE_MUTEX(devices_mutex); -- 2.9.2

2 1

[alsa-devel] [PATCH 1271/1285] Replace numeric parameter like 0444 with macro
by Baole Ni 02 Aug '16

02 Aug '16

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu <chuansheng.liu(a)intel.com> Signed-off-by: Baole Ni <baolex.ni(a)intel.com> --- sound/soc/omap/mcbsp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c index 4a16e77..3938336 100644 --- a/sound/soc/omap/mcbsp.c +++ b/sound/soc/omap/mcbsp.c @@ -857,7 +857,7 @@ unlock: return size; } -static DEVICE_ATTR(dma_op_mode, 0644, dma_op_mode_show, dma_op_mode_store); +static DEVICE_ATTR(dma_op_mode, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, dma_op_mode_show, dma_op_mode_store); static const struct attribute *additional_attrs[] = { &dev_attr_max_tx_thres.attr, @@ -926,7 +926,7 @@ out: return size; } -static DEVICE_ATTR(st_taps, 0644, st_taps_show, st_taps_store); +static DEVICE_ATTR(st_taps, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, st_taps_show, st_taps_store); static const struct attribute *sidetone_attrs[] = { &dev_attr_st_taps.attr, -- 2.9.2

2 1

[alsa-devel] [PATCH 1285/1285] Replace numeric parameter like 0444 with macro
by Baole Ni 02 Aug '16

02 Aug '16

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu <chuansheng.liu(a)intel.com> Signed-off-by: Baole Ni <baolex.ni(a)intel.com> --- sound/usb/usx2y/usbusx2yaudio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/usx2y/usbusx2yaudio.c b/sound/usb/usx2y/usbusx2yaudio.c index dd40ca9..a98ddcf 100644 --- a/sound/usb/usx2y/usbusx2yaudio.c +++ b/sound/usb/usx2y/usbusx2yaudio.c @@ -61,7 +61,7 @@ #ifdef USX2Y_NRPACKS_VARIABLE static int nrpacks = USX2Y_NRPACKS; /* number of packets per urb */ #define nr_of_packs() nrpacks - module_param(nrpacks, int, 0444); + module_param(nrpacks, int, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(nrpacks, "Number of packets per URB."); #else #define nr_of_packs() USX2Y_NRPACKS -- 2.9.2

1 0

[alsa-devel] [PATCH 1284/1285] Replace numeric parameter like 0444 with macro
by Baole Ni 02 Aug '16

02 Aug '16

I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng Liu <chuansheng.liu(a)intel.com> Signed-off-by: Baole Ni <baolex.ni(a)intel.com> --- sound/usb/usx2y/usbusx2y.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sound/usb/usx2y/usbusx2y.c b/sound/usb/usx2y/usbusx2y.c index 91e0e2a..86f0d0b 100644 --- a/sound/usb/usx2y/usbusx2y.c +++ b/sound/usb/usx2y/usbusx2y.c @@ -156,11 +156,11 @@ static int index[SNDRV_CARDS] = SNDRV_DEFAULT_IDX; /* Index 0-max */ static char* id[SNDRV_CARDS] = SNDRV_DEFAULT_STR; /* Id for this card */ static bool enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP; /* Enable this card */ -module_param_array(index, int, NULL, 0444); +module_param_array(index, int, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(index, "Index value for "NAME_ALLCAPS"."); -module_param_array(id, charp, NULL, 0444); +module_param_array(id, charp, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(id, "ID string for "NAME_ALLCAPS"."); -module_param_array(enable, bool, NULL, 0444); +module_param_array(enable, bool, NULL, S_IRUSR | S_IRGRP | S_IROTH); MODULE_PARM_DESC(enable, "Enable "NAME_ALLCAPS"."); -- 2.9.2

1 0