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
>>>
>>> According to the spec the tuner type field is not used when calling
>>> S_TUNER: index, audmode and reserved
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) 4.5
Hans Verkuil 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
>> >
>> > According to the spec the tuner type field is not used when calling
>> > S_TUNER: index, audmode and reserved are the only writa
From: Hans Verkuil
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 only return if the cur
From: Hans Verkuil
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 (i.e. the mode is suppor
From: Hans Verkuil
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
---
drivers/media/video/tuner-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/driver
From: Hans Verkuil
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil
---
drivers/media/video/tuner-core.c | 92 +++---
1 files changed, 27 insertions(+), 65 deletions(-)
diff --git a/drive
From: Hans Verkuil
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
---
drivers/media/video/tuner-co
From: Hans Verkuil
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 return type to bool.
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 not
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
---
drivers/media/video/marvell-ccic/cafe-driver.c |9 -
drivers/media/video/marvell-ccic/mcam-core.c |2 +-
2 files changed
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
---
drivers/media/video/Makefile |1 +
drivers/media/v
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
---
drivers/media/video/marvell-ccic/cafe-driver.c |9 +++--
drivers/media/video/mar
This code is, indeed, tested :)
Signed-off-by: Jonathan Corbet
---
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
b/drivers/media/video/marvell-ccic/cafe-driver.c
index 08ed
Nobody else ever needs to see these, so let's hide them.
Signed-off-by: Jonathan Corbet
---
drivers/media/video/marvell-ccic/cafe-driver.c | 63
drivers/media/video/marvell-ccic/mcam-core.h | 56 +-
2 files changed, 64 insertions(+), 55 deletion
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
run
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:
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
Signed-off-by: Jonathan Corbet
---
drivers/media/video/Kconfig| 11 ++-
On Saturday, June 11, 2011 15:54:59 Mauro Carvalho Chehab wrote:
> Em 11-06-2011 10:34, Hans Verkuil escreveu:
> > From: Hans Verkuil
> >
> > 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 remo
On Saturday, June 11, 2011 17:05:30 Hans Verkuil wrote:
> From: Hans Verkuil
>
> 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
> f
On Sat, Jun 11, 2011 at 1:02 PM, Hans Verkuil 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 since you should
b
On Saturday, June 11, 2011 18:57:16 Devin Heitmueller wrote:
> On Sat, Jun 11, 2011 at 12:06 PM, Andy Walls 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 s
On Sat, Jun 11, 2011 at 11:53 AM, Hans Verkuil 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 close track of cur
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 t
On Sat, Jun 11, 2011 at 12:06 PM, Andy Walls 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 does support standby.
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 caus
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
> drive
Hans Verkuil wrote:
>On Saturday, June 11, 2011 17:32:10 Devin Heitmueller wrote:
>> On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil
>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,
Devin Heitmueller wrote:
>On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil
>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
On Saturday, June 11, 2011 17:32:10 Devin Heitmueller wrote:
> On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil 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 patc
On Sat, Jun 11, 2011 at 11:05 AM, Hans Verkuil 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 added a new fi
From: Hans Verkuil
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
---
drivers/media/video/tuner-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/driver
From: Hans Verkuil
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 (i.e. the mode is suppor
From: Hans Verkuil
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil
---
drivers/media/video/tuner-core.c | 92 +++---
1 files changed, 27 insertions(+), 65 deletions(-)
diff --git a/drive
From: Hans Verkuil
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
---
drivers/media/video/tuner-co
From: Hans Verkuil
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 return type to bool.
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,
Em 11-06-2011 10:34, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> 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
On Saturday, June 11, 2011 15:44:43 Mauro Carvalho Chehab wrote:
> Em 11-06-2011 10:34, Hans Verkuil escreveu:
> > From: Hans Verkuil
> >
> > 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, t
Em 11-06-2011 10:34, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> 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 tuner, as both TV a
Em 11-06-2011 10:34, Hans Verkuil escreveu:
> From: Hans Verkuil
>
> 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 fille
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 po
Remove empty and useless g_input and s_input ioctls.
This fixes one fail of v4l2-compliance test.
Signed-off-by: Ondrej Zary
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-06-11
15:29:18.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-06-11
15:29:51.0
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
Regards,
Hans
> Signed-off-by: Ondrej Zary
>
> --- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-06-11
From: Hans Verkuil
Get rid of a number of unnecessary tuner_dbg messages by simplifying
the std fixup function.
Signed-off-by: Hans Verkuil
---
drivers/media/video/tuner-core.c | 92 +++---
1 files changed, 27 insertions(+), 65 deletions(-)
diff --git a/drive
From: Hans Verkuil
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 (i.e. the mode is suppor
From: Hans Verkuil
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.
Signed-off-by: Hans Verkuil
--
From: Hans Verkuil
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 Verkuil
---
drivers/
From: Hans Verkuil
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
---
drivers/media/video/tuner-core.c |2 --
1 files changed, 0 insertions(+), 2 delet
From: Hans Verkuil
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
---
drivers/media/video/tuner-co
From: Hans Verkuil
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 return type to bool.
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 driver,
Change locking to allow tea575x-radio device to be opened multiple times.
Signed-off-by: Ondrej Zary
--- 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
14:50:55.0 +0200
@@ -49,7
Em 06-05-2011 06:46, David Härdeman escreveu:
> On Wed, 04 May 2011 12:23:03 -0300, Mauro Carvalho Chehab
> 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 to the ini
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
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, USB_PID_KWORLD_UB383_T)}
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.
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
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 Pinh
Signed-off-by: Manoel Pinheiro
---
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 e85304c..dd922c9 10064
Signed-off-by: Manoel Pinheiro
---
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 mode 100644 drivers/medi
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
---
drivers/media/dvb/frontends/mb86a20s.c | 203
drivers/media/dvb/front
The register 0xfe controls the i2c-bus from the mb86a20s to tuner.
Signed-off-by: Manoel Pinheiro
---
drivers/media/dvb/frontends/mb86a20s.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
b/drivers/media/dvb/frontends
63 matches
Mail list logo
