| Age | Commit message (Collapse) | Author |
|---|
|
From: Mauro Carvalho Chehab <mchehab@infradead.org>
Original changelog:
Author: Joe Perches <joe@perches.com>
Date: Sun Feb 3 17:18:59 2008 +0200
drivers/media/: Spelling fixes
kernel-sync:
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|
From: Douglas Schilling Landgraf <dougsland@gmail.com>
- Static memory is always initialized with 0.
- Replaced in some cases C99 comments for /* */
Signed-off-by: Douglas Schilling Landgraf <dougsland@gmail.com>
|
|
From: Michael Krufky <mkrufky@linuxtv.org>
VIDEO_PVRUSB2 must select:
VIDEO_SAA711X, VIDEO_CX25840, VIDEO_MSP3400, and VIDEO_WM8775
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Acked-by: Mike Isely <isely@pobox.com>
|
|
From: Michael Krufky <mkrufky@linuxtv.org>
Create a device description and enable autodetection for
Hauppauge WinTV PVR-USB2 Model 75xxx
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
|
|
From: Mauro Carvalho Chehab <mchehab@infradead.org>
>> I recommend applying all except for the topmost patch:
>>
>> pvrusb2: Fix compilation for OnAir Creator config
>>
>> This is a backwards-compat patch that is not needed within the v4l-dvb
>> repository nor the upstream kernel, but *is* needed within the pvrusb2
>> svn repository.
>>
>
> Agreed. Just don't pull that. I will deal with the issue in svn later.
> -Mike
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|
From: Mike Isely <isely@pobox.com>
The OnAir creator configuration calls for a specific tuner type to be
declared. However for some old kernels that tuner type was named
differently. This change adapts to the older name, when present.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The pvrusb2 driver tries to keep all device specific attributes in a
single data structure in one source file. This change further cleans
up how that table is set up. We now try to group everything together
for each specific device, and the number of symbols exported from this
module has now been reduced to a single global.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
pvrusb2: When a per-device-type default video standard is declared,
handle it in such a way that it can be correctly and unambiguously
reported in the system log.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
pvrusb2: Eliminate use of volatile in pipeline control state
variables. These were all cases of paranoia; upon further review the
overall mechanism employed here should not require use of volatile.
This had originally been done out of paranoia, and I have since been
convinced that the paranoia is not required.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
pvrusb2: Remove use of volatile for command sequencer; these variables
are set by interrupt-context code and we check their state in such a
manner that there should be no race conditions. This had originally
been done out of paranoia, and I have since been convinced that the
paranoia is not required.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
This adds a default video standard setting to the pvr2_device_desc
structure for describing device types. With this change it is
possible to set a reasonable default standard based on device type.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Michael Krufky <mkrufky@linuxtv.org>
Firmware file name(s) for 24xxx devices
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
|
|
From: Mike Isely <isely@pobox.com>
This changeset allows the pvrusb2 driver to operate a new device type
("GOTVIEW USB2.0 DVD2"). Changes amount to defining a new routing
scheme for the device and adding appropriate table entries into
pvrusb2-devattr.c.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The pvrusb2 driver has been successfully recovering from a crashed
encoder now for over 2 years. I think it's time to reduce the
perceived severity of the warning message. While I'd still very much
like to stop these crashes, the recovery logic is solid enough that
the problem is effectively benign. No point in panicing the users
over it.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
For Hauppauge 24xxx devices, the IR receiver is a custom piece of
logic that is very specific to the device. The pvrusb2 driver can
virtualize this to make it look like a more normal IR receiver found
in other Hauppauge devices. The decision of whether or not to enable
this virtualization however is a device-specific attribute, thus this
changeset.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The exact routing of video and audio signals within a device is a
device-specific attribute. Hauppauge devices do it one way; other
types of device may route things differently. Unfortunately it is
rather impractical to define chip-specific routing at the device
attribute level, so instead what happens here is that "schemes" are
defined. Each chip level interface implements its part of a given
scheme and the scheme as a whole is made into a device specific
attribute controlled via a table entry in pvrusb2-devattr.c. The only
scheme defined here is for Hauppauge devices, but clearly this opens
the door for other possibilities to follow.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Arrange so that the pvrusb2 driver can optionally work without a
Hauppauge ROM being present - which is fairly important for devices
that happen to not come from Hauppauge. The expected existence of a
Hauppauge ROM is now a device attribute. The tuner type is now also a
device attribute, which is consulted if there is no ROM.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Correctly mark when a tuner type is set. Report more faithfully
information about known supported device video standards.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Implement additional pvrusb2 device info table entries for a device
identifier and a device description. Export this information via the
driver's internal API. Make this information available via the sysfs
driver interface. Also propagate this information into the v4l2
capability structure. An app can now retrieve and report a
descriptive string about the particular type of hardware device it is
operating.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Device-specific driver behavior is now defined by generic device
characteristics rather than by specific device model information.
With this change, the hardware type field can go away, thus this
change.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The pvrusb2 driver currently supports two variants of the Hauppauge
PVR USB2. However there are other hardware types potentially
supportable, but the driver at the moment is not structured to make it
easy to describe these minor variations. This changeset is the first
set of changes to make such additional device support possible.
Device attributes are held in several tables all contained within
pvrusb2-devattr.c; all other device-specific driver behavior now
derives from these tables.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
This is a new implementation for video pipeline control within the
pvrusb2 driver. Actual start/stop of the pipeline is moved to the
driver's kernel thread. Pipeline stages are controlled autonomously
based on surrounding pipeline or application control state. Kernel
thread management is also cleaned up and moved into the internal
control structure of the driver, solving a set up / tear down race
along the way. Better failure recovery is implemented with this new
control strategy. Also with this change comes better control of the
cx23416 encoder, building on additional information learned about the
peculiarities of controlling this part (this information was the
original trigger for this rework). With this change, overall encoder
stability should be considerably improved. Yes, this is a large
change for this driver, but due to the nature of the feature being
worked on, the changes are fairly pervasive and would be difficult to
break into smaller pieces with any semblence of step-wise stability.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The pvrusb2 driver is tearing down its sysfs related pieces in the
incorrect order. This leaves dangling pointers which causes the
kernel device core to oops. The problem has been present virtually
forever but became malignant with the changeover to the way of
handling /sys/class. Fix is just to make sure we don't tear down the
class structure until AFTER the driver instances are deregistered.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The pvrusb2 driver's sysfs implementation had long since implemented a
dummy hotplug function because at the time the kernel would oops
without at least the empty function being present. Today - after
numerous class interface changes in the kernel - this pvrusb2 change
had been dutifully carried forward but an inspection of the kernel
sources shows that it is no longer needed. So remove the dummy
function and its reference. This also solves a recurring backwards
compatibility issue in the pvrusb2 driver as the class interface has
been getting thrashed in the kernel.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Roel Kluin <12o3l@tiscali.nl>
if(!x & y) should either be if(!(x & y)) or if(!x && y)
I made changes as seemed appropriate, but please review
this is against current git.
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mauro Carvalho Chehab <mchehab@infradead.org>
Original Description:
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue Aug 14 15:15:12 2007 +0200
Driver core: change add_uevent_var to use a struct
This changes the uevent buffer functions to use a struct instead of a
long list of parameters. It does no longer require the caller to do the
proper buffer termination and size accounting, which is currently wrong
in some places. It fixes a known bug where parts of the uevent
environment are overwritten because of wrong index calculations.
Many thanks to Mathieu Desnoyers for finding bugs and improving the
error handling.
CC: Mike Isely <isely@isely.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|
From: Mauro Carvalho Chehab <mchehab@infradead.org>
Original description:
i2c: Remove NOP i2c_algorithm.algo_control() methods
This removes NOP implementations of i2c_algorithm.algo_control.
With this change, there are no implementations of this hook in
the kernel.org tree ... that hook seems about ripe to remove.
kernel-sync:
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|
From: Mike Isely <isely@pobox.com>
Earlier changes to move away from use of struct class_device
introduced breakage for kernels older than 2.6.19. This change at
least allows it to build again for 2.6.18. Still unclear about older
kernels, unfortunately :-(
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
This is a minor change to help with tracking the viability of the
encoder chip within the PVR USB2 device.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mauro Carvalho Chehab <mchehab@infradead.org>
struct video_device used to define a .hardware field. While
initialized on severl drivers, this field is never used inside V4L.
However, drivers using it need to include the old V4L1 header.
This seems to cause compilation troubles with some random configs.
Better just to remove it from all drivers.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|
From: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
Reviewed-by: Mike Isely <isely@pobox.com>
|
|
From: Trent Piepho <xyzzy@speakeasy.org>
The prototypes for the show and store methods of a device_attribute changed in
kernel 2.6.13, but the code in pvrusb2 was never updated. I guess the
DEBUGIFC stuff isn't used much....
Signed-off-by: Trent Piepho <xyzzy@speakeasy.org>
|
|
From: Kay Sievers <kay.sievers@vrfy.org>
The currently used "struct class_device" will be removed from the
kernel. Here is a patch that converts all users in drivers/media/video/
to struct device.
Reviewed-by: Thierry Merle <thierry.merle@free.fr>
Reviewed-by: Mike Isely <isely@pobox.com>
Reviewed-by: Luca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
|
|
From: Mauro Carvalho Chehab <mchehab@infradead.org>
kernel-sync:
A few changes were done at mainstream, affecting v4l/dvb drivers. Backport those
changes to the out-kernel tree.
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
|
|
From: Jean Delvare <khali@linux-fr.org>
* I2C adapters aren't expected to handle I2C_M_NOSTART unless they
really have to. As the pvrusb2 driver doesn't support it, I take it
that it doesn't need it so it shouldn't mention it at all.
* I2C_FUNC_SMBUS_EMUL includes I2C_FUNC_SMBUS_BYTE_DATA so listing
both is redundant.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
It's useful to see specific details for how the pvrusb2 driver is
figuring out things related to the video standard, independent of
other initialization activities. So let's set up a separate debug
mask bit for this and turn it on.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The v4l tveeprom logic tells us what video standards are supported by
the hardware, however it doesn't directly tell us what should be the
preferred initial standard. For example "NTSC/NTSC-J" devices are
reported by tveeprom as support NTSC-M and PAL-M, and while that might
be true, in the vast majority of cases NTSC-M is really what the user
is going to want. However the driver previously just arbitrarily
picked the "lowest numbered" standard as the initial default, which in
that case would have been PAL-M. (And making matters more confusing -
this only caused real problems on 24xxx devices because the saa7115 on
29xxx seems to autodetect the right answer anyway.) This change
implements an algorithm that uses the set of "supported" standards as
a hint to decide on the initial standard. This algorithm ONLY comes
into play if the driver isn't specifically told what to do; said
another way - the user can always still change the standard via the
sysfs interface, via the usual V4L methods, or even specified as a
module parameter. The idea here is only to pick a better starting
point if the user (or app) doesn't otherwise do something to set the
standard; otherwise this change has no real impact.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
This is a bunch of cleanup in various places to improve behavior based
on actual device type being driven. While this doesn't actually
affect operation with existing devices, it cleans things up so that it
will be easier / more deterministic when other devices are added.
Ideally we should make stuff like this table-driven, but for now this
is just a series of small incremental (read: safe) improvements.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The pvrusb2 driver already has a method for extracting the FX2's
program memory back out to a user application; this ability is used to
facilitate manual firmware extraction as per the procedure documented
on the pvrusb2 web site. This change follows that pattern and
implements a corresponding method to grab the binary contents of the
PVR USB2 prom (which for PVR USB2 devices can contain information in
addition to the usual Hauppauge metadata).
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Signed-off-by: Mike Isely <isely@pobox.com>
|
