Problem with Avermedia 771

Problem with Avermedia 771

[Gerd Knorr]

  Hi guys,

We are talking about the bt878 second PCI function here.  On some analog
cards it is used to capture audio, some dvb cards use it to transfer
MPEG streams.  Problem is that both alsa and dvb want grab the device ...

Cc'ing both involved devel mailing lists ...

> >>Audio DMA channel, and the snd_bt87x module has already taken that over -

> Sure.  Want me to add a:
>               printk("dvb_bt8xx: if you have the ALSA bt87x audio driver "
>                      "installed, try removing it.\n");

Yep, that should improve things.

I think it would be even better if the alsa driver checks the PCI
Subsystem ID of the card in question to figure whenever it should try to
attach to the device or not.  With the dvb driver that already happens
indirectly through bttv (bttv knows which ones are DVB cards and which
ones are not).

The list of DVB card ID's isn't that long at the moment (from bttv):

	// DVB cards (using pci function .1 for mpeg data xfer)
	{ 0x01010071, BTTV_NEBULA_DIGITV, "Nebula Electronics DigiTV" },
	{ 0x07611461, BTTV_AVDVBT_761,    "AverMedia AverTV DVB-T" },
	{ 0x002611bd, BTTV_TWINHAN_DST,   "Pinnacle PCTV SAT CI" },
	{ 0x00011822, BTTV_TWINHAN_DST,   "Twinhan VisionPlus DVB-T" },
	{ 0xfc00270f, BTTV_TWINHAN_DST,   "ChainTech digitop DST-1000 DVB-S" },
	{ 0x07711461, BTTV_AVDVBT_771,    "AVermedia DVB-T 771" },
	{ 0xdb1018ac, BTTV_DVICO_DVBT_LITE,    "DVICO FusionHDTV DVB-T Lite" },
            ^^^^      subsystem device
                ^^^^  subsystem vendor

The alsa driver could either blacklist those or use a whitelist.  The
whitelist approach probably is more work, but would have the advantage
that the driver could also filter out analog tv cards where you don't
get any useful audio data out of the card.  And there is at least one
DVB card which can't be identified by PCI Subsystem ID because it hasn't
one, the whitelist approach would catch that one as well.

Comments?

  Gerd

-- 
return -ENOSIG;

Re: Problem with Avermedia 771

[Jaroslav Kysela]

On Fri, 15 Oct 2004, Gerd Knorr wrote:

> The list of DVB card ID's isn't that long at the moment (from bttv):
> 
> 	// DVB cards (using pci function .1 for mpeg data xfer)
> 	{ 0x01010071, BTTV_NEBULA_DIGITV, "Nebula Electronics DigiTV" },
> 	{ 0x07611461, BTTV_AVDVBT_761,    "AverMedia AverTV DVB-T" },
> 	{ 0x002611bd, BTTV_TWINHAN_DST,   "Pinnacle PCTV SAT CI" },
> 	{ 0x00011822, BTTV_TWINHAN_DST,   "Twinhan VisionPlus DVB-T" },
> 	{ 0xfc00270f, BTTV_TWINHAN_DST,   "ChainTech digitop DST-1000 DVB-S" },
> 	{ 0x07711461, BTTV_AVDVBT_771,    "AVermedia DVB-T 771" },
> 	{ 0xdb1018ac, BTTV_DVICO_DVBT_LITE,    "DVICO FusionHDTV DVB-T Lite" },
>             ^^^^      subsystem device
>                 ^^^^  subsystem vendor
> 
> The alsa driver could either blacklist those or use a whitelist.  The
> whitelist approach probably is more work, but would have the advantage
> that the driver could also filter out analog tv cards where you don't
> get any useful audio data out of the card.  And there is at least one
> DVB card which can't be identified by PCI Subsystem ID because it hasn't
> one, the whitelist approach would catch that one as well.
> 
> Comments?

I think that the database should be on one central place.
I suggest to create a simple function in a standalone module:

#define BTTV_CAP_AUDIOISVIDEO	(1<<0)

unsigned int bttv_caps(struct pci_dev *bttv, char **name);

It will simply check, if audio is real audio and return the real name for 
passed bttv card. Then we can call this function from our driver, too.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [Alsa-devel] Problem with Avermedia 771

[Holger Waechtler]

Jaroslav Kysela wrote:

>On Fri, 15 Oct 2004, Gerd Knorr wrote:
>
>  
>
>>The list of DVB card ID's isn't that long at the moment (from bttv):
>>
>>	// DVB cards (using pci function .1 for mpeg data xfer)
>>	{ 0x01010071, BTTV_NEBULA_DIGITV, "Nebula Electronics DigiTV" },
>>	{ 0x07611461, BTTV_AVDVBT_761,    "AverMedia AverTV DVB-T" },
>>	{ 0x002611bd, BTTV_TWINHAN_DST,   "Pinnacle PCTV SAT CI" },
>>	{ 0x00011822, BTTV_TWINHAN_DST,   "Twinhan VisionPlus DVB-T" },
>>	{ 0xfc00270f, BTTV_TWINHAN_DST,   "ChainTech digitop DST-1000 DVB-S" },
>>	{ 0x07711461, BTTV_AVDVBT_771,    "AVermedia DVB-T 771" },
>>	{ 0xdb1018ac, BTTV_DVICO_DVBT_LITE,    "DVICO FusionHDTV DVB-T Lite" },
>>            ^^^^      subsystem device
>>                ^^^^  subsystem vendor
>>
>>The alsa driver could either blacklist those or use a whitelist.  The
>>whitelist approach probably is more work, but would have the advantage
>>that the driver could also filter out analog tv cards where you don't
>>get any useful audio data out of the card.  And there is at least one
>>DVB card which can't be identified by PCI Subsystem ID because it hasn't
>>one, the whitelist approach would catch that one as well.
>>
>>Comments?
>>    
>>
>
>I think that the database should be on one central place.
>I suggest to create a simple function in a standalone module:
>
>#define BTTV_CAP_AUDIOISVIDEO	(1<<0)
>
>unsigned int bttv_caps(struct pci_dev *bttv, char **name);
>
>It will simply check, if audio is real audio and return the real name for 
>passed bttv card. Then we can call this function from our driver, too.
>

