[patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Alexey Klimov]

Hello, all
What do you think about such patch that makes selecting of radio drivers
in menuconfig more comfortable ?

---

Patch divides/separates radio drivers in Kconfig in 3 groups - ISA, PCI
and others.

Signed-off-by: Alexey Klimov <klimov.linux@gmail.com>

--
diff -r 626c136ec221 linux/drivers/media/radio/Kconfig
--- a/linux/drivers/media/radio/Kconfig	Fri Mar 13 14:35:14 2009 -0700
+++ b/linux/drivers/media/radio/Kconfig	Thu Mar 19 15:20:12 2009 +0300
@@ -10,6 +10,13 @@
 	  Say Y here to enable selecting AM/FM radio adapters.
 
 if RADIO_ADAPTERS && VIDEO_V4L2
+
+config RADIO_ADAPTERS_ISA
+	boolean "ISA radio adapters"
+	---help---
+	  Enable this if you have ISA-based radio adapter.
+
+if RADIO_ADAPTERS_ISA
 
 config RADIO_CADET
 	tristate "ADS Cadet AM/FM Tuner"
@@ -150,50 +157,6 @@
 	  Say Y here to enable automatic probing for GemTek Radio card. The
 	  following ports will be probed: 0x20c, 0x30c, 0x24c, 0x34c, 0x248 and
 	  0x28c.
-
-config RADIO_GEMTEK_PCI
-	tristate "GemTek PCI Radio Card support"
-	depends on VIDEO_V4L2 && PCI
-	---help---
-	  Choose Y here if you have this PCI FM radio card.
-
-	  In order to control your radio card, you will need to use programs
-	  that are compatible with the Video for Linux API.  Information on
-	  this API and pointers to "v4l" programs may be found at
-	  <file:Documentation/video4linux/API.html>.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called radio-gemtek-pci.
-
-config RADIO_MAXIRADIO
-	tristate "Guillemot MAXI Radio FM 2000 radio"
-	depends on VIDEO_V4L2 && PCI
-	---help---
-	  Choose Y here if you have this radio card.  This card may also be
-	  found as Gemtek PCI FM.
-
-	  In order to control your radio card, you will need to use programs
-	  that are compatible with the Video For Linux API.  Information on
-	  this API and pointers to "v4l" programs may be found at
-	  <file:Documentation/video4linux/API.html>.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called radio-maxiradio.
-
-config RADIO_MAESTRO
-	tristate "Maestro on board radio"
-	depends on VIDEO_V4L2 && PCI
-	---help---
-	  Say Y here to directly support the on-board radio tuner on the
-	  Maestro 2 or 2E sound card.
-
-	  In order to control your radio card, you will need to use programs
-	  that are compatible with the Video For Linux API.  Information on
-	  this API and pointers to "v4l" programs may be found at
-	  <file:Documentation/video4linux/API.html>.
-
-	  To compile this driver as a module, choose M here: the
-	  module will be called radio-maestro.
 
 config RADIO_SF16FMI
 	tristate "SF16FMI Radio"
@@ -339,6 +302,68 @@
 	help
 	  Enter the I/O port of your Zoltrix radio card.
 
+endif # RADIO_ADAPTERS_ISA
+
+config RADIO_ADAPTERS_PCI
+	boolean "PCI radio adapters"
+	---help---
+	  Enable this if you have PCI-based radio adapters.
+
+if RADIO_ADAPTERS_PCI
+
+config RADIO_GEMTEK_PCI
+	tristate "GemTek PCI Radio Card support"
+	depends on VIDEO_V4L2 && PCI
+	---help---
+	  Choose Y here if you have this PCI FM radio card.
+
+	  In order to control your radio card, you will need to use programs
+	  that are compatible with the Video for Linux API.  Information on
+	  this API and pointers to "v4l" programs may be found at
+	  <file:Documentation/video4linux/API.html>.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called radio-gemtek-pci.
+
+config RADIO_MAXIRADIO
+	tristate "Guillemot MAXI Radio FM 2000 radio"
+	depends on VIDEO_V4L2 && PCI
+	---help---
+	  Choose Y here if you have this radio card.  This card may also be
+	  found as Gemtek PCI FM.
+
+	  In order to control your radio card, you will need to use programs
+	  that are compatible with the Video For Linux API.  Information on
+	  this API and pointers to "v4l" programs may be found at
+	  <file:Documentation/video4linux/API.html>.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called radio-maxiradio.
+
+config RADIO_MAESTRO
+	tristate "Maestro on board radio"
+	depends on VIDEO_V4L2 && PCI
+	---help---
+	  Say Y here to directly support the on-board radio tuner on the
+	  Maestro 2 or 2E sound card.
+
+	  In order to control your radio card, you will need to use programs
+	  that are compatible with the Video For Linux API.  Information on
+	  this API and pointers to "v4l" programs may be found at
+	  <file:Documentation/video4linux/API.html>.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called radio-maestro.
+
+endif # RADIO_ADAPTERS_PCI
+
+config RADIO_ADAPTERS_OTHERS
+	boolean "USB, I2C and others radio adapter interfaces"
+	---help---
+	  Enable this if you have USB, I2C or others radio interfaces.
+
+if RADIO_ADAPTERS_OTHERS
+
 config USB_DSBR
 	tristate "D-Link/GemTek USB FM radio support"
 	depends on USB && VIDEO_V4L2
@@ -406,4 +431,6 @@
 	  Say Y here if TEA5764 have a 32768 Hz crystal in circuit, say N
 	  here if TEA5764 reference frequency is connected in FREQIN.
 
+endif # RADIO_ADAPTERS_OTHERS
+
 endif # RADIO_ADAPTERS



-- 
Best regards, Klimov Alexey

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Mauro Carvalho Chehab]

On Thu, 19 Mar 2009 16:03:20 +0300
Alexey Klimov <klimov.linux@gmail.com> wrote:

> Hello, all
> What do you think about such patch that makes selecting of radio drivers
> in menuconfig more comfortable ?

Frankly, I don't see any gain: If the user doesn't have ISA (or doesn't want to
have), it should have already unselected the ISA sub-menu. The remaining PCI
and USB drivers are few. So, creating menus for them seem overkill.

We could eventually reorganize the item order, and adding a few comments to
indicate the drivers that are ISA, PCI, PCIe and USB (something similar to what
was done at DVB frontend part of the menu), but still, I can't see much value.

Cheers,
Mauro

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Alexey Klimov]

On Thu, Mar 19, 2009 at 5:03 PM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> On Thu, 19 Mar 2009 16:03:20 +0300
> Alexey Klimov <klimov.linux@gmail.com> wrote:
>
>> Hello, all
>> What do you think about such patch that makes selecting of radio drivers
>> in menuconfig more comfortable ?
>
> Frankly, I don't see any gain: If the user doesn't have ISA (or doesn't want to
> have), it should have already unselected the ISA sub-menu. The remaining PCI
> and USB drivers are few. So, creating menus for them seem overkill.
>
> We could eventually reorganize the item order, and adding a few comments to
> indicate the drivers that are ISA, PCI, PCIe and USB (something similar to what
> was done at DVB frontend part of the menu), but still, I can't see much value.

Okay, well, sorry for bothering.
Only one point here - if user want to unselect radio drivers in
menuconfig, for example - pci and isa in some bad config file he
should pick a lot of times, and with this patch only 2 times.
But, okay.

-- 
Best regards, Klimov Alexey

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Mauro Carvalho Chehab]

On Thu, 19 Mar 2009 17:18:47 +0300
Alexey Klimov <klimov.linux@gmail.com> wrote:

> On Thu, Mar 19, 2009 at 5:03 PM, Mauro Carvalho Chehab
> <mchehab@infradead.org> wrote:
> > On Thu, 19 Mar 2009 16:03:20 +0300
> > Alexey Klimov <klimov.linux@gmail.com> wrote:
> >
> >> Hello, all
> >> What do you think about such patch that makes selecting of radio drivers
> >> in menuconfig more comfortable ?
> >
> > Frankly, I don't see any gain: If the user doesn't have ISA (or doesn't want to
> > have), it should have already unselected the ISA sub-menu. The remaining PCI
> > and USB drivers are few. So, creating menus for them seem overkill.
> >
> > We could eventually reorganize the item order, and adding a few comments to
> > indicate the drivers that are ISA, PCI, PCIe and USB (something similar to what
> > was done at DVB frontend part of the menu), but still, I can't see much value.
> 
> Okay, well, sorry for bothering.
> Only one point here - if user want to unselect radio drivers in
> menuconfig, for example - pci and isa in some bad config file he
> should pick a lot of times, and with this patch only 2 times.
> But, okay.
> 

Once, someone suggested me to create some sort of "default" option for media
drivers, in a way that people can just click on a few places, if he wants
to do things like "select all that compiles and their dependencies" or "don't
select nothing" except for those.

Those kind of things could be interesting, but they may create even more mess
over what we currently have on our complex Kbuilding system.

For the out-of-system building, one alternative would be to create some make
syntax for building just some drivers, like:

	make driver=cx88,ivtv

or, even better:

	make cx88 ivtv

Such command could generate a .config file that has just the driver plus their
dependencies and selects.

Cheers,
Mauro

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Trent Piepho]

On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote:
> On Thu, 19 Mar 2009 17:18:47 +0300
> Alexey Klimov <klimov.linux@gmail.com> wrote:
> over what we currently have on our complex Kbuilding system.
>
> For the out-of-system building, one alternative would be to create some make
> syntax for building just some drivers, like:
>
> 	make driver=cx88,ivtv

The problem with this is that it's really hard to do decently.

For instance, if you want cx88 dvb support, you need some front-ends to do
anything with it.  Well, what front-ends should be turned on?  You can turn
on any number from none to all.  Probably all of them would be best.  But
there are tons of other tuners, front-ends, decoders, drivers, etc. that
cx88 doesn't use.  Those should be off.

So you give an algorithm the config variables you want set (e.g.,
VIDEO_CX88) and then tell it to find a valid solution to the rest of the
variables given the constraints from Kconfig.  This is the classic
NP-complete SAT problem.  It is hard, but we can solve this.

But we get a solution that has all the tuners, etc. that cx88 can't used
turned on.  That's not what we want!  So, we say we want the solution that
has the fewest modules turned on.  Well, you've just made the problem much
much harder to solve as SAT solving heuristics won't do you any good now.

But suppose we solve it anyway and get the solution with the fewest modules
turned on.  It's going to have all the frontends cx88 can use turned OFF.
That's not what we want either!  How is the algorithm supposed to know what
we want on and what we want off?  We basically have to do it so that 'make
cx88' means use certain exact config options that someone has manually
pre-configured.

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Mauro Carvalho Chehab]

On Thu, 19 Mar 2009 15:43:42 -0700 (PDT)
Trent Piepho <xyzzy@speakeasy.org> wrote:

> On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote:
> > On Thu, 19 Mar 2009 17:18:47 +0300
> > Alexey Klimov <klimov.linux@gmail.com> wrote:
> > over what we currently have on our complex Kbuilding system.
> >
> > For the out-of-system building, one alternative would be to create some make
> > syntax for building just some drivers, like:
> >
> > 	make driver=cx88,ivtv
> 
> The problem with this is that it's really hard to do decently.

True.

> For instance, if you want cx88 dvb support, you need some front-ends to do
> anything with it.  Well, what front-ends should be turned on?  You can turn
> on any number from none to all.  Probably all of them would be best.  But
> there are tons of other tuners, front-ends, decoders, drivers, etc. that
> cx88 doesn't use.  Those should be off.
>
> So you give an algorithm the config variables you want set (e.g.,
> VIDEO_CX88) and then tell it to find a valid solution to the rest of the
> variables given the constraints from Kconfig.  This is the classic
> NP-complete SAT problem.  It is hard, but we can solve this.
> 
> But we get a solution that has all the tuners, etc. that cx88 can't used
> turned on.  That's not what we want!  So, we say we want the solution that
> has the fewest modules turned on.  Well, you've just made the problem much
> much harder to solve as SAT solving heuristics won't do you any good now.
> 
> But suppose we solve it anyway and get the solution with the fewest modules
> turned on.  It's going to have all the frontends cx88 can use turned OFF.
> That's not what we want either!  How is the algorithm supposed to know what
> we want on and what we want off?  We basically have to do it so that 'make
> cx88' means use certain exact config options that someone has manually
> pre-configured.

It is hard to have a tool that will truly compile just the minimum amount of
things that the user needs.

Yet, it seems valid to have a make to select some specific subsets. For
example, we may select the the "common" configs, like:
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_VIDEO_ALLOW_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_DVB_CORE=y
CONFIG_VIDEO_MEDIA=y
CONFIG_DVB_DYNAMIC_MINORS=y
(we need to add here also the menu-only group of configs)

And allowing the automation of the helper chips:
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
# CONFIG_DVB_FE_CUSTOMISE is not set

Then, the make will add just the modules for that specific driver. In the case
of cx88, an interesting subset would be to select CX88*:

CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_MPEG=m
CONFIG_VIDEO_CX88_VP3054=m

For sure this is _not_ the minimal set of cx88. People may not want
blackbird, or their device may not need xc5000, for example.

Yet, it is faster to compile the above 42 kernel modules than all the 200+
modules of a full build.

The advantages are bigger if we think on those smaller drivers, like for example opera1:
CONFIG_DVB_USB_OPERA1=m

Such config will compile only 15 drivers:
  LD [M]  /home/v4l/master/v4l/dvb-usb-opera.ko
  LD [M]  /home/v4l/master/v4l/dvb-usb.ko
  LD [M]  /home/v4l/master/v4l/tea5767.ko
  LD [M]  /home/v4l/master/v4l/stv0299.ko
  LD [M]  /home/v4l/master/v4l/dvb-pll.ko
  LD [M]  /home/v4l/master/v4l/mt20xx.ko
  LD [M]  /home/v4l/master/v4l/mc44s803.ko
  LD [M]  /home/v4l/master/v4l/xc5000.ko
  LD [M]  /home/v4l/master/v4l/tuner-simple.ko
  LD [M]  /home/v4l/master/v4l/tuner-types.ko
  LD [M]  /home/v4l/master/v4l/tda8290.ko
  LD [M]  /home/v4l/master/v4l/v4l2-common.ko
  LD [M]  /home/v4l/master/v4l/tea5761.ko
  LD [M]  /home/v4l/master/v4l/tuner-xc2028.ko
  LD [M]  /home/v4l/master/v4l/tda9887.ko

Cheers,
Mauro

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Alain Kalker]

Op donderdag 19-03-2009 om 15:43 uur [tijdzone -0700], schreef Trent
Piepho:
> On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote:
> > On Thu, 19 Mar 2009 17:18:47 +0300
> > Alexey Klimov <klimov.linux@gmail.com> wrote:
> > over what we currently have on our complex Kbuilding system.
> >
> > For the out-of-system building, one alternative would be to create some make
> > syntax for building just some drivers, like:
> >
> > 	make driver=cx88,ivtv
> 
> The problem with this is that it's really hard to do decently.

It depends on how you define 'decently'. We're not trying to find a
general solution to the Boolean Satisfiability Problem here, we can use
information about the structure of the dependencies to simplify.
As I see it, drivers depend on subsystems, which in turn depend on core
functionality. These are mandatory dependencies: an USB device won't
function without USB support.
Then there are recommended and optional dependencies, which enhance the
functionality of a driver. As I have seen with the dummy frontend
module, a driver doesn't need to _have_ a frontend module to be
functional (e.g. if there simply isn't one written yet), it just will be
(much) less useful.

Pruning (deselecting) all principal modules (i.e. those that actually
provide modaliases) for devices that we don't want, and then pruning all
of their dependencies that have now become redundant (i.e. modules that
have nothing or only unselected modules depending on them) seems decent
enough to me.

> For instance, if you want cx88 dvb support, you need some front-ends to do
> anything with it.  Well, what front-ends should be turned on?  You can turn
> on any number from none to all.  Probably all of them would be best.  But
> there are tons of other tuners, front-ends, decoders, drivers, etc. that
> cx88 doesn't use.  Those should be off.

This is already covered by DVB_FE_CUSTOMIZE. A user who just wants a
driver for his device and doesn't know (or care) what frontend it uses,
can just supply a target config of:

CONFIG_DVB_FE_CUSTOMISE=n
CONFIG_<driver>=m

and build the driver, which should simply build all available frontend
modules. This already happens with allmodconfig, and as far as I know,
the current drivers don't care if one or many frontent modules are
available, the right one to use will be selected during hardware
probe/attach depending on the actual hardware anyway.

A user who wants to further customise the frontend(s) used with the
driver, should supply this information:

DVB_FE_CUSTOMISE=y
CONFIG_<driver>=m
CONFIG_<frontend>=M
...

This looks very much like the 'virtual packages' and 'alternatives'
support in package managers.

> So you give an algorithm the config variables you want set (e.g.,
> VIDEO_CX88) and then tell it to find a valid solution to the rest of the
> variables given the constraints from Kconfig.  This is the classic
> NP-complete SAT problem.  It is hard, but we can solve this.

By redefining dependencies and restructuring the dependency graph so
requirements can be propagated better, you can greatly reduce this
problem, to the point that simple search, backtracking or heuristics
become quite feasible. Again, package managers are a good example.
Entire Linux installers, live cds and preconfigured embedded systems are
being generated with very little user intervention on a daily basis.

Kind regards,

Alain

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Alain Kalker]

Op zaterdag 21-03-2009 om 22:11 uur [tijdzone +0100], schreef Alain
Kalker:
> Op donderdag 19-03-2009 om 15:43 uur [tijdzone -0700], schreef Trent
> Piepho:
> > On Thu, 19 Mar 2009, Mauro Carvalho Chehab wrote:
> > > On Thu, 19 Mar 2009 17:18:47 +0300
> > > Alexey Klimov <klimov.linux@gmail.com> wrote:
> > > over what we currently have on our complex Kbuilding system.
> > >
> > > For the out-of-system building, one alternative would be to create some make
> > > syntax for building just some drivers, like:
> > >
> > > 	make driver=cx88,ivtv
> > 
> > The problem with this is that it's really hard to do decently.
> 
> It depends on how you define 'decently'. We're not trying to find a
> general solution to the Boolean Satisfiability Problem here, we can use
> information about the structure of the dependencies to simplify.
> As I see it, drivers depend on subsystems, which in turn depend on core
> functionality. These are mandatory dependencies: an USB device won't
> function without USB support.
> Then there are recommended and optional dependencies, which enhance the
> functionality of a driver. As I have seen with the dummy frontend
> module, a driver doesn't need to _have_ a frontend module to be
> functional (e.g. if there simply isn't one written yet), it just will be
> (much) less useful.

Also, I believe there are very few (if any) circular, multiple or
conflicting dependencies in the tree.
All this structural information can be used to ease tackling this
problem.

> Pruning (deselecting) all principal modules (i.e. those that actually
> provide modaliases) for devices that we don't want, and then pruning all
> of their dependencies that have now become redundant (i.e. modules that
> have nothing or only unselected modules depending on them) seems decent
> enough to me.

> Kind regards,
> 
> Alain

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Alain Kalker]

Op zaterdag 21-03-2009 om 22:16 uur [tijdzone +0100], schreef Alain
Kalker:

Starting out from 'allmodconfig',
> > Pruning (deselecting) all principal modules (i.e. those that actually
> > provide modaliases) for devices that we don't want, and then pruning all
> > of their dependencies that have now become redundant (i.e. modules that
> > have nothing or only unselected modules depending on them) seems decent
> > enough to me.

Sorry for the multiple refinement replies :-)

> > Kind regards,
> > 
> > Alain

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Alexey Klimov]

On Thu, 2009-03-19 at 14:37 +0100, Hans Verkuil wrote:
> > Hello, all
> > What do you think about such patch that makes selecting of radio drivers
> > in menuconfig more comfortable ?
> 
> I think splitting off the ISA drivers is certainly useful. I'm not sure
> whether you need to split the remainder into PCI and Others. I think
> that's overkill.
> 
> Regards,
> 
>         Hans

Yeah, i can inclose isa drivers by this construction:

config RADIO_ADAPTERS_ISA
       boolean "ISA radio adapters"
       ---help---
         Enable this if you have ISA-based radio adapter.

if RADIO_ADAPTERS_ISA

..isa driver..

endif # RADIO_ADAPTERS_ISA

and don't touch other drivers. That looks fine for me.

> > ---
> >
> > Patch divides/separates radio drivers in Kconfig in 3 groups - ISA, PCI
> > and others.
> >
> > Signed-off-by: Alexey Klimov <klimov.linux@gmail.com>
> >
> > --
> > diff -r 626c136ec221 linux/drivers/media/radio/Kconfig
> > --- a/linux/drivers/media/radio/Kconfig	Fri Mar 13 14:35:14 2009 -0700
> > +++ b/linux/drivers/media/radio/Kconfig	Thu Mar 19 15:20:12 2009 +0300
> > @@ -10,6 +10,13 @@
> >  	  Say Y here to enable selecting AM/FM radio adapters.
> >
> >  if RADIO_ADAPTERS && VIDEO_V4L2
> > +
> > +config RADIO_ADAPTERS_ISA
> > +	boolean "ISA radio adapters"
> > +	---help---
> > +	  Enable this if you have ISA-based radio adapter.
> > +
> > +if RADIO_ADAPTERS_ISA
> >
> >  config RADIO_CADET
> >  	tristate "ADS Cadet AM/FM Tuner"
> > @@ -150,50 +157,6 @@
> >  	  Say Y here to enable automatic probing for GemTek Radio card. The
> >  	  following ports will be probed: 0x20c, 0x30c, 0x24c, 0x34c, 0x248 and
> >  	  0x28c.
> > -
> > -config RADIO_GEMTEK_PCI
> > -	tristate "GemTek PCI Radio Card support"
> > -	depends on VIDEO_V4L2 && PCI
> > -	---help---
> > -	  Choose Y here if you have this PCI FM radio card.
> > -
> > -	  In order to control your radio card, you will need to use programs
> > -	  that are compatible with the Video for Linux API.  Information on
> > -	  this API and pointers to "v4l" programs may be found at
> > -	  <file:Documentation/video4linux/API.html>.
> > -
> > -	  To compile this driver as a module, choose M here: the
> > -	  module will be called radio-gemtek-pci.
> > -
> > -config RADIO_MAXIRADIO
> > -	tristate "Guillemot MAXI Radio FM 2000 radio"
> > -	depends on VIDEO_V4L2 && PCI
> > -	---help---
> > -	  Choose Y here if you have this radio card.  This card may also be
> > -	  found as Gemtek PCI FM.
> > -
> > -	  In order to control your radio card, you will need to use programs
> > -	  that are compatible with the Video For Linux API.  Information on
> > -	  this API and pointers to "v4l" programs may be found at
> > -	  <file:Documentation/video4linux/API.html>.
> > -
> > -	  To compile this driver as a module, choose M here: the
> > -	  module will be called radio-maxiradio.
> > -
> > -config RADIO_MAESTRO
> > -	tristate "Maestro on board radio"
> > -	depends on VIDEO_V4L2 && PCI
> > -	---help---
> > -	  Say Y here to directly support the on-board radio tuner on the
> > -	  Maestro 2 or 2E sound card.
> > -
> > -	  In order to control your radio card, you will need to use programs
> > -	  that are compatible with the Video For Linux API.  Information on
> > -	  this API and pointers to "v4l" programs may be found at
> > -	  <file:Documentation/video4linux/API.html>.
> > -
> > -	  To compile this driver as a module, choose M here: the
> > -	  module will be called radio-maestro.
> >
> >  config RADIO_SF16FMI
> >  	tristate "SF16FMI Radio"
> > @@ -339,6 +302,68 @@
> >  	help
> >  	  Enter the I/O port of your Zoltrix radio card.
> >
> > +endif # RADIO_ADAPTERS_ISA
> > +
> > +config RADIO_ADAPTERS_PCI
> > +	boolean "PCI radio adapters"
> > +	---help---
> > +	  Enable this if you have PCI-based radio adapters.
> > +
> > +if RADIO_ADAPTERS_PCI
> > +
> > +config RADIO_GEMTEK_PCI
> > +	tristate "GemTek PCI Radio Card support"
> > +	depends on VIDEO_V4L2 && PCI
> > +	---help---
> > +	  Choose Y here if you have this PCI FM radio card.
> > +
> > +	  In order to control your radio card, you will need to use programs
> > +	  that are compatible with the Video for Linux API.  Information on
> > +	  this API and pointers to "v4l" programs may be found at
> > +	  <file:Documentation/video4linux/API.html>.
> > +
> > +	  To compile this driver as a module, choose M here: the
> > +	  module will be called radio-gemtek-pci.
> > +
> > +config RADIO_MAXIRADIO
> > +	tristate "Guillemot MAXI Radio FM 2000 radio"
> > +	depends on VIDEO_V4L2 && PCI
> > +	---help---
> > +	  Choose Y here if you have this radio card.  This card may also be
> > +	  found as Gemtek PCI FM.
> > +
> > +	  In order to control your radio card, you will need to use programs
> > +	  that are compatible with the Video For Linux API.  Information on
> > +	  this API and pointers to "v4l" programs may be found at
> > +	  <file:Documentation/video4linux/API.html>.
> > +
> > +	  To compile this driver as a module, choose M here: the
> > +	  module will be called radio-maxiradio.
> > +
> > +config RADIO_MAESTRO
> > +	tristate "Maestro on board radio"
> > +	depends on VIDEO_V4L2 && PCI
> > +	---help---
> > +	  Say Y here to directly support the on-board radio tuner on the
> > +	  Maestro 2 or 2E sound card.
> > +
> > +	  In order to control your radio card, you will need to use programs
> > +	  that are compatible with the Video For Linux API.  Information on
> > +	  this API and pointers to "v4l" programs may be found at
> > +	  <file:Documentation/video4linux/API.html>.
> > +
> > +	  To compile this driver as a module, choose M here: the
> > +	  module will be called radio-maestro.
> > +
> > +endif # RADIO_ADAPTERS_PCI
> > +
> > +config RADIO_ADAPTERS_OTHERS
> > +	boolean "USB, I2C and others radio adapter interfaces"
> > +	---help---
> > +	  Enable this if you have USB, I2C or others radio interfaces.
> > +
> > +if RADIO_ADAPTERS_OTHERS
> > +
> >  config USB_DSBR
> >  	tristate "D-Link/GemTek USB FM radio support"
> >  	depends on USB && VIDEO_V4L2
> > @@ -406,4 +431,6 @@
> >  	  Say Y here if TEA5764 have a 32768 Hz crystal in circuit, say N
> >  	  here if TEA5764 reference frequency is connected in FREQIN.
> >
> > +endif # RADIO_ADAPTERS_OTHERS
> > +
> >  endif # RADIO_ADAPTERS
> >
> >
> >
> > --
> > Best regards, Klimov Alexey
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-media" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
-- 
Best regards, Klimov Alexey

Re: [patch review] radio/Kconfig: introduce 3 groups: isa, pci, and others drivers

[Hans Verkuil]

> Hello, all
> What do you think about such patch that makes selecting of radio drivers
> in menuconfig more comfortable ?

I think splitting off the ISA drivers is certainly useful. I'm not sure
whether you need to split the remainder into PCI and Others. I think
that's overkill.

Regards,

        Hans

>
> ---
>
> Patch divides/separates radio drivers in Kconfig in 3 groups - ISA, PCI
> and others.
>
> Signed-off-by: Alexey Klimov <klimov.linux@gmail.com>
>
> --
> diff -r 626c136ec221 linux/drivers/media/radio/Kconfig
> --- a/linux/drivers/media/radio/Kconfig	Fri Mar 13 14:35:14 2009 -0700
> +++ b/linux/drivers/media/radio/Kconfig	Thu Mar 19 15:20:12 2009 +0300
> @@ -10,6 +10,13 @@
>  	  Say Y here to enable selecting AM/FM radio adapters.
>
>  if RADIO_ADAPTERS && VIDEO_V4L2
> +
> +config RADIO_ADAPTERS_ISA
> +	boolean "ISA radio adapters"
> +	---help---
> +	  Enable this if you have ISA-based radio adapter.
> +
> +if RADIO_ADAPTERS_ISA
>
>  config RADIO_CADET
>  	tristate "ADS Cadet AM/FM Tuner"
> @@ -150,50 +157,6 @@
>  	  Say Y here to enable automatic probing for GemTek Radio card. The
>  	  following ports will be probed: 0x20c, 0x30c, 0x24c, 0x34c, 0x248 and
>  	  0x28c.
> -
> -config RADIO_GEMTEK_PCI
> -	tristate "GemTek PCI Radio Card support"
> -	depends on VIDEO_V4L2 && PCI
> -	---help---
> -	  Choose Y here if you have this PCI FM radio card.
> -
> -	  In order to control your radio card, you will need to use programs
> -	  that are compatible with the Video for Linux API.  Information on
> -	  this API and pointers to "v4l" programs may be found at
> -	  <file:Documentation/video4linux/API.html>.
> -
> -	  To compile this driver as a module, choose M here: the
> -	  module will be called radio-gemtek-pci.
> -
> -config RADIO_MAXIRADIO
> -	tristate "Guillemot MAXI Radio FM 2000 radio"
> -	depends on VIDEO_V4L2 && PCI
> -	---help---
> -	  Choose Y here if you have this radio card.  This card may also be
> -	  found as Gemtek PCI FM.
> -
> -	  In order to control your radio card, you will need to use programs
> -	  that are compatible with the Video For Linux API.  Information on
> -	  this API and pointers to "v4l" programs may be found at
> -	  <file:Documentation/video4linux/API.html>.
> -
> -	  To compile this driver as a module, choose M here: the
> -	  module will be called radio-maxiradio.
> -
> -config RADIO_MAESTRO
> -	tristate "Maestro on board radio"
> -	depends on VIDEO_V4L2 && PCI
> -	---help---
> -	  Say Y here to directly support the on-board radio tuner on the
> -	  Maestro 2 or 2E sound card.
> -
> -	  In order to control your radio card, you will need to use programs
> -	  that are compatible with the Video For Linux API.  Information on
> -	  this API and pointers to "v4l" programs may be found at
> -	  <file:Documentation/video4linux/API.html>.
> -
> -	  To compile this driver as a module, choose M here: the
> -	  module will be called radio-maestro.
>
>  config RADIO_SF16FMI
>  	tristate "SF16FMI Radio"
> @@ -339,6 +302,68 @@
>  	help
>  	  Enter the I/O port of your Zoltrix radio card.
>
> +endif # RADIO_ADAPTERS_ISA
> +
> +config RADIO_ADAPTERS_PCI
> +	boolean "PCI radio adapters"
> +	---help---
> +	  Enable this if you have PCI-based radio adapters.
> +
> +if RADIO_ADAPTERS_PCI
> +
> +config RADIO_GEMTEK_PCI
> +	tristate "GemTek PCI Radio Card support"
> +	depends on VIDEO_V4L2 && PCI
> +	---help---
> +	  Choose Y here if you have this PCI FM radio card.
> +
> +	  In order to control your radio card, you will need to use programs
> +	  that are compatible with the Video for Linux API.  Information on
> +	  this API and pointers to "v4l" programs may be found at
> +	  <file:Documentation/video4linux/API.html>.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called radio-gemtek-pci.
> +
> +config RADIO_MAXIRADIO
> +	tristate "Guillemot MAXI Radio FM 2000 radio"
> +	depends on VIDEO_V4L2 && PCI
> +	---help---
> +	  Choose Y here if you have this radio card.  This card may also be
> +	  found as Gemtek PCI FM.
> +
> +	  In order to control your radio card, you will need to use programs
> +	  that are compatible with the Video For Linux API.  Information on
> +	  this API and pointers to "v4l" programs may be found at
> +	  <file:Documentation/video4linux/API.html>.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called radio-maxiradio.
> +
> +config RADIO_MAESTRO
> +	tristate "Maestro on board radio"
> +	depends on VIDEO_V4L2 && PCI
> +	---help---
> +	  Say Y here to directly support the on-board radio tuner on the
> +	  Maestro 2 or 2E sound card.
> +
> +	  In order to control your radio card, you will need to use programs
> +	  that are compatible with the Video For Linux API.  Information on
> +	  this API and pointers to "v4l" programs may be found at
> +	  <file:Documentation/video4linux/API.html>.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called radio-maestro.
> +
> +endif # RADIO_ADAPTERS_PCI
> +
> +config RADIO_ADAPTERS_OTHERS
> +	boolean "USB, I2C and others radio adapter interfaces"
> +	---help---
> +	  Enable this if you have USB, I2C or others radio interfaces.
> +
> +if RADIO_ADAPTERS_OTHERS
> +
>  config USB_DSBR
>  	tristate "D-Link/GemTek USB FM radio support"
>  	depends on USB && VIDEO_V4L2
> @@ -406,4 +431,6 @@
>  	  Say Y here if TEA5764 have a 32768 Hz crystal in circuit, say N
>  	  here if TEA5764 reference frequency is connected in FREQIN.
>
> +endif # RADIO_ADAPTERS_OTHERS
> +
>  endif # RADIO_ADAPTERS
>
>
>
> --
> Best regards, Klimov Alexey
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG