Wu Fengguang | 12 May 03:30 2010
Picon

[PATCH 0/5] updates for Intel SandyBridge/CougarPoint HDMI codec

Hi Takashi,

The Intel SandyBridge/CougarPoint HDMI codec is very similar to the
IbexPeak HDMI codec, except that it exports one more Audio Converter.

Now we have 3 Audio Converters, each of them present one HDMI PCM device:
(and expect a 4th HDMI PCM device in future)

	$ aplay -l | grep HDMI
	card 0: PCH [HDA Intel PCH], device 3: INTEL HDMI 0 [INTEL HDMI 0]
	card 0: PCH [HDA Intel PCH], device 7: INTEL HDMI 1 [INTEL HDMI 1]
	card 0: PCH [HDA Intel PCH], device 8: INTEL HDMI 2 [INTEL HDMI 2]

So ALSA has to support more than 8 PCM playback devices now. The first two
patches do this dirty work, however I'm not sure if they will introduce some
side effects.

The last three patches are more straightforward and safe.

Thanks,
Fengguang
Wu Fengguang | 12 May 03:30 2010
Picon

[PATCH 2/5] hda - allow up to 10 Azalia codecs

Currently AZX_MAX_CODECS is defined to 8. Increase it to 10 in order to
support the HDMI device indices {3, 7, 8, 9}.

The HD audio spec allows up to 14 codecs. So we are still within the
hardware capacity.

Signed-off-by: Wu Fengguang <fengguang.wu <at> intel.com>
---
 sound/pci/hda/hda_intel.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- sound-2.6.orig/sound/pci/hda/hda_intel.c	2010-05-10 09:40:20.000000000 +0800
+++ sound-2.6/sound/pci/hda/hda_intel.c	2010-05-11 13:02:51.000000000 +0800
 <at>  <at>  -267,7 +267,7  <at>  <at>  enum { SDI0, SDI1, SDI2, SDI3, SDO0, SDO
 #define RIRB_INT_MASK		0x05

 /* STATESTS int mask: S3,SD2,SD1,SD0 */
-#define AZX_MAX_CODECS		8
+#define AZX_MAX_CODECS		10
 #define AZX_DEFAULT_CODECS	4
 #define STATESTS_INT_MASK	((1 << AZX_MAX_CODECS) - 1)

 <at>  <at>  -866,7 +866,7  <at>  <at>  static int azx_reset(struct azx *chip, i
 		goto __skip;

 	/* clear STATESTS */
-	azx_writeb(chip, STATESTS, STATESTS_INT_MASK);
+	azx_writew(chip, STATESTS, STATESTS_INT_MASK);

 	/* reset controller */
(Continue reading)

Takashi Iwai | 12 May 16:35 2010
Picon

Re: [PATCH 2/5] hda - allow up to 10 Azalia codecs

At Wed, 12 May 2010 09:30:17 +0800,
Wu Fengguang wrote:
> 
> Currently AZX_MAX_CODECS is defined to 8. Increase it to 10 in order to
> support the HDMI device indices {3, 7, 8, 9}.

If I understand correctly, the codec slot number is basically
independent from the PCM device number assigned.  Hence this change
shouldn't be necessary unless you really have more than 8 codec
chips.  Or will be such a high codec address expected soon on new
Intel platforms?

> The HD audio spec allows up to 14 codecs. So we are still within the
> hardware capacity.

I thought this was at most 8, so I used the value 0x100 as a special
bit flag for probe_mask module option :-<
We'd need to change this if we extend the max codecs...

thanks,

Takashi

> 
> Signed-off-by: Wu Fengguang <fengguang.wu <at> intel.com>
> ---
>  sound/pci/hda/hda_intel.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> --- sound-2.6.orig/sound/pci/hda/hda_intel.c	2010-05-10 09:40:20.000000000 +0800
(Continue reading)

Wu Fengguang | 13 May 05:03 2010
Picon

Re: [PATCH 2/5] hda - allow up to 10 Azalia codecs

On Wed, May 12, 2010 at 10:35:46PM +0800, Takashi Iwai wrote:
> At Wed, 12 May 2010 09:30:17 +0800,
> Wu Fengguang wrote:
> > 
> > Currently AZX_MAX_CODECS is defined to 8. Increase it to 10 in order to
> > support the HDMI device indices {3, 7, 8, 9}.
> 
> If I understand correctly, the codec slot number is basically
> independent from the PCM device number assigned.  Hence this change
> shouldn't be necessary unless you really have more than 8 codec
> chips.  Or will be such a high codec address expected soon on new
> Intel platforms?

You are right, it works without this patch. Sorry for the confusion!

> > The HD audio spec allows up to 14 codecs. So we are still within the
> > hardware capacity.
> 
> I thought this was at most 8, so I used the value 0x100 as a special
> bit flag for probe_mask module option :-<
> We'd need to change this if we extend the max codecs...

It may allow 15 codecs in fact. I get the max number from "Figure 32.
Codec Address Assignment Frame":

CODEC Samples Address ** Address 15 is reserved for
 0 1 2 3 ......... 14    link protocol purposes and
                         may not be assigned to
                         CODECs

(Continue reading)

Wu Fengguang | 12 May 03:30 2010
Picon

[PATCH 3/5] intelhdmi - user friendly codec name

Use the full chipset codename as codec name.
They are more user friendly than the spec abbrs.

Signed-off-by: Wu Fengguang <fengguang.wu <at> intel.com>
---
 sound/pci/hda/patch_intelhdmi.c |   16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

--- sound-2.6.orig/sound/pci/hda/patch_intelhdmi.c	2010-05-11 13:03:50.000000000 +0800
+++ sound-2.6/sound/pci/hda/patch_intelhdmi.c	2010-05-11 13:04:39.000000000 +0800
 <at>  <at>  -185,14 +185,14  <at>  <at>  static int patch_intel_hdmi(struct hda_c
 }

 static struct hda_codec_preset snd_hda_preset_intelhdmi[] = {
-	{ .id = 0x808629fb, .name = "G45 DEVCL",  .patch = patch_intel_hdmi },
-	{ .id = 0x80862801, .name = "G45 DEVBLC", .patch = patch_intel_hdmi },
-	{ .id = 0x80862802, .name = "G45 DEVCTG", .patch = patch_intel_hdmi },
-	{ .id = 0x80862803, .name = "G45 DEVELK", .patch = patch_intel_hdmi },
-	{ .id = 0x80862804, .name = "G45 DEVIBX", .patch = patch_intel_hdmi },
-	{ .id = 0x80860054, .name = "Q57 DEVIBX", .patch = patch_intel_hdmi },
-	{ .id = 0x10951392, .name = "SiI1392 HDMI",     .patch = patch_intel_hdmi },
-	{} /* terminator */
+{ .id = 0x808629fb, .name = "Crestline HDMI",	.patch = patch_intel_hdmi },
+{ .id = 0x80862801, .name = "Bearlake HDMI",	.patch = patch_intel_hdmi },
+{ .id = 0x80862802, .name = "Cantiga HDMI",	.patch = patch_intel_hdmi },
+{ .id = 0x80862803, .name = "Eaglelake HDMI",	.patch = patch_intel_hdmi },
+{ .id = 0x80862804, .name = "IbexPeak HDMI",	.patch = patch_intel_hdmi },
+{ .id = 0x80860054, .name = "IbexPeak HDMI",	.patch = patch_intel_hdmi },
+{ .id = 0x10951392, .name = "SiI1392 HDMI",	.patch = patch_intel_hdmi },
+{} /* terminator */
(Continue reading)

Wu Fengguang | 12 May 03:30 2010
Picon

[PATCH 5/5] hdmi - dont fail on extra nodes

The number of HDMI nodes is expected to go up in future.
So don't fail hard on seeing extra converter/pin nodes.

We can still operate safely on the nodes within
MAX_HDMI_CVTS/MAX_HDMI_PINS.

Signed-off-by: Wu Fengguang <fengguang.wu <at> intel.com>
---
 sound/pci/hda/patch_hdmi.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

--- sound-2.6.orig/sound/pci/hda/patch_hdmi.c	2010-05-11 13:25:35.000000000 +0800
+++ sound-2.6/sound/pci/hda/patch_hdmi.c	2010-05-11 13:53:47.000000000 +0800
 <at>  <at>  -766,7 +766,7  <at>  <at>  static int hdmi_add_pin(struct hda_codec
 	if (spec->num_pins >= MAX_HDMI_PINS) {
 		snd_printk(KERN_WARNING
 			   "HDMI: no space for pin %d\n", pin_nid);
-		return -EINVAL;
+		return -E2BIG;
 	}

 	hdmi_present_sense(codec, pin_nid, &spec->sink_eld[spec->num_pins]);
 <at>  <at>  -788,7 +788,7  <at>  <at>  static int hdmi_add_cvt(struct hda_codec
 	if (spec->num_cvts >= MAX_HDMI_CVTS) {
 		snd_printk(KERN_WARNING
 			   "HDMI: no space for converter %d\n", nid);
-		return -EINVAL;
+		return -E2BIG;
 	}

(Continue reading)

Wu Fengguang | 12 May 03:30 2010
Picon

[PATCH 4/5] intelhdmi - add id for the CougarPoint chipset

Add id for Intel CougarPoint HDMI audio codec.

CougarPoint provides 3 Audio Converters.
Increase MAX_HDMI_CVTS/MAX_HDMI_PINS accordingly.

Signed-off-by: Wu Fengguang <fengguang.wu <at> intel.com>
---
 sound/pci/hda/patch_intelhdmi.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- sound-2.6.orig/sound/pci/hda/patch_intelhdmi.c	2010-05-11 13:04:39.000000000 +0800
+++ sound-2.6/sound/pci/hda/patch_intelhdmi.c	2010-05-11 13:22:30.000000000 +0800
 <at>  <at>  -40,7 +40,7  <at>  <at> 
  *
  * The HDA correspondence of pipes/ports are converter/pin nodes.
  */
-#define MAX_HDMI_CVTS	2
+#define MAX_HDMI_CVTS	3
 #define MAX_HDMI_PINS	3

 #include "patch_hdmi.c"
 <at>  <at>  -48,6 +48,7  <at>  <at> 
 static char *intel_hdmi_pcm_names[MAX_HDMI_CVTS] = {
 	"INTEL HDMI 0",
 	"INTEL HDMI 1",
+	"INTEL HDMI 2",
 };

 /*
 <at>  <at>  -191,6 +192,7  <at>  <at>  static struct hda_codec_preset snd_hda_p
(Continue reading)

Wu Fengguang | 12 May 03:30 2010
Picon

[PATCH 1/5] allow up to 32 PCM devices

Reserve 32 minor numbers for PCM playback devices.

The Intel SandyBridge HDMI audio codec provides 3 PCM devices with
indices 3, 7, 8. Among which the device 8's minor number will be
overlapped with the first capture device's minor number in the current
static minor number allocation scheme.

Also increase SNDRV_PCM_DEVICES to make pcm_dev_bits big enough to hold
the increasing number of PCM devices.

Signed-off-by: Wu Fengguang <fengguang.wu <at> intel.com>
---
 include/sound/minors.h |   16 ++++++++--------
 include/sound/pcm.h    |    2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

--- sound-2.6.orig/include/sound/minors.h	2010-04-16 16:03:28.000000000 +0800
+++ sound-2.6/include/sound/minors.h	2010-05-11 13:02:48.000000000 +0800
 <at>  <at>  -23,23 +23,23  <at>  <at> 

 #define SNDRV_OS_MINORS			256

-#define SNDRV_MINOR_DEVICES		32
-#define SNDRV_MINOR_CARD(minor)		((minor) >> 5)
-#define SNDRV_MINOR_DEVICE(minor)	((minor) & 0x001f)
-#define SNDRV_MINOR(card, dev)		(((card) << 5) | (dev))
+#define SNDRV_MINOR_DEVICES		64
+#define SNDRV_MINOR_CARD(minor)		((minor) >> 6)
+#define SNDRV_MINOR_DEVICE(minor)	((minor) & 0x003f)
+#define SNDRV_MINOR(card, dev)		(((card) << 6) | (dev))
(Continue reading)

Jaroslav Kysela | 12 May 09:29 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

On Wed, 12 May 2010, Wu Fengguang wrote:

> Reserve 32 minor numbers for PCM playback devices.
>
> The Intel SandyBridge HDMI audio codec provides 3 PCM devices with
> indices 3, 7, 8. Among which the device 8's minor number will be
> overlapped with the first capture device's minor number in the current
> static minor number allocation scheme.
>
> Also increase SNDRV_PCM_DEVICES to make pcm_dev_bits big enough to hold
> the increasing number of PCM devices.

I don't agree to have only 4 slots for soundcards in the static minor 
numbering. Maybe the driver should be converted to use subdevices or we 
might drop the static minor number allocation at all (it might have only 
impact for old distros).

 						Jaroslav

-----
Jaroslav Kysela <perex <at> perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
Takashi Iwai | 12 May 10:03 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

At Wed, 12 May 2010 09:29:57 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Wed, 12 May 2010, Wu Fengguang wrote:
> 
> > Reserve 32 minor numbers for PCM playback devices.
> >
> > The Intel SandyBridge HDMI audio codec provides 3 PCM devices with
> > indices 3, 7, 8. Among which the device 8's minor number will be
> > overlapped with the first capture device's minor number in the current
> > static minor number allocation scheme.
> >
> > Also increase SNDRV_PCM_DEVICES to make pcm_dev_bits big enough to hold
> > the increasing number of PCM devices.
> 
> I don't agree to have only 4 slots for soundcards in the static minor 
> numbering. Maybe the driver should be converted to use subdevices or we 
> might drop the static minor number allocation at all (it might have only 
> impact for old distros).

Dropping such a base feature is really no good option.  Better to give
simply an error for more than 8 PCMs in such a case, IMO.

I also wonder whether having 4 individual PCMs is a way to go.  We may
have PCM substreams, if any.  OTOH, the current IEC958 stream
assignment mechanism doesn't consider multiple substreams well, e.g.
we have no proper way to match the IEC958 status bits control to a PCM
substream.

thanks,
(Continue reading)

Wu Fengguang | 12 May 10:39 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

On Wed, May 12, 2010 at 04:03:43PM +0800, Takashi Iwai wrote:
> At Wed, 12 May 2010 09:29:57 +0200 (CEST),
> Jaroslav Kysela wrote:
> > 
> > On Wed, 12 May 2010, Wu Fengguang wrote:
> > 
> > > Reserve 32 minor numbers for PCM playback devices.
> > >
> > > The Intel SandyBridge HDMI audio codec provides 3 PCM devices with
> > > indices 3, 7, 8. Among which the device 8's minor number will be
> > > overlapped with the first capture device's minor number in the current
> > > static minor number allocation scheme.
> > >
> > > Also increase SNDRV_PCM_DEVICES to make pcm_dev_bits big enough to hold
> > > the increasing number of PCM devices.
> > 
> > I don't agree to have only 4 slots for soundcards in the static minor 
> > numbering. Maybe the driver should be converted to use subdevices or we 
> > might drop the static minor number allocation at all (it might have only 
> > impact for old distros).

Jaroslav, will there be so many sound cards in one system?

> Dropping such a base feature is really no good option.  Better to give
> simply an error for more than 8 PCMs in such a case, IMO.

Agreed.

> I also wonder whether having 4 individual PCMs is a way to go.  We may
> have PCM substreams, if any.  OTOH, the current IEC958 stream
(Continue reading)

Takashi Iwai | 12 May 11:01 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

At Wed, 12 May 2010 16:39:50 +0800,
Wu Fengguang wrote:
> 
> On Wed, May 12, 2010 at 04:03:43PM +0800, Takashi Iwai wrote:
> > At Wed, 12 May 2010 09:29:57 +0200 (CEST),
> > Jaroslav Kysela wrote:
> > > 
> > > On Wed, 12 May 2010, Wu Fengguang wrote:
> > > 
> > > > Reserve 32 minor numbers for PCM playback devices.
> > > >
> > > > The Intel SandyBridge HDMI audio codec provides 3 PCM devices with
> > > > indices 3, 7, 8. Among which the device 8's minor number will be
> > > > overlapped with the first capture device's minor number in the current
> > > > static minor number allocation scheme.
> > > >
> > > > Also increase SNDRV_PCM_DEVICES to make pcm_dev_bits big enough to hold
> > > > the increasing number of PCM devices.
> > > 
> > > I don't agree to have only 4 slots for soundcards in the static minor 
> > > numbering. Maybe the driver should be converted to use subdevices or we 
> > > might drop the static minor number allocation at all (it might have only 
> > > impact for old distros).
> 
> Jaroslav, will there be so many sound cards in one system?

In the old time, yes.  Now we have less and less PCI slots.
In theory, we may have lots of USB audio devices, though :)

Another possible solution would be to change the minor number
(Continue reading)

Wu Fengguang | 12 May 12:06 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

On Wed, May 12, 2010 at 05:01:57PM +0800, Takashi Iwai wrote:
> At Wed, 12 May 2010 16:39:50 +0800,
> Wu Fengguang wrote:
> > 
> > On Wed, May 12, 2010 at 04:03:43PM +0800, Takashi Iwai wrote:
> > > At Wed, 12 May 2010 09:29:57 +0200 (CEST),
> > > Jaroslav Kysela wrote:
> > > > 
> > > > On Wed, 12 May 2010, Wu Fengguang wrote:
> > > > 
> > > > > Reserve 32 minor numbers for PCM playback devices.
> > > > >
> > > > > The Intel SandyBridge HDMI audio codec provides 3 PCM devices with
> > > > > indices 3, 7, 8. Among which the device 8's minor number will be
> > > > > overlapped with the first capture device's minor number in the current
> > > > > static minor number allocation scheme.
> > > > >
> > > > > Also increase SNDRV_PCM_DEVICES to make pcm_dev_bits big enough to hold
> > > > > the increasing number of PCM devices.
> > > > 
> > > > I don't agree to have only 4 slots for soundcards in the static minor 
> > > > numbering. Maybe the driver should be converted to use subdevices or we 
> > > > might drop the static minor number allocation at all (it might have only 
> > > > impact for old distros).
> > 
> > Jaroslav, will there be so many sound cards in one system?
> 
> In the old time, yes.  Now we have less and less PCI slots.
> In theory, we may have lots of USB audio devices, though :)
> 
(Continue reading)

Eliot Blennerhassett | 13 May 02:05 2010

Re: [PATCH 1/5] allow up to 32 PCM devices

On 12/05/10 22:06, Wu Fengguang wrote:

> Can I ask a dumb question? Currently I select the target playback
> device with the -D option:
> 
>         speaker-test -Dhw:0,3 
> 
> How can I do the job when PCM substreams are used?

         speaker-test -Dhw:0,0,3
Clemens Ladisch | 12 May 12:20 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

Takashi Iwai wrote:
> Wu Fengguang wrote:
> > > Jaroslav Kysela wrote:
> > > > I don't agree to have only 4 slots for soundcards in the static minor 
> > > > numbering. Maybe the driver should be converted to use subdevices or we 
> > > > might drop the static minor number allocation at all (it might have only 
> > > > impact for old distros).
> > 
> > Jaroslav, will there be so many sound cards in one system?
> 
> In the old time, yes.  Now we have less and less PCI slots.
> In theory, we may have lots of USB audio devices, though :)

I implemented CONFIG_SND_DYNAMIC_MINORS because people had been asking
for more than eight cards.  (And by now I have lots of cards too,
although my computer probably isn't very typical.)

Anyway, static numbering is needed only for systems without udev/devfs,
and there we shouldn't change it for backwards compatibility.  The HDA
driver already requires kernels >= 2.6, so I don't see a problem with
requiring CONFIG_SND_DYNAMIC_MINORS to get all HDMI outputs.

> Another possible solution would be to change the minor number
> assignment to a really dynamic one.  So far, due to legacy /dev/aload
> and co, we have some static restriction per card basis.

What restriction would that be?  With CONFIG_SND_DYNAMIC_MINORS, we
don't allocate minors that would be used by /dev/aload*, but there are
no restrictions on the number of cards or devices.

(Continue reading)

Takashi Iwai | 12 May 12:55 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

At Wed, 12 May 2010 12:20:33 +0200,
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > Wu Fengguang wrote:
> > > > Jaroslav Kysela wrote:
> > > > > I don't agree to have only 4 slots for soundcards in the static minor 
> > > > > numbering. Maybe the driver should be converted to use subdevices or we 
> > > > > might drop the static minor number allocation at all (it might have only 
> > > > > impact for old distros).
> > > 
> > > Jaroslav, will there be so many sound cards in one system?
> > 
> > In the old time, yes.  Now we have less and less PCI slots.
> > In theory, we may have lots of USB audio devices, though :)
> 
> I implemented CONFIG_SND_DYNAMIC_MINORS because people had been asking
> for more than eight cards.  (And by now I have lots of cards too,
> although my computer probably isn't very typical.)
> 
> Anyway, static numbering is needed only for systems without udev/devfs,
> and there we shouldn't change it for backwards compatibility.  The HDA
> driver already requires kernels >= 2.6, so I don't see a problem with
> requiring CONFIG_SND_DYNAMIC_MINORS to get all HDMI outputs.

Right.  We can make it dependent.

> > Another possible solution would be to change the minor number
> > assignment to a really dynamic one.  So far, due to legacy /dev/aload
> > and co, we have some static restriction per card basis.
(Continue reading)

Wu Fengguang | 13 May 04:21 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

On Wed, May 12, 2010 at 06:55:09PM +0800, Takashi Iwai wrote:
> At Wed, 12 May 2010 12:20:33 +0200,
> Clemens Ladisch wrote:
> > 
> > Takashi Iwai wrote:
> > > Wu Fengguang wrote:
> > > > > Jaroslav Kysela wrote:
> > > > > > I don't agree to have only 4 slots for soundcards in the static minor 
> > > > > > numbering. Maybe the driver should be converted to use subdevices or we 
> > > > > > might drop the static minor number allocation at all (it might have only 
> > > > > > impact for old distros).
> > > > 
> > > > Jaroslav, will there be so many sound cards in one system?
> > > 
> > > In the old time, yes.  Now we have less and less PCI slots.
> > > In theory, we may have lots of USB audio devices, though :)
> > 
> > I implemented CONFIG_SND_DYNAMIC_MINORS because people had been asking
> > for more than eight cards.  (And by now I have lots of cards too,
> > although my computer probably isn't very typical.)
> > 
> > Anyway, static numbering is needed only for systems without udev/devfs,
> > and there we shouldn't change it for backwards compatibility.  The HDA
> > driver already requires kernels >= 2.6, so I don't see a problem with
> > requiring CONFIG_SND_DYNAMIC_MINORS to get all HDMI outputs.
> 
> Right.  We can make it dependent.
> 

Like this?
(Continue reading)

Takashi Iwai | 14 May 10:21 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

At Thu, 13 May 2010 10:21:26 +0800,
Wu Fengguang wrote:
> 
> On Wed, May 12, 2010 at 06:55:09PM +0800, Takashi Iwai wrote:
> > At Wed, 12 May 2010 12:20:33 +0200,
> > Clemens Ladisch wrote:
> > > 
> > > Takashi Iwai wrote:
> > > > Wu Fengguang wrote:
> > > > > > Jaroslav Kysela wrote:
> > > > > > > I don't agree to have only 4 slots for soundcards in the static minor 
> > > > > > > numbering. Maybe the driver should be converted to use subdevices or we 
> > > > > > > might drop the static minor number allocation at all (it might have only 
> > > > > > > impact for old distros).
> > > > > 
> > > > > Jaroslav, will there be so many sound cards in one system?
> > > > 
> > > > In the old time, yes.  Now we have less and less PCI slots.
> > > > In theory, we may have lots of USB audio devices, though :)
> > > 
> > > I implemented CONFIG_SND_DYNAMIC_MINORS because people had been asking
> > > for more than eight cards.  (And by now I have lots of cards too,
> > > although my computer probably isn't very typical.)
> > > 
> > > Anyway, static numbering is needed only for systems without udev/devfs,
> > > and there we shouldn't change it for backwards compatibility.  The HDA
> > > driver already requires kernels >= 2.6, so I don't see a problem with
> > > requiring CONFIG_SND_DYNAMIC_MINORS to get all HDMI outputs.
> > 
> > Right.  We can make it dependent.
(Continue reading)

Wu Fengguang | 14 May 10:32 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

On Fri, May 14, 2010 at 04:21:09PM +0800, Takashi Iwai wrote:
> At Thu, 13 May 2010 10:21:26 +0800,
> Wu Fengguang wrote:
> > 
> > On Wed, May 12, 2010 at 06:55:09PM +0800, Takashi Iwai wrote:
> > > At Wed, 12 May 2010 12:20:33 +0200,
> > > Clemens Ladisch wrote:
> > > > 
> > > > Takashi Iwai wrote:
> > > > > Wu Fengguang wrote:
> > > > > > > Jaroslav Kysela wrote:
> > > > > > > > I don't agree to have only 4 slots for soundcards in the static minor 
> > > > > > > > numbering. Maybe the driver should be converted to use subdevices or we 
> > > > > > > > might drop the static minor number allocation at all (it might have only 
> > > > > > > > impact for old distros).
> > > > > > 
> > > > > > Jaroslav, will there be so many sound cards in one system?
> > > > > 
> > > > > In the old time, yes.  Now we have less and less PCI slots.
> > > > > In theory, we may have lots of USB audio devices, though :)
> > > > 
> > > > I implemented CONFIG_SND_DYNAMIC_MINORS because people had been asking
> > > > for more than eight cards.  (And by now I have lots of cards too,
> > > > although my computer probably isn't very typical.)
> > > > 
> > > > Anyway, static numbering is needed only for systems without udev/devfs,
> > > > and there we shouldn't change it for backwards compatibility.  The HDA
> > > > driver already requires kernels >= 2.6, so I don't see a problem with
> > > > requiring CONFIG_SND_DYNAMIC_MINORS to get all HDMI outputs.
> > > 
(Continue reading)

Jaroslav Kysela | 12 May 11:49 2010
Picon

Re: [PATCH 1/5] allow up to 32 PCM devices

On Wed, 12 May 2010, Takashi Iwai wrote:

> At Wed, 12 May 2010 09:29:57 +0200 (CEST),
> Jaroslav Kysela wrote:
>>
>> On Wed, 12 May 2010, Wu Fengguang wrote:
>>
>>> Reserve 32 minor numbers for PCM playback devices.
>>>
>>> The Intel SandyBridge HDMI audio codec provides 3 PCM devices with
>>> indices 3, 7, 8. Among which the device 8's minor number will be
>>> overlapped with the first capture device's minor number in the current
>>> static minor number allocation scheme.
>>>
>>> Also increase SNDRV_PCM_DEVICES to make pcm_dev_bits big enough to hold
>>> the increasing number of PCM devices.
>>
>> I don't agree to have only 4 slots for soundcards in the static minor
>> numbering. Maybe the driver should be converted to use subdevices or we
>> might drop the static minor number allocation at all (it might have only
>> impact for old distros).
>
> Dropping such a base feature is really no good option.  Better to give
> simply an error for more than 8 PCMs in such a case, IMO.
>
> I also wonder whether having 4 individual PCMs is a way to go.  We may
> have PCM substreams, if any.  OTOH, the current IEC958 stream

Yes, I noted this above.

(Continue reading)


Gmane