Re: [PATCH v2] media: v4l2-ctrls: add control for test pattern
On Fri September 7 2012 20:20:51 Sakari Ailus wrote:
Hi Prabhakar,
Thanks for the patch!
Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
add V4L2_CID_TEST_PATTERN of type menu, which determines
the internal test pattern selected by the device.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Rob Landley r...@landley.net
---
This patches has one checkpatch warning for line over
80 characters altough it can be avoided I have kept it
for consistency.
Changes for v2:
1: Included display devices in the description for test pattern
as pointed by Hans.
2: In the menu replaced 'Test Pattern Disabled' by 'Disabled' as
pointed by Sylwester.
3: Removed the test patterns from menu as the are hardware specific
as pointed by Sakari.
Documentation/DocBook/media/v4l/controls.xml | 20
drivers/media/v4l2-core/v4l2-ctrls.c |8
include/linux/videodev2.h|4
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index ad873ea..173934e 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4311,6 +4311,26 @@ interface and may change in the future./para
/tbody
/entrytbl
/row
+ row
+ entry
spanname=idconstantV4L2_CID_TEST_PATTERN/constant/entry
+ entrymenu/entry
+ /row
+ row id=v4l2-test-pattern
+ entry spanname=descr The Capture/Display/Sensors have the
capability
+ to generate internal test patterns and this are hardware specific.
This
+ test patterns are used to test a device is properly working and can
generate
+ the desired waveforms that it supports./entry
+ /row
+ row
+ entrytbl spanname=descr cols=2
+ tbody valign=top
+ row
+entryconstantV4L2_TEST_PATTERN_DISABLED/constant/entry
+ entryTest pattern generation is disabled/entry
+ /row
+ /tbody
+ /entrytbl
+ /row
rowentry/entry/row
/tbody
/tgroup
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 8f2f40b..d731422 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -430,6 +430,10 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
Advanced,
NULL,
};
+ static const char * const test_pattern[] = {
+ Disabled,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -509,6 +513,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return jpeg_chroma_subsampling;
case V4L2_CID_DPCM_PREDICTOR:
return dpcm_predictor;
+ case V4L2_CID_TEST_PATTERN:
+ return test_pattern;
I think it's not necessary to define test_pattern (nor be prepared to
return it) since the menu is going to be device specific. So the driver
is responsible for all of the menu items. Such menus are created using
v4l2_ctrl_new_custom() instead of v4l2_ctrl_new_std_menu().
Looks good to me otherwise.
I would suggest that we *do* make this a standard control, but the menu consists
of just one item: Disabled. After creating the control you can just set the
ctrl-qmenu pointer to the device-specific menu. I like using standard controls
because they guarantee standard naming and type conventions. They are also
easier to use in an application.
This would obvious require good documentation, both in the code and in the
spec.
BTW, see also this patch that needs to use the test pattern control:
http://www.spinics.net/lists/linux-media/msg52747.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
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On Fri September 7 2012 22:00:33 Sylwester Nawrocki wrote: On 09/07/2012 03:29 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuilhans.verk...@cisco.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. +For devices without a bus it should start with the driver name, optionally Most, if not all, devices are on some sort of bus. What would be an example of a device without a bus ? Virtual devices like vivi and platform devices. Or is there some sort of platform bus? Could we just be saying here For other devices instead of For devices without a bus, or something similar ? Well, I'd like for any device on a bus to have a consistent naming convention so we can guarantee that bus_info is always unique. Regards, Hans +followed by - and an index if multiple instances of the device as possible. +Many platform devices can have only one instance, so in that case bus_info +is identical to thestructfielddriver/structfield field./entry /row row entry__u32/entry -- 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 -- 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 v2] drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c: fix error return code
From: Peter Senna Tschudin peter.se...@gmail.com
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
---
walter harms wha...@bfs.de, thanks for the tip. Please take a look carefully
to check if I got your suggestion correctly. It was tested by compilation only.
drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c | 30 ++---
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
b/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
index c8c94fb..b663dac 100644
--- a/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
+++ b/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
@@ -704,11 +704,9 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev,
int channel_select,
{
struct sram_channel *sram_ch;
u32 tmp;
- int retval = 0;
int err = 0;
int data_frame_size = 0;
int risc_buffer_size = 0;
- int str_length = 0;
if (dev-_is_running_ch2) {
pr_info(Video Channel is still running so return!\n);
@@ -744,20 +742,16 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev,
int channel_select,
risc_buffer_size = dev-_isNTSC_ch2 ?
NTSC_RISC_BUF_SIZE : PAL_RISC_BUF_SIZE;
- if (dev-input_filename_ch2) {
- str_length = strlen(dev-input_filename_ch2);
- dev-_filename_ch2 = kmemdup(dev-input_filename_ch2,
-str_length + 1, GFP_KERNEL);
-
- if (!dev-_filename_ch2)
- goto error;
- } else {
- str_length = strlen(dev-_defaultname_ch2);
- dev-_filename_ch2 = kmemdup(dev-_defaultname_ch2,
-str_length + 1, GFP_KERNEL);
+ if (dev-input_filename_ch2)
+ dev-_filename_ch2 = kstrdup(dev-input_filename_ch2,
+ GFP_KERNEL);
+ else
+ dev-_filename_ch2 = kstrdup(dev-_defaultname_ch2,
+ GFP_KERNEL);
- if (!dev-_filename_ch2)
- goto error;
+ if (!dev-_filename_ch2) {
+ err = -ENOENT;
+ goto error;
}
/* Default if filename is empty string */
@@ -773,7 +767,7 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev,
int channel_select,
}
}
- retval = cx25821_sram_channel_setup_upstream(dev, sram_ch,
+ err = cx25821_sram_channel_setup_upstream(dev, sram_ch,
dev-_line_size_ch2, 0);
/* setup fifo + format */
@@ -783,9 +777,9 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev *dev,
int channel_select,
dev-upstream_databuf_size_ch2 = data_frame_size * 2;
/* Allocating buffers and prepare RISC program */
- retval = cx25821_upstream_buffer_prepare_ch2(dev, sram_ch,
+ err = cx25821_upstream_buffer_prepare_ch2(dev, sram_ch,
dev-_line_size_ch2);
- if (retval 0) {
+ if (err 0) {
pr_err(%s: Failed to set up Video upstream buffers!\n,
dev-name);
goto error;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 05/28] DocBook: bus_info can no longer be empty.
On 09/08/2012 01:15 PM, Hans Verkuil wrote: On Fri September 7 2012 22:00:33 Sylwester Nawrocki wrote: On 09/07/2012 03:29 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com During the 2012 Media Workshop it was decided that bus_info as returned by VIDIOC_QUERYCAP can no longer be empty. It should be a unique identifier, and empty strings are obviously not unique. Signed-off-by: Hans Verkuilhans.verk...@cisco.com Reviewed-by: Sylwester Nawrockis.nawro...@samsung.com --- Documentation/DocBook/media/v4l/vidioc-querycap.xml | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd74..d5b1248 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,17 @@ ambiguities./entry entry__u8/entry entrystructfieldbus_info/structfield[32]/entry entryLocation of the device in the system, a -NUL-terminated ASCII string. For example: PCI Slot 4. This +NUL-terminated ASCII string. For example: PCI::05:06.0. This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (structfieldbus_info/structfield[0] = 0).!-- XXX pci_dev-slot_name example --/entry +identical devices. If no such information is available the field must +simply count the devices controlled by the driver (vivi-000). The bus_info +must start with PCI: for PCI boards, PCIe: for PCI Express boards, +usb- for USB devices, I2C: for i2c devices, ISA: for ISA devices and +parport for parallel port devices. +For devices without a bus it should start with the driver name, optionally Most, if not all, devices are on some sort of bus. What would be an example of a device without a bus ? Virtual devices like vivi and platform devices. Or is there some sort of platform bus? OK, then virtual devices like vivi are indeed not on any bus. But saying so, or implicitly assuming, about platform devices would have been misleading. On ASICs and SoCs such devices are on some kind of on-chip peripheral bus, e.g. AMBA APB/AHB [1]. So perhaps we could specify that for platform devices bus_info should start with platform- ? A unique remainder could be easily formed in drivers on basis of a memory mapped register region address/size and/or a device interrupt number to the CPU. However, exposing such sensitive data may be questionable, so it's probably better to just stick with a simple counter of identical devices. Could we just be saying here For other devices instead of For devices without a bus, or something similar ? Well, I'd like for any device on a bus to have a consistent naming convention so we can guarantee that bus_info is always unique. Regards, Hans +followed by - and an index if multiple instances of the device as possible. +Many platform devices can have only one instance, so in that case bus_info +is identical to thestructfielddriver/structfield field./entry /row row entry__u32/entry [1] http://www-micro.deis.unibo.it/~magagni/amba99.pdf -- 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: [RFCv2 API PATCH 13/28] Add V4L2_CAP_MONOTONIC_TS where applicable.
Le vendredi 7 septembre 2012 16:29:13, Hans Verkuil a écrit : diff --git a/drivers/media/platform/davinci/vpbe_display.c b/drivers/media/platform/davinci/vpbe_display.c index 9a05c81..3a50547 100644 --- a/drivers/media/platform/davinci/vpbe_display.c +++ b/drivers/media/platform/davinci/vpbe_display.c @@ -620,7 +620,8 @@ static int vpbe_display_querycap(struct file *file, void *priv, struct vpbe_device *vpbe_dev = fh-disp_dev-vpbe_dev; cap-version = VPBE_DISPLAY_VERSION_CODE; - cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING; + cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING | + V4L2_MONOTONIC_TS; Typo ? strlcpy(cap-driver, VPBE_DISPLAY_DRIVER, sizeof(cap-driver)); strlcpy(cap-bus_info, platform, sizeof(cap-bus_info)); strlcpy(cap-card, vpbe_dev-cfg-module_name, sizeof(cap-card)); -- Rémi Denis-Courmont http://www.remlab.net/ -- 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] Add toggle to the tt3650_rc_query function of the ttusb2 driver
This patch add the toggle bit to the tt3650_rc_query function of the ttusb2
driver.
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
Jose Albertodiff -upr linux/drivers/media/usb/dvb-usb/ttusb2.c linux.new/drivers/media/usb/dvb-usb/ttusb2.c
--- linux/drivers/media/usb/dvb-usb/ttusb2.c 2012-08-14 05:45:22.0 +0200
+++ linux.new/drivers/media/usb/dvb-usb/ttusb2.c 2012-08-23 18:33:33.459191850 +0200
@@ -440,7 +440,7 @@ static int tt3650_rc_query(struct dvb_us
/* got a press event */
st-last_rc_key = (rx[3] 8) | rx[2];
deb_info(%s: cmd=0x%02x sys=0x%02x\n, __func__, rx[2], rx[3]);
- rc_keydown(d-rc_dev, st-last_rc_key, 0);
+ rc_keydown(d-rc_dev, st-last_rc_key, rx[1]);
} else if (st-last_rc_key) {
rc_keyup(d-rc_dev);
st-last_rc_key = 0;
v42l-ctl not working correctly with a em28xx device
Hi, I was wondering if you could help me. I have an EzCAP 116 USB 2.0 Video Capture device purchased directly from http://www.ezcap.tv/ I can play audio from the device, however all my attempts to view video from it result in either a green or black screen v4l2-ctl appears to not be working correctly with it. This is illustrated by trying to set the standard on the device as shown below. Any advice on how to get both video and audio from the device would be much appreciated The device is connected to a raspberry pi running raspian: Linux raspi1 3.2.27+ #114 PREEMPT Tue Sep 4 00:15:33 BST 2012 armv6l GNU/Linux Listing the available standards shows: pi@raspi1 ~/capture $ v4l2-ctl --list-standards supported by the device shows ioctl: VIDIOC_ENUMSTD Index : 0 ID : 0xB000 Name : NTSC Frame period: 1001/3 Frame lines : 525 Index : 1 ID : 0x1000 Name : NTSC-M Frame period: 1001/3 Frame lines : 525 Index : 2 ID : 0x2000 Name : NTSC-M-JP Frame period: 1001/3 Frame lines : 525 Index : 3 ID : 0x8000 Name : NTSC-M-KR Frame period: 1001/3 Frame lines : 525 Index : 4 ID : 0x4000 Name : NTSC-443 Frame period: 1001/3 Frame lines : 525 Index : 5 ID : 0x00FF Name : PAL Frame period: 1/25 Frame lines : 625 Index : 6 ID : 0x0007 Name : PAL-BG Frame period: 1/25 Frame lines : 625 Index : 7 ID : 0x0008 Name : PAL-H Frame period: 1/25 Frame lines : 625 Index : 8 ID : 0x0010 Name : PAL-I Frame period: 1/25 Frame lines : 625 Index : 9 ID : 0x00E0 Name : PAL-DK Frame period: 1/25 Frame lines : 625 Index : 10 ID : 0x0100 Name : PAL-M Frame period: 1001/3 Frame lines : 525 Index : 11 ID : 0x0200 Name : PAL-N Frame period: 1/25 Frame lines : 625 Index : 12 ID : 0x0400 Name : PAL-Nc Frame period: 1/25 Frame lines : 625 Index : 13 ID : 0x0800 Name : PAL-60 Frame period: 1001/3 Frame lines : 525 Index : 14 ID : 0x00FF Name : SECAM Frame period: 1/25 Frame lines : 625 Index : 15 ID : 0x0001 Name : SECAM-B Frame period: 1/25 Frame lines : 625 Index : 16 ID : 0x0004 Name : SECAM-G Frame period: 1/25 Frame lines : 625 Index : 17 ID : 0x0008 Name : SECAM-H Frame period: 1/25 Frame lines : 625 Index : 18 ID : 0x0032 Name : SECAM-DK Frame period: 1/25 Frame lines : 625 Index : 19 ID : 0x0040 Name : SECAM-L Frame period: 1/25 Frame lines : 625 Index : 20 ID : 0x0080 Name : SECAM-Lc Frame period: 1/25 Frame lines : 625 If I try and set the standard to PAL-60: pi@raspi1 ~/capture $ v4l2-ctl --set-standard PAL-60 Standard set to b000 It sets the standard ID to b000 which is NTSC rather than the 800 ID associated with PAL-60 This confirmed by then reading the standard back from the device: pi@raspi1 ~/capture $ v4l2-ctl --get-standard Video Standard = 0xb000 NTSC-M/M-JP/M-KR If however I set the standard using the index for PAL-60 it correctly sets the standard: pi@raspi1 ~/capture $ v4l2-ctl --set-standard 13 Standard set to 0800 Which is confirmed by: pi@raspi1 ~/capture $ v4l2-ctl --get-standard Video Standard = 0x0800 PAL-60 The device is identified as follows by lsusb pi@raspi1 ~/capture $ lsusb -s 1:39 Bus 001 Device 039: ID eb1a:2861 eMPIA Technology, Inc. Dmesg shows the following when the device is plugged in: [37368.868492] usb 1-1.3.1.3: new high-speed USB device number 39 using dwc_otg [37368.968977] usb 1-1.3.1.3: New USB device found, idVendor=eb1a, idProduct=2861 [37368.969001] usb 1-1.3.1.3: New USB device
Re: dvb-apps scan files
Great! On Sat, Sep 8, 2012 at 12:48 AM, Hernán Rossetto hmronl...@gmail.com wrote: Please add the attached files for Argentina and Brazil to the DVB-T scan list. You will notice they have the same content already published here http://www.linuxtv.org/wiki/index.php/ISDB-T_Frequency_Table Muchas gracias! 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: [PATCH v2] drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c: fix error return code
Peter,
On Sat, Sep 8, 2012 at 11:01 AM, Peter Senna Tschudin
peter.se...@gmail.com wrote:
From: Peter Senna Tschudin peter.se...@gmail.com
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
(
if@p1 (\(ret 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// /smpl
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
---
walter harms wha...@bfs.de, thanks for the tip. Please take a look
carefully to check if I got your suggestion correctly. It was tested by
compilation only.
drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c | 30
++---
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
b/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
index c8c94fb..b663dac 100644
--- a/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
+++ b/drivers/media/pci/cx25821/cx25821-video-upstream-ch2.c
@@ -704,11 +704,9 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev
*dev, int channel_select,
{
struct sram_channel *sram_ch;
u32 tmp;
- int retval = 0;
int err = 0;
int data_frame_size = 0;
int risc_buffer_size = 0;
- int str_length = 0;
if (dev-_is_running_ch2) {
pr_info(Video Channel is still running so return!\n);
@@ -744,20 +742,16 @@ int cx25821_vidupstream_init_ch2(struct cx25821_dev
*dev, int channel_select,
risc_buffer_size = dev-_isNTSC_ch2 ?
NTSC_RISC_BUF_SIZE : PAL_RISC_BUF_SIZE;
- if (dev-input_filename_ch2) {
- str_length = strlen(dev-input_filename_ch2);
- dev-_filename_ch2 = kmemdup(dev-input_filename_ch2,
-str_length + 1, GFP_KERNEL);
-
- if (!dev-_filename_ch2)
- goto error;
- } else {
- str_length = strlen(dev-_defaultname_ch2);
- dev-_filename_ch2 = kmemdup(dev-_defaultname_ch2,
-str_length + 1, GFP_KERNEL);
+ if (dev-input_filename_ch2)
+ dev-_filename_ch2 = kstrdup(dev-input_filename_ch2,
+ GFP_KERNEL);
+ else
+ dev-_filename_ch2 = kstrdup(dev-_defaultname_ch2,
+ GFP_KERNEL);
You're replacing kmemdup for kstrdup, which is great,
but that's not anywhere in the commit message.
I'm not sure if you should re-send, but you should definitely
try to have better commit messages in the future!
Not to mention you're doing two things in one patch, and that makes
very difficult to bisect.
Thanks (and sorry for the nitpick)...
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
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:Sat Sep 8 19:00:17 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: 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 linux-3.5-x86_64: WARNINGS linux-3.6-rc2-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-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
dvb bug
With recent kernels I get system freeze when running with the following hardware: Intel DX58S02 motherboard Xeon W5520 cpu Hauppauge HVR-1700 PCIe DVB-T Technisat SkyStar2 DVB-T PCI card If I run either DVB-T card on its own then everything is ok. Or if I run both cards on different motherboard and cpu then everything is ok. So seems to related to DX58S02 and/or CPU and/or some timing issue. But with both dvb cards and debug kernel, I get: ? printk + 14/18 valid_state + 131/144 mark_lock + f2/1e1 ? check_usage_backwards + 0/65 __lock_acquire + 2dc/b91 ? sched_clock + 9/d ? sched_clock_cpu + 46/13b ? trace_hardirqs_off + b/d ? cpu_clock + 3b/53 lock_acquire + 93/b1 ? dvb_dmx_swfilter + 26/104 _spin_lock + 23/53 ? dvb_dmx_swfilter + 26/104 dvb_dmx_swfilter + 26/104 videobuf_dvb_thread + b3/135 ? videobuf_dvb_thread + 0/135 kthread + 64/69 ? kthread + 0/69 kernel_thread_helper + 7/10 And at that point everything freezes (the INFO printk wasn't visible on screen but I would have thought that this should have just been an informative trace and not something which would cause system to freeze). Without debug kernel I get either system freeze or other oops. And if there is any oops then the cx23885 module is always in the trace. The user space application runs as two completely seperate instances and opens two completely (supposedly) independent devices. Can anybody make sense of the trace and point out what exactly is happening? -- 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/3] rtl28xxu: add support for FCI FC2580 silicon tuner driver
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/Kconfig| 1 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 15 +--
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 329d222..e09930c 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -142,6 +142,7 @@ config DVB_USB_RTL28XXU
select MEDIA_TUNER_FC0012 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_FC0013 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_E4000 if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_FC2580 if MEDIA_SUBDRV_AUTOSELECT
help
Say Y here to support the Realtek RTL28xxU DVB USB receiver.
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index d0d23f2..f195b77 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -31,6 +31,7 @@
#include fc0012.h
#include fc0013.h
#include e4000.h
+#include fc2580.h
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -576,10 +577,11 @@ static int rtl2832u_frontend_attach(struct
dvb_usb_adapter *adap)
ret = rtl28xxu_ctrl_msg(d, req_fc2580);
if (ret == 0 buf[0] == 0x56) {
priv-tuner = TUNER_RTL2832_FC2580;
- /* TODO implement tuner */
+ /* FIXME: do not abuse fc0012 settings */
+ rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
dev_info(d-udev-dev, %s: FC2580 tuner found,
KBUILD_MODNAME);
- goto unsupported;
+ goto found;
}
/* check MT2063 ID register; reg=00 val=9e || 9c */
@@ -753,6 +755,11 @@ static const struct e4000_config rtl2832u_e4000_config = {
.clock = 2880,
};
+static const struct fc2580_config rtl2832u_fc2580_config = {
+ .i2c_addr = 0x56,
+ .clock = 16384000,
+};
+
static int rtl2832u_tuner_attach(struct dvb_usb_adapter *adap)
{
int ret;
@@ -785,6 +792,10 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter
*adap)
fe = dvb_attach(e4000_attach, adap-fe[0], d-i2c_adap,
rtl2832u_e4000_config);
break;
+ case TUNER_RTL2832_FC2580:
+ fe = dvb_attach(fc2580_attach, adap-fe[0], d-i2c_adap,
+ rtl2832u_fc2580_config);
+ break;
default:
fe = NULL;
dev_err(d-udev-dev, %s: unknown tuner=%d\n, KBUILD_MODNAME,
--
1.7.11.4
--
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/3] FCI FC2580 silicon tuner driver
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/Kconfig | 7 +
drivers/media/tuners/Makefile | 1 +
drivers/media/tuners/fc2580.c | 524 +
drivers/media/tuners/fc2580.h | 52
drivers/media/tuners/fc2580_priv.h | 134 ++
5 files changed, 718 insertions(+)
create mode 100644 drivers/media/tuners/fc2580.c
create mode 100644 drivers/media/tuners/fc2580.h
create mode 100644 drivers/media/tuners/fc2580_priv.h
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index f9e299c..622375e 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -229,6 +229,13 @@ config MEDIA_TUNER_E4000
help
Elonics E4000 silicon tuner driver.
+config MEDIA_TUNER_FC2580
+ tristate FCI FC2580 silicon tuner
+ depends on MEDIA_SUPPORT I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ FCI FC2580 silicon tuner driver.
+
config MEDIA_TUNER_TUA9001
tristate Infineon TUA 9001 silicon tuner
depends on MEDIA_SUPPORT I2C
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index 9f7b2c2..5e569b1 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
obj-$(CONFIG_MEDIA_TUNER_TDA18212) += tda18212.o
obj-$(CONFIG_MEDIA_TUNER_E4000) += e4000.o
+obj-$(CONFIG_MEDIA_TUNER_FC2580) += fc2580.o
obj-$(CONFIG_MEDIA_TUNER_TUA9001) += tua9001.o
obj-$(CONFIG_MEDIA_TUNER_FC0011) += fc0011.o
obj-$(CONFIG_MEDIA_TUNER_FC0012) += fc0012.o
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
new file mode 100644
index 000..afc0491
--- /dev/null
+++ b/drivers/media/tuners/fc2580.c
@@ -0,0 +1,524 @@
+/*
+ * FCI FC2580 silicon tuner driver
+ *
+ * Copyright (C) 2012 Antti Palosaari cr...@iki.fi
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License along
+ *with this program; if not, write to the Free Software Foundation, Inc.,
+ *51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include fc2580_priv.h
+
+/*
+ * TODO:
+ * I2C write and read works only for one single register. Multiple registers
+ * could not be accessed using normal register address auto-increment.
+ * There could be (very likely) register to change that behavior
+ *
+ * Due to that limitation functions:
+ * fc2580_wr_regs()
+ * fc2580_rd_regs()
+ * could not be used for accessing more than one register at once.
+ *
+ * TODO:
+ * Currently it blind writes bunch of static registers from the
+ * fc2580_freq_regs_lut[] when fc2580_set_params() is called. Add some
+ * logic to reduce unneeded register writes.
+ * There is also don't-care registers, initialized with value 0xff, and those
+ * are also written to the chip currently (yes, not wise).
+ */
+
+/* write multiple registers */
+static int fc2580_wr_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
+{
+ int ret;
+ u8 buf[1 + len];
+ struct i2c_msg msg[1] = {
+ {
+ .addr = priv-cfg-i2c_addr,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf,
+ }
+ };
+
+ buf[0] = reg;
+ memcpy(buf[1], val, len);
+
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (ret == 1) {
+ ret = 0;
+ } else {
+ dev_warn(priv-i2c-dev, %s: i2c wr failed=%d reg=%02x \
+ len=%d\n, KBUILD_MODNAME, ret, reg, len);
+ ret = -EREMOTEIO;
+ }
+ return ret;
+}
+
+/* read multiple registers */
+static int fc2580_rd_regs(struct fc2580_priv *priv, u8 reg, u8 *val, int len)
+{
+ int ret;
+ u8 buf[len];
+ struct i2c_msg msg[2] = {
+ {
+ .addr = priv-cfg-i2c_addr,
+ .flags = 0,
+ .len = 1,
+ .buf = reg,
+ }, {
+ .addr = priv-cfg-i2c_addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(buf),
+ .buf = buf,
+ }
+ };
+
+ ret = i2c_transfer(priv-i2c, msg, 2);
+ if (ret == 2) {
+ memcpy(val, buf, len);
+
[PATCH 3/3] rtl28xxu: Dexatek DK DVB-T Dongle [1d19:1101]
It is RTL2832U + FC2580 reference design.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-core/dvb-usb-ids.h| 1 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index fed6dcd..d572307 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -24,6 +24,7 @@
#define USB_VID_COMPRO_UNK 0x145f
#define USB_VID_CONEXANT 0x0572
#define USB_VID_CYPRESS0x04b4
+#define USB_VID_DEXATEK0x1d19
#define USB_VID_DIBCOM 0x10b8
#define USB_VID_DPOSH 0x1498
#define USB_VID_DVICO 0x0fe9
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index f195b77..a62238f 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1249,6 +1249,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl2832u_props, Realtek RTL2832U reference design, NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
+ { DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
+ rtl2832u_props, Dexatek DK DVB-T Dongle, NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.7.11.4
--
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: go7007 question
On Fri, Sep 07, 2012 at 06:18:31PM +0400, vol...@telros.ru wrote: On Thu, Sep 06, 2012 at 11:10:14PM +0400, Volokh Konstantin wrote: On Mon, Sep 03, 2012 at 02:37:16PM -0400, Adam Rosi-Kessel wrote: [469.928881] wis-saa7115: initializing SAA7115 at address 32 on WIS GO7007SB EZ-USB [469.989083] go7007: probing for module i2c:wis_saa7115 failed [470.004785] wis-uda1342: initializing UDA1342 at address 26 on WIS GO7007SB EZ-USB [470.005454] go7007: probing for module i2c:wis_uda1342 failed [470.011659] wis-sony-tuner: initializing tuner at address 96 on WIS GO7007SB EZ-USB Hi, I generated patchs, that u may in your own go7007/ folder It contains go7007 initialization and i2c_subdev fixing It was checked for 3.6 branch (compile only) So I have this installed now (patched with your 3.6 patch) but I'm not seeing the device. The module is there: [ 416.189030] Linux media interface: v0.10 [ 416.198616] Linux video capture interface: v2.00 [ 416.220656] wis_uda1342: module is from the staging directory, the quality is unknown, you have been warned. # lsmod|grep -i go7 go7007_usb 10059 0 go7007 46966 1 go7007_usb v4l2_common 4206 1 go7007 videodev 78250 2 go7007,v4l2_common # uname -a Linux storage 3.6.0-rc4.ajk+ #5 SMP Sat Sep 8 22:05:57 EDT 2012 i686 GNU/Linux # grep -i go7 /boot/config-`uname -r` CONFIG_VIDEO_GO7007=m CONFIG_VIDEO_GO7007_USB=m CONFIG_VIDEO_GO7007_OV7640=m # CONFIG_VIDEO_GO7007_SAA7113 is not set # CONFIG_VIDEO_GO7007_SAA7115 is not set CONFIG_VIDEO_GO7007_TW9903=m CONFIG_VIDEO_GO7007_UDA1342=m CONFIG_VIDEO_GO7007_SONY_TUNER=m CONFIG_VIDEO_GO7007_TW2804=m But I'm not getting any device to appear: # ls /dev/video* ls: cannot access /dev/video*: No such file or directory # gorecord -format mpeg4 test.avi Driver loaded but no GO7007 devices found. Is the device connected properly? When I connect the device I see this: [ 585.705406] usb 1-4: udev 4, busnum 1, minor = 3 [ 585.705412] usb 1-4: New USB device found, idVendor=093b, idProduct=a004 [ 585.705415] usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 585.705532] usb 1-4: usb_probe_device [ 585.705535] usb 1-4: configuration #1 chosen from 1 choice [ 585.706233] usb 1-4: adding 1-4:1.0 (config #1, interface 0) But no video node. Am I missing something? Adam -- 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
