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

[alsa-devel] [PATCH] ASoC: dapm: Make sure we have a card when displaying component widgets
by Mark Brown 18 Mar '16

18 Mar '16

The dummy component is reused for all cards so we special case and don't bind it to any of them. This means that code like that displaying the component widgets that tries to look at the card will crash. In the future we will fix this by ensuring that the dummy component looks like other components but that is invasive and so not suitable for a fix. Instead add a special case check here. Reported-by: Harry Pan <harry.pan(a)intel.com> Suggested-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/soc-dapm.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 801ae1a81dfd..c4464858bf01 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -2188,6 +2188,13 @@ static ssize_t dapm_widget_show_component(struct snd_soc_component *cmpnt, int count = 0; char *state = "not set"; + /* card won't be set for the dummy component, as a spot fix + * we're checking for that case specifically here but in future + * we will ensure that the dummy component looks like others. + */ + if (!cmpnt->card) + return 0; + list_for_each_entry(w, &cmpnt->card->widgets, list) { if (w->dapm != dapm) continue; -- 2.7.0

1 0

Re: [alsa-devel] [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix off-by-one error in Broxton PLL IDs (rev3)
by Daniel Vetter 18 Mar '16

18 Mar '16

On Wed, Mar 16, 2016 at 02:37:24PM +0200, Tomi Sarvela wrote: > On Wednesday 16 March 2016 10:48:43 Imre Deak wrote: > > Tomi, noticed two things that maybe infrastructure related, see below: > > > > > Test drv_module_reload_basic: > > > skip -> PASS (bdw-nuci7) > > > Test gem_ringfill: > > > Subgroup basic-default-s3: > > > pass -> DMESG-WARN (skl-nuci5) > > > Test gem_storedw_loop: > > > Subgroup basic-bsd: > > > pass -> DMESG-WARN (skl-nuci5) > > > Subgroup basic-bsd1: > > > pass -> DMESG-WARN (skl-nuci5) > > > > Unrelated platform. All of the above are SND resume failures. Ville > > said he contacted Takashi about them. > > SND is recurring problem. I'd like to see drm-intel-nightly not breaking when > pulling sound updates. We need to escalate this again, snd team seriously sucks at quality control :( Adding Libin&Takashi. If this doesn't improve I need to throw sound trees out of -nightly for real. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

4 9

[alsa-devel] Bad rever-select of CONFIG_SND_HDA_I915
by Takashi Iwai 18 Mar '16

18 Mar '16

Hi, while build testing, I noticed the following warning: warning: (SND_SOC_INTEL_SKYLAKE) selects SND_HDA_I915 which has unmet direct dependencies (SOUND && !M68K && !UML && SND && DRM_I915 && SND_HDA_CORE) And it's indeed broken: you can't select CONFIG_SND_HDA_I915 from the driver side. This is the condition depending on DRM i915 driver. Fixing this doesn't look too trivial, though. Since SND_SOC_INTEL_SKYLAKE is the item to be selected, it can't have "depends on". So, the top-level configs that select SND_SOC_INTEL_SKYLAKE need to have "depends on DRM_I915" lines, or modify the driver to be built without i915 binding. Takashi

2 7

[alsa-devel] [PATCH] ASoC: rt5640: Correct the digital interface data select
by Sugar Zhang 18 Mar '16

18 Mar '16

this patch corrects the interface adc/dac control register definition according to datasheet. Signed-off-by: Sugar Zhang <sugar.zhang(a)rock-chips.com> --- sound/soc/codecs/rt5640.c | 2 +- sound/soc/codecs/rt5640.h | 36 ++++++++++++++++++------------------ 2 files changed, 19 insertions(+), 19 deletions(-) diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index 11d032c..48dbb2f 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -359,7 +359,7 @@ static const DECLARE_TLV_DB_RANGE(bst_tlv, /* Interface data select */ static const char * const rt5640_data_select[] = { - "Normal", "left copy to right", "right copy to left", "Swap"}; + "Normal", "Swap", "left copy to right", "right copy to left"}; static SOC_ENUM_SINGLE_DECL(rt5640_if1_dac_enum, RT5640_DIG_INF_DATA, RT5640_IF1_DAC_SEL_SFT, rt5640_data_select); diff --git a/sound/soc/codecs/rt5640.h b/sound/soc/codecs/rt5640.h index 83a7150..f84231e 100644 --- a/sound/soc/codecs/rt5640.h +++ b/sound/soc/codecs/rt5640.h @@ -442,39 +442,39 @@ #define RT5640_IF1_DAC_SEL_MASK (0x3 << 14) #define RT5640_IF1_DAC_SEL_SFT 14 #define RT5640_IF1_DAC_SEL_NOR (0x0 << 14) -#define RT5640_IF1_DAC_SEL_L2R (0x1 << 14) -#define RT5640_IF1_DAC_SEL_R2L (0x2 << 14) -#define RT5640_IF1_DAC_SEL_SWAP (0x3 << 14) +#define RT5640_IF1_DAC_SEL_SWAP (0x1 << 14) +#define RT5640_IF1_DAC_SEL_L2R (0x2 << 14) +#define RT5640_IF1_DAC_SEL_R2L (0x3 << 14) #define RT5640_IF1_ADC_SEL_MASK (0x3 << 12) #define RT5640_IF1_ADC_SEL_SFT 12 #define RT5640_IF1_ADC_SEL_NOR (0x0 << 12) -#define RT5640_IF1_ADC_SEL_L2R (0x1 << 12) -#define RT5640_IF1_ADC_SEL_R2L (0x2 << 12) -#define RT5640_IF1_ADC_SEL_SWAP (0x3 << 12) +#define RT5640_IF1_ADC_SEL_SWAP (0x1 << 12) +#define RT5640_IF1_ADC_SEL_L2R (0x2 << 12) +#define RT5640_IF1_ADC_SEL_R2L (0x3 << 12) #define RT5640_IF2_DAC_SEL_MASK (0x3 << 10) #define RT5640_IF2_DAC_SEL_SFT 10 #define RT5640_IF2_DAC_SEL_NOR (0x0 << 10) -#define RT5640_IF2_DAC_SEL_L2R (0x1 << 10) -#define RT5640_IF2_DAC_SEL_R2L (0x2 << 10) -#define RT5640_IF2_DAC_SEL_SWAP (0x3 << 10) +#define RT5640_IF2_DAC_SEL_SWAP (0x1 << 10) +#define RT5640_IF2_DAC_SEL_L2R (0x2 << 10) +#define RT5640_IF2_DAC_SEL_R2L (0x3 << 10) #define RT5640_IF2_ADC_SEL_MASK (0x3 << 8) #define RT5640_IF2_ADC_SEL_SFT 8 #define RT5640_IF2_ADC_SEL_NOR (0x0 << 8) -#define RT5640_IF2_ADC_SEL_L2R (0x1 << 8) -#define RT5640_IF2_ADC_SEL_R2L (0x2 << 8) -#define RT5640_IF2_ADC_SEL_SWAP (0x3 << 8) +#define RT5640_IF2_ADC_SEL_SWAP (0x1 << 8) +#define RT5640_IF2_ADC_SEL_L2R (0x2 << 8) +#define RT5640_IF2_ADC_SEL_R2L (0x3 << 8) #define RT5640_IF3_DAC_SEL_MASK (0x3 << 6) #define RT5640_IF3_DAC_SEL_SFT 6 #define RT5640_IF3_DAC_SEL_NOR (0x0 << 6) -#define RT5640_IF3_DAC_SEL_L2R (0x1 << 6) -#define RT5640_IF3_DAC_SEL_R2L (0x2 << 6) -#define RT5640_IF3_DAC_SEL_SWAP (0x3 << 6) +#define RT5640_IF3_DAC_SEL_SWAP (0x1 << 6) +#define RT5640_IF3_DAC_SEL_L2R (0x2 << 6) +#define RT5640_IF3_DAC_SEL_R2L (0x3 << 6) #define RT5640_IF3_ADC_SEL_MASK (0x3 << 4) #define RT5640_IF3_ADC_SEL_SFT 4 #define RT5640_IF3_ADC_SEL_NOR (0x0 << 4) -#define RT5640_IF3_ADC_SEL_L2R (0x1 << 4) -#define RT5640_IF3_ADC_SEL_R2L (0x2 << 4) -#define RT5640_IF3_ADC_SEL_SWAP (0x3 << 4) +#define RT5640_IF3_ADC_SEL_SWAP (0x1 << 4) +#define RT5640_IF3_ADC_SEL_L2R (0x2 << 4) +#define RT5640_IF3_ADC_SEL_R2L (0x3 << 4) /* REC Left Mixer Control 1 (0x3b) */ #define RT5640_G_HP_L_RM_L_MASK (0x7 << 13) -- 1.9.1

2 1

[alsa-devel] [PATCH] ASoC: dapm: Do not traverse widget hooks to snd-soc-dummy
by Harry Pan 18 Mar '16

18 Mar '16

All components are initially given an empty card when registering platform, and since the commit 6e78108bda78 ("ASoC: core: Don't probe the component which is dummy")', snd-soc-dummy will not be probed so that it remains an empty card assigned. This patch ignores to iterate widget hooks to the 'snd-soc-dummy' component, else it will trigger memory fault because of invalid dereference address of card->widgets. Test by grep -rsI "hello" /sys/devices/platform/skl_nau88l25_ssm4567_i2s/ Conflicts: sound/soc/soc-dapm.c Signed-off-by: Harry Pan <harry.pan(a)intel.com> --- sound/soc/soc-dapm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 581175a..0bc15c9 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -2188,6 +2188,9 @@ static ssize_t dapm_widget_show_component(struct snd_soc_component *cmpnt, int count = 0; char *state = "not set"; + if (!strcmp(cmpnt->name, "snd-soc-dummy")) + return 0; + list_for_each_entry(w, &cmpnt->card->widgets, list) { if (w->dapm != dapm) continue; -- 2.1.2

5 7

Re: [alsa-devel] [pulseaudio-discuss] ASoC and pulseaudio
by Liam Girdwood 17 Mar '16

17 Mar '16

+ alsa, Takashi and Mark since it's a naming convention being discussed as part of this work. On Mon, 2016-03-14 at 08:17 +0000, Lu, Han wrote: > Hi, > > > -----Original Message----- > > From: pulseaudio-discuss [mailto:pulseaudio-discuss- > > bounces(a)lists.freedesktop.org] On Behalf Of Liam Girdwood > > Sent: Tuesday, February 23, 2016 7:13 PM > > To: General PulseAudio Discussion <pulseaudio- > > discuss(a)lists.freedesktop.org> > > Cc: Linux Upstreaming Team <linux(a)endlessm.com>; han.lu > > <han.lu(a)linux.intel.com> > > Subject: Re: [pulseaudio-discuss] ASoC and pulseaudio > > > > On Sat, 2016-02-20 at 12:22 -0600, Pierre-Louis Bossart wrote: > > > r > > > On 02/17/2016 09:27 AM, Carlo Caione wrote: > > > > Hi, > > > > In our daily work we are seeing more and more laptops coming in with > > > > SoC audio (ASoC). In the most recent case, we are working with a new > > > > consumer laptop based on Intel Cherry Trail. As you probably know to > > > > have audio working on these laptops / codecs a fairly lengthy hw > > > > specific mixer configuration is needed. > > > > The problem we are facing is how to ship a single PA / ALSA package > > > > containing a working configuration for several of those laptops and > > > > we were wondering what is the most correct / upstream-friendly way > > > > to do that. > > > > > > > > I'm already excluding here some trivial workarounds like: shipping a > > > > different PA package for each hw or using an hw-tailored script to > > > > load the correct ALSA configuration. > > > > > > > > The first solution we came up with is just to write a profile-set > > > > configuration file loaded by udev for each cards / laptop with the > > > > correct mixer configuration already embedded in the path > > > > configuration files. This looks a bit like an overkill when you have > > > > to change tens of controls most of which just one time (once you > > > > have setup the codec selecting the main path is usually just matter > > > > of changing a few controls to change the output / input path). > > > > > > > > Another possibility is to use UCM and let PA create automatically > > > > from that profile and path configuration files. This looks promising > > > > but we were a bit worried about the UCM support in PA and how > > > > stable/adopted is UCM itself. > > > > Fwiw, I've not had any problems using PA and UCM together on my BDW + > > RT286 based development platforms. The problem we have atm is matching > > and quirks as Pierre describes. > > > > > > > > > > So, what is the suggested way to accomplish this and in general how > > > > PA is trying to address this problem? I expect in the future to see > > > > many more ASoC coming into the laptops world, how will the community > > > > make it so that you install a distro and then sound "just works"? > > > > > > Not an easy problem. I generated a set of UCM files for baytrail-based > > platforms and I was planning on doing the same for CHT now that there are a > > set of commercially available devices. > > > There are however a set of limitations that are known already, e.g. > > > the UCM file matches the machine driver name, so if there are any quirks > > inside the driver we'd need to add a DMI-based info to the card name and > > also build UCM files based on an include mechanism, otherwise it's going to > > be copy/paste hell Adding Liam to make sure he sees this thread. > > > > > > > Fwiw, we have been looking at providing some fixes for naming and quirks. > > We should probably schedule the work now. > > > > For naming we have the problem of duplication in the driver name e.g. > > > > cat /proc/asound/cards > > 0 [bytrt5640 ]: byt-rt5640 - byt-rt5640 > > byt-rt5640 > > > > The driver name actually has three strings iirc and we could differentiate here > > (by adding DMI name, plus any others?? ) to help UCM and PA deal with any > > quirks. > > > > UCM also does not currently support #include. The intention is to provide a > > method to define mixer settings on a codec per codec basis and the these > > could be #included into a machine UCM file. The machine UCM file would > > also define settings for any quirks and would #include any codec UCM files > > that were needed. PA would load the machine UCM file (based on > > improvements to the driver naming above) intead of the generic UCM file > > that is loaded atm. > > > > Liam > > > > We can fix this from driver level and user space level: > (1) to reporting more information from driver. > ALSA sound cards have 3 names. longname, shortname and drivername. e.g. > from soc-core.c :- > > snprintf(card->snd_card->shortname, sizeof(card->snd_card->shortname), > "%s", card->name); > snprintf(card->snd_card->longname, sizeof(card->snd_card->longname), > "%s", card->long_name ? card->long_name : card->name); > snprintf(card->snd_card->driver, sizeof(card->snd_card->driver), > "%s", card->driver_name ? card->driver_name : card->name); > > We can additionally set the long_name and driver_name in ASoC if they were not set. > > The naming scheme could be :- > > a) shortname is current machine driver name i.e. "byt-rt5640" > b) longname is DMI boardname + 1 i.e. "Minnowboard Max: byt-rt5640" > c) driver name is platform driver name i.e. "baytrail-pcm-audio" > > (2) to enable UCM to support "include" parsing, so each codec will have its own UCM file to define all the use cases for the codec only, and the codec UCM file can be included and the codec use cases can be referenced by different machine driver UCM files. > > I'll try to work out RFC patches to implement the features above. > > BR, > Han > > > > > > > > _______________________________________________ > > > pulseaudio-discuss mailing list > > > pulseaudio-discuss(a)lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > > > _______________________________________________ > > pulseaudio-discuss mailing list > > pulseaudio-discuss(a)lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss

6 20

[alsa-devel] [PATCH] ALSA: ctl: change return value in compatibility layer so that it's the same value in core implementation
by Takashi Sakamoto 17 Mar '16

17 Mar '16

In control compatibility layer, when no elements are found by ELEM_READ/ELEM_WRITE ioctl commands, ENXIO is returned. On the other hand, in core implementation, ENOENT is returned. This is not good for ALSA ctl applications. This commit changes the return value from the compatibility layer so that the same value is returned. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/core/control_compat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/core/control_compat.c b/sound/core/control_compat.c index 0608f21..1fa7076 100644 --- a/sound/core/control_compat.c +++ b/sound/core/control_compat.c @@ -196,7 +196,7 @@ static int get_ctl_type(struct snd_card *card, struct snd_ctl_elem_id *id, kctl = snd_ctl_find_id(card, id); if (! kctl) { up_read(&card->controls_rwsem); - return -ENXIO; + return -ENOENT; } info = kzalloc(sizeof(*info), GFP_KERNEL); if (info == NULL) { -- 2.7.0

2 1

[alsa-devel] adau1701: Different sample rates need different firmwares
by Pascal Huerst 17 Mar '16

17 Mar '16

Hey Lars, I'm having an issue with the adau1701 codec. There is this line which checks, if the mclk/lrclk ratio has changed and whether it is necessary to reset the codec and upload a new firmware. http://lxr.free-electrons.com/source/sound/soc/codecs/adau1701.c#L444 But if we change mclk in the machine driver (for example to playback 44.1), this ration might not change, but still we have to upload a new firmware, so shouldn't we probably be checking for sample rate changes instead: if (adau1701->current_rate != params_rate(params) { adau1701->current_rate = params_rate(params); ret = adau1701_reset(codec, clkdiv, params_rate(params)); if (ret < 0) return ret; } Or did I miss something? regards pascal

2 1

Re: [alsa-devel] different return value from some ioctl commands for x86 binary executed on x86_64
by Takashi Iwai 17 Mar '16

17 Mar '16

On Thu, 17 Mar 2016 04:52:52 +0100, Takashi Sakamoto wrote: > > Hi, > > When testing ioctl compatibility layer for ALSA ctl interface, I found > that error code of some ioctl commands are different depending on binary > architecture. > > The commands are SNDRV_CTL_IOCTL_ELEM_READ/SNDRV_CTL_IOCTL_ELEM_WRITE. > When passing data for non-existent element, ENOENT is returned by the > core implementation. On the other hand, ENXIO is returned by the > compatibility layer. > > This code is for reproduction of this bug. > > #include <stdio.h> > #include <stdlib.h> > #include <stdbool.h> > #include <sys/types.h> > #include <sys/stat.h> > #include <fcntl.h> > #include <sys/ioctl.h> > #include <errno.h> > #include <string.h> > > #include <sound/asound.h> > > static void check_elem_read(int fd) > { > struct snd_ctl_elem_value data = {0}; > if (ioctl(fd, SNDRV_CTL_IOCTL_ELEM_READ, &data) < 0) { > printf("ioctl(SNDRV_CTL_IOCTL_ELEM_READ): %s\n", > strerror(errno)); > } > } > > static void check_elem_write(int fd) > { > struct snd_ctl_elem_value data = {0}; > if (ioctl(fd, SNDRV_CTL_IOCTL_ELEM_WRITE, &data) < 0) { > printf("ioctl(SNDRV_CTL_IOCTL_ELEM_WRITE): %s\n", > strerror(errno)); > } > } > > int main(void) > { > int fd; > > fd = open("/dev/snd/controlC0", O_RDONLY); > if (fd < 0) { > printf("open(2): %s\n", strerror(errno)); > return EXIT_FAILURE; > } > > check_elem_read(fd); > check_elem_write(fd); > > return EXIT_SUCCESS; > } > > I tested on x86_64 machine with enough support for multi-arch. > > $ gcc -Wall -m64 -o ./test ./test.c ; ./test > ioctl(SNDRV_CTL_IOCTL_ELEM_READ): No such file or directory > ioctl(SNDRV_CTL_IOCTL_ELEM_WRITE): No such file or directory > > $ gcc -Wall -m32 -o ./test ./test.c ; ./test > ioctl(SNDRV_CTL_IOCTL_ELEM_READ): No such device or address > ioctl(SNDRV_CTL_IOCTL_ELEM_WRITE): No such device or address > > > This bug is due to return value of condition statement for > 'snd_ctl_find()'. I wrote a patch to fix it. > > > >From d7a8fd14a1bc100dbaf9bf28af47094d5ccb882b Mon Sep 17 00:00:00 2001 > From: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> > Date: Wed, 16 Mar 2016 13:40:31 +0900 > Subject: [PATCH] ALSA: ctl: change error code in compatibility layer so that > it's the same code as core implementation > > In control compatibility layer, when no elements are found by > ELEM_READ/ELEM_WRITE ioctl commands, ENXIO is returned. On the other > hand, in core implementation, ENOENT is returned. This is not good for > applications. > > This commit changes the return value from the compatibility layer so > that the same error code is returned. > > diff --git a/sound/core/control_compat.c b/sound/core/control_compat.c > index 0608f21..1fa7076 100644 > --- a/sound/core/control_compat.c > +++ b/sound/core/control_compat.c > @@ -196,7 +196,7 @@ static int get_ctl_type(struct snd_card *card, > struct snd_ctl_elem_id *id, > kctl = snd_ctl_find_id(card, id); > if (! kctl) { > up_read(&card->controls_rwsem); > - return -ENXIO; > + return -ENOENT; > } > info = kzalloc(sizeof(*info), GFP_KERNEL); > if (info == NULL) { > > Well, it's already in merge window for Linux 4.6. I don't mind to > postpone this patch to next developing cycle, while I also think it > better to fix the bug now. So I leave the decision to maintainers. Looks good to me, and trivial enough to be merged for 4.6. Please resubmit with a proper sign off. thanks, Takashi

2 1

[alsa-devel] [PATCH v7 0/6] Implement generic ASoC HDMI codec and use it in tda998x
by Jyri Sarha 17 Mar '16

17 Mar '16

Not much have changed since v6[1] patch series. I did everything addressed every comment, mostly by robots :), to previous series and there was one bug fixed in tda998x side. Unless there is any significant reaction to this series, I am going to put it to rest for a while now. I have other things to do. There is currently two other patch series[2][3] that depend on the first two (ALSA-) patches of this series. The third ("ASoC: hdmi-codec: Add audio abort() callback for video side to use") is currently not used and can be dropped if so decided. The rest depends on those the first two and adds hdmi-audio support for Beaglebone-black. Best regards, Jyri [1] "[PATCH v6 0/6] Implement generic ASoC HDMI codec and use it in tda998x" http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105524.html [2] "[PATCH v6 00/10] ASoC: Add mediatek HDMI codec support" by Philipp Zabel http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105509.html [3] "[RFC v2 0/6] sti: add audio interface to the hdmi driver" http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103374.ht… and "[PATCH v4 0/6] add IEC958 channel status control helpers" http://mailman.alsa-project.org/pipermail/alsa-devel/2016-March/105502.html by Arnaud Pouliquen Changes since v6 * "ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders" - Add "Acked-by: Arnaud Pouliquen <arnaud.pouliquen(a)st.com>" and "Tested-by: Philipp Zabel <p.zabel(a)pengutronix.de>", no other changes * "ALSA: pcm: add IEC958 channel status helper for hw_param" - Added kernel-doc for snd_pcm_create_iec958_consumer_hw_params() * "drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding" - Use PTR_ERR_OR_ZERO() in tda998x_audio_codec_init() - Fix possible uninitialized use of 'size' in tda998x_get_audio_ports() - Store audio configuration in tda998x_audio_hw_params() instead of tda998x_configure_audio(). Changes since v5 - Rebased on top of the latest drm-next branch - Allow 32 bit samplewidth in snd_pcm_create_iec958_consumer() and snd_pcm_create_iec958_consumer_hw_params() - Propose new simpler DT binding for tda998x audio - Squash tda998x audio DT binding together with hdmi-codec integration Changes since RFC v4, - Rebased on top of the latest drm-next branch - Split the hdmi-codec abort functionality into a separate patch for better visibility of what it is all about - This does not affect the tda998x patches as the abort functionality is not used - Drop S18_3* formats from I2S_FORMATS and add a comment about formats not supported by HDMI Changes since RFC v3, ASoC side: - Add "ALSA: pcm: add IEC958 channel status helper for hw_params" - Add "tda998x: Improve tda998x_configure_audio() audio related pdata" - use snd_pcm_create_iec958_consumer_hw_params() to construct the stream header - Remove set_clk() callback from hdmi-codec. It is not needed for now. - Refer to stream header in AIF as specified in HDMI standard - Set current_stream to NULL only after video side audio_shutdown() has been called. Avoid potential race if video side attempts to abort audio at the same time. - No need to have video side device pointer in the hdmi codec's pdata as it is found from dev->parent. - Fix hdmi-codec enum: DAI_ID_I2C > DAI_ID_I2S - Improve audio_startup API comment - Make improved checkpatch happy - BUG_ON > WARN_ON - put */ ending the block comment to a separate line DRM side: - Fix tda998x get_eld() locking - Change tda998x audio parameters in pdata to more generic, that can be readily used in tda998x_audio_config() - Rename and restructure audio port related private data members to be more descriptive - Require audio configuration trough ASoC hdmi-codec if HDMI audio is configured trough DT binding. DTS: - Increase McASP fifo usage form 1 to 32 Jyri Sarha (6): ALSA: pcm: add IEC958 channel status helper for hw_params ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders ASoC: hdmi-codec: Add audio abort() callback for video side to use drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding ARM: dts: am335x-boneblack: Add HDMI audio support .../devicetree/bindings/display/bridge/tda998x.txt | 18 + arch/arm/boot/dts/am335x-boneblack.dts | 71 +++- drivers/gpu/drm/i2c/Kconfig | 1 + drivers/gpu/drm/i2c/tda998x_drv.c | 276 ++++++++++++-- include/drm/i2c/tda998x.h | 24 +- include/dt-bindings/display/tda998x.h | 7 + include/sound/hdmi-codec.h | 104 ++++++ include/sound/pcm_iec958.h | 2 + sound/core/pcm_iec958.c | 65 +++- sound/soc/codecs/Kconfig | 6 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/hdmi-codec.c | 411 +++++++++++++++++++++ 12 files changed, 915 insertions(+), 72 deletions(-) create mode 100644 include/dt-bindings/display/tda998x.h create mode 100644 include/sound/hdmi-codec.h create mode 100644 sound/soc/codecs/hdmi-codec.c -- 1.9.1

2 7