The register 0xfe controls the i2c-bus from the mb86a20s to tuner.
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
---
drivers/media/dvb/frontends/mb86a20s.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
This code allows free programming of some registers of the mb86a20s
demodulator. All registers that need changes received an identification
(REG_IDCFG).
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
---
drivers/media/dvb/frontends/mb86a20s.c | 203
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
---
drivers/media/rc/keymaps/Makefile |1 +
drivers/media/rc/keymaps/rc-tbs-dtb08.c | 77 +++
include/media/rc-map.h |1 +
3 files changed, 79 insertions(+), 0 deletions(-)
create
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
---
drivers/media/dvb/dvb-usb/Kconfig |8
drivers/media/dvb/dvb-usb/Makefile |3 +++
2 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/Kconfig
b/drivers/media/dvb/dvb-usb/Kconfig
index
Need patches:
[PATCH 1/5] [media] mb86a20s: add i2c_gate_ctrl
[PATCH 2/5] [media] mb86a20s: Add support for TBS-Tech ISDB-T Full Seg DTB08
[PATCH 3/5] [media] Add Keytable for tbs_dtb08 remote controller
[PATCH 4/5] [media] Add support for TBS-Tech ISDB-T Full Seg DTB08
Signed-off-by: Manoel
Hi,
Given the many comments in this thread, I'm just
going reply to this one, and try to also answer any
other ones in this mail.
As far as the dual mode camera is involved, I agree
that that should be fixed in the existing v4l2
drivers + libgphoto. I think that Felipe's solution
to also handle
Hi Hans,
On Thursday 09 June 2011 13:22:03 Hans de Goede wrote:
Hi,
When I unplug a uvc camera *while streaming* I get:
[15824.809741] BUG: unable to handle kernel NULL pointer dereference at
(null)
[snip]
I've not tested if this also impacts 3.0!!
It probably does. Thanks
Hello:
I have patched af9015.c and dvb-usb-ids to support sveon stv22 ( KWorld USB
Dual DVB-T TV Stick (DVB-T 399U) clone ) dual with
-
#define USB_PID_SVEON_STV22 0xe401
--
in dvb-usb-ids.h file
and
-
/* 30 */{USB_DEVICE(USB_VID_KWORLD_2,
Hi Hans de G.,
Em 26-04-2011 08:54, Hans de Goede escreveu:
If you could give it a shot that would be great. I've some hardware to
test this with (although I've never actually tested that hardware), so
I can hopefully pick things up if you cannot finish things before you
need to return the
Em 06-05-2011 06:46, David Härdeman escreveu:
On Wed, 04 May 2011 12:23:03 -0300, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 28-04-2011 12:13, David Härdeman escreveu:
Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary
Change locking to allow tea575x-radio device to be opened multiple times.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-06-11
15:21:50.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-06-11
While testing the new multi-standard tuner of the HVR-1600 (the cx18 driver)
I came across a number of bugs in tuner-core that were recently introduced.
This patch series fixes those bugs and cleans up some code that confused
me.
The bugs fixed in this series are:
1) 'type' is set by the
From: Hans Verkuil hans.verk...@cisco.com
The check_mode function checks whether a mode is supported. So calling it
supported_mode is more appropriate. In addition it returned either 0 or
-EINVAL which suggests that the -EINVAL error should be passed on. However,
that's not the case so change the
From: Hans Verkuil hans.verk...@cisco.com
set_mode_freq currently returns 0 or -EINVAL. But -EINVAL does not
indicate a error that should be passed on, it just indicates that the
tuner does not support the requested mode. So change the return type to
bool.
Signed-off-by: Hans Verkuil
From: Hans Verkuil hans.verk...@cisco.com
g_tuner just returns the tuner data for the current tuner mode and the
application does not have to set the tuner type. So don't test for a
valid tuner type.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c |2
From: Hans Verkuil hans.verk...@cisco.com
According to the spec the tuner type field is not used when calling
S_TUNER: index, audmode and reserved are the only writable fields.
So remove the type check. Instead, just set the audmode if the current
tuner mode is set to radio.
Signed-off-by: Hans
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_G_FREQUENCY should not check the tuner type, instead that is
something the driver fill in.
Since apps will often leave the type at 0, the 'supported_mode' call
will return false and the frequency never gets filled in.
Remove this check.
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
first calls set_mode, and if that returns true
On Saturday, June 11, 2011 15:28:59 Ondrej Zary wrote:
Change locking to allow tea575x-radio device to be opened multiple times.
Very nice!
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Regards,
Hans
Signed-off-by: Ondrej Zary li...@rainbow-software.org
---
Em 03-06-2011 18:28, Jarod Wilson escreveu:
This is a custom IR protocol decoder, for the RC-6-ish protocol used by
the Microsoft Remote Keyboard.
http://www.amazon.com/Microsoft-Remote-Keyboard-Windows-ZV1-4/dp/B000AOAAN8
Its a standard keyboard with embedded thumb stick mouse pointer
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_G_FREQUENCY should not check the tuner type, instead that is
something the driver fill in.
Since apps will often leave the type at 0, the 'supported_mode' call
will return false and the frequency
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
g_tuner just returns the tuner data for the current tuner mode and the
application does not have to set the tuner type. So don't test for a
valid tuner type.
This also breaks support for a separate radio
On Saturday, June 11, 2011 15:44:43 Mauro Carvalho Chehab wrote:
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_G_FREQUENCY should not check the tuner type, instead that is
something the driver fill in.
Since apps will often leave the
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
According to the spec the tuner type field is not used when calling
S_TUNER: index, audmode and reserved are the only writable fields.
So remove the type check. Instead, just set the audmode if the
Second version of this patch series.
It's the same as RFCv1, except that I dropped the g_frequency and
g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch series)
because I need to think more on those, and I added a new fix for tuner_resume
which was broken as well.
Regards,
From: Hans Verkuil hans.verk...@cisco.com
The check_mode function checks whether a mode is supported. So calling it
supported_mode is more appropriate. In addition it returned either 0 or
-EINVAL which suggests that the -EINVAL error should be passed on. However,
that's not the case so change the
From: Hans Verkuil hans.verk...@cisco.com
set_mode_freq currently returns 0 or -EINVAL. But -EINVAL does not
indicate a error that should be passed on, it just indicates that the
tuner does not support the requested mode. So change the return type to
bool.
Signed-off-by: Hans Verkuil
From: Hans Verkuil hans.verk...@cisco.com
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 92 +++---
1 files changed, 27
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
first calls set_mode, and if that returns true
On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil hverk...@xs4all.nl wrote:
Second version of this patch series.
It's the same as RFCv1, except that I dropped the g_frequency and
g_tuner/s_tuner patches (patch 3, 6 and 7 in the original patch series)
because I need to think more on those, and I
On Saturday, June 11, 2011 17:32:10 Devin Heitmueller wrote:
On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil hverk...@xs4all.nl wrote:
Second version of this patch series.
It's the same as RFCv1, except that I dropped the g_frequency and
g_tuner/s_tuner patches (patch 3, 6 and 7 in the
Hans Verkuil hverk...@xs4all.nl wrote:
On Saturday, June 11, 2011 17:32:10 Devin Heitmueller wrote:
On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil hverk...@xs4all.nl
wrote:
Second version of this patch series.
It's the same as RFCv1, except that I dropped the g_frequency and
On Sat, 11 Jun 2011, Hans de Goede wrote:
Hi,
Given the many comments in this thread, I'm just
going reply to this one, and try to also answer any
other ones in this mail.
As far as the dual mode camera is involved, I agree
that that should be fixed in the existing v4l2
drivers +
i've been using the patches in the latest media_tree for some hours -
the S2-3650 CI seems to work. There's one thing that disturbs me, though
- when it scans / locks on a frequency, another device on the same PC,
using the same stb6100, gets stuck for a moment. Any ideas what might be
the
On Sat, Jun 11, 2011 at 12:06 PM, Andy Walls awa...@md.metrocast.net wrote:
Devin,
I think I have a Gotview or compro card with an xc2028. Is that tuner
capable of standby? Would the cx18 or ivtv driver need to actively support
using stand by?
An xc2028/xc3028 should be fine, as that
On Sat, 11 Jun 2011, Hans de Goede wrote:
So what do we need to make this situation better:
1) A usb_driver callback alternative to the disconnect callback,
I propose to call this soft_disconnect. This serves 2 purposes
a) It will allow the driver to tell the caller that that is
On Sat, Jun 11, 2011 at 11:53 AM, Hans Verkuil hverk...@xs4all.nl wrote:
Do you happen to know not-too-expensive cards that you can buy that have
this sort of tuners? It may be useful to be able to test this myself.
Anything with an xc3028 or xc5000 would have this issue. I don't
really keep
On Sat, Jun 11, 2011 at 1:02 PM, Hans Verkuil hverk...@xs4all.nl wrote:
OK, but how do you get it into standby in the first place? (I must be missing
something here...)
The tuner core puts the chip into standby when the last V4L filehandle
is closed. Yes, I realize this violates the V4L spec
On Saturday, June 11, 2011 17:05:30 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq
On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote:
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
According to the spec the tuner type field is not used when calling
S_TUNER: index, audmode and reserved are the only writable fields.
This driver will soon become a family of drivers, so let's give it its own
place to live. This move requires putting ov7670.h into include/media, but
there are no code changes.
Cc: Daniel Drake d...@laptop.org
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/Kconfig
Here is the second posting of the cafe_ccic driver rework and the addition
of the Armada 610 camera driver. Things have been somewhat cleaned up
since the first time around, and I think that this series is ready to be
queued for 3.1. Mauro, if you agree, the whole series can be pulled from:
Depending on the controller, the ov7670 sensor may be told to work with a
different clock speed or to use the SMBUS protocol. Remove the wired-in
code and pass that information from the platform layer. The Cafe driver
now just assumes it's running on an OLPC XO 1; I do not believe it has ever
Nobody else ever needs to see these, so let's hide them.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/cafe-driver.c | 63
drivers/media/video/marvell-ccic/mcam-core.h | 56 +-
2 files changed, 64
This code is, indeed, tested :)
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/cafe-driver.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/marvell-ccic/cafe-driver.c
The upcoming mmp-camera driver will need an i2c_adapter structure allocated
externally, so change the core adapter to a pointer and require the
platform code to fill it in.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/cafe-driver.c |9 +++--
Now we have a camera working over the marvell cam controller core. It
works like the cafe driver and has all the same limitations, contiguous DMA
only being one of them. But it's a start.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/Makefile |1 +
This makes the cafe i2c implement consistent with the rest of Linux so that
the core can use the same slave ID everywhere.
Signed-off-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/video/marvell-ccic/cafe-driver.c |9 -
drivers/media/video/marvell-ccic/mcam-core.c |2 +-
Third version of this patch series.
Pretty much the same as RFCv2 (except for a small fix in the fourth patch)
except for patch 6. This it my attempt to fix tuner-core without having
to change any drivers.
It just keeps track of whether the current application mode is valid for
this tuner. If
From: Hans Verkuil hans.verk...@cisco.com
set_mode_freq currently returns 0 or -EINVAL. But -EINVAL does not
indicate a error that should be passed on, it just indicates that the
tuner does not support the requested mode. So change the return type to
bool.
Signed-off-by: Hans Verkuil
From: Hans Verkuil hans.verk...@cisco.com
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c | 92 +++---
1 files changed, 27
From: Hans Verkuil hans.verk...@cisco.com
set_mode is called with t-type, which is the tuner type. Instead, use
t-mode which is the actual tuner mode (i.e. radio vs tv).
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/tuner-core.c |2 +-
1 files changed, 1
From: Hans Verkuil hans.verk...@cisco.com
Both s_std and s_tuner are broken because set_mode_freq is called before the
new std (for s_std) and audmode (for s_tuner) are set.
This patch splits set_mode_freq in a set_mode and a set_freq and in s_std
first calls set_mode, and if that returns true
From: Hans Verkuil hans.verk...@cisco.com
VIDIOC_G_FREQUENCY and VIDIOC_G/S_TUNER should not check the tuner type,
instead that is something the driver fills in.
Since apps will often leave the type at 0, the 'supported_mode' call
will return false and the call just returns.
But the call should
Hans Verkuil hverk...@xs4all.nl wrote:
On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote:
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
According to the spec the tuner type field is not used when calling
S_TUNER: index, audmode and
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.
Results of the daily build of v4l-dvb:
date:Sat Jun 11 19:02:27 CEST 2011
git hash:f49c454fe981d955d7c3d620f6baa04fb9876adc
gcc version: i686-linux-gcc (GCC)
Em 11-06-2011 14:27, Hans Verkuil escreveu:
On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote:
Em 11-06-2011 10:34, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
According to the spec the tuner type field is not used when calling
S_TUNER: index, audmode and
57 matches
Mail list logo