Please implement the whitelist approach as suggested by Gerd. It's will 
always cause problems if drivers attach to cards that are not known 
(whitelisted) to work. The whitelists can easily get updated by the 
maintainers, a central database for all cards requires much more efforts.

On the long term it would make things easier if bttv, cx88 and 
saa714x-drivers would not instanciate itself as PCI drivers but would 
only provide the library functions to talk with the hardware. Then the 
DVB/audio/TV-card-driver can implement the PCI attach function on their 
own and are free to use i2c adresses showing up on the board, EEPROM 
content etc to validate whitelisted cards, this would even work for the 
cards without valid subsystem IDs.

Holger

Re: Problem with Avermedia 771

[Gerd Knorr]

On Fri, Oct 15, 2004 at 01:03:07PM +0200, Jaroslav Kysela wrote:
> On Fri, 15 Oct 2004, Gerd Knorr wrote:
> 
> I think that the database should be on one central place.
> I suggest to create a simple function in a standalone module:
> 
> #define BTTV_CAP_AUDIOISVIDEO	(1<<0)
> 
> unsigned int bttv_caps(struct pci_dev *bttv, char **name);

Hmm, I was thinking about that as well, I'm not sure it is really a good
idea through.  We have three different different bt878 cards:

  (1) The ones where you can get audio data out of PCI function .1
  (2) The ones which use PCI function .1 for DVB.
  (3) The ones which use PCI function .1 for other data transfers,
      the first WinTV PVR card for example (which isn't supported by
      Linux at the moment, at least not the mpeg stuff).
  (4) Cards where PCI function .1 is simply unused, i.e. you get either
      nothing or just noise if you try to record audio from there.

I think the alsa driver should only try to use cards which fall into
group (1), not everything but (2).  Problem with that is that it simply
isn't known for most cards whenever they are in group (1) or (4).

There are no overlaps between the different card groups, so if every
driver whitelists the IDs for "known-good" hardware there should be no
overlaps between the lists (and thus no point in having a central list).

The whitelist approach would also have the advantage that you can stick
the IDs into a struct pci_device_id list, so they will show up in
/lib/modules/$(uname -r)/modules.pcimap, which will make the hardware
probing easier for the distributions.

  Gerd



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Takashi Iwai]

At Mon, 18 Oct 2004 15:01:14 +0200,
Gerd Knorr wrote:
> 
> On Fri, Oct 15, 2004 at 01:03:07PM +0200, Jaroslav Kysela wrote:
> > On Fri, 15 Oct 2004, Gerd Knorr wrote:
> > 
> > I think that the database should be on one central place.
> > I suggest to create a simple function in a standalone module:
> > 
> > #define BTTV_CAP_AUDIOISVIDEO	(1<<0)
> > 
> > unsigned int bttv_caps(struct pci_dev *bttv, char **name);
> 
> Hmm, I was thinking about that as well, I'm not sure it is really a good
> idea through.  We have three different different bt878 cards:
> 
>   (1) The ones where you can get audio data out of PCI function .1
>   (2) The ones which use PCI function .1 for DVB.
>   (3) The ones which use PCI function .1 for other data transfers,
>       the first WinTV PVR card for example (which isn't supported by
>       Linux at the moment, at least not the mpeg stuff).
>   (4) Cards where PCI function .1 is simply unused, i.e. you get either
>       nothing or just noise if you try to record audio from there.
> 
> I think the alsa driver should only try to use cards which fall into
> group (1), not everything but (2).  Problem with that is that it simply
> isn't known for most cards whenever they are in group (1) or (4).
> 
> There are no overlaps between the different card groups, so if every
> driver whitelists the IDs for "known-good" hardware there should be no
> overlaps between the lists (and thus no point in having a central list).
> 
> The whitelist approach would also have the advantage that you can stick
> the IDs into a struct pci_device_id list, so they will show up in
> /lib/modules/$(uname -r)/modules.pcimap, which will make the hardware
> probing easier for the distributions.

I agree with Gerd.  The whitelisting would be the easiest and the most
trustful way.  Even a new PCI entry can be added dynamically on 2.6
kernels through sysfs.

I see the device list in drivers/media/video/bttv-cards.c as mentioned
in Gerd's original post.  Which ones can be as the white list entries
for ALSA?


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Gerd Knorr]

> >   (1) The ones where you can get audio data out of PCI function .1

> >   (4) Cards where PCI function .1 is simply unused, i.e. you get either
> >       nothing or just noise if you try to record audio from there.

> > I think the alsa driver should only try to use cards which fall into
> > group (1), not everything but (2).  Problem with that is that it simply
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > isn't known for most cards whenever they are in group (1) or (4).
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> I see the device list in drivers/media/video/bttv-cards.c as mentioned
> in Gerd's original post.  Which ones can be as the white list entries
> for ALSA?

Well, the problem is that no such list exists right now, I didn't keep
track of whenever Function .1 can do audio or not in bttvs card database
because bttv doesn't care, it does video only ...

So we'll have to build a whitelist from scratch from user feedback, and
maybe add a insmod option so you can ask the driver to grab the device
even if not whitelisted for easy use.

I know it works with my wintv (0070:13eb), but thats it :-/

  Gerd



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Takashi Iwai]

