Details now match with radio-gemtek.c, eg. no more different ports.
Included a short note about cards that should be compatible with
radio-gemtek module.
Signed-off-by: Pekka Seppanen <pexu@kapsi.fi>
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
Reviewed-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Added GemTek USB radio and removed experimental dependency.
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
If one has a dependency chain (tristate)FOO depends on (bool)BAR depends on
(tristate)BAZ, build problems will result. If BAZ=m, then BAR can be set
y, which allows FOO=y. It's possible to have FOO=y && BAZ=m, which
wouldn't be allowed if FOO depended directly on BAZ. In effect, the bool
promotes the tristate from m to y.
This ends up causing a problem with several menuconfigs that look like:
menuconfig BAR
bool
depends on BAZ [tristate]
if BAR
config FOO
tristate
endif
The solution used here is to add the dependencies of BAR to the if
statement, so that items in the if block will gain a direct
non-bool-promoted dependency on BAZ. This is how it would work if a menu
was used instead of an if block.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: Jeff Garzik <jeff@garzik.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
All the radio drivers need video_dev, but they were depending on
VIDEO_DEV!=n. That meant that one could try to compile the driver into
the kernel when VIDEO_DEV=m, which will not work. If video_dev is a
module, then the radio drivers must be modules too.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
The scheduled removal of the OSS drivers depending on OSS_OBSOLETE_DRIVER.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Now that devfs is removed, there's no longer any need to document how to
do this or that with devfs.
This patch includes some improvements by Joe Perches.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
This is a card with RDS capabilities.
RDS specifications didn't change from V4L1 to V4L2, so that part should be OK.
This patch changed the following stuff:
* The device can be opened multiple times. That's necessary because there are
at least a radio application and an RDS application (rdsd) that want to
open() the device.
* Added a poll() function. Every character device should have that, and rdsd
expects it as it uses select() on that file descriptor.
* Converted the ioctls to V4L2. MUTE is not implemented correctly as the
card doesn't seem to have a special bit for that. Probably there are a few
more ioctls that should at least return 0 or an error.
As I do not own such a card, I couldn't test anything. If there is anybody out
there who owns such an ancient card, please test and report.
I just checked that the code compiles.
Signed-off-by: Hans J. Koch <koch@hjk-az.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Driver conversion to V4L2 API.
Require some testing, since this obsolete hardware is not
common those days.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
V4L1 API is depreciated and should be removed soon from kernel. This patch
adds two new options, one to disable V4L1 drivers, and another to disable
V4L1 compat module. This way, it would be easy to check what still depends
on V4L1 stuff, allowing also to test if app works fine with V4L2 only support.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
