From: Wu Fengguang <fengguang.wu@intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Clemens Ladisch <clemens@ladisch.de>
Subject: Re: [PATCH 1/5] allow up to 32 PCM devices
Date: Fri, 14 May 2010 16:32:54 +0800 [thread overview]
Message-ID: <20100514083254.GA5723@localhost> (raw)
In-Reply-To: <s5hocgiq4ga.wl%tiwai@suse.de>
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.
> > >
> > > Right. We can make it dependent.
> > >
> >
> > Like this?
> >
> > config SND_HDA_CODEC_INTELHDMI
> > bool "Build INTEL HDMI HD-audio codec support"
> > + select SND_DYNAMIC_MINORS
> > default y
> >
> > That will effectively turn on CONFIG_SND_DYNAMIC_MINORS by default
> > (distribution kernels will have to enable it).
>
> It's always a question whether we use "depends on" or "select".
> The former is safer while the latter is more intuitive.
>
> In this particular case, I think "select" would be OK.
> If other guys have no objection, please repost the patch so that I can
> pick it up later.
OK. Wait a minute :)
> > Another backwards compatible solution is to fall back to the two
> > reserved values. This makes me a bit more comfortable :)
>
> As mentioned in another post, I don't see a big merit by it.
> In short: don't touch a working code :) The non-dynamic minors are
> only for old stuff, better to keep as is.
OK. I'll drop that idea.
Thanks,
Fengguang
next prev parent reply other threads:[~2010-05-14 8:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-12 1:30 [PATCH 0/5] updates for Intel SandyBridge/CougarPoint HDMI codec Wu Fengguang
2010-05-12 1:30 ` [PATCH 1/5] allow up to 32 PCM devices Wu Fengguang
2010-05-12 7:29 ` Jaroslav Kysela
2010-05-12 8:03 ` Takashi Iwai
2010-05-12 8:39 ` Wu Fengguang
2010-05-12 9:01 ` Takashi Iwai
2010-05-12 10:06 ` Wu Fengguang
2010-05-13 0:05 ` Eliot Blennerhassett
2010-05-12 10:20 ` Clemens Ladisch
2010-05-12 10:55 ` Takashi Iwai
2010-05-13 2:21 ` Wu Fengguang
2010-05-14 8:21 ` Takashi Iwai
2010-05-14 8:32 ` Wu Fengguang [this message]
2010-05-12 9:49 ` Jaroslav Kysela
2010-05-12 1:30 ` [PATCH 2/5] hda - allow up to 10 Azalia codecs Wu Fengguang
2010-05-12 14:35 ` Takashi Iwai
2010-05-13 3:03 ` Wu Fengguang
2010-05-12 1:30 ` [PATCH 3/5] intelhdmi - user friendly codec name Wu Fengguang
2010-05-12 1:30 ` [PATCH 4/5] intelhdmi - add id for the CougarPoint chipset Wu Fengguang
2010-05-12 1:30 ` [PATCH 5/5] hdmi - dont fail on extra nodes Wu Fengguang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100514083254.GA5723@localhost \
--to=fengguang.wu@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).