At Tue, 19 Oct 2004 18:13:40 +0200,
Gerd Knorr wrote:
> 
> > >   (1) The ones where you can get audio data out of PCI function .1
> 
> > >   (4) Cards where PCI function .1 is simply unused, i.e. you get either
> > >       nothing or just noise if you try to record audio from there.
> 
> > > I think the alsa driver should only try to use cards which fall into
> > > group (1), not everything but (2).  Problem with that is that it simply
>                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > isn't known for most cards whenever they are in group (1) or (4).
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> > I see the device list in drivers/media/video/bttv-cards.c as mentioned
> > in Gerd's original post.  Which ones can be as the white list entries
> > for ALSA?
> 
> Well, the problem is that no such list exists right now, I didn't keep
> track of whenever Function .1 can do audio or not in bttvs card database
> because bttv doesn't care, it does video only ...

Ok.

> So we'll have to build a whitelist from scratch from user feedback, and
> maybe add a insmod option so you can ask the driver to grab the device
> even if not whitelisted for easy use.

We have some options for this kind of behavior:

1. the driver has one pci_driver struct, and its pci_id array includes
   the default entries (with PCI_ANY_ID for subsystem ids).

   In this case, the driver checks the pci id in probe and rejects
   unless it's in the whitelist or a specific module option is given.

2. the driver has two pci_driver structs, one only with whitelist and
   one with the whitelist and the default entries.
   In init code, the driver registers the corresponding pci_driver
   record according to the module option.

   In this case, the driver accepts all.
   But which table should be exported via MODULE_DEVICE_TABLE?


I think 1 is the better way but my concern is about the hotplug.
Can this mechanism work with hotplug properly?  I guess yes, but
didn't take a look at any example yet...


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

At Wed, 20 Oct 2004 15:06:38 +0200,
I wrote:
> 
> > So we'll have to build a whitelist from scratch from user feedback, and
> > maybe add a insmod option so you can ask the driver to grab the device
> > even if not whitelisted for easy use.
> 
> We have some options for this kind of behavior:
> 
> 1. the driver has one pci_driver struct, and its pci_id array includes
>    the default entries (with PCI_ANY_ID for subsystem ids).
> 
>    In this case, the driver checks the pci id in probe and rejects
>    unless it's in the whitelist or a specific module option is given.

The experimental patch for this is below.


Takashi

[-- Attachment #2: Type: text/plain, Size: 2313 bytes --]

Index: alsa-kernel/pci/bt87x.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/bt87x.c,v
retrieving revision 1.14
diff -u -r1.14 bt87x.c
--- alsa-kernel/pci/bt87x.c	29 Sep 2004 16:17:59 -0000	1.14
+++ alsa-kernel/pci/bt87x.c	20 Oct 2004 13:17:26 -0000
@@ -45,6 +45,7 @@
 static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;	/* ID for this card */
 static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;	/* Enable this card */
 static int digital_rate[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = 0 }; /* digital input rate */
+static int load_all;	/* allow to load the non-whitelisted cards */
 static int boot_devs;
 
 module_param_array(index, int, boot_devs, 0444);
@@ -55,6 +56,8 @@
 MODULE_PARM_DESC(enable, "Enable Bt87x soundcard");
 module_param_array(digital_rate, int, boot_devs, 0444);
 MODULE_PARM_DESC(digital_rate, "Digital input rate for Bt87x soundcard");
+module_param(load_all, bool, 0444);
+MODULE_PARM_DESC(load_all, "Allow to load the non-whitelisted cards");
 
 
 #ifndef PCI_VENDOR_ID_BROOKTREE
@@ -148,6 +151,9 @@
 #endif
 #define CLOCK_DIV_MAX 15
 
+#define DRIVER_DEFAULT_ENTRY	(1<<24)
+#define DRIVER_RATE_MASK	((1<<24)-1)
+
 #define ERROR_INTERRUPTS (INT_FBUS | INT_FTRGT | INT_PPERR | \
 			  INT_RIPERR | INT_PABORT | INT_OCERR)
 #define MY_INTERRUPTS (INT_RISCI | ERROR_INTERRUPTS)
@@ -746,6 +752,11 @@
 	bt87x_t *chip;
 	int err;
 
+	if (pci_id->driver_data & DRIVER_DEFAULT_ENTRY) {
+		if (! load_all)
+			return -ENODEV;
+	}
+
 	if (dev >= SNDRV_CARDS)
 		return -ENODEV;
 	if (!enable[dev]) {
@@ -764,7 +775,7 @@
 	if (digital_rate[dev] > 0)
 		chip->dig_rate = digital_rate[dev];
 	else
-		chip->dig_rate = (int)pci_id->driver_data;
+		chip->dig_rate = (int)(pci_id->driver_data & DRIVER_RATE_MASK);
 
 	err = snd_bt87x_pcm(chip, DEVICE_DIGITAL, "Bt87x Digital");
 	if (err < 0)
@@ -819,8 +830,8 @@
 	BT_DEVICE(878, 0x0070, 0xff01, 44100), /* Osprey 200 */
 
 	/* default entries for 32kHz and generic Bt87x cards */
-	BT_DEVICE(878, PCI_ANY_ID, PCI_ANY_ID, 32000),
-	BT_DEVICE(879, PCI_ANY_ID, PCI_ANY_ID, 32000),
+	BT_DEVICE(878, PCI_ANY_ID, PCI_ANY_ID, 32000 | DRIVER_DEFAULT_ENTRY),
+	BT_DEVICE(879, PCI_ANY_ID, PCI_ANY_ID, 32000 | DRIVER_DEFAULT_ENTRY),
 	{ }
 };
 MODULE_DEVICE_TABLE(pci, snd_bt87x_ids);

Re: Problem with Avermedia 771

[Clemens Ladisch]

Takashi Iwai wrote:
> > > So we'll have to build a whitelist from scratch from user feedback, and
> > > maybe add a insmod option so you can ask the driver to grab the device
> > > even if not whitelisted for easy use.
>
> The experimental patch for this is below.

