| Message ID | E1Yr1xy-0006l8-Ft@rmk-PC.arm.linux.org.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > Add a helper for the EDID like data structure, which is typically passed > from a HDMI adapter to its associated audio driver. This informs the > audio driver of the capabilities of the attached HDMI sink. As far as I can tell people are fairly happy with the implementation here and unless I'm missing something are definitely happy with the interface. If that's the case can we get this into -next? There's a lot of interest in HDMI right now (which is great) and this would be helpful for that, it seems like even if there are issues with the implementation it would be worth merging as is so we can start adding users and then do any improvements to the interface in parallel. From an interface point of view: Reviewed-by: Mark Brown <broonie@kernel.org>
On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > Add a helper for the EDID like data structure, which is typically passed > > from a HDMI adapter to its associated audio driver. This informs the > > audio driver of the capabilities of the attached HDMI sink. > > As far as I can tell people are fairly happy with the implementation > here and unless I'm missing something are definitely happy with the > interface. If that's the case can we get this into -next? There's a > lot of interest in HDMI right now (which is great) and this would be > helpful for that, it seems like even if there are issues with the > implementation it would be worth merging as is so we can start adding > users and then do any improvements to the interface in parallel. > > From an interface point of view: > > Reviewed-by: Mark Brown <broonie@kernel.org> I'd be more than happy if Takashi Iwai wants to take them - I'm not planning on the audio driver itself being merged just yet as we still need to properly hammer out the differences between the AHB audio (for iMX6) and I2S audio (for Rockchip) for this device. Alternatively, I could move these two patches to the beginning of my series, and merge that point into my for-next and/or publish it as a separate sub-branch... whatever people want, just let me know.
At Fri, 22 May 2015 14:15:35 +0100, Russell King - ARM Linux wrote: > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > Add a helper for the EDID like data structure, which is typically passed > > > from a HDMI adapter to its associated audio driver. This informs the > > > audio driver of the capabilities of the attached HDMI sink. > > > > As far as I can tell people are fairly happy with the implementation > > here and unless I'm missing something are definitely happy with the > > interface. If that's the case can we get this into -next? There's a > > lot of interest in HDMI right now (which is great) and this would be > > helpful for that, it seems like even if there are issues with the > > implementation it would be worth merging as is so we can start adding > > users and then do any improvements to the interface in parallel. > > > > From an interface point of view: > > > > Reviewed-by: Mark Brown <broonie@kernel.org> > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > planning on the audio driver itself being merged just yet as we still > need to properly hammer out the differences between the AHB audio (for > iMX6) and I2S audio (for Rockchip) for this device. Sorry, I've been on vacation in the last two weeks, so slowly digesting all backlogs now. > Alternatively, I could move these two patches to the beginning of my > series, and merge that point into my for-next and/or publish it as a > separate sub-branch... whatever people want, just let me know. I'm fine to take the sound part. It's only patches 10 and 11, right? Then I can provide a branch that can be merged for the rest drm stuff. thanks, Takashi
On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > At Fri, 22 May 2015 14:15:35 +0100, > Russell King - ARM Linux wrote: > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > Add a helper for the EDID like data structure, which is typically passed > > > > from a HDMI adapter to its associated audio driver. This informs the > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > As far as I can tell people are fairly happy with the implementation > > > here and unless I'm missing something are definitely happy with the > > > interface. If that's the case can we get this into -next? There's a > > > lot of interest in HDMI right now (which is great) and this would be > > > helpful for that, it seems like even if there are issues with the > > > implementation it would be worth merging as is so we can start adding > > > users and then do any improvements to the interface in parallel. > > > > > > From an interface point of view: > > > > > > Reviewed-by: Mark Brown <broonie@kernel.org> > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > planning on the audio driver itself being merged just yet as we still > > need to properly hammer out the differences between the AHB audio (for > > iMX6) and I2S audio (for Rockchip) for this device. > > Sorry, I've been on vacation in the last two weeks, so slowly > digesting all backlogs now. > > > Alternatively, I could move these two patches to the beginning of my > > series, and merge that point into my for-next and/or publish it as a > > separate sub-branch... whatever people want, just let me know. > > I'm fine to take the sound part. It's only patches 10 and 11, right? > Then I can provide a branch that can be merged for the rest drm > stuff. Yep, just patches 10 and 11. If possible, please base these patches on v4.1-rc1, thanks. Thanks.
At Fri, 22 May 2015 14:53:31 +0100, Russell King - ARM Linux wrote: > > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > > At Fri, 22 May 2015 14:15:35 +0100, > > Russell King - ARM Linux wrote: > > > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > > Add a helper for the EDID like data structure, which is typically passed > > > > > from a HDMI adapter to its associated audio driver. This informs the > > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > > > As far as I can tell people are fairly happy with the implementation > > > > here and unless I'm missing something are definitely happy with the > > > > interface. If that's the case can we get this into -next? There's a > > > > lot of interest in HDMI right now (which is great) and this would be > > > > helpful for that, it seems like even if there are issues with the > > > > implementation it would be worth merging as is so we can start adding > > > > users and then do any improvements to the interface in parallel. > > > > > > > > From an interface point of view: > > > > > > > > Reviewed-by: Mark Brown <broonie@kernel.org> > > > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > > planning on the audio driver itself being merged just yet as we still > > > need to properly hammer out the differences between the AHB audio (for > > > iMX6) and I2S audio (for Rockchip) for this device. > > > > Sorry, I've been on vacation in the last two weeks, so slowly > > digesting all backlogs now. > > > > > Alternatively, I could move these two patches to the beginning of my > > > series, and merge that point into my for-next and/or publish it as a > > > separate sub-branch... whatever people want, just let me know. > > > > I'm fine to take the sound part. It's only patches 10 and 11, right? > > Then I can provide a branch that can be merged for the rest drm > > stuff. > > Yep, just patches 10 and 11. If possible, please base these patches on > v4.1-rc1, thanks. I applied them on top of -rc4, I suppose it's OK? Now pushed as topic/hdmi branch of sound git tree. Let me know if anything else needed. thanks, Takashi
On Fri, May 22, 2015 at 03:54:56PM +0200, Takashi Iwai wrote: > At Fri, 22 May 2015 14:53:31 +0100, > Russell King - ARM Linux wrote: > > > > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > > > At Fri, 22 May 2015 14:15:35 +0100, > > > Russell King - ARM Linux wrote: > > > > > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > > > Add a helper for the EDID like data structure, which is typically passed > > > > > > from a HDMI adapter to its associated audio driver. This informs the > > > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > > > > > As far as I can tell people are fairly happy with the implementation > > > > > here and unless I'm missing something are definitely happy with the > > > > > interface. If that's the case can we get this into -next? There's a > > > > > lot of interest in HDMI right now (which is great) and this would be > > > > > helpful for that, it seems like even if there are issues with the > > > > > implementation it would be worth merging as is so we can start adding > > > > > users and then do any improvements to the interface in parallel. > > > > > > > > > > From an interface point of view: > > > > > > > > > > Reviewed-by: Mark Brown <broonie@kernel.org> > > > > > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > > > planning on the audio driver itself being merged just yet as we still > > > > need to properly hammer out the differences between the AHB audio (for > > > > iMX6) and I2S audio (for Rockchip) for this device. > > > > > > Sorry, I've been on vacation in the last two weeks, so slowly > > > digesting all backlogs now. > > > > > > > Alternatively, I could move these two patches to the beginning of my > > > > series, and merge that point into my for-next and/or publish it as a > > > > separate sub-branch... whatever people want, just let me know. > > > > > > I'm fine to take the sound part. It's only patches 10 and 11, right? > > > Then I can provide a branch that can be merged for the rest drm > > > stuff. > > > > Yep, just patches 10 and 11. If possible, please base these patches on > > v4.1-rc1, thanks. > > I applied them on top of -rc4, I suppose it's OK? It is, but what it means is that I'll keep my copy of the patches in my tree rather than pulling your tree. Having branches spread on different start points makes it difficult to generate a patch series from the git tree - which is something I continue to do for the SolidRun iMX6 platforms (publishing it as separate patches, tarball of those patches and a combined patch.) As I say, it doesn't matter that much, I can just keep my copies of the patches, and when this stuff gets rebased to 4.2-rc1, git rebase should eliminate them automatically.
At Fri, 22 May 2015 15:00:10 +0100, Russell King - ARM Linux wrote: > > On Fri, May 22, 2015 at 03:54:56PM +0200, Takashi Iwai wrote: > > At Fri, 22 May 2015 14:53:31 +0100, > > Russell King - ARM Linux wrote: > > > > > > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > > > > At Fri, 22 May 2015 14:15:35 +0100, > > > > Russell King - ARM Linux wrote: > > > > > > > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > > > > Add a helper for the EDID like data structure, which is typically passed > > > > > > > from a HDMI adapter to its associated audio driver. This informs the > > > > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > > > > > > > As far as I can tell people are fairly happy with the implementation > > > > > > here and unless I'm missing something are definitely happy with the > > > > > > interface. If that's the case can we get this into -next? There's a > > > > > > lot of interest in HDMI right now (which is great) and this would be > > > > > > helpful for that, it seems like even if there are issues with the > > > > > > implementation it would be worth merging as is so we can start adding > > > > > > users and then do any improvements to the interface in parallel. > > > > > > > > > > > > From an interface point of view: > > > > > > > > > > > > Reviewed-by: Mark Brown <broonie@kernel.org> > > > > > > > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > > > > planning on the audio driver itself being merged just yet as we still > > > > > need to properly hammer out the differences between the AHB audio (for > > > > > iMX6) and I2S audio (for Rockchip) for this device. > > > > > > > > Sorry, I've been on vacation in the last two weeks, so slowly > > > > digesting all backlogs now. > > > > > > > > > Alternatively, I could move these two patches to the beginning of my > > > > > series, and merge that point into my for-next and/or publish it as a > > > > > separate sub-branch... whatever people want, just let me know. > > > > > > > > I'm fine to take the sound part. It's only patches 10 and 11, right? > > > > Then I can provide a branch that can be merged for the rest drm > > > > stuff. > > > > > > Yep, just patches 10 and 11. If possible, please base these patches on > > > v4.1-rc1, thanks. > > > > I applied them on top of -rc4, I suppose it's OK? > > It is, but what it means is that I'll keep my copy of the patches in my > tree rather than pulling your tree. Having branches spread on different > start points makes it difficult to generate a patch series from the git > tree - which is something I continue to do for the SolidRun iMX6 platforms > (publishing it as separate patches, tarball of those patches and a combined > patch.) > > As I say, it doesn't matter that much, I can just keep my copies of the > patches, and when this stuff gets rebased to 4.2-rc1, git rebase should > eliminate them automatically. OK, if so, then I rebase on top of -rc1. The branch isn't merged yet, so no big problem. Takashi
At Fri, 22 May 2015 16:02:13 +0200, Takashi Iwai wrote: > > At Fri, 22 May 2015 15:00:10 +0100, > Russell King - ARM Linux wrote: > > > > On Fri, May 22, 2015 at 03:54:56PM +0200, Takashi Iwai wrote: > > > At Fri, 22 May 2015 14:53:31 +0100, > > > Russell King - ARM Linux wrote: > > > > > > > > On Fri, May 22, 2015 at 03:30:54PM +0200, Takashi Iwai wrote: > > > > > At Fri, 22 May 2015 14:15:35 +0100, > > > > > Russell King - ARM Linux wrote: > > > > > > > > > > > > On Fri, May 22, 2015 at 01:20:09PM +0100, Mark Brown wrote: > > > > > > > On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote: > > > > > > > > Add a helper for the EDID like data structure, which is typically passed > > > > > > > > from a HDMI adapter to its associated audio driver. This informs the > > > > > > > > audio driver of the capabilities of the attached HDMI sink. > > > > > > > > > > > > > > As far as I can tell people are fairly happy with the implementation > > > > > > > here and unless I'm missing something are definitely happy with the > > > > > > > interface. If that's the case can we get this into -next? There's a > > > > > > > lot of interest in HDMI right now (which is great) and this would be > > > > > > > helpful for that, it seems like even if there are issues with the > > > > > > > implementation it would be worth merging as is so we can start adding > > > > > > > users and then do any improvements to the interface in parallel. > > > > > > > > > > > > > > From an interface point of view: > > > > > > > > > > > > > > Reviewed-by: Mark Brown <broonie@kernel.org> > > > > > > > > > > > > I'd be more than happy if Takashi Iwai wants to take them - I'm not > > > > > > planning on the audio driver itself being merged just yet as we still > > > > > > need to properly hammer out the differences between the AHB audio (for > > > > > > iMX6) and I2S audio (for Rockchip) for this device. > > > > > > > > > > Sorry, I've been on vacation in the last two weeks, so slowly > > > > > digesting all backlogs now. > > > > > > > > > > > Alternatively, I could move these two patches to the beginning of my > > > > > > series, and merge that point into my for-next and/or publish it as a > > > > > > separate sub-branch... whatever people want, just let me know. > > > > > > > > > > I'm fine to take the sound part. It's only patches 10 and 11, right? > > > > > Then I can provide a branch that can be merged for the rest drm > > > > > stuff. > > > > > > > > Yep, just patches 10 and 11. If possible, please base these patches on > > > > v4.1-rc1, thanks. > > > > > > I applied them on top of -rc4, I suppose it's OK? > > > > It is, but what it means is that I'll keep my copy of the patches in my > > tree rather than pulling your tree. Having branches spread on different > > start points makes it difficult to generate a patch series from the git > > tree - which is something I continue to do for the SolidRun iMX6 platforms > > (publishing it as separate patches, tarball of those patches and a combined > > patch.) > > > > As I say, it doesn't matter that much, I can just keep my copies of the > > patches, and when this stuff gets rebased to 4.2-rc1, git rebase should > > eliminate them automatically. > > OK, if so, then I rebase on top of -rc1. The branch isn't merged yet, > so no big problem. Now the rebased branch is pushed. I also merged this branch now to for-next branch, so that it'll be tested through linux-next. Takashi
On Fri, May 22, 2015 at 04:05:22PM +0200, Takashi Iwai wrote: > At Fri, 22 May 2015 16:02:13 +0200, > Takashi Iwai wrote: > > OK, if so, then I rebase on top of -rc1. The branch isn't merged yet, > > so no big problem. > > Now the rebased branch is pushed. > > I also merged this branch now to for-next branch, so that it'll be > tested through linux-next. Thanks!
diff --git a/include/sound/pcm_drm_eld.h b/include/sound/pcm_drm_eld.h new file mode 100644 index 000000000000..93357b25d2e2 --- /dev/null +++ b/include/sound/pcm_drm_eld.h @@ -0,0 +1,6 @@ +#ifndef __SOUND_PCM_DRM_ELD_H +#define __SOUND_PCM_DRM_ELD_H + +int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void *eld); + +#endif diff --git a/sound/core/Kconfig b/sound/core/Kconfig index 313f22e9d929..b534c8a6046b 100644 --- a/sound/core/Kconfig +++ b/sound/core/Kconfig @@ -6,6 +6,9 @@ config SND_PCM tristate select SND_TIMER +config SND_PCM_ELD + bool + config SND_DMAENGINE_PCM tristate diff --git a/sound/core/Makefile b/sound/core/Makefile index 4daf2f58261c..591b49157b4d 100644 --- a/sound/core/Makefile +++ b/sound/core/Makefile @@ -13,6 +13,7 @@ snd-$(CONFIG_SND_JACK) += jack.o snd-pcm-y := pcm.o pcm_native.o pcm_lib.o pcm_timer.o pcm_misc.o \ pcm_memory.o memalloc.o snd-pcm-$(CONFIG_SND_DMA_SGBUF) += sgbuf.o +snd-pcm-$(CONFIG_SND_PCM_ELD) += pcm_drm_eld.o # for trace-points CFLAGS_pcm_lib.o := -I$(src) diff --git a/sound/core/pcm_drm_eld.c b/sound/core/pcm_drm_eld.c new file mode 100644 index 000000000000..e70379fb63d0 --- /dev/null +++ b/sound/core/pcm_drm_eld.c @@ -0,0 +1,99 @@ +/* + * PCM DRM helpers + * + * 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. + */ +#include <linux/export.h> +#include <drm/drm_edid.h> +#include <sound/pcm.h> +#include <sound/pcm_drm_eld.h> + +static const unsigned int eld_rates[] = { + 32000, + 44100, + 48000, + 88200, + 96000, + 176400, + 192000, +}; + +static unsigned int sad_max_channels(const u8 *sad) +{ + return 1 + (sad[0] & 7); +} + +static int eld_limit_rates(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct snd_interval *r = hw_param_interval(params, rule->var); + struct snd_interval *c; + unsigned int rate_mask = 7, i; + const u8 *sad, *eld = rule->private; + + sad = drm_eld_sad(eld); + if (sad) { + c = hw_param_interval(params, SNDRV_PCM_HW_PARAM_CHANNELS); + + for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) { + unsigned max_channels = sad_max_channels(sad); + + /* + * Exclude SADs which do not include the + * requested number of channels. + */ + if (c->min <= max_channels) + rate_mask |= sad[1]; + } + } + + return snd_interval_list(r, ARRAY_SIZE(eld_rates), eld_rates, + rate_mask); +} + +static int eld_limit_channels(struct snd_pcm_hw_params *params, + struct snd_pcm_hw_rule *rule) +{ + struct snd_interval *c = hw_param_interval(params, rule->var); + struct snd_interval *r; + struct snd_interval t = { .min = 1, .max = 2, .integer = 1, }; + unsigned int i; + const u8 *sad, *eld = rule->private; + + sad = drm_eld_sad(eld); + if (sad) { + unsigned int rate_mask = 0; + + /* Convert the rate interval to a mask */ + r = hw_param_interval(params, SNDRV_PCM_HW_PARAM_RATE); + for (i = 0; i < ARRAY_SIZE(eld_rates); i++) + if (r->min <= eld_rates[i] && r->max >= eld_rates[i]) + rate_mask |= BIT(i); + + for (i = drm_eld_sad_count(eld); i > 0; i--, sad += 3) + if (rate_mask & sad[1]) + t.max = max(t.max, sad_max_channels(sad)); + } + + return snd_interval_refine(c, &t); +} + +int snd_pcm_hw_constraint_eld(struct snd_pcm_runtime *runtime, void *eld) +{ + int ret; + + ret = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_RATE, + eld_limit_rates, eld, + SNDRV_PCM_HW_PARAM_CHANNELS, -1); + if (ret < 0) + return ret; + + ret = snd_pcm_hw_rule_add(runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS, + eld_limit_channels, eld, + SNDRV_PCM_HW_PARAM_RATE, -1); + + return ret; +} +EXPORT_SYMBOL_GPL(snd_pcm_hw_constraint_eld);
Add a helper for the EDID like data structure, which is typically passed from a HDMI adapter to its associated audio driver. This informs the audio driver of the capabilities of the attached HDMI sink. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> --- include/sound/pcm_drm_eld.h | 6 +++ sound/core/Kconfig | 3 ++ sound/core/Makefile | 1 + sound/core/pcm_drm_eld.c | 99 +++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 109 insertions(+) create mode 100644 include/sound/pcm_drm_eld.h create mode 100644 sound/core/pcm_drm_eld.c