[PATCH] tm6000: bugfix bad marge
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-core.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 9f60ad5..1fea5a0 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -341,12 +341,6 @@ int tm6000_init_analog_mode(struct tm6000_core *dev)
dev-gpio.dvb_led, 0x01);
}
- /* switch dvb led off */
- if (dev-gpio.dvb_led) {
- tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-gpio.dvb_led, 0x01);
- }
-
return 0;
}
--
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: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added
Hello, On Monday, July 26, 2010 10:29 PM Hans Verkuil wrote: Hi Michal, Thanks for working on this, we definitely need something along these lines. On Monday 26 July 2010 16:40:30 Michal Nazarewicz wrote: The Contiguous Memory Allocator framework is a set of APIs for allocating physically contiguous chunks of memory. Various chips require contiguous blocks of memory to operate. Those chips include devices such as cameras, hardware video decoders and encoders, etc. The code is highly modular and customisable to suit the needs of various users. Set of regions reserved for CMA can be configured on run-time and it is easy to add custom allocator algorithms if one has such need. For more details see Documentation/contiguous-memory.txt. Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Pawel Osciak p.osc...@samsung.com --- Documentation/00-INDEX |2 + .../ABI/testing/sysfs-kernel-mm-contiguous |9 + Documentation/contiguous-memory.txt| 646 +++ Documentation/kernel-parameters.txt|4 + include/linux/cma.h| 445 mm/Kconfig | 34 + mm/Makefile|3 + mm/cma-best-fit.c | 407 +++ mm/cma.c | 1170 9 files changed, 2720 insertions(+), 0 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-contiguous create mode 100644 Documentation/contiguous-memory.txt create mode 100644 include/linux/cma.h create mode 100644 mm/cma-best-fit.c create mode 100644 mm/cma.c diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 5405f7a..bb50209 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -94,6 +94,8 @@ connector/ - docs on the netlink based userspace-kernel space communication mod. console/ - documentation on Linux console drivers. +contiguous-memory.txt + - documentation on physically-contiguous memory allocation framework. cpu-freq/ - info on CPU frequency and voltage scaling. cpu-hotplug.txt diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-contiguous b/Documentation/ABI/testing/sysfs-kernel-mm-contiguous new file mode 100644 index 000..05e2f6a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-contiguous @@ -0,0 +1,9 @@ +What: /sys/kernel/mm/contiguous/ +Date: July 2008 +Contact: Michal Nazarewicz m.nazarew...@samsung.com +Description: + /sys/kernel/mm/contiguous/ contains two files: asterisk and + map. They are used to configure the Contiguous Memory + Allocator framework. + + For details see Documentation/contiguous-memory.txt. diff --git a/Documentation/contiguous-memory.txt b/Documentation/contiguous-memory.txt new file mode 100644 index 000..6eb1295 --- /dev/null +++ b/Documentation/contiguous-memory.txt @@ -0,0 +1,646 @@ + -*- org -*- + +* Contiguous Memory Allocator + + The Contiguous Memory Allocator (CMA) is a framework, which allows + setting up a machine-specific configuration for physically-contiguous + memory management. Memory for devices is then allocated according + to that configuration. + + The main role of the framework is not to allocate memory, but to + parse and manage memory configurations, as well as to act as an + in-between between device drivers and pluggable allocators. It is + thus not tied to any memory allocation method or strategy. + +** Why is it needed? + +Various devices on embedded systems have no scatter-getter and/or +IO map support and as such require contiguous blocks of memory to +operate. They include devices such as cameras, hardware video +decoders and encoders, etc. + +Such devices often require big memory buffers (a full HD frame is, +for instance, more then 2 mega pixels large, i.e. more than 6 MB +of memory), which makes mechanisms such as kmalloc() ineffective. + +Some embedded devices impose additional requirements on the +buffers, e.g. they can operate only on buffers allocated in +particular location/memory bank (if system has more than one +memory bank) or buffers aligned to a particular memory boundary. + +Development of embedded devices have seen a big rise recently +(especially in the V4L area) and many such drivers include their +own memory allocation code. Most of them use bootmem-based methods. +CMA framework is an attempt to unify contiguous memory allocation +
Development list only?
Hello, I have been redirected here after subscribing to the linux-dvb list. Thus, I asked my usage-related question on this mailing list, but I did not get any reply up to now (subject Very poor quality on buget card TwinHan VP DST). I suspect that this is because this mailing list is not a user mailing list, but developers-only. If this is the case, could someone please point me in the right direction for discussing user issues like mine? Thank you very much, Arne Brutschy -- 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 for TwinHan VT DST and compatible DVB-T cards
Hi, here a small patch to get a TwinHan VT DST DVB-T card working with kernels = 2.6.32. Analogously to http://linuxtv.org/hg/v4l-dvb/rev/0e735b509163 I had to: Fill in the .caps field in struct dst_dvbt_ops (around line 1763) with all the supported QAM modulation methods to match the capabilities of the card as implemented in function dst_set_modulation (around line 502). Note that beginning with linux kernel version 2.6.32 the modulation method is checked (by function dvb_frontend_check_parameters in file drivers/media/dvb/dvb-core/dvb_frontend.c) and thus tuning fails if you use a modulation method that is not present in the .caps field. Patch: diff -r 9652f85e688a linux/drivers/media/dvb/bt8xx/dst.c --- a/linux/drivers/media/dvb/bt8xx/dst.c Thu May 27 02:02:09 2010 -0300 +++ b/linux/drivers/media/dvb/bt8xx/dst.c Tue Jul 27 09:34:38 2010 +0200 @@ -1763,7 +1763,15 @@ .frequency_min = 13700, .frequency_max = 85800, .frequency_stepsize = 17, - .caps = FE_CAN_FEC_AUTO | FE_CAN_QAM_AUTO | FE_CAN_TRANSMISSION_MODE_AUTO | FE_CAN_GUARD_INTERVAL_AUTO + .caps = FE_CAN_FEC_AUTO | + FE_CAN_QAM_AUTO | + FE_CAN_QAM_16 | + FE_CAN_QAM_32 | + FE_CAN_QAM_64 | + FE_CAN_QAM_128 | + FE_CAN_QAM_256 | + FE_CAN_TRANSMISSION_MODE_AUTO | + FE_CAN_GUARD_INTERVAL_AUTO }, .release = dst_release, -8-- Tested on 2.6.32-24, works fine. Thanks to Klaas de Waal for creating the original patch for the DVB-C cards. Hope this helps someone, Arne -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2 06/10] media: Entities, pads and links enumeration
Hi Hans,
On Monday 26 July 2010 21:48:28 Hans Verkuil wrote:
On Monday 26 July 2010 18:34:42 Laurent Pinchart wrote:
On Saturday 24 July 2010 14:45:39 Hans Verkuil wrote:
On Wednesday 21 July 2010 16:35:31 Laurent Pinchart wrote:
Create the following two ioctls and implement them at the media
device level to enumerate entities, pads and links.
- MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties
- MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given
entity
Entity IDs can be non-contiguous. Userspace applications should
enumerate entities using the MEDIA_ENTITY_ID_FLAG_NEXT flag. When the
flag is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return
the next entity with an ID bigger than the requested one.
Only forward links that originate at one of the entity's source pads
are returned during the enumeration process.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
Documentation/media-framework.txt | 134
drivers/media/media-device.c |
153 + include/linux/media.h
| 73 ++
include/media/media-device.h |3 +
include/media/media-entity.h | 19 +-
5 files changed, 364 insertions(+), 18 deletions(-)
create mode 100644 include/linux/media.h
snip
diff --git a/include/linux/media.h b/include/linux/media.h
new file mode 100644
index 000..746bdda
--- /dev/null
+++ b/include/linux/media.h
@@ -0,0 +1,73 @@
+#ifndef __LINUX_MEDIA_H
+#define __LINUX_MEDIA_H
+
+#define MEDIA_ENTITY_TYPE_NODE 1
+#define MEDIA_ENTITY_TYPE_SUBDEV 2
+
+#define MEDIA_ENTITY_SUBTYPE_NODE_V4L 1
+#define MEDIA_ENTITY_SUBTYPE_NODE_FB 2
+#define MEDIA_ENTITY_SUBTYPE_NODE_ALSA 3
+#define MEDIA_ENTITY_SUBTYPE_NODE_DVB 4
+
+#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER1
+#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER2
+#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC 3
+
+#define MEDIA_PAD_DIR_INPUT1
+#define MEDIA_PAD_DIR_OUTPUT 2
+
+#define MEDIA_LINK_FLAG_ACTIVE (1 0)
+#define MEDIA_LINK_FLAG_IMMUTABLE (1 1)
+
+#define MEDIA_ENTITY_ID_FLAG_NEXT (1 31)
+
+struct media_user_pad {
+ __u32 entity; /* entity ID */
+ __u8 index; /* pad index */
+ __u32 direction;/* pad direction */
+};
How about:
struct media_pad {
__u32 entity; /* entity ID */
__u16 index;/* pad index */
__u16 flags;/* pad flags (includes direction) */
Just to be sure, I suppose I should combine flags + direction in the
media_k_pad structure as well, right ?
Yes. I think we should just make a u32 flags, use bits 0 and 1 for the
direction and add a simple inline like this:
static inline u8 media_dir(struct media_pad *pad)
{
return pad-flags MEDIA_PAD_MASK_DIR);
}
And we should use the same for media_k_pad (and make a media_k_dir inline).
OK.
u32 reserved;
};
OK.
I think u16 for the number of pads might be safer than a u8.
it should definitely be enough, otherwise we'll have a big issue anyway.
Is u8 definitely enough or u16? I assume u16.
u16. u8 should be enough, u16 should definitely be enough :-)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
dmesg log - unknown USB video grabber
I recently bought a Video Grabber USB stick. The unit works with Windows XP and is supplied with a driver for it. I hoped that I could get it to work with Linux. It is made by AGK Nordic and is model 3015. Below is a copy of the relevant lines from dmesg after inserting it. Regards, Jim Comerford [ 2082.744121] usb 1-1: new high speed USB device using ehci_hcd and address 6 [ 2082.877991] usb 1-1: configuration #1 chosen from 1 choice [ 2082.878502] em28xx: New device @ 480 Mbps (eb1a:2861, interface 0, class 0) [ 2082.878711] em28xx #0: chip ID is em2860 [ 2082.968804] em28xx #0: board has no eeprom [ 2082.980570] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 2083.016565] em28xx #0: found i2c device @ 0xb8 [tvp5150a] [ 2083.029944] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 2083.029961] em28xx #0: You may try to use card=n insmod option to workaround that. [ 2083.029973] em28xx #0: Please send an email with this log to: [ 2083.029982] em28xx #0: V4L Mailing List linux-media@vger.kernel.org [ 2083.029992] em28xx #0: Board eeprom hash is 0x [ 2083.030002] em28xx #0: Board i2c devicelist hash is 0x77800080 [ 2083.030011] em28xx #0: Here is a list of valid choices for the card=n insmod option: [ 2083.030023] em28xx #0: card=0 - Unknown EM2800 video grabber [ 2083.030035] em28xx #0: card=1 - Unknown EM2750/28xx video grabber [ 2083.030046] em28xx #0: card=2 - Terratec Cinergy 250 USB [ 2083.030056] em28xx #0: card=3 - Pinnacle PCTV USB 2 [ 2083.030066] em28xx #0: card=4 - Hauppauge WinTV USB 2 [ 2083.030075] em28xx #0: card=5 - MSI VOX USB 2.0 [ 2083.030085] em28xx #0: card=6 - Terratec Cinergy 200 USB [ 2083.030095] em28xx #0: card=7 - Leadtek Winfast USB II [ 2083.030105] em28xx #0: card=8 - Kworld USB2800 [ 2083.030116] em28xx #0: card=9 - Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker / Kworld DVD Maker 2 [ 2083.030129] em28xx #0: card=10 - Hauppauge WinTV HVR 900 [ 2083.030140] em28xx #0: card=11 - Terratec Hybrid XS [ 2083.030150] em28xx #0: card=12 - Kworld PVR TV 2800 RF [ 2083.030160] em28xx #0: card=13 - Terratec Prodigy XS [ 2083.030170] em28xx #0: card=14 - SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 2083.030182] em28xx #0: card=15 - V-Gear PocketTV [ 2083.030192] em28xx #0: card=16 - Hauppauge WinTV HVR 950 [ 2083.030202] em28xx #0: card=17 - Pinnacle PCTV HD Pro Stick [ 2083.030212] em28xx #0: card=18 - Hauppauge WinTV HVR 900 (R2) [ 2083.030223] em28xx #0: card=19 - EM2860/SAA711X Reference Design [ 2083.030234] em28xx #0: card=20 - AMD ATI TV Wonder HD 600 [ 2083.030244] em28xx #0: card=21 - eMPIA Technology, Inc. GrabBeeX+ Video Encoder [ 2083.030256] em28xx #0: card=22 - EM2710/EM2750/EM2751 webcam grabber [ 2083.030266] em28xx #0: card=23 - Huaqi DLCW-130 [ 2083.030276] em28xx #0: card=24 - D-Link DUB-T210 TV Tuner [ 2083.030286] em28xx #0: card=25 - Gadmei UTV310 [ 2083.030296] em28xx #0: card=26 - Hercules Smart TV USB 2.0 [ 2083.030307] em28xx #0: card=27 - Pinnacle PCTV USB 2 (Philips FM1216ME) [ 2083.030318] em28xx #0: card=28 - Leadtek Winfast USB II Deluxe [ 2083.030328] em28xx #0: card=29 - NULL [ 2083.030338] em28xx #0: card=30 - Videology 20K14XUSB USB2.0 [ 2083.030348] em28xx #0: card=31 - Usbgear VD204v9 [ 2083.030358] em28xx #0: card=32 - Supercomp USB 2.0 TV [ 2083.030368] em28xx #0: card=33 - NULL [ 2083.030377] em28xx #0: card=34 - Terratec Cinergy A Hybrid XS [ 2083.030388] em28xx #0: card=35 - Typhoon DVD Maker [ 2083.030397] em28xx #0: card=36 - NetGMBH Cam [ 2083.030407] em28xx #0: card=37 - Gadmei UTV330 [ 2083.030417] em28xx #0: card=38 - Yakumo MovieMixer [ 2083.030426] em28xx #0: card=39 - KWorld PVRTV 300U [ 2083.030436] em28xx #0: card=40 - Plextor ConvertX PX-TV100U [ 2083.030447] em28xx #0: card=41 - Kworld 350 U DVB-T [ 2083.030456] em28xx #0: card=42 - Kworld 355 U DVB-T [ 2083.030466] em28xx #0: card=43 - Terratec Cinergy T XS [ 2083.030477] em28xx #0: card=44 - Terratec Cinergy T XS (MT2060) [ 2083.030487] em28xx #0: card=45 - Pinnacle PCTV DVB-T [ 2083.030497] em28xx #0: card=46 - Compro, VideoMate U3 [ 2083.030507] em28xx #0: card=47 - KWorld DVB-T 305U [ 2083.030517] em28xx #0: card=48 - KWorld DVB-T 310U [ 2083.030527] em28xx #0: card=49 - MSI DigiVox A/D [ 2083.030536] em28xx #0: card=50 - MSI DigiVox A/D II [ 2083.030546] em28xx #0: card=51 - Terratec Hybrid XS Secam [ 2083.030557] em28xx #0: card=52 - DNT DA2 Hybrid [ 2083.030566] em28xx #0: card=53 - Pinnacle Hybrid Pro [ 2083.030576] em28xx #0: card=54 - Kworld VS-DVB-T 323UR [ 2083.030586] em28xx #0: card=55 - Terratec Hybrid XS (em2882) [ 2083.030597] em28xx #0: card=56 - Pinnacle Hybrid Pro (2) [ 2083.030607] em28xx #0: card=57 - Kworld
Re: [PATCH] Fix possible memory leak in dvbca.c
2010/7/25 Tomer Barletz barl...@gmail.com: Allocated memory will never get free when read fails. See attached patch. Tomer Does anybody knows who's dvb-apps maintainer? -- 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 0/4] mx2_camera: mx25 fixes and enhancements
The first 3 pathces in this series are fixes for the mx2_camera driver which is going upstream via the imx git tree. The last patch implements forced active buffer termination on mx25. Baruch Siach (4): mx2_camera: fix a race causing NULL dereference mx2_camera: return IRQ_NONE when doing nothing mx2_camera: fix comment typo mx2_camera: implement forced termination of active buffer for mx25 drivers/media/video/mx2_camera.c | 34 ++ 1 files changed, 26 insertions(+), 8 deletions(-) -- 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] mx2_camera: fix a race causing NULL dereference
The mx25_camera_irq irq handler may get called after the camera has been deactivated (from mx2_camera_deactivate). Detect this situation, and bail out. Signed-off-by: Baruch Siach bar...@tkos.co.il --- drivers/media/video/mx2_camera.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c index 881d5d8..1536bd4 100644 --- a/drivers/media/video/mx2_camera.c +++ b/drivers/media/video/mx2_camera.c @@ -384,6 +384,9 @@ static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb, spin_lock_irqsave(pcdev-lock, flags); + if (*fb_active == NULL) + goto out; + vb = (*fb_active)-vb; dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__, vb, vb-baddr, vb-bsize); @@ -408,6 +411,7 @@ static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb, *fb_active = buf; +out: spin_unlock_irqrestore(pcdev-lock, flags); } -- 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 3/4] mx2_camera: fix comment typo
Signed-off-by: Baruch Siach bar...@tkos.co.il --- drivers/media/video/mx2_camera.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c index b42ad8d..d327d11 100644 --- a/drivers/media/video/mx2_camera.c +++ b/drivers/media/video/mx2_camera.c @@ -469,7 +469,7 @@ static void free_buffer(struct videobuf_queue *vq, struct mx2_buffer *buf) /* * This waits until this buffer is out of danger, i.e., until it is no -* longer in STATE_QUEUED or STATE_ACTIVE +* longer in state VIDEOBUF_QUEUED or VIDEOBUF_ACTIVE */ videobuf_waiton(vb, 0, 0); -- 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 2/4] mx2_camera: return IRQ_NONE when doing nothing
Signed-off-by: Baruch Siach bar...@tkos.co.il --- drivers/media/video/mx2_camera.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c index 1536bd4..b42ad8d 100644 --- a/drivers/media/video/mx2_camera.c +++ b/drivers/media/video/mx2_camera.c @@ -420,15 +420,17 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void *data) struct mx2_camera_dev *pcdev = data; u32 status = readl(pcdev-base_csi + CSISR); - if (status CSISR_DMA_TSF_FB1_INT) + writel(status, pcdev-base_csi + CSISR); + + if (!(status (CSISR_DMA_TSF_FB1_INT | CSISR_DMA_TSF_FB2_INT))) + return IRQ_NONE; + else if (status CSISR_DMA_TSF_FB1_INT) mx25_camera_frame_done(pcdev, 1, VIDEOBUF_DONE); else if (status CSISR_DMA_TSF_FB2_INT) mx25_camera_frame_done(pcdev, 2, VIDEOBUF_DONE); /* FIXME: handle CSISR_RFF_OR_INT */ - writel(status, pcdev-base_csi + CSISR); - return IRQ_HANDLED; } -- 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 4/4] mx2_camera: implement forced termination of active buffer for mx25
This allows userspace to terminate a capture without waiting for the current
frame to complete.
Signed-off-by: Baruch Siach bar...@tkos.co.il
---
drivers/media/video/mx2_camera.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index d327d11..396542b 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -648,15 +648,27 @@ static void mx2_videobuf_release(struct videobuf_queue
*vq,
* Terminate only queued but inactive buffers. Active buffers are
* released when they become inactive after videobuf_waiton().
*
-* FIXME: implement forced termination of active buffers, so that the
-* user won't get stuck in an uninterruptible state. This requires a
-* specific handling for each of the three DMA types that this driver
-* supports.
+* FIXME: implement forced termination of active buffers for mx27 and
+* mx27 eMMA, so that the user won't get stuck in an uninterruptible
+* state. This requires a specific handling for each of the these DMA
+* types.
*/
spin_lock_irqsave(pcdev-lock, flags);
if (vb-state == VIDEOBUF_QUEUED) {
list_del(vb-queue);
vb-state = VIDEOBUF_ERROR;
+ } else if (cpu_is_mx25() vb-state == VIDEOBUF_ACTIVE) {
+ if (pcdev-fb1_active == buf) {
+ pcdev-csicr1 = ~CSICR1_FB1_DMA_INTEN;
+ writel(0, pcdev-base_csi + CSIDMASA_FB1);
+ pcdev-fb1_active = NULL;
+ } else if (pcdev-fb2_active == buf) {
+ pcdev-csicr1 = ~CSICR1_FB2_DMA_INTEN;
+ writel(0, pcdev-base_csi + CSIDMASA_FB2);
+ pcdev-fb2_active = NULL;
+ }
+ writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
+ vb-state = VIDEOBUF_ERROR;
}
spin_unlock_irqrestore(pcdev-lock, flags);
--
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]videobuf_dma_sg: a new implementation for mmap
a mmap issue for videobuf-dma-sg: it will alloc a new page for mmaping
when it encounter page fault at video_vm_ops-fault().
a new implementation for mmap, it translate the vmalloc to page at
video_vm_ops-fault().
Signed-off-by: Figo.zhang figo1...@gmail.com
---
drivers/media/video/videobuf-dma-sg.c | 38
1 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/videobuf-dma-sg.c
b/drivers/media/video/videobuf-dma-sg.c
index 8359e6b..c9a8817 100644
--- a/drivers/media/video/videobuf-dma-sg.c
+++ b/drivers/media/video/videobuf-dma-sg.c
@@ -397,16 +397,44 @@ static void videobuf_vm_close(struct
vm_area_struct *vma)
*/
static int videobuf_vm_fault(struct vm_area_struct *vma, struct
vm_fault *vmf)
{
- struct page *page;
+ struct page *page = NULL;
+ struct videobuf_mapping *map = vma-vm_private_data;
+ struct videobuf_queue *q = map-q;
+ struct videobuf_dma_sg_memory *mem = NULL;
+
+ unsigned long offset;
+ unsigned long page_nr;
+ int first;
dprintk(3, fault: fault @ %08lx [vma %08lx-%08lx]\n,
(unsigned long)vmf-virtual_address,
vma-vm_start, vma-vm_end);
- page = alloc_page(GFP_USER | __GFP_DMA32);
- if (!page)
- return VM_FAULT_OOM;
- clear_user_highpage(page, (unsigned long)vmf-virtual_address);
+ mutex_lock(q-vb_lock);
+
+ offset = (unsigned long)vmf-virtual_address - vma-vm_start;
+ page_nr = offset PAGE_SHIFT;
+
+ for (first = 0; first VIDEO_MAX_FRAME; first++) {
+ if (NULL == q-bufs[first])
+ continue;
+
+ MAGIC_CHECK(mem-magic, MAGIC_SG_MEM);
+
+ if (q-bufs[first]-map == map)
+ break;
+ }
+
+ mem = q-bufs[first]-priv;
+ if (!mem)
+ return VM_FAULT_SIGBUS;
+ if (mem-dma.vmalloc)
+ page = vmalloc_to_page(mem-dma.vmalloc+
+ (offset (~PAGE_MASK)));
+ if (mem-dma.pages)
+ page = mem-dma.pages[page_nr];
+ mutex_unlock(q-vb_lock);
+
vmf-page = page;
return 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/2] drivers: usbvideo: remove custom implementation of hex_to_bin()
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
---
drivers/media/video/usbvideo/usbvideo.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/usbvideo/usbvideo.c
b/drivers/media/video/usbvideo/usbvideo.c
index 5ac37c6..f1fcf97 100644
--- a/drivers/media/video/usbvideo/usbvideo.c
+++ b/drivers/media/video/usbvideo/usbvideo.c
@@ -282,19 +282,15 @@ static void usbvideo_OverlayChar(struct uvd *uvd, struct
usbvideo_frame *frame,
};
unsigned short digit;
int ix, iy;
+ int value;
if ((uvd == NULL) || (frame == NULL))
return;
- if (ch = '0' ch = '9')
- ch -= '0';
- else if (ch = 'A' ch = 'F')
- ch = 10 + (ch - 'A');
- else if (ch = 'a' ch = 'f')
- ch = 10 + (ch - 'a');
- else
+ value = hex_to_bin(ch);
+ if (value 0)
return;
- digit = digits[ch];
+ digit = digits[value];
for (iy=0; iy 5; iy++) {
for (ix=0; ix 3; ix++) {
--
1.7.1.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 2/2] media: video: pvrusb2: remove custom hex_to_bin()
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
Cc: Mike Isely is...@pobox.com
---
drivers/media/video/pvrusb2/pvrusb2-debugifc.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
b/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
index e9b11e1..4279ebb 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
@@ -94,8 +94,6 @@ static int debugifc_parse_unsigned_number(const char
*buf,unsigned int count,
u32 *num_ptr)
{
u32 result = 0;
- u32 val;
- int ch;
int radix = 10;
if ((count = 2) (buf[0] == '0')
((buf[1] == 'x') || (buf[1] == 'X'))) {
@@ -107,17 +105,9 @@ static int debugifc_parse_unsigned_number(const char
*buf,unsigned int count,
}
while (count--) {
- ch = *buf++;
- if ((ch = '0') (ch = '9')) {
- val = ch - '0';
- } else if ((ch = 'a') (ch = 'f')) {
- val = ch - 'a' + 10;
- } else if ((ch = 'A') (ch = 'F')) {
- val = ch - 'A' + 10;
- } else {
+ int val = hex_to_bin(*buf++);
+ if (val 0 || val = radix)
return -EINVAL;
- }
- if (val = radix) return -EINVAL;
result *= radix;
result += val;
}
--
1.7.1.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: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added
Hello, On Tuesday, July 27, 2010 2:09 PM Russell King - ARM Linux wrote: On Mon, Jul 26, 2010 at 04:40:30PM +0200, Michal Nazarewicz wrote: +** Why is it needed? + +Various devices on embedded systems have no scatter-getter and/or +IO map support and as such require contiguous blocks of memory to +operate. They include devices such as cameras, hardware video +decoders and encoders, etc. Yes, this is becoming quite a big problem - and many ARM SoCs suffer from the existing memory allocators being extremely inadequate for their use. One of the areas I've been working on is sorting out the DMA coherent allocator so we don't violate the architecture requirements for ARMv6 and ARMv7 CPUs (which basically prohibits multiple mappings of memory with different attributes.) One of the ideas that I've thought about for this is to reserve an amount of contiguous memory at boot time to fill the entire DMA coherent mapping, marking the memory in the main kernel memory map as 'no access', and allocate directly from the DMA coherent region. However, discussing this with people who have the problem you're trying to solve indicates that they do not want to set aside an amount of memory as they perceive this to be a waste of resources. Assuming your board have only 128MB of physical memory (quite common case for some embedded boards), leaving 16MB unused just for DMA coherent area is a huge waste imho. This concern also applies to 'cma'. Yes, we know. We plan to recover some of that 'wasted' memory by providing a way to allocate some kind of virtual swap device on it. This is just an idea, no related works has been started yet. +/* + * Don't call it directly, use cma_alloc(), cma_alloc_from() or + * cma_alloc_from_region(). + */ +dma_addr_t __must_check +__cma_alloc(const struct device *dev, const char *kind, + size_t size, dma_addr_t alignment); Does this really always return DMA-able memory (memory which can be DMA'd to/from without DMA-mapping etc?) As it returns a dma_addr_t, it's returning a cookie for the memory which will be suitable for writing directly to the device 'dev' doing the DMA. (NB: DMA addresses may not be the same as physical addresses, especially if the device is on a downstream bus. We have ARM platforms which have different bus offsets.) How does one obtain the CPU address of this memory in order for the CPU to access it? Right, we did not cover such case. In CMA approach we tried to separate memory allocation from the memory mapping into user/kernel space. Mapping a buffer is much more complicated process that cannot be handled in a generic way, so we decided to leave this for the device drivers. Usually video processing devices also don't need in-kernel mapping for such buffers at all. Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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: [Q]: any DVB-S2 card which is 45MS/s capable?
VDR User a écrit : Look at the vp-1041 I think. From what I gathered it is not able to do 45MS/s for DVB-S2. Thanks anyway, Manu -- 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] Fix possible memory leak in dvbca.c
2010/7/25 Tomer Barletz barl...@gmail.com:
Allocated memory will never get free when read fails.
See attached patch.
Tomer
Attached a better patch... :)
diff -r d3509d6e9499 lib/libdvbapi/dvbca.c
--- a/lib/libdvbapi/dvbca.c Sat Aug 08 19:17:21 2009 +0200
+++ b/lib/libdvbapi/dvbca.c Tue Jul 27 15:56:48 2010 +0300
@@ -89,8 +89,10 @@
uint8_t *data, uint16_t data_length)
{
uint8_t *buf = malloc(data_length + 2);
- if (buf == NULL)
+ if (buf == NULL) {
+ free(buf);
return -1;
+ }
buf[0] = slot;
buf[1] = connection_id;
@@ -110,8 +112,10 @@
if (buf == NULL)
return -1;
- if ((size = read(fd, buf, data_length+2)) 2)
+ if ((size = read(fd, buf, data_length+2)) 2) {
+ free(buf);
return -1;
+ }
*slot = buf[0];
*connection_id = buf[1];
Re: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added
On Tue, 27 Jul 2010 14:45:58 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: How does one obtain the CPU address of this memory in order for the CPU to access it? Right, we did not cover such case. In CMA approach we tried to separate memory allocation from the memory mapping into user/kernel space. Mapping a buffer is much more complicated process that cannot be handled in a generic way, so we decided to leave this for the device drivers. Usually video processing devices also don't need in-kernel mapping for such buffers at all. Still...that *is* why I suggested an interface which would return both the DMA address and a kernel-space virtual address, just like the DMA API does... Either that, or just return the void * kernel address and let drivers do the DMA mapping themselves. Returning only the dma_addr_t address will make the interface difficult to use in many situations. jon -- 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/2] media: video: pvrusb2: remove custom hex_to_bin()
Andy:
Acked-By: Mike Isely is...@pobox.com
-Mike
On Tue, 27 Jul 2010, Andy Shevchenko wrote:
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
Cc: Mike Isely is...@pobox.com
---
drivers/media/video/pvrusb2/pvrusb2-debugifc.c | 14 ++
1 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
b/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
index e9b11e1..4279ebb 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-debugifc.c
@@ -94,8 +94,6 @@ static int debugifc_parse_unsigned_number(const char
*buf,unsigned int count,
u32 *num_ptr)
{
u32 result = 0;
- u32 val;
- int ch;
int radix = 10;
if ((count = 2) (buf[0] == '0')
((buf[1] == 'x') || (buf[1] == 'X'))) {
@@ -107,17 +105,9 @@ static int debugifc_parse_unsigned_number(const char
*buf,unsigned int count,
}
while (count--) {
- ch = *buf++;
- if ((ch = '0') (ch = '9')) {
- val = ch - '0';
- } else if ((ch = 'a') (ch = 'f')) {
- val = ch - 'a' + 10;
- } else if ((ch = 'A') (ch = 'F')) {
- val = ch - 'A' + 10;
- } else {
+ int val = hex_to_bin(*buf++);
+ if (val 0 || val = radix)
return -EINVAL;
- }
- if (val = radix) return -EINVAL;
result *= radix;
result += val;
}
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added
Hello, On Tuesday, July 27, 2010 2:59 PM Jonathan Corbet wrote: On Tue, 27 Jul 2010 14:45:58 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: How does one obtain the CPU address of this memory in order for the CPU to access it? Right, we did not cover such case. In CMA approach we tried to separate memory allocation from the memory mapping into user/kernel space. Mapping a buffer is much more complicated process that cannot be handled in a generic way, so we decided to leave this for the device drivers. Usually video processing devices also don't need in-kernel mapping for such buffers at all. Still...that *is* why I suggested an interface which would return both the DMA address and a kernel-space virtual address, just like the DMA API does... Either that, or just return the void * kernel address and let drivers do the DMA mapping themselves. Returning only the dma_addr_t address will make the interface difficult to use in many situations. As I said, drivers usually don't need in-kernel mapping for video buffers. Is there really a need for creating such mapping? Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added
On Tue, 27 Jul 2010 06:58:42 -0600 Jonathan Corbet cor...@lwn.net wrote: On Tue, 27 Jul 2010 14:45:58 +0200 Marek Szyprowski m.szyprow...@samsung.com wrote: How does one obtain the CPU address of this memory in order for the CPU to access it? Right, we did not cover such case. In CMA approach we tried to separate memory allocation from the memory mapping into user/kernel space. Mapping a buffer is much more complicated process that cannot be handled in a generic way, so we decided to leave this for the device drivers. Usually video processing devices also don't need in-kernel mapping for such buffers at all. Still...that *is* why I suggested an interface which would return both the DMA address and a kernel-space virtual address, just like the DMA API does... Either that, or just return the void * kernel address and The DMA API for coherent memory (dma_alloc_coherent) returns both an DMA address and a kernel-space virtual address because it does both allocation and mapping. However, other DMA API (dma_map_*) returns only an DMA address because it does only mapping. I think that if we need new API for coherent memory, we could unify it with the DMA API for coherent memory. IMO, it's cleaner to having two separate APIs for allocation and mapping (except for coherent memory). The drivers have been working in that way. -- 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: [Q]: any DVB-S2 card which is 45MS/s capable?
On Tue, Jul 27, 2010 at 5:52 AM, Emmanuel eall...@gmail.com wrote: VDR User a écrit : Look at the vp-1041 I think. From what I gathered it is not able to do 45MS/s for DVB-S2. Thanks anyway, You may want to ask Manu Abraham (author of the mantis driver) about that to be sure. It seems I recall him telling me it could quite some time ago. -- 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
[GIT PATCHES FOR 2.6.36] Samsung fimc driver
The following changes since commit c57fd88318988f17731e446fe1d8498f506fdd44: V4L/DVB: uvcvideo: Add support for Manta MM-353 Plako (2010-07-05 19:47:16 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung v4l/s5p-fimc Sylwester Nawrocki (2): ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface v4l: Add driver for Samsung S5P SoC video postprocessor arch/arm/plat-samsung/include/plat/regs-fimc.h | 294 + drivers/media/video/Kconfig| 10 + drivers/media/video/Makefile |1 + drivers/media/video/s5p-fimc/Makefile |3 + drivers/media/video/s5p-fimc/fimc-core.c | 1568 drivers/media/video/s5p-fimc/fimc-core.h | 489 drivers/media/video/s5p-fimc/fimc-reg.c| 571 + include/linux/videodev2.h |1 + 8 files changed, 2937 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-samsung/include/plat/regs-fimc.h create mode 100644 drivers/media/video/s5p-fimc/Makefile create mode 100644 drivers/media/video/s5p-fimc/fimc-core.c create mode 100644 drivers/media/video/s5p-fimc/fimc-core.h create mode 100644 drivers/media/video/s5p-fimc/fimc-reg.c Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD Center -- 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 0/15] STAGING: add lirc device drivers
On Tue, Jul 27, 2010 at 12:59:00PM -0300, Mauro Carvalho Chehab wrote: Em 26-07-2010 20:25, Jarod Wilson escreveu: This patch series adds the remaining lirc_foo device drivers to the staging tree. drivers/staging/lirc/TODO |8 + ^^^ Hi Jarod, Please add a TODO file at staging/lirc, describing what's needed for the drivers to move to the IR branch. See above. :) It could use some further fleshing out though, particularly, some known issues that must be fixed in this specific driver type things. Greg, It is probably simpler to merge those files via my tree, as they depend on some changes scheduled for 2.6.36. The patches were created against yesterday's linux-next tree, so I'd assumed they could go in via staging for 2.6.36, but... Would it be ok for you if I merge them from my tree? ...it certainly doesn't matter to me if they go in this way instead. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dvb: siano: free spinlock before schedule()
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 sego...@gmail.com
---
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);
--
1.7.0.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 0/15] STAGING: add lirc device drivers
Em 27-07-2010 15:17, Jarod Wilson escreveu: On Tue, Jul 27, 2010 at 12:59:00PM -0300, Mauro Carvalho Chehab wrote: Em 26-07-2010 20:25, Jarod Wilson escreveu: This patch series adds the remaining lirc_foo device drivers to the staging tree. drivers/staging/lirc/TODO |8 + ^^^ Hi Jarod, Please add a TODO file at staging/lirc, describing what's needed for the drivers to move to the IR branch. See above. :) Ops! It could use some further fleshing out though, particularly, some known issues that must be fixed in this specific driver type things. Yes, but that's ok for now ;) Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Unknown CX23885 device
(please CC, I'm not subscribed yet) Hey Linux-DVB people I'm trying to make an as-of-yet unsupported CX23885 device work in Linux. I've tested that the device is not supported using the newest snapshot of the DVB drivers. They did support a bunch of extra devices compared to the standard ubuntu driver, but to no avail. This is what I know about the device: ### physical description ### The device is a small mini-PCIe device currently installed in my Thinkpad T61p notebook. It did not originate there, but I managed to fit it in. It has an Avermedia logo on top, but no other discernable markings. I've tried removing the chip cover, but I can't see any other major chips than the cx23885. I can take a second look, if I know what to look for. ### pci info ### $ sudo lspci -s 02:00.0 -vv 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Subsystem: Avermedia Technologies Inc Device c139 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at d7a0 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 2us, L1 4us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Vital Product Data ? Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: Data: Capabilities: [100] Advanced Error Reporting ? Capabilities: [200] Virtual Channel ? Kernel driver in use: cx23885 Kernel modules: cx23885 I've tried several different card=X settings for modprobe cx23885, and a few of them result in creation of /dev/dvb devices, but none of them really seem towork. What can I try for a next step? -- Med venlig hilsen Christian Iversen ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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 0/15] STAGING: add lirc device drivers
Em 27-07-2010 15:24, Jarod Wilson escreveu: On Tue, Jul 27, 2010 at 09:09:56AM -0700, Greg KH wrote: On Tue, Jul 27, 2010 at 12:59:00PM -0300, Mauro Carvalho Chehab wrote: Em 26-07-2010 20:25, Jarod Wilson escreveu: Hm, Jarod, you forgot to cc: the staging maintainer, so I missed these :) D'oh, sorry, yeah, realized that about 10 minutes after I sent everything. Figured I'd ping you if you hadn't said anything about 'em in a day or three. Greg, It is probably simpler to merge those files via my tree, as they depend on some changes scheduled for 2.6.36. Would it be ok for you if I merge them from my tree? No objection from me for them to go through your tree. Ok, thanks. I'll merge the patches on my tree. Do you want me to handle the cleanup and other fixes after they go into the tree, or do you want to also handle them as well (either is fine with me.) Note that I've got a git tree I've been maintaining the lirc drivers in for a while, so whomever is ultimately the gateway, I can also stage cleanups there -- I'll certainly be pushing any cleanups I do on the lirc drivers there prior to sending along for upstream, or else I'm liable to lose track of them... :) http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git Well, maybe the easiest way would be if I handle the first merge, to be sure that they'll reach linux-next and 2.6.36 at the right time, avoiding conflicts with some core changes. After the merge, Jerod can handle it via his own tree. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Tue Jul 27 19:00:24 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unknown CX23885 device
On Tue, Jul 27, 2010 at 3:21 PM, Christian Iversen chriv...@iversen-net.dk wrote: (please CC, I'm not subscribed yet) Hey Linux-DVB people I'm trying to make an as-of-yet unsupported CX23885 device work in Linux. I've tested that the device is not supported using the newest snapshot of the DVB drivers. They did support a bunch of extra devices compared to the standard ubuntu driver, but to no avail. This is what I know about the device: ### physical description ### The device is a small mini-PCIe device currently installed in my Thinkpad T61p notebook. It did not originate there, but I managed to fit it in. How are you attaching the video/audio/antenna/etc. input to the pcie card? I don't imagine the card is much use without external connectors. Alex It has an Avermedia logo on top, but no other discernable markings. I've tried removing the chip cover, but I can't see any other major chips than the cx23885. I can take a second look, if I know what to look for. ### pci info ### $ sudo lspci -s 02:00.0 -vv 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Subsystem: Avermedia Technologies Inc Device c139 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at d7a0 (64-bit, non-prefetchable) [size=2M] Capabilities: [40] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 2us, L1 4us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Vital Product Data ? Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Address: Data: Capabilities: [100] Advanced Error Reporting ? Capabilities: [200] Virtual Channel ? Kernel driver in use: cx23885 Kernel modules: cx23885 I've tried several different card=X settings for modprobe cx23885, and a few of them result in creation of /dev/dvb devices, but none of them really seem towork. What can I try for a next step? -- Med venlig hilsen Christian Iversen ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/15] STAGING: add lirc device drivers
On Tue, Jul 27, 2010 at 04:33:32PM -0300, Mauro Carvalho Chehab wrote: Em 27-07-2010 15:24, Jarod Wilson escreveu: On Tue, Jul 27, 2010 at 09:09:56AM -0700, Greg KH wrote: On Tue, Jul 27, 2010 at 12:59:00PM -0300, Mauro Carvalho Chehab wrote: Em 26-07-2010 20:25, Jarod Wilson escreveu: Hm, Jarod, you forgot to cc: the staging maintainer, so I missed these :) D'oh, sorry, yeah, realized that about 10 minutes after I sent everything. Figured I'd ping you if you hadn't said anything about 'em in a day or three. Greg, It is probably simpler to merge those files via my tree, as they depend on some changes scheduled for 2.6.36. Would it be ok for you if I merge them from my tree? No objection from me for them to go through your tree. Ok, thanks. I'll merge the patches on my tree. Do you want me to handle the cleanup and other fixes after they go into the tree, or do you want to also handle them as well (either is fine with me.) Note that I've got a git tree I've been maintaining the lirc drivers in for a while, so whomever is ultimately the gateway, I can also stage cleanups there -- I'll certainly be pushing any cleanups I do on the lirc drivers there prior to sending along for upstream, or else I'm liable to lose track of them... :) http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git Well, maybe the easiest way would be if I handle the first merge, to be sure that they'll reach linux-next and 2.6.36 at the right time, avoiding conflicts with some core changes. After the merge, Jerod can handle it via his own tree. Well, Jerod needs to send me the patches for inclusion in linux-next and Linus's tree from his tree as I will need to coordinate them after the initial merge from Mauro happens. thanks, greg k-h -- 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: Unknown CX23885 device
On 7/27/10 3:21 PM, Christian Iversen wrote: (please CC, I'm not subscribed yet) Hey Linux-DVB people I'm trying to make an as-of-yet unsupported CX23885 device work in Linux. http://kernellabs.com/hg/~stoth/cx23885-mpx/ Try this and if necessary module option card=29. Any good? - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~mkrufky/raw-payload
Hi Mike, Em 19-06-2010 15:09, Michael Krufky escreveu: Mauro, This adds the ability for drivers to send the received raw payload to the dvr device, in cases of newer delivery systems that do not deliver transport stream and do not require usage of the kernel demux. In these cases, the data can be fully decoded by a userspace application / library. For a driver to deliver the raw payload, simply use the function dvb_dmx_swfilter_raw instead of dvb_dmx_swfilter or dvb_dmx_swfilter_204, as shown in the dvb-usb patch. As discussed on IRC, please provide us a patch also to the DVB DocBook, and add a logic to allow enum/get/set the raw/TS formats provided by hardware. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unknown CX23885 device
On 2010-07-27 22:09, Steven Toth wrote: On 7/27/10 3:21 PM, Christian Iversen wrote: (please CC, I'm not subscribed yet) Hey Linux-DVB people I'm trying to make an as-of-yet unsupported CX23885 device work in Linux. http://kernellabs.com/hg/~stoth/cx23885-mpx/ Try this and if necessary module option card=29. Without card=29, nothing was found. This is with card=29, but still no /dev/dvb nodes. [ 6287.278003] 2010-07-27 22:38:24 [ 6288.248799] Linux video capture interface: v2.00 [ 6288.268106] cx23885 driver version 0.0.2 loaded [ 6288.268273] cx23885 :02:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 6288.268276] cx23885[0]: cx23885_dev_setup() Memory configured for PCIe bridge type 885 [ 6288.268396] CORE cx23885[0]: subsystem: 1461:c139, board: MPX-885 [card=29,insmod option] [ 6288.268398] cx23885[0]: cx23885_pci_quirks() [ 6288.268402] cx23885[0]: cx23885_dev_setup() tuner_type = 0x0 tuner_addr = 0x0 [ 6288.268404] cx23885[0]: cx23885_dev_setup() radio_type = 0x0 radio_addr = 0x0 [ 6288.268405] cx23885[0]: cx23885_reset() [ 6288.368410] cx23885[0]: cx23885_sram_channel_setup() Configuring channel [VID A] [ 6288.368421] cx23885[0]: cx23885_sram_channel_setup() Erasing channel [ch2] [ 6288.368423] cx23885[0]: cx23885_sram_channel_setup() Configuring channel [TS1 B] [ 6288.368436] cx23885[0]: cx23885_sram_channel_setup() Erasing channel [ch4] [ 6288.368437] cx23885[0]: cx23885_sram_channel_setup() Erasing channel [ch5] [ 6288.368439] cx23885[0]: cx23885_sram_channel_setup() Configuring channel [TS2 C] [ 6288.368452] cx23885[0]: cx23885_sram_channel_setup() Configuring channel [TV Audio] [ 6288.368467] cx23885[0]: cx23885_sram_channel_setup() Erasing channel [ch8] [ 6288.368469] cx23885[0]: cx23885_sram_channel_setup() Erasing channel [ch9] [ 6288.399900] cx25840 2-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [ 6288.404410] cx25840 2-0044: firmware: requesting v4l-cx23885-avcore-01.fw [ 6289.042011] cx25840 2-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 6289.054227] cx23885[0]: registered device video0 [v4l2] [ 6289.054244] cx23885[0]: registered device vbi0 [ 6289.054320] cx23885[0]: registered ALSA audio device [ 6289.068837] cx23885_dev_checkrevision() Hardware revision = 0xb0 [ 6289.068845] cx23885[0]/0: found at :02:00.0, rev: 2, irq: 16, latency: 0, mmio: 0xd7a0 [ 6289.068855] cx23885 :02:00.0: setting latency timer to 64 [ 6289.068859] IRQ 16/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs What's the preferred method of pulling the source, btw? I just downloaded a .tar.gz. It works, but updating is not pleasant :) -- Med venlig hilsen Christian Iversen -- 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 sego...@gmail.com
---
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 0/15] STAGING: add lirc device drivers
On Tue, Jul 27, 2010 at 12:51:50PM -0700, Greg KH wrote: On Tue, Jul 27, 2010 at 04:33:32PM -0300, Mauro Carvalho Chehab wrote: Em 27-07-2010 15:24, Jarod Wilson escreveu: On Tue, Jul 27, 2010 at 09:09:56AM -0700, Greg KH wrote: On Tue, Jul 27, 2010 at 12:59:00PM -0300, Mauro Carvalho Chehab wrote: Em 26-07-2010 20:25, Jarod Wilson escreveu: Hm, Jarod, you forgot to cc: the staging maintainer, so I missed these :) D'oh, sorry, yeah, realized that about 10 minutes after I sent everything. Figured I'd ping you if you hadn't said anything about 'em in a day or three. Greg, It is probably simpler to merge those files via my tree, as they depend on some changes scheduled for 2.6.36. Would it be ok for you if I merge them from my tree? No objection from me for them to go through your tree. Ok, thanks. I'll merge the patches on my tree. Do you want me to handle the cleanup and other fixes after they go into the tree, or do you want to also handle them as well (either is fine with me.) Note that I've got a git tree I've been maintaining the lirc drivers in for a while, so whomever is ultimately the gateway, I can also stage cleanups there -- I'll certainly be pushing any cleanups I do on the lirc drivers there prior to sending along for upstream, or else I'm liable to lose track of them... :) http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-lirc.git Well, maybe the easiest way would be if I handle the first merge, to be sure that they'll reach linux-next and 2.6.36 at the right time, avoiding conflicts with some core changes. After the merge, Jerod can handle it via his own tree. Well, Jerod needs to send me the patches for inclusion in linux-next and Linus's tree from his tree as I will need to coordinate them after the initial merge from Mauro happens. Not a problem, I can do that. With luck, most of them will be remove this driver from drivers/staging/lirc/ and add its replacement ir-core driver over in drivers/media/IR/, where Greg doesn't have to worry about it (as much) any longer. :) -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IR/imon: remove bad ir_input_dev use
The ir_input_dev gets filled in by __ir_input_register, the one
allocated in imon_init_idev was being overwritten by the correct one
shortly after it was initialized (ultimately resulting in a memory
leak). Additionally, there was an ill-advised memcpy into that
extraneous ir_input_dev which gets fixed by this.
Ill-advised memcpy pointed out by Dmitry Torokhov, bad usage of
ir_input_dev pointed out by Maxim Levitsky (in mceusb.c, which copied the
bug from here).
CC: Dmitry Torokhov dmitry.torok...@gmail.com
CC: Maxim Levitsky maximlevit...@gmail.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/imon.c | 15 ---
1 files changed, 0 insertions(+), 15 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index 08dff8c..433dca6 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -87,7 +87,6 @@ static ssize_t lcd_write(struct file *file, const char *buf,
struct imon_context {
struct device *dev;
struct ir_dev_props *props;
- struct ir_input_dev *ir;
/* Newer devices have two interfaces */
struct usb_device *usbdev_intf0;
struct usb_device *usbdev_intf1;
@@ -1656,7 +1655,6 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
{
struct input_dev *idev;
struct ir_dev_props *props;
- struct ir_input_dev *ir;
int ret, i;
idev = input_allocate_device();
@@ -1671,12 +1669,6 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
goto props_alloc_failed;
}
- ir = kzalloc(sizeof(struct ir_input_dev), GFP_KERNEL);
- if (!ir) {
- dev_err(ictx-dev, remote ir input dev allocation failed\n);
- goto ir_dev_alloc_failed;
- }
-
snprintf(ictx-name_idev, sizeof(ictx-name_idev),
iMON Remote (%04x:%04x), ictx-vendor, ictx-product);
idev-name = ictx-name_idev;
@@ -1706,14 +1698,9 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
props-change_protocol = imon_ir_change_protocol;
ictx-props = props;
- ictx-ir = ir;
- memcpy(ir-dev, ictx-dev, sizeof(struct device));
-
usb_to_input_id(ictx-usbdev_intf0, idev-id);
idev-dev.parent = ictx-dev;
- input_set_drvdata(idev, ir);
-
ret = ir_input_register(idev, RC_MAP_IMON_PAD, props, MOD_NAME);
if (ret 0) {
dev_err(ictx-dev, remote input dev register failed\n);
@@ -1723,8 +1710,6 @@ static struct input_dev *imon_init_idev(struct
imon_context *ictx)
return idev;
idev_register_failed:
- kfree(ir);
-ir_dev_alloc_failed:
kfree(props);
props_alloc_failed:
input_free_device(idev);
--
1.7.1.1
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IR/mceusb: remove bad ir_input_dev use
The ir_input_dev gets filled in by __ir_input_register, the one
allocated in mceusb_init_input_dev was being overwritten by the correct
one shortly after it was initialized (ultimately resulting in a memory
leak). This bug was inherited from imon.c, and was pointed out to me by
Maxim Levitsky.
CC: Maxim Levitsky maximlevit...@gmail.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/mceusb.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 78bf7f7..9a7da32 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -228,7 +228,6 @@ static struct usb_device_id std_tx_mask_list[] = {
/* data structure for each usb transceiver */
struct mceusb_dev {
/* ir-core bits */
- struct ir_input_dev *irdev;
struct ir_dev_props *props;
struct ir_raw_event rawir;
@@ -739,7 +738,7 @@ static void mceusb_dev_recv(struct urb *urb, struct pt_regs
*regs)
if (ir-send_flags == RECV_FLAG_IN_PROGRESS) {
ir-send_flags = SEND_FLAG_COMPLETE;
- dev_dbg(ir-irdev-dev, setup answer received %d bytes\n,
+ dev_dbg(ir-dev, setup answer received %d bytes\n,
buf_len);
}
@@ -861,7 +860,6 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
{
struct input_dev *idev;
struct ir_dev_props *props;
- struct ir_input_dev *irdev;
struct device *dev = ir-dev;
int ret = -ENODEV;
@@ -878,12 +876,6 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
goto props_alloc_failed;
}
- irdev = kzalloc(sizeof(struct ir_input_dev), GFP_KERNEL);
- if (!irdev) {
- dev_err(dev, remote ir input dev allocation failed\n);
- goto ir_dev_alloc_failed;
- }
-
snprintf(ir-name, sizeof(ir-name), Media Center Ed. eHome
Infrared Remote Transceiver (%04x:%04x),
le16_to_cpu(ir-usbdev-descriptor.idVendor),
@@ -902,9 +894,6 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
props-tx_ir = mceusb_tx_ir;
ir-props = props;
- ir-irdev = irdev;
-
- input_set_drvdata(idev, irdev);
ret = ir_input_register(idev, RC_MAP_RC6_MCE, props, DRIVER_NAME);
if (ret 0) {
@@ -915,8 +904,6 @@ static struct input_dev *mceusb_init_input_dev(struct
mceusb_dev *ir)
return idev;
irdev_failed:
- kfree(irdev);
-ir_dev_alloc_failed:
kfree(props);
props_alloc_failed:
input_free_device(idev);
--
1.7.1.1
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can I expect in-kernel decoding to work out of box?
On Tue, Jul 27, 2010 at 9:29 PM, Jon Smirl jonsm...@gmail.com wrote: On Tue, Jul 27, 2010 at 7:32 PM, Maxim Levitsky maximlevit...@gmail.com wrote: On Wed, 2010-07-28 at 01:33 +0300, Maxim Levitsky wrote: Hi, I ported my ene driver to in-kernel decoding. It isn't yet ready to be released, but in few days it will be. Now, knowing about wonders of in-kernel decoding, I try to use it, but it just doesn't work. Mind you that lircd works with this remote. (I attach my lircd.conf) Here is the output of mode2 for a single keypress: 8850 4350 525 1575 525 1575 525 450 525 450 525 450 525 450 525 1575 525 450 525 1575 525 450 525 1575 525 450 525 450 525 1575 525 450 525 450 525 23625 That decodes as: 1100 0010 1010 0100 In the NEC protocol the second word is supposed to be the inverse of the first word and it isn't. The timing is too short for NEC protocol too. Valid NEC... 1100 0011 1010 0101 Maybe JVC protocol but it is longer than normal. The JVC decoder was unable to get started decoding it. I don't think the JVC decoder has been tested much. Take a look at it and see why it couldn't get out of state 0. Personally, I haven't really tried much of anything but RC-6(A) and RC-5 while working on mceusb, so they're the only ones I can really vouch for myself at the moment. It seems that I don't have many remotes that aren't an RC-x variant, outside of universals, which I have yet to get around to programming for various other modes to test any of the protocol decoders. I assume that David Hardeman already did that much before submitting each of the ir protocol decoders with his name one them (which were, if I'm not mistaken, based at least partially on Jon's earlier work), but its entirely possible there are slight variants of each that aren't handled properly just yet. That right there is one of the major reasons I saw for writing the lirc bridge driver plugin in the first place -- the lirc userspace decoder has been around for a LOT longer, and thus is likely to know how to handle more widely varying IR signals. -- Jarod Wilson ja...@wilsonet.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Analog support for X8558
Hi, I would like to try to add support to the mygica X8558. Digital TV is already supported for this hardware in the linux kernel but analog support isn't. I haven't done kernel development before but the chipset it contains, cx23885, seems to be widely supported. The spec sheets for the tuner used, maxim 2165E, seems to be available on website. I'm having trouble deciding whether it is possible to enable analog support on this card. It seems that there are two tuners for digital tv, but only one cx23885. Will it be possible to support two analog tuners along with the tuners with only one cx23885? Is there a source code I can use? What information should I try to obtain to help answer this question so I can start coding for it? Regards, Sunil This message was sent using IMP, the Internet Messaging Program. -- 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
