On platforms that have CONFIG_HZ set to 100, the power ramp time effectively
ends up being 10ms. However, on those that have a higher CONFIG_HZ, the time
ends up *actually* being 5ms, which doesn't allow enough time for the hardware
to be fully powered up before attempting to address it via i2c.
Change the constant to 10ms, which is long enough for the hardware to power
up, and won't really be anymore time than it was previously on platforms
with CONFIG_HZ being 100.
Credit goes to Mauro Carvalho Chehab and Gerd Hoffmann who previously
investigated this issue.
Tested with the Hauppauge USBLive 2, with which the problem was readily
reproducible after setting CONFIG_HZ to 1000.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
All the modified drivers didn't have any version increment since
Jan, 1 2011. Several of them didn't have any version increment
for a long time, even having new features and important bug fixes
happening.
As we're now filling the QUERYCAP version with the current Kernel
Release, we don't need to maintain a per-driver version control
anymore. So, let's just use the default.
In order to preserve the Kernel module version history, a
KERNEL_VERSION() macro were added to all modified drivers, and
the extraver number were incremented.
I opted to preserve the per-driver version control to a few
pwc, pvrusb2, s2255, s5p-fimc and sh_vou.
A few drivers are still using the legacy way to handle ioctl's.
So, we can't do such change on them, otherwise, they'll break.
Those are: uvc, et61x251 and sn9c102.
The rationale is that the per-driver version control seems to be
actively maintained on those.
Yet, I think that the better for them would be to just use the
default version numbering, instead of doing that by themselves.
While here, removed a few uneeded include linux/version.h
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for the "Hauppauge WinTV USB2-FM" Analog TV Stick.
It includes support for both the PAL and NTSC variants of the device.
Signed-off-by: Peter Moon <pomoon@gmail.com>
Reviewed-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch adds support for the "Iconbit Analog Stick U100 FM".
Only composite & s-video inputs, no tuner support now.
Signed-off-by: Igor Novgorodov <igor@novg.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patch below removes an extra "l" in the word.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Adds support for Pixelviex Xcapture USB grabber device.
This device has one composite and one s-video entry
only, plus a button.
For now, the button is not supported.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some devices don't need to use it. So allow to just disable this logic.
Having it enabled on some devices cause power management to complain,
generating error -71.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of per-model tests all over the code, use some parameters
at the board entries to describe the model variants for:
- devices with 417 MPEG encoder;
- devices that use external AV;
- devices where vbi VANC endpoint doesn't work;
- devices with xc5000 that require different IF
initialization (and probably will cover also
xc3028).
- devices with xceive tuner that require a reset
during init.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The struct that describes a rc mapping had an weird and long name.
We should properly name it, to make easier for developers to work
with it, and to avoid confusion.
Basically, generated by this script:
for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,ir_scancode_table,rc_map,g <$i >a && mv a $i; done
for i in `find drivers/staging -type f -name *.[ch]` `find include/media -type f -name *.[ch]` `find drivers/media -type f -name *.[ch]`; do sed s,rc_tab,rc_map,g <$i >a && mv a $i; done
(and manually fixed where needed)
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
rc_map is confusing, as it may be understood as another thing. Properly
rename the field to indicate its usage.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Remote Controller subsystem is meant to be used not only by Infra Red
but also for similar types of Remote Controllers. The core is not specific
to Infra Red. As such, rename:
- ir-core.h to rc-core.h
- IR_CORE to RC_CORE
- namespace inside rc-core.c/rc-core.h
To be consistent with the other changes.
No functional change on this patch.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
There was a bug at cx231xx-input, where it were registering the remote
controls twice, one via ir-kbd-i2c and another directly.
Also, the patch that added rc_register_device() broke compilation for it.
This patch fixes cx231xx-input by fixing the depends on, to point to the
new symbol, and initializing the scanmask via platform_data.
While here, also fix Kconfig symbol change for IR core dependencies.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch merges the ir_input_dev and ir_dev_props structs into a single
struct called rc_dev. The drivers and various functions in rc-core used
by the drivers are also changed to use rc_dev as the primary interface
when dealing with rc-core.
This means that the input_dev is abstracted away from the drivers which
is necessary if we ever want to support multiple input devs per rc device.
The new API is similar to what the input subsystem uses, i.e:
rc_device_alloc()
rc_device_free()
rc_device_register()
rc_device_unregister()
[mchehab@redhat.com: Fix compilation on mceusb and cx231xx, due to merge conflicts]
Signed-off-by: David Härdeman <david@hardeman.nu>
Acked-by: Jarod Wilson <jarod@redhat.com>
Tested-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Although cx231xx has a very good IR support, already supported by
mceusb driver, some designs decided to add a separate I2C
microcontroller chip in order to handle IR.
Due to that, add a glue to ir-kbd-i2c is needed, in order to support
those devices.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Polaris design uses MCE support. Instead of reinventing the wheel,
just let mceusb handle the remote controller.
Acked-by: Jarod Wilson <jarod@redhat.com>
Acked-by: Sri Devi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The patches received from the vendor contained a lot of CodingStyle
issues. Cleans the style issues reported by checkpatch.pl on
those drivers.
It is better to do such style fixes when merging a big set of
changes than latter. Of course, the better is to receive patches
already cleaned ;)
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Improves the logic, for it to be clearer and to avoid having
board-dependent config there.
Acked-by: Sri Deevi <Srinivasa.Deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Nobody is ever going to implement an i2c based IR controller on a bridge that
has an onboard universal IR receiver. This stuff was all copied from em28xx,
which has old enough versions of the chip that some didn't have onboard IR.
Remove the stubs related to i2c based IR (keeping the cx231xx-input code).
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Extend the board profile structure to allow configuration of the output mode.
Right now they are all doing VIP 1.1 format, but we have a board that needs
ITU656 format (which hasn't been checked in yet).
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add initial support for the Hauppauge USBLive 2 (2040:c200). Note that I
had to copy a bunch of the case statements used for the Conexant video grabber
reference design (which also doesn't have a tuner). This will likely need to
be refactored out into the board profile.
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Move the responsibility for setting up the horizontal and vertical scalers
entirely to the cx25840 driver. The cx231xx-avcore was actually programming
garbage into the HSCALE_CTRL and VSCALE_CTRL registers (because of differences
in how the em28xx driver worked, which the cx231xx driver was derived from).
The net effect is that the scaler now works properly (tested with both PAL
and NTSC under mplayer and tvtime).
This patch also gets rid of cx25840 errors showing up in dmesg which say
"720x480 is not a valid size" (since we now properly setup the size of the
active video area).
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add support for various Hauppauge EXETER designs.
Note by DJH: fixed a few minor 'make checkpatch' warnings before commit.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Devin Heitmueller <dheitmueller@hauppauge.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Convert drivers/media/video/cx231xx/cx231xx-input.c to not
rely on ir-functions.c.
(I do not have the hardware so I can only compile test this)
Signed-off-by: David Härdeman <david@hardeman.nu>
Cc: Srinivasa Deevi <srinivasa.deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix all device drivers to use the video_drvdata function instead of
maintaining a local list of minor to private data mappings. Call
video_set_drvdata to register the driver private pointer when not
already done.
Where applicable, the local list of mappings is completely removed when
it becomes unused.
[mchehab.redhat.com: removed tm6000 changes as tm6000 is not ready yet for submission even on staging]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, V4L uses a scancode table whose index is the scancode and
the value is the keycode. While this works, it has some drawbacks:
1) It requires that the scancode to be at the range 00-7f;
2) keycodes should be masked on 7 bits in order for it to work;
3) due to the 7 bits approach, sometimes it is not possible to replace
the default keyboard to another one with a different encoding rule;
4) it is different than what is done with dvb-usb approach;
5) it requires a typedef for it to work. This is not a recommended
Linux CodingStyle.
This patch is part of a larger series of IR changes. It basically
replaces the IR_KEYTAB_TYPE tables by a structured table:
struct ir_scancode {
u16 scancode;
u32 keycode;
};
This is very close to what dvb does. So, a further integration with DVB
code will be easy.
While we've changed the tables, for now, the IR keycode handling is still
based on the old approach.
The only notable effect is the redution of about 35% of the ir-common
module size:
text data bss dec hex filename
6721 29208 4 35933 8c5d old/ir-common.ko
5756 18040 4 23800 5cf8 new/ir-common.ko
In thesis, we could be using above u8 for scancode, reducing even more the size
of the module, but defining it as u16 is more convenient, since, on dvb, each
scancode has up to 16 bits, and we currently have a few troubles with rc5, as their
scancodes are defined with more than 8 bits.
This patch itself shouldn't be doing any functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In the TRY_FMT handler the function get_scale() is called to find what the
scaler hardware will produce for a requested size.
The problem is that get_scale(struct cx231xx *dev, ..., unsigned int *vscale,
unsigned int *hscale) saves the calculated scale values into both the
pointer arguments and into dev's hscale and vscale fields. TRY_FMT shouldn't
actually change anything in the device state.
The code to in get_scale() that writes to dev->[hv]scale can just be
deleted. In all cases when dev's fields should be modified, get_scale()
was called with get_scale(dev, ..., &dev->hscale, &dev->vscale), so dev was
getting updated anyway.
This didn't actually cause a problem because nothing ever actually made use
of the hscale and vscale fields. I changed cx231xx_resolution_set() to use
those fields rather than re-calculate them with a call to get_scale().
Updating [hv]scale in cx231xx_resolution_set() isn't necessary because
every call of cx231xx_resolution_set() was already preceded by a call to
get_scale() or setting the [hv]scale fields, so they will be always be
up-to-date w.r.t. width and height.
Removing the call to get_scale() from cx231xx_resolution_set() allowed
making get_scale() a static function, which is a good thing for something
with such a short name. There is already another function with the same
name in the em28xx driver, but that one is static.
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
For specific boards, pass initialization data to ir-kbd-i2c instead
of modifying the settings after the device is initialized. This is
more efficient and easier to read.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Let card drivers probe for IR receiver devices and instantiate them if
found. Ultimately it would be better if we could stop probing
completely, but I suspect this won't be possible for all card types.
There's certainly room for cleanups. For example, some drivers are
sharing I2C adapter IDs, so they also had to share the list of I2C
addresses being probed for an IR receiver. Now that each driver
explicitly says which addresses should be probed, maybe some addresses
can be dropped from some drivers.
Also, the special cases in saa7134-i2c should probably be handled on a
per-board basis. This would be more efficient and less risky than always
probing extra addresses on all boards. I'll give it a try later.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch converts cx231xx to the new v4l2 dev/subdev, doing:
- Conversion of i2c calls to subdev calls;
- all subdev calls to call_all();
- Corrected the header file order in cx231xx.h;
- Added tuner frequency setting.
Signed-off-by: Srinivasa Deevi <srinivasa.deevi@conexant.com>
Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
changed the pcb-config.c/h to pcb-cfg.c/h for short names.
Signed-off-by: Srinivasa Deevi <srinivasa.deevi@conexant.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Only cx231xx-video needs linux/version.h, due to KERNEL_VERSION macro,
that is used by V4L2 API.
This patch moves the KERNEL_VERSION to its proper place and starts with
0,0,1.
There are still much more to be fixed on later patches
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch cleans up CodingStyle on the following source files:
There are still much more to be fixed on later patches
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
