Re: Discussion: How to deal with radio tuners which can tune to multiple bands
Hi, Just noticed the following on: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html#id2570531 This specification does not define radio output devices., iow no radio modulators, but we agreed upon making the band changes to the modulator too, and this makes sense because AFAIK we do support radio modulators. I hit this while working on adding support for the proposed API to v4l2-ctl, as I wanted to only print the band stuff for radio type devices, but the modulator struct has no type! 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: Discussion: How to deal with radio tuners which can tune to multiple bands
On Sun May 27 2012 11:06:27 Hans de Goede wrote: Hi, Just noticed the following on: http://linuxtv.org/downloads/v4l-dvb-apis/tuner.html#id2570531 This specification does not define radio output devices., iow no radio modulators, but we agreed upon making the band changes to the modulator too, and this makes sense because AFAIK we do support radio modulators. I hit this while working on adding support for the proposed API to v4l2-ctl, as I wanted to only print the band stuff for radio type devices, but the modulator struct has no type! Regards, Hans Yeah, that section needs to be rewritten. We have no TV modulators at all. If a video/vbi node supports G/S_MODULATOR, then it is a TV modulator. If a radio node supports it, then it is a radio modulator. Even for g/s_freq and g/s_tuner the type field is now determined strictly by the type of the node. It is no longer possible to e.g. query the radio tuner from a video node. It used to be possible (as least in theory) in the past, but that was crazy. 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
[RFCv1 PATCH 0/5] Add hwseek caps and frequency bands.
This patch series adds improved hwseek support as discussed here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg45957.html and on irc: http://linuxtv.org/irc/v4l/index.php?date=2012-05-26 From the RFC I have implemented/documented items 1-4 and 6a. I decided not to go with option 6b. This may be added in the future if there is a clear need. The addition of the frequency band came out of this discussion: http://www.spinics.net/lists/linux-media/msg48272.html 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
[RFCv1 PATCH 1/5] videodev2.h: add new hwseek capability bits.
From: Hans Verkuil hans.verk...@cisco.com
Tell the application whether the hardware seek is bounded and/or wraps around.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/linux/videodev2.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 370d111..2339678 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2039,6 +2039,8 @@ struct v4l2_modulator {
/* Flags for the 'capability' field */
#define V4L2_TUNER_CAP_LOW 0x0001
#define V4L2_TUNER_CAP_NORM0x0002
+#define V4L2_TUNER_CAP_HWSEEK_BOUNDED 0x0004
+#define V4L2_TUNER_CAP_HWSEEK_WRAP 0x0008
#define V4L2_TUNER_CAP_STEREO 0x0010
#define V4L2_TUNER_CAP_LANG2 0x0020
#define V4L2_TUNER_CAP_SAP 0x0020
--
1.7.10
--
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
[RFCv1 PATCH 3/5] S_HW_FREQ_SEEK: set capability flags and return ENODATA instead of EAGAIN.
From: Hans Verkuil hans.verk...@cisco.com
Set the new capability flags in G_TUNER and return ENODATA if no channels
were found.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/radio/radio-mr800.c|5 +++--
drivers/media/radio/radio-wl1273.c |3 ++-
drivers/media/radio/si470x/radio-si470x-common.c |6 --
drivers/media/radio/wl128x/fmdrv_rx.c|2 +-
drivers/media/radio/wl128x/fmdrv_v4l2.c |4 +++-
sound/i2c/other/tea575x-tuner.c |4 +++-
6 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/radio/radio-mr800.c
b/drivers/media/radio/radio-mr800.c
index 94cb6bc..3182b26 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -295,7 +295,8 @@ static int vidioc_g_tuner(struct file *file, void *priv,
v-type = V4L2_TUNER_RADIO;
v-rangelow = FREQ_MIN * FREQ_MUL;
v-rangehigh = FREQ_MAX * FREQ_MUL;
- v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
+ v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
v-rxsubchans = is_stereo ? V4L2_TUNER_SUB_STEREO : V4L2_TUNER_SUB_MONO;
v-audmode = radio-stereo ?
V4L2_TUNER_MODE_STEREO : V4L2_TUNER_MODE_MONO;
@@ -372,7 +373,7 @@ static int vidioc_s_hw_freq_seek(struct file *file, void
*priv,
timeout = jiffies + msecs_to_jiffies(3);
for (;;) {
if (time_after(jiffies, timeout)) {
- retval = -EAGAIN;
+ retval = -ENODATA;
break;
}
if (schedule_timeout_interruptible(msecs_to_jiffies(10))) {
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index f1b6070..e8428f5 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1514,7 +1514,8 @@ static int wl1273_fm_vidioc_g_tuner(struct file *file,
void *priv,
tuner-rangehigh = WL1273_FREQ(WL1273_BAND_OTHER_HIGH);
tuner-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_RDS |
- V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS_BLOCK_IO;
+ V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED | V4L2_TUNER_CAP_HWSEEK_WRAP;
if (radio-stereo)
tuner-audmode = V4L2_TUNER_MODE_STEREO;
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 969cf49..d485b79 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -363,7 +363,7 @@ stop:
/* try again, if timed out */
if (retval == 0 timed_out)
- return -EAGAIN;
+ return -ENODATA;
return retval;
}
@@ -596,7 +596,9 @@ static int si470x_vidioc_g_tuner(struct file *file, void
*priv,
strcpy(tuner-name, FM);
tuner-type = V4L2_TUNER_RADIO;
tuner-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
- V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO;
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
/* range limits */
switch ((radio-registers[SYSCONFIG2] SYSCONFIG2_BAND) 6) {
diff --git a/drivers/media/radio/wl128x/fmdrv_rx.c
b/drivers/media/radio/wl128x/fmdrv_rx.c
index 43fb722..3dd9fc0 100644
--- a/drivers/media/radio/wl128x/fmdrv_rx.c
+++ b/drivers/media/radio/wl128x/fmdrv_rx.c
@@ -251,7 +251,7 @@ again:
if (!timeleft) {
fmerr(Timeout(%d sec),didn't get tune ended int\n,
jiffies_to_msecs(FM_DRV_RX_SEEK_TIMEOUT) / 1000);
- return -ETIMEDOUT;
+ return -ENODATA;
}
int_reason = fmdev-irq_info.flag (FM_TUNE_COMPLETE | FM_BAND_LIMIT);
diff --git a/drivers/media/radio/wl128x/fmdrv_v4l2.c
b/drivers/media/radio/wl128x/fmdrv_v4l2.c
index 080b96a..49a11ec 100644
--- a/drivers/media/radio/wl128x/fmdrv_v4l2.c
+++ b/drivers/media/radio/wl128x/fmdrv_v4l2.c
@@ -285,7 +285,9 @@ static int fm_v4l2_vidioc_g_tuner(struct file *file, void
*priv,
tuner-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO |
((fmdev-rx.rds.flag == FM_RDS_ENABLE) ? V4L2_TUNER_SUB_RDS : 0);
tuner-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS |
- V4L2_TUNER_CAP_LOW;
+ V4L2_TUNER_CAP_LOW |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
tuner-audmode = (stereo_mono_mode ?
V4L2_TUNER_MODE_MONO : V4L2_TUNER_MODE_STEREO);
diff --git
[RFCv1 PATCH 4/5] videodev2.h: add frequency band information.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.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_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
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -2065,6 +2072,14 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1 0x0003
#define V4L2_TUNER_MODE_LANG1_LANG20x0004
+/* Values for the 'band' field */
+#define V4L2_TUNER_BAND_DEFAULT 0
+#define V4L2_TUNER_BAND_FM_EUROPE_US 1 /* 87.5 Mhz - 108 MHz */
+#define V4L2_TUNER_BAND_FM_JAPAN 2 /* 76 MHz - 90 MHz */
+#define V4L2_TUNER_BAND_FM_RUSSIAN3 /* 65.8 MHz - 74 MHz */
+#define V4L2_TUNER_BAND_FM_WEATHER4 /* 162.4 MHz - 162.55 MHz */
+#define V4L2_TUNER_BAND_AM_MW 5
+
struct v4l2_frequency {
__u32 tuner;
__u32 type; /* enum v4l2_tuner_type */
--
1.7.10
--
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
[RFCv1 PATCH 5/5] V4L2 spec: add frequency band documentation.
From: Hans Verkuil hans.verk...@cisco.com Based in part on an earlier patch from hallima...@gmail.com. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/common.xml | 28 -- .../DocBook/media/v4l/vidioc-g-modulator.xml | 38 +--- Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 97 +--- .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml|3 +- 4 files changed, 131 insertions(+), 35 deletions(-) diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 4101aeb..4e7082d 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -464,17 +464,18 @@ The structfieldtype/structfield field of the respective structfieldtuner/structfield field contains the index number of the tuner./para - paraRadio devices have exactly one tuner with index zero, no -video inputs./para + paraRadio input devices have one or more tuners, but these are +obviously not associated with any video inputs./para paraTo query and change tuner properties applications use the VIDIOC-G-TUNER; and VIDIOC-S-TUNER; ioctl, respectively. The v4l2-tuner; returned by constantVIDIOC_G_TUNER/constant also contains signal status information applicable when the tuner of the -current video input, or a radio tuner is queried. Note that +current video input or a radio tuner is queried. Note that constantVIDIOC_S_TUNER/constant does not switch the current tuner, when there is more than one at all. The tuner is solely determined by -the current video input. Drivers must support both ioctls and set the +the current video input or by calling VIDIOC-S-FREQUENCY; for radio +tuners. Drivers must support both ioctls and set the constantV4L2_CAP_TUNER/constant flag in the v4l2-capability; returned by the VIDIOC-QUERYCAP; ioctl when the device has one or more tuners./para @@ -491,14 +492,24 @@ the modulator. The structfieldtype/structfield field of the respective v4l2-output; returned by the VIDIOC-ENUMOUTPUT; ioctl is set to constantV4L2_OUTPUT_TYPE_MODULATOR/constant and its structfieldmodulator/structfield field contains the index number -of the modulator. This specification does not define radio output -devices./para +of the modulator./para + + paraRadio output devices have one or more modulators, but these +are obviously not associated with any video outputs./para + + paraA video or radio device cannot support both a tuner and a +modulator. Two separate device nodes will have to be used for such +hardware, one that supports the tuner functionality and one that supports +the modulator functionality. The reason is a limitation with the +VIDIOC-S-FREQUENCY; ioctl where you cannot specify whether the frequency +is for a tuner or a modulator./para paraTo query and change modulator properties applications use the VIDIOC-G-MODULATOR; and VIDIOC-S-MODULATOR; ioctl. Note that constantVIDIOC_S_MODULATOR/constant does not switch the current modulator, when there is more than one at all. The modulator is solely -determined by the current video output. Drivers must support both +determined by the current video output or by calling VIDIOC-S-FREQUENCY; +for radio modulators. Drivers must support both ioctls and set the constantV4L2_CAP_MODULATOR/constant flag in the v4l2-capability; returned by the VIDIOC-QUERYCAP; ioctl when the device has one or more modulators./para @@ -511,8 +522,7 @@ device has one or more modulators./para applications use the VIDIOC-G-FREQUENCY; and VIDIOC-S-FREQUENCY; ioctl which both take a pointer to a v4l2-frequency;. These ioctls are used for TV and radio devices alike. Drivers must support both -ioctls when the tuner or modulator ioctls are supported, or -when the device is a radio device./para +ioctls when the tuner or modulator ioctls are supported./para /section /section diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml index 7f4ac7e..713ba06 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml @@ -68,17 +68,17 @@ to this structure. Drivers fill the rest of the structure or return an applications shall begin at index zero, incrementing by one until the driver returns errorcodeEINVAL/errorcode./para -paraModulators have two writable properties, an audio -modulation set and the radio frequency. To change the modulated audio -subprograms, applications initialize the structfieldindex -/structfield and structfieldtxsubchans/structfield fields and the -structfieldreserved/structfield array and call the -constantVIDIOC_S_MODULATOR/constant ioctl. Drivers may choose a -different audio modulation if the request cannot be satisfied. However -this is a write-only ioctl, it does not return the actual audio +paraModulators have three
[RFCv1 PATCH 2/5] v4l2 spec: document the new v4l2_tuner capabilities
From: Hans Verkuil hans.verk...@cisco.com Update the spec with the new capabilities and specify new error codes for S_HW_FREQ_SEEK. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- .../DocBook/media/v4l/vidioc-g-frequency.xml |6 ++ Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 12 .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml | 18 +++--- 3 files changed, 33 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml index 69c178a..40e58a4 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml @@ -135,6 +135,12 @@ bounds or the value in the structfieldtype/structfield field is wrong./para /listitem /varlistentry + varlistentry + termerrorcodeEBUSY/errorcode/term + listitem + paraA hardware seek is in progress./para + /listitem + /varlistentry /variablelist /refsect1 /refentry diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index 62a1aa2..95d5371 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -276,6 +276,18 @@ can or must be switched. (B/G PAL tuners for example are typically not constantV4L2_TUNER_ANALOG_TV/constant tuners can have this capability./entry /row row + entryconstantV4L2_TUNER_CAP_HWSEEK_BOUNDED/constant/entry + entry0x0004/entry + entryIf set, then this tuner supports the hardware seek functionality + where the seek stops when it reaches the end of the frequency range./entry + /row + row + entryconstantV4L2_TUNER_CAP_HWSEEK_WRAP/constant/entry + entry0x0008/entry + entryIf set, then this tuner supports the hardware seek functionality + where the seek wraps around when it reaches the end of the frequency range./entry + /row + row entryconstantV4L2_TUNER_CAP_STEREO/constant/entry entry0x0010/entry entryStereo audio reception is supported./entry diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index 407dfce..d58b648 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -58,6 +58,9 @@ To do this applications initialize the structfieldtuner/structfield, call the constantVIDIOC_S_HW_FREQ_SEEK/constant ioctl with a pointer to this structure./para +paraIf an error is returned, then the frequency original frequency will +be restored./para + paraThis ioctl is supported if the constantV4L2_CAP_HW_FREQ_SEEK/constant capability is set./para table pgwide=1 frame=none id=v4l2-hw-freq-seek @@ -87,7 +90,10 @@ field and the v4l2-tuner; structfieldindex/structfield field./entry row entry__u32/entry entrystructfieldwrap_around/structfield/entry - entryIf non-zero, wrap around when at the end of the frequency range, else stop seeking./entry + entryIf non-zero, wrap around when at the end of the frequency range, else stop seeking. + The v4l2-tuner; structfieldcapability/structfield field will tell you what the + hardware supports. + /entry /row row entry__u32/entry @@ -118,9 +124,15 @@ wrong./para /listitem /varlistentry varlistentry - termerrorcodeEAGAIN/errorcode/term + termerrorcodeENODATA/errorcode/term + listitem + paraThe hardware seek found no channels./para + /listitem + /varlistentry + varlistentry + termerrorcodeEBUSY/errorcode/term listitem - paraThe ioctl timed-out. Try again./para + paraAnother hardware seek is already in progress./para /listitem /varlistentry /variablelist -- 1.7.10 -- 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: DVB USB: change USB stream settings dynamically
On 26.05.2012 01:47, Antti Palosaari wrote: I was planning make DVB USB be able to switch USB streaming parameters dynamically. I mean [struct usb_data_stream_properties] parameters. Currently it reserves USB streaming buffers when device is plugged. Own buffer is reserved for each frontend, which means currently 1-3 streaming buffers depending on device. Basically I see USB TS as a DVB USB device property - not property of frontend. USB TS is interface between computer and USB-bridge and amount of parallel USB TS or TS configurations depends on USB-bridge capabilities. Sometimes used USB TS could be configured to fit better used stream. Smaller buffers for the narrow radio stream and biggest buffers for the wide DVB-S2 stream. I was wondering how to resolve that situation? It is not very big problem currently but I still want to make it better as there is surely coming new devices that needs better control for the USB streaming parameters. Currently there is mxl111sf driver which seems to offer 6 different streaming configurations but AFAIK only three is currently used as there is 3 frontends and each one has own streaming parameters - and buffers - even only one can be used at the time. 1. Configure streaming parameters (alloc buffers) every time when streaming is started? IIRC that causes some problems lately for em28xx as memory goes dis-coherent and buffers cannot allocated. 2. Allocate buffers (streaming configuration) for all needed device use configurations at very beginning. Then add some logic to map streaming config to frontend at runtime. That is quite near what mxl111sf does currently. After looking existing code carefully and doing some tests I think I will implement that a way it changes buffers at runtime to fit current needs. int usb_urb_submit(struct usb_data_stream *stream) is called when streaming is started. At that point it is possible to compare already reserved buffers and buffers needed. If needed buffers are larger it is possible to reallocate bigger buffers. Of course it is not needed to decrease buffers even smaller stream configurations is asked, just to avoid repetitive allocations of large chunks of coherent memory. 1) allocate buffers at the init as now (callback to read stream properties from the driver) 2) re-allocate bigger buffers in runtime if needed (callback to read stream properties from the driver) 3) free all buffers when device is disconnected Basically those USB buffers are type of (buffer count) x (buffer size). Buffer count is same as used count of URBs, typically ~5, and buffer size is the payload size of one URB. Here is some background info (em28xx buffer alloc failures) why to avoid continuous buffer allocs / frees. http://www.spinics.net/lists/linux-media/msg44209.html regards Antti -- http://palosaari.fi/ -- 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: [GIT PULL for v3.5-rc1] media updates for v3.5
Em 25-05-2012 19:38, Stefan Richter escreveu: On May 25 Mauro Carvalho Chehab wrote: A simple way to solve it seems to make those options dependent on CONFIG_EXPERT. Not sure if all usual distributions disable it, but I guess most won't have EXPERT enabled. The enclosed patch does that. If nobody complains, I'll submit it together with the next git pull request. I only want dvb-core and firedtv. But when I switch off CONFIG_MEDIA_TUNER_CUSTOMISE, suddenly also CC [M] drivers/media/common/tuners/tuner-xc2028.o CC [M] drivers/media/common/tuners/tuner-simple.o CC [M] drivers/media/common/tuners/tuner-types.o CC [M] drivers/media/common/tuners/mt20xx.o CC [M] drivers/media/common/tuners/tda8290.o CC [M] drivers/media/common/tuners/tea5767.o CC [M] drivers/media/common/tuners/tea5761.o CC [M] drivers/media/common/tuners/tda9887.o CC [M] drivers/media/common/tuners/tda827x.o CC [M] drivers/media/common/tuners/tda18271-maps.o CC [M] drivers/media/common/tuners/tda18271-common.o CC [M] drivers/media/common/tuners/tda18271-fe.o CC [M] drivers/media/common/tuners/xc5000.o CC [M] drivers/media/common/tuners/xc4000.o CC [M] drivers/media/common/tuners/mc44s803.o LD [M] drivers/media/common/tuners/tda18271.o are built. Why is that? Those are the tuners supported by the tuner_core logic. The tuner_core module is required by all TV drivers that have analog support. After the tuner rework to allow a driver under drivers/media/dvb to use the same tuner module as the ../v4l modules, there are now pure dvb drivers that don't use tune_core. So, it makes sense to add a new config for tuner_core that will be selected only for devices with analog TV support. Regards, Mauro -- 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: [GIT PULL for v3.5-rc1] media updates for v3.5
Em 27-05-2012 11:47, Mauro Carvalho Chehab escreveu: Em 25-05-2012 19:38, Stefan Richter escreveu: On May 25 Mauro Carvalho Chehab wrote: A simple way to solve it seems to make those options dependent on CONFIG_EXPERT. Not sure if all usual distributions disable it, but I guess most won't have EXPERT enabled. The enclosed patch does that. If nobody complains, I'll submit it together with the next git pull request. I only want dvb-core and firedtv. But when I switch off CONFIG_MEDIA_TUNER_CUSTOMISE, suddenly also CC [M] drivers/media/common/tuners/tuner-xc2028.o CC [M] drivers/media/common/tuners/tuner-simple.o CC [M] drivers/media/common/tuners/tuner-types.o CC [M] drivers/media/common/tuners/mt20xx.o CC [M] drivers/media/common/tuners/tda8290.o CC [M] drivers/media/common/tuners/tea5767.o CC [M] drivers/media/common/tuners/tea5761.o CC [M] drivers/media/common/tuners/tda9887.o CC [M] drivers/media/common/tuners/tda827x.o CC [M] drivers/media/common/tuners/tda18271-maps.o CC [M] drivers/media/common/tuners/tda18271-common.o CC [M] drivers/media/common/tuners/tda18271-fe.o CC [M] drivers/media/common/tuners/xc5000.o CC [M] drivers/media/common/tuners/xc4000.o CC [M] drivers/media/common/tuners/mc44s803.o LD [M] drivers/media/common/tuners/tda18271.o are built. Why is that? Those are the tuners supported by the tuner_core logic. The tuner_core module is required by all TV drivers that have analog support. After the tuner rework to allow a driver under drivers/media/dvb to use the same tuner module as the ../v4l modules, there are now pure dvb drivers that don't use tune_core. So, it makes sense to add a new config for tuner_core that will be selected only for devices with analog TV support. The correct fix for it seems to change the Kconfig menu to be like: m Multimedia support --- [ ] Webcams and video grabbers support [ ] Analog TV API and drivers support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support and only select the tuner-core drivers if analog TV is selected. I'll write some RFC patches for it for 3.6, posting them at linux-media. Regards, Mauro -- 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: DVB USB: change USB stream settings dynamically
Hi Antti, Il 27/05/2012 15:10, Antti Palosaari ha scritto: On 26.05.2012 01:47, Antti Palosaari wrote: I was planning make DVB USB be able to switch USB streaming parameters dynamically. I mean [struct usb_data_stream_properties] parameters. Currently it reserves USB streaming buffers when device is plugged. Own buffer is reserved for each frontend, which means currently 1-3 streaming buffers depending on device. Basically I see USB TS as a DVB USB device property - not property of frontend. USB TS is interface between computer and USB-bridge and amount of parallel USB TS or TS configurations depends on USB-bridge capabilities. Sometimes used USB TS could be configured to fit better used stream. Smaller buffers for the narrow radio stream and biggest buffers for the wide DVB-S2 stream. I was wondering how to resolve that situation? It is not very big problem currently but I still want to make it better as there is surely coming new devices that needs better control for the USB streaming parameters. Currently there is mxl111sf driver which seems to offer 6 different streaming configurations but AFAIK only three is currently used as there is 3 frontends and each one has own streaming parameters - and buffers - even only one can be used at the time. 1. Configure streaming parameters (alloc buffers) every time when streaming is started? IIRC that causes some problems lately for em28xx as memory goes dis-coherent and buffers cannot allocated. 2. Allocate buffers (streaming configuration) for all needed device use configurations at very beginning. Then add some logic to map streaming config to frontend at runtime. That is quite near what mxl111sf does currently. After looking existing code carefully and doing some tests I think I will implement that a way it changes buffers at runtime to fit current needs. int usb_urb_submit(struct usb_data_stream *stream) is called when streaming is started. At that point it is possible to compare already reserved buffers and buffers needed. If needed buffers are larger it is possible to reallocate bigger buffers. Of course it is not needed to decrease buffers even smaller stream configurations is asked, just to avoid repetitive allocations of large chunks of coherent memory. I have a patch that enables a similar behavior on the em28xx driver (for digital devices). I used it to play with the buffer size in order to determine the minimum working size. I added a couple of parameters to the em28xx module that can be used to change the buffer number and size at runtime. If anybody is interested, I can post this patch to the list for comments. 1) allocate buffers at the init as now (callback to read stream properties from the driver) 2) re-allocate bigger buffers in runtime if needed (callback to read stream properties from the driver) 3) free all buffers when device is disconnected I think the deciding factor here is the ratio between the default initial size and the maximum buffer size. If it is something like 2X, then maybe it's better to keep the code simple and just allocate the bigger size from the beginning. If the difference is an order of magnitude or more, then using dynamic allocation is probably worth the effort. Another possibility is to allocate a single memory pool of coherent memory at the init, big enough to cover all the possible modes for the given device. Then it is possible to map the URB buffers into this memory pool at runtime, choosing the optimal size for each mode. The memory pool is freed when the device is disconnected. This approach avoids any reallocation so it's safer on ARM/MIPS hardware. For example, the as102 driver allocates a single memory pool in dev-stream, then it maps the URB buffers into this area (see function as102_alloc_usb_stream_buffer() ). In this case the URBs are mapped statically, but nothing prevents to dynamically remap the URB buffers at runtime if needed. Basically those USB buffers are type of (buffer count) x (buffer size). Buffer count is same as used count of URBs, typically ~5, and buffer size is the payload size of one URB. Here is some background info (em28xx buffer alloc failures) why to avoid continuous buffer allocs / frees. http://www.spinics.net/lists/linux-media/msg44209.html There is also the old thread about the issue: http://www.mail-archive.com/linux-media@vger.kernel.org/msg42776.html regards Antti Regards, Gianluca -- 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
[RFC PATCH 1/3] media: reorganize the main Kconfig items
Change the main items to: m Multimedia support --- [ ] Webcams and video grabbers support [ ] Analog TV API and drivers support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support This provides an interface that is clearer to end users that are compiling the Kernel, and will allow the building system to automatically unselect drivers for unused functions. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/Kconfig | 110 --- drivers/media/common/tuners/Kconfig |1 + drivers/media/dvb/frontends/Kconfig |1 + drivers/media/rc/Kconfig| 29 - 4 files changed, 90 insertions(+), 51 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 9575db4..8deddcd 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -6,20 +6,83 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM help - If you want to use Video for Linux, DVB for Linux, or DAB adapters, + If you want to use Webcams, Video grabber devices and/or TV devices enable this option and other options below. + Additional info and docs are available on the web at + http://linuxtv.org + if MEDIA_SUPPORT comment Multimedia core support # +# Multimedia support - automatically enable V4L2 and DVB core +# +config MEDIA_WEBCAM_SUPP + bool Webcams and video grabbers support + ---help--- + Enable support for webcams and video grabbers. + + Say Y when you have a webcam or a video capture grabber board. + +config MEDIA_ANALOG_TV_SUPP + bool Analog TV API and drivers support + ---help--- + Enable analog TV support. + + Say Y when you have a TV board with analog support of with an + hybrid analog/digital TV chipset. + + Note: There are several DVB cards that are based on chips that + supports both analog and digital TV. Disabling this option + will disable support for them. + +config MEDIA_DIGITAL_TV_SUPP + bool Digital TV support + ---help--- + Enable digital TV support. + + Say Y when you have a board with digital support or a board with + hybrid digital TV and analog TV. + +config MEDIA_RADIO_SUPP + bool AM/FM radio receivers/transmitters support + ---help--- + Enable AM/FM radio support. + + Additional info and docs are available on the web at + http://linuxtv.org + + Say Y when you have a board with radio support. + + Note: There are several TV cards that are based on chips that + supports radio reception Disabling this option will + disable support for them. + +menuconfig RC_CORE_SUPP + bool Remote Controller support + depends on INPUT + ---help--- + Enable support for Remote Controllers on Linux. This is + needed in order to support several video capture adapters, + standalone IR receivers/transmitters, and RF receivers. + + Enable this option if you have a video capture board even + if you don't need IR, as otherwise, you may not be able to + compile the driver for your adapter. + + Say Y when you have a TV or an IR device. + +# # Media controller +# Selectable only for webcam/grabbers, as other drivers don't use it # config MEDIA_CONTROLLER bool Media Controller API (EXPERIMENTAL) depends on EXPERIMENTAL + depends on MEDIA_WEBCAM_SUPP ---help--- Enable the media controller API used to query media devices internal topology and configure it dynamically. @@ -27,26 +90,15 @@ config MEDIA_CONTROLLER This API is mostly used by camera interfaces in embedded platforms. # -# V4L core and enabled API's +# Video4Linux support +# Only enables if one of the V4L2 types (ATV, webcam, radio) is selected # config VIDEO_DEV - tristate Video For Linux - ---help--- - V4L core support for video capture and overlay devices, webcams and - AM/FM radio cards. - - This kernel includes support for the new Video for Linux Two API, - (V4L2). - - Additional info and docs are available on the web at - http://linuxtv.org - - Documentation for V4L2 is also available on the web at - http://bytesex.org/v4l/. - - To compile this driver as a module, choose M here: the - module will be called videodev. + tristate + depends on MEDIA_SUPPORT + depends on MEDIA_WEBCAM_SUPP || MEDIA_ANALOG_TV_SUPP || MEDIA_RADIO_SUPP + default y config VIDEO_V4L2_COMMON tristate @@ -64,25 +116,15 @@ config VIDEO_V4L2_SUBDEV_API # # DVB Core +# Only enables if one of DTV is selected # config DVB_CORE - tristate
[RFC PATCH 3/3] media: only show V4L devices based on device type selection
After this patch, the MEDIA*_SUPP will be used as a filter, exposing only devices that are pertinent to one of the 3 V4L types: webcam/grabber, radio, analog TV. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/radio/Kconfig|1 + drivers/media/video/Kconfig| 76 ++- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/smiapp/Kconfig |1 + 4 files changed, 59 insertions(+), 20 deletions(-) diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index c257da1..ac4f627 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -5,6 +5,7 @@ menuconfig RADIO_ADAPTERS bool Radio Adapters depends on VIDEO_V4L2 + depends on MEDIA_RADIO_SUPP default y ---help--- Say Y here to enable selecting AM/FM radio adapters. diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 99937c9..bc7f55e 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -5,7 +5,7 @@ config VIDEO_V4L2 tristate depends on VIDEO_DEV VIDEO_V4L2_COMMON - default VIDEO_DEV VIDEO_V4L2_COMMON + default y config VIDEOBUF_GEN tristate @@ -73,6 +73,7 @@ config VIDEOBUF2_DMA_SG menuconfig VIDEO_CAPTURE_DRIVERS bool Video capture adapters depends on VIDEO_V4L2 + depends on MEDIA_WEBCAM_SUPP || MEDIA_ANALOG_TV_SUPP default y ---help--- Say Y here to enable selecting the video adapters for @@ -478,6 +479,7 @@ config VIDEO_SMIAPP_PLL config VIDEO_OV7670 tristate OmniVision OV7670 sensor support depends on I2C VIDEO_V4L2 + depends on MEDIA_WEBCAM_SUPP ---help--- This is a Video4Linux2 sensor-level driver for the OmniVision OV7670 VGA camera. It currently only works with the M88ALP01 @@ -486,6 +488,7 @@ config VIDEO_OV7670 config VIDEO_VS6624 tristate ST VS6624 sensor support depends on VIDEO_V4L2 I2C + depends on MEDIA_WEBCAM_SUPP ---help--- This is a Video4Linux2 sensor-level driver for the ST VS6624 camera. @@ -496,6 +499,7 @@ config VIDEO_VS6624 config VIDEO_MT9M032 tristate MT9M032 camera sensor support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_WEBCAM_SUPP select VIDEO_APTINA_PLL ---help--- This driver supports MT9M032 camera sensors from Aptina, monochrome @@ -504,6 +508,7 @@ config VIDEO_MT9M032 config VIDEO_MT9P031 tristate Aptina MT9P031 support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_WEBCAM_SUPP select VIDEO_APTINA_PLL ---help--- This is a Video4Linux2 sensor-level driver for the Aptina @@ -512,6 +517,7 @@ config VIDEO_MT9P031 config VIDEO_MT9T001 tristate Aptina MT9T001 support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_WEBCAM_SUPP ---help--- This is a Video4Linux2 sensor-level driver for the Aptina (Micron) mt0t001 3 Mpixel camera. @@ -519,6 +525,7 @@ config VIDEO_MT9T001 config VIDEO_MT9V011 tristate Micron mt9v011 sensor support depends on I2C VIDEO_V4L2 + depends on MEDIA_WEBCAM_SUPP ---help--- This is a Video4Linux2 sensor-level driver for the Micron mt0v011 1.3 Mpixel camera. It currently only works with the @@ -527,6 +534,7 @@ config VIDEO_MT9V011 config VIDEO_MT9V032 tristate Micron MT9V032 sensor support depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_WEBCAM_SUPP ---help--- This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. @@ -534,6 +542,7 @@ config VIDEO_MT9V032 config VIDEO_TCM825X tristate TCM825x camera sensor support depends on I2C VIDEO_V4L2 + depends on MEDIA_WEBCAM_SUPP ---help--- This is a driver for the Toshiba TCM825x VGA camera sensor. It is used for example in Nokia N800. @@ -541,12 +550,14 @@ config VIDEO_TCM825X config VIDEO_SR030PC30 tristate Siliconfile SR030PC30 sensor support depends on I2C VIDEO_V4L2 + depends on MEDIA_WEBCAM_SUPP ---help--- This driver supports SR030PC30 VGA camera from Siliconfile config VIDEO_NOON010PC30 tristate Siliconfile NOON010PC30 sensor support depends on I2C VIDEO_V4L2 EXPERIMENTAL VIDEO_V4L2_SUBDEV_API + depends on MEDIA_WEBCAM_SUPP ---help--- This driver supports NOON010PC30 CIF camera from Siliconfile @@ -554,6 +565,7 @@ source drivers/media/video/m5mols/Kconfig config VIDEO_S5K6AA tristate Samsung S5K6AAFX sensor support + depends on MEDIA_WEBCAM_SUPP depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API ---help---
[RFC PATCH 2/3] media: Remove VIDEO_MEDIA Kconfig option
In the past, it was possible to have either DVB or V4L2 core as module and the other as builtin. Such config never make much sense, and created several issues in order to make the Kconfig dependency to work, as all drivers that depend on both (most TV drivers) would need to be compiled as 'm'. Due to that, the VIDEO_MEDIA config option were added. Instead of such weird approach, let's just use the MEDIA_SUPPORT =y or =m to select if the media subsystem core will be either builtin or module, simplifying the building system logic. Also, fix the tuners configuration, by enabling them only if a tuner is required. So, if just webcam/grabbers support is selected, no tuner option will be selected. Also, if only digital TV is selected, no analog tuner support is selected. That removes the need of using EXPERT customise options, when analog TV is not selected. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/Kconfig |4 -- drivers/media/common/tuners/Kconfig | 63 ++- drivers/media/video/pvrusb2/Kconfig |1 - 3 files changed, 32 insertions(+), 36 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 8deddcd..fe59b49 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -139,10 +139,6 @@ config DVB_NET You may want to disable the network support on embedded devices. If unsure say Y. -config VIDEO_MEDIA - tristate - default (DVB_CORE (VIDEO_DEV = n)) || (VIDEO_DEV (DVB_CORE = n)) || (DVB_CORE VIDEO_DEV) - source drivers/media/common/Kconfig source drivers/media/rc/Kconfig diff --git a/drivers/media/common/tuners/Kconfig b/drivers/media/common/tuners/Kconfig index 16ee1a4..35780df 100644 --- a/drivers/media/common/tuners/Kconfig +++ b/drivers/media/common/tuners/Kconfig @@ -1,6 +1,6 @@ config MEDIA_ATTACH bool Load and attach frontend and tuner driver modules as needed - depends on VIDEO_MEDIA + depends on MEDIA_ANALOG_TV_SUPP || MEDIA_DIGITAL_TV_SUPP || MEDIA_RADIO_SUPP depends on MODULES default y if !EXPERT help @@ -20,15 +20,15 @@ config MEDIA_ATTACH config MEDIA_TUNER tristate - default VIDEO_MEDIA I2C - depends on VIDEO_MEDIA I2C + depends on (MEDIA_ANALOG_TV_SUPP || MEDIA_RADIO_SUPP) I2C + default y select MEDIA_TUNER_XC2028 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_XC5000 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_XC4000 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_MT20XX if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_TDA8290 if !MEDIA_TUNER_CUSTOMISE - select MEDIA_TUNER_TEA5761 if !MEDIA_TUNER_CUSTOMISE EXPERIMENTAL - select MEDIA_TUNER_TEA5767 if !MEDIA_TUNER_CUSTOMISE + select MEDIA_TUNER_TEA5761 if !MEDIA_TUNER_CUSTOMISE MEDIA_RADIO_SUPP EXPERIMENTAL + select MEDIA_TUNER_TEA5767 if !MEDIA_TUNER_CUSTOMISE MEDIA_RADIO_SUPP select MEDIA_TUNER_SIMPLE if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_TDA9887 if !MEDIA_TUNER_CUSTOMISE select MEDIA_TUNER_MC44S803 if !MEDIA_TUNER_CUSTOMISE @@ -48,10 +48,11 @@ config MEDIA_TUNER_CUSTOMISE menu Customize TV tuners visible if MEDIA_TUNER_CUSTOMISE + depends on MEDIA_ANALOG_TV_SUPP || MEDIA_DIGITAL_TV_SUPP || MEDIA_RADIO_SUPP config MEDIA_TUNER_SIMPLE tristate Simple tuner support - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C select MEDIA_TUNER_TDA9887 default m if MEDIA_TUNER_CUSTOMISE help @@ -59,7 +60,7 @@ config MEDIA_TUNER_SIMPLE config MEDIA_TUNER_TDA8290 tristate TDA 8290/8295 + 8275(a)/18271 tuner combo - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C select MEDIA_TUNER_TDA827X select MEDIA_TUNER_TDA18271 default m if MEDIA_TUNER_CUSTOMISE @@ -68,21 +69,21 @@ config MEDIA_TUNER_TDA8290 config MEDIA_TUNER_TDA827X tristate Philips TDA827X silicon tuner - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C default m if MEDIA_TUNER_CUSTOMISE help A DVB-T silicon tuner module. Say Y when you want to support this tuner. config MEDIA_TUNER_TDA18271 tristate NXP TDA18271 silicon tuner - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C default m if MEDIA_TUNER_CUSTOMISE help A silicon tuner module. Say Y when you want to support this tuner. config MEDIA_TUNER_TDA9887 tristate TDA 9885/6/7 analog IF demodulator - depends on VIDEO_MEDIA I2C + depends on MEDIA_SUPPORT I2C default m if MEDIA_TUNER_CUSTOMISE help Say Y here to include support for Philips TDA9885/6/7 @@ -90,7 +91,7 @@ config MEDIA_TUNER_TDA9887 config MEDIA_TUNER_TEA5761 tristate TEA 5761 radio tuner (EXPERIMENTAL) - depends on VIDEO_MEDIA I2C +
[RFC PATCH 0/3] Improve Kconfig selection for media devices
The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) -- 1.7.8 -- 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
[RFC] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
Em 27-05-2012 13:56, Mauro Carvalho Chehab escreveu: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) The organization between DVB only, V4L only and hybrid devices are somewhat confusing on our tree. From time to time, someone proposes changing one driver from one place to another or complains that his device is DVB only but it is inside the V4L tree (and other similar requests). This sometimes happen because the same driver can support analog only, digital only or hybrid devices. Also, one driver may start as a DVB only or as a V4L only and then it can be latter be converted into an hybrid driver. So, the better is to rearrange the drivers tree, in order to fix this issue, removing them from /video and /dvb, and storing them on a better place. So, my proposal is to move all radio, analog TV, digital TV, webcams and grabber bridge drivers to this arrangement: drivers/media/isa - ISA drivers drivers/media/usb - USB drivers drivers/media/pci - PCI/PCIe drivers drivers/media/platform - platform drivers Comments? Regards, Mauro - PS.: for now, I don't intend to touch at I2C/ancillary drivers. We may latter move the i2c drivers that aren't frontend/tuners to media/i2c or to media/common. -- 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 PATCH 1/3] media: reorganize the main Kconfig items
Just a few typos... On Sun May 27 2012 18:56:41 Mauro Carvalho Chehab wrote: Change the main items to: m Multimedia support --- [ ] Webcams and video grabbers support [ ] Analog TV API and drivers support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support This provides an interface that is clearer to end users that are compiling the Kernel, and will allow the building system to automatically unselect drivers for unused functions. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/Kconfig | 110 --- drivers/media/common/tuners/Kconfig |1 + drivers/media/dvb/frontends/Kconfig |1 + drivers/media/rc/Kconfig| 29 - 4 files changed, 90 insertions(+), 51 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 9575db4..8deddcd 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -6,20 +6,83 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM help - If you want to use Video for Linux, DVB for Linux, or DAB adapters, + If you want to use Webcams, Video grabber devices and/or TV devices enable this option and other options below. + Additional info and docs are available on the web at + http://linuxtv.org + if MEDIA_SUPPORT comment Multimedia core support # +# Multimedia support - automatically enable V4L2 and DVB core +# +config MEDIA_WEBCAM_SUPP + bool Webcams and video grabbers support + ---help--- + Enable support for webcams and video grabbers. + + Say Y when you have a webcam or a video capture grabber board. + +config MEDIA_ANALOG_TV_SUPP + bool Analog TV API and drivers support I would rename this to Analog TV support to be consistent with the digital option. + ---help--- + Enable analog TV support. + + Say Y when you have a TV board with analog support of with an Typo: of with an - or with a + hybrid analog/digital TV chipset. + + Note: There are several DVB cards that are based on chips that + supports both analog and digital TV. Disabling this option supports - support + will disable support for them. + +config MEDIA_DIGITAL_TV_SUPP + bool Digital TV support + ---help--- + Enable digital TV support. + + Say Y when you have a board with digital support or a board with + hybrid digital TV and analog TV. + +config MEDIA_RADIO_SUPP + bool AM/FM radio receivers/transmitters support + ---help--- + Enable AM/FM radio support. + + Additional info and docs are available on the web at + http://linuxtv.org + + Say Y when you have a board with radio support. + + Note: There are several TV cards that are based on chips that + supports radio reception Disabling this option will supports - support Also add a period after reception. 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: [RFC PATCH 1/3] media: reorganize the main Kconfig items
Em 27-05-2012 14:15, Hans Verkuil escreveu: Just a few typos... On Sun May 27 2012 18:56:41 Mauro Carvalho Chehab wrote: Change the main items to: m Multimedia support --- [ ] Webcams and video grabbers support [ ] Analog TV API and drivers support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support This provides an interface that is clearer to end users that are compiling the Kernel, and will allow the building system to automatically unselect drivers for unused functions. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/Kconfig | 110 --- drivers/media/common/tuners/Kconfig |1 + drivers/media/dvb/frontends/Kconfig |1 + drivers/media/rc/Kconfig| 29 - 4 files changed, 90 insertions(+), 51 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 9575db4..8deddcd 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -6,20 +6,83 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM help - If you want to use Video for Linux, DVB for Linux, or DAB adapters, + If you want to use Webcams, Video grabber devices and/or TV devices enable this option and other options below. + Additional info and docs are available on the web at + http://linuxtv.org + if MEDIA_SUPPORT comment Multimedia core support # +# Multimedia support - automatically enable V4L2 and DVB core +# +config MEDIA_WEBCAM_SUPP +bool Webcams and video grabbers support +---help--- + Enable support for webcams and video grabbers. + + Say Y when you have a webcam or a video capture grabber board. + +config MEDIA_ANALOG_TV_SUPP +bool Analog TV API and drivers support I would rename this to Analog TV support to be consistent with the digital option. +---help--- + Enable analog TV support. + + Say Y when you have a TV board with analog support of with an Typo: of with an - or with a + hybrid analog/digital TV chipset. + + Note: There are several DVB cards that are based on chips that +supports both analog and digital TV. Disabling this option supports - support +will disable support for them. + +config MEDIA_DIGITAL_TV_SUPP +bool Digital TV support +---help--- + Enable digital TV support. + + Say Y when you have a board with digital support or a board with + hybrid digital TV and analog TV. + +config MEDIA_RADIO_SUPP +bool AM/FM radio receivers/transmitters support +---help--- + Enable AM/FM radio support. + + Additional info and docs are available on the web at + http://linuxtv.org + + Say Y when you have a board with radio support. + + Note: There are several TV cards that are based on chips that +supports radio reception Disabling this option will supports - support Also add a period after reception. Regards, Hans Thanks! It follows v2 with the suggested fixes. - media: reorganize the main Kconfig items From: Mauro Carvalho Chehab mche...@redhat.com Change the main items to: m Multimedia support --- [ ] Webcams and video grabbers support [ ] Analog TV API and drivers support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support This provides an interface that is clearer to end users that are compiling the Kernel, and will allow the building system to automatically unselect drivers for unused functions. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 9575db4..2ac4c9a 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -6,20 +6,83 @@ menuconfig MEDIA_SUPPORT tristate Multimedia support depends on HAS_IOMEM help - If you want to use Video for Linux, DVB for Linux, or DAB adapters, + If you want to use Webcams, Video grabber devices and/or TV devices enable this option and other options below. + Additional info and docs are available on the web at + http://linuxtv.org + if MEDIA_SUPPORT comment Multimedia core support # +# Multimedia support - automatically enable V4L2 and DVB core +# +config MEDIA_WEBCAM_SUPP + bool Webcams and video grabbers support + ---help--- + Enable support for webcams and video grabbers. + + Say Y when you have a webcam or a video capture grabber board. + +config MEDIA_ANALOG_TV_SUPP + bool Analog TV support + ---help--- + Enable analog TV support. + + Say Y when you have a TV board with analog support of with a + hybrid analog/digital TV chipset. + + Note: There are several DVB cards
Re: [RFC] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
On Sun May 27 2012 19:13:38 Mauro Carvalho Chehab wrote: Em 27-05-2012 13:56, Mauro Carvalho Chehab escreveu: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) The organization between DVB only, V4L only and hybrid devices are somewhat confusing on our tree. From time to time, someone proposes changing one driver from one place to another or complains that his device is DVB only but it is inside the V4L tree (and other similar requests). This sometimes happen because the same driver can support analog only, digital only or hybrid devices. Also, one driver may start as a DVB only or as a V4L only and then it can be latter be converted into an hybrid driver. So, the better is to rearrange the drivers tree, in order to fix this issue, removing them from /video and /dvb, and storing them on a better place. So, my proposal is to move all radio, analog TV, digital TV, webcams and grabber bridge drivers to this arrangement: drivers/media/isa - ISA drivers drivers/media/usb - USB drivers drivers/media/pci - PCI/PCIe drivers drivers/media/platform - platform drivers drivers/media/parport drivers/media/i2c Also, if we do this then I would really like to separate the sub-device drivers from the main drivers. I find it very messy that those are mixed. So: drivers/media/subdevs We might subdivide /subdevs even further (sensors, encoders, decoders, etc.) but I am not sure if that is worthwhile. Frankly, the current directory structure (other than the lack of a subdevs directory) doesn't bother me. But your proposal is a bit cleaner. Regards, Hans Comments? Regards, Mauro - PS.: for now, I don't intend to touch at I2C/ancillary drivers. We may latter move the i2c drivers that aren't frontend/tuners to media/i2c or to media/common. -- 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: [RFC PATCH 1/3] media: reorganize the main Kconfig items
Hi Mauro, On 05/27/2012 06:56 PM, Mauro Carvalho Chehab wrote: Change the main items to: m Multimedia support --- [ ] Webcams and video grabbers support [ ] Analog TV API and drivers support [ ] Digital TV support [ ] AM/FM radio receivers/transmitters support [ ] Remote Controller support This provides an interface that is clearer to end users that are compiling the Kernel, and will allow the building system to automatically unselect drivers for unused functions. The change looks reasonable to me, however I have few doubts with regards to the naming. Is V4L2 really only for webcams? :) How about renaming: MEDIA_WEBCAM - MEDIA_CAMERA, *_SUPP - _SUPPORT (grep gives many more results for the full word), Webcams - Cameras ? Regards, Sylwester -- 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: [RFCv1 PATCH 1/5] videodev2.h: add new hwseek capability bits.
Looks good:
Acked-by: Hans de Goede hdego...@redhat.com
On 05/27/2012 01:50 PM, Hans Verkuil wrote:
From: Hans Verkuilhans.verk...@cisco.com
Tell the application whether the hardware seek is bounded and/or wraps around.
Signed-off-by: Hans Verkuilhans.verk...@cisco.com
---
include/linux/videodev2.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 370d111..2339678 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2039,6 +2039,8 @@ struct v4l2_modulator {
/* Flags for the 'capability' field */
#define V4L2_TUNER_CAP_LOW0x0001
#define V4L2_TUNER_CAP_NORM 0x0002
+#define V4L2_TUNER_CAP_HWSEEK_BOUNDED 0x0004
+#define V4L2_TUNER_CAP_HWSEEK_WRAP 0x0008
#define V4L2_TUNER_CAP_STEREO 0x0010
#define V4L2_TUNER_CAP_LANG2 0x0020
#define V4L2_TUNER_CAP_SAP0x0020
--
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: [RFCv1 PATCH 2/5] v4l2 spec: document the new v4l2_tuner capabilities
Small typo, see comment inline, with that fixed: Acked-by: Hans de Goede hdego...@redhat.com On 05/27/2012 01:50 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com Update the spec with the new capabilities and specify new error codes for S_HW_FREQ_SEEK. Signed-off-by: Hans Verkuilhans.verk...@cisco.com --- .../DocBook/media/v4l/vidioc-g-frequency.xml |6 ++ Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 12 .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml | 18 +++--- 3 files changed, 33 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml index 69c178a..40e58a4 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml @@ -135,6 +135,12 @@ bounds or the value in thestructfieldtype/structfield field is wrong./para /listitem /varlistentry +varlistentry + termerrorcodeEBUSY/errorcode/term + listitem + paraA hardware seek is in progress./para + /listitem +/varlistentry /variablelist /refsect1 /refentry diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index 62a1aa2..95d5371 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -276,6 +276,18 @@ can or must be switched. (B/G PAL tuners for example are typically not constantV4L2_TUNER_ANALOG_TV/constant tuners can have this capability./entry /row row + entryconstantV4L2_TUNER_CAP_HWSEEK_BOUNDED/constant/entry + entry0x0004/entry + entryIf set, then this tuner supports the hardware seek functionality + where the seek stops when it reaches the end of the frequency range./entry + /row + row + entryconstantV4L2_TUNER_CAP_HWSEEK_WRAP/constant/entry + entry0x0008/entry + entryIf set, then this tuner supports the hardware seek functionality + where the seek wraps around when it reaches the end of the frequency range./entry + /row + row entryconstantV4L2_TUNER_CAP_STEREO/constant/entry entry0x0010/entry entryStereo audio reception is supported./entry diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index 407dfce..d58b648 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -58,6 +58,9 @@ To do this applications initialize thestructfieldtuner/structfield, call theconstantVIDIOC_S_HW_FREQ_SEEK/constant ioctl with a pointer to this structure./para +paraIf an error is returned, then the frequency original frequency will +be restored./para + One frequency too many in that sentence :) paraThis ioctl is supported if theconstantV4L2_CAP_HW_FREQ_SEEK/constant capability is set./para table pgwide=1 frame=none id=v4l2-hw-freq-seek @@ -87,7 +90,10 @@ field and thev4l2-tuner;structfieldindex/structfield field./entry row entry__u32/entry entrystructfieldwrap_around/structfield/entry - entryIf non-zero, wrap around when at the end of the frequency range, else stop seeking./entry + entryIf non-zero, wrap around when at the end of the frequency range, else stop seeking. + Thev4l2-tuner;structfieldcapability/structfield field will tell you what the + hardware supports. + /entry /row row entry__u32/entry @@ -118,9 +124,15 @@ wrong./para /listitem /varlistentry varlistentry - termerrorcodeEAGAIN/errorcode/term + termerrorcodeENODATA/errorcode/term + listitem + paraThe hardware seek found no channels./para + /listitem +/varlistentry +varlistentry + termerrorcodeEBUSY/errorcode/term listitem - paraThe ioctl timed-out. Try again./para + paraAnother hardware seek is already in progress./para /listitem /varlistentry /variablelist -- 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: [RFCv1 PATCH 3/5] S_HW_FREQ_SEEK: set capability flags and return ENODATA instead of EAGAIN.
Looks good:
Acked-by: Hans de Goede hdego...@redhat.com
On 05/27/2012 01:50 PM, Hans Verkuil wrote:
From: Hans Verkuilhans.verk...@cisco.com
Set the new capability flags in G_TUNER and return ENODATA if no channels
were found.
Signed-off-by: Hans Verkuilhans.verk...@cisco.com
---
drivers/media/radio/radio-mr800.c|5 +++--
drivers/media/radio/radio-wl1273.c |3 ++-
drivers/media/radio/si470x/radio-si470x-common.c |6 --
drivers/media/radio/wl128x/fmdrv_rx.c|2 +-
drivers/media/radio/wl128x/fmdrv_v4l2.c |4 +++-
sound/i2c/other/tea575x-tuner.c |4 +++-
6 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/radio/radio-mr800.c
b/drivers/media/radio/radio-mr800.c
index 94cb6bc..3182b26 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -295,7 +295,8 @@ static int vidioc_g_tuner(struct file *file, void *priv,
v-type = V4L2_TUNER_RADIO;
v-rangelow = FREQ_MIN * FREQ_MUL;
v-rangehigh = FREQ_MAX * FREQ_MUL;
- v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
+ v-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
v-rxsubchans = is_stereo ? V4L2_TUNER_SUB_STEREO : V4L2_TUNER_SUB_MONO;
v-audmode = radio-stereo ?
V4L2_TUNER_MODE_STEREO : V4L2_TUNER_MODE_MONO;
@@ -372,7 +373,7 @@ static int vidioc_s_hw_freq_seek(struct file *file, void
*priv,
timeout = jiffies + msecs_to_jiffies(3);
for (;;) {
if (time_after(jiffies, timeout)) {
- retval = -EAGAIN;
+ retval = -ENODATA;
break;
}
if (schedule_timeout_interruptible(msecs_to_jiffies(10))) {
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index f1b6070..e8428f5 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1514,7 +1514,8 @@ static int wl1273_fm_vidioc_g_tuner(struct file *file,
void *priv,
tuner-rangehigh = WL1273_FREQ(WL1273_BAND_OTHER_HIGH);
tuner-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_RDS |
- V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS_BLOCK_IO;
+ V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED | V4L2_TUNER_CAP_HWSEEK_WRAP;
if (radio-stereo)
tuner-audmode = V4L2_TUNER_MODE_STEREO;
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 969cf49..d485b79 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -363,7 +363,7 @@ stop:
/* try again, if timed out */
if (retval == 0 timed_out)
- return -EAGAIN;
+ return -ENODATA;
return retval;
}
@@ -596,7 +596,9 @@ static int si470x_vidioc_g_tuner(struct file *file, void
*priv,
strcpy(tuner-name, FM);
tuner-type = V4L2_TUNER_RADIO;
tuner-capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
- V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO;
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
/* range limits */
switch ((radio-registers[SYSCONFIG2] SYSCONFIG2_BAND) 6) {
diff --git a/drivers/media/radio/wl128x/fmdrv_rx.c
b/drivers/media/radio/wl128x/fmdrv_rx.c
index 43fb722..3dd9fc0 100644
--- a/drivers/media/radio/wl128x/fmdrv_rx.c
+++ b/drivers/media/radio/wl128x/fmdrv_rx.c
@@ -251,7 +251,7 @@ again:
if (!timeleft) {
fmerr(Timeout(%d sec),didn't get tune ended int\n,
jiffies_to_msecs(FM_DRV_RX_SEEK_TIMEOUT) / 1000);
- return -ETIMEDOUT;
+ return -ENODATA;
}
int_reason = fmdev-irq_info.flag (FM_TUNE_COMPLETE | FM_BAND_LIMIT);
diff --git a/drivers/media/radio/wl128x/fmdrv_v4l2.c
b/drivers/media/radio/wl128x/fmdrv_v4l2.c
index 080b96a..49a11ec 100644
--- a/drivers/media/radio/wl128x/fmdrv_v4l2.c
+++ b/drivers/media/radio/wl128x/fmdrv_v4l2.c
@@ -285,7 +285,9 @@ static int fm_v4l2_vidioc_g_tuner(struct file *file, void
*priv,
tuner-rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO |
((fmdev-rx.rds.flag == FM_RDS_ENABLE) ? V4L2_TUNER_SUB_RDS : 0);
tuner-capability = V4L2_TUNER_CAP_STEREO | V4L2_TUNER_CAP_RDS |
- V4L2_TUNER_CAP_LOW;
+ V4L2_TUNER_CAP_LOW |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP;
tuner-audmode = (stereo_mono_mode ?
cron job: media_tree daily build: WARNINGS
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:Sun May 27 19:00:19 CEST 2012 git hash:5472d3f17845c4398c6a510b46855820920c2181 gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.3-6.slh.2-amd64 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-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: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: 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: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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: [RFCv1 PATCH 4/5] videodev2.h: add frequency band information.
Looks good:
Acked-by: Hans de Goede hdego...@redhat.com
On 05/27/2012 01:50 PM, Hans Verkuil wrote:
From: Hans Verkuilhans.verk...@cisco.com
Signed-off-by: Hans Verkuilhans.verk...@cisco.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_RDS0x0080
#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
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO 0x0001
@@ -2065,6 +2072,14 @@ struct v4l2_modulator {
#define V4L2_TUNER_MODE_LANG1 0x0003
#define V4L2_TUNER_MODE_LANG1_LANG2 0x0004
+/* Values for the 'band' field */
+#define V4L2_TUNER_BAND_DEFAULT 0
+#define V4L2_TUNER_BAND_FM_EUROPE_US 1 /* 87.5 Mhz - 108 MHz */
+#define V4L2_TUNER_BAND_FM_JAPAN 2 /* 76 MHz - 90 MHz */
+#define V4L2_TUNER_BAND_FM_RUSSIAN3 /* 65.8 MHz - 74 MHz */
+#define V4L2_TUNER_BAND_FM_WEATHER4 /* 162.4 MHz - 162.55 MHz */
+#define V4L2_TUNER_BAND_AM_MW 5
+
struct v4l2_frequency {
__u32 tuner;
__u32 type; /* enum v4l2_tuner_type */
--
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: [RFCv1 PATCH 5/5] V4L2 spec: add frequency band documentation.
Hi, Comments inline. On 05/27/2012 01:50 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com Based in part on an earlier patch fromhallima...@gmail.com. Signed-off-by: Hans Verkuilhans.verk...@cisco.com --- Documentation/DocBook/media/v4l/common.xml | 28 -- .../DocBook/media/v4l/vidioc-g-modulator.xml | 38 +--- Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 97 +--- .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml|3 +- 4 files changed, 131 insertions(+), 35 deletions(-) diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 4101aeb..4e7082d 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -464,17 +464,18 @@ Thestructfieldtype/structfield field of the respective structfieldtuner/structfield field contains the index number of the tuner./para -paraRadio devices have exactly one tuner with index zero, no -video inputs./para +paraRadio input devices have one or more tuners, but these are +obviously not associated with any video inputs./para This is about having multiple tuners for radio devices, not about the band support, IMHO as such this belongs in a different patch. Also it seems we never finished the earlier discussions of how to handle radio devices which really have multiple tuners, so it seems premature to change this at all atm. paraTo query and change tuner properties applications use the VIDIOC-G-TUNER; andVIDIOC-S-TUNER; ioctl, respectively. The v4l2-tuner; returned byconstantVIDIOC_G_TUNER/constant also contains signal status information applicable when the tuner of the -current video input, or a radio tuner is queried. Note that +current video input or a radio tuner is queried. Note that constantVIDIOC_S_TUNER/constant does not switch the current tuner, when there is more than one at all. The tuner is solely determined by -the current video input. Drivers must support both ioctls and set the +the current video input or by callingVIDIOC-S-FREQUENCY; for radio +tuners. Drivers must support both ioctls and set the constantV4L2_CAP_TUNER/constant flag in thev4l2-capability; returned by theVIDIOC-QUERYCAP; ioctl when the device has one or more tuners./para Again this seems about having multiple tuners on radio devices. If a radio device has multiple tuners, I would expect both to be able to be active at the same time (ie for recording one show and listening an other), so I would expect there to be a mapping between audio-inputs and tuners, just like we have one between video inputs and tuners for video. Which means that the language of S_FREQ selecting a tuner makes no sense, as both can be active at the same time ... All in all I think the whole what to do with radio devices with multiple tuners discussion can best be deferred until we actually encounter such a device. @@ -491,14 +492,24 @@ the modulator. Thestructfieldtype/structfield field of the respectivev4l2-output; returned by theVIDIOC-ENUMOUTPUT; ioctl is set toconstantV4L2_OUTPUT_TYPE_MODULATOR/constant and its structfieldmodulator/structfield field contains the index number -of the modulator. This specification does not define radio output -devices./para +of the modulator./para + +paraRadio output devices have one or more modulators, but these +are obviously not associated with any video outputs./para + +paraA video or radio device cannot support both a tuner and a +modulator. Two separate device nodes will have to be used for such +hardware, one that supports the tuner functionality and one that supports +the modulator functionality. The reason is a limitation with the +VIDIOC-S-FREQUENCY; ioctl where you cannot specify whether the frequency +is for a tuner or a modulator./para paraTo query and change modulator properties applications use theVIDIOC-G-MODULATOR; andVIDIOC-S-MODULATOR; ioctl. Note that constantVIDIOC_S_MODULATOR/constant does not switch the current modulator, when there is more than one at all. The modulator is solely -determined by the current video output. Drivers must support both +determined by the current video output or by callingVIDIOC-S-FREQUENCY; +for radio modulators. Drivers must support both ioctls and set theconstantV4L2_CAP_MODULATOR/constant flag in thev4l2-capability; returned by theVIDIOC-QUERYCAP; ioctl when the device has one or more modulators./para Same again, who says if there are 2 modulators they cannot be both active at the same time, which means the whole notion of selecting one is wrong. @@ -511,8 +522,7 @@ device has one or more modulators./para applications use theVIDIOC-G-FREQUENCY; andVIDIOC-S-FREQUENCY; ioctl which both take a pointer to av4l2-frequency;. These ioctls are used for TV and radio devices alike. Drivers must support both -ioctls when the tuner or modulator ioctls are supported, or -when the device
Re: [RFC] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
Hans Verkuil hverk...@xs4all.nl wrote: On Sun May 27 2012 19:13:38 Mauro Carvalho Chehab wrote: Em 27-05-2012 13:56, Mauro Carvalho Chehab escreveu: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) The organization between DVB only, V4L only and hybrid devices are somewhat confusing on our tree. From time to time, someone proposes changing one driver from one place to another or complains that his device is DVB only but it is inside the V4L tree (and other similar requests). This sometimes happen because the same driver can support analog only, digital only or hybrid devices. Also, one driver may start as a DVB only or as a V4L only and then it can be latter be converted into an hybrid driver. So, the better is to rearrange the drivers tree, in order to fix this issue, removing them from /video and /dvb, and storing them on a better place. So, my proposal is to move all radio, analog TV, digital TV, webcams and grabber bridge drivers to this arrangement: drivers/media/isa - ISA drivers drivers/media/usb - USB drivers drivers/media/pci - PCI/PCIe drivers drivers/media/platform - platform drivers drivers/media/parport drivers/media/i2c Also, if we do this then I would really like to separate the sub-device drivers from the main drivers. I find it very messy that those are mixed. So: drivers/media/subdevs We might subdivide /subdevs even further (sensors, encoders, decoders, etc.) but I am not sure if that is worthwhile. Frankly, the current directory structure (other than the lack of a subdevs directory) doesn't bother me. But your proposal is a bit cleaner. Regards, Hans Comments? Regards, Mauro - PS.: for now, I don't intend to touch at I2C/ancillary drivers. We may latter move the i2c drivers that aren't frontend/tuners to media/i2c or to media/common. -- 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 Also cx2341x and tveeprom are oddballs. I can't think of any other exceptions at the moment. Regards, Andy -- 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] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
Em 27-05-2012 14:25, Hans Verkuil escreveu: On Sun May 27 2012 19:13:38 Mauro Carvalho Chehab wrote: Em 27-05-2012 13:56, Mauro Carvalho Chehab escreveu: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) The organization between DVB only, V4L only and hybrid devices are somewhat confusing on our tree. From time to time, someone proposes changing one driver from one place to another or complains that his device is DVB only but it is inside the V4L tree (and other similar requests). This sometimes happen because the same driver can support analog only, digital only or hybrid devices. Also, one driver may start as a DVB only or as a V4L only and then it can be latter be converted into an hybrid driver. So, the better is to rearrange the drivers tree, in order to fix this issue, removing them from /video and /dvb, and storing them on a better place. So, my proposal is to move all radio, analog TV, digital TV, webcams and grabber bridge drivers to this arrangement: drivers/media/isa - ISA drivers drivers/media/usb - USB drivers drivers/media/pci - PCI/PCIe drivers drivers/media/platform - platform drivers drivers/media/parport Ok. drivers/media/i2c See below. Also, if we do this then I would really like to separate the sub-device drivers from the main drivers. I find it very messy that those are mixed. So: drivers/media/subdevs We might subdivide /subdevs even further (sensors, encoders, decoders, etc.) but I am not sure if that is worthwhile. I think all subdevs (being i2c or not) should be under the same directory. drivers/media/subdevs seems reasonable. Sub-dividing them doesn't seem a good idea, as some subdevs may have more than one function. Frankly, the current directory structure (other than the lack of a subdevs directory) doesn't bother me. But your proposal is a bit cleaner. It doesn't bother me either[1], with regards to the existing drivers, but it is confusing for someone that wants to write a new driver. [1] with exception to the saa7146 driver under media/common - that looks really weird. Also, for example, Antti proposed to add V4L2 support for dvb-usb. I think he ended by discarding it for his GoC scope of work, but, anyway, with the current arrangement, that would mean that dvb-usb won't fit well at media/dvb (as all other hybrid cards aren't there). So, as we're removing the explicit Kconfig logic for compiling V4L2 core/DVB core, it makes sense to rearrange the rest of the structure and improve the building system to better handle the media cards, removing the artificial and imperfect divisions that it is used there. Regards, Mauro -- 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] file tree rearrangement - was: Re: [RFC PATCH 0/3] Improve Kconfig selection for media devices
Em 27-05-2012 15:47, Andy Walls escreveu: Hans Verkuil hverk...@xs4all.nl wrote: On Sun May 27 2012 19:13:38 Mauro Carvalho Chehab wrote: Em 27-05-2012 13:56, Mauro Carvalho Chehab escreveu: The Kconfig building system is improperly selecting some drivers, like analog TV tuners even when this is not required. Rearrange the Kconfig in a way to prevent that. Mauro Carvalho Chehab (3): media: reorganize the main Kconfig items media: Remove VIDEO_MEDIA Kconfig option media: only show V4L devices based on device type selection drivers/media/Kconfig | 114 +++ drivers/media/common/tuners/Kconfig | 64 ++-- drivers/media/dvb/frontends/Kconfig |1 + drivers/media/radio/Kconfig |1 + drivers/media/rc/Kconfig| 29 - drivers/media/video/Kconfig | 76 +-- drivers/media/video/m5mols/Kconfig |1 + drivers/media/video/pvrusb2/Kconfig |1 - drivers/media/video/smiapp/Kconfig |1 + 9 files changed, 181 insertions(+), 107 deletions(-) The organization between DVB only, V4L only and hybrid devices are somewhat confusing on our tree. From time to time, someone proposes changing one driver from one place to another or complains that his device is DVB only but it is inside the V4L tree (and other similar requests). This sometimes happen because the same driver can support analog only, digital only or hybrid devices. Also, one driver may start as a DVB only or as a V4L only and then it can be latter be converted into an hybrid driver. So, the better is to rearrange the drivers tree, in order to fix this issue, removing them from /video and /dvb, and storing them on a better place. So, my proposal is to move all radio, analog TV, digital TV, webcams and grabber bridge drivers to this arrangement: drivers/media/isa - ISA drivers drivers/media/usb - USB drivers drivers/media/pci - PCI/PCIe drivers drivers/media/platform - platform drivers drivers/media/parport drivers/media/i2c Also, if we do this then I would really like to separate the sub-device drivers from the main drivers. I find it very messy that those are mixed. So: drivers/media/subdevs We might subdivide /subdevs even further (sensors, encoders, decoders, etc.) but I am not sure if that is worthwhile. Frankly, the current directory structure (other than the lack of a subdevs directory) doesn't bother me. But your proposal is a bit cleaner. Regards, Hans Comments? Regards, Mauro - PS.: for now, I don't intend to touch at I2C/ancillary drivers. We may latter move the i2c drivers that aren't frontend/tuners to media/i2c or to media/common. -- 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 Also cx2341x and tveeprom cx2341x is a sub-device module. So, it can go to drivers/media/subdevs (ok, it has other problems, but solving them is not as simple as moving things from one place to the other - so let's not mix it here). The case of tveeprom is different, because it is not really a sub-device. Btw, this file is bad named - it should be called hauppauge-eeprom or something like that. Yet, I wouldn't move it out of drivers/media/video (or at least on this first step). There are other similar cases. for example, btcx-risc is a common module used by both cx88 and bttv drivers to handle the RISC processor that exists on both. This is not a sub-device, so it won't fit on the above structure. . Maybe we can create a drivers/media/v4l2-core and move everything that belongs to the core into it, and the things that won't fit elsewhere can be moved into drivers/media/common. I would also move tuner, dvb-core and frontend to an upper level: So, in summary, the final structure would be: drivers/media /common - drivers that are common to several ones, like tveeprom and btcx-risc /dvb-core - what is already at dvb/dvb-core /frontends - what is already at dvb/frontends /isa- all ISA drivers /parport- all parallel port drivers /pci- all PCI/PCIe drivers /platform - all platform drivers /subdevice - all sub-device drivers /tuner - what's currently at common/tuners /usb- all USB drivers /v4l2-core - V4L2 core After doing that, the Kconfig options at isa, parport, pci, platform and usb can be optimized further, based on the media support filters: m Multimedia support --- [ ] Webcams and video grabbers support [
Re: [PATCH 1/1] [media] s5p-fimc: Add missing static storage class
On 05/26/2012 05:11 PM, Sachin Kamat wrote: Fixes the following sparse warnings: Hi Sachin. Thanks, in case somebody else applies this patch before I do: Acked-by: Sylwester Nawrocki s.nawro...@samsung.com I would just change the summary line to: s5p-fimc: Add missing static storage class specifiers when applying this patch. -- Regards, Sylwester -- 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/PATCH] media: Add stk1160 new driver
Hi Hans,
On Sat, May 26, 2012 at 2:05 PM, Hans Verkuil hverk...@xs4all.nl wrote:
Always test your driver using the v4l2-compliance test tool that it part of
v4l-utils! If it passes that, then your code will be in really good shape!
You're right. I'll add v4l2-compliance output in the next patch.
On Sat May 26 2012 18:41:00 Ezequiel Garcia wrote:
This driver adds support for stk1160 usb bridge as used in some
video/audio usb capture devices.
It is a complete rewrite of staging/media/easycap driver and
it's expected as a future replacement.
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
As of today testing has been performed using both vlc and mplayer
on a gentoo machine, including hot unplug and on-the-fly standard
change using a device with 1-cvs and 1-audio output.
However more testing is underway with another device and/or another
distribution.
Alsa sound support is a missing feature (work in progress).
As this is my first complete driver, the patch is (obviously) intended as
RFC only.
Any comments/reviews of *any* kind will be greatly appreciated.
---
drivers/media/video/Kconfig | 2 +
drivers/media/video/Makefile | 1 +
drivers/media/video/stk1160/Kconfig | 11 +
drivers/media/video/stk1160/Makefile | 6 +
drivers/media/video/stk1160/stk1160-core.c | 399 +
drivers/media/video/stk1160/stk1160-i2c.c | 304 ++
drivers/media/video/stk1160/stk1160-reg.h | 78 +++
drivers/media/video/stk1160/stk1160-v4l.c | 846
+++
drivers/media/video/stk1160/stk1160-video.c | 506
drivers/media/video/stk1160/stk1160.h | 183 ++
10 files changed, 2336 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/stk1160/Kconfig
create mode 100644 drivers/media/video/stk1160/Makefile
create mode 100644 drivers/media/video/stk1160/stk1160-core.c
create mode 100644 drivers/media/video/stk1160/stk1160-i2c.c
create mode 100644 drivers/media/video/stk1160/stk1160-reg.h
create mode 100644 drivers/media/video/stk1160/stk1160-v4l.c
create mode 100644 drivers/media/video/stk1160/stk1160-video.c
create mode 100644 drivers/media/video/stk1160/stk1160.h
+
+ /*
+ * We take the lock just before device registration,
+ * to prevent someone (probably udev) from opening us
+ * before we finish initialization
+ */
+ mutex_init(dev-mutex);
+ mutex_lock(dev-mutex);
+
+ rc = stk1160_video_register(dev);
It's usually better to register the video node as the very last thing
in probe(). That way when the node appears it's ready for udev to use.
No need to lock the mutex in that case.
Done.
+ /*
+ * Wait until all current v4l2 operation are finished
+ * then deallocate resources
+ */
+ mutex_lock(dev-mutex);
+
+ /* Since saa7115 is no longer present, it's better to unregister it */
+ v4l2_device_unregister_subdev(dev-sd_saa7115);
+
+ stk1160_stop_streaming(dev);
+
+ v4l2_device_disconnect(dev-v4l2_dev);
+
+ /* This way current users can detect device is gone */
+ dev-udev = NULL;
+
+ mutex_unlock(dev-mutex);
+
+ stk1160_i2c_unregister(dev);
+ stk1160_video_unregister(dev);
I recommend that you use the same approach as I did in media/radio/dsbr100.c:
use the v4l2_dev-release callback to handle the final cleanup. That is a safe
method that does all the refcounting for you.
I'm sorry but I don't really see the difference.
Right now I'm having video_device release function to handle the final cleanup.
I don't do the refcounting myself either. See my other comment below.
...
diff --git a/drivers/media/video/stk1160/stk1160-v4l.c
b/drivers/media/video/stk1160/stk1160-v4l.c
new file mode 100644
index 000..a7a012b
--- /dev/null
+++ b/drivers/media/video/stk1160/stk1160-v4l.c
...
+static int stk1160_open(struct file *filp)
+{
+ struct stk1160 *dev = video_drvdata(filp);
+
+ dev-users++;
Why the users field? You shouldn't need it.
Done.
+
+ stk1160_info(opened: users=%d\n, dev-users);
+
+ return v4l2_fh_open(filp);
+}
+
+static int stk1160_close(struct file *file)
+{
+ struct stk1160 *dev = video_drvdata(file);
+
+ dev-users--;
+
+ stk1160_info(closed: users=%d\n, dev-users);
+
+ /*
+ * If this is the last fh remaining open, then we
+ * stop streaming and free/dequeue all buffers.
+ * This prevents device from streaming without
+ * any opened filehandles.
+ */
+ if (v4l2_fh_is_singular_file(file))
+ vb2_queue_release(dev-vb_vidq);
No. You should keep track of which filehandle started streaming (actually
the filehandle that called REQBUFS is the owner of the queue) and release
the queue when that particular filehandle is closed (or it calls REQBUFS
with a count of 0).
Ah. I gave much
em28xx: Remote control support for another board
Hello, some days ago I purchased a TerraTec Cinergy HTC Stick HD. Unfortunately the remote control (which came bundled) did not work. I found out that there's no remote control support for that stick/board in the em28xx driver. Thus I wrote two patches: The first one adds remote control support for my USB DVB-[T,C] stick. The second patch (is optional and) adds a small printk which lets the user know that he doesn't have to search in userspace if his remote control does not work. PS: I could re-use the existing keymap for the TerraTec Cinergy XS because it uses the same remote control as my Cinergy HTC Stick HD. Regards, Martin -- 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
[PATCH 1/2] [media] em28xx: Add remote control support for Terratec's Cinergy HTC Stick HD.
The Cinergy HTC Stick HD uses the same remote control as the TerraTec
Cinergy XS products.
---
drivers/media/video/em28xx/em28xx-cards.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 20a7e24..8e32339 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -974,6 +974,7 @@ struct em28xx_board em28xx_boards[] = {
[EM2884_BOARD_CINERGY_HTC_STICK] = {
.name = Terratec Cinergy HTC Stick,
.has_dvb = 1,
+ .ir_codes = RC_MAP_NEC_TERRATEC_CINERGY_XS,
#if 0
.tuner_type = TUNER_PHILIPS_TDA8290,
.tuner_addr = 0x41,
--
1.7.10.2
--
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
[PATCH 2/2] [media] em28xx: Show a warning if the board does not support remote controls.
This simply shows a little warning if the board does not have remote
control support. This should make it easier for users to see if they
have misconfigured their system or if the driver simply does not have
rc-support for their card (yet).
---
drivers/media/video/em28xx/em28xx-input.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/video/em28xx/em28xx-input.c
b/drivers/media/video/em28xx/em28xx-input.c
index fce5f76..d94b434 100644
--- a/drivers/media/video/em28xx/em28xx-input.c
+++ b/drivers/media/video/em28xx/em28xx-input.c
@@ -527,6 +527,9 @@ static int em28xx_ir_init(struct em28xx *dev)
if (dev-board.ir_codes == NULL) {
/* No remote control support */
+ printk(No remote control support for em28xx
+ card %s (model %d) available.\n,
+ dev-name, dev-model);
return 0;
}
--
1.7.10.2
--
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/PATCH] media: Add stk1160 new driver
Hi Sylwester,
On Sat, May 26, 2012 at 4:31 PM, Sylwester Nawrocki snj...@gmail.com wrote:
You can drop this line, it's overwritten with KERNEL_VERSION in v4l2-ioctl.c.
Also I could imagine there might be better names, than dev, for
capabilities.
Yes, indeed. Starting with cap.
+ dev-capabilities =
+ V4L2_CAP_VIDEO_CAPTURE |
+ V4L2_CAP_STREAMING |
+ V4L2_CAP_READWRITE;
+ return 0;
+ f-fmt.pix.width = dev-width;
+ f-fmt.pix.height = dev-height;
+ f-fmt.pix.field = V4L2_FIELD_INTERLACED;
+ f-fmt.pix.pixelformat = dev-fmt-fourcc;
+ f-fmt.pix.bytesperline = dev-width 1;
Probably better to just write: dev-width * 2.
I saw like that in a number of places and I tought it was faster.
Guess, I was being truly naive.
Could be also done as:
*buffers = clamp(*buffers, STK1160_MIN_VIDEO_BUFFERS,
STK1160_MAX_VIDEO_BUFFERS);
Done.
+ /*
+ * videobuf2-vmalloc allocator is context-less so no need to set
+ * alloc_ctxs array.
+ */
+
+ if (v4l_fmt) {
+ stk1160_info(selected format %d (%d)\n,
+ v4l_fmt-fmt.pix.pixelformat,
+ dev-fmt-fourcc);
+ }
This log is not exactly right. You just ignore v4l_fmt, so it is not selected
anywhere. The *v4l_fmt argument is here for ioctls like VIDIOC_CREATE_BUFS,
and in case you wanted to support this ioctl you would need to do something
like:
pix = v4l_fmt-fmt.pix;
sizes[0] = pix-width * pix-height * 2;
Of course with any required sanity checks.
But this driver does not implement vidioc_create_bufs/vidioc_prepare_buf ioctl
callbacks are not, so the code is generally OK.
You're right, that was just legacy code from some early stages.
+static int buffer_prepare(struct vb2_buffer *vb)
+{
+ struct stk1160 *dev = vb2_get_drv_priv(vb-vb2_queue);
+ struct stk1160_buffer *buf =
+ container_of(vb, struct stk1160_buffer, vb);
+
+ /* If the device is disconnected, reject the buffer */
+ if (!dev-udev)
+ return -ENODEV;
+
+ buf-mem = vb2_plane_vaddr(vb, 0);
+ buf-length = vb2_plane_size(vb, 0);
Where do you check if the buffer you get from vb2 has correct parameters
for your hardware (with current settings) to start writing data to it ?
It seems that this driver supports just one pixel format and resolution,
but still would be good to do such checks in buf_prepare().
You mean I should check buf-length?
And initialization of buf-mem, buf-length is better done from
buffer_queue() op. This way there would be no need to take dev-buf_lock
spinlock also in buf_prepare() to protect the driver's buffer (queue),
which isn't done but it should in buffer_prepare() btw.
Yes, I missed this spot.
+ buf-bytesused = 0;
+ buf-pos = 0;
+
+ return 0;
+}
+
+static int buffer_finish(struct vb2_buffer *vb)
+{
+ return 0;
+}
+
+static void buffer_cleanup(struct vb2_buffer *vb)
+{
+}
buf_init, buf_finish, buf_cleanup are optional callbacks, so if you
don't use them they could be removed altogether.
Done.
+
+static void buffer_queue(struct vb2_buffer *vb)
+{
+ unsigned long flags = 0;
+ struct stk1160 *dev = vb2_get_drv_priv(vb-vb2_queue);
+ struct stk1160_buffer *buf =
+ container_of(vb, struct stk1160_buffer, vb);
+
+ spin_lock_irqsave(dev-buf_lock, flags);
+ if (!dev-udev) {
+ /*
+ * If the device is disconnected return the buffer to userspace
+ * directly. The next QBUF call will fail with -ENODEV.
+ */
+ vb2_buffer_done(buf-vb, VB2_BUF_STATE_ERROR);
+ } else {
+ list_add_tail(buf-list,dev-avail_bufs);
+ }
+ spin_unlock_irqrestore(dev-buf_lock, flags);
+}
--
Regards,
Sylwester
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: [RFC/PATCH] media: Add stk1160 new driver
Hi Ezequiel,
On 05/27/2012 11:32 PM, Ezequiel Garcia wrote:
+static int buffer_prepare(struct vb2_buffer *vb)
+{
+struct stk1160 *dev = vb2_get_drv_priv(vb-vb2_queue);
+struct stk1160_buffer *buf =
+container_of(vb, struct stk1160_buffer, vb);
+
+/* If the device is disconnected, reject the buffer */
+if (!dev-udev)
+return -ENODEV;
+
+buf-mem = vb2_plane_vaddr(vb, 0);
+buf-length = vb2_plane_size(vb, 0);
Where do you check if the buffer you get from vb2 has correct parameters
for your hardware (with current settings) to start writing data to it ?
It seems that this driver supports just one pixel format and resolution,
but still would be good to do such checks in buf_prepare().
You mean I should check buf-length?
Yeah, you should validate the passed in vb2_buffer. Here is some example:
http://lxr.linux.no/#linux+v3.4/drivers/media/video/mx2_emmaprp.c#L715
IOW, you should compare value returned from vb2_plane_vaddr(vb, 0) during
streaming with value computed from pixel format and resolution -
configured with S_FMT. Rather than accepting any buffer passed to the driver
from user space.
Regards,
Sylwester
--
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: DVB USB: change USB stream settings dynamically
On 27.05.2012 19:43, Gianluca Gennari wrote: Hi Antti, Il 27/05/2012 15:10, Antti Palosaari ha scritto: On 26.05.2012 01:47, Antti Palosaari wrote: I was planning make DVB USB be able to switch USB streaming parameters dynamically. I mean [struct usb_data_stream_properties] parameters. Currently it reserves USB streaming buffers when device is plugged. Own buffer is reserved for each frontend, which means currently 1-3 streaming buffers depending on device. Basically I see USB TS as a DVB USB device property - not property of frontend. USB TS is interface between computer and USB-bridge and amount of parallel USB TS or TS configurations depends on USB-bridge capabilities. Sometimes used USB TS could be configured to fit better used stream. Smaller buffers for the narrow radio stream and biggest buffers for the wide DVB-S2 stream. I was wondering how to resolve that situation? It is not very big problem currently but I still want to make it better as there is surely coming new devices that needs better control for the USB streaming parameters. Currently there is mxl111sf driver which seems to offer 6 different streaming configurations but AFAIK only three is currently used as there is 3 frontends and each one has own streaming parameters - and buffers - even only one can be used at the time. 1. Configure streaming parameters (alloc buffers) every time when streaming is started? IIRC that causes some problems lately for em28xx as memory goes dis-coherent and buffers cannot allocated. 2. Allocate buffers (streaming configuration) for all needed device use configurations at very beginning. Then add some logic to map streaming config to frontend at runtime. That is quite near what mxl111sf does currently. After looking existing code carefully and doing some tests I think I will implement that a way it changes buffers at runtime to fit current needs. int usb_urb_submit(struct usb_data_stream *stream) is called when streaming is started. At that point it is possible to compare already reserved buffers and buffers needed. If needed buffers are larger it is possible to reallocate bigger buffers. Of course it is not needed to decrease buffers even smaller stream configurations is asked, just to avoid repetitive allocations of large chunks of coherent memory. I have a patch that enables a similar behavior on the em28xx driver (for digital devices). I used it to play with the buffer size in order to determine the minimum working size. I added a couple of parameters to the em28xx module that can be used to change the buffer number and size at runtime. If anybody is interested, I can post this patch to the list for comments. Maybe there is no idea of merge it but it could be interesting to see still. 1) allocate buffers at the init as now (callback to read stream properties from the driver) 2) re-allocate bigger buffers in runtime if needed (callback to read stream properties from the driver) 3) free all buffers when device is disconnected I think the deciding factor here is the ratio between the default initial size and the maximum buffer size. If it is something like 2X, then maybe it's better to keep the code simple and just allocate the bigger size from the beginning. If the difference is an order of magnitude or more, then using dynamic allocation is probably worth the effort. The problem is here driver author could make buffer size calculation error easily :) But as it will likely crash very soon or at least some other effects like broken stream it should never go to the public. And it is cheap to add check for that too, just few lines of code that compares buffer sizes when streaming is started. I think I will go to that as it is very simple. Another possibility is to allocate a single memory pool of coherent memory at the init, big enough to cover all the possible modes for the given device. Then it is possible to map the URB buffers into this memory pool at runtime, choosing the optimal size for each mode. The memory pool is freed when the device is disconnected. This approach avoids any reallocation so it's safer on ARM/MIPS hardware. I do not see any difference to the situation largest needed buffers are reserved at the device initialization unless dynamically re-allocate. But I am going to skip it as it is easier to alloc just as big buffer as needed at worst case. For example, the as102 driver allocates a single memory pool in dev-stream, then it maps the URB buffers into this area (see function as102_alloc_usb_stream_buffer() ). In this case the URBs are mapped statically, but nothing prevents to dynamically remap the URB buffers at runtime if needed. I should look that driver too. But it sounds a little bit more complex to implement than alloc own buffer in the loop for every used URB. There is also drawback that it needs very large, 5-6 times larger, coherent chunk than per URB buffer. Basically those USB buffers are type of (buffer count) x (buffer size).