Below is the same patch with entries for WinTV cards (the old default
entries were intended to handle those).

I don't know of any other cards with working audio function (all
feedback I got for other cards was negative).

I'm going to write some documention, too.


Clemens

-- 
Index: alsa-kernel/pci/bt87x.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/bt87x.c,v
retrieving revision 1.14
diff -u -r1.14 bt87x.c
--- alsa-kernel/pci/bt87x.c	29 Sep 2004 13:33:18 -0000	1.14
+++ alsa-kernel/pci/bt87x.c	20 Oct 2004 14:43:12 -0000
@@ -45,6 +45,7 @@
 static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;	/* ID for this card */
 static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;	/* Enable this card */
 static int digital_rate[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = 0 }; /* digital input rate */
+static int load_all;	/* allow to load the non-whitelisted cards */
 static int boot_devs;

 module_param_array(index, int, boot_devs, 0444);
@@ -55,6 +56,8 @@
 MODULE_PARM_DESC(enable, "Enable Bt87x soundcard");
 module_param_array(digital_rate, int, boot_devs, 0444);
 MODULE_PARM_DESC(digital_rate, "Digital input rate for Bt87x soundcard");
+module_param(load_all, bool, 0444);
+MODULE_PARM_DESC(load_all, "Allow to load the non-whitelisted cards");


 #ifndef PCI_VENDOR_ID_BROOKTREE
@@ -148,6 +151,9 @@
 #endif
 #define CLOCK_DIV_MAX 15

+#define DRIVER_DEFAULT_ENTRY	(1<<24)
+#define DRIVER_RATE_MASK	((1<<24)-1)
+
 #define ERROR_INTERRUPTS (INT_FBUS | INT_FTRGT | INT_PPERR | \
 			  INT_RIPERR | INT_PABORT | INT_OCERR)
 #define MY_INTERRUPTS (INT_RISCI | ERROR_INTERRUPTS)
@@ -746,6 +752,11 @@
 	bt87x_t *chip;
 	int err;

+	if (pci_id->driver_data & DRIVER_DEFAULT_ENTRY) {
+		if (! load_all)
+			return -ENODEV;
+	}
+
 	if (dev >= SNDRV_CARDS)
 		return -ENODEV;
 	if (!enable[dev]) {
@@ -764,7 +775,7 @@
 	if (digital_rate[dev] > 0)
 		chip->dig_rate = digital_rate[dev];
 	else
-		chip->dig_rate = (int)pci_id->driver_data;
+		chip->dig_rate = (int)(pci_id->driver_data & DRIVER_RATE_MASK);

 	err = snd_bt87x_pcm(chip, DEVICE_DIGITAL, "Bt87x Digital");
 	if (err < 0)
@@ -816,11 +827,13 @@

 /* driver_data is the default digital_rate value for that device */
 static struct pci_device_id snd_bt87x_ids[] = {
-	BT_DEVICE(878, 0x0070, 0xff01, 44100), /* Osprey 200 */
-
-	/* default entries for 32kHz and generic Bt87x cards */
-	BT_DEVICE(878, PCI_ANY_ID, PCI_ANY_ID, 32000),
-	BT_DEVICE(879, PCI_ANY_ID, PCI_ANY_ID, 32000),
+	BT_DEVICE(878, 0x0070, 0x13eb, 32000), /* Hauppauge WinTV series */
+	BT_DEVICE(879, 0x0070, 0x13eb, 32000), /* Hauppauge WinTV series */
+	BT_DEVICE(878, 0x0070, 0xff01, 44100), /* Viewcast Osprey 200 */
+
+	/* default entries for unknown Bt87x cards */
+	BT_DEVICE(878, PCI_ANY_ID, PCI_ANY_ID, 32000 | DRIVER_DEFAULT_ENTRY),
+	BT_DEVICE(879, PCI_ANY_ID, PCI_ANY_ID, 32000 | DRIVER_DEFAULT_ENTRY),
 	{ }
 };
 MODULE_DEVICE_TABLE(pci, snd_bt87x_ids);





-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Takashi Iwai]

At Wed, 20 Oct 2004 17:02:34 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Takashi Iwai wrote:
> > > > So we'll have to build a whitelist from scratch from user feedback, and
> > > > maybe add a insmod option so you can ask the driver to grab the device
> > > > even if not whitelisted for easy use.
> >
> > The experimental patch for this is below.
> 
> Below is the same patch with entries for WinTV cards (the old default
> entries were intended to handle those).

Thanks!

> I don't know of any other cards with working audio function (all
> feedback I got for other cards was negative).
> 
> I'm going to write some documention, too.

Great.

Should the driver put some kernel info when the device is probed but
disabled?  Something like:

	bt87x: the device XXXX:YYYY is not in the list of supported devices.
	       For using this driver for unsupported devices, too,
	       specify load_all=1 module option.

One concern is again hotplug.  This might be annoying although it's
harmless.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Clemens Ladisch]

Takashi Iwai wrote:
> > > > > So we'll have to build a whitelist from scratch from user feedback, and
> > > > > maybe add a insmod option so you can ask the driver to grab the device
> > > > > even if not whitelisted for easy use.
>
> Should the driver put some kernel info when the device is probed but
> disabled?

New patch for this below, including a doc file which has quite an
amount of "literal, line-by-line copying" :) from btaudio.txt.

> One concern is again hotplug.  This might be annoying although it's
> harmless.

Well, so we now have a blacklist for cards we ignore silently.

A centralized card list looks more advantageous now ...


I'm going to commit it to ALSA if nobody objects.


Clemens


-- 
Index: alsa-kernel/pci/Kconfig
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/Kconfig,v
retrieving revision 1.35
diff -u -r1.35 Kconfig
--- alsa-kernel/pci/Kconfig	29 Sep 2004 13:33:18 -0000	1.35
+++ alsa-kernel/pci/Kconfig	21 Oct 2004 06:50:51 -0000
@@ -106,8 +106,9 @@
         depends on SND
 	select SND_PCM
         help
-	  Say Y here to include support for recording audio from TV
-	  cards based on Brooktree Bt878/Bt879 chips.
+	  If you want to record audio from TV cards based on
+	  Brooktree Bt878/Bt879 chips, say Y here and read
+	  <file:Documentation/sound/alsa/Bt87x.txt>.

 	  To compile this driver as a module, choose M here: the module
 	  will be called snd-bt87x.
Index: alsa-kernel/pci/bt87x.c
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/pci/bt87x.c,v
retrieving revision 1.14
diff -u -r1.14 bt87x.c
--- alsa-kernel/pci/bt87x.c	29 Sep 2004 13:33:18 -0000	1.14
+++ alsa-kernel/pci/bt87x.c	21 Oct 2004 06:50:51 -0000
@@ -45,6 +45,7 @@
 static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;	/* ID for this card */
 static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;	/* Enable this card */
 static int digital_rate[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = 0 }; /* digital input rate */
+static int load_all;	/* allow to load the non-whitelisted cards */
 static int boot_devs;

 module_param_array(index, int, boot_devs, 0444);
@@ -55,6 +56,8 @@
 MODULE_PARM_DESC(enable, "Enable Bt87x soundcard");
 module_param_array(digital_rate, int, boot_devs, 0444);
 MODULE_PARM_DESC(digital_rate, "Digital input rate for Bt87x soundcard");
+module_param(load_all, bool, 0444);
+MODULE_PARM_DESC(load_all, "Allow to load the non-whitelisted cards");


 #ifndef PCI_VENDOR_ID_BROOKTREE
@@ -738,14 +741,77 @@
 	return 0;
 }

