[10/13] sound/core: add DRM ELD helper
diff mbox

Message ID E1Yr1xy-0006l8-Ft@rmk-PC.arm.linux.org.uk
State New
Headers show

Commit Message

Russell King May 9, 2015, 10:26 a.m. UTC
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

Comments

Mark Brown May 22, 2015, 12:20 p.m. UTC | #1
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>
Russell King - ARM Linux May 22, 2015, 1:15 p.m. UTC | #2
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.
Takashi Iwai May 22, 2015, 1:30 p.m. UTC | #3
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
Russell King - ARM Linux May 22, 2015, 1:53 p.m. UTC | #4
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.
Takashi Iwai May 22, 2015, 1:54 p.m. UTC | #5
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
Russell King - ARM Linux May 22, 2015, 2 p.m. UTC | #6
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.
Takashi Iwai May 22, 2015, 2:02 p.m. UTC | #7
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
Takashi Iwai May 22, 2015, 2:05 p.m. UTC | #8
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
Russell King - ARM Linux May 22, 2015, 4:12 p.m. UTC | #9
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!

Patch
diff mbox

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);