Re: cron job: media_tree daily build: ERRORS: help needed
Hi all, Yesterday I upgraded the gcc version I use to compile the daily build to 4.7.1. This causes very strange errors when compiling 2.6.39 - 3.3: FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a modulo of the size of section __mod_i2c_device_table=18. Fix definition of struct i2c_device_id in mod_devicetable.h This error does not appear when compiling with gcc 4.6.3, and I see absolutely nothing wrong with mod_devicetable.h. I tried very hard to figure out what is going on and why older and newer kernels are not affected, but I still have no idea. The error itself it reported by scripts/mod/file2alias.c. I can suppress that error but that will just lead to a modpost crash later in the compile process. The tuner.o file always causes this. Commenting tuner.o in the Makefile will cause the same problems in other modules (cafe_ccic), but there are also i2c modules that compile just fine. Does anyone have an insight into this? Did something magical change in kernel 3.4 that fixed this? Regards, Hans On 18/06/12 20:58, Hans Verkuil wrote: This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Jun 18 19:00:12 CEST 2012 git hash:5472d3f17845c4398c6a510b46855820920c2181 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Hi,
On 06/19/2012 02:47 AM, Mauro Carvalho Chehab wrote:
Em 28-05-2012 07:46, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2339678..013ee46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2023,7 +2023,8 @@ struct v4l2_tuner {
__u32 audmode;
__s32 signal;
__s32 afc;
- __u32 reserved[4];
+ __u32 band;
+ __u32 reserved[3];
};
struct v4l2_modulator {
@@ -2033,7 +2034,8 @@ struct v4l2_modulator {
__u32 rangelow;
__u32 rangehigh;
__u32 txsubchans;
- __u32 reserved[4];
+ __u32 band;
+ __u32 reserved[3];
};
/* Flags for the 'capability' field */
@@ -2048,6 +2050,11 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
+#define V4L2_TUNER_CAP_BAND_FM_EUROPE_US 0x0001
+#define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002
+#define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004
+#define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008
+#define V4L2_TUNER_CAP_BAND_AM_MW0x0010
Frequency band is already specified by rangelow/rangehigh.
Why do you need to duplicate this information?
Because radio tuners may support multiple non overlapping
bands, this is why this patch also adds a band member
to the tuner struct, which can be used to set/get
the current band.
One example of this are the tea5757 / tea5759
radio tuner chips:
FM:
tea5757 87.5 - 108 MHz
tea5759 76 - 91 MHz
AM:
Both: 530 - 1710 kHz
So an app would set as band one of DEFAULT, EUROPE_US
(or JAPAN depending on the model) and AM_MW, and then
get the actual range supported reported in rangelow /
rangehigh on a subsequent G_TUNER.
Note that setting ie a band of FM_JAPAN on a 5757 would
result in the S_TUNER failing with -EINVAL.
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO 0x0001
@@ -2065,6 +2072,14 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG10x0003
#define V4L2_TUNER_MODE_LANG1_LANG2 0x0004
+/* Values for the 'band' field */
+#define V4L2_TUNER_BAND_DEFAULT 0
What does default mean?
Default means default. This is for compatibility with
old apps which don't know about the new tuner band API
extension so they will set this field to 0 (as reserved
fields should be set to 0 by userspace). In this case
we don't want to fail with -EINVAL based on the band
value, so we need some value all tuners will accept.
Some tuners, ie the si470x support both selecting a
specific FM band, as well as selecting a universal
FM band of 76 - 108 MHz. For those default would be
the universal FM band. For the tea575x devices discussed
above default would have the range of whatever FM band
they support.
Note that even on devices with a universal band being
able to select a certain band is quite useful to limit
hardware freq-seek to this band since searching freqs
below 87.5 is useless in europe / US for example.
Thinking more about this I think we should rename
V4L2_TUNER_BAND_DEFAULT to V4L2_TUNER_BAND_FM_UNIVERSAL,
and document that this means the widest FM band the
device supports, with the actual limits being reported
in rangelow and rangehigh. Note that the mentioned ranges
by the bands are indications of the expected range only
the true range will still be reported through rangelow and
rangehigh, and this is what apps are expected to use.
Defining 0 as V4L2_TUNER_BAND_FM_UNIVERSAL does cause
a -EINVAL when doing a S_TUNER with a band value of 0
on AM only tuners, but:
1) We don't support AM only tuners atm, and I don't expect
we will in the future either
2) Non band aware apps don't work well with AM tuners anyways
(as they must take much smaller frequency steps for one).
+#define V4L2_TUNER_BAND_FM_EUROPE_US 1 /* 87.5 Mhz - 108 MHz */
EUROPE_US is a bad name for this range. According with Wikipedia, this
range is used at ITU region 1 (Europe/Africa), while America uses
ITU region 2 (88-108).
In Brazil, the range from 87.5-88 were added several years ago, so it is
currently at the ITU region 1 range, just like in US.
I don't doubt that there are still some places at the 88-108 MHz range.
87.5 - 108 MHz is very close to 88 - 108 MHz, I don't think it is worth
creating 2 band defines for this.
+#define V4L2_TUNER_BAND_FM_JAPAN 2 /* 76 MHz - 90 MHz */
This is currently true,
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Em 19-06-2012 05:27, Hans de Goede escreveu:
Hi,
On 06/19/2012 02:47 AM, Mauro Carvalho Chehab wrote:
Em 28-05-2012 07:46, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2339678..013ee46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2023,7 +2023,8 @@ struct v4l2_tuner {
__u32audmode;
__s32signal;
__s32afc;
-__u32reserved[4];
+__u32band;
+__u32reserved[3];
};
struct v4l2_modulator {
@@ -2033,7 +2034,8 @@ struct v4l2_modulator {
__u32rangelow;
__u32rangehigh;
__u32txsubchans;
-__u32reserved[4];
+__u32band;
+__u32reserved[3];
};
/* Flags for the 'capability' field */
@@ -2048,6 +2050,11 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
+#define V4L2_TUNER_CAP_BAND_FM_EUROPE_US 0x0001
+#define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002
+#define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004
+#define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008
+#define V4L2_TUNER_CAP_BAND_AM_MW0x0010
Frequency band is already specified by rangelow/rangehigh.
Why do you need to duplicate this information?
Because radio tuners may support multiple non overlapping
bands, this is why this patch also adds a band member
to the tuner struct, which can be used to set/get
the current band.
One example of this are the tea5757 / tea5759
radio tuner chips:
FM:
tea5757 87.5 - 108 MHz
rangelow = 87.5 * 62500;
rangehigh = 108 * 62500;
tea5759 76 - 91 MHz
rangelow = 76 * 62500;
rangehigh = 91 * 62500;
AM:
Both: 530 - 1710 kHz
rangelow = 0.530 * 62500;
rangehigh = 0.1710 * 62500;
See radio-cadet.c:
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
v-type = V4L2_TUNER_RADIO;
switch (v-index) {
case 0:
strlcpy(v-name, FM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS |
V4L2_TUNER_CAP_RDS_BLOCK_IO;
v-rangelow = 1400; /* 87.5 MHz */
v-rangehigh = 1728;/* 108.0 MHz */
v-rxsubchans = cadet_getstereo(dev);
switch (v-rxsubchans) {
case V4L2_TUNER_SUB_MONO:
v-audmode = V4L2_TUNER_MODE_MONO;
break;
case V4L2_TUNER_SUB_STEREO:
v-audmode = V4L2_TUNER_MODE_STEREO;
break;
default:
break;
}
v-rxsubchans |= V4L2_TUNER_SUB_RDS;
break;
case 1:
strlcpy(v-name, AM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_LOW;
v-rangelow = 8320; /* 520 kHz */
v-rangehigh = 26400;/* 1650 kHz */
v-rxsubchans = V4L2_TUNER_SUB_MONO;
v-audmode = V4L2_TUNER_MODE_MONO;
break;
default:
return -EINVAL;
}
v-signal = dev-sigstrength; /* We might need to modify scaling of this
*/
return 0;
}
static int vidioc_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
if (v-index != 0 v-index != 1)
return -EINVAL;
dev-curtuner = v-index;
return 0;
}
Band switching are made via g_tuner/s_tuner calls. If a device have
several non-overlapping bands, just implement it there. There's no
need for a new API.
Also, this is generic enough to cover even devices with non-standard
frequency ranges.
All bands can easily be detected via a g_tuner loop, and band switching
is done via s_tuner.
Each band range can have its name (AM, FM, AM-SW, FM-Japan, ...),
and this is a way more generic than what's being proposed.
It likely makes sense to standardize the band names inside the radio core,
in order to avoid having the same band called with two different names inside
the drivers.
It should also be noticed that each band may have different properties.
On the above, the FM band can do stereo/mono and RDS, while AM is just
mono So, a change like what's proposed would keep requiring two
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Hi,
On 06/19/2012 01:09 PM, Mauro Carvalho Chehab wrote:
Em 19-06-2012 05:27, Hans de Goede escreveu:
Hi,
On 06/19/2012 02:47 AM, Mauro Carvalho Chehab wrote:
Em 28-05-2012 07:46, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2339678..013ee46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2023,7 +2023,8 @@ struct v4l2_tuner {
__u32audmode;
__s32signal;
__s32afc;
-__u32reserved[4];
+__u32band;
+__u32reserved[3];
};
struct v4l2_modulator {
@@ -2033,7 +2034,8 @@ struct v4l2_modulator {
__u32rangelow;
__u32rangehigh;
__u32txsubchans;
-__u32reserved[4];
+__u32band;
+__u32reserved[3];
};
/* Flags for the 'capability' field */
@@ -2048,6 +2050,11 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
+#define V4L2_TUNER_CAP_BAND_FM_EUROPE_US 0x0001
+#define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002
+#define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004
+#define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008
+#define V4L2_TUNER_CAP_BAND_AM_MW0x0010
Frequency band is already specified by rangelow/rangehigh.
Why do you need to duplicate this information?
Because radio tuners may support multiple non overlapping
bands, this is why this patch also adds a band member
to the tuner struct, which can be used to set/get
the current band.
One example of this are the tea5757 / tea5759
radio tuner chips:
FM:
tea5757 87.5 - 108 MHz
rangelow = 87.5 * 62500;
rangehigh = 108 * 62500;
tea5759 76 - 91 MHz
rangelow = 76 * 62500;
rangehigh = 91 * 62500;
AM:
Both: 530 - 1710 kHz
rangelow = 0.530 * 62500;
rangehigh = 0.1710 * 62500;
See radio-cadet.c:
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
v-type = V4L2_TUNER_RADIO;
switch (v-index) {
case 0:
strlcpy(v-name, FM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS |
V4L2_TUNER_CAP_RDS_BLOCK_IO;
v-rangelow = 1400; /* 87.5 MHz */
v-rangehigh = 1728;/* 108.0 MHz */
v-rxsubchans = cadet_getstereo(dev);
switch (v-rxsubchans) {
case V4L2_TUNER_SUB_MONO:
v-audmode = V4L2_TUNER_MODE_MONO;
break;
case V4L2_TUNER_SUB_STEREO:
v-audmode = V4L2_TUNER_MODE_STEREO;
break;
default:
break;
}
v-rxsubchans |= V4L2_TUNER_SUB_RDS;
break;
case 1:
strlcpy(v-name, AM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_LOW;
v-rangelow = 8320; /* 520 kHz */
v-rangehigh = 26400;/* 1650 kHz */
v-rxsubchans = V4L2_TUNER_SUB_MONO;
v-audmode = V4L2_TUNER_MODE_MONO;
break;
default:
return -EINVAL;
}
v-signal = dev-sigstrength; /* We might need to modify scaling of this
*/
return 0;
}
static int vidioc_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
if (v-index != 0 v-index != 1)
return -EINVAL;
dev-curtuner = v-index;
return 0;
}
Band switching are made via g_tuner/s_tuner calls. If a device have
several non-overlapping bands, just implement it there. There's no
need for a new API.
sigh, this has been discussed extensively between me, Hans V and
Halli Manjunatha on both irc and on the list. What the cadet driver is
doing is an ugly hack, and really a poor match for what we want.
Not to mention that it is a clear violation of the v4l2 spec:
http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html
Radio input devices have exactly one tuner with index zero, no video inputs.
So there is supposed to be only one tuner, and s_tuner / g_tuner
on radio devices always expect a tuner index of 0.
Also from the same page:
Note that VIDIOC_S_TUNER does not switch the current tuner, when there is more than
one at all.
So if we model
Re: [v4l-utils] Add configure option to allow qv4l2 disable
Hi Mauro, On Mon, Jun 18, 2012 at 7:01 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 31-05-2012 13:29, Ezequiel Garcia escreveu: Hi Gregor, On Thu, May 31, 2012 at 4:07 AM, Gregor Jasny gja...@googlemail.com wrote: Hello, On 5/30/12 3:42 PM, Ezequiel Garcia wrote: This patch could ease the job of a few people, by providing an option they actually need. OpenWRT [1] and Openembedded [2] are already disabling qv4l2 by applying ugly patches. [1] https://dev.openwrt.org/browser/packages/libs/libv4l/patches/004-disable-qv4l2.patch [2] http://patches.openembedded.org/patch/21469/ What's the purpose of this patch? As far as I can see it saves compile time if Qt4 development stuff is installed. Otherwise building qv4l should be skipped. I just found that people were applying patches to disable qv4l2 compilation. In [2] you'll find this message: The makefiles in the project attempt to use the hosts' compilers if qmake is installed. Perhaps, this was due to an old bug that's already solved. So: I'm not sure if patch is useful, but I thought I could send it anyway and let you decide ;) Yeah, compiling qv4l2 on embedded distros may be hard. I'll apply it. Gregory already applied this patch, and it seems you have now over applied it in the same tree: http://git.linuxtv.org/v4l-utils.git/commit/7fc9fa40e7fd1a72688c6f43fc11e085079b3f0c http://git.linuxtv.org/v4l-utils.git/commit/06e5235b4e1514f9234a21942261ba417deb106c Also Gregory cleaned a bit the patch (mine was very basic, since I'm not autoconf-friendly). So, could you revert the one you've committed? Thanks, Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cron job: media_tree daily build: ERRORS: help needed
Hi Hans, On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, Yesterday I upgraded the gcc version I use to compile the daily build to 4.7.1. This causes very strange errors when compiling 2.6.39 - 3.3: FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a modulo of the size of section __mod_i2c_device_table=18. Fix definition of struct i2c_device_id in mod_devicetable.h This error does not appear when compiling with gcc 4.6.3, and I see absolutely nothing wrong with mod_devicetable.h. I tried very hard to figure out what is going on and why older and newer kernels are not affected, but I still have no idea. The error itself it reported by scripts/mod/file2alias.c. I can suppress that error but that will just lead to a modpost crash later in the compile process. The tuner.o file always causes this. Commenting tuner.o in the Makefile will cause the same problems in other modules (cafe_ccic), but there are also i2c modules that compile just fine. Does anyone have an insight into this? Did something magical change in kernel 3.4 that fixed this? Perhaps this thread could be useful: https://lkml.org/lkml/2012/6/15/323 Hope it helps, Ezequiel. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Hi Mauro,
Please take the Patch-set 7 which I submitted by removing my set_band
implementation (as per Hans V suggestion).
https://lkml.org/lkml/2012/5/21/294
Regards
Manju
On Tue, Jun 19, 2012 at 7:36 AM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 06/19/2012 01:09 PM, Mauro Carvalho Chehab wrote:
Em 19-06-2012 05:27, Hans de Goede escreveu:
Hi,
On 06/19/2012 02:47 AM, Mauro Carvalho Chehab wrote:
Em 28-05-2012 07:46, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2339678..013ee46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2023,7 +2023,8 @@ struct v4l2_tuner {
__u32 audmode;
__s32 signal;
__s32 afc;
- __u32 reserved[4];
+ __u32 band;
+ __u32 reserved[3];
};
struct v4l2_modulator {
@@ -2033,7 +2034,8 @@ struct v4l2_modulator {
__u32 rangelow;
__u32 rangehigh;
__u32 txsubchans;
- __u32 reserved[4];
+ __u32 band;
+ __u32 reserved[3];
};
/* Flags for the 'capability' field */
@@ -2048,6 +2050,11 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
+#define V4L2_TUNER_CAP_BAND_FM_EUROPE_US 0x0001
+#define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002
+#define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004
+#define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008
+#define V4L2_TUNER_CAP_BAND_AM_MW 0x0010
Frequency band is already specified by rangelow/rangehigh.
Why do you need to duplicate this information?
Because radio tuners may support multiple non overlapping
bands, this is why this patch also adds a band member
to the tuner struct, which can be used to set/get
the current band.
One example of this are the tea5757 / tea5759
radio tuner chips:
FM:
tea5757 87.5 - 108 MHz
rangelow = 87.5 * 62500;
rangehigh = 108 * 62500;
tea5759 76 - 91 MHz
rangelow = 76 * 62500;
rangehigh = 91 * 62500;
AM:
Both: 530 - 1710 kHz
rangelow = 0.530 * 62500;
rangehigh = 0.1710 * 62500;
See radio-cadet.c:
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
v-type = V4L2_TUNER_RADIO;
switch (v-index) {
case 0:
strlcpy(v-name, FM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS
|
V4L2_TUNER_CAP_RDS_BLOCK_IO;
v-rangelow = 1400; /* 87.5 MHz */
v-rangehigh = 1728; /* 108.0 MHz */
v-rxsubchans = cadet_getstereo(dev);
switch (v-rxsubchans) {
case V4L2_TUNER_SUB_MONO:
v-audmode = V4L2_TUNER_MODE_MONO;
break;
case V4L2_TUNER_SUB_STEREO:
v-audmode = V4L2_TUNER_MODE_STEREO;
break;
default:
break;
}
v-rxsubchans |= V4L2_TUNER_SUB_RDS;
break;
case 1:
strlcpy(v-name, AM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_LOW;
v-rangelow = 8320; /* 520 kHz */
v-rangehigh = 26400; /* 1650 kHz */
v-rxsubchans = V4L2_TUNER_SUB_MONO;
v-audmode = V4L2_TUNER_MODE_MONO;
break;
default:
return -EINVAL;
}
v-signal = dev-sigstrength; /* We might need to modify scaling of
this
*/
return 0;
}
static int vidioc_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
if (v-index != 0 v-index != 1)
return -EINVAL;
dev-curtuner = v-index;
return 0;
}
Band switching are made via g_tuner/s_tuner calls. If a device have
several non-overlapping bands, just implement it there. There's no
need for a new API.
sigh, this has been discussed extensively between me, Hans V and
Halli Manjunatha on both irc and on the list. What the cadet driver is
doing is an ugly hack, and really a poor match for what we want.
Not to mention that it is a clear violation of the v4l2 spec:
http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html
Radio input devices have
Re: cron job: media_tree daily build: ERRORS: help needed
On Tue 19 June 2012 14:50:09 Ezequiel Garcia wrote: Hi Hans, On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, Yesterday I upgraded the gcc version I use to compile the daily build to 4.7.1. This causes very strange errors when compiling 2.6.39 - 3.3: FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a modulo of the size of section __mod_i2c_device_table=18. Fix definition of struct i2c_device_id in mod_devicetable.h This error does not appear when compiling with gcc 4.6.3, and I see absolutely nothing wrong with mod_devicetable.h. I tried very hard to figure out what is going on and why older and newer kernels are not affected, but I still have no idea. The error itself it reported by scripts/mod/file2alias.c. I can suppress that error but that will just lead to a modpost crash later in the compile process. The tuner.o file always causes this. Commenting tuner.o in the Makefile will cause the same problems in other modules (cafe_ccic), but there are also i2c modules that compile just fine. Does anyone have an insight into this? Did something magical change in kernel 3.4 that fixed this? Perhaps this thread could be useful: https://lkml.org/lkml/2012/6/15/323 Yeah, I read that as well. But there there is a clear change that caused the problem. As far as I can tell include/linux/mod_devicetable.h has identical i2c_device_id structs for linux-3.0/1/2/3/4, yet all compile fine with gcc-4.6.3, but for gcc-4.7.1 only linux-3.4 compiles. I'm stumped. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Em 19-06-2012 09:36, Hans de Goede escreveu:
Hi,
On 06/19/2012 01:09 PM, Mauro Carvalho Chehab wrote:
Em 19-06-2012 05:27, Hans de Goede escreveu:
Hi,
On 06/19/2012 02:47 AM, Mauro Carvalho Chehab wrote:
Em 28-05-2012 07:46, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2339678..013ee46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2023,7 +2023,8 @@ struct v4l2_tuner {
__u32audmode;
__s32signal;
__s32afc;
-__u32reserved[4];
+__u32band;
+__u32reserved[3];
};
struct v4l2_modulator {
@@ -2033,7 +2034,8 @@ struct v4l2_modulator {
__u32rangelow;
__u32rangehigh;
__u32txsubchans;
-__u32reserved[4];
+__u32band;
+__u32reserved[3];
};
/* Flags for the 'capability' field */
@@ -2048,6 +2050,11 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
+#define V4L2_TUNER_CAP_BAND_FM_EUROPE_US 0x0001
+#define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002
+#define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004
+#define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008
+#define V4L2_TUNER_CAP_BAND_AM_MW0x0010
Frequency band is already specified by rangelow/rangehigh.
Why do you need to duplicate this information?
Because radio tuners may support multiple non overlapping
bands, this is why this patch also adds a band member
to the tuner struct, which can be used to set/get
the current band.
One example of this are the tea5757 / tea5759
radio tuner chips:
FM:
tea5757 87.5 - 108 MHz
rangelow = 87.5 * 62500;
rangehigh = 108 * 62500;
tea5759 76 - 91 MHz
rangelow = 76 * 62500;
rangehigh = 91 * 62500;
AM:
Both: 530 - 1710 kHz
rangelow = 0.530 * 62500;
rangehigh = 0.1710 * 62500;
See radio-cadet.c:
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
v-type = V4L2_TUNER_RADIO;
switch (v-index) {
case 0:
strlcpy(v-name, FM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS |
V4L2_TUNER_CAP_RDS_BLOCK_IO;
v-rangelow = 1400; /* 87.5 MHz */
v-rangehigh = 1728;/* 108.0 MHz */
v-rxsubchans = cadet_getstereo(dev);
switch (v-rxsubchans) {
case V4L2_TUNER_SUB_MONO:
v-audmode = V4L2_TUNER_MODE_MONO;
break;
case V4L2_TUNER_SUB_STEREO:
v-audmode = V4L2_TUNER_MODE_STEREO;
break;
default:
break;
}
v-rxsubchans |= V4L2_TUNER_SUB_RDS;
break;
case 1:
strlcpy(v-name, AM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_LOW;
v-rangelow = 8320; /* 520 kHz */
v-rangehigh = 26400;/* 1650 kHz */
v-rxsubchans = V4L2_TUNER_SUB_MONO;
v-audmode = V4L2_TUNER_MODE_MONO;
break;
default:
return -EINVAL;
}
v-signal = dev-sigstrength; /* We might need to modify scaling of this
*/
return 0;
}
static int vidioc_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
if (v-index != 0 v-index != 1)
return -EINVAL;
dev-curtuner = v-index;
return 0;
}
Band switching are made via g_tuner/s_tuner calls. If a device have
several non-overlapping bands, just implement it there. There's no
need for a new API.
sigh, this has been discussed extensively between me, Hans V and
Halli Manjunatha on both irc and on the list. What the cadet driver is
doing is an ugly hack, and really a poor match for what we want.
Not to mention that it is a clear violation of the v4l2 spec:
http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html
Radio input devices have exactly one tuner with index zero, no video inputs.
So there is supposed to be only one tuner, and s_tuner / g_tuner
on radio devices always expect a tuner index of 0.
Also from the same page:
Note that VIDIOC_S_TUNER does not switch the current tuner, when there is
more than one at all.
So if we model discontinuous ranges as multiple tuners how do we
select the right tuner? Certainly *not* though s_tuner, as that would
violate the spec. Note that changing the spec here is not really
[PATCH 1/1] [media] ene_ir: Fix driver initialisation
commit 9ef449c6b31bb6a8e6dedc24de475a3b8c79be20 ([media] rc: Postpone ISR
registration) fixed an early ISR registration on several drivers. It did
however also introduced a bug by moving the invocation of pnp_port_start()
to the end of the probe function.
This patch fixes this issue by moving the invocation of pnp_port_start() to
an earlier stage in the probe function.
Cc: sta...@vger.kernel.org
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
drivers/media/rc/ene_ir.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/ene_ir.c b/drivers/media/rc/ene_ir.c
index ed77c6d..5327061 100644
--- a/drivers/media/rc/ene_ir.c
+++ b/drivers/media/rc/ene_ir.c
@@ -1018,6 +1018,8 @@ static int ene_probe(struct pnp_dev *pnp_dev, const
struct pnp_device_id *id)
spin_lock_init(dev-hw_lock);
+ dev-hw_io = pnp_port_start(pnp_dev, 0);
+
pnp_set_drvdata(pnp_dev, dev);
dev-pnp_dev = pnp_dev;
@@ -1072,7 +1074,6 @@ static int ene_probe(struct pnp_dev *pnp_dev, const
struct pnp_device_id *id)
/* claim the resources */
error = -EBUSY;
- dev-hw_io = pnp_port_start(pnp_dev, 0);
if (!request_region(dev-hw_io, ENE_IO_SIZE, ENE_DRIVER_NAME)) {
dev-hw_io = -1;
dev-irq = -1;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Em 19-06-2012 10:31, halli manjunatha escreveu:
Hi Mauro,
Please take the Patch-set 7 which I submitted by removing my set_band
implementation (as per Hans V suggestion).
https://lkml.org/lkml/2012/5/21/294
Manju,
That doesn't solve the issue.
As I pointed on my previous email, the ranges aren't consistent among the
radio devices. The best, IMHO, would be to use several g/s_tuner ranges,
one for each supported one.
An alternative would be to write a set of ioctls specific for radio that
would do the same that g/s_tuner does at radio-cadet, but, IMHO, this is
is overdesign.
In any case, we should not apply a patch for it without having a consensus
about the right way.
Regards,
Mauro
Regards
Manju
On Tue, Jun 19, 2012 at 7:36 AM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 06/19/2012 01:09 PM, Mauro Carvalho Chehab wrote:
Em 19-06-2012 05:27, Hans de Goede escreveu:
Hi,
On 06/19/2012 02:47 AM, Mauro Carvalho Chehab wrote:
Em 28-05-2012 07:46, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2339678..013ee46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2023,7 +2023,8 @@ struct v4l2_tuner {
__u32audmode;
__s32signal;
__s32afc;
-__u32reserved[4];
+__u32band;
+__u32reserved[3];
};
struct v4l2_modulator {
@@ -2033,7 +2034,8 @@ struct v4l2_modulator {
__u32rangelow;
__u32rangehigh;
__u32txsubchans;
-__u32reserved[4];
+__u32band;
+__u32reserved[3];
};
/* Flags for the 'capability' field */
@@ -2048,6 +2050,11 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
+#define V4L2_TUNER_CAP_BAND_FM_EUROPE_US 0x0001
+#define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002
+#define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004
+#define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008
+#define V4L2_TUNER_CAP_BAND_AM_MW0x0010
Frequency band is already specified by rangelow/rangehigh.
Why do you need to duplicate this information?
Because radio tuners may support multiple non overlapping
bands, this is why this patch also adds a band member
to the tuner struct, which can be used to set/get
the current band.
One example of this are the tea5757 / tea5759
radio tuner chips:
FM:
tea5757 87.5 - 108 MHz
rangelow = 87.5 * 62500;
rangehigh = 108 * 62500;
tea5759 76 - 91 MHz
rangelow = 76 * 62500;
rangehigh = 91 * 62500;
AM:
Both: 530 - 1710 kHz
rangelow = 0.530 * 62500;
rangehigh = 0.1710 * 62500;
See radio-cadet.c:
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
v-type = V4L2_TUNER_RADIO;
switch (v-index) {
case 0:
strlcpy(v-name, FM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS
|
V4L2_TUNER_CAP_RDS_BLOCK_IO;
v-rangelow = 1400; /* 87.5 MHz */
v-rangehigh = 1728;/* 108.0 MHz */
v-rxsubchans = cadet_getstereo(dev);
switch (v-rxsubchans) {
case V4L2_TUNER_SUB_MONO:
v-audmode = V4L2_TUNER_MODE_MONO;
break;
case V4L2_TUNER_SUB_STEREO:
v-audmode = V4L2_TUNER_MODE_STEREO;
break;
default:
break;
}
v-rxsubchans |= V4L2_TUNER_SUB_RDS;
break;
case 1:
strlcpy(v-name, AM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_LOW;
v-rangelow = 8320; /* 520 kHz */
v-rangehigh = 26400;/* 1650 kHz */
v-rxsubchans = V4L2_TUNER_SUB_MONO;
v-audmode = V4L2_TUNER_MODE_MONO;
break;
default:
return -EINVAL;
}
v-signal = dev-sigstrength; /* We might need to modify scaling of
this
*/
return 0;
}
static int vidioc_s_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
if (v-index != 0
RE: DiBcom adapter problems
Hello, can you provide more information: - kernel version - more log information (not only the error message but also the log from the beginning, when you plug the device) with: * the debug parameter of the dib8000 module set to 1 * the frontend_debug parameter of the dvb-core module set to 1 - which application do you use to tune the board regards, Olivier From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On Behalf Of Rodolfo Timoteo da Silva [zhushaz...@gmail.com] Sent: Sunday, June 17, 2012 3:58 PM To: linux-media@vger.kernel.org Subject: DiBcom adapter problems Hi, every time that i try to syntonize DVB-T channels i receive a message in kernel like in log1.txt arch. There are in log2.txt some usefull information about the device. My kernel/system is: Linux version 3.4.2-gentoo-r1-asgard (root@asgard) (gcc version 4.6.3 (Gentoo 4.6.3 p1.3, pie-0.5.2) ) #1 SMP PREEMPT Thu Jun 14 07:45:19 BRT 2012 Best Regards -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [media] cx231xx: restore tuner settings on first open
Hi David, It sounds like we want a solution that * lives in core code * doesn't require tuner drivers to save state * manages hybrid tuners appropriately * allows for gradual API change-over (no flag day for tuners or for capture devices) * has a reasonable grace period before putting tuner to standby These seem like pretty reasonable working requirements to start with. Aside from the entering standby issue, fixing the loss of mode/frequency looks like it may be fixable by just having the capture cards explicitly request the tuner become active -- the tuner core will already restore those for us. It's just that few cards do that today. The challenge is *when* do those cards request the tuner become active? In response to what ioctl() calls? Is it safe to say that the tuner core will know about all hybrid tuners, even if it doesn't know if the digital side is still in use? The tuner-core is used for pretty much every hybrid tuner I know of except for saa7164, which from what I understand controls the tuners directly. Can a single tuner be used for both digital and analog tuning at the same time? No. However one mode is often used *immediately* after the other. I've seen quite a few race conditions over the years that had to do with closing the v4l2 device and then immediately opening the DVB device (or vice versa). I'm wondering if just having a simple counter would work, with the digital side calling for power just as the capture side should already be doing. If the count is non-zero on a standby call, don't do anything. If it goes to zero, then schedule the HW standby. The challenge would seem to be getting the DVB system to call into the tuner-core (or other proper place). There is a ts_ctrl() callback in the dvb frontend which could be used by the digital side to claim that it's using the tuner. You may also wish to consider this in the context of allowing either side to lock the tuner to prevent callers from attempting to use it in both analog and digital mode simultaneously. This is a huge outstanding problem for hybrid tuners, where applications like MythTV will attempt to use the device in both modes at the same time (thinking they are separate tuners), and the failure to return something like EBUSY to the second caller results in all sorts of undefined behavior. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
On Tue, Jun 19, 2012 at 10:41 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 19-06-2012 10:31, halli manjunatha escreveu:
Hi Mauro,
Please take the Patch-set 7 which I submitted by removing my set_band
implementation (as per Hans V suggestion).
https://lkml.org/lkml/2012/5/21/294
Manju,
That doesn't solve the issue.
As I pointed on my previous email, the ranges aren't consistent among the
radio devices. The best, IMHO, would be to use several g/s_tuner ranges,
one for each supported one.
An alternative would be to write a set of ioctls specific for radio that
would do the same that g/s_tuner does at radio-cadet, but, IMHO, this is
is overdesign.
In any case, we should not apply a patch for it without having a consensus
about the right way.
I agree with you that we should not apply a patch till we come to a
conclusion about the design.
But the patches which I have sent (PATCH-SET 7) that doesn't deal with
FM band selection, instead it adds
few other features like below
1) FM RX RDS AF turn ON/OFF
2) FM RX De-Emphasis mode set/get
3) FM TX Alternate Frequency set/get
So since these are other features which are not related to Band
selection I think you can merge these to K3.6 kernel.
Regards,
Mauro
Regards
Manju
On Tue, Jun 19, 2012 at 7:36 AM, Hans de Goede hdego...@redhat.com wrote:
Hi,
On 06/19/2012 01:09 PM, Mauro Carvalho Chehab wrote:
Em 19-06-2012 05:27, Hans de Goede escreveu:
Hi,
On 06/19/2012 02:47 AM, Mauro Carvalho Chehab wrote:
Em 28-05-2012 07:46, Hans Verkuil escreveu:
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Hans de Goede hdego...@redhat.com
---
include/linux/videodev2.h | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 2339678..013ee46 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2023,7 +2023,8 @@ struct v4l2_tuner {
__u32 audmode;
__s32 signal;
__s32 afc;
- __u32 reserved[4];
+ __u32 band;
+ __u32 reserved[3];
};
struct v4l2_modulator {
@@ -2033,7 +2034,8 @@ struct v4l2_modulator {
__u32 rangelow;
__u32 rangehigh;
__u32 txsubchans;
- __u32 reserved[4];
+ __u32 band;
+ __u32 reserved[3];
};
/* Flags for the 'capability' field */
@@ -2048,6 +2050,11 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS 0x0080
#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200
+#define V4L2_TUNER_CAP_BAND_FM_EUROPE_US 0x0001
+#define V4L2_TUNER_CAP_BAND_FM_JAPAN 0x0002
+#define V4L2_TUNER_CAP_BAND_FM_RUSSIAN 0x0004
+#define V4L2_TUNER_CAP_BAND_FM_WEATHER 0x0008
+#define V4L2_TUNER_CAP_BAND_AM_MW 0x0010
Frequency band is already specified by rangelow/rangehigh.
Why do you need to duplicate this information?
Because radio tuners may support multiple non overlapping
bands, this is why this patch also adds a band member
to the tuner struct, which can be used to set/get
the current band.
One example of this are the tea5757 / tea5759
radio tuner chips:
FM:
tea5757 87.5 - 108 MHz
rangelow = 87.5 * 62500;
rangehigh = 108 * 62500;
tea5759 76 - 91 MHz
rangelow = 76 * 62500;
rangehigh = 91 * 62500;
AM:
Both: 530 - 1710 kHz
rangelow = 0.530 * 62500;
rangehigh = 0.1710 * 62500;
See radio-cadet.c:
static int vidioc_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *v)
{
struct cadet *dev = video_drvdata(file);
v-type = V4L2_TUNER_RADIO;
switch (v-index) {
case 0:
strlcpy(v-name, FM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS
|
V4L2_TUNER_CAP_RDS_BLOCK_IO;
v-rangelow = 1400; /* 87.5 MHz */
v-rangehigh = 1728; /* 108.0 MHz */
v-rxsubchans = cadet_getstereo(dev);
switch (v-rxsubchans) {
case V4L2_TUNER_SUB_MONO:
v-audmode = V4L2_TUNER_MODE_MONO;
break;
case V4L2_TUNER_SUB_STEREO:
v-audmode = V4L2_TUNER_MODE_STEREO;
break;
default:
break;
}
v-rxsubchans |= V4L2_TUNER_SUB_RDS;
break;
case 1:
strlcpy(v-name, AM, sizeof(v-name));
v-capability = V4L2_TUNER_CAP_LOW;
v-rangelow = 8320;
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Hi, snip long discussion about having a fixed set of bands versus a way to enumerate bands, including their rangelow, rangehigh and capabilities Ok, you've convinced me. I agree that having a way to actually enumerate ranges, rather then having a fixed set of ranges, is better. Which brings us back many weeks to the proposal for making it possible to enumerate bands on radio devices. Rather then digging up the old mails lets start anew, I propose the following API for this: 1. A radio device can have multiple tuners, but only 1 can be active (streaming audio to the associated audio input) at the same time. 2. Radio device tuners are enumerated by calling G_TUNER with an increasing index until EINVAL gets returned 3. G_FREQUENCY will always return the frequency and index of the currently active tuner 4. When calling S_TUNER on a radio device, the active tuner will be set to the v4l2_tuner index field 5. When calling S_FREQUENCY on a radio device, the active tuner will be set to the v4l2_frequency tuner field 6. On a G_TUNER call on a radio device the rxsubchans, audmode, signal and afc v4l2_tuner fields are only filled on for the active tuner (as returned by G_FREQUENCY) for inactive tuners these fields are reported as 0. This is pretty close to what the cadet driver currently does, the differences are point 5 and 6, currently wrt point 5 the cadet driver just ignores the tuner field, and wrt point 6 it always tries to fill in these fields, reporting ie the FM signal strength when the FM tuner is active as signal for the AM tuner too. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Hi, On 06/19/2012 06:47 PM, Hans de Goede wrote: Hi, snip long discussion about having a fixed set of bands versus a way to enumerate bands, including their rangelow, rangehigh and capabilities Ok, you've convinced me. I agree that having a way to actually enumerate ranges, rather then having a fixed set of ranges, is better. Which brings us back many weeks to the proposal for making it possible to enumerate bands on radio devices. Rather then digging up the old mails lets start anew, I propose the following API for this: 1. A radio device can have multiple tuners, but only 1 can be active (streaming audio to the associated audio input) at the same time. 2. Radio device tuners are enumerated by calling G_TUNER with an increasing index until EINVAL gets returned 3. G_FREQUENCY will always return the frequency and index of the currently active tuner 4. When calling S_TUNER on a radio device, the active tuner will be set to the v4l2_tuner index field 5. When calling S_FREQUENCY on a radio device, the active tuner will be set to the v4l2_frequency tuner field 6. On a G_TUNER call on a radio device the rxsubchans, audmode, signal and afc v4l2_tuner fields are only filled on for the active tuner (as returned by G_FREQUENCY) for inactive tuners these fields are reported as 0. p.s. I forgot: 7. When calling VIDIOC_S_HW_FREQ_SEEK on a radio device, the active tuner will be set to the v4l2_hw_freq_seek tuner field 8. When changing the active tuner with S_TUNER or S_HW_FREQ_SEEK, the current frequency may be changed to fit in the range of the new active tuner 9. For backwards compatibility reasons tuner 0 should be the tuner with the broadest possible FM range Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
On Tue, Jun 19, 2012 at 12:33 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 06/19/2012 06:47 PM, Hans de Goede wrote: Hi, snip long discussion about having a fixed set of bands versus a way to enumerate bands, including their rangelow, rangehigh and capabilities Ok, you've convinced me. I agree that having a way to actually enumerate ranges, rather then having a fixed set of ranges, is better. Which brings us back many weeks to the proposal for making it possible to enumerate bands on radio devices. Rather then digging up the old mails lets start anew, I propose the following API for this: 1. A radio device can have multiple tuners, but only 1 can be active (streaming audio to the associated audio input) at the same time. 2. Radio device tuners are enumerated by calling G_TUNER with an increasing index until EINVAL gets returned 3. G_FREQUENCY will always return the frequency and index of the currently active tuner 4. When calling S_TUNER on a radio device, the active tuner will be set to the v4l2_tuner index field 5. When calling S_FREQUENCY on a radio device, the active tuner will be set to the v4l2_frequency tuner field 6. On a G_TUNER call on a radio device the rxsubchans, audmode, signal and afc v4l2_tuner fields are only filled on for the active tuner (as returned by G_FREQUENCY) for inactive tuners these fields are reported as 0. p.s. I forgot: 7. When calling VIDIOC_S_HW_FREQ_SEEK on a radio device, the active tuner will be set to the v4l2_hw_freq_seek tuner field 8. When changing the active tuner with S_TUNER or S_HW_FREQ_SEEK, the current frequency may be changed to fit in the range of the new active tuner 9. For backwards compatibility reasons tuner 0 should be the tuner with the broadest possible FM range So with this approach every time during S_FREQ/S_HW_SEEK/S_TUNER driver will check which tuner mode it is set to and change the tuner mode (or band) according to tuner field. So in my case I will have to support 5 tuner modes (EUROPE, JAPAN, RUSSIAN, WEATHER and DEFAULT) just like bands. This approach looks good to me. Regards, Hans -- Regards Halli -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
On 19/06/12 19:33, Hans de Goede wrote: Hi, On 06/19/2012 06:47 PM, Hans de Goede wrote: Hi, snip long discussion about having a fixed set of bands versus a way to enumerate bands, including their rangelow, rangehigh and capabilities Ok, you've convinced me. I agree that having a way to actually enumerate ranges, rather then having a fixed set of ranges, is better. Which brings us back many weeks to the proposal for making it possible to enumerate bands on radio devices. Rather then digging up the old mails lets start anew, I propose the following API for this: 1. A radio device can have multiple tuners, but only 1 can be active (streaming audio to the associated audio input) at the same time. 2. Radio device tuners are enumerated by calling G_TUNER with an increasing index until EINVAL gets returned 3. G_FREQUENCY will always return the frequency and index of the currently active tuner 4. When calling S_TUNER on a radio device, the active tuner will be set to the v4l2_tuner index field 5. When calling S_FREQUENCY on a radio device, the active tuner will be set to the v4l2_frequency tuner field 6. On a G_TUNER call on a radio device the rxsubchans, audmode, signal and afc v4l2_tuner fields are only filled on for the active tuner (as returned by G_FREQUENCY) for inactive tuners these fields are reported as 0. p.s. I forgot: 7. When calling VIDIOC_S_HW_FREQ_SEEK on a radio device, the active tuner will be set to the v4l2_hw_freq_seek tuner field 8. When changing the active tuner with S_TUNER or S_HW_FREQ_SEEK, the current frequency may be changed to fit in the range of the new active tuner 9. For backwards compatibility reasons tuner 0 should be the tuner with the broadest possible FM range I need to think about all these proposals. I know that when I worked with the cadet driver I didn't like those multiple tuners at all. But I need to read up on these new discussions and think about it. I doubt I'll have time tomorrow, so it's probably going to be Thursday or Friday. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue Jun 19 19:00:25 CEST 2012 git hash:5472d3f17845c4398c6a510b46855820920c2181 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: WARNINGS apps: ERRORS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 PATCH 4/6] videodev2.h: add frequency band information.
Hi, On 06/19/2012 07:43 PM, halli manjunatha wrote: On Tue, Jun 19, 2012 at 12:33 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 06/19/2012 06:47 PM, Hans de Goede wrote: Hi, snip long discussion about having a fixed set of bands versus a way to enumerate bands, including their rangelow, rangehigh and capabilities Ok, you've convinced me. I agree that having a way to actually enumerate ranges, rather then having a fixed set of ranges, is better. Which brings us back many weeks to the proposal for making it possible to enumerate bands on radio devices. Rather then digging up the old mails lets start anew, I propose the following API for this: 1. A radio device can have multiple tuners, but only 1 can be active (streaming audio to the associated audio input) at the same time. 2. Radio device tuners are enumerated by calling G_TUNER with an increasing index until EINVAL gets returned 3. G_FREQUENCY will always return the frequency and index of the currently active tuner 4. When calling S_TUNER on a radio device, the active tuner will be set to the v4l2_tuner index field 5. When calling S_FREQUENCY on a radio device, the active tuner will be set to the v4l2_frequency tuner field 6. On a G_TUNER call on a radio device the rxsubchans, audmode, signal and afc v4l2_tuner fields are only filled on for the active tuner (as returned by G_FREQUENCY) for inactive tuners these fields are reported as 0. p.s. I forgot: 7. When calling VIDIOC_S_HW_FREQ_SEEK on a radio device, the active tuner will be set to the v4l2_hw_freq_seek tuner field 8. When changing the active tuner with S_TUNER or S_HW_FREQ_SEEK, the current frequency may be changed to fit in the range of the new active tuner 9. For backwards compatibility reasons tuner 0 should be the tuner with the broadest possible FM range So with this approach every time during S_FREQ/S_HW_SEEK/S_TUNER driver will check which tuner mode it is set to and change the tuner mode (or band) according to tuner field. So in my case I will have to support 5 tuner modes (EUROPE, JAPAN, RUSSIAN, WEATHER and DEFAULT) just like bands. Correct. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cron job: media_tree daily build: ERRORS: help needed
Hans, I've: [peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c linux-3.4.3/scripts/mod/file2alias.c And found: 727a840 ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry); This line only exists on 3.4.3 version of file2alias.c. Isn't this why it successfully compile with newer Kernel? []'s Peter On Tue, Jun 19, 2012 at 11:03 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Tue 19 June 2012 14:50:09 Ezequiel Garcia wrote: Hi Hans, On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, Yesterday I upgraded the gcc version I use to compile the daily build to 4.7.1. This causes very strange errors when compiling 2.6.39 - 3.3: FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a modulo of the size of section __mod_i2c_device_table=18. Fix definition of struct i2c_device_id in mod_devicetable.h This error does not appear when compiling with gcc 4.6.3, and I see absolutely nothing wrong with mod_devicetable.h. I tried very hard to figure out what is going on and why older and newer kernels are not affected, but I still have no idea. The error itself it reported by scripts/mod/file2alias.c. I can suppress that error but that will just lead to a modpost crash later in the compile process. The tuner.o file always causes this. Commenting tuner.o in the Makefile will cause the same problems in other modules (cafe_ccic), but there are also i2c modules that compile just fine. Does anyone have an insight into this? Did something magical change in kernel 3.4 that fixed this? Perhaps this thread could be useful: https://lkml.org/lkml/2012/6/15/323 Yeah, I read that as well. But there there is a clear change that caused the problem. As far as I can tell include/linux/mod_devicetable.h has identical i2c_device_id structs for linux-3.0/1/2/3/4, yet all compile fine with gcc-4.6.3, but for gcc-4.7.1 only linux-3.4 compiles. I'm stumped. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Peter Senna Tschudin peter.se...@gmail.com gpg id: 48274C36 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cron job: media_tree daily build: ERRORS: help needed
Full diff: http://pastebin.com/BJS2EXcH On Tue, Jun 19, 2012 at 4:39 PM, Peter Senna Tschudin peter.se...@gmail.com wrote: Hans, I've: [peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c linux-3.4.3/scripts/mod/file2alias.c And found: 727a840 ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry); This line only exists on 3.4.3 version of file2alias.c. Isn't this why it successfully compile with newer Kernel? []'s Peter On Tue, Jun 19, 2012 at 11:03 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Tue 19 June 2012 14:50:09 Ezequiel Garcia wrote: Hi Hans, On Tue, Jun 19, 2012 at 3:34 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi all, Yesterday I upgraded the gcc version I use to compile the daily build to 4.7.1. This causes very strange errors when compiling 2.6.39 - 3.3: FATAL: media_build/v4l/tuner: sizeof(struct i2c_device_id)=32 is not a modulo of the size of section __mod_i2c_device_table=18. Fix definition of struct i2c_device_id in mod_devicetable.h This error does not appear when compiling with gcc 4.6.3, and I see absolutely nothing wrong with mod_devicetable.h. I tried very hard to figure out what is going on and why older and newer kernels are not affected, but I still have no idea. The error itself it reported by scripts/mod/file2alias.c. I can suppress that error but that will just lead to a modpost crash later in the compile process. The tuner.o file always causes this. Commenting tuner.o in the Makefile will cause the same problems in other modules (cafe_ccic), but there are also i2c modules that compile just fine. Does anyone have an insight into this? Did something magical change in kernel 3.4 that fixed this? Perhaps this thread could be useful: https://lkml.org/lkml/2012/6/15/323 Yeah, I read that as well. But there there is a clear change that caused the problem. As far as I can tell include/linux/mod_devicetable.h has identical i2c_device_id structs for linux-3.0/1/2/3/4, yet all compile fine with gcc-4.6.3, but for gcc-4.7.1 only linux-3.4 compiles. I'm stumped. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Peter Senna Tschudin peter.se...@gmail.com gpg id: 48274C36 -- Peter Senna Tschudin peter.se...@gmail.com gpg id: 48274C36 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cron job: media_tree daily build: ERRORS: help needed
On Tue, Jun 19, 2012 at 4:39 PM, Peter Senna Tschudin peter.se...@gmail.com wrote: Hans, I've: [peter@ace tmp]$ diff linux-2.6.35.13/scripts/mod/file2alias.c linux-3.4.3/scripts/mod/file2alias.c And found: 727a840 ADD_TO_DEVTABLE(i2c, struct i2c_device_id, do_i2c_entry); FWIW, that macro was added on commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e49ce14150c64b29a8dd211df785576fa19a9858 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 02/15] Documentation: media: description of DMABUF importing in V4L2
Hi Thomas,
Thanks for the patch.
On Thursday 14 June 2012 15:37:36 Tomasz Stanislawski wrote:
This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: linux-...@vger.kernel.org
I just have a couple of minor comments, after taking them into account you can
add
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/media/v4l/compat.xml |4 +
Documentation/DocBook/media/v4l/io.xml | 179 +
.../DocBook/media/v4l/vidioc-create-bufs.xml |3 +-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 15 ++
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 ++---
5 files changed, 225 insertions(+), 23 deletions(-)
[snip]
diff --git a/Documentation/DocBook/media/v4l/io.xml
b/Documentation/DocBook/media/v4l/io.xml index fd6aca2..f55b0ab 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
[snip]
+example
+ titleInitiating streaming I/O with DMABUF file descriptors/title
+
+ programlisting
+v4l2-requestbuffers; reqbuf;
+
+memset (amp;reqbuf, 0, sizeof (reqbuf));
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+reqbuf.memory = V4L2_MEMORY_DMABUF;
You need to set reqbuf.count to a non-zero value.
+
+if (ioctl (fd, VIDIOC-REQBUFS;, amp;reqbuf) == -1) {
+ if (errno == EINVAL)
+ printf (Video capturing or DMABUF streaming is not
supported\n);
+ else
+ perror (VIDIOC_REQBUFS);
+
+ exit (EXIT_FAILURE);
+}
+ /programlisting
+/example
+
+paraBuffer (plane) file is passed on the fly with the VIDIOC-QBUF;
s/file/file descriptor/
+ioctl. In case of multiplanar buffers, every plane can be associated with a
+different DMABUF descriptor.Although buffers are commonly cycled,
s/descriptor./descriptor. /
applications +can pass different DMABUF descriptor at each
s/pass/pass a/
constantVIDIOC_QBUF/constant +call./para
+
+example
+ titleQueueing DMABUF using single plane API/title
+
+ programlisting
+int buffer_queue(int v4lfd, int index, int dmafd)
+{
+ v4l2-buffer; buf;
+
+ memset(amp;buf, 0, sizeof buf);
+ buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ buf.memory = V4L2_MEMORY_DMABUF;
+ buf.index = index;
+ buf.m.fd = dmafd;
+
+ if (ioctl (v4lfd, VIDIOC-QBUF;, amp;buf) == -1) {
+ perror (VIDIOC_QBUF);
+ return -1;
+ }
+
+ return 0;
+}
+ /programlisting
+/example
+
+example
+ titleQueueing DMABUF using multi plane API/title
+
+ programlisting
+int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes)
+{
+ v4l2-buffer; buf;
+ v4l2-plane; planes[VIDEO_MAX_PLANES];
+ int i;
+
+ memset(amp;buf, 0, sizeof buf);
+ buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+ buf.memory = V4L2_MEMORY_DMABUF;
+ buf.index = index;
+ buf.m.planes = planes;
+ buf.length = n_planes;
+
+ memset(amp;planes, 0, sizeof planes);
+
+ for (i = 0; i lt; n_planes; ++i)
+ buf.m.planes[i].m.fd = dmafd[i];
+
+ if (ioctl (v4lfd, VIDIOC-QBUF;, amp;buf) == -1) {
+ perror (VIDIOC_QBUF);
+ return -1;
+ }
+
+ return 0;
+}
+ /programlisting
+/example
+
+paraFilled or displayed buffers are dequeued with the
+VIDIOC-DQBUF; ioctl. The driver can unlock the buffer at any
+time between the completion of the DMA and this ioctl. The memory is
+also unlocked when VIDIOC-STREAMOFF; is called, VIDIOC-REQBUFS;, or
+when the device is closed./para
+
+paraFor capturing applications it is customary to enqueue a
+number of empty buffers, to start capturing and enter the read loop.
+Here the application waits until a filled buffer can be dequeued, and
+re-enqueues the buffer when the data is no longer needed. Output
+applications fill and enqueue buffers, when enough buffers are stacked
+up output is started. In the write loop, when the application
+runs out of free buffers it must wait until an empty buffer can be
+dequeued and reused. Two methods exist to suspend execution of the
+application until one or more buffers can be dequeued. By default
+constantVIDIOC_DQBUF/constant blocks when no buffer is in the
+outgoing queue. When the constantO_NONBLOCK/constant flag was
+given to the func-open; function, constantVIDIOC_DQBUF/constant
+returns immediately with an EAGAIN; when no buffer is available. The
+func-select; or func-poll; function are always available./para
+
+paraTo start and stop capturing or output applications call the
+VIDIOC-STREAMON; and VIDIOC-STREAMOFF; ioctls. Note that
+constantVIDIOC_STREAMOFF/constant removes all buffers from both queues
and +unlocks all buffers as a side
Re: uvcvideo issue with kernel 3.5-rc2 and 3
On 18 June 2012 12:41, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: This might be cause by a bug in the USB core or in the UVC driver. Would you be able to bisect the regression ? Are you aware of any tool to bisect such issues using kvm/virtualbox/..? I would like to bisect the issue but rebooting the system needs to be avoided. Or, alternatively, test the v3.4 uvcvideo driver on v3.5-rc3 ? Or the other way around, test the latest v4l tree on v3.4 (instructions regarding how to compile the v4l tree with a different kernel are available at http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L- DVB_Device_Drivers). I compiled the 3.4 module with 3.5-rc3. The error is still the same using usb2. I tried to connect the camera to an usb3 port and it worked as it should. -- The issue seems to be related to usb2 then. I'll inform the usb guys. Regards, Philipp Dreimann -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 10/15] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator
Hi Tomasz,
Thanks for the patch.
On Thursday 14 June 2012 15:37:44 Tomasz Stanislawski wrote:
From: Marek Szyprowski m.szyprow...@samsung.com
Add prepare/finish callbacks to vb2-dma-contig allocator.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf2-dma-contig.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c index 94f0874..f9286d7 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -103,6 +103,28 @@ static unsigned int vb2_dc_num_users(void *buf_priv)
return atomic_read(buf-refcount);
}
+static void vb2_dc_prepare(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+ struct sg_table *sgt = buf-dma_sgt;
+
+ if (!sgt)
+ return;
+
+ dma_sync_sg_for_device(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
+}
+
+static void vb2_dc_finish(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+ struct sg_table *sgt = buf-dma_sgt;
+
+ if (!sgt)
+ return;
+
+ dma_sync_sg_for_cpu(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
+}
+
/*/
/*callbacks for MMAP buffers */
/*/
@@ -369,6 +391,8 @@ const struct vb2_mem_ops vb2_dma_contig_memops = {
.mmap = vb2_dc_mmap,
.get_userptr= vb2_dc_get_userptr,
.put_userptr= vb2_dc_put_userptr,
+ .prepare= vb2_dc_prepare,
+ .finish = vb2_dc_finish,
.num_users = vb2_dc_num_users,
};
EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 12/15] v4l: vb2-vmalloc: add support for dmabuf importing
Hi Tomasz, Thanks for the patch. On Thursday 14 June 2012 15:37:46 Tomasz Stanislawski wrote: This patch adds support for importing DMABUF files for vmalloc allocator in Videobuf2. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 06/15] v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
Hi Tomasz,
Thanks for the patch.
On Thursday 14 June 2012 15:37:40 Tomasz Stanislawski wrote:
This patch removes a reference to alloc_ctx from an instance of a DMA
contiguous buffer. It helps to avoid a risk of a dangling pointer if the
context is released while the buffer is still valid.
Can this really happen ? All drivers except marvell-ccic seem to call
vb2_dma_contig_cleanup_ctx() in their remove handler and probe cleanup path
only. Freeing the context while buffers are still around would be a driver
bug, and I expect drivers to destroy the queue in that case anyway.
This being said, removing the dereference step is a good idea, so I think the
patch should be applied, possibly with a different commit message.
Moreover it removes one
dereference step while accessing a device structure.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf2-dma-contig.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c index a05784f..20c95da 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -23,7 +23,7 @@ struct vb2_dc_conf {
};
struct vb2_dc_buf {
- struct vb2_dc_conf *conf;
+ struct device *dev;
void*vaddr;
dma_addr_t dma_addr;
unsigned long size;
@@ -37,22 +37,21 @@ static void vb2_dc_put(void *buf_priv);
static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
{
struct vb2_dc_conf *conf = alloc_ctx;
+ struct device *dev = conf-dev;
struct vb2_dc_buf *buf;
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
- buf-vaddr = dma_alloc_coherent(conf-dev, size, buf-dma_addr,
- GFP_KERNEL);
+ buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
if (!buf-vaddr) {
- dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n,
- size);
+ dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
- buf-conf = conf;
+ buf-dev = dev;
buf-size = size;
buf-handler.refcount = buf-refcount;
@@ -69,7 +68,7 @@ static void vb2_dc_put(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
if (atomic_dec_and_test(buf-refcount)) {
- dma_free_coherent(buf-conf-dev, buf-size, buf-vaddr,
+ dma_free_coherent(buf-dev, buf-size, buf-vaddr,
buf-dma_addr);
kfree(buf);
}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 00/15] Integration of videobuf2 with dmabuf
Hi Tomasz, On Thursday 14 June 2012 15:37:34 Tomasz Stanislawski wrote: Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. This patchset depends on new scatterlist constructor [5]. There are very few remaining issues with the patch set, I think the next iteration will be the right one. [snip] [5] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/47983 What's the status of that patch ? Is it ready for v3.6 ? I'd like to see DMABUF import support in V4L2 in v3.6. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] usb: gadget/uvc: Add support for 'USB_GADGET_DELAYED_STATUS' response for a set_intf(alt-set 1) command
Hi Bhupesh,
Thanks for the patch, and sorry for the late reply.
On Friday 01 June 2012 15:08:58 Bhupesh Sharma wrote:
This patch adds the support in UVC webcam gadget design for providing
USB_GADGET_DELAYED_STATUS in response to a set_interface(alt setting 1)
command issue by the Host.
The current UVC webcam gadget design generates a STREAMON event
corresponding to a set_interface(alt setting 1) command from the Host. This
STREAMON event will eventually be routed to a real V4L2 device.
To start video streaming, it may be required to perform some register writes
to a camera sensor device over slow external busses like I2C or SPI. So, it
makes sense to ensure that we delay the STATUS stage of the
set_interface(alt setting 1) command.
Otherwise, a lot of ISOC IN tokens sent by the Host will be replied to by
zero-length packets by the webcam device. On certain Hosts this may even
lead to ISOC URBs been cancelled from the Host side.
So, as soon as we finish doing all the streaming related stuff on the real
V4L2 device, we call a STREAMON ioctl on the UVC side and from here we call
the 'usb_composite_setup_continue' function to complete the status stage of
the set_interface(alt setting 1) command.
That sounds good, thank you for coming up with a solution to this issue.
Further, we need to ensure that we queue no video buffers on the UVC webcam
gadget, until we de-queue a video buffer from the V4L2 device. Also, we need
to enable UVC video related stuff at the first QBUF ioctl call itself, as
the application will call the STREAMON on UVC side only when it has
dequeued sufficient buffers from the V4L2 side and queued them to the UVC
gadget. So, the UVC video enable stuff cannot be done in STREAMON ioctl
call.
Is that really required ? First of all, the userspace application can queue
buffers before it calls VIDIOC_STREAMON. Assuming it doesn't, the gadget
driver calls uvc_video_enable() at streamon time, which then calls
uvc_video_pump(). As no buffer is queued, the function will return without
queuing any USB request, so we shouldn't have any problem.
For the same we add two more UVC states:
- PRE_STREAMING : not even a single buffer has been queued to UVC
- BUF_QUEUED_STREAMING_OFF : one video buffer has been queued to UVC
but we have not yet enabled STREAMING on UVC side.
Signed-off-by: Bhupesh Sharma bhupesh.sha...@st.com
---
drivers/usb/gadget/f_uvc.c| 17 -
drivers/usb/gadget/uvc.h |3 +++
drivers/usb/gadget/uvc_v4l2.c | 38 --
3 files changed, 51 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 2a8bf06..3589ed0 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -272,6 +272,13 @@ uvc_function_setup(struct usb_function *f, const struct
usb_ctrlrequest *ctrl) return 0;
}
+void uvc_function_setup_continue(struct uvc_device *uvc)
+{
+ struct usb_composite_dev *cdev = uvc-func.config-cdev;
+
+ usb_composite_setup_continue(cdev);
+}
+
static int
uvc_function_get_alt(struct usb_function *f, unsigned interface)
{
@@ -334,7 +341,8 @@ uvc_function_set_alt(struct usb_function *f, unsigned
interface, unsigned alt) v4l2_event_queue(uvc-vdev, v4l2_event);
uvc-state = UVC_STATE_CONNECTED;
- break;
+
+ return 0;
case 1:
if (uvc-state != UVC_STATE_CONNECTED)
@@ -352,14 +360,13 @@ uvc_function_set_alt(struct usb_function *f, unsigned
interface, unsigned alt) v4l2_event.type = UVC_EVENT_STREAMON;
v4l2_event_queue(uvc-vdev, v4l2_event);
- uvc-state = UVC_STATE_STREAMING;
- break;
+ uvc-state = UVC_STATE_PRE_STREAMING;
+
+ return USB_GADGET_DELAYED_STATUS;
default:
return -EINVAL;
}
-
- return 0;
}
static void
diff --git a/drivers/usb/gadget/uvc.h b/drivers/usb/gadget/uvc.h
index d78ea25..6cd1435 100644
--- a/drivers/usb/gadget/uvc.h
+++ b/drivers/usb/gadget/uvc.h
@@ -141,6 +141,8 @@ enum uvc_state
{
UVC_STATE_DISCONNECTED,
UVC_STATE_CONNECTED,
+ UVC_STATE_PRE_STREAMING,
+ UVC_STATE_BUF_QUEUED_STREAMING_OFF,
UVC_STATE_STREAMING,
};
@@ -190,6 +192,7 @@ struct uvc_file_handle
* Functions
*/
+extern void uvc_function_setup_continue(struct uvc_device *uvc);
extern void uvc_endpoint_stream(struct uvc_device *dev);
extern void uvc_function_connect(struct uvc_device *uvc);
diff --git a/drivers/usb/gadget/uvc_v4l2.c b/drivers/usb/gadget/uvc_v4l2.c
index 9c2b45b..5f23571 100644
--- a/drivers/usb/gadget/uvc_v4l2.c
+++ b/drivers/usb/gadget/uvc_v4l2.c
@@ -235,10 +235,36 @@ uvc_v4l2_do_ioctl(struct file *file, unsigned int cmd,
void *arg) }
case VIDIOC_QBUF:
+ /*
+ * Theory of operation:
+
Re: [RFC] Support for 'Coda' video codec IP.
Hi Javier, On Tue, Jun 19, 2012 at 11:11 AM, Javier Martin javier.mar...@vista-silicon.com wrote: This patch adds support for the video encoder present in the i.MX27. It currently support encoding in H.264 and in MPEG4 SP. It's working properly in a Visstrim SM10 platform. It uses V4L2-mem2mem framework. A public git repository is available too: git://github.com/jmartinc/video_visstrim.git I will give it a try and I have some questions: - How did you generate the VPU firmware? - Which userspace application did you use for testing the encoding? Is Gstreamer OK to test it? Thanks, Fabio Estevam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