+/* cards known to have audio */
+static struct card_entry {
+	unsigned short subvendor, subdevice;
+	int digital_rate;
+	const char *name;
+} whitelist[] __devinitdata = {
+	{0x0070, 0x13eb, 32000, "WinTV series"},
+	{0x0070, 0xff01, 44100, "Osprey 200"},
+};
+
+/* cards known not to have audio
+ * (DVB cards use the audio function to transfer MPEG data) */
+static struct {
+	unsigned short subvendor, subdevice;
+} blacklist[] __devinitdata = {
+	{0x0071, 0x0101}, /* Nebula Electronics DigiTV */
+	{0x11bd, 0x0026}, /* Pinnacle PCTV SAT CI */
+	{0x1461, 0x0761}, /* AVermedia AverTV DVB-T */
+	{0x1461, 0x0771}, /* AVermedia DVB-T 771 */
+	{0x1822, 0x0001}, /* Twinhan VisionPlus DVB-T */
+	{0x270f, 0xfc00}, /* Chaintech Digitop DST-1000 DVB-S */
+};
+
+static struct card_entry *
+__devinit snd_bt87x_detect_card(struct pci_dev *pci)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(whitelist); ++i)
+		if (whitelist[i].subvendor == pci->subsystem_vendor &&
+		    whitelist[i].subdevice == pci->subsystem_device) {
+			snd_printk(KERN_INFO "detected audio for %s (%d Hz)\n",
+				   whitelist[i].name, whitelist[i].digital_rate);
+			return &whitelist[i];
+		}
+	for (i = 0; i < ARRAY_SIZE(blacklist); ++i)
+		if (blacklist[i].subvendor == pci->subsystem_vendor &&
+		    blacklist[i].subdevice == pci->subsystem_device) {
+			snd_printdd(KERN_INFO "card %#04x:%#04x has no audio\n",
+				    pci->subsystem_vendor, pci->subsystem_device);
+			return NULL;
+		}
+	if (load_all) {
+		static struct card_entry unknown_card __devinitdata = {
+			PCI_ANY_ID, PCI_ANY_ID, 32000, NULL
+		};
+		snd_printk(KERN_INFO "unknown card %#04x:%#04x\n",
+			   pci->subsystem_vendor, pci->subsystem_device);
+		snd_printk(KERN_DEBUG "please mail id, board name, and, "
+			   "if it works, the correct digital_rate option to "
+			   "<alsa-devel@lists.sf.net>\n");
+		return &unknown_card;
+	}
+	snd_printk(KERN_INFO "Unknown TV card found, the audio driver will not load.\n");
+	snd_printk(KERN_INFO "To try to capture audio from this card, use the load_all=1 option.\n");
+	return NULL;
+}
+
 static int __devinit snd_bt87x_probe(struct pci_dev *pci,
 				     const struct pci_device_id *pci_id)
 {
 	static int dev;
+	struct card_entry *card_entry;
 	snd_card_t *card;
 	bt87x_t *chip;
 	int err;

+	card_entry = snd_bt87x_detect_card(pci);
+	if (!card_entry)
+		return -ENODEV;
+
 	if (dev >= SNDRV_CARDS)
 		return -ENODEV;
 	if (!enable[dev]) {
@@ -764,7 +830,7 @@
 	if (digital_rate[dev] > 0)
 		chip->dig_rate = digital_rate[dev];
 	else
-		chip->dig_rate = (int)pci_id->driver_data;
+		chip->dig_rate = card_entry->digital_rate;

 	err = snd_bt87x_pcm(chip, DEVICE_DIGITAL, "Bt87x Digital");
 	if (err < 0)
@@ -808,19 +874,17 @@
 	pci_set_drvdata(pci, NULL);
 }

-#define BT_DEVICE(chip, subvend, subdev, rate) \
-	{ .vendor = PCI_VENDOR_ID_BROOKTREE, \
-	  .device = PCI_DEVICE_ID_BROOKTREE_##chip, \
-	  .subvendor = subvend, .subdevice = subdev, \
-	  .driver_data = rate }
-
-/* driver_data is the default digital_rate value for that device */
 static struct pci_device_id snd_bt87x_ids[] = {
-	BT_DEVICE(878, 0x0070, 0xff01, 44100), /* Osprey 200 */
-
-	/* default entries for 32kHz and generic Bt87x cards */
-	BT_DEVICE(878, PCI_ANY_ID, PCI_ANY_ID, 32000),
-	BT_DEVICE(879, PCI_ANY_ID, PCI_ANY_ID, 32000),
+	{
+		.vendor = PCI_VENDOR_ID_BROOKTREE,
+		.device = PCI_DEVICE_ID_BROOKTREE_878,
+		.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID
+	},
+	{
+		.vendor = PCI_VENDOR_ID_BROOKTREE,
+		.device = PCI_DEVICE_ID_BROOKTREE_879,
+		.subvendor = PCI_ANY_ID, .subdevice = PCI_ANY_ID
+	},
 	{ }
 };
 MODULE_DEVICE_TABLE(pci, snd_bt87x_ids);
Index: alsa-kernel/Documentation/ALSA-Configuration.txt
===================================================================
RCS file: /cvsroot/alsa/alsa-kernel/Documentation/ALSA-Configuration.txt,v
retrieving revision 1.53
diff -u -r1.53 ALSA-Configuration.txt
--- alsa-kernel/Documentation/ALSA-Configuration.txt	28 Sep 2004 16:44:02 -0000	1.53
+++ alsa-kernel/Documentation/ALSA-Configuration.txt	21 Oct 2004 06:50:52 -0000
@@ -252,6 +252,7 @@
     Module for video cards based on Bt87x chips.

     digital_rate - Override the default digital rate (Hz)
+    load_all	- Load the driver even if the card model isn't known

     Module supports up to 8 cards.

--- alsa-kernel/Documentation/Bt87x.txt.org	1970-01-01 01:00:00.000000000 +0100
+++ alsa-kernel/Documentation/Bt87x.txt	2004-10-21 08:50:16.740436000 +0200
@@ -0,0 +1,78 @@
+Intro
+=====
+
+You might have noticed that the bt878 grabber cards have actually
+_two_ PCI functions:
+
+$ lspci
+[ ... ]
+00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
+00:0a.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02)
+[ ... ]
+
+The first does video, it is backward compatible to the bt848.  The second
+does audio.  snd-bt87x is a driver for the second function.  It's a sound
+driver which can be used for recording sound (and _only_ recording, no
+playback).  As most TV cards come with a short cable which can be plugged
+into your sound card's line-in you probably don't need this driver if all
+you want to do is just watching TV...
+
+Some cards do not bother to connect anything to the audio input pins of
+the chip, and some other cards use the audio function to transport MPEG
+video data, so it's quite possible that audio recording may not work
+with your card.
+
+
+Driver Status
+=============
+
+The driver is now stable.  However, it doesn't know about many TV cards,
+and it refuses to load for cards it doesn't know.
+
+If the driver complains ("Unknown TV card found, the audio driver will
+not load"), you can specify the load_all=1 option to force the driver to
+try to use the audio capture function of your card.  If the frequency of
+recorded data is not right, try to specify the digital_rate option with
+other values than the default 32000 (often it's 44100 or 64000).
+
+If you have an unknown card, please mail the ID and board name to
+<alsa-devel@lists.sf.net>, regardless of whether audio capture works or
+not, so that future versions of this driver know about your card.
+
+
+Audio modes
+===========
+
+The chip knows two different modes (digital/analog).  snd-bt87x
+registers two PCM devices, one for each mode.  They cannot be used at
+the same time.
+
+
+Digital audio mode
+==================
+
+The first device (hw:X,0) gives you 16 bit stereo sound.  The sample
+rate depends on the external source which feeds the Bt87x with digital
+sound via I2S interface.
+
+
+Analog audio mode (A/D)
+=======================
+
+The second device (hw:X,1) gives you 8 or 16 bit mono sound.  Supported
+sample rates are between 119466 and 448000 Hz (yes, these numbers are
+that high).  If you've set the CONFIG_SND_BT87X_OVERCLOCK option, the
+maximum sample rate is 1792000 Hz, but audio data becomes unusable
+beyond 896000 Hz on my card.
+
+The chip has three analog inputs.  Consequently you'll get a mixer
+device to control these.
+
+
+Have fun,
+
+  Clemens
+
+
+Written by Clemens Ladisch <clemens@ladisch.de>
+big parts copied from btaudio.txt by Gerd Knorr <kraxel@bytesex.org>



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [Alsa-devel] Problem with Avermedia 771

[Gerd Knorr]

> A centralized card list looks more advantageous now ...

Hmm, along these lines maybe?

   Gerd

==============================[ cut here ]==============================

enum bt878_func1 {
	BT878_FUNC1_IS_UNKNOWN = 0,
	BT878_FUNC1_IS_AUDIO,
	BT878_FUNC1_IS_DVB,
	BT878_FUNC1_IS_OTHER,
};

struct bt878_entry {
	u16    subvendor;
	u16    subdevice;
	char   *name;
	enum bt878_func1 func1;      /* what PCI function 1 is used for?    */
	int    bttv_id;              /* for bttv, index into bttv_tvcards[] */
	int    audio_rate;           /* for alsa/btaudio, sample rate       */
};

const struct bt878_entry* bt878_db_lookup(struct pci_dev *pci);

Re: Problem with Avermedia 771

[Takashi Iwai]

At Thu, 21 Oct 2004 09:22:18 +0200 (METDST),
Clemens Ladisch wrote:
> 
> > One concern is again hotplug.  This might be annoying although it's
> > harmless.
> 
> Well, so we now have a blacklist for cards we ignore silently.

The new patch hides the whitelisted ids from the exported PCI id
table, i.e. hotplug can't know which driver should be loaded for the
certain known device.

I think it'd be better to put back the whitelist into the pci_id
table and handle the blacklist inidividually.


> A centralized card list looks more advantageous now ...

Well, the centralized list can't tell to the user-space which driver
should be used unless you prepare a special hotplug agent parsing the
driver_data entry.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Gerd Knorr]

> The new patch hides the whitelisted ids from the exported PCI id
> table, i.e. hotplug can't know which driver should be loaded for the
> certain known device.

If the wildcard entry is in there as well like it used to be that
doesn't really make a difference, hotplug doesn't know that the driver
will ignore the card by default because it is tagged "DEFAULT_ENTRY" via
driver-data ...

  Gerd



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Takashi Iwai]

At Thu, 21 Oct 2004 12:18:18 +0200,
Gerd Knorr wrote:
> 
> > The new patch hides the whitelisted ids from the exported PCI id
> > table, i.e. hotplug can't know which driver should be loaded for the
> > certain known device.
> 
> If the wildcard entry is in there as well like it used to be that
> doesn't really make a difference, hotplug doesn't know that the driver
> will ignore the card by default because it is tagged "DEFAULT_ENTRY" via
> driver-data ...

Yes, that was my concern.  The hotplug can load multiple modules, but
it's disabled as default.

That's the reason why I suggested the second way in my earlier post:

We prepare two pci_id tables, one for the whitelist and another for
the default ids.  Only the former is exported.

When the module option is given, the latter id is registered while
usually the fomer is used.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Gerd Knorr]

> That's the reason why I suggested the second way in my earlier post:
> 
> We prepare two pci_id tables, one for the whitelist and another for
> the default ids.  Only the former is exported.
> 
> When the module option is given, the latter id is registered while
> usually the fomer is used.

Yep, that should make the correct ID list visible to hotplug ...

  Gerd



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

At Thu, 21 Oct 2004 13:43:11 +0200,
Gerd Knorr wrote:
> 
> > That's the reason why I suggested the second way in my earlier post:
> > 
> > We prepare two pci_id tables, one for the whitelist and another for
> > the default ids.  Only the former is exported.
> > 
> > When the module option is given, the latter id is registered while
> > usually the fomer is used.
> 
> Yep, that should make the correct ID list visible to hotplug ...

Ok, how about the attached patch?

We may have a certralized header file such as linux/bt_pci_id.h
containig the entries of known working boards so that this can be
included from different drivers...


Takashi

[-- Attachment #2: Type: text/plain, Size: 4903 bytes --]

Index: alsa-kernel/pci/bt87x.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/bt87x.c,v
retrieving revision 1.14
diff -u -r1.14 bt87x.c
--- alsa-kernel/pci/bt87x.c	29 Sep 2004 16:17:59 -0000	1.14
+++ alsa-kernel/pci/bt87x.c	21 Oct 2004 12:08:03 -0000
@@ -45,6 +45,7 @@
 static char *id[SNDRV_CARDS] = SNDRV_DEFAULT_STR;	/* ID for this card */
 static int enable[SNDRV_CARDS] = SNDRV_DEFAULT_ENABLE_PNP;	/* Enable this card */
 static int digital_rate[SNDRV_CARDS] = { [0 ... (SNDRV_CARDS-1)] = 0 }; /* digital input rate */
+static int load_all;	/* allow to load the non-whitelisted cards */
 static int boot_devs;
 
 module_param_array(index, int, boot_devs, 0444);
@@ -55,6 +56,8 @@
 MODULE_PARM_DESC(enable, "Enable Bt87x soundcard");
 module_param_array(digital_rate, int, boot_devs, 0444);
 MODULE_PARM_DESC(digital_rate, "Digital input rate for Bt87x soundcard");
+module_param(load_all, bool, 0444);
+MODULE_PARM_DESC(load_all, "Allow to load the non-whitelisted cards");
 
 
 #ifndef PCI_VENDOR_ID_BROOKTREE
@@ -738,13 +741,73 @@
 	return 0;
 }
 
+#define BT_DEVICE(chip, subvend, subdev, rate) \
+	{ .vendor = PCI_VENDOR_ID_BROOKTREE, \
+	  .device = PCI_DEVICE_ID_BROOKTREE_##chip, \
+	  .subvendor = subvend, .subdevice = subdev, \
+	  .driver_data = rate }
+
+/* driver_data is the default digital_rate value for that device */
+static struct pci_device_id snd_bt87x_ids[] = {
+	BT_DEVICE(878, 0x0070, 0x13eb, 32000), /* Hauppauge WinTV series */
+	BT_DEVICE(879, 0x0070, 0x13eb, 32000), /* Hauppauge WinTV series */
+	BT_DEVICE(878, 0x0070, 0xff01, 44100), /* Viewcast Osprey 200 */
+	{ }
+};
+MODULE_DEVICE_TABLE(pci, snd_bt87x_ids);
+
+/* cards known not to have audio
+ * (DVB cards use the audio function to transfer MPEG data) */
+static struct {
+	unsigned short subvendor, subdevice;
+} blacklist[] __devinitdata = {
+	{0x0071, 0x0101}, /* Nebula Electronics DigiTV */
+	{0x11bd, 0x0026}, /* Pinnacle PCTV SAT CI */
+	{0x1461, 0x0761}, /* AVermedia AverTV DVB-T */
+	{0x1461, 0x0771}, /* AVermedia DVB-T 771 */
+	{0x1822, 0x0001}, /* Twinhan VisionPlus DVB-T */
+	{0x270f, 0xfc00}, /* Chaintech Digitop DST-1000 DVB-S */
+};
+
+/* return the rate of the card, or a negative if it's blacklisted */
+static int
+__devinit snd_bt87x_detect_card(struct pci_dev *pci)
+{
+	int i;
+	const struct pci_device_id *supported;
+
+	supported = pci_match_device(snd_bt87x_ids, pci);
+	if (supported)
+		return supported->driver_data;
+
+	for (i = 0; i < ARRAY_SIZE(blacklist); ++i)
+		if (blacklist[i].subvendor == pci->subsystem_vendor &&
+		    blacklist[i].subdevice == pci->subsystem_device) {
+			snd_printdd(KERN_INFO "card %#04x:%#04x has no audio\n",
+				    pci->subsystem_vendor, pci->subsystem_device);
+			return -EBUSY;
+		}
+
+	snd_printk(KERN_INFO "unknown card %#04x:%#04x, using default rate 32000\n",
+		   pci->subsystem_vendor, pci->subsystem_device);
+	snd_printk(KERN_DEBUG "please mail id, board name, and, "
+		   "if it works, the correct digital_rate option to "
+		   "<alsa-devel@lists.sf.net>\n");
+	return 32000; /* default rate */
+}
+
 static int __devinit snd_bt87x_probe(struct pci_dev *pci,
 				     const struct pci_device_id *pci_id)
 {
 	static int dev;
 	snd_card_t *card;
 	bt87x_t *chip;
-	int err;
+	int err, rate;
+
+	rate = pci_id->driver_data;
+	if (! rate)
+		if ((rate = snd_bt87x_detect_card(pci)) <= 0)
+			return -ENODEV;
 
 	if (dev >= SNDRV_CARDS)
 		return -ENODEV;
@@ -764,7 +827,7 @@
 	if (digital_rate[dev] > 0)
 		chip->dig_rate = digital_rate[dev];
 	else
-		chip->dig_rate = (int)pci_id->driver_data;
+		chip->dig_rate = rate;
 
 	err = snd_bt87x_pcm(chip, DEVICE_DIGITAL, "Bt87x Digital");
 	if (err < 0)
@@ -808,22 +871,13 @@
 	pci_set_drvdata(pci, NULL);
 }
 
-#define BT_DEVICE(chip, subvend, subdev, rate) \
-	{ .vendor = PCI_VENDOR_ID_BROOKTREE, \
-	  .device = PCI_DEVICE_ID_BROOKTREE_##chip, \
-	  .subvendor = subvend, .subdevice = subdev, \
-	  .driver_data = rate }
-
-/* driver_data is the default digital_rate value for that device */
-static struct pci_device_id snd_bt87x_ids[] = {
-	BT_DEVICE(878, 0x0070, 0xff01, 44100), /* Osprey 200 */
-
-	/* default entries for 32kHz and generic Bt87x cards */
-	BT_DEVICE(878, PCI_ANY_ID, PCI_ANY_ID, 32000),
-	BT_DEVICE(879, PCI_ANY_ID, PCI_ANY_ID, 32000),
+/* default entries for 32kHz and generic Bt87x cards - it's not exported */
+/* driver_data is set to 0 to call detection */
+static struct pci_device_id snd_bt87x_default_ids[] = {
+	BT_DEVICE(878, PCI_ANY_ID, PCI_ANY_ID, 0),
+	BT_DEVICE(879, PCI_ANY_ID, PCI_ANY_ID, 0),
 	{ }
 };
-MODULE_DEVICE_TABLE(pci, snd_bt87x_ids);
 
 static struct pci_driver driver = {
 	.name = "Bt87x",
@@ -834,6 +888,8 @@
 
 static int __init alsa_card_bt87x_init(void)
 {
+	if (load_all)
+		driver.id_table = snd_bt87x_default_ids;
 	return pci_module_init(&driver);
 }
 

Re: Problem with Avermedia 771

[Takashi Iwai]

At Thu, 21 Oct 2004 14:11:44 +0200,
I wrote:
> 
> At Thu, 21 Oct 2004 13:43:11 +0200,
> Gerd Knorr wrote:
> > 
> > > That's the reason why I suggested the second way in my earlier post:
> > > 
> > > We prepare two pci_id tables, one for the whitelist and another for
> > > the default ids.  Only the former is exported.
> > > 
> > > When the module option is given, the latter id is registered while
> > > usually the fomer is used.
> > 
> > Yep, that should make the correct ID list visible to hotplug ...
> 
> Ok, how about the attached patch?
> 
> We may have a certralized header file such as linux/bt_pci_id.h
> containig the entries of known working boards so that this can be
> included from different drivers...

BTW, I'll be in vacation from tomorrow for a couple of weeks.
Will be unreachable from nets for a while...


ciao,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Clemens Ladisch]

Takashi Iwai wrote:
> Gerd Knorr wrote:
> > Takashi Iwai wrote:
> > > That's the reason why I suggested the second way in my earlier post:
> > >
> > > We prepare two pci_id tables, one for the whitelist and another for
> > > the default ids.  Only the former is exported.
> > >
> > > When the module option is given, the latter id is registered while
> > > usually the fomer is used.
> >
> > Yep, that should make the correct ID list visible to hotplug ...
>
> Ok, how about the attached patch?

Committed now.


Gerd Knorr wrote:
> Clemens Ladisch wrote:
> > A centralized card list looks more advantageous now ...
>
> Hmm, along these lines maybe?
>
> [...]
> const struct bt878_entry* bt878_db_lookup(struct pci_dev *pci);

Yes, this would be fine.


Clemens



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Problem with Avermedia 771

[Gerd Knorr]

> +	if (pci_id->driver_data & DRIVER_DEFAULT_ENTRY) {
> +		if (! load_all)
> +			return -ENODEV;
> +	}

A (temporary) printk here would probably be useful so people with
working but not-yet whitelisted cards know what is going on and can (a)
report the IDs and (b) get the card going using the new insmod option.

Otherwise the patch looks fine to me.

  Gerd



-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl