| Age | Commit message (Collapse) | Author |
|---|
|
From: Michael Krufky <mkrufky@linuxtv.org>
Added necessary header file in order for kconfig build options to be
considered at compile time. Without this patch all options will always
be disabled, regardless of whether they are selected or not.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Acked-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Insert an I2C transaction filter for the cx25843 chip on new model
24xxx hardware. This filter attempts to stabilize the part by
limiting how the part can be accessed. The filter won't allow anyone
to touch the chip until an attempt is made to specifically read the
chip's revision registers. If that read fails (which can happen if
the chip wedges itself), a warning is logged and the driver is
rendered useless. If the read succeeds, then the filter deletes
itself and normal access to the part takes place. This filter should
keep msp3400 away from the chip (a failure scenario which otherwise
frequently ends badly for the kernel, due to suspected misbehaviors
within the msp3400 module).
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Implement a rudimentary filter mechanism in the I2C adapter within the
pvrusb2 driver. It is possible now to interpose a filtering function
on a per-target basis. This function can intercept the requested
transaction and perform various manipulations on behalf of the
client. With this mechanism is also a filter inserted for wm8775 that
causes all probe attempts to the chip to always succeed (just return
success on probe attempts without touching the hardware). This neatly
solves the problem in the PVR USB2 hardware where we can't seem able
to probe the chip at all.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
The correct mutex header to grab is linux/mutex.h, and while
asm/mutex.h seems to work for x86 architecture, it has been reported
not to work for amd64 architecture. So let's just do this right.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Clean up logic for handling video standards in the pvrusb2 driver.
New implementation should be able to handle all possible V4L defined
video standards now, and it should be far easier to maintain this
going forward.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Rework controls internal architecture. Rework video standard
handling. This is a major change.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Since there are lingering stability problems with support of the newer
PVR USB2 model 24xxx series hardware, I have isolate those changes
with a config option. This commit leaves that option off.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Rework entire internal controls interface to eliminate the need for
visibly defined control IDs which must otherwise be translated by the
V4L2 public interface. As part of this work, internal structures
which mimiced various V4L2 structures (video standards, audio modes)
have been reworked to actually use the native structures. This
triggered a _significant_ rework for how video standards are dealt
with (and what is in place now should be much more flexible and
forgiving for various handling less-common video standards).
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Eliminate the need to track the number pvrusb2 CIDs at compile time
from within the pvrusb2 driver. This is part of a control structure
cleanup.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
This change threads logic through the pvrusb2 to make it possible to
command the decoder chip to reset itself. The method is
decoder-agnostic; the part of the pvrusb2 which control's that chip's
module has to provide the final hook. This just lays the foundation.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Mike Isely <isely@pobox.com>
Notice and track actual hardware type of device. This information is
also used now to select the correct FX2 firmware file to load (because
they can be different, unfortunately).
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
From: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
|
