uvcvideo: IR camera lights only every second frame
Hi, I have a Dell Lattitude 7280 with two webcams. The standard one works fine (/dev/video0). The other one is an IR camera (/dev/video1). The camera proper works fine and produces 340x374 frames. But there is an IR led supposed to light the object. The video is 30fps, but the LED seems to emit light only on half of the frames, i.e. on every second frame (15 fps). This makes the video blink a lot. The two consecutive frames look like: https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0002.jpg https://www.fi.muni.cz/~xslaby/sklad/mpv-shot0003.jpg Do you have any ideas what to check/test? $ v4l2-ctl --all -d /dev/video2 Driver Info (not using libv4l2): Driver name : uvcvideo Card type : Integrated_Webcam_HD: Integrate Bus info : usb-:00:14.0-5 Driver version: 4.18.15 Capabilities : 0x84A1 Video Capture Metadata Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x0421 Video Capture Streaming Extended Pix Format Priority: 2 Video input : 0 (Camera 11: ok) Format Video Capture: Width/Height : 340/374 Pixel Format : 'YUYV' Field : None Bytes per Line: 680 Size Image: 254320 Colorspace: sRGB Transfer Function : Default (maps to sRGB) YCbCr/HSV Encoding: Default (maps to ITU-R 601) Quantization : Default (maps to Limited Range) Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 340, Height 374 Default : Left 0, Top 0, Width 340, Height 374 Pixel Aspect: 1/1 Selection: crop_default, Left 0, Top 0, Width 340, Height 374 Selection: crop_bounds, Left 0, Top 0, Width 340, Height 374 Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 30.000 (30/1) Read buffers : 0 $ lsusb -vs 1:3 Bus 001 Device 003: ID 0bda:5691 Realtek Semiconductor Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x5691 bcdDevice 60.12 iManufacturer 3 CNFGE16N5214300025C2 iProduct1 Integrated_Webcam_HD iSerial 2 0001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 1041 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 4 USB Camera bmAttributes 0x80 (Bus Powered) MaxPower 500mA ** UNRECOGNIZED: 28 ff 42 49 53 54 00 01 06 06 10 00 00 00 00 00 01 07 f4 01 02 08 f4 01 03 09 f4 01 04 0a f4 01 05 0b f4 01 06 0c e8 03 Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 14 Video bFunctionSubClass 3 Video Interface Collection bFunctionProtocol 0 iFunction 5 Integrated Webcam Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass14 Video bInterfaceSubClass 1 Video Control bInterfaceProtocol 0 iInterface 5 Integrated Webcam VideoControl Interface Descriptor: bLength13 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdUVC 1.00 wTotalLength 107 dwClockFrequency 15.00MHz bInCollection 1 baInterfaceNr( 0) 1 VideoControl Interface Descriptor: bLength18 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Camera Sensor bAssocTerminal 0 iTerminal 0 wObjectiveFocalLengthMin 0 wObjectiveFocalLengthMax 0 wOcularFocalLength0 bControlSize 3 bmControls 0x000e Auto-Exposure Mode Auto-Exposure Priority Exposure Time (Absolute) VideoControl Interface Descriptor: bLength11 bDescriptorType36 bDescriptorSubtype 5 (PROCESSING_UNIT) Warning: Descriptor too short bUnitID 2 bSourceID 1
[PATCH] media: radio-cadet, initialize timer with setup_timer
From: Matej Hulín
Stop accessing timer struct members directly and use the setup_timer
helper intended for that use. It makes the code cleaner and will allow
for easier change of the timer struct internals.
Signed-off-by: Matej Hulín
Signed-off-by: Jiri Slaby
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Cc:
---
drivers/media/radio/radio-cadet.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 82affaedf067..cbaf850f4791 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -309,9 +309,7 @@ static void cadet_handler(unsigned long data)
/*
* Clean up and exit
*/
- init_timer(&dev->readtimer);
- dev->readtimer.function = cadet_handler;
- dev->readtimer.data = data;
+ setup_timer(&dev->readtimer, cadet_handler, data);
dev->readtimer.expires = jiffies + msecs_to_jiffies(50);
add_timer(&dev->readtimer);
}
@@ -320,9 +318,7 @@ static void cadet_start_rds(struct cadet *dev)
{
dev->rdsstat = 1;
outb(0x80, dev->io);/* Select RDS fifo */
- init_timer(&dev->readtimer);
- dev->readtimer.function = cadet_handler;
- dev->readtimer.data = (unsigned long)dev;
+ setup_timer(&dev->readtimer, cadet_handler, (unsigned long)dev);
dev->readtimer.expires = jiffies + msecs_to_jiffies(50);
add_timer(&dev->readtimer);
}
--
2.11.0
--
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/1] DVB-USB: dib0700, fix oops with non-dib7000pc devices
These devices use different internal structures (dib7000m) and
dib7000p pid ctrl accesses invalid members causing kernel to die.
Introduce pid control functions for dib7000m which operate on the
correct structure.
The oops it fixes:
BUG: unable to handle kernel NULL pointer dereference at 0012
IP: [] i2c_transfer+0x17/0x140
PGD 13dcbb067 PUD 13e3c9067 PMD 0
Oops: [#1] PREEMPT SMP
...
Modules linked in: ...
Pid: 3511, comm: kaffeine Tainted: G M 2.6.34.8-0.1-desktop #1
NITU1/20023
RIP: 0010:[] [] i2c_transfer+0x17/0x140
RSP: 0018:88011ce59bc8 EFLAGS: 00010292
RAX: 88011ce59c38 RBX: 0002 RCX: 1cda
RDX: 0002 RSI: 88011ce59c18 RDI: 0002
...
CR2: 0012 CR3: 00011ce53000 CR4: 000406e0
Process kaffeine (pid: 3511, threadinfo 88011ce58000, task 88009a40c700)
Stack:
...
Call Trace:
[] dib7000p_read_word+0x6f/0xd0 [dib7000p]
[] dib7000p_pid_filter_ctrl+0x42/0xb0 [dib7000p]
[] dvb_usb_ctrl_feed+0x151/0x170 [dvb_usb]
[] dmx_ts_feed_start_filtering+0x5b/0xe0 [dvb_core]
...
Code: a6 f9 ff 48 83 c4 18 c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 56
41 89 d6 41 55 49 89 f5 41 54 55 53 48 89 fb 48 83 ec 18 <48> 8b 47 10 48 83 38
00 0f 84 c8 00 00 00 65 48 8b 04 25 40 b5
Signed-off-by: Jiri Slaby
---
drivers/media/dvb/dvb-usb/dib0700_devices.c | 18 +-
drivers/media/dvb/frontends/dib7000m.c | 19 +++
drivers/media/dvb/frontends/dib7000m.h | 16
3 files changed, 52 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index c6022af..23fe0c3 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -80,6 +80,9 @@ static struct dib3000mc_config bristol_dib3000mc_config[2] = {
}
};
+static int stk70x0m_pid_filter(struct dvb_usb_adapter *adapter, int index, u16
pid, int onoff);
+static int stk70x0m_pid_filter_ctrl(struct dvb_usb_adapter *adapter, int
onoff);
+
static int bristol_frontend_attach(struct dvb_usb_adapter *adap)
{
struct dib0700_state *st = adap->dev->priv;
@@ -686,8 +689,11 @@ static int stk7700p_frontend_attach(struct dvb_usb_adapter
*adap)
if (dib7000pc_detection(&adap->dev->i2c_adap)) {
adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap,
18, &stk7700p_dib7000p_config);
st->is_dib7000pc = 1;
- } else
+ } else {
adap->fe = dvb_attach(dib7000m_attach, &adap->dev->i2c_adap,
18, &stk7700p_dib7000m_config);
+ adap->props.pid_filter = stk70x0m_pid_filter;
+ adap->props.pid_filter_ctrl = stk70x0m_pid_filter_ctrl;
+ }
return adap->fe == NULL ? -ENODEV : 0;
}
@@ -882,6 +888,16 @@ static int stk70x0p_pid_filter_ctrl(struct dvb_usb_adapter
*adapter, int onoff)
return dib7000p_pid_filter_ctrl(adapter->fe, onoff);
}
+static int stk70x0m_pid_filter(struct dvb_usb_adapter *adapter, int index, u16
pid, int onoff)
+{
+ return dib7000m_pid_filter(adapter->fe, index, pid, onoff);
+}
+
+static int stk70x0m_pid_filter_ctrl(struct dvb_usb_adapter *adapter, int onoff)
+{
+ return dib7000m_pid_filter_ctrl(adapter->fe, onoff);
+}
+
static struct dibx000_bandwidth_config dib7070_bw_config_12_mhz = {
6, 15000,
1, 20, 3, 1, 0,
diff --git a/drivers/media/dvb/frontends/dib7000m.c
b/drivers/media/dvb/frontends/dib7000m.c
index c7f5ccf..90d9411 100644
--- a/drivers/media/dvb/frontends/dib7000m.c
+++ b/drivers/media/dvb/frontends/dib7000m.c
@@ -1372,6 +1372,25 @@ error:
}
EXPORT_SYMBOL(dib7000m_attach);
+int dib7000m_pid_filter_ctrl(struct dvb_frontend *fe, u8 onoff)
+{
+ struct dib7000m_state *state = fe->demodulator_priv;
+ u16 val = dib7000m_read_word(state, 235) & 0xffef;
+ val |= (onoff & 0x1) << 4;
+ dprintk("PID filter enabled %d", onoff);
+ return dib7000m_write_word(state, 235, val);
+}
+EXPORT_SYMBOL(dib7000m_pid_filter_ctrl);
+
+int dib7000m_pid_filter(struct dvb_frontend *fe, u8 id, u16 pid, u8 onoff)
+{
+ struct dib7000m_state *state = fe->demodulator_priv;
+ dprintk("PID filter: index %x, PID %d, OnOff %d", id, pid, onoff);
+ return dib7000m_write_word(state, 241 + id,
+ onoff ? (1 << 13) | pid : 0);
+}
+EXPORT_SYMBOL(dib7000m_pid_filter);
+
static struct dvb_frontend_ops dib7000m_ops = {
.info = {
.name = "DiBcom 7000MA/MB/PA/PB/MC",
diff --git a/drivers/media/dvb/frontends/dib7000m.h
b/drivers/media/dvb/frontends/dib7000m.h
index 113819c..3353f5a 100644
--- a/drivers/media/dvb/frontends/dib7000m.h
+++ b/drivers/media/dvb/frontends/dib7000m.h
@@ -46,6 +46,8 @@ extern struct
Re: [PATCH 1/1] DVB-USB: dib0700, fix oops with non-dib7000pc devices
Hmm, could anybody pick it up?
On 02/05/2011 07:20 PM, Jiri Slaby wrote:
> These devices use different internal structures (dib7000m) and
> dib7000p pid ctrl accesses invalid members causing kernel to die.
>
> Introduce pid control functions for dib7000m which operate on the
> correct structure.
>
> The oops it fixes:
> BUG: unable to handle kernel NULL pointer dereference at 0012
> IP: [] i2c_transfer+0x17/0x140
> PGD 13dcbb067 PUD 13e3c9067 PMD 0
> Oops: [#1] PREEMPT SMP
> ...
> Modules linked in: ...
> Pid: 3511, comm: kaffeine Tainted: G M 2.6.34.8-0.1-desktop #1
> NITU1/20023
> RIP: 0010:[] [] i2c_transfer+0x17/0x140
> RSP: 0018:88011ce59bc8 EFLAGS: 00010292
> RAX: 88011ce59c38 RBX: 0002 RCX: 1cda
> RDX: 0002 RSI: 88011ce59c18 RDI: 0002
> ...
> CR2: 0012 CR3: 00011ce53000 CR4: 000406e0
> Process kaffeine (pid: 3511, threadinfo 88011ce58000, task
> 88009a40c700)
> Stack:
> ...
> Call Trace:
> [] dib7000p_read_word+0x6f/0xd0 [dib7000p]
> [] dib7000p_pid_filter_ctrl+0x42/0xb0 [dib7000p]
> [] dvb_usb_ctrl_feed+0x151/0x170 [dvb_usb]
> [] dmx_ts_feed_start_filtering+0x5b/0xe0 [dvb_core]
> ...
> Code: a6 f9 ff 48 83 c4 18 c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 56
> 41 89 d6 41 55 49 89 f5 41 54 55 53 48 89 fb 48 83 ec 18 <48> 8b 47 10 48 83
> 38 00 0f 84 c8 00 00 00 65 48 8b 04 25 40 b5
>
> Signed-off-by: Jiri Slaby
> ---
> drivers/media/dvb/dvb-usb/dib0700_devices.c | 18 +-
> drivers/media/dvb/frontends/dib7000m.c | 19 +++
> drivers/media/dvb/frontends/dib7000m.h | 16
> 3 files changed, 52 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
> b/drivers/media/dvb/dvb-usb/dib0700_devices.c
> index c6022af..23fe0c3 100644
> --- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
> +++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
> @@ -80,6 +80,9 @@ static struct dib3000mc_config bristol_dib3000mc_config[2]
> = {
> }
> };
>
> +static int stk70x0m_pid_filter(struct dvb_usb_adapter *adapter, int index,
> u16 pid, int onoff);
> +static int stk70x0m_pid_filter_ctrl(struct dvb_usb_adapter *adapter, int
> onoff);
> +
> static int bristol_frontend_attach(struct dvb_usb_adapter *adap)
> {
> struct dib0700_state *st = adap->dev->priv;
> @@ -686,8 +689,11 @@ static int stk7700p_frontend_attach(struct
> dvb_usb_adapter *adap)
> if (dib7000pc_detection(&adap->dev->i2c_adap)) {
> adap->fe = dvb_attach(dib7000p_attach, &adap->dev->i2c_adap,
> 18, &stk7700p_dib7000p_config);
> st->is_dib7000pc = 1;
> - } else
> + } else {
> adap->fe = dvb_attach(dib7000m_attach, &adap->dev->i2c_adap,
> 18, &stk7700p_dib7000m_config);
> + adap->props.pid_filter = stk70x0m_pid_filter;
> + adap->props.pid_filter_ctrl = stk70x0m_pid_filter_ctrl;
> + }
>
> return adap->fe == NULL ? -ENODEV : 0;
> }
> @@ -882,6 +888,16 @@ static int stk70x0p_pid_filter_ctrl(struct
> dvb_usb_adapter *adapter, int onoff)
> return dib7000p_pid_filter_ctrl(adapter->fe, onoff);
> }
>
> +static int stk70x0m_pid_filter(struct dvb_usb_adapter *adapter, int index,
> u16 pid, int onoff)
> +{
> + return dib7000m_pid_filter(adapter->fe, index, pid, onoff);
> +}
> +
> +static int stk70x0m_pid_filter_ctrl(struct dvb_usb_adapter *adapter, int
> onoff)
> +{
> + return dib7000m_pid_filter_ctrl(adapter->fe, onoff);
> +}
> +
> static struct dibx000_bandwidth_config dib7070_bw_config_12_mhz = {
> 6, 15000,
> 1, 20, 3, 1, 0,
> diff --git a/drivers/media/dvb/frontends/dib7000m.c
> b/drivers/media/dvb/frontends/dib7000m.c
> index c7f5ccf..90d9411 100644
> --- a/drivers/media/dvb/frontends/dib7000m.c
> +++ b/drivers/media/dvb/frontends/dib7000m.c
> @@ -1372,6 +1372,25 @@ error:
> }
> EXPORT_SYMBOL(dib7000m_attach);
>
> +int dib7000m_pid_filter_ctrl(struct dvb_frontend *fe, u8 onoff)
> +{
> + struct dib7000m_state *state = fe->demodulator_priv;
> + u16 val = dib7000m_read_word(state, 235) & 0xffef;
> + val |= (onoff & 0x1) << 4;
> + dprintk("PID filter enabled %d", onoff);
> + return dib7000m_write_word(state, 235, val);
> +}
> +EXPORT_SYMBOL(dib7000m_pid_filter_ctrl);
> +
> +int dib7000m_pid_filter(struct dvb_frontend *fe, u8 id, u16 pid, u8 onoff)
> +{
> + struct dib7000m_state *state = fe->demodulator_priv;
>
Re: [PATCH 1/1] DVB-USB: dib0700, fix oops with non-dib7000pc devices
On 02/24/2011 01:53 PM, Mauro Carvalho Chehab wrote: > Em 24-02-2011 09:24, Jiri Slaby escreveu: >> Hmm, could anybody pick it up? >> >> On 02/05/2011 07:20 PM, Jiri Slaby wrote: >>> These devices use different internal structures (dib7000m) and >>> dib7000p pid ctrl accesses invalid members causing kernel to die. >>> >>> Introduce pid control functions for dib7000m which operate on the >>> correct structure. > > Patrick (DibCom drivers maintainer) has proposed an alternate patch for it [1] > that properly address the issues: > > http://git.linuxtv.org/pb/media_tree.git?a=commitdiff;h=80a5f1fdc6beb496347cbb297f9c1458c8cb9f50 > > [1] http://www.spinics.net/lists/linux-media/msg27890.html > > Could you please test it? Yes, I will later. Is there any reason why this is not in Linus' and stable trees and mainly in linux/next already? thanks, -- js suse labs -- 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 1/1] DVB-USB: dib0700, fix oops with non-dib7000pc devices
On 02/24/2011 02:49 PM, Mauro Carvalho Chehab wrote: > Em 24-02-2011 10:41, Jiri Slaby escreveu: >> On 02/24/2011 01:53 PM, Mauro Carvalho Chehab wrote: >>> Em 24-02-2011 09:24, Jiri Slaby escreveu: >>>> Hmm, could anybody pick it up? >>>> >>>> On 02/05/2011 07:20 PM, Jiri Slaby wrote: >>>>> These devices use different internal structures (dib7000m) and >>>>> dib7000p pid ctrl accesses invalid members causing kernel to die. >>>>> >>>>> Introduce pid control functions for dib7000m which operate on the >>>>> correct structure. >>> >>> Patrick (DibCom drivers maintainer) has proposed an alternate patch for it >>> [1] >>> that properly address the issues: >>> >>> http://git.linuxtv.org/pb/media_tree.git?a=commitdiff;h=80a5f1fdc6beb496347cbb297f9c1458c8cb9f50 >>> >>> [1] http://www.spinics.net/lists/linux-media/msg27890.html >>> >>> Could you please test it? >> >> Yes, I will later. >> >> Is there any reason why this is not in Linus' and stable trees and >> mainly in linux/next already? > > Yes. I'm waiting for confirmation that this patch fixes the reported issue. Ok, it works as expected. Tested-by: Pavel SKARKA References: https://bugzilla.novell.com/show_bug.cgi?id=644807 thanks, -- js suse labs -- 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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
mem->dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU. So ensure we are
remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
by using virt_to_phys(mem->vaddr) and not mem->dma_handle.
While at it, use PFN_DOWN instead of explicit shift.
Signed-off-by: Jiri Slaby
Cc: Mauro Carvalho Chehab
Cc: Konrad Rzeszutek Wilk
---
drivers/media/video/videobuf-dma-contig.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index c969111..19d3e4a 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
retval = remap_pfn_range(vma, vma->vm_start,
-mem->dma_handle >> PAGE_SHIFT,
+PFN_DOWN(virt_to_phys(mem->vaddr))
size, vma->vm_page_prot);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
--
1.7.4.1
--
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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On 02/28/2011 11:53 AM, Laurent Pinchart wrote:
> On Monday 28 February 2011 10:37:02 Jiri Slaby wrote:
>> mem->dma_handle is a dma address obtained by dma_alloc_coherent which
>> needn't be a physical address in presence of IOMMU. So ensure we are
>> remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
>> by using virt_to_phys(mem->vaddr) and not mem->dma_handle.
>
> Quoting arch/arm/include/asm/memory.h,
>
> /*
> * These are *only* valid on the kernel direct mapped RAM memory.
Which the DMA allocation shall be.
> * Note: Drivers should NOT use these.
This is weird.
> They are the wrong
> * translation for translating DMA addresses. Use the driver
> * DMA support - see dma-mapping.h.
Yes, ACK, and vice versa. DMA addresses cannot be used as physical ones.
> */
> static inline unsigned long virt_to_phys(const volatile void *x)
> {
> return __virt_to_phys((unsigned long)(x));
> }
>
> Why would you use physically contiguous memory if you have an IOMMU anyway ?
Sorry, what? When IOMMU is used, dma_alloc_* functions may return "tags"
as a DMA address, not a physical address. So using these DMA "addresses"
directly (e.g. in remap_pfn_range) is a bug.
Maybe there is a better way to convert a kernel address of the DMA
mapping into a physical frame, but I'm not aware of any...
>> While at it, use PFN_DOWN instead of explicit shift.
>>
>> Signed-off-by: Jiri Slaby
>> Cc: Mauro Carvalho Chehab
>> Cc: Konrad Rzeszutek Wilk
>> ---
>> drivers/media/video/videobuf-dma-contig.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/media/video/videobuf-dma-contig.c
>> b/drivers/media/video/videobuf-dma-contig.c index c969111..19d3e4a 100644
>> --- a/drivers/media/video/videobuf-dma-contig.c
>> +++ b/drivers/media/video/videobuf-dma-contig.c
>> @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
>> *q,
>>
>> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
>> retval = remap_pfn_range(vma, vma->vm_start,
>> - mem->dma_handle >> PAGE_SHIFT,
>> + PFN_DOWN(virt_to_phys(mem->vaddr))
>> size, vma->vm_page_prot);
>> if (retval) {
>> dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
>
regards,
--
js
suse labs
--
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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On 02/28/2011 04:14 PM, Laurent Pinchart wrote:
> Hi Jiri,
>
> On Monday 28 February 2011 16:07:43 Jiri Slaby wrote:
>> On 02/28/2011 11:53 AM, Laurent Pinchart wrote:
>>> On Monday 28 February 2011 10:37:02 Jiri Slaby wrote:
>>>> mem->dma_handle is a dma address obtained by dma_alloc_coherent which
>>>> needn't be a physical address in presence of IOMMU. So ensure we are
>>>> remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
>>>> by using virt_to_phys(mem->vaddr) and not mem->dma_handle.
>>>
>>> Quoting arch/arm/include/asm/memory.h,
>>>
>>> /*
>>>
>>> * These are *only* valid on the kernel direct mapped RAM memory.
>>
>> Which the DMA allocation shall be.
>>
>>> * Note: Drivers should NOT use these.
>>
>> This is weird.
>>
>>> They are the wrong
>>>
>>> * translation for translating DMA addresses. Use the driver
>>> * DMA support - see dma-mapping.h.
>>
>> Yes, ACK, and vice versa. DMA addresses cannot be used as physical ones.
>>
>>> */
>>>
>>> static inline unsigned long virt_to_phys(const volatile void *x)
>>> {
>>>
>>> return __virt_to_phys((unsigned long)(x));
>>>
>>> }
>>>
>>> Why would you use physically contiguous memory if you have an IOMMU
>>> anyway ?
>>
>> Sorry, what? When IOMMU is used, dma_alloc_* functions may return "tags"
>> as a DMA address, not a physical address. So using these DMA "addresses"
>> directly (e.g. in remap_pfn_range) is a bug.
>
> What I mean is that videobuf-dma-contig is meant to be used by drivers that
> require physically contiguous memory. If the system has an IOMMU, why would
> drivers need that ?
Aha. They actually need not but they would need do the mapping
themselves which they currently do not.
IOW the vbuf-dma-contig allocator is used unconditionally in the few
drivers I checked.
BUT Even if they need only one page and use vbuf-dma-contig, which I
don't see a reason not to, it will cause problems too.
regards,
--
js
suse labs
--
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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On 02/28/2011 03:53 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Feb 28, 2011 at 10:37:02AM +0100, Jiri Slaby wrote: >> mem->dma_handle is a dma address obtained by dma_alloc_coherent which >> needn't be a physical address in presence of IOMMU. So ensure we are > > Can you add a comment why you are fixing it? Is there a bug report for this? > Under what conditions did you expose this fault? No, by a just peer review when I was looking for something completely different. > You also might want to mention that "needn't be a physical address as > a hardware IOMMU can (and most likely) will return a bus address where > physical != bus address." Mauro, do you want me to resend this with such an udpate in the changelog? > Otherwise you can stick 'Reviewed-by: Konrad Rzeszutek Wilk > ' > on it. thanks, -- js suse labs -- 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 1/1] V4L: videobuf, don't use dma addr as physical
mem->dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address as a hardware IOMMU can (and most
likely will) return a bus address where physical != bus address. So
ensure we are remapping (remap_pfn_range) the right page in
__videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not
mem->dma_handle.
While at it, use PFN_DOWN instead of explicit shift to obtain a frame
number.
This was discovered by a random review of the code when looking for
something completely different. I'm not aware of any bug reports for
this.
However it is a bug because many v4l drivers use this layer and have
no idea whether IOMMU is in the system and running or not.
Signed-off-by: Jiri Slaby
Cc: Mauro Carvalho Chehab
Cc: Konrad Rzeszutek Wilk
---
This is a version with updated changelog.
drivers/media/video/videobuf-dma-contig.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index c969111..19d3e4a 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
retval = remap_pfn_range(vma, vma->vm_start,
-mem->dma_handle >> PAGE_SHIFT,
+PFN_DOWN(virt_to_phys(mem->vaddr))
size, vma->vm_page_prot);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
--
1.7.4.1
--
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 1/1] V4L: videobuf, don't use dma addr as physical
On 03/01/2011 09:21 AM, Jiri Slaby wrote:
> mem->dma_handle is a dma address obtained by dma_alloc_coherent which
> needn't be a physical address as a hardware IOMMU can (and most
> likely will) return a bus address where physical != bus address. So
> ensure we are remapping (remap_pfn_range) the right page in
> __videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not
> mem->dma_handle.
>
> While at it, use PFN_DOWN instead of explicit shift to obtain a frame
> number.
>
> This was discovered by a random review of the code when looking for
> something completely different. I'm not aware of any bug reports for
> this.
>
> However it is a bug because many v4l drivers use this layer and have
> no idea whether IOMMU is in the system and running or not.
>
> Signed-off-by: Jiri Slaby
> Cc: Mauro Carvalho Chehab
> Cc: Konrad Rzeszutek Wilk
Ah, this is rather:
Acked-by: Konrad Rzeszutek Wilk
> ---
>
> This is a version with updated changelog.
>
> drivers/media/video/videobuf-dma-contig.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/videobuf-dma-contig.c
> b/drivers/media/video/videobuf-dma-contig.c
> index c969111..19d3e4a 100644
> --- a/drivers/media/video/videobuf-dma-contig.c
> +++ b/drivers/media/video/videobuf-dma-contig.c
> @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
> *q,
>
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> retval = remap_pfn_range(vma, vma->vm_start,
> - mem->dma_handle >> PAGE_SHIFT,
> + PFN_DOWN(virt_to_phys(mem->vaddr))
>size, vma->vm_page_prot);
> if (retval) {
> dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
--
js
--
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-apps: add scan file for Kojal, Czech Republic
# HG changeset patch # User Jiri Slaby # Date 1262532622 -3600 # Node ID 5f093a32da807e2e324e978e36ab092402aece6f # Parent a66ed623e524395f3805ce6266354f9e52913941 add scan file for Kojal, Czech Republic diff -r a66ed623e524 -r 5f093a32da80 util/scan/dvb-t/cz-Kojal --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/util/scan/dvb-t/cz-Kojal Sun Jan 03 16:30:22 2010 +0100 @@ -0,0 +1,8 @@ +# DVB-T Kojal (Brno, Czech Republic) +# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy +# CT - Ceska televize (multiplex 1) +T 53800 8MHz 2/3 NONE QAM64 8k 1/4 NONE +# CRa - Ceske radiokomunikace (multiplex 2) +T 62600 8MHz 2/3 NONE QAM64 8k 1/4 NONE +# Czech Digital Group (multiplex 3) +T 77800 8MHz 2/3 NONE QAM64 8k 1/4 NONE
Re: [PATCH 1/2] media: video/tuner-core, fix memory leak
On 01/06/2010 05:47 PM, Jiri Slaby wrote: > Stanse found a memory leak in tuner_probe. t is not > freed/assigned on all paths. Fix that. Oops. I generated two patches here, only the second is for PCI. Sorry Mauro, you got this one twice. -- js -- 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: dvb/siano, fix memory leak
Stanse found a memory leak in smscore_gpio_configure. buffer is not
freed/assigned on all paths. Fix that.
Signed-off-by: Jiri Slaby
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/siano/smscoreapi.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/siano/smscoreapi.c
b/drivers/media/dvb/siano/smscoreapi.c
index ca758bc..4bfd345 100644
--- a/drivers/media/dvb/siano/smscoreapi.c
+++ b/drivers/media/dvb/siano/smscoreapi.c
@@ -1459,8 +1459,10 @@ int smscore_gpio_configure(struct smscore_device_t
*coredev, u8 PinNum,
if (!(coredev->device_flags & SMS_DEVICE_FAMILY2)) {
pMsg->xMsgHeader.msgType = MSG_SMS_GPIO_CONFIG_REQ;
if (GetGpioPinParams(PinNum, &TranslatedPinNum, &GroupNum,
- &groupCfg) != 0)
- return -EINVAL;
+ &groupCfg) != 0) {
+ rc = -EINVAL;
+ goto free;
+ }
pMsg->msgData[1] = TranslatedPinNum;
pMsg->msgData[2] = GroupNum;
@@ -1490,6 +1492,7 @@ int smscore_gpio_configure(struct smscore_device_t
*coredev, u8 PinNum,
else
sms_err("smscore_gpio_configure error");
}
+free:
kfree(buffer);
return rc;
--
1.6.5.7
--
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: video/tuner-core, fix memory leak
Stanse found a memory leak in tuner_probe. t is not freed/assigned on all paths. Fix that. Signed-off-by: Jiri Slaby Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org --- drivers/media/video/tuner-core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index 5b3eaa1..c4dab6c 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1078,6 +1078,7 @@ static int tuner_probe(struct i2c_client *client, goto register_client; } + kfree(t); return -ENODEV; case 0x42: case 0x43: -- 1.6.5.7 -- 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: video/tuner-core, fix memory leak
Stanse found a memory leak in tuner_probe. t is not freed/assigned on all paths. Fix that. Signed-off-by: Jiri Slaby Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org --- drivers/media/video/tuner-core.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c index 5b3eaa1..c4dab6c 100644 --- a/drivers/media/video/tuner-core.c +++ b/drivers/media/video/tuner-core.c @@ -1078,6 +1078,7 @@ static int tuner_probe(struct i2c_client *client, goto register_client; } + kfree(t); return -ENODEV; case 0x42: case 0x43: -- 1.6.5.7 -- 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/1] media: dvb/zl10039, jump to error on error
Stanse found an unreachable statement in zl10039_attach. There is
a `break' followed by `goto error'. Remove that break, so that it
can handle the error.
Signed-off-by: Jiri Slaby
Cc: Igor M. Liplianin
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/frontends/zl10039.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/zl10039.c
b/drivers/media/dvb/frontends/zl10039.c
index 11b29cb..c085e58 100644
--- a/drivers/media/dvb/frontends/zl10039.c
+++ b/drivers/media/dvb/frontends/zl10039.c
@@ -287,7 +287,6 @@ struct dvb_frontend *zl10039_attach(struct dvb_frontend *fe,
break;
default:
dprintk("Chip ID=%x does not match a known type\n", state->id);
- break;
goto error;
}
--
1.6.5.7
--
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/1] media: video/cx18, fix potential null dereference
Stanse found a potential null dereference in cx18_dvb_start_feed
and cx18_dvb_stop_feed. There is a check for stream being NULL,
but it is dereferenced earlier. Move the dereference after the
check.
Signed-off-by: Jiri Slaby
---
drivers/media/video/cx18/cx18-dvb.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-dvb.c
b/drivers/media/video/cx18/cx18-dvb.c
index 71ad2d1..0ad5b63 100644
--- a/drivers/media/video/cx18/cx18-dvb.c
+++ b/drivers/media/video/cx18/cx18-dvb.c
@@ -213,10 +213,14 @@ static int cx18_dvb_start_feed(struct dvb_demux_feed
*feed)
{
struct dvb_demux *demux = feed->demux;
struct cx18_stream *stream = (struct cx18_stream *) demux->priv;
- struct cx18 *cx = stream->cx;
+ struct cx18 *cx;
int ret;
u32 v;
+ if (!stream)
+ return -EINVAL;
+
+ cx = stream->cx;
CX18_DEBUG_INFO("Start feed: pid = 0x%x index = %d\n",
feed->pid, feed->index);
@@ -253,9 +257,6 @@ static int cx18_dvb_start_feed(struct dvb_demux_feed *feed)
if (!demux->dmx.frontend)
return -EINVAL;
- if (!stream)
- return -EINVAL;
-
mutex_lock(&stream->dvb.feedlock);
if (stream->dvb.feeding++ == 0) {
CX18_DEBUG_INFO("Starting Transport DMA\n");
@@ -279,13 +280,14 @@ static int cx18_dvb_stop_feed(struct dvb_demux_feed *feed)
{
struct dvb_demux *demux = feed->demux;
struct cx18_stream *stream = (struct cx18_stream *)demux->priv;
- struct cx18 *cx = stream->cx;
+ struct cx18 *cx;
int ret = -EINVAL;
- CX18_DEBUG_INFO("Stop feed: pid = 0x%x index = %d\n",
- feed->pid, feed->index);
-
if (stream) {
+ cx = stream->cx;
+ CX18_DEBUG_INFO("Stop feed: pid = 0x%x index = %d\n",
+ feed->pid, feed->index);
+
mutex_lock(&stream->dvb.feedlock);
if (--stream->dvb.feeding == 0) {
CX18_DEBUG_INFO("Stopping Transport DMA\n");
--
1.6.5.7
--
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/1] MAINTAINERS: ivtv-devel is moderated
Mark ivtv-de...@ivtvdriver.org as 'moderated for non-subscribers'. Signed-off-by: Jiri Slaby Cc: linux-media@vger.kernel.org --- MAINTAINERS |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d4baf3d..6f088ac 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1649,7 +1649,7 @@ F:sound/pci/cs5535audio/ CX18 VIDEO4LINUX DRIVER M: Hans Verkuil M: Andy Walls -L: ivtv-de...@ivtvdriver.org +L: ivtv-de...@ivtvdriver.org (moderated for non-subscribers) L: linux-media@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git W: http://linuxtv.org @@ -3037,7 +3037,7 @@ F:drivers/isdn/hardware/eicon/ IVTV VIDEO4LINUX DRIVER M: Hans Verkuil -L: ivtv-de...@ivtvdriver.org +L: ivtv-de...@ivtvdriver.org (moderated for non-subscribers) L: linux-media@vger.kernel.org T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git W: http://www.ivtvdriver.org -- 1.6.5.7 -- 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 1/1] media: video/cx18, fix potential null dereference
On 01/12/2010 12:48 AM, Andy Walls wrote: > On Sun, 2010-01-10 at 09:56 +0100, Jiri Slaby wrote: >> Stanse found a potential null dereference in cx18_dvb_start_feed >> and cx18_dvb_stop_feed. There is a check for stream being NULL, >> but it is dereferenced earlier. Move the dereference after the >> check. >> >> Signed-off-by: Jiri Slaby > > Reviewed-by: Andy Walls > Acked-by: Andy Walls You definitely know the code better, have you checked that it can happen at all? I mean may demux->priv be NULL? -- 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 1/1] media: video/cx18, fix potential null dereference
On 01/13/2010 12:32 PM, Andy Walls wrote: > If you don't mind a delay of until Sunday or so to get the patch applied > to the V4L-DVB tree, I can take the patch and work it in my normal path > through Mauro. Let me know. I have no problem with that. thanks, -- js -- 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/1] HID: ignore afatech 9016
Let's ignore the device altogether by HID layer. It's handled by
dvb-usb-remote driver properly already.
By now, FULLSPEED_INTERVAL quirk was used. It probably made things
better, but the remote ctrl was still a perfect X killer. This was
the last user of the particular quirk. So remove the quirk as well.
With input going through dvb-usb-remote, the remote works
perfectly.
Signed-off-by: Jiri Slaby
Cc: Jiri Kosina
---
drivers/hid/usbhid/hid-core.c |8
drivers/hid/usbhid/hid-quirks.c |2 +-
include/linux/hid.h |1 -
3 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index e2997a8..36a1561 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -938,14 +938,6 @@ static int usbhid_start(struct hid_device *hid)
interval = endpoint->bInterval;
- /* Some vendors give fullspeed interval on highspeed devides */
- if (hid->quirks & HID_QUIRK_FULLSPEED_INTERVAL &&
- dev->speed == USB_SPEED_HIGH) {
- interval = fls(endpoint->bInterval*8);
- printk(KERN_INFO "%s: Fixing fullspeed to highspeed
interval: %d -> %d\n",
- hid->name, endpoint->bInterval, interval);
- }
-
/* Change the polling interval of mice. */
if (hid->collection->usage == HID_GD_MOUSE &&
hid_mousepoll_interval > 0)
interval = hid_mousepoll_interval;
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 38773dc..788d9a3 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -41,7 +41,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
- { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016,
HID_QUIRK_FULLSPEED_INTERVAL },
+ { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_IGNORE
},
{ USB_VENDOR_ID_PANTHERLORD,
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT |
HID_QUIRK_SKIP_OUTPUT_REPORTS },
{ USB_VENDOR_ID_PLAYDOTCOM, USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII,
HID_QUIRK_MULTI_INPUT },
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 8709365..4a33e16 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -311,7 +311,6 @@ struct hid_item {
#define HID_QUIRK_BADPAD 0x0020
#define HID_QUIRK_MULTI_INPUT 0x0040
#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x0001
-#define HID_QUIRK_FULLSPEED_INTERVAL 0x1000
#define HID_QUIRK_NO_INIT_REPORTS 0x2000
/*
--
1.6.5.7
--
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/1] media: dvb-usb/af9015, add IR support for digivox mini II
MSI digivox mini II works even with remote=2 module parameter. Check
for manufacturer and if it is Afatech, use af9015_ir_table_msi and
af9015_rc_keys_msi.
The device itself is 15a4:9016.
Signed-off-by: Jiri Slaby
Cc: Antti Palosaari
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/af9015.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 8b60a60..f0d5731 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -835,9 +835,15 @@ static int af9015_read_config(struct usb_device *udev)
af9015_ir_table_mygictv;
af9015_config.ir_table_size =
ARRAY_SIZE(af9015_ir_table_mygictv);
- } else if (!strcmp("MSI", manufacturer)) {
- /* iManufacturer 1 MSI
- iProduct 2 MSI K-VOX */
+ } else if (!strcmp("MSI", manufacturer) ||
+ !strcmp("Afatech", manufacturer)) {
+ /*
+ iManufacturer 1 MSI
+ iProduct 2 MSI K-VOX
+ iManufacturer 1 Afatech
+ iProduct 2 DVB-T 2
+*/
+
af9015_properties[i].rc_key_map =
af9015_rc_keys_msi;
af9015_properties[i].rc_key_map_size =
--
1.6.5.7
--
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 1/1] HID: ignore afatech 9016
On 01/13/2010 09:20 PM, Jiri Kosina wrote:
>> diff --git a/drivers/hid/usbhid/hid-quirks.c
>> b/drivers/hid/usbhid/hid-quirks.c
>> index 38773dc..788d9a3 100644
>> --- a/drivers/hid/usbhid/hid-quirks.c
>> +++ b/drivers/hid/usbhid/hid-quirks.c
>> @@ -41,7 +41,7 @@ static const struct hid_blacklist {
>> { USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
>> HID_QUIRK_BADPAD },
>> { USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
>> },
>>
>> -{ USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016,
>> HID_QUIRK_FULLSPEED_INTERVAL },
>> +{ USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_IGNORE
>> },
>
> Hmm, why do we keep HID_QUIRK_IGNORE anyway, when we already have generic
> hid_ignore_list[]?
You returned it back because of dynamic quirks...
> We don't set it for any device in the current codebase any more.
Oh yeah, it's hard for people who don't remember code they wrote :).
Will respin. Thanks for the reminder.
--
js
--
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 1/1] HID: ignore afatech 9016
Let's ignore the device altogether by the HID layer. It's handled
by dvb-usb-remote driver already.
By now, FULLSPEED_INTERVAL quirk was used. It probably made things
better, but the remote controller was still a perfect X killer.
This was the last user of the particular quirk. So remove the quirk
as well.
With input going through dvb-usb-remote, the remote works
perfectly.
The device is 15a4:9016.
Signed-off-by: Jiri Slaby
Cc: Jiri Kosina
Cc: Pekka Sarnila
---
drivers/hid/hid-core.c |1 +
drivers/hid/usbhid/hid-core.c |8
drivers/hid/usbhid/hid-quirks.c |2 --
include/linux/hid.h |1 -
4 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 08f8f23..0ae0bfd 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1534,6 +1534,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_FLAIR) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_302) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ADS_TECH,
USB_DEVICE_ID_ADS_TECH_RADIO_SI470X) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016) },
{ HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01) },
{ HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10) },
{ HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_20) },
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index e2997a8..36a1561 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -938,14 +938,6 @@ static int usbhid_start(struct hid_device *hid)
interval = endpoint->bInterval;
- /* Some vendors give fullspeed interval on highspeed devides */
- if (hid->quirks & HID_QUIRK_FULLSPEED_INTERVAL &&
- dev->speed == USB_SPEED_HIGH) {
- interval = fls(endpoint->bInterval*8);
- printk(KERN_INFO "%s: Fixing fullspeed to highspeed
interval: %d -> %d\n",
- hid->name, endpoint->bInterval, interval);
- }
-
/* Change the polling interval of mice. */
if (hid->collection->usage == HID_GD_MOUSE &&
hid_mousepoll_interval > 0)
interval = hid_mousepoll_interval;
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index 38773dc..f2ae8a7 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -41,8 +41,6 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD,
HID_QUIRK_BADPAD },
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
- { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016,
HID_QUIRK_FULLSPEED_INTERVAL },
-
{ USB_VENDOR_ID_PANTHERLORD,
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT |
HID_QUIRK_SKIP_OUTPUT_REPORTS },
{ USB_VENDOR_ID_PLAYDOTCOM, USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII,
HID_QUIRK_MULTI_INPUT },
diff --git a/include/linux/hid.h b/include/linux/hid.h
index 8709365..4a33e16 100644
--- a/include/linux/hid.h
+++ b/include/linux/hid.h
@@ -311,7 +311,6 @@ struct hid_item {
#define HID_QUIRK_BADPAD 0x0020
#define HID_QUIRK_MULTI_INPUT 0x0040
#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x0001
-#define HID_QUIRK_FULLSPEED_INTERVAL 0x1000
#define HID_QUIRK_NO_INIT_REPORTS 0x2000
/*
--
1.6.5.7
--
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/1] media: dvb-usb/af9015, fix disconnection crashes
When both remote controller and receiver intfs are handled by
af9015, .probe do nothing for remote intf, but when .disconnect
is called for both of them it touches intfdata every time. For
remote it crashes obviously (as intfdata are unset).
Altough there is test against data being NULL, it is not enough.
It is because someone before us does not set intf drvdata to
NULL. (In this case the hid layer.) But we cannot rely on intf
being NULL anyway.
Fix that by checking bInterfaceNumber in af9015_usb_device_exit
and do actually nothing if it is not 0.
The crash in question:
BUG: unable to handle kernel paging request at 000700c5
IP: [] dvb_usb_device_exit+0x39/0x60 [dvb_usb]
PGD 192344067 PUD 1921ba067 PMD 0
Oops: [#1] SMP
last sysfs file: /sys/devices/virtual/net/tun0/statistics/collisions
CPU 1
Pid: 10515, comm: rmmod Not tainted 2.6.33-rc4-mm1_64 #930 To be filled by
O.E.M./To Be Filled By O.E.M.
RIP: 0010:[] []
dvb_usb_device_exit+0x39/0x60 [dvb_usb]
RSP: 0018:88018066bd48 EFLAGS: 00010206
RAX: 000700c5 RBX: a0061c8a RCX:
RDX: RSI: RDI: 8801cab599e0
RBP: 88018066bd58 R08: 0001 R09: 0046dd74
R10: 0005 R11: 0064 R12: 8801caa14090
R13: 8801ca886360 R14: a00a8668 R15:
FS: 7fe2ec1566f0() GS:88002828() knlGS:
CS: 0010 DS: ES: CR0: 8005003b
CR2: 000700c5 CR3: 0001b126e000 CR4: 06e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process rmmod (pid: 10515, threadinfo 88018066a000, task 88019f1eb880)
Stack:
8801cab599b0 8801cab599b0 88018066bd78 a00a604c
<0> 8801ca886360 8801cab599e0 88018066bdc8 812fd844
<0> a00a8668 a00a8600 a00a8668 8801cab599e0
Call Trace:
[] af9015_usb_device_exit+0x3c/0x60 [dvb_usb_af9015]
[] usb_unbind_interface+0x124/0x170
...
Code: e8 8d 4b 22 e1 31 f6 49 89 c4 48 89 df 48 c7 c3 8a 1c 06 a0 e8 a9 4b 22
e1 4d 85 e4 74 18 49 8b 84 24 c0 0c 00 00 48 85 c0 74 0b <48> 8b 18 4c 89 e7 e8
ec fe ff ff 48 89 de 48 c7 c7 40 14 06 a0
RIP [] dvb_usb_device_exit+0x39/0x60 [dvb_usb]
RSP
CR2: 000700c5
---[ end trace f25ee66d2135f162 ]---
Signed-off-by: Jiri Slaby
Cc: Antti Palosaari
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/af9015.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index f0d5731..bd20945 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1661,6 +1661,10 @@ static void af9015_usb_device_exit(struct usb_interface
*intf)
struct dvb_usb_device *d = usb_get_intfdata(intf);
deb_info("%s: \n", __func__);
+ /* we do nothing for remote controller interface */
+ if (intf->cur_altsetting->desc.bInterfaceNumber != 0)
+ return;
+
/* remove 2nd I2C adapter */
if (d != NULL && d->desc != NULL)
af9015_i2c_exit(d);
--
1.6.5.7
--
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 4/4] media: dvb/af9015, add hashes support
So as a final patch, add support for hash and one hash entry
for MSI digi vox mini II:
iManufacturer 1 Afatech
iProduct 2 DVB-T 2
iSerial 3 01010101061
It is now handled with proper IR and key map tables.
Signed-off-by: Jiri Slaby
Cc: Antti Palosaari
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Signed-off-by: Jiri Slaby
---
drivers/media/dvb/dvb-usb/af9015.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 796f9d5..650c913 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -788,6 +788,13 @@ static const struct af9015_setup af9015_setup_usbids[] = {
{ }
};
+static const struct af9015_setup af9015_setup_hashes[] = {
+ { 0xb8feb708,
+ af9015_rc_keys_msi, ARRAY_SIZE(af9015_rc_keys_msi),
+ af9015_ir_table_msi, ARRAY_SIZE(af9015_ir_table_msi) },
+ { }
+};
+
static void af9015_set_remote_config(struct usb_device *udev,
struct dvb_usb_device_properties *props)
{
@@ -800,7 +807,10 @@ static void af9015_set_remote_config(struct usb_device
*udev,
} else {
u16 vendor = le16_to_cpu(udev->descriptor.idVendor);
- if (vendor == USB_VID_AFATECH) {
+ table = af9015_setup_match(af9015_config.eeprom_sum,
+ af9015_setup_hashes);
+
+ if (!table && vendor == USB_VID_AFATECH) {
/* Check USB manufacturer and product strings and try
to determine correct remote in case of chip vendor
reference IDs are used.
@@ -831,7 +841,7 @@ static void af9015_set_remote_config(struct usb_device
*udev,
ARRAY_SIZE(af9015_ir_table_trekstor)
};
}
- } else
+ } else if (!table)
table = af9015_setup_match(vendor, af9015_setup_usbids);
}
--
1.6.5.7
--
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/4] media: dvb/af9015, factor out remote setting
This is just a code shuffle without functional changes. For easier
review of later changes, i.e. preparation.
Signed-off-by: Jiri Slaby
Cc: Antti Palosaari
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/af9015.c | 305 ++-
1 files changed, 157 insertions(+), 148 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 616b3ba..adba90d 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -732,12 +732,166 @@ error:
return ret;
}
+static void af9015_set_remote_config(struct usb_device *udev,
+ struct dvb_usb_device_properties *props)
+{
+ if (dvb_usb_af9015_remote) {
+ /* load remote defined as module param */
+ switch (dvb_usb_af9015_remote) {
+ case AF9015_REMOTE_A_LINK_DTU_M:
+ props->rc_key_map =
+ af9015_rc_keys_a_link;
+ props->rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_a_link);
+ af9015_config.ir_table = af9015_ir_table_a_link;
+ af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_a_link);
+ break;
+ case AF9015_REMOTE_MSI_DIGIVOX_MINI_II_V3:
+ props->rc_key_map =
+ af9015_rc_keys_msi;
+ props->rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_msi);
+ af9015_config.ir_table = af9015_ir_table_msi;
+ af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_msi);
+ break;
+ case AF9015_REMOTE_MYGICTV_U718:
+ props->rc_key_map =
+ af9015_rc_keys_mygictv;
+ props->rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_mygictv);
+ af9015_config.ir_table =
+ af9015_ir_table_mygictv;
+ af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_mygictv);
+ break;
+ case AF9015_REMOTE_DIGITTRADE_DVB_T:
+ props->rc_key_map =
+ af9015_rc_keys_digittrade;
+ props->rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_digittrade);
+ af9015_config.ir_table =
+ af9015_ir_table_digittrade;
+ af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_digittrade);
+ break;
+ case AF9015_REMOTE_AVERMEDIA_KS:
+ props->rc_key_map =
+ af9015_rc_keys_avermedia;
+ props->rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_avermedia);
+ af9015_config.ir_table =
+ af9015_ir_table_avermedia_ks;
+ af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_avermedia_ks);
+ break;
+ }
+ } else {
+ switch (le16_to_cpu(udev->descriptor.idVendor)) {
+ case USB_VID_LEADTEK:
+ props->rc_key_map =
+ af9015_rc_keys_leadtek;
+ props->rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_leadtek);
+ af9015_config.ir_table =
+ af9015_ir_table_leadtek;
+ af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_leadtek);
+ break;
+ case USB_VID_VISIONPLUS:
+ props->rc_key_map =
+ af9015_rc_keys_twinhan;
+ props->rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_twinhan);
+ af9015_config.ir_table =
+ af9015_ir_table_twinhan;
+ af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_twinhan);
+ break;
+ case USB_VID_KWORLD_2:
+ /* TODO: use correct rc keys */
+ props->rc_key_map =
+ af9015_rc_keys_twinhan;
+ props->rc_key_map_size =
+ ARRAY_SIZE(af9015_rc_keys_twinhan);
+ af9015_config.ir_table = af9015_ir_table_kworld;
+ af9015_config.ir_table_size =
+ ARRAY_SIZE(af9015_ir_table_kworld);
+
[PATCH 3/4] media: dvb/af9015, refactor remote setting
Add af9015_setup structure to hold (right now only remote) setup
of distinct receivers.
Add af9015_setup_match for matching ids against tables.
This is for easier matching different kind of ids against tables
to obtain setups. Currently module parameters and usb vendor ids
are switched into and matched against tables. Hashes will follow.
Signed-off-by: Jiri Slaby
Cc: Antti Palosaari
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/af9015.c | 222 ++-
1 files changed, 89 insertions(+), 133 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index adba90d..796f9d5 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -732,98 +732,80 @@ error:
return ret;
}
+struct af9015_setup {
+ unsigned int id;
+ struct dvb_usb_rc_key *rc_key_map;
+ unsigned int rc_key_map_size;
+ u8 *ir_table;
+ unsigned int ir_table_size;
+};
+
+static const struct af9015_setup *af9015_setup_match(unsigned int id,
+ const struct af9015_setup *table)
+{
+ for (; table->rc_key_map; table++)
+ if (table->id == id)
+ return table;
+ return NULL;
+}
+
+static const struct af9015_setup af9015_setup_modparam[] = {
+ { AF9015_REMOTE_A_LINK_DTU_M,
+ af9015_rc_keys_a_link, ARRAY_SIZE(af9015_rc_keys_a_link),
+ af9015_ir_table_a_link, ARRAY_SIZE(af9015_ir_table_a_link) },
+ { AF9015_REMOTE_MSI_DIGIVOX_MINI_II_V3,
+ af9015_rc_keys_msi, ARRAY_SIZE(af9015_rc_keys_msi),
+ af9015_ir_table_msi, ARRAY_SIZE(af9015_ir_table_msi) },
+ { AF9015_REMOTE_MYGICTV_U718,
+ af9015_rc_keys_mygictv, ARRAY_SIZE(af9015_rc_keys_mygictv),
+ af9015_ir_table_mygictv, ARRAY_SIZE(af9015_ir_table_mygictv) },
+ { AF9015_REMOTE_DIGITTRADE_DVB_T,
+ af9015_rc_keys_digittrade,
ARRAY_SIZE(af9015_rc_keys_digittrade),
+ af9015_ir_table_digittrade,
ARRAY_SIZE(af9015_ir_table_digittrade) },
+ { AF9015_REMOTE_AVERMEDIA_KS,
+ af9015_rc_keys_avermedia, ARRAY_SIZE(af9015_rc_keys_avermedia),
+ af9015_ir_table_avermedia_ks,
ARRAY_SIZE(af9015_ir_table_avermedia_ks) },
+ { }
+};
+
+/* don't add new entries here anymore, use hashes instead */
+static const struct af9015_setup af9015_setup_usbids[] = {
+ { USB_VID_LEADTEK,
+ af9015_rc_keys_leadtek, ARRAY_SIZE(af9015_rc_keys_leadtek),
+ af9015_ir_table_leadtek, ARRAY_SIZE(af9015_ir_table_leadtek) },
+ { USB_VID_VISIONPLUS,
+ af9015_rc_keys_twinhan, ARRAY_SIZE(af9015_rc_keys_twinhan),
+ af9015_ir_table_twinhan, ARRAY_SIZE(af9015_ir_table_twinhan) },
+ { USB_VID_KWORLD_2, /* TODO: use correct rc keys */
+ af9015_rc_keys_twinhan, ARRAY_SIZE(af9015_rc_keys_twinhan),
+ af9015_ir_table_kworld, ARRAY_SIZE(af9015_ir_table_kworld) },
+ { USB_VID_AVERMEDIA,
+ af9015_rc_keys_avermedia, ARRAY_SIZE(af9015_rc_keys_avermedia),
+ af9015_ir_table_avermedia,
ARRAY_SIZE(af9015_ir_table_avermedia) },
+ { USB_VID_MSI_2,
+ af9015_rc_keys_msi_digivox_iii,
ARRAY_SIZE(af9015_rc_keys_msi_digivox_iii),
+ af9015_ir_table_msi_digivox_iii,
ARRAY_SIZE(af9015_ir_table_msi_digivox_iii) },
+ { }
+};
+
static void af9015_set_remote_config(struct usb_device *udev,
struct dvb_usb_device_properties *props)
{
+ const struct af9015_setup *table = NULL;
+
if (dvb_usb_af9015_remote) {
/* load remote defined as module param */
- switch (dvb_usb_af9015_remote) {
- case AF9015_REMOTE_A_LINK_DTU_M:
- props->rc_key_map =
- af9015_rc_keys_a_link;
- props->rc_key_map_size =
- ARRAY_SIZE(af9015_rc_keys_a_link);
- af9015_config.ir_table = af9015_ir_table_a_link;
- af9015_config.ir_table_size =
- ARRAY_SIZE(af9015_ir_table_a_link);
- break;
- case AF9015_REMOTE_MSI_DIGIVOX_MINI_II_V3:
- props->rc_key_map =
- af9015_rc_keys_msi;
- props->rc_key_map_size =
- ARRAY_SIZE(af9015_rc_keys_msi);
- af9015_config.ir_table = af9015_ir_table_msi;
- af9015_config.ir_table_size =
- ARRAY_SIZE(af9015_ir_table_msi);
- break;
- case AF9015_REMOTE_MYGICTV_U718:
- props->rc_key_map =
- af9015_rc_keys_mygictv;
- props->rc_key_map_size =
-
Re: [PATCH 1/1] media: dvb-usb/af9015, add IR support for digivox mini II
On 01/14/2010 08:09 PM, Antti Palosaari wrote: > Device ID 15a4:9016 is reference design ID and it is used by vary many > devices. Also manufacturer string "Afatech" is chipset default one. This > leads MSI remote in question configured for many devices using default / > reference values which I don't like good idea. Strings and other USB > settings are stored to the device eeprom. What do you think about the following patches? thanks, -- js -- 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/4] media: dvb/af9015, implement eeprom hashing
This will be useful for matching of IR tables later.
We read the eeprom anyway for dumping. Switch the dumping to
print_hex_dump_bytes and compute hash above that by
hash = 0;
for (u32 VAL) in (eeprom):
hash *= GOLDEN_RATIO_PRIME_32
hash += VAL; // while preserving endinaness
The computation is moved earlier to the flow, namely from
af9015_af9013_frontend_attach to af9015_read_config, so that
we can access the sum in af9015_read_config already.
Signed-off-by: Jiri Slaby
Cc: Antti Palosaari
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/af9015.c | 65 +++
drivers/media/dvb/dvb-usb/af9015.h |1 +
2 files changed, 44 insertions(+), 22 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index a365c05..616b3ba 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -21,6 +21,8 @@
*
*/
+#include
+
#include "af9015.h"
#include "af9013.h"
#include "mt2060.h"
@@ -553,26 +555,45 @@ exit:
return ret;
}
-/* dump eeprom */
-static int af9015_eeprom_dump(struct dvb_usb_device *d)
+/* hash (and dump) eeprom */
+static int af9015_eeprom_hash(struct usb_device *udev)
{
- u8 reg, val;
+ static const unsigned int eeprom_size = 256;
+ unsigned int reg;
+ int ret;
+ u8 val, *eeprom;
+ struct req_t req = {READ_I2C, AF9015_I2C_EEPROM, 0, 0, 1, 1, &val};
- for (reg = 0; ; reg++) {
- if (reg % 16 == 0) {
- if (reg)
- deb_info(KERN_CONT "\n");
- deb_info(KERN_DEBUG "%02x:", reg);
- }
- if (af9015_read_reg_i2c(d, AF9015_I2C_EEPROM, reg, &val) == 0)
- deb_info(KERN_CONT " %02x", val);
- else
- deb_info(KERN_CONT " --");
- if (reg == 0xff)
- break;
+ eeprom = kmalloc(eeprom_size, GFP_KERNEL);
+ if (eeprom == NULL)
+ return -ENOMEM;
+
+ for (reg = 0; reg < eeprom_size; reg++) {
+ req.addr = reg;
+ ret = af9015_rw_udev(udev, &req);
+ if (ret)
+ goto free;
+ eeprom[reg] = val;
}
- deb_info(KERN_CONT "\n");
- return 0;
+
+ if (dvb_usb_af9015_debug & 0x01)
+ print_hex_dump_bytes("", DUMP_PREFIX_OFFSET, eeprom,
+ eeprom_size);
+
+ BUG_ON(eeprom_size % 4);
+
+ af9015_config.eeprom_sum = 0;
+ for (reg = 0; reg < eeprom_size / sizeof(u32); reg++) {
+ af9015_config.eeprom_sum *= GOLDEN_RATIO_PRIME_32;
+ af9015_config.eeprom_sum += le32_to_cpu(((u32 *)eeprom)[reg]);
+ }
+
+ deb_info("%s: eeprom sum=%.8x\n", __func__, af9015_config.eeprom_sum);
+
+ ret = 0;
+free:
+ kfree(eeprom);
+ return ret;
}
static int af9015_download_ir_table(struct dvb_usb_device *d)
@@ -728,6 +749,11 @@ static int af9015_read_config(struct usb_device *udev)
}
if (ret)
goto error;
+
+ ret = af9015_eeprom_hash(udev);
+ if (ret)
+ goto error;
+
deb_info("%s: IR mode:%d\n", __func__, val);
for (i = 0; i < af9015_properties_count; i++) {
if (val == AF9015_IR_MODE_DISABLED) {
@@ -1125,11 +1151,6 @@ static int af9015_af9013_frontend_attach(struct
dvb_usb_adapter *adap)
deb_info("%s: init I2C\n", __func__);
ret = af9015_i2c_init(adap->dev);
-
- /* dump eeprom (debug) */
- ret = af9015_eeprom_dump(adap->dev);
- if (ret)
- return ret;
} else {
/* select I2C adapter */
i2c_adap = &state->i2c_adap;
diff --git a/drivers/media/dvb/dvb-usb/af9015.h
b/drivers/media/dvb/dvb-usb/af9015.h
index 931c851..ef36b18 100644
--- a/drivers/media/dvb/dvb-usb/af9015.h
+++ b/drivers/media/dvb/dvb-usb/af9015.h
@@ -107,6 +107,7 @@ struct af9015_config {
u16 mt2060_if1[2];
u16 firmware_size;
u16 firmware_checksum;
+ u32 eeprom_sum;
u8 *ir_table;
u16 ir_table_size;
};
--
1.6.5.7
--
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 1/4] media: dvb/af9015, implement eeprom hashing
On 01/24/2010 05:16 PM, Antti Palosaari wrote:
>> +af9015_config.eeprom_sum = 0;
>> +for (reg = 0; reg< eeprom_size / sizeof(u32); reg++) {
>> +af9015_config.eeprom_sum *= GOLDEN_RATIO_PRIME_32;
>> +af9015_config.eeprom_sum += le32_to_cpu(((u32 *)eeprom)[reg]);
>> +}
>> +
>> +deb_info("%s: eeprom sum=%.8x\n", __func__,
>> af9015_config.eeprom_sum);
>
> Does this sum contain all 256 bytes from EEPROM? 256/4 is 64.
Yes it does. It is computed as a hashed sum of 32-bit numbers (4 bytes)
-- speed (does not matter) and larger space of hashes. Hence the
division by 4. The cast does the trick: ((u32 *)eeprom)[reg] -- reg
index is on a 4-byte basis.
regards,
--
js
--
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 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 01/25/2010 12:44 AM, Antti Palosaari wrote: > When I now test this patch with debugs enabled I don't see > .probe and .disconnect be called for this HID interface (interface 1) at > all and thus checks not needed. What happens if you disable the HID layer? Or at least if you add an ignore quirk for the device in usbhid? I forbid usbhid to attach to the device, as the remote kills X with HID driver. With dvb-usb-remote it works just fine (with remote=2 for af9015 or the 4 patches I've sent). -- js -- 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-usb-remote woes [was: HID: ignore afatech 9016]
On 02/01/2010 07:28 PM, Jiri Kosina wrote: > On Mon, 1 Feb 2010, Pekka Sarnila wrote: >> Well short answer is: No, it does not work. Hi, thanks for the input. >> What I did: >> >> I pulled few days ago latest >> >>git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >> >> and compiled it. Everything works fine including the tv-stick and the >> remote. However I get: >> >> <3>af9015: command failed:255 >> <3>dvb-usb: error while querying for an remote control event. Yes, I saw this quite recently too. For me it appears when it is booted up with the stick in. It's still to be fixed. >> I applied the patch in your mail and recompiled. Remote does not work; >> af9015.c gets no key presses. Instead that above message still comes. Yeah, and that's the reason why it doesn't work. >> Also removing the device or rmmod:ing dvb-usb-af9015.ko causes kernel oops. Already fixed: http://patchwork.kernel.org/patch/74095/ >> Analysis: >> >> When it works, the remote is recognized by the system as a HID-keyboard, >> and thus it works as a normal USB-keyboard. dvb-usb-remote.c is not >> participating at all (though it gives those errors). Actually it is. But it fails to get status. >> The remote is visible to the system as a usb interrupt end point. >> Interrupt endpoint tells the system the polling interval (by endpoint >> report). From the USB specs on the interval: >> >> The USB System Software will use this information during configuration >> to determine a period that can be sustained. The period provided by >> the system may be shorter than that desired by the device up to the >> shortest period defined by the USB (125 µs microframe or 1 ms frame). >> The client software and device can depend only on the fact that the >> host will ensure that the time duration between two transaction >> attempts with the endpoint will be no longer than the desired period. >> >> As I understand it, in plain English it means that the polling interval >> must not be longer than what the endpoint report says (in case of >> full-speed endpoint 1 to 255 ms). This device in question, assuming it >> gives the interval in full-speed mode even it really is high-speed >> device, gives 16ms interval period. >> >> However af9015.c/dvb-usb-remote.c accesses it as if it was a bulk >> endpoint and with 150ms interval. I did not look further on if this is >> the only reason or the reason for it not to work. But at least it is in >> clear contradiction of the USB-specs. To what statement is it in contradiction? The statement above is for interrupt transfers. >> I suspect, to make it work, much of the code from hid-driver should be >> copied to the device driver. Which code? I see no code being copied. >> However I think that would be exactly the >> wrong way to go. I think the whole idea of making for every device a >> separated driver ignoring the common code already in the kernel is bad >> architecture. Common code does not work well here. Don't you see weird key repetitions and similar? >> I have noticed more and more of this type of movement in >> the driver development resulting the same thing done in hundred >> different ways when common code could be used. Especially bad I think it >> is in the cases where universal specification is available (albeit there >> are many devices that do not follow the usb specs correctly). In this case I suppose this is why dvb-usb-remote exists. Maybe it can be handled better by a separate driver (still) as a part of the HID layer nowadays. Patrick, Johannes, why was not dvb-usb-remote implemented rather as a part of the HID layer? >> Also it is wrong idea that you could/should detect the type of remote >> controller based on the tv-stick. E.g with Haupauge TV-NOVA nearly any >> remote works ok (e.g my panasonic tv remote). Every generic ir-receiver >> sends also the manufacturer and model codes. Remote ir-to-code >> translates should be based on that (there is a kind of generic layer for >> that in linux kernel) and not on the tv-stick model at all (as in the >> af9015 driver). Sorry, I don't understand this paragraph. Could you rephrase? >> BTW I now recall how I got Afateck remote work as should. The driver >> loads ir-to-code translate table to the stick. I changed the codes to >> what made more sense. Why you didn't push this upstream? >> One problem here is that current HID layer is very sparse in the >> information it passes on, really only a code. It should also convey the >> precice id of the device so upper layer would be better able to deal >> with events. One of my hobbies is flight simulator flying. I use X-plane >> (excellent program). There is also a linux version. But the linux >> joystick driver is far from adequate for it (also some joysticks, yokes >> and pedals or some of their controls didn't work at all). So I use a >> special kernel for which I rewrote big parts of the HID-driver and >> input-driver and wrote completely new joysti
Re: dvb-usb-remote woes [was: HID: ignore afatech 9016]
On 02/01/2010 10:23 PM, Antti Palosaari wrote: > On 02/01/2010 09:42 PM, Jiri Slaby wrote: >> On 02/01/2010 07:28 PM, Jiri Kosina wrote: >>> On Mon, 1 Feb 2010, Pekka Sarnila wrote: >>>><3>af9015: command failed:255 >>>><3>dvb-usb: error while querying for an remote control event. >> >> Yes, I saw this quite recently too. For me it appears when it is booted >> up with the stick in. It's still to be fixed. > > I suspect you are using old firmware, 4.65.0.0 probably, that does not > support remote polling and thus this 255 errors seen. For me: af9013: firmware version:4.95.0 As I wrote, for me it happens iff it is plugged-in while booting. I'll investigate it further later -- that it a reason why I haven't reported it yet. -- js suse labs -- 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 -resend#1 1/1] V4L: videobuf, don't use dma addr as physical
On 03/21/2011 11:43 PM, Mauro Carvalho Chehab wrote:
> As I got no return, and the patch looked sane, I've reviewed the comment
> myself,
Aha, I forgot to send it. Sorry.
It looks OK.
> Author: Jiri Slaby
> Date: Mon Feb 28 06:37:02 2011 -0300
>
> [media] V4L: videobuf, don't use dma addr as physical
>
> mem->dma_handle is a dma address obtained by dma_alloc_coherent which
> needn't be a physical address in presence of IOMMU, as
> a hardware IOMMU can (and most likely) will return a bus address where
> physical != bus address.
>
> So ensure we are remapping (remap_pfn_range) the right page in
> __videobuf_mmap_mapper by using virt_to_phys(mem->vaddr) and not
> mem->dma_handle.
>
> While at it, use PFN_DOWN instead of explicit shift.
>
> Signed-off-by: Jiri Slaby
> Reviewed-by: Konrad Rzeszutek Wilk
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/media/video/videobuf-dma-contig.c
> b/drivers/media/video/videobuf-dma-contig.c
> index c969111..19d3e4a 100644
> --- a/drivers/media/video/videobuf-dma-contig.c
> +++ b/drivers/media/video/videobuf-dma-contig.c
> @@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue
> *q,
>
> vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> retval = remap_pfn_range(vma, vma->vm_start,
> -mem->dma_handle >> PAGE_SHIFT,
> + PFN_DOWN(virt_to_phys(mem->vaddr))
> size, vma->vm_page_prot);
> if (retval) {
> dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
thanks,
--
js
suse labs
--
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: V4L/ARM: videobuf-dma-contig no longer works on my ARM machine
On 04/09/2011 05:10 PM, Janusz Krzysztofik wrote: > (CC: Jiri Slaby, the author of the problematic change; truncate subject) > > On Sat, 09 Apr 2011, at 09:16:24, Russell King - ARM Linux wrote: >> On Sat, Apr 09, 2011 at 03:33:39AM +0200, Janusz Krzysztofik wrote: >>> Since there were no actual problems reported before, I suppose the >>> old code, which was passing to remap_pfn_range() a physical page >>> number calculated from dma_alloc_coherent() privided dma_handle, >>> worked correctly on all platforms actually using >>> videobud-dma-config. No, it didn't when IOMMU was used. Because remap_pfn_range didn't get a physical page address. >>> Now, on my ARM machine, a completely >>> different, then completely wrong physical address, calculated as >>> virt_to_phys(dma_alloc_coherent()), is used instead of the >>> dma_handle, which causes the machine to hang. >> >> virt_to_phys(dma_alloc_coherent()) is and always has been invalid, >> and will break on several architectures apart from ARM. Yes, the fix is broken for some archs. Feel free to revert it until it is fixed properly. Sound pcm mmap had a similar problem and solved that by a bit hackish way (see snd_pcm_default_mmap). I saw a discussion about how to sort it out in the sound subsystem and do that in a clean manner. Maybe somebody else remembers where it was. thanks, -- js suse labs -- 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
[REVERT] Re: V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On 04/14/2011 12:00 AM, Russell King - ARM Linux wrote: > On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote: >> Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux >> napisał(a): >>> On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: >>>> Taking into account that I'm just trying to fix a regression, and >>>> not invent a new, long term solution: are you able to name an ARM >>>> based board which a) is already supported in 2.6.39, b) is (or can >>>> be) equipped with a device supported by a V4L driver which uses >>>> videobuf- dma-config susbsystem, c) has a bus structure with which >>>> virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? >>> >>> I have no idea - and why should whether someone can name something >>> that may break be a justification to allow something which is >>> technically wrong? >>> >>> Surely it should be the other way around - if its technically wrong >>> and _may_ break something then it shouldn't be allowed. >> >> In theory - of course. In practice - couldn't we now, close to -rc3, >> relax the rules a little bit and stop bothering with something that may >> break in the future if it doesn't break on any board supported so far (I >> hope)? > > If we are worried about closeness to -final, then what should happen is > that the original commit is reverted; the "fix" for IOMMUs resulted in > a regression for existing users which isn't trivial to resolve without > risking possible breakage of other users. Hi, as -rc4 is out, I think it's time to revert that commit and rethink the mmap behaviour for some of next -rc1s. Linus, please revert commit 35d9f510b67b10338161aba6229d4f55b4000f5b Author: Jiri Slaby Date: Mon Feb 28 06:37:02 2011 -0300 [media] V4L: videobuf, don't use dma addr as physical === It fixes mmap when IOMMU is used on x86 only, but breaks architectures like ARM or PPC where virt_to_phys(dma_alloc_coherent) doesn't work. We need there dma_mmap_coherent or similar (the trickery what snd_pcm_default_mmap does but in some saner way). But this cannot be done at this phase. thanks, -- js suse labs -- 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] vino: replace dma_sync_single with dma_sync_single_for_cpu
On 05/28/2009 03:10 AM, FUJITA Tomonori wrote:
> This replaces dma_sync_single() with dma_sync_single_for_cpu() because
> dma_sync_single() is an obsolete API; include/linux/dma-mapping.h says:
>
> /* Backwards compat, remove in 2.7.x */
> #define dma_sync_single dma_sync_single_for_cpu
> #define dma_sync_sg dma_sync_sg_for_cpu
>
> Signed-off-by: FUJITA Tomonori
> ---
> drivers/media/video/vino.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/video/vino.c b/drivers/media/video/vino.c
> index 43e0998..97b082f 100644
> --- a/drivers/media/video/vino.c
> +++ b/drivers/media/video/vino.c
> @@ -868,9 +868,9 @@ static void vino_sync_buffer(struct vino_framebuffer *fb)
> dprintk("vino_sync_buffer():\n");
>
> for (i = 0; i < fb->desc_table.page_count; i++)
> - dma_sync_single(NULL,
> - fb->desc_table.dma_cpu[VINO_PAGE_RATIO * i],
> - PAGE_SIZE, DMA_FROM_DEVICE);
> + dma_sync_single_for_cpu(NULL,
> + fb->desc_table.dma_cpu[VINO_PAGE_RATIO
> * i],
> + PAGE_SIZE, DMA_FROM_DEVICE);
Shouldn't be there sync_for_device in vino_dma_setup (or somewhere)
then? If I understand the API correctly this won't (and didn't) work on
some platforms.
The same for other drivers who don't free the buffer after the sync but
recycle it instead.
--
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
sleep in atomic in dvb_dmx_swfilter_packet
Hi, we've found that there is a vmalloc call from atomic context: dvb_dmx_swfilter_packets -> spin_lock() -> dvb_dmx_swfilter_packet -> vmalloc() -- 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/4] V4L: em28xx, fix lock imbalance
There is one omitted unlock in em28xx_usb_probe. Fix that.
Signed-off-by: Jiri Slaby
---
drivers/media/video/em28xx/em28xx-cards.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 36abb35..922d21d 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2445,6 +2445,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
retval = em28xx_init_dev(&dev, udev, interface, nr);
if (retval) {
em28xx_devused &= ~(1<devno);
+ mutex_unlock(&dev->lock);
kfree(dev);
goto err;
}
--
1.6.3.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 4/4] V4L: saa7134, fix lock imbalance
There seems to be one superfluos unlock in a poll function. Remove it. Signed-off-by: Jiri Slaby --- drivers/media/video/saa7134/saa7134-video.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c index 82b57a6..dd9aab0 100644 --- a/drivers/media/video/saa7134/saa7134-video.c +++ b/drivers/media/video/saa7134/saa7134-video.c @@ -1443,7 +1443,6 @@ video_poll(struct file *file, struct poll_table_struct *wait) fh->cap.ops->buf_queue(&fh->cap,fh->cap.read_buf); fh->cap.read_off = 0; } - mutex_unlock(&fh->cap.vb_lock); buf = fh->cap.read_buf; } -- 1.6.3.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 1/4] V4L: radio-si470x, fix lock imbalance
There is one path with omitted unlock in si470x_fops_release. Fix that. Signed-off-by: Jiri Slaby --- drivers/media/radio/radio-si470x.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/radio/radio-si470x.c b/drivers/media/radio/radio-si470x.c index 640421c..46d2163 100644 --- a/drivers/media/radio/radio-si470x.c +++ b/drivers/media/radio/radio-si470x.c @@ -1200,7 +1200,7 @@ static int si470x_fops_release(struct file *file) video_unregister_device(radio->videodev); kfree(radio->buffer); kfree(radio); - goto done; + goto unlock; } /* stop rds reception */ @@ -1213,9 +1213,8 @@ static int si470x_fops_release(struct file *file) retval = si470x_stop(radio); usb_autopm_put_interface(radio->intf); } - +unlock: mutex_unlock(&radio->disconnect_lock); - done: return retval; } -- 1.6.3.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 3/4] V4L: hdpvr, fix lock imbalances
There are many lock imbalances in this driver. Fix all found.
Signed-off-by: Jiri Slaby
---
drivers/media/video/hdpvr/hdpvr-core.c | 12 ++--
drivers/media/video/hdpvr/hdpvr-video.c |6 --
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
b/drivers/media/video/hdpvr/hdpvr-core.c
index 188bd5a..1c9bc94 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -126,7 +126,7 @@ static int device_authorization(struct hdpvr_device *dev)
char *print_buf = kzalloc(5*buf_size+1, GFP_KERNEL);
if (!print_buf) {
v4l2_err(&dev->v4l2_dev, "Out of memory\n");
- goto error;
+ return retval;
}
#endif
@@ -140,7 +140,7 @@ static int device_authorization(struct hdpvr_device *dev)
if (ret != 46) {
v4l2_err(&dev->v4l2_dev,
"unexpected answer of status request, len %d\n", ret);
- goto error;
+ goto unlock;
}
#ifdef HDPVR_DEBUG
else {
@@ -163,7 +163,7 @@ static int device_authorization(struct hdpvr_device *dev)
v4l2_err(&dev->v4l2_dev, "unknown firmware version 0x%x\n",
dev->usbc_buf[1]);
ret = -EINVAL;
- goto error;
+ goto unlock;
}
response = dev->usbc_buf+38;
@@ -188,10 +188,10 @@ static int device_authorization(struct hdpvr_device *dev)
1);
v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
"magic request returned %d\n", ret);
- mutex_unlock(&dev->usbc_mutex);
retval = ret != 8;
-error:
+unlock:
+ mutex_unlock(&dev->usbc_mutex);
return retval;
}
@@ -350,6 +350,7 @@ static int hdpvr_probe(struct usb_interface *interface,
mutex_lock(&dev->io_mutex);
if (hdpvr_alloc_buffers(dev, NUM_BUFFERS)) {
+ mutex_unlock(&dev->io_mutex);
v4l2_err(&dev->v4l2_dev,
"allocating transfer buffers failed\n");
goto error;
@@ -381,7 +382,6 @@ static int hdpvr_probe(struct usb_interface *interface,
error:
if (dev) {
- mutex_unlock(&dev->io_mutex);
/* this frees allocated memory */
hdpvr_delete(dev);
}
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c
b/drivers/media/video/hdpvr/hdpvr-video.c
index ccd47f5..5937de2 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -375,6 +375,7 @@ static int hdpvr_open(struct file *file)
* in resumption */
mutex_lock(&dev->io_mutex);
dev->open_count++;
+ mutex_unlock(&dev->io_mutex);
fh->dev = dev;
@@ -383,7 +384,6 @@ static int hdpvr_open(struct file *file)
retval = 0;
err:
- mutex_unlock(&dev->io_mutex);
return retval;
}
@@ -519,8 +519,10 @@ static unsigned int hdpvr_poll(struct file *filp,
poll_table *wait)
mutex_lock(&dev->io_mutex);
- if (video_is_unregistered(dev->video_dev))
+ if (video_is_unregistered(dev->video_dev)) {
+ mutex_unlock(&dev->io_mutex);
return -EIO;
+ }
if (dev->status == STATUS_IDLE) {
if (hdpvr_start_streaming(dev)) {
--
1.6.3.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 repost 1/4] V4L: radio-si470x, fix lock imbalance
There is one path with omitted unlock in si470x_fops_release. Fix that. Signed-off-by: Jiri Slaby --- drivers/media/radio/radio-si470x.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/radio/radio-si470x.c b/drivers/media/radio/radio-si470x.c index 640421c..46d2163 100644 --- a/drivers/media/radio/radio-si470x.c +++ b/drivers/media/radio/radio-si470x.c @@ -1200,7 +1200,7 @@ static int si470x_fops_release(struct file *file) video_unregister_device(radio->videodev); kfree(radio->buffer); kfree(radio); - goto done; + goto unlock; } /* stop rds reception */ @@ -1213,9 +1213,8 @@ static int si470x_fops_release(struct file *file) retval = si470x_stop(radio); usb_autopm_put_interface(radio->intf); } - +unlock: mutex_unlock(&radio->disconnect_lock); - done: return retval; } -- 1.6.3.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 repost 2/4] V4L: em28xx, fix lock imbalance
There is one omitted unlock in em28xx_usb_probe. Fix that.
Signed-off-by: Jiri Slaby
---
drivers/media/video/em28xx/em28xx-cards.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 36abb35..922d21d 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -2445,6 +2445,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
retval = em28xx_init_dev(&dev, udev, interface, nr);
if (retval) {
em28xx_devused &= ~(1<devno);
+ mutex_unlock(&dev->lock);
kfree(dev);
goto err;
}
--
1.6.3.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 repost 3/4] V4L: hdpvr, fix lock imbalances
There are many lock imbalances in this driver. Fix all found.
Signed-off-by: Jiri Slaby
---
drivers/media/video/hdpvr/hdpvr-core.c | 12 ++--
drivers/media/video/hdpvr/hdpvr-video.c |6 --
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
b/drivers/media/video/hdpvr/hdpvr-core.c
index 188bd5a..1c9bc94 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -126,7 +126,7 @@ static int device_authorization(struct hdpvr_device *dev)
char *print_buf = kzalloc(5*buf_size+1, GFP_KERNEL);
if (!print_buf) {
v4l2_err(&dev->v4l2_dev, "Out of memory\n");
- goto error;
+ return retval;
}
#endif
@@ -140,7 +140,7 @@ static int device_authorization(struct hdpvr_device *dev)
if (ret != 46) {
v4l2_err(&dev->v4l2_dev,
"unexpected answer of status request, len %d\n", ret);
- goto error;
+ goto unlock;
}
#ifdef HDPVR_DEBUG
else {
@@ -163,7 +163,7 @@ static int device_authorization(struct hdpvr_device *dev)
v4l2_err(&dev->v4l2_dev, "unknown firmware version 0x%x\n",
dev->usbc_buf[1]);
ret = -EINVAL;
- goto error;
+ goto unlock;
}
response = dev->usbc_buf+38;
@@ -188,10 +188,10 @@ static int device_authorization(struct hdpvr_device *dev)
1);
v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
"magic request returned %d\n", ret);
- mutex_unlock(&dev->usbc_mutex);
retval = ret != 8;
-error:
+unlock:
+ mutex_unlock(&dev->usbc_mutex);
return retval;
}
@@ -350,6 +350,7 @@ static int hdpvr_probe(struct usb_interface *interface,
mutex_lock(&dev->io_mutex);
if (hdpvr_alloc_buffers(dev, NUM_BUFFERS)) {
+ mutex_unlock(&dev->io_mutex);
v4l2_err(&dev->v4l2_dev,
"allocating transfer buffers failed\n");
goto error;
@@ -381,7 +382,6 @@ static int hdpvr_probe(struct usb_interface *interface,
error:
if (dev) {
- mutex_unlock(&dev->io_mutex);
/* this frees allocated memory */
hdpvr_delete(dev);
}
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c
b/drivers/media/video/hdpvr/hdpvr-video.c
index ccd47f5..5937de2 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -375,6 +375,7 @@ static int hdpvr_open(struct file *file)
* in resumption */
mutex_lock(&dev->io_mutex);
dev->open_count++;
+ mutex_unlock(&dev->io_mutex);
fh->dev = dev;
@@ -383,7 +384,6 @@ static int hdpvr_open(struct file *file)
retval = 0;
err:
- mutex_unlock(&dev->io_mutex);
return retval;
}
@@ -519,8 +519,10 @@ static unsigned int hdpvr_poll(struct file *filp,
poll_table *wait)
mutex_lock(&dev->io_mutex);
- if (video_is_unregistered(dev->video_dev))
+ if (video_is_unregistered(dev->video_dev)) {
+ mutex_unlock(&dev->io_mutex);
return -EIO;
+ }
if (dev->status == STATUS_IDLE) {
if (hdpvr_start_streaming(dev)) {
--
1.6.3.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 repost 4/4] V4L: saa7134, fix lock imbalance
There seems to be one superfluos unlock in a poll function. Remove it. Signed-off-by: Jiri Slaby --- drivers/media/video/saa7134/saa7134-video.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c index 82b57a6..dd9aab0 100644 --- a/drivers/media/video/saa7134/saa7134-video.c +++ b/drivers/media/video/saa7134/saa7134-video.c @@ -1443,7 +1443,6 @@ video_poll(struct file *file, struct poll_table_struct *wait) fh->cap.ops->buf_queue(&fh->cap,fh->cap.read_buf); fh->cap.read_off = 0; } - mutex_unlock(&fh->cap.vb_lock); buf = fh->cap.read_buf; } -- 1.6.3.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 repost2 1/2] V4L: hdpvr, fix lock imbalances
Hrm, nobody picked these up, twice. Maybe this time :)?
--
There are many lock imbalances in this driver. Fix all found.
Signed-off-by: Jiri Slaby
---
drivers/media/video/hdpvr/hdpvr-core.c | 12 ++--
drivers/media/video/hdpvr/hdpvr-video.c |6 --
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
b/drivers/media/video/hdpvr/hdpvr-core.c
index 188bd5a..1c9bc94 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -126,7 +126,7 @@ static int device_authorization(struct hdpvr_device *dev)
char *print_buf = kzalloc(5*buf_size+1, GFP_KERNEL);
if (!print_buf) {
v4l2_err(&dev->v4l2_dev, "Out of memory\n");
- goto error;
+ return retval;
}
#endif
@@ -140,7 +140,7 @@ static int device_authorization(struct hdpvr_device *dev)
if (ret != 46) {
v4l2_err(&dev->v4l2_dev,
"unexpected answer of status request, len %d\n", ret);
- goto error;
+ goto unlock;
}
#ifdef HDPVR_DEBUG
else {
@@ -163,7 +163,7 @@ static int device_authorization(struct hdpvr_device *dev)
v4l2_err(&dev->v4l2_dev, "unknown firmware version 0x%x\n",
dev->usbc_buf[1]);
ret = -EINVAL;
- goto error;
+ goto unlock;
}
response = dev->usbc_buf+38;
@@ -188,10 +188,10 @@ static int device_authorization(struct hdpvr_device *dev)
1);
v4l2_dbg(MSG_INFO, hdpvr_debug, &dev->v4l2_dev,
"magic request returned %d\n", ret);
- mutex_unlock(&dev->usbc_mutex);
retval = ret != 8;
-error:
+unlock:
+ mutex_unlock(&dev->usbc_mutex);
return retval;
}
@@ -350,6 +350,7 @@ static int hdpvr_probe(struct usb_interface *interface,
mutex_lock(&dev->io_mutex);
if (hdpvr_alloc_buffers(dev, NUM_BUFFERS)) {
+ mutex_unlock(&dev->io_mutex);
v4l2_err(&dev->v4l2_dev,
"allocating transfer buffers failed\n");
goto error;
@@ -381,7 +382,6 @@ static int hdpvr_probe(struct usb_interface *interface,
error:
if (dev) {
- mutex_unlock(&dev->io_mutex);
/* this frees allocated memory */
hdpvr_delete(dev);
}
diff --git a/drivers/media/video/hdpvr/hdpvr-video.c
b/drivers/media/video/hdpvr/hdpvr-video.c
index ccd47f5..5937de2 100644
--- a/drivers/media/video/hdpvr/hdpvr-video.c
+++ b/drivers/media/video/hdpvr/hdpvr-video.c
@@ -375,6 +375,7 @@ static int hdpvr_open(struct file *file)
* in resumption */
mutex_lock(&dev->io_mutex);
dev->open_count++;
+ mutex_unlock(&dev->io_mutex);
fh->dev = dev;
@@ -383,7 +384,6 @@ static int hdpvr_open(struct file *file)
retval = 0;
err:
- mutex_unlock(&dev->io_mutex);
return retval;
}
@@ -519,8 +519,10 @@ static unsigned int hdpvr_poll(struct file *filp,
poll_table *wait)
mutex_lock(&dev->io_mutex);
- if (video_is_unregistered(dev->video_dev))
+ if (video_is_unregistered(dev->video_dev)) {
+ mutex_unlock(&dev->io_mutex);
return -EIO;
+ }
if (dev->status == STATUS_IDLE) {
if (hdpvr_start_streaming(dev)) {
--
1.6.3.3
--
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 repost2 2/2] V4L: saa7134, fix lock imbalance
There is one superfluos (imbalanced) unlock in a poll function. Remove it. Signed-off-by: Jiri Slaby --- drivers/media/video/saa7134/saa7134-video.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-video.c b/drivers/media/video/saa7134/saa7134-video.c index 58854df..da26f47 100644 --- a/drivers/media/video/saa7134/saa7134-video.c +++ b/drivers/media/video/saa7134/saa7134-video.c @@ -1444,7 +1444,6 @@ video_poll(struct file *file, struct poll_table_struct *wait) fh->cap.ops->buf_queue(&fh->cap,fh->cap.read_buf); fh->cap.read_off = 0; } - mutex_unlock(&fh->cap.vb_lock); buf = fh->cap.read_buf; } -- 1.6.3.3 -- 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_NET help message is useless
Hi, I've just updated to 3.0-rc and saw CONFIG_DVB_NET. Hmm, let's see what's that by asking with '?'. And I got this crap: CONFIG_DVB_NET: The DVB network support in the DVB core can optionally be disabled if this option is set to N. If unsure say Y. Why do you think this help message is useful? It's clear to everybody that if one eventually disables it it will be disabled. The help message should mention _what_ the network support is. I would send a patch, but I really have no idea what's that good for. thanks, -- js -- 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] DVB: dvb-net, make the kconfig text helpful
Telling the user they can disable an option if they want is not the much useful. Describe what it is good for instead. The text was derived from Mauro's email. Signed-off-by: Jiri Slaby Cc: Mauro Carvalho Chehab Cc: Hans Petter Selasky --- drivers/media/Kconfig | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index dc61895..279e2b9 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -89,11 +89,13 @@ config DVB_NET default (NET && INET) depends on NET && INET help - The DVB network support in the DVB core can - optionally be disabled if this - option is set to N. + This option enables DVB Network Support which is a part of the DVB + standard. It is used, for example, by automatic firmware updates used + on Set-Top-Boxes. It can also be used to access the Internet via the + DVB card, if the network provider supports it. - If unsure say Y. + You may want to disable the network support on embedded devices. If + unsure say Y. config VIDEO_MEDIA tristate -- 1.7.5.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: [PATCH] DVB: dvb-net, make the kconfig text helpful
On 06/17/2011 08:04 AM, Hans Petter Selasky wrote: > PS: Don't forget the other patch to add a dependency to DVB_CORE. Sorry, I'm not your fixing monkey. Fix your bugs on your own. thanks, -- js -- 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: schedule inside spin_lock_irqsave?
On 05/30/2010 04:52 PM, Richard Zidlicky wrote:
> Hi,
>
> came across following snippet of code
> (2.6.34:drivers/media/dvb/siano/smscoreapi.c) and
> since prepare_to_wait is new for me I am wondering if this is can work?
>
> struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
> {
> struct smscore_buffer_t *cb = NULL;
> unsigned long flags;
>
> DEFINE_WAIT(wait);
>
> spin_lock_irqsave(&coredev->bufferslock, flags);
>
> /* This function must return a valid buffer, since the buffer list is
>* finite, we check that there is an available buffer, if not, we wait
>* until such buffer become available.
>*/
>
> prepare_to_wait(&coredev->buffer_mng_waitq, &wait, TASK_INTERRUPTIBLE);
>
> if (list_empty(&coredev->buffers))
> schedule();
>
> finish_wait(&coredev->buffer_mng_waitq, &wait);
>
> cb = (struct smscore_buffer_t *) coredev->buffers.next;
> list_del(&cb->entry);
>
> spin_unlock_irqrestore(&coredev->bufferslock, flags);
Yep, that's a double bug.
1) If the waiting is interrupted, it will die because the list is still
empty.
2) If there is no entry in the list, it will deadlock at least on UP.
This should be
wait_event(&coredev->buffer_mng_waitq, cb = get_entry());
with get_entry like:
struct smscore_buffer_t *get_entry(void)
{
struct smscore_buffer_t *cb = NULL;
spin_lock_irqsave(&coredev->bufferslock, flags);
if (!list_empty(&coredev->buffers)) {
cb = (struct smscore_buffer_t *) coredev->buffers.next;
list_del(&cb->entry);
}
spin_unlock_irqrestore(&coredev->bufferslock, flags);
return cb;
}
regards,
--
js
--
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: schedule inside spin_lock_irqsave?
On 05/30/2010 05:24 PM, Jiri Slaby wrote:
> struct smscore_buffer_t *get_entry(void)
> {
> struct smscore_buffer_t *cb = NULL;
> spin_lock_irqsave(&coredev->bufferslock, flags);
> if (!list_empty(&coredev->buffers)) {
> cb = (struct smscore_buffer_t *) coredev->buffers.next;
Looking at the smscore_buffer_t definition, this is really ugly since it
relies on entry being the first in the structure. It should be
list_first_entry(&coredev->buffers, ...) instead, cast-less.
> list_del(&cb->entry);
> }
> spin_unlock_irqrestore(&coredev->bufferslock, flags);
> return cb;
> }
--
js
--
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 2.6.34] schedule inside spin_lock_irqsave
On 06/06/2010 02:43 PM, Richard Zidlicky wrote:
> Hi,
>
> I have done a minimaly invasive patch for the stable 2.6.34 kernel and
> stress-tested
> it for many hours, definitely seems to improve the behaviour.
>
> I have left out your beautification suggestion for now, want to do more
> playing with
> other aspects of the driver. There still seem to be issues when the device is
> unplugged
> while in use and such.
>
> --- linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c.rz 2010-06-03
> 21:58:11.0 +0200
> +++ linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c 2010-06-04
> 23:00:35.0 +0200
> @@ -1100,31 +1100,26 @@
> *
> * @return pointer to descriptor on success, NULL on error.
> */
> -struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
> +
> +struct smscore_buffer_t *get_entry(void)
> {
> struct smscore_buffer_t *cb = NULL;
> unsigned long flags;
>
> - DEFINE_WAIT(wait);
> -
> spin_lock_irqsave(&coredev->bufferslock, flags);
Sorry, maybe I'm just blind, but where is 'coredev' defined in this
scope? You probably forgot to pass it to get_entry?
How could this be compiled? Is there coredev defined globally?
> -
> - /* This function must return a valid buffer, since the buffer list is
> - * finite, we check that there is an available buffer, if not, we wait
> - * until such buffer become available.
> - */
> -
> - prepare_to_wait(&coredev->buffer_mng_waitq, &wait, TASK_INTERRUPTIBLE);
> -
> - if (list_empty(&coredev->buffers))
> - schedule();
> -
> - finish_wait(&coredev->buffer_mng_waitq, &wait);
> -
> + if (!list_empty(&coredev->buffers)) {
> cb = (struct smscore_buffer_t *) coredev->buffers.next;
> list_del(&cb->entry);
> -
> + }
> spin_unlock_irqrestore(&coredev->bufferslock, flags);
> + return cb;
> +}
> +
> +struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
> +{
> + struct smscore_buffer_t *cb = NULL;
> +
> + wait_event(coredev->buffer_mng_waitq, (cb = get_entry()));
>
> return cb;
> }
--
js
--
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] VIDEO: ivtvfb, remove unneeded NULL test
Stanse found that in ivtvfb_callback_cleanup there is an unneeded test
for itv being NULL. But itv is initialized as container_of with
non-zero offset, so it is never NULL (even if v4l2_dev is). This was
found because itv is dereferenced earlier than the test.
Signed-off-by: Jiri Slaby
Cc: Andy Walls
Cc: Mauro Carvalho Chehab
Cc: Tejun Heo
Cc: Ian Armstrong
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
---
drivers/media/video/ivtv/ivtvfb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtvfb.c
b/drivers/media/video/ivtv/ivtvfb.c
index 9ff3425..5dc460e 100644
--- a/drivers/media/video/ivtv/ivtvfb.c
+++ b/drivers/media/video/ivtv/ivtvfb.c
@@ -1219,7 +1219,7 @@ static int ivtvfb_callback_cleanup(struct device *dev,
void *p)
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
struct osd_info *oi = itv->osd_info;
- if (itv && (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
if (unregister_framebuffer(&itv->osd_info->ivtvfb_info)) {
IVTVFB_WARN("Framebuffer %d is in use, cannot unload\n",
itv->instance);
--
1.7.1
--
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] VIDEO: ivtvfb, remove unneeded NULL test
On 07/04/2010 06:11 AM, Andy Walls wrote:
> You missed an identical instance of the useless test 10 lines prior in
> ivtvfb_callback_init(). :)
Ah, thank you for pointing out. Find my comment below.
> --- a/drivers/media/video/ivtv/ivtvfb.c
> +++ b/drivers/media/video/ivtv/ivtvfb.c
> @@ -1201,9 +1201,14 @@ static int ivtvfb_init_card(struct ivtv *itv)
> static int __init ivtvfb_callback_init(struct device *dev, void *p)
> {
> struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
> - struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
> + struct ivtv *itv;
>
> - if (itv && (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)) {
> + if (v4l2_dev == NULL)
> + return 0;
> +
> + itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
> +
> + if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
> if (ivtvfb_init_card(itv) == 0) {
> IVTVFB_INFO("Framebuffer registered on %s\n",
> itv->v4l2_dev.name);
> @@ -1216,10 +1221,16 @@ static int __init ivtvfb_callback_init(struct device
> *de
> static int ivtvfb_callback_cleanup(struct device *dev, void *p)
> {
> struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
> - struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
> - struct osd_info *oi = itv->osd_info;
> + struct ivtv *itv;
> + struct osd_info *oi;
> +
> + if (v4l2_dev == NULL)
> + return 0;
>From my POV I NACK this. Given that it never triggered and drvdata are
set in v4l2_device_register called from ivtv_probe I can't see how
v4l2_dev be NULL. Could you elaborate?
--
js
suse labs
--
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] VIDEO: ivtvfb, remove unneeded NULL test
On 07/04/2010 03:22 PM, Andy Walls wrote:
> On Sun, 2010-07-04 at 09:24 +0200, Jiri Slaby wrote:
>> On 07/04/2010 06:11 AM, Andy Walls wrote:
>>> --- a/drivers/media/video/ivtv/ivtvfb.c
>>> +++ b/drivers/media/video/ivtv/ivtvfb.c
>>> @@ -1201,9 +1201,14 @@ static int ivtvfb_init_card(struct ivtv *itv)
>>> static int __init ivtvfb_callback_init(struct device *dev, void *p)
>>> {
>>> struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
>>> - struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
>>> + struct ivtv *itv;
>>>
>>> - if (itv && (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)) {
>>> + if (v4l2_dev == NULL)
>>> + return 0;
>>> +
>>> + itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
>>> +
>>> + if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
>>> if (ivtvfb_init_card(itv) == 0) {
>>> IVTVFB_INFO("Framebuffer registered on %s\n",
>>> itv->v4l2_dev.name);
>>> @@ -1216,10 +1221,16 @@ static int __init ivtvfb_callback_init(struct
>>> device *de
>>> static int ivtvfb_callback_cleanup(struct device *dev, void *p)
>>> {
>>> struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
>>> - struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
>>> - struct osd_info *oi = itv->osd_info;
>>> + struct ivtv *itv;
>>> + struct osd_info *oi;
>>> +
>>> + if (v4l2_dev == NULL)
>>> + return 0;
>>
>> >From my POV I NACK this. Given that it never triggered and drvdata are
>> set in v4l2_device_register called from ivtv_probe I can't see how
>> v4l2_dev be NULL. Could you elaborate?
>
> I hemmed and hawed over that too. I didn't do a very thorough analysis
> of the restrictions on unloading modules, but here was my line of
> reasoning:
...
> 2. Note that the ivtvfb driver is not automatically loaded nor unloaded
> by the kernel ivtv driver. Something from userspace will reqeust the
> load and unload of the module.
>
> There are windows of time where a struct device * will exist for a card
> in the ivtv driver, but a struct v4l2_device * may not: the end of
> ivtv_remove() and the beginning of ivtv_probe().
If there is no locking or refcounting, this won't change with the added
check. The window is still there, but it begins after the check with
your patch. Hence will still cause oopses.
> I was contemplating a case where user space requested unloading both the
> ivtvfb and the ivtv driver. Given all the I2C devices these cards can
> have, I thought v4l2_device_unregister() at the end of ivtv_remove()
> could present a window of time large enough to worry about a race.
> v4l2_device_unregister() sets the struct device drvdata pointer to
> NULL, and then begins unregistering the i2c clients. I haven't profiled
> the process to know how long it typically takes, though.
>
> I also don't know if kernel mechanisms will absolutely prevent
> initiating the unload of ivtv.ko before the unload of ivtvfb.ko is
> completely finished. Will they?
Given ivtvfb uses functions from ivtv, no, it can't unload ivtv earlier
than ivtvfb.
regards,
--
js
suse labs
--
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
MEDIA: lirc, improper locking
Hi,
stanse found a locking error in lirc_dev_fop_read:
if (mutex_lock_interruptible(&ir->irctl_lock))
return -ERESTARTSYS;
...
while (written < length && ret == 0) {
if (mutex_lock_interruptible(&ir->irctl_lock)) {#1
ret = -ERESTARTSYS;
break;
}
...
}
remove_wait_queue(&ir->buf->wait_poll, &wait);
set_current_state(TASK_RUNNING);
mutex_unlock(&ir->irctl_lock);#2
If lock at #1 fails, it beaks out of the loop, with the lock unlocked,
but there is another "unlock" at #2.
regards,
--
js
--
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/1] DVB: fix dvr node refcounting
In dvb_dvr_release, there is a test dvbdev->users==-1, but users are
never negative. This error results in hung tasks:
taskPC stack pid father
bash D a000c948 0 3264 3170 0x
88003aec5ce8 0086 00011f80 00011f80
88003aec5fd8 88003aec5fd8 88003b848670 00011f80
88003aec5fd8 00011f80 88003e02a030 88003b848670
Call Trace:
[] dvb_dmxdev_release+0xc5/0x130
[] ? autoremove_wake_function+0x0/0x40
[] dvb_usb_adapter_dvb_exit+0x42/0x70 [dvb_usb]
[] dvb_usb_exit+0x55/0xd0 [dvb_usb]
[] dvb_usb_device_exit+0x4e/0x70 [dvb_usb]
[] af9015_usb_device_exit+0x55/0x60 [dvb_usb_af9015]
[] usb_unbind_interface+0x55/0x1a0
[] __device_release_driver+0x70/0xe0
...
So check against 1 there instead.
BTW why's the TODO there? Adding TODOs to the code without
descriptions is like adding nothing.
Signed-off-by: Jiri Slaby
Cc: Markus Rechberger
Cc: Mauro Carvalho Chehab
---
drivers/media/dvb/dvb-core/dmxdev.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dmxdev.c
b/drivers/media/dvb/dvb-core/dmxdev.c
index 425862f..0042306 100644
--- a/drivers/media/dvb/dvb-core/dmxdev.c
+++ b/drivers/media/dvb/dvb-core/dmxdev.c
@@ -207,7 +207,7 @@ static int dvb_dvr_release(struct inode *inode, struct file
*file)
}
/* TODO */
dvbdev->users--;
- if(dvbdev->users==-1 && dmxdev->exit==1) {
+ if (dvbdev->users == 1 && dmxdev->exit == 1) {
fops_put(file->f_op);
file->f_op = NULL;
mutex_unlock(&dmxdev->mutex);
--
1.7.1
--
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/1] VIDEO: ivtvfb, remove unneeded NULL test
Stanse found that in ivtvfb_callback_cleanup and ivtvfb_callback_init
there are unneeded tests for itv being NULL. But itv is initialized
as container_of with non-zero offset in those functions, so it is
never NULL (even if v4l2_dev is). This was found because itv is
dereferenced earlier than the test.
Signed-off-by: Jiri Slaby
Cc: Andy Walls
Cc: Mauro Carvalho Chehab
Cc: Tejun Heo
Cc: Ian Armstrong
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-media@vger.kernel.org
---
drivers/media/video/ivtv/ivtvfb.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtvfb.c
b/drivers/media/video/ivtv/ivtvfb.c
index 9ff3425..9c77bfa 100644
--- a/drivers/media/video/ivtv/ivtvfb.c
+++ b/drivers/media/video/ivtv/ivtvfb.c
@@ -1203,7 +1203,7 @@ static int __init ivtvfb_callback_init(struct device
*dev, void *p)
struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
- if (itv && (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
if (ivtvfb_init_card(itv) == 0) {
IVTVFB_INFO("Framebuffer registered on %s\n",
itv->v4l2_dev.name);
@@ -1219,7 +1219,7 @@ static int ivtvfb_callback_cleanup(struct device *dev,
void *p)
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
struct osd_info *oi = itv->osd_info;
- if (itv && (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
if (unregister_framebuffer(&itv->osd_info->ivtvfb_info)) {
IVTVFB_WARN("Framebuffer %d is in use, cannot unload\n",
itv->instance);
--
1.7.1
--
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] dvb: siano: free spinlock before schedule()
On 07/27/2010 08:42 PM, Kulikov Vasiliy wrote:
> Calling schedule() holding spinlock with disables irqs is improper. As
> spinlock protects list coredev->buffers, it can be unlocked untill wakeup.
> This bug was introduced in a9349315f65cd6a16e8fab1f6cf0fd40f379c4db.
>
> Signed-off-by: Kulikov Vasiliy
> ---
> drivers/media/dvb/siano/smscoreapi.c |6 --
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/dvb/siano/smscoreapi.c
> b/drivers/media/dvb/siano/smscoreapi.c
> index 7f2c94a..d93468c 100644
> --- a/drivers/media/dvb/siano/smscoreapi.c
> +++ b/drivers/media/dvb/siano/smscoreapi.c
> @@ -1113,9 +1113,11 @@ struct smscore_buffer_t *smscore_getbuffer(struct
> smscore_device_t *coredev)
>*/
>
> prepare_to_wait(&coredev->buffer_mng_waitq, &wait, TASK_INTERRUPTIBLE);
> -
> - if (list_empty(&coredev->buffers))
> + if (list_empty(&coredev->buffers)) {
> + spin_unlock_irqrestore(&coredev->bufferslock, flags);
> schedule();
> + spin_lock_irqsave(&coredev->bufferslock, flags);
> + }
>
> finish_wait(&coredev->buffer_mng_waitq, &wait);
There is a better fix (which fixes the potential NULL dereference):
http://lkml.org/lkml/2010/6/7/175
Richard, could you address the comments there and resend?
regards,
--
js
--
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 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 01/26/2010 02:08 PM, Jiri Kosina wrote:
>> In my understanding the cause of the remote problem is chipset bug which sets
>> USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
>> or starts repeating. It is possible to implement remote as polling from the
>> driver which works very well. But HID problem still remains. I have some
>> hacks
>> in my mind to test to kill HID. One is to configure HID wrongly to see if it
>> stops outputting characters. Other way is try to read remote codes directly
>> from the chip memory.
>
> Yes, Pekka Sarnila has added this workaround to the HID driver, as the
> device is apparently broken.
>
> I want to better understand why others are not hitting this with the
> DVB remote driver before removing the quirk from HID code completely.
I think, we should go for a better way. Thanks Pekka for hints, I ended
up with the patch in the attachment. Could you try it whether it works
for you?
I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
disable_rc_polling (a dvb_usb module parameter) must be set to not get
doubled characters now. And then, it works like a charm.
Note that, it's just some kind of proof of concept. A migration of
af9015 devices from dvb-usb-remote needs to be done first.
Ideas, comments?
regards,
--
js
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 139668d..0daf90a 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -122,6 +122,13 @@ config DRAGONRISE_FF
Say Y here if you want to enable force feedback support for DragonRise Inc.
game controllers.
+config HID_DVB
+ tristate "DVB remotes support" if EMBEDDED
+ depends on USB_HID
+ default !EMBEDDED
+ ---help---
+ Say Y here if you have DVB remote controllers.
+
config HID_EZKEY
tristate "Ezkey" if EMBEDDED
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index b62d4b3..a336b2a 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_HID_CHERRY) += hid-cherry.o
obj-$(CONFIG_HID_CHICONY) += hid-chicony.o
obj-$(CONFIG_HID_CYPRESS) += hid-cypress.o
obj-$(CONFIG_HID_DRAGONRISE) += hid-drff.o
+obj-$(CONFIG_HID_DVB) += hid-dvb.o
obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_KENSINGTON) += hid-kensington.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 2dd9b28..678c553 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1252,6 +1252,7 @@ static const struct hid_device_id hid_blacklist[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M1968) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ATV_IRCONTROL) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_IRCONTROL4) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE) },
@@ -1310,6 +1311,7 @@ static const struct hid_device_id hid_blacklist[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LABTEC, USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LEADTEK, USB_DEVICE_ID_DTV_GOLD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_S510_RECEIVER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_S510_RECEIVER_2) },
diff --git a/drivers/hid/hid-dvb.c b/drivers/hid/hid-dvb.c
new file mode 100644
index 000..ee94c07
--- /dev/null
+++ b/drivers/hid/hid-dvb.c
@@ -0,0 +1,78 @@
+/*
+ * HID driver for dvb devices
+ *
+ * Copyright (c) 2010 Jiri Slaby
+ *
+ * Licensed under the GPLv2.
+ */
+
+#include
+#include
+#include
+
+#include "hid-ids.h"
+
+#define FULLSPEED_INTERVAL 0x1
+
+static int dvb_event(struct hid_device *hdev, struct hid_field *field,
+ struct hid_usage *usage, __s32 value)
+{
+ /* we won't get a "key up" event */
+ if (value) {
+ input_event(field->hidinput->input, usage->type, usage->code, 1);
+ input_event(field->hidinput->input, usage->type, usage->code, 0);
+ }
+ return 1;
+}
+
+static int dvb_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ unsigned long quirks = id->driver_data;
+ int ret;
+
+ if (quirks & FULLSPEED_INTERVAL)
+ hdev->quirks |= HID_QUIRK_FULLSPEED_INTERVAL;
+
+ ret = hid_parse(hdev);
+ if (ret) {
+ dev_err(&hdev->dev, "parse failed\n");
+ goto end;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret)
+ dev_err(&hdev->dev, "hw start
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
>> I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
>> disable_rc_polling (a dvb_usb module parameter) must be set to not get
>> doubled characters now. And then, it works like a charm.
>
> Module parameters always bothers me. They should be used as last resort
> alternatives
> when there's no other possible way to make it work properly.
>
> If we know for sure that the RC polling should be disabled by an specific
> device,
> just add this logic at the driver.
Yes, this is planned and written below:
>> Note that, it's just some kind of proof of concept. A migration of
>> af9015 devices from dvb-usb-remote needs to be done first.
>>
>> Ideas, comments?
>
> Please next time, send the patch inlined. As you're using Thunderbird, you'll
> likely need
> Asalted-patches[1] to avoid thunderbird to destroy your patches.
I must disagree for two reasons: (a) it was not patch intended for merge
and (b) it was a plain-text attachment which is fine even for
submission. However I don't like patches as attachments so if I decide
to submit it for a merge later, you will not see it as an attachment
then :).
> +config HID_DVB
> + tristate "DVB remotes support" if EMBEDDED
> + depends on USB_HID
> + default !EMBEDDED
> + ---help---
> + Say Y here if you have DVB remote controllers.
> +
>
> I think the better would be to use a more generic name, like HID_RC (for
> Remote Controller).
> I suspect we may need in the future other hacks for other similar devices.
Seconded. I would only go for some other abbreviation other than RC or
not abbreviate that at all.
> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
> + struct hid_usage *usage, __s32 value)
> +{
> + /* we won't get a "key up" event */
> + if (value) {
> + input_event(field->hidinput->input, usage->type, usage->code,
> 1);
> + input_event(field->hidinput->input, usage->type, usage->code,
> 0);
> + }
> + return 1;
> +}
>
> Several V4L/DVB IR's have keyup/keydown events. So I think the name here is
> also wrong:
> it is better to name the function as dvb_nokeyup_event() and eventually add
> an specific
> quirk to indicate devices that only have key up events.
If such appear later, it can be rewritten. I don't plan to add such
functionality now until somebody comes with device IDs which should be
handled that way and tests it, because I guess I will definitely do it
wrong otherwise. Do you know/have such a device?
There are many of quirks needed for various devices. I already wrote
about af9005 which sends key repeat aside from key down etc. But the
same as above, I can't test it (and don't want to introduce
regressions). So again, if somebody can test it, I'll be happy to code it.
thanks for the input,
--
js
--
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 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 02/04/2010 02:41 PM, Mauro Carvalho Chehab wrote: > The point is that it is better to name the function right since the beginning. Sorry, I misunderstood you for the first time. It's .event member of hid_driver. Hence I named it dvb_event (or now rc_event or whatever). The function may contain decisions on what to do with the event based for example on quirks set up in .probe. And if the function grows later, it may be factored out to rc_nokeyup_event. But rc_event is a root for the decision tree and it should be there forever. Does it make sense now? -- js -- 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 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 02/04/2010 07:14 PM, Dmitry Torokhov wrote:
> On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
> +
>> +static int dvb_event(struct hid_device *hdev, struct hid_field *field,
>> +struct hid_usage *usage, __s32 value)
>> +{
>> +/* we won't get a "key up" event */
>> +if (value) {
>> +input_event(field->hidinput->input, usage->type, usage->code,
>> 1);
>> +input_event(field->hidinput->input, usage->type, usage->code,
>> 0);
>
> Do not ever forget input_sync(), you need 2 of them here.
>
> With the latest changes to evdev, if you are using SIGIO you won't get
> wioken up until EV_SYN/SYN_REPORT.
HID layer syncs on its own. So the second is not needed. Why is needed
the first?
I.e. should there be one also in dvb_usb_read_remote_control?
--
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/1] DVB: ngene, fix memset parameters
Switch second and third memset parameter to stamp the length buffer bytes
by 0xff's, not 255 bytes by low 8 bits of Length.
Signed-off-by: Jiri Slaby
Cc: Matthias Benesch
Cc: Ralph Metzler
Cc: Oliver Endriss
Cc: Mauro Carvalho Chehab
---
drivers/media/dvb/ngene/ngene-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index cb5982e..0150dfe 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -564,7 +564,7 @@ static void FillTSBuffer(void *Buffer, int Length, u32
Flags)
{
u32 *ptr = Buffer;
- memset(Buffer, Length, 0xff);
+ memset(Buffer, 0xff, Length);
while (Length > 0) {
if (Flags & DF_SWAP32)
*ptr = 0x471FFF10;
--
1.6.6.1
--
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] V4L: dvb-usb, add extra sync to down-up input events
Userspace is allowed to coalesce events between SYNCs. And since the code
emits UP right after DOWN for the same key, it may be missed
(up+down=nothing). Add an extra sync in between UP and DOWN events to disable
the coalesce.
Signed-off-by: Jiri Slaby
Cc: Dmitry Torokhov
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/dib0700_core.c |1 +
drivers/media/dvb/dvb-usb/dvb-usb-remote.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 4450214..4f961d2 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -612,6 +612,7 @@ static void dib0700_rc_urb_completion(struct urb *purb)
case REMOTE_KEY_REPEAT:
deb_info("key repeated\n");
input_event(d->rc_input_dev, EV_KEY, event, 1);
+ input_sync(d->rc_input_dev);
input_event(d->rc_input_dev, EV_KEY, d->last_event, 0);
input_sync(d->rc_input_dev);
break;
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
index 6b5ded9..a03ef7e 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-remote.c
@@ -107,6 +107,7 @@ static void dvb_usb_read_remote_control(struct work_struct
*work)
case REMOTE_KEY_REPEAT:
deb_rc("key repeated\n");
input_event(d->rc_input_dev, EV_KEY, event, 1);
+ input_sync(d->rc_input_dev);
input_event(d->rc_input_dev, EV_KEY, d->last_event, 0);
input_sync(d->rc_input_dev);
break;
--
1.6.6.1
--
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/4] V4L: cx231xx, fix lock imbalance
Stanse found that there is mutex_lock in a fail path of
cx231xx_i2c_xfer instead of mutex_unlock (i.e. double lock + leaving a
function in locked state). So fix that.
Signed-off-by: Jiri Slaby
Cc: Mauro Carvalho Chehab
Cc: Devin Heitmueller
---
drivers/media/video/cx231xx/cx231xx-i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/cx231xx/cx231xx-i2c.c
b/drivers/media/video/cx231xx/cx231xx-i2c.c
index cce74e5..8356706 100644
--- a/drivers/media/video/cx231xx/cx231xx-i2c.c
+++ b/drivers/media/video/cx231xx/cx231xx-i2c.c
@@ -372,7 +372,7 @@ static int cx231xx_i2c_xfer(struct i2c_adapter *i2c_adap,
rc = cx231xx_i2c_check_for_device(i2c_adap, &msgs[i]);
if (rc < 0) {
dprintk2(2, " no device\n");
- mutex_lock(&dev->i2c_lock);
+ mutex_unlock(&dev->i2c_lock);
return rc;
}
--
1.7.3.1
--
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/1] V4L: videobuf, don't use dma addr as physical
mem->dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU. So ensure we are
remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
by using virt_to_phys(mem->vaddr) and not mem->dma_handle.
Signed-off-by: Jiri Slaby
Cc: Mauro Carvalho Chehab
---
drivers/media/video/videobuf-dma-contig.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index c969111..8d778aa 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
retval = remap_pfn_range(vma, vma->vm_start,
-mem->dma_handle >> PAGE_SHIFT,
+virt_to_phys(mem->vaddr) >> PAGE_SHIFT,
size, vma->vm_page_prot);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
--
1.7.3.1
--
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 1/1] V4L: videobuf, don't use dma addr as physical
mem->dma_handle is a dma address obtained by dma_alloc_coherent which
needn't be a physical address in presence of IOMMU. So ensure we are
remapping (remap_pfn_range) the right page in __videobuf_mmap_mapper
by using virt_to_phys(mem->vaddr) and not mem->dma_handle.
While at it, use PFN_DOWN instead of explicit shift.
Signed-off-by: Jiri Slaby
Cc: Mauro Carvalho Chehab
Cc: Konrad Rzeszutek Wilk
---
drivers/media/video/videobuf-dma-contig.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index c969111..19d3e4a 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -300,7 +300,7 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
retval = remap_pfn_range(vma, vma->vm_start,
-mem->dma_handle >> PAGE_SHIFT,
+PFN_DOWN(virt_to_phys(mem->vaddr))
size, vma->vm_page_prot);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ", retval);
--
1.7.3.1
--
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 v3] Add tw5864 driver
On 07/11/2016, 07:58 AM, Hans Verkuil wrote: >> +static char *artifacts_warning = "BEWARE OF KNOWN ISSUES WITH VIDEO >> QUALITY\n" > > const char * const Or even better, drop the extra space for pointer: static const char artifacts_warning[] = thanks, -- js suse labs -- 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
AF9035 with no tuner?
Hello, I have a USB device which digitizes composite video into a MPEG-2 stream (I think). It is an AF9035 device according to windows. But it has no tuner. Is there a way to make it working on linux or am I out of luck? lsusb -v: Bus 001 Device 016: ID 1d19:6105 Dexatek Technology Ltd. Video grabber Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1d19 Dexatek Technology Ltd. idProduct 0x6105 Video grabber bcdDevice2.00 iManufacturer 1 Afa Technologies Inc. iProduct2 ITE Video Capture Device iSerial 3 AF010202071 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 97 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 5 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 5 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes2 Transfer TypeBulk
Re: AF9035 with no tuner?
On 12/12/2015, 10:12 PM, Benjamin Larsson wrote: > On 12/12/2015 10:08 PM, Jiri Slaby wrote: >> Hello, >> >> I have a USB device which digitizes composite video into a MPEG-2 stream >> (I think). It is an AF9035 device according to windows. But it has no >> tuner. Is there a way to make it working on linux or am I out of luck? >> > > Open the device and take pictures of the pcb and the chips. After that > it might be possible to identify what kind of device it is. Sure: http://www.fi.muni.cz/~xslaby/sklad/back.JPG http://www.fi.muni.cz/~xslaby/sklad/front.JPG thanks, -- js -- 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] dib0700: do not lock interruptible on tear-down paths
When mutex_lock_interruptible is used on paths where a signal can be
pending, the device is not closed properly and cannot be reused.
This usually happens when you start tzap for example and send it a
TERM signal. The signal is pending while tear-down routines are
called. Hence streaming is not properly stopped in that case. And
the device stops working from that moment on.
Signed-off-by: Jiri Slaby
---
drivers/media/usb/dvb-usb/dib0700_core.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
b/drivers/media/usb/dvb-usb/dib0700_core.c
index 19b5ed2..bf2a908 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -561,10 +561,7 @@ int dib0700_streaming_ctrl(struct dvb_usb_adapter *adap,
int onoff)
}
}
- if (mutex_lock_interruptible(&adap->dev->usb_mutex) < 0) {
- err("could not acquire lock");
- return -EINTR;
- }
+ mutex_lock(&adap->dev->usb_mutex);
st->buf[0] = REQUEST_ENABLE_VIDEO;
/* this bit gives a kind of command,
--
1.8.1
--
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] Initial scan files troubles and brainstorming
On 12/18/2012 11:01 PM, Oliver Schinagl wrote: > Unfortunatly, I have had zero replies. Hmm, it's sad there is a silence in this thread from linux-media guys :/. > So why bring it up again? On 2012/11/30 Jakub Kasprzycki provided us > with updated polish DVB-T frequencies for his region. This has yet to be > merged, almost 3 weeks later. I sent a patch for cz data too: https://patchwork.kernel.org/patch/1844201/ > I'll quickly repeat why I think this approach would be quite reasonable. > > * dvb-apps binary changes don't result in unnecessary releases > * frequency updates don't result in unnecessary dvb-app releases > * Less strict requirements for commits (code reviews etc) Well the code should be reviewed still. See commit a2e96055db297 in your repo, it's bogus. The freq added is in kHz instead of MHz. > * Possibly easier entry for new submitters > * much easier to package (tag it once per month if an update was) > * Separate maintainer possible > * just seems more logical to have it separated ;) The downside is you have to change the URL in kaffeine sources as kaffeine generates its scan file from that repo (on the server side and the client downloads then http://kaffeine.kde.org/scanfile.dvb.qz). > This obviously should find a nice home on linuxtv where it belongs! At best. > Here is my personal repository with the work I mentioned done. > git://git.schinagl.nl/dvb_frequency_scanfiles.git > > If an issue is that none of the original maintainers are not looking > forward to do the job, I am willing to take maintenance on me for now. Ping? Anybody? I would help with that too as I hate resending patches. But the first step I would do is a conversion to GIT. HG is demented to begin with. -- js -- 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
kaffeine.kde.org/scanfile.dvb.qz is obsolete [was: [RFC] Initial scan files troubles and brainstorming]
On 01/09/2013 03:41 PM, Mauro Carvalho Chehab wrote: > Christoph, > > Thank you for all the hard work over all those years! Yeah, I second this. I have a note though. Who is going to fix the URL in kaffeine? And how often is kaffeine.kde.org/scanfile.dvb.qz updated? Is this done automatically? As it is pretty outdated (9/2011), I don't think it is... Should this be moved somewhere else? thanks, -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 06:40 PM, Manu Abraham wrote: > On 1/9/13, Mauro Carvalho Chehab wrote: >> Em Wed, 9 Jan 2013 06:08:44 -0500 >> Michael Krufky escreveu: >> >>> On Wed, Jan 9, 2013 at 5:41 AM, Mauro Carvalho Chehab >>> wrote: >>>> Em Wed, 09 Jan 2013 10:43:23 +0100 >>>> Oliver Schinagl escreveu: >>>> >>>>> On 08-01-13 21:01, Johannes Stezenbach wrote: >>>>>> On Mon, Jan 07, 2013 at 01:48:29PM +0100, Oliver Schinagl wrote: >>>>>>> On 07-01-13 11:46, Jiri Slaby wrote: >>>>>>>> On 12/18/2012 11:01 PM, Oliver Schinagl wrote: >>>>>>>>> Unfortunatly, I have had zero replies. >>>>>>>> Hmm, it's sad there is a silence in this thread from linux-media >>>>>>>> guys :/. >>>>>>> In their defense, they are very very busy people ;) chatter on this >>>>>>> thread does bring it up however. >>>>>> This is such a nice thing to say :-) >>>>>> But it might be that Mauro thinks the dvb-apps maintainer should >>>>>> respond, but apparently there is no dvb-apps maintainer... >>>>>> Maybe you should ask Mauro directly to create an account for you >>>>>> to implement what you proposed. >>>>> Mauro is CC'ed and I'd ask of course for this (I kinda did) but who >>>>> decides what I suggested is a good idea? I personally obviously think >>>>> it >>>>> is ;) and even more so if dvb-apps are unmaintained. >>>>> >>>>> I guess the question now becomes 'who okay's this change? Who says >>>>> 'okay, lets do it this way. Once that is answered we can go from there >>>>> ;) >>>> >>>> If I understood it right, you want to split the scan files into a >>>> separate >>>> git tree and maintain it, right? >>>> >>>> I'm ok with that. >>>> >>>> Regards, >>>> Mauro >>> >>> As a DVB maintainer, I am OK with this as well - It does indeed make >>> sense to separate the c code sources from the regional frequency >>> tables, and I'm sure we'll see much benefit from this change. >> >> Done. I created a tree for Oliver to maintain it and an account for him. >> I also created a new tree with just the DVB table commits to: >> http://git.linuxtv.org/dtv-scan-tables.git >> >> I kept there both szap and scan files, although maybe it makes sense to >> drop the szap table (channels-conf dir). It also makes sense to drop the >> tables from the dvb-apps tree, to avoid duplicated stuff, and to avoid > > Being one of the maintainers: > > I will keep the tables in the dvb-apps tree for the time being. That does not make sense at all -- why? Duplicated stuff always hurts. > Will decide to > drop the config files as needed from dvb-apps. It is necessary to keep a > copy of the config files for development purposes, rather than pulling from > different trees. What development purposes, could you be more specific? You can still use git submodules if really needed. But as it stands I do not see a reason for that at all... regards, -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 07:46 PM, Manu Abraham wrote: > The scan files and config files are very specific to dvb-apps, some > applications > do rely on these config files. It doesn't really make sense to have > split out config > files for these small applications. I don't care where they are, really. However I'm strongly against duplicating them. Feel free to remove the newly created repository, I'll be fine with that. > So according to you, you want to make it > still harder for someone to work with dvb-apps. I wasn't the one to suggest a separate directory for the data, there is no point in blaming me... -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 07:56 PM, Michael Krufky wrote: > I see great value in separating the history of the data files from the > code files. If you really think this is such a terrible task for a > developer to have to pull from a second repository to fetch these data > files, then I find no reason why we couldn't script it such that > building the dvb-apps package would trigger the pull from the > additional repository. (Or use submodules.) -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 08:08 PM, Manu Abraham wrote: > On 1/11/13, Jiri Slaby wrote: >> On 01/10/2013 07:46 PM, Manu Abraham wrote: >>> The scan files and config files are very specific to dvb-apps, some >>> applications >>> do rely on these config files. It doesn't really make sense to have >>> split out config >>> files for these small applications. >> >> I don't care where they are, really. However I'm strongly against >> duplicating them. Feel free to remove the newly created repository, I'll >> be fine with that. > > I haven't duplicated anything at all. It is Mauro who has duplicated stuff, > by creating a new tree altogether. I didn't accuse you. This was a general comment to everybody. Whatever the consensus is at the end, do not duplicate the data. > if you need the scan files to be properly maintained then you need to > handle it in the same repository altogether. Not by separating out the > configuration files of a few applications. That's up to you guys to decide. I don't mind either option. -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 09:25 PM, Manu Abraham wrote: >> Also, purely out of curiousity, how are the scanfiles used during >> development? > > The scanfiles what you call them are the configuration files for dvb-apps, > rather than purely data files. But you cannot change their format, so what's the point? You can use them from a different directory or system ones... -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 09:38 PM, Manu Abraham wrote: > The format can be definitely changed. There's no issue to it. No you cannot. Applications depend on that, it's part of the dvb ABI. If you changed that, you would do the same mistake as Mauro let it flowing through his tree and it was pointed out by Linus in the link you sent... -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 09:41 PM, Jiri Slaby wrote: > On 01/10/2013 09:38 PM, Manu Abraham wrote: >> The format can be definitely changed. There's no issue to it. > > No you cannot. Applications depend on that, it's part of the dvb ABI. If > you changed that, you would do the same mistake as Mauro let it flowing > through his tree and it was pointed out by Linus in the link you sent... Id you provide an abstraction library, convert all applications to use that instead of the files, you can change them then. Not any time before. -- js -- 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] Initial scan files troubles and brainstorming
On 01/10/2013 09:49 PM, Manu Abraham wrote: > On 1/11/13, Jiri Slaby wrote: >> On 01/10/2013 09:38 PM, Manu Abraham wrote: >>> The format can be definitely changed. There's no issue to it. >> >> No you cannot. Applications depend on that, it's part of the dvb ABI. If >> you changed that, you would do the same mistake as Mauro let it flowing >> through his tree and it was pointed out by Linus in the link you sent... > > I understand what you are thinking, but that's not exactly about it. The > format > can simply be updated by adding newer params to it's end, thus not breaking > any of the applications. OK, but that still does not explain why it is requisite to have the data along with the sources. There is no problem in updating both the files and scandata separately, because it has to be compatible. Also I'm not sure whether adding a column at the end wouldn't break the apps. -- js -- 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] Initial scan files troubles and brainstorming
On 01/11/2013 01:39 PM, Mauro Carvalho Chehab wrote: > tgz: > git archive --format tgz HEAD >dtv-scan-files-`date > +"%Y%m%d.%H:%M"`.tar.gz Better to use the top commit date: git log -n1 --date=short --pretty=format:%ad You won't generate a snapshot every day with the same contents then. or %ad-g%p if you want also a short commit id in there. -- js -- 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-tools: scan_data/cz-all: 4th multiplex has FEC 3/4
-- js # HG changeset patch # User Jiri Slaby # Date 1354786687 -3600 # Node ID c72238053530a0ad8e446af2cce0cb8d14c9640a # Parent 96025655e6e844af2bc69bd368f8d04a4e5bc58b scan_data/cz-all: 4th multiplex has FEC 3/4 Not 2/3. This I inappropriatelly got from the website. But it is wrong. 3/4 is definitely correct. Change that so that we can actually tune that multiplex. diff -r 96025655e6e8 -r c72238053530 util/scan/dvb-t/cz-All --- a/util/scan/dvb-t/cz-All Tue Jun 26 22:28:54 2012 +0200 +++ b/util/scan/dvb-t/cz-All Thu Dec 06 10:38:07 2012 +0100 @@ -42,11 +42,11 @@ T 77800 8MHz 3/4 NONE QAM64 8k 1/8 NONE T 78600 8MHz 3/4 NONE QAM64 8k 1/8 NONE # multiplex 4 -T 50600 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 54600 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 64200 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 66600 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 75400 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 81000 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 81800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 50600 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 54600 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 64200 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 65800 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 66600 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 75400 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 81000 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 81800 8MHz 3/4 NONE QAM64 8k 1/8 NONE
[PATCH 2/4] DVB: dib0700, separate stk7070pd initialization
The start is common for both stk7070pd and novatd specific routine.
This is just a preparation for the next patch.
Signed-off-by: Jiri Slaby
---
drivers/media/dvb/dvb-usb/dib0700_devices.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 3c6ee54..e5c2bd2 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -3066,19 +3066,25 @@ static struct dib7000p_config
stk7070pd_dib7000p_config[2] = {
}
};
-static int stk7070pd_frontend_attach0(struct dvb_usb_adapter *adap)
+static void stk7070pd_init(struct dvb_usb_device *dev)
{
- dib0700_set_gpio(adap->dev, GPIO6, GPIO_OUT, 1);
+ dib0700_set_gpio(dev, GPIO6, GPIO_OUT, 1);
msleep(10);
- dib0700_set_gpio(adap->dev, GPIO9, GPIO_OUT, 1);
- dib0700_set_gpio(adap->dev, GPIO4, GPIO_OUT, 1);
- dib0700_set_gpio(adap->dev, GPIO7, GPIO_OUT, 1);
- dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 0);
+ dib0700_set_gpio(dev, GPIO9, GPIO_OUT, 1);
+ dib0700_set_gpio(dev, GPIO4, GPIO_OUT, 1);
+ dib0700_set_gpio(dev, GPIO7, GPIO_OUT, 1);
+ dib0700_set_gpio(dev, GPIO10, GPIO_OUT, 0);
- dib0700_ctrl_clock(adap->dev, 72, 1);
+ dib0700_ctrl_clock(dev, 72, 1);
msleep(10);
- dib0700_set_gpio(adap->dev, GPIO10, GPIO_OUT, 1);
+ dib0700_set_gpio(dev, GPIO10, GPIO_OUT, 1);
+}
+
+static int stk7070pd_frontend_attach0(struct dvb_usb_adapter *adap)
+{
+ stk7070pd_init(adap->dev);
+
msleep(10);
dib0700_set_gpio(adap->dev, GPIO0, GPIO_OUT, 1);
--
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
[PATCH 4/4] DVB: dib0700, add support for Nova-TD LEDs
Add an override of read_status to intercept lock status. This allows
us to switch LEDs appropriately on and off with signal un/locked.
The second phase is to override sleep to properly turn off both.
This is a hackish way to achieve that.
Thanks to Mike Krufky for his help.
Signed-off-by: Jiri Slaby
---
drivers/media/dvb/dvb-usb/dib0700.h |2 +
drivers/media/dvb/dvb-usb/dib0700_devices.c | 41 ++-
2 files changed, 42 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700.h
b/drivers/media/dvb/dvb-usb/dib0700.h
index 9bd6d51..7de125c 100644
--- a/drivers/media/dvb/dvb-usb/dib0700.h
+++ b/drivers/media/dvb/dvb-usb/dib0700.h
@@ -48,6 +48,8 @@ struct dib0700_state {
u8 disable_streaming_master_mode;
u32 fw_version;
u32 nb_packet_buffer_size;
+ int (*read_status)(struct dvb_frontend *, fe_status_t *);
+ int (*sleep)(struct dvb_frontend* fe);
u8 buf[255];
};
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 3ab45ae..f9e966a 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -3105,6 +3105,35 @@ static int stk7070pd_frontend_attach1(struct
dvb_usb_adapter *adap)
return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
}
+static int novatd_read_status_override(struct dvb_frontend *fe,
+ fe_status_t *stat)
+{
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct dvb_usb_device *dev = adap->dev;
+ struct dib0700_state *state = dev->priv;
+ int ret;
+
+ ret = state->read_status(fe, stat);
+
+ if (!ret)
+ dib0700_set_gpio(dev, adap->id == 0 ? GPIO1 : GPIO0, GPIO_OUT,
+ !!(*stat & FE_HAS_LOCK));
+
+ return ret;
+}
+
+static int novatd_sleep_override(struct dvb_frontend* fe)
+{
+ struct dvb_usb_adapter *adap = fe->dvb->priv;
+ struct dvb_usb_device *dev = adap->dev;
+ struct dib0700_state *state = dev->priv;
+
+ /* turn off LED */
+ dib0700_set_gpio(dev, adap->id == 0 ? GPIO1 : GPIO0, GPIO_OUT, 0);
+
+ return state->sleep(fe);
+}
+
/**
* novatd_frontend_attach - Nova-TD specific attach
*
@@ -3114,6 +3143,7 @@ static int stk7070pd_frontend_attach1(struct
dvb_usb_adapter *adap)
static int novatd_frontend_attach(struct dvb_usb_adapter *adap)
{
struct dvb_usb_device *dev = adap->dev;
+ struct dib0700_state *st = dev->priv;
if (adap->id == 0) {
stk7070pd_init(dev);
@@ -3134,7 +3164,16 @@ static int novatd_frontend_attach(struct dvb_usb_adapter
*adap)
adap->fe_adap[0].fe = dvb_attach(dib7000p_attach, &dev->i2c_adap,
adap->id == 0 ? 0x80 : 0x82,
&stk7070pd_dib7000p_config[adap->id]);
- return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
+
+ if (adap->fe_adap[0].fe == NULL)
+ return -ENODEV;
+
+ st->read_status = adap->fe_adap[0].fe->ops.read_status;
+ adap->fe_adap[0].fe->ops.read_status = novatd_read_status_override;
+ st->sleep = adap->fe_adap[0].fe->ops.sleep;
+ adap->fe_adap[0].fe->ops.sleep = novatd_sleep_override;
+
+ return 0;
}
/* S5H1411 */
--
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
[PATCH 3/4] DVB: dib0700, add corrected Nova-TD frontend_attach
This means cut & paste from the former f. attach. But while at it write
to the right GPIO to turn on the right LED. Also turn the other two
off jsut for sure.
Signed-off-by: Jiri Slaby
---
drivers/media/dvb/dvb-usb/dib0700_devices.c | 36 +-
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index e5c2bd2..3ab45ae 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -3105,6 +3105,38 @@ static int stk7070pd_frontend_attach1(struct
dvb_usb_adapter *adap)
return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
}
+/**
+ * novatd_frontend_attach - Nova-TD specific attach
+ *
+ * Nova-TD has GPIO0, 1 and 2 for LEDs. So do not fiddle with them except for
+ * information purposes.
+ */
+static int novatd_frontend_attach(struct dvb_usb_adapter *adap)
+{
+ struct dvb_usb_device *dev = adap->dev;
+
+ if (adap->id == 0) {
+ stk7070pd_init(dev);
+
+ /* turn the power LED on, the other two off (just in case) */
+ dib0700_set_gpio(dev, GPIO0, GPIO_OUT, 0);
+ dib0700_set_gpio(dev, GPIO1, GPIO_OUT, 0);
+ dib0700_set_gpio(dev, GPIO2, GPIO_OUT, 1);
+
+ if (dib7000p_i2c_enumeration(&dev->i2c_adap, 2, 18,
+stk7070pd_dib7000p_config) != 0) {
+ err("%s: dib7000p_i2c_enumeration failed. Cannot
continue\n",
+ __func__);
+ return -ENODEV;
+ }
+ }
+
+ adap->fe_adap[0].fe = dvb_attach(dib7000p_attach, &dev->i2c_adap,
+ adap->id == 0 ? 0x80 : 0x82,
+ &stk7070pd_dib7000p_config[adap->id]);
+ return adap->fe_adap[0].fe == NULL ? -ENODEV : 0;
+}
+
/* S5H1411 */
static struct s5h1411_config pinnacle_801e_config = {
.output_mode = S5H1411_PARALLEL_OUTPUT,
@@ -3876,7 +3908,7 @@ struct dvb_usb_device_properties dib0700_devices[] = {
.pid_filter_count = 32,
.pid_filter = stk70x0p_pid_filter,
.pid_filter_ctrl = stk70x0p_pid_filter_ctrl,
- .frontend_attach = stk7070pd_frontend_attach0,
+ .frontend_attach = novatd_frontend_attach,
.tuner_attach = dib7070p_tuner_attach,
DIB0700_DEFAULT_STREAMING_CONFIG(0x02),
@@ -3889,7 +3921,7 @@ struct dvb_usb_device_properties dib0700_devices[] = {
.pid_filter_count = 32,
.pid_filter = stk70x0p_pid_filter,
.pid_filter_ctrl = stk70x0p_pid_filter_ctrl,
- .frontend_attach = stk7070pd_frontend_attach1,
+ .frontend_attach = novatd_frontend_attach,
.tuner_attach = dib7070p_tuner_attach,
DIB0700_DEFAULT_STREAMING_CONFIG(0x03),
--
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
[PATCH 1/4] DVB: dib0700, move Nova-TD Stick to a separate set
To properly support the three LEDs which are on the stick, we need
a special handling in the ->frontend_attach function. Thus let's have
a separate ->frontend_attach instead of ifs in the common one.
The hadnling itself will be added in further patches.
Signed-off-by: Jiri Slaby
---
drivers/media/dvb/dvb-usb/dib0700_devices.c | 57 --
1 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 81ef4b4..3c6ee54 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -3892,7 +3892,58 @@ struct dvb_usb_device_properties dib0700_devices[] = {
}
},
- .num_device_descs = 6,
+ .num_device_descs = 1,
+ .devices = {
+ { "Hauppauge Nova-TD Stick (52009)",
+ { &dib0700_usb_id_table[35], NULL },
+ { NULL },
+ },
+ },
+
+ .rc.core = {
+ .rc_interval = DEFAULT_RC_INTERVAL,
+ .rc_codes = RC_MAP_DIB0700_RC5_TABLE,
+ .module_name = "dib0700",
+ .rc_query = dib0700_rc_query_old_firmware,
+ .allowed_protos = RC_TYPE_RC5 |
+ RC_TYPE_RC6 |
+ RC_TYPE_NEC,
+ .change_protocol = dib0700_change_protocol,
+ },
+ }, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+
+ .num_adapters = 2,
+ .adapter = {
+ {
+ .num_frontends = 1,
+ .fe = {{
+ .caps = DVB_USB_ADAP_HAS_PID_FILTER |
DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
+ .pid_filter_count = 32,
+ .pid_filter = stk70x0p_pid_filter,
+ .pid_filter_ctrl = stk70x0p_pid_filter_ctrl,
+ .frontend_attach = stk7070pd_frontend_attach0,
+ .tuner_attach = dib7070p_tuner_attach,
+
+ DIB0700_DEFAULT_STREAMING_CONFIG(0x02),
+ }},
+ .size_of_priv = sizeof(struct
dib0700_adapter_state),
+ }, {
+ .num_frontends = 1,
+ .fe = {{
+ .caps = DVB_USB_ADAP_HAS_PID_FILTER |
DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
+ .pid_filter_count = 32,
+ .pid_filter = stk70x0p_pid_filter,
+ .pid_filter_ctrl = stk70x0p_pid_filter_ctrl,
+ .frontend_attach = stk7070pd_frontend_attach1,
+ .tuner_attach = dib7070p_tuner_attach,
+
+ DIB0700_DEFAULT_STREAMING_CONFIG(0x03),
+ }},
+ .size_of_priv = sizeof(struct
dib0700_adapter_state),
+ }
+ },
+
+ .num_device_descs = 5,
.devices = {
{ "DiBcom STK7070PD reference design",
{ &dib0700_usb_id_table[17], NULL },
@@ -3902,10 +3953,6 @@ struct dvb_usb_device_properties dib0700_devices[] = {
{ &dib0700_usb_id_table[18], NULL },
{ NULL },
},
- { "Hauppauge Nova-TD Stick (52009)",
- { &dib0700_usb_id_table[35], NULL },
- { NULL },
- },
{ "Hauppauge Nova-TD-500 (84xxx)",
{ &dib0700_usb_id_table[36], NULL },
{ NULL },
--
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
[PATCH dvb-utils] proper dvb-t scan data for Czech Republic
BTW I would appreciate if you move also dvb-utils to GIT. hg wastes our time. -- js suse labs # HG changeset patch # User Jiri Slaby # Date 1340742534 -7200 # Node ID 96025655e6e844af2bc69bd368f8d04a4e5bc58b # Parent 4030c51d6e7baef760e65d4ff2e8f61af91bec02 proper dvb-t scan data for Czech Republic The tuning parameters are different for multiplexes 3 and 4. And the scan data are invalid for them. Further there are few more transmitters built in here. Especially for mux 4. So it is added too. diff -r 4030c51d6e7b -r 96025655e6e8 util/scan/dvb-t/cz-All --- a/util/scan/dvb-t/cz-All Tue Apr 10 16:44:06 2012 +0200 +++ b/util/scan/dvb-t/cz-All Tue Jun 26 22:28:54 2012 +0200 @@ -3,39 +3,50 @@ # and http://www.digizone.cz/texty/mapy-pokryti-multiplex-2-radiokomunikace/ # and http://www.digizone.cz/texty/mapy-pokryti-multiplex-3-czech-digital-group/ # and http://www.digizone.cz/texty/mapy-pokryti-multiplex-4-telefonica-o2/ +# and http://www.digitalnitelevize.cz/informace/dvb-t/vysilaci-sit-1.html +# and http://www.digitalnitelevize.cz/informace/dvb-t/vysilaci-sit-2.html # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 48200 8MHz 2/3 NONE QAM64 8k 1/4 NONE +# multiplexes 1+2 T 50600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 53800 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 54600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 56200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 57000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 57800 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 58600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 59400 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 60200 8MHz 2/3 NONE QAM64 8k 1/4 NONE +T 61000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 61800 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 62600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 63400 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 64200 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 65000 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 66600 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 67400 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 67400 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 69000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 69800 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 70600 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 71400 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 72200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 73000 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 73800 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 74600 8MHz 2/3 NONE QAM64 8k 1/4 NONE +T 76200 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 77000 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 77800 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 78600 8MHz 2/3 NONE QAM64 8k 1/4 NONE T 79400 8MHz 2/3 NONE QAM64 8k 1/4 NONE -T 80200 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 83400 8MHz 2/3 NONE QAM64 8k 1/4 NONE +# multiplex 3 +T 48200 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 50600 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 54600 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 57800 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 69800 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 71400 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 72200 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 74600 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 77800 8MHz 3/4 NONE QAM64 8k 1/8 NONE +T 78600 8MHz 3/4 NONE QAM64 8k 1/8 NONE +# multiplex 4 +T 50600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 54600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 64200 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 65800 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 66600 8MHz 2/3 NONE QAM64 8k 1/8 NONE +T 75400 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 81000 8MHz 2/3 NONE QAM64 8k 1/8 NONE T 81800 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 82600 8MHz 2/3 NONE QAM64 8k 1/8 NONE -T 83400 8MHz 2/3 NONE QAM64 8k 1/4 NONE
[PATCH -resend] DVB: dib0700, remove double \n's from log
err() already adds \n to the end of the format string. So remove one
more \n from formatting strings in the dib0700 driver.
Signed-off-by: Jiri Slaby
Cc: Mauro Carvalho Chehab
Cc: Michael Krufky
---
drivers/media/dvb/dvb-usb/dib0700_core.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 7e9e00f..ef87229 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -768,13 +768,13 @@ int dib0700_rc_setup(struct dvb_usb_device *d)
/* Starting in firmware 1.20, the RC info is provided on a bulk pipe */
purb = usb_alloc_urb(0, GFP_KERNEL);
if (purb == NULL) {
- err("rc usb alloc urb failed\n");
+ err("rc usb alloc urb failed");
return -ENOMEM;
}
purb->transfer_buffer = kzalloc(RC_MSG_SIZE_V1_20, GFP_KERNEL);
if (purb->transfer_buffer == NULL) {
- err("rc kzalloc failed\n");
+ err("rc kzalloc failed");
usb_free_urb(purb);
return -ENOMEM;
}
@@ -786,7 +786,7 @@ int dib0700_rc_setup(struct dvb_usb_device *d)
ret = usb_submit_urb(purb, GFP_ATOMIC);
if (ret) {
- err("rc submit urb failed\n");
+ err("rc submit urb failed");
kfree(purb->transfer_buffer);
usb_free_urb(purb);
}
--
1.7.10.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 2/5] MEDIA: ttusbir, fix double free
rc_unregister_device already calls rc_free_device to free the passed device. But in one of ttusbir's probe fail paths, we call rc_unregister_device _and_ rc_free_device. This is wrong and results in a double free. Instead, set rc to NULL resulting in rc_free_device being a noop. Signed-off-by: Jiri Slaby Cc: Sean Young Cc: Mauro Carvalho Chehab Cc: linux-media@vger.kernel.org --- drivers/media/rc/ttusbir.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/rc/ttusbir.c b/drivers/media/rc/ttusbir.c index cf0d47f..891762d 100644 --- a/drivers/media/rc/ttusbir.c +++ b/drivers/media/rc/ttusbir.c @@ -347,6 +347,7 @@ static int ttusbir_probe(struct usb_interface *intf, return 0; out3: rc_unregister_device(rc); + rc = NULL; out2: led_classdev_unregister(&tt->led); out: -- 1.8.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: V4L2 drivers: potentially dangerous and inefficient msecs_to_jiffies() calculation
On 09/14/2009 11:07 PM, Andreas Mohr wrote: > ./drivers/media/video/zc0301/zc0301_core.c > do > cam->module_param.frame_timeout * > 1000 * msecs_to_jiffies(1) ); > multiple times each. > What they should do instead is > frame_timeout * msecs_to_jiffies(1000), I'd think. In fact, msecs_to_jiffies(frame_timeout * 1000) makes much more sense. > msecs_to_jiffies(1) is quite a bit too boldly assuming > that all of the msecs_to_jiffies(x) implementation branches > always round up. They do, don't they? -- 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: V4L2 drivers: potentially dangerous and inefficient msecs_to_jiffies() calculation
On 09/14/2009 11:39 PM, Andreas Mohr wrote: > On Mon, Sep 14, 2009 at 11:34:40PM +0200, Jiri Slaby wrote: >> On 09/14/2009 11:07 PM, Andreas Mohr wrote: >>> msecs_to_jiffies(1) is quite a bit too boldly assuming >>> that all of the msecs_to_jiffies(x) implementation branches >>> always round up. >> >> They do, don't they? > > I'd hope so, but a slight risk remains, you never know, > especially with 4+ or so variants... A potential problem here is rather that it may wait longer due to returning 1 jiffie. It's then timeout * 1000 * 1. On 250HZ system it makes a difference of multiple of 4. Don't think it's a real issue in those drivers at all, but it's worth fixing. Care to post a patch? -- 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
