Re: [RFC 2/6] omap: iovmm: generic iommu api migration
On Wed, Jun 8, 2011 at 1:46 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 07 June 2011 15:46:26 Ohad Ben-Cohen wrote: Where do you take care of those potential offsets today ? Or do you simply ignore the offsets and map the entire page ? Here http://marc.info/?l=linux-omapm=130693502326513w=2 :-) :) Ok so it seems iovmm will take care of that for now ? Let's get the basics working with the IOMMU API and then revise this when we switch from iovmm to the generic dma. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC] Media kernelspace-userspace API specs (V4L/DVB/IR) - Was: Re: [PATCH 00/13] Reduce the gap between DVBv5 API and the specs
On Thursday, June 09, 2011 03:20:43 Mauro Carvalho Chehab wrote: 2) CURRENT STATUS == After the last day patches, the end result of is that: - API gaps on both V4L and DVB parts are now shown; - The V4L gaps were already fixed; - include/linux/osd.h: the API is not documented. I decided to keep it outside the documentation, as it is being used only by a legacy driver, and the API violates several Linux CodingStyle rules. I suspect that we can just deprecate this API, instead of propagating its usage. Agreed. - 100% of the DVB data structures are now documented; Great! - there are 22 DVB ioctl's not documented at the API (excluding the osd ones), from the total amount of 111 ioctl's. So, about 20% of the ioctl's are not documented yet. - the API specs contain several IOCTL's and data structures that are used only by one or two old drivers, without any recent driver needing to use them; - there are some overlap area between DVB Video/Audio API's and V4L API; - there are some overlap area between DVB Audio API and ALSA API; - there are still some gaps at the Remote Controller API. Basically, the sysfs nodes are not documented yet; - currently, there's no Makefile magic to double check discrepancies at the Remote Controller and at the Media Controller API's. 3) PROPOSALS = A badly documented API is something very bad, as: - userspace developers need to figure out how the driver and core works in order to write their code. Worse than that, if a driver has a bug and is doing something wrong, the userspace developer may assume that the broken behavior is the correct one. So, a latter fix at the driver will break the userspace application; - kernelspace developers may have different opinions about how to implement some feature, leading into different, incompatible implementations. So, we need to be sure that the API is properly documenting what's the expected behavior, otherwise the specs are useless. I got some interesting statistics at the annex part of this RFC. Based on that, I propose to: a) Put a notice at the specs that the AUDIO, VIDEO and OSD ioctl's are deprecated and shouldn't be used on newer drivers. We don't need to remove them from the drivers, but, at least on ivtv, we should expand the V4L/ALSA support if needed, in order to implement what's missed there. Agreed. d) The API usage inside drivers/media and drivers/staging is given by: I'll comment on those ioctls used by ivtv: AUDIO_SET_MUTE drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c Used to mute the audio when playing back an mpeg stream. We can use the AUDIO_MUTE control for this. This will require some work in ivtv since at the moment all video nodes share the same controls. In this case the video output node should get its own MUTE control. AUDIO_CHANNEL_SELECT drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c How to playback normal MPEG audio: left, right, stereo, swapped. AUDIO_BILINGUAL_CHANNEL_SELECT drivers/media/video/ivtv/ivtv-ioctl.c How to playback bilingual MPEG audio: left, right, stereo, swapped. The decoder will automatically detect whether the source is bilingual or not and select either CHANNEL_SELECT or BILINGUAL_CHANNEL_SELECT as needed for the audio output. I'm not sure what to do with these. There are multiple options: - Reimplement them as menu controls. - Add them to VIDIOC_DECODER_CMD, either as a separate command or as part of the PLAY command. I'm not enthusiastic about this since these properties can be changed while decoding is in progress. It does not really fit my idea of a 'decoder command'. - Add support for this to VIDIOC_G/S_AUDOUT. Any decoder with audio output should have this ioctl. There is a currently unused 'mode' field in struct v4l2_audioout that might be used for this purpose. I think either controls or using AUDOUT is the way to go. I am leaning towards controls since they will automatically appear in properly written applications and this is really a user-driven setting. And with menu controls it is easy to extend the number of options. VIDEO_STOP drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c VIDEO_PLAY drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c VIDEO_FREEZE drivers/media/dvb/ttpci/av7110.c drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c VIDEO_CONTINUE drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c Stop/Play/Pause/Continue MPEG decoding. There should all be deprecated and replaced with VIDIOC_DECODER_CMD. VIDEO_SELECT_SOURCE drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c Select passthrough mode where the input is directly linked to the output
Re: [PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Guennadi, Jon: thanks! we hope to work out a common ccic core, and then re base the code. : On Wed, Jun 8, 2011 at 7:30 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Kassey Thanks for the new version, but, IIUC, you agreed to reimplement your driver on top of a common ccic core, which means, a lot of code will change. So, it doesn't really make much sense now to make and review new stand-alone versions of your driver, right? So, shall we wait until Jon's CCIC code stabilises a bit and you rebase your driver on top of it? Of course, you can also work together with Jon on the drivers to get them faster in shape and in a way, suitable fou you both. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC] Media kernelspace-userspace API specs (V4L/DVB/IR) - Was: Re: [PATCH 00/13] Reduce the gap between DVBv5 API and the specs
AUDIO_SET_EXT_ID AUDIO_SET_ATTRIBUTES AUDIO_SET_KARAOKE VIDEO_SET_SYSTEM VIDEO_SET_HIGHLIGHT VIDEO_SET_SPU VIDEO_SET_SPU_PALETTE VIDEO_GET_NAVI VIDEO_SET_ATTRIBUTES VIDEO_SET_ID VIDEO_GET_FRAME_RATE These are only seen in audio.h/video.h and fs/compat_ioctl.c. Remove these ioctls + associated structs? I meant of course: 'mark for removal'. Basically all the AUDIO, VIDEO and OSD ioctls should be removed eventually as a general API: they are really a poor-man's V4L and have nothing to do with DVB. The first step is to get ivtv converted so that av7110 is the only one still using them. ivtv will still need to have a small backwards compatibility layer, but at least there is no more need to keep these ioctls in DocBook. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] v4l: add macro for 1080p59_54 preset
On Wednesday, June 08, 2011 14:03:29 Tomasz Stanislawski wrote:
The 1080p59_94 is supported in latest Samusng SoC.
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-common.c |1 +
include/linux/videodev2.h |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-common.c b/drivers/media/video/v4l2-
common.c
index 06b9f9f..003e648 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -582,6 +582,7 @@ int v4l_fill_dv_preset_info(u32 preset, struct
v4l2_dv_enum_preset *info)
{ 1920, 1080, 1080p@30 }, /* V4L2_DV_1080P30 */
{ 1920, 1080, 1080p@50 }, /* V4L2_DV_1080P50 */
{ 1920, 1080, 1080p@60 }, /* V4L2_DV_1080P60 */
+ { 1920, 1080, 1080p@59.94 }, /* V4L2_DV_1080P59_94 */
};
if (info == NULL || preset = ARRAY_SIZE(dv_presets))
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 8a4c309..7c77c4e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -872,6 +872,7 @@ struct v4l2_dv_enum_preset {
#define V4L2_DV_1080P30 16 /* SMPTE 296M */
#define V4L2_DV_1080P50 17 /* BT.1120 */
#define V4L2_DV_1080P60 18 /* BT.1120 */
+#define V4L2_DV_1080P59_94 19
/*
* D V B T T I M I N G S
--
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
--
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/3] v4l: add g_tvnorms callback to V4L2 subdev
On Wednesday, June 08, 2011 14:03:30 Tomasz Stanislawski wrote:
Callback is used to acquire TV norms supported by a subdev.
It is used to avoid having standards in top-level driver.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/media/v4l2-subdev.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1562c4f..4206e97 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -261,6 +261,7 @@ struct v4l2_subdev_video_ops {
int (*s_crystal_freq)(struct v4l2_subdev *sd, u32 freq, u32 flags);
int (*s_std_output)(struct v4l2_subdev *sd, v4l2_std_id std);
int (*querystd)(struct v4l2_subdev *sd, v4l2_std_id *std);
+ int (*g_tvnorms)(struct v4l2_subdev *sd, v4l2_std_id *std);
I would rename this to g_tvnorms_output to clarify that this is for video
output, not input.
It is likely that a g_tvnorms for video input will be added in the future
since this is actually a good idea.
Regards,
Hans
int (*g_input_status)(struct v4l2_subdev *sd, u32 *status);
int (*s_stream)(struct v4l2_subdev *sd, int enable);
int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
--
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
--
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] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Thu, 9 Jun 2011, Kassey Lee wrote: Guennadi, Jon: thanks! we hope to work out a common ccic core, and then re base the code. ok, so, we agree, that I don't review your last version, ok? Thanks Guennadi : On Wed, Jun 8, 2011 at 7:30 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Kassey Thanks for the new version, but, IIUC, you agreed to reimplement your driver on top of a common ccic core, which means, a lot of code will change. So, it doesn't really make much sense now to make and review new stand-alone versions of your driver, right? So, shall we wait until Jon's CCIC code stabilises a bit and you rebase your driver on top of it? Of course, you can also work together with Jon on the drivers to get them faster in shape and in a way, suitable fou you both. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Thu, Jun 9, 2011 at 4:42 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 9 Jun 2011, Kassey Lee wrote: Guennadi, Jon: thanks! we hope to work out a common ccic core, and then re base the code. ok, so, we agree, that I don't review your last version, ok? Guennadi, Jon your comments are always welcome and valuable for us. As Jon will convert cafe_ccic.c to videobuf2 too, I wish He can review this driver too, if it is useful for him. and find the common ccic core. Just Mark it. Thanks Thanks Guennadi : On Wed, Jun 8, 2011 at 7:30 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Kassey Thanks for the new version, but, IIUC, you agreed to reimplement your driver on top of a common ccic core, which means, a lot of code will change. So, it doesn't really make much sense now to make and review new stand-alone versions of your driver, right? So, shall we wait until Jon's CCIC code stabilises a bit and you rebase your driver on top of it? Of course, you can also work together with Jon on the drivers to get them faster in shape and in a way, suitable fou you both. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Best regards Kassey Application Processor Systems Engineering, Marvell Technology Group Ltd. Shanghai, China. -- 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: How do I change a IR remotes keymap?
On Wed, Jun 8, 2011 at 10:23 PM, Dark Shadow shadowofdarkn...@gmail.com wrote: I just got a Grey IR Hauppauge Remote working and I am now trying to setup the keymap for my XBMC HTPC but it seems some buttons don't even show up to XBMC's debugging mode. How do I modify the keymap loaded by the cx23885 module, I don't even know where it is. My most pressing concern is that the OK button on the remote can't be used with XBMC so I can't start anything. When I put the cx23885 module in debugging mode and XBMC in debugging mode. Then have to ssh terminals into it, one running tail -f /var/log/syslog and one doing the XBMC log. Then press most buttons entries show up in both logs but when I try a button like OK it is only the module debugging that shows the rx data but XBMC never sees anything that I can map to a function. Here is one press of the OK button how would I use this info in the modules keymap to make it work as a keyboards enter key Jun 8 21:52:25 htpc kernel: [ 248.019314] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun 8 21:52:25 htpc kernel: [ 248.019318] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.022854] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun 8 21:52:25 htpc kernel: [ 248.022859] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.026418] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun 8 21:52:25 htpc kernel: [ 248.026423] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.032541] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun 8 21:52:25 htpc kernel: [ 248.032546] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.038770] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun 8 21:52:25 htpc kernel: [ 248.038774] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.050099] cx23885[0]/888-ir: IRQ Status: tsr rto Jun 8 21:52:25 htpc kernel: [ 248.050104] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.050127] cx23885[0]/888-ir: rx read: 851815 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050131] cx23885[0]/888-ir: rx read: 800407 ns space Jun 8 21:52:25 htpc kernel: [ 248.050134] cx23885[0]/888-ir: rx read: 826926 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050137] cx23885[0]/888-ir: rx read: 812407 ns space Jun 8 21:52:25 htpc kernel: [ 248.050140] cx23885[0]/888-ir: rx read: 827667 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050143] cx23885[0]/888-ir: rx read: 811815 ns space Jun 8 21:52:25 htpc kernel: [ 248.050146] cx23885[0]/888-ir: rx read: 826926 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050149] cx23885[0]/888-ir: rx read: 812704 ns space Jun 8 21:52:25 htpc kernel: [ 248.050153] cx23885[0]/888-ir: rx read: 850481 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050156] cx23885[0]/888-ir: rx read: 788852 ns space Jun 8 21:52:25 htpc kernel: [ 248.050159] cx23885[0]/888-ir: rx read: 826926 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050162] cx23885[0]/888-ir: rx read: 812704 ns space Jun 8 21:52:25 htpc kernel: [ 248.050165] cx23885[0]/888-ir: rx read: 1627519 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050168] cx23885[0]/888-ir: rx read: 1651222 ns space Jun 8 21:52:25 htpc kernel: [ 248.050171] cx23885[0]/888-ir: rx read: 1627519 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050177] cx23885[0]/888-ir: rx read: 786630 ns space Jun 8 21:52:25 htpc kernel: [ 248.050179] cx23885[0]/888-ir: rx read: 853444 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050181] cx23885[0]/888-ir: rx read: 1650926 ns space Jun 8 21:52:25 htpc kernel: [ 248.050183] cx23885[0]/888-ir: rx read: 1627074 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050185] cx23885[0]/888-ir: rx read: 1651667 ns space Jun 8 21:52:25 htpc kernel: [ 248.050187] cx23885[0]/888-ir: rx read: 801148 ns mark Jun 8 21:52:25 htpc kernel: [ 248.050189] cx23885[0]/888-ir: rx read: end of rx Jun 8 21:52:25 htpc kernel: [ 248.050191] cx23885[0]/888-ir: rx read: 9709000 ns space Jun 8 21:52:25 htpc kernel: [ 248.132956] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun 8 21:52:25 htpc kernel: [ 248.132961] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.136485] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun 8 21:52:25 htpc kernel: [ 248.136491] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.139986] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun 8 21:52:25 htpc kernel: [ 248.139992] cx23885[0]/888-ir: IRQ Enables: rse rte roe Jun 8 21:52:25 htpc kernel: [ 248.146119] cx23885[0]/888-ir: IRQ Status: tsr rsr rby Jun
[PATCH 3.0] soc_camera: OMAP1: stop falling back to dma-sg on single -ENOMEM
Since commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, mm: check if any
page in a pageblock is reserved before marking it MIGRATE_RESERVE, the
OMAP1 camera driver behaviour while in videobuf-dma-contig mode can be
observed as much more stable than before. Once all application programs
are started up and nothing unexpected happens in the system, consecutive
device open()s tend to succeed with almost 100% reliability.
While the result is still not perfect, still prone to occasional -ENOMEM
failures, I think there is no longer a need to fall back to more
reliable but less effective, more resource hungry videobuf-dma-sg mode
if a single open() fails, as long as users are still able to switch
DMA modes from user space over the driver provided sysfs interface,
should videobuf-dma-contig mode still happen to keep failing for them.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi,
While this patch is not a classic fix, not correcting anything that
could be considered as a bug or regression, it is a simple consequence
of unexpected but very welcome enhancement introduced during this merge
window, so I hope it can be accepted in the rc cycle for that reason.
Moreover, it provides no new, but simplifies existing code by removing
no longer needed bits.
Thanks,
Janusz
drivers/media/video/omap1_camera.c | 37 +
1 file changed, 1 insertion(+), 36 deletions(-)
--- git/drivers/media/video/omap1_camera.c.orig 2011-06-06 18:07:54.0
+0200
+++ git/drivers/media/video/omap1_camera.c 2011-06-09 12:04:09.0
+0200
@@ -172,9 +172,6 @@ struct omap1_cam_dev {
struct omap1_cam_buf*ready;
enum omap1_cam_vb_mode vb_mode;
- int (*mmap_mapper)(struct videobuf_queue *q,
- struct videobuf_buffer *buf,
- struct vm_area_struct *vma);
u32 reg_cache[0];
};
@@ -1352,28 +1349,6 @@ static int omap1_cam_try_fmt(struct soc_
static bool sg_mode;
-/*
- * Local mmap_mapper wrapper,
- * used for detecting videobuf-dma-contig buffer allocation failures
- * and switching to videobuf-dma-sg automatically for future attempts.
- */
-static int omap1_cam_mmap_mapper(struct videobuf_queue *q,
- struct videobuf_buffer *buf,
- struct vm_area_struct *vma)
-{
- struct soc_camera_device *icd = q-priv_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
- struct omap1_cam_dev *pcdev = ici-priv;
- int ret;
-
- ret = pcdev-mmap_mapper(q, buf, vma);
-
- if (ret == -ENOMEM)
- sg_mode = true;
-
- return ret;
-}
-
static void omap1_cam_init_videobuf(struct videobuf_queue *q,
struct soc_camera_device *icd)
{
@@ -1391,18 +1366,8 @@ static void omap1_cam_init_videobuf(stru
V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
sizeof(struct omap1_cam_buf), icd,
icd-video_lock);
- /* use videobuf mode (auto)selected with the module parameter */
+ /* use videobuf mode selected with the module parameter */
pcdev-vb_mode = sg_mode ? OMAP1_CAM_DMA_SG : OMAP1_CAM_DMA_CONTIG;
-
- /*
-* Ensure we substitute the videobuf-dma-contig version of the
-* mmap_mapper() callback with our own wrapper, used for switching
-* automatically to videobuf-dma-sg on buffer allocation failure.
-*/
- if (!sg_mode q-int_ops-mmap_mapper != omap1_cam_mmap_mapper) {
- pcdev-mmap_mapper = q-int_ops-mmap_mapper;
- q-int_ops-mmap_mapper = omap1_cam_mmap_mapper;
- }
}
static int omap1_cam_reqbufs(struct soc_camera_device *icd,
--
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
Crash on unplug with the uvc driver in linuxtv/staging/for_v3.1
Hi, When I unplug a uvc camera *while streaming* I get: Jun 9 13:20:02 shalem kernel: [15824.809741] BUG: unable to handle kernel NULL pointer dereference at (null) Jun 9 13:20:02 shalem kernel: [15824.809816] IP: [a0309eae] media_entity_put+0x12/0x2c [media] Jun 9 13:20:02 shalem kernel: [15824.809877] PGD 0 Jun 9 13:20:02 shalem kernel: [15824.809898] Oops: [#1] SMP Jun 9 13:20:02 shalem kernel: [15824.809933] CPU 1 Jun 9 13:20:02 shalem kernel: [15824.809952] Modules linked in: uvcvideo videodev media v4l2_compat_ioctl32 nf_conntrack_ipv4 nf_defrag_ipv4 vfat fat tcp_lp tun fuse ebtable_nat ebtables cpufreq_ondemand acpi_cpufreq freq_table mperf bridge stp llc be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb3i libcxgbi iw_cxgb3 cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ip6t_REJECT nf_conntrack_ipv6 coretemp xt_physdev nf_defrag_ipv6 ip6table_filter xt_state ip6_tables nf_conntrack snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_bt87x usb_storage snd_seq snd_usb_audio uas snd_pcm snd_hwdep snd_usbmidi_lib ppdev snd_rawmidi microcode e1000e snd_seq_device serio_raw i2c_i801 snd_timer tpm_infineon snd iTCO_wdt parport_pc parport soundcore mei(C) iTCO_vendor_support snd_page_alloc virtio_net kvm_intel kvm ipv6 i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: tuner_types] Jun 9 13:20:02 shalem kernel: [15824.810794] Jun 9 13:20:02 shalem kernel: [15824.810811] Pid: 4944, comm: camorama Tainted: G C 3.0.0-rc1+ #5 FUJITSU D3071-S1/D3071-S1 Jun 9 13:20:02 shalem kernel: [15824.810888] RIP: 0010:[a0309eae] [a0309eae] media_entity_put+0x12/0x2c [media] Jun 9 13:20:02 shalem kernel: [15824.810961] RSP: 0018:88011da23d98 EFLAGS: 00010286 Jun 9 13:20:02 shalem kernel: [15824.811003] RAX: RBX: 88006a864400 RCX: 0118 Jun 9 13:20:02 shalem kernel: [15824.811057] RDX: 0001 RSI: 0004 RDI: 88006a864400 Jun 9 13:20:02 shalem kernel: [15824.82] RBP: 88011da23d98 R08: ea0002896e28 R09: 88011da23d38 Jun 9 13:20:02 shalem kernel: [15824.811165] R10: a0526026 R11: 81a58210 R12: 880027d43840 Jun 9 13:20:02 shalem kernel: [15824.811219] R13: 0008 R14: 880133310dc0 R15: 88012db76300 Jun 9 13:20:02 shalem kernel: [15824.811274] FS: 7f7942ff49c0() GS:88013e28() knlGS: Jun 9 13:20:02 shalem kernel: [15824.811336] CS: 0010 DS: ES: CR0: 80050033 Jun 9 13:20:02 shalem kernel: [15824.811381] CR2: CR3: 01a03000 CR4: 000406e0 Jun 9 13:20:02 shalem kernel: [15824.811435] DR0: 0003 DR1: 00b0 DR2: 0001 Jun 9 13:20:02 shalem kernel: [15824.811491] DR3: DR6: 0ff0 DR7: 0400 Jun 9 13:20:02 shalem kernel: [15824.811546] Process camorama (pid: 4944, threadinfo 88011da22000, task 880113618000) Jun 9 13:20:02 shalem kernel: [15824.811609] Stack: Jun 9 13:20:02 shalem kernel: [15824.811629] 88011da23db8 a0510203 880027d43840 880133310dc0 Jun 9 13:20:02 shalem kernel: [15824.811695] 88011da23e08 811233fe 880027d43850 880134530500 Jun 9 13:20:02 shalem kernel: [15824.811763] 811e3397 880027d43840 8801347a5b80 Jun 9 13:20:02 shalem kernel: [15824.811829] Call Trace: Jun 9 13:20:02 shalem kernel: [15824.811856] [a0510203] v4l2_release+0x7b/0x8e [videodev] Jun 9 13:20:02 shalem kernel: [15824.811910] [811233fe] fput+0x121/0x1e3 Jun 9 13:20:02 shalem kernel: [15824.811953] [811e3397] ? exit_sem+0x1c7/0x1d8 Jun 9 13:20:02 shalem kernel: [15824.811998] [811208a7] filp_close+0x6e/0x7a Jun 9 13:20:02 shalem kernel: [15824.812041] [81131b33] ? __d_free+0x53/0x58 Jun 9 13:20:02 shalem kernel: [15824.812084] [810567e1] put_files_struct+0x6e/0xd5 Jun 9 13:20:02 shalem kernel: [15824.812130] [810568d5] exit_files+0x41/0x46 Jun 9 13:20:02 shalem kernel: [15824.812172] [81056e55] do_exit+0x2aa/0x738 Jun 9 13:20:02 shalem kernel: [15824.812214] [8104be73] ? wake_up_state+0x10/0x12 Jun 9 13:20:02 shalem kernel: [15824.812259] [81062ba2] ? signal_wake_up+0x32/0x43 Jun 9 13:20:02 shalem kernel: [15824.812304] [810638b4] ? zap_other_threads+0x59/0x82 Jun 9 13:20:02 shalem kernel: [15824.812352] [81057568] do_group_exit+0x7a/0xa2 Jun 9 13:20:02 shalem kernel: [15824.812395] [810575a7] sys_exit_group+0x17/0x17 Jun 9 13:20:02 shalem kernel: [15824.812440] [81487802] system_call_fastpath+0x16/0x1b Jun 9 13:20:02 shalem kernel: [15824.812486] Code: 10 66 41 ff 44 24 40 48 83 c4 18 44 89 f0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 66 66 66
Re: Brazilian HDTV device
Em 09-06-2011 00:21, Moacyr Prado escreveu: Hi guys, I got some improvements on em28xx to support my device, follow my log: [ 1053.559124] usb 2-2: new high speed USB device using ehci_hcd and address 7 [ 1053.674873] usb 2-2: New USB device found, idVendor=1b80, idProduct=e755 [ 1053.674883] usb 2-2: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 1053.674890] usb 2-2: Product: USB 2885 Device [ 1053.674896] usb 2-2: SerialNumber: 1 [ 1063.858533] em28xx: New device USB 2885 Device @ 480 Mbps (1b80:e755, interface 0, class 0) [ 1063.858902] em28xx #0: em28xx chip ID = 68 [ 1063.980947] em28xx #0: board has no eeprom [ 1063.982123] em28xx #0: Identified as C3Tech U-200 FullSeg Hybrid (card=78) [ 1063.982130] em28xx #0: [ 1063.982132] [ 1063.982137] em28xx #0: The support for this board weren't valid yet. [ 1063.982142] em28xx #0: Please send a report of having this working [ 1063.982148] em28xx #0: not to V4L mailing list (and/or to other addresses) [ 1063.982151] [ 1064.000652] i2c-core: driver [tuner] using legacy suspend method [ 1064.000655] i2c-core: driver [tuner] using legacy resume method [ 1064.006098] Chip ID is not zero. It is not a TEA5767 [ 1064.006193] tuner 16-0060: chip found @ 0xc0 (em28xx #0) [ 1064.008180] tda18271 16-0060: creating new instance [ 1064.015727] TDA18271HD/C2 detected @ 16-0060 [ 1064.905095] tda18271: performing RF tracking filter calibration [ 1068.512078] tda18271: RF tracking filter calibration complete [ 1068.634254] em28xx #0: Config register raw data: 0x9b [ 1068.646228] em28xx #0: AC97 vendor ID = 0x70947094 [ 1068.652224] em28xx #0: AC97 features = 0x7094 [ 1068.652230] em28xx #0: Unknown AC97 audio processor detected! [ 1068.861285] em28xx #0: v4l2 driver version 0.1.2 [ 1069.415411] em28xx #0: V4L2 video device registered as video1 [ 1069.421162] usbcore: registered new interface driver em28xx [ 1069.421169] em28xx driver loaded [ 1069.436428] em28xx-audio.c: probing for em28x1 non standard usbaudio [ 1069.436431] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [ 1069.438133] Em28xx: Initialized (Em28xx Audio Extension) extension [ 1069.560298] mb86a20s: mb86a20s_attach: [ 1069.566738] Detected a Fujitsu mb86a20s frontend [ 1069.566852] tda18271 16-0060: attaching existing instance [ 1069.566858] DVB: registering new adapter (em28xx #0) [ 1069.566863] DVB: registering adapter 0 frontend 0 (Fujitsu mb86A20s)... [ 1069.567506] em28xx #0: Successfully loaded em28xx-dvb [ 1069.567515] Em28xx: Initialized (Em28xx dvb Extension) extension But is not working yet, DVB scan always fail. It must be gpio settings. I got a sniffer data from win7 driver. Anybody has a tip to discover gpio settigs from data sniffed? Moacyr, Take a look at the v4l-utils tree. There are some parsers there for some common sniffer formats, at the utils dirs, and a parser for em28xx format. You may eventually need to write a new parser, if your sniffer has a different format. Of course, you can just try to search for the changes at the GPIO registers, but doing it manually may be very time-consuming. Cheers, Mauro Thanks Moa. --- On Fri, 5/27/11, Moacyr Prado mwpr...@yahoo.com wrote: From: Moacyr Prado mwpr...@yahoo.com Subject: Brazilian HDTV device To: linux-media@vger.kernel.org Date: Friday, May 27, 2011, 9:20 AM Hi, I have a board with empia chipset. The em28xx driver not load, because the device ID is not listed on source(cards.c, I guess). Following bellow have some infos from board: lsusb: Bus 001 Device 004: ID 1b80:e755 Afatech Opening the device, shows this ic: empia em2888 d351c-195 727-00ag (em28xx) nxp saa7136e/1/g SI5296.1 22 ZSD08411 NXP TDA 18271??C2 HDC2? (tda18271) F JAPAN mb86a20s 0937 M01 E1 (mb86a20s) but... dmesg shows: [18373.454136] usb 6-1: USB disconnect, address 2 [18376.744074] usb 2-1: new high speed USB device using ehci_hcd and address 9 [18376.860283] usb 2-1: New USB device found, idVendor=1b80, idProduct=e755 [18376.860293] usb 2-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [18376.860300] usb 2-1: Product: USB 2885 Device [18376.860306] usb 2-1: SerialNumber: 1 Could The em28xx module (writing some code for me)handle this device? Thanks, Moa -- 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
[GIT PULL FOR 3.0] s5p-fimc and m5mols driver fixes
Mauro, please pull the following s5p-fimc and m5mols driver updates. The following changes since commit 215c52702775556f4caf5872cc84fa8810e6fc7d: [media] V4L/videobuf2-memops: use pr_debug for debug messages (2011-06-01 18:20:34 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung s5p-fimc HeungJun, Kim (4): m5mols: Fix capture image size register definition m5mols: add m5mols_read_u8/u16/u32() according to I2C byte width m5mols: remove union in the m5mols_get_version(), and VERSION_SIZE m5mols: Use proper email address format Sylwester Nawrocki (7): s5p-fimc: Fix possible memory leak during capture devnode registration s5p-fimc: Fix V4L2_PIX_FMT_RGB565X description s5p-fimc: Fix data structures documentation and cleanup debug trace s5p-fimc: Fix wrong buffer size in queue_setup s5p-fimc: Remove empty buf_init operation s5p-fimc: Use pix_mp for the color format lookup s5p-fimc: Update copyright notices drivers/media/video/m5mols/m5mols.h | 57 +- drivers/media/video/m5mols/m5mols_capture.c | 22 ++-- drivers/media/video/m5mols/m5mols_controls.c |6 +- drivers/media/video/m5mols/m5mols_core.c | 144 -- drivers/media/video/m5mols/m5mols_reg.h | 21 +++- drivers/media/video/s5p-fimc/fimc-capture.c | 21 +--- drivers/media/video/s5p-fimc/fimc-core.c | 28 ++ drivers/media/video/s5p-fimc/fimc-core.h | 29 +++--- include/media/m5mols.h |4 +- 9 files changed, 176 insertions(+), 156 deletions(-) Thanks, Sylwester Nawrocki -- 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 3.0] soc_camera: OMAP1: stop falling back to dma-sg on single -ENOMEM
Hi Janusz
On Thu, 9 Jun 2011, Janusz Krzysztofik wrote:
Since commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, mm: check if any
page in a pageblock is reserved before marking it MIGRATE_RESERVE, the
OMAP1 camera driver behaviour while in videobuf-dma-contig mode can be
observed as much more stable than before. Once all application programs
are started up and nothing unexpected happens in the system, consecutive
device open()s tend to succeed with almost 100% reliability.
While the result is still not perfect, still prone to occasional -ENOMEM
failures, I think there is no longer a need to fall back to more
reliable but less effective, more resource hungry videobuf-dma-sg mode
if a single open() fails, as long as users are still able to switch
DMA modes from user space over the driver provided sysfs interface,
should videobuf-dma-contig mode still happen to keep failing for them.
Tested on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Hi,
While this patch is not a classic fix, not correcting anything that
could be considered as a bug or regression, it is a simple consequence
of unexpected but very welcome enhancement introduced during this merge
window, so I hope it can be accepted in the rc cycle for that reason.
Moreover, it provides no new, but simplifies existing code by removing
no longer needed bits.
Thanks for the patch.
Hm... First of all, I'm not sure I'd try to push this after the -rc2.
Secondly, I'm having a hard time seeing this as an improvement at all...
Your driver is capable to work in two modes: contiguous and sg, right?
Fortunately also, you are able to automatically switch to the less
efficient, but easier to obtain mode at open() time - I see this as an
advantage. You say, after the quoted commit the contig DMA almost never
fails. I believe, it almost never fails in your configuration. But if you
put your system under a higher memory pressure, it still will fail
repeatedly, right? And I'm not sure, it is always intuitive to the user,
that they have to retry starting an application, after it fails with
-ENOMEM. If you really want to be able to prohibit falling back to SG,
maybe you can add one more module parameter to enforce dma-contig? Is the
reason, why you want to do this, because for your situation you'd prefer
open() to fail rather to switch to SG?
Thanks
Guennadi
Thanks,
Janusz
drivers/media/video/omap1_camera.c | 37
+
1 file changed, 1 insertion(+), 36 deletions(-)
--- git/drivers/media/video/omap1_camera.c.orig 2011-06-06
18:07:54.0 +0200
+++ git/drivers/media/video/omap1_camera.c2011-06-09 12:04:09.0
+0200
@@ -172,9 +172,6 @@ struct omap1_cam_dev {
struct omap1_cam_buf*ready;
enum omap1_cam_vb_mode vb_mode;
- int (*mmap_mapper)(struct videobuf_queue *q,
- struct videobuf_buffer *buf,
- struct vm_area_struct *vma);
u32 reg_cache[0];
};
@@ -1352,28 +1349,6 @@ static int omap1_cam_try_fmt(struct soc_
static bool sg_mode;
-/*
- * Local mmap_mapper wrapper,
- * used for detecting videobuf-dma-contig buffer allocation failures
- * and switching to videobuf-dma-sg automatically for future attempts.
- */
-static int omap1_cam_mmap_mapper(struct videobuf_queue *q,
- struct videobuf_buffer *buf,
- struct vm_area_struct *vma)
-{
- struct soc_camera_device *icd = q-priv_data;
- struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
- struct omap1_cam_dev *pcdev = ici-priv;
- int ret;
-
- ret = pcdev-mmap_mapper(q, buf, vma);
-
- if (ret == -ENOMEM)
- sg_mode = true;
-
- return ret;
-}
-
static void omap1_cam_init_videobuf(struct videobuf_queue *q,
struct soc_camera_device *icd)
{
@@ -1391,18 +1366,8 @@ static void omap1_cam_init_videobuf(stru
V4L2_BUF_TYPE_VIDEO_CAPTURE, V4L2_FIELD_NONE,
sizeof(struct omap1_cam_buf), icd,
icd-video_lock);
- /* use videobuf mode (auto)selected with the module parameter */
+ /* use videobuf mode selected with the module parameter */
pcdev-vb_mode = sg_mode ? OMAP1_CAM_DMA_SG : OMAP1_CAM_DMA_CONTIG;
-
- /*
- * Ensure we substitute the videobuf-dma-contig version of the
- * mmap_mapper() callback with our own wrapper, used for switching
- * automatically to videobuf-dma-sg on buffer allocation failure.
- */
- if (!sg_mode q-int_ops-mmap_mapper != omap1_cam_mmap_mapper) {
- pcdev-mmap_mapper = q-int_ops-mmap_mapper;
- q-int_ops-mmap_mapper = omap1_cam_mmap_mapper;
-
Re: RFC] Media kernelspace-userspace API specs (V4L/DVB/IR) - Was: Re: [PATCH 00/13] Reduce the gap between DVBv5 API and the specs
Em 09-06-2011 04:08, Hans Verkuil escreveu: On Thursday, June 09, 2011 03:20:43 Mauro Carvalho Chehab wrote: d) The API usage inside drivers/media and drivers/staging is given by: I'll comment on those ioctls used by ivtv: AUDIO_SET_MUTE drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c Used to mute the audio when playing back an mpeg stream. We can use the AUDIO_MUTE control for this. This will require some work in ivtv since at the moment all video nodes share the same controls. In this case the video output node should get its own MUTE control. AUDIO_CHANNEL_SELECT drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c How to playback normal MPEG audio: left, right, stereo, swapped. AUDIO_BILINGUAL_CHANNEL_SELECT drivers/media/video/ivtv/ivtv-ioctl.c How to playback bilingual MPEG audio: left, right, stereo, swapped. The decoder will automatically detect whether the source is bilingual or not and select either CHANNEL_SELECT or BILINGUAL_CHANNEL_SELECT as needed for the audio output. I'm not sure what to do with these. There are multiple options: - Reimplement them as menu controls. - Add them to VIDIOC_DECODER_CMD, either as a separate command or as part of the PLAY command. I'm not enthusiastic about this since these properties can be changed while decoding is in progress. It does not really fit my idea of a 'decoder command'. - Add support for this to VIDIOC_G/S_AUDOUT. Any decoder with audio output should have this ioctl. There is a currently unused 'mode' field in struct v4l2_audioout that might be used for this purpose. I think either controls or using AUDOUT is the way to go. I am leaning towards controls since they will automatically appear in properly written applications and this is really a user-driven setting. And with menu controls it is easy to extend the number of options. I think that using AUDOUT would be more coherent. There are two fields there that are reserved: capability and mode. We can add capability flags to indicate that the audout supports channel mode changes and use the mode on a way similar to rxsubchans to select between the channel outputs. Yet, MPEG AAC supports up to 48 channels and multiple languages. We may need to have a way to get the information from the hardware about what channels are available, and how they're grouped. VIDEO_STOP drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c VIDEO_PLAY drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c VIDEO_FREEZE drivers/media/dvb/ttpci/av7110.c drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c VIDEO_CONTINUE drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c Stop/Play/Pause/Continue MPEG decoding. There should all be deprecated and replaced with VIDIOC_DECODER_CMD. Another alternative would be to consider: VIDIOC_STREAMON = VIDEO_PLAY VIDIOC_STREAMOFF = VIDEO_STOP And add VIDIOC_FREEZE/VIDIOC_CONTINUE. Adding a VIDIOC_DECODER_CMD ioctl that also controls play/stop seems to be a bad idea, as we'll have some API overlap here. VIDEO_SELECT_SOURCE drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c Select passthrough mode where the input is directly linked to the output in the hardware. This really changes the topology of the device. The media controller does just that, so ivtv should implement the MC. There are no applications that use this to my knowledge other than ivtv-ctl in v4l-utils. We don't need to use MC for that. The VIDIOC_*_AUDIOOUT already provides the elements to enumerate and select the audio output. VIDEO_GET_EVENT drivers/media/dvb/ttpci/av7110_av.c drivers/media/video/ivtv/ivtv-ioctl.c Already deprecated: use the V4L event APIs for that (VIDIOC_DQEVENT et al). OK. AUDIO_SET_EXT_ID AUDIO_SET_ATTRIBUTES AUDIO_SET_KARAOKE VIDEO_SET_SYSTEM VIDEO_SET_HIGHLIGHT VIDEO_SET_SPU VIDEO_SET_SPU_PALETTE VIDEO_GET_NAVI VIDEO_SET_ATTRIBUTES VIDEO_SET_ID VIDEO_GET_FRAME_RATE These are only seen in audio.h/video.h and fs/compat_ioctl.c. Remove these ioctls + associated structs? Yes, that sounds the right way to do it. As nobody is using it, I don't think we need to add it at the list of the Kernel features to be removed. as this is unused stuff. So, no regressions will happen. VIDEO_GET_PTS drivers/media/video/ivtv/ivtv-ioctl.c Returns the current PTS of the decoder. Perhaps a read-only MPEG control is more suitable? Yes, a MPEG control for it seems to be enough. VIDEO_GET_FRAME_COUNT drivers/media/video/ivtv/ivtv-ioctl.c Returns the number of decoded frames since the decoder started. Make this a read-only MPEG control? Yes, a MPEG control for it seems to be enough. VIDEO_COMMAND drivers/media/dvb/ttpci/av7110_hw.h drivers/media/video/ivtv/ivtv-ioctl.c VIDEO_TRY_COMMAND
Re: [PATCH 05/13] [media] dvb/audio.h: Remove definition for AUDIO_GET_PTS
On 06/08/2011 10:23 PM, Mauro Carvalho Chehab wrote:
While this ioctl is defined inside dvb/audio.h, it is not docummented
at the API specs, nor implemented on any driver inside the Linux Kernel.
So, it doesn't make sense to keep it here.
As this is not used anywere, removing it is not a regression. So,
there's no need to use the normal features-to-be-removed process.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
index d47bccd..c1b3555 100644
--- a/include/linux/dvb/audio.h
+++ b/include/linux/dvb/audio.h
@@ -118,18 +118,6 @@ typedef __u16 audio_attributes_t;
#define AUDIO_SET_ATTRIBUTES _IOW('o', 17, audio_attributes_t)
#define AUDIO_SET_KARAOKE _IOW('o', 18, audio_karaoke_t)
-/**
- * AUDIO_GET_PTS
- *
- * Read the 33 bit presentation time stamp as defined
- * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
- *
- * The PTS should belong to the currently played
- * frame if possible, but may also be a value close to it
- * like the PTS of the last decoded frame or the last PTS
- * extracted by the PES parser.
- */
-#define AUDIO_GET_PTS _IOR('o', 19, __u64)
#define AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
#endif /* _DVBAUDIO_H_ */
Please don't apply this patch. In general, many ioctls aren't
implemented in mainline drivers, because most if not all supported
devices inside the kernel tree are either PCI or USB add-in devices and
usually quite simple compared to a STB.
This ioctl is used at least by enigma2 in userspace and implemented in
drivers for several generations of the dreambox.
Regards,
Andreas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: Add V4L2 decoder commands/controls to replace dvb/video.h
RFC: Proposal for a V4L2 decoder API
This RFC is based on this discussion:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg32703.html
The purpose is to remove the dependency of ivtv to the ioctls in dvb/audio.h
and dvb/video.h.
The summary of the posting referred to above is:
- Add two controls to select the audio output channels.
- Add two read-only controls for the PTS and frame count.
- Copy and paste the old VIDEO_(TRY_)COMMAND to VIDIOC_(TRY_)DECODER_CMD.
So, here is the RFC that does that. I'm going through the items from the
summary in reverse order.
1) Add new VIDIOC_TRY_DECODER_CMD and VIDIOC_DECODER_CMD ioctls.
These are the decoder counterparts of the VIDIOC_(TRY_)ENCODER_CMD ioctls
that are already in V4L2.
/* Decoder commands */
#define V4L2_DEC_CMD_PLAY(0)
#define V4L2_DEC_CMD_STOP(1)
#define V4L2_DEC_CMD_FREEZE (2)
#define V4L2_DEC_CMD_CONTINUE(3)
/* Flags for V4L2_DEC_CMD_FREEZE */
#define V4L2_DEC_CMD_FREEZE_TO_BLACK(1 0)
/* Flags for V4L2_DEC_CMD_STOP */
#define V4L2_DEC_CMD_STOP_TO_BLACK (1 0)
#define V4L2_DEC_CMD_STOP_IMMEDIATELY (1 1)
/* Play format requirements (returned by the driver): */
/* The decoder has no special format requirements */
#define V4L2_DEC_PLAY_FMT_NONE (0)
/* The decoder requires full GOPs */
#define V4L2_DEC_PLAY_FMT_GOP (1)
/* The structure must be zeroed before use by the application
This ensures it can be extended safely in the future. */
struct v4l2_decoder_cmd {
__u32 cmd;
__u32 flags;
union {
struct {
/* Stop when this PTS is reached */
__u64 pts;
} stop;
struct {
/* 0 or 1000 specifies normal speed,
1 specifies forward single stepping,
-1 specifies backward single stepping,
1: playback at speed/1000 of the normal speed,
-1: reverse playback at (-speed/1000) of the normal
speed.
*/
__s32 speed;
__u32 format;
} play;
struct {
__u32 data[16];
} raw;
};
};
Other than renaming the #defines and struct there are no changes compared to
the current video.h API. I see no reason to change this either.
2) Add read-only controls for the PTS and framecount.
V4L2_CID_MPEG_STREAM_DEC_PTS - integer64
Return the PTS (Presentation Time Stamp) of the currently presented frame.
V4L2_CID_MPEG_VIDEO_DEC_FRAME - integer
Return the frame number of the currently presented frame. When the decoder
starts the frame counter is reset to 0.
3) Add two new audio selection controls.
V4L2_CID_MPEG_AUDIO_DEC_CHANNEL - menu
Select how to playback stereo audio from a normal audio stream:
0 - Auto (playback native format)
1 - Left (left channel only)
2 - Right (right channel only)
3 - Stereo
4 - Swapped Stereo (I'm not sure whether this should be added. Is this ever
useful?)
This control relates to its encoder counterpart V4L2_CID_MPEG_AUDIO_MODE for
the non-DUAL modes.
V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_CHANNEL - menu
Select how to playback audio from a multilingual audio stream:
0 - Auto (either always Left or can be based on some preferred language)
1 - Left (left channel only)
2 - Right (right channel only)
3 - Stereo
4 - Swapped Stereo (I'm not sure whether this should be added. Is this ever
useful?)
This control relates to its encoder counterpart V4L2_CID_MPEG_AUDIO_MODE for
the DUAL mode.
Note that these two controls are specific to the audio layer I/II/III audio
mode setting. They do not support any e.g. AAC decoding. More research will
need to be done to know whether that makes sense or not.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] Reduce the gap between DVBv5 API and the specs
On 06/08/2011 11:38 PM, Mauro Carvalho Chehab wrote: - all AUDIO*, OSD* and VIDEO* are used only by av7110 and ivtv. - The CA* ioctls are used by core (although several are only implemented inside a few drivers); All (or most) of these ioctls (except OSD, which AFAIR has been deprecated since v3) are used by out-of-tree drivers. av7110 and ivtv just happen to be the only in-tree drivers supporting audio and video decoders. Regards, Andreas -- 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 05/13] [media] dvb/audio.h: Remove definition for AUDIO_GET_PTS
Hi Andreas,
Em 09-06-2011 09:44, Andreas Oberritter escreveu:
On 06/08/2011 10:23 PM, Mauro Carvalho Chehab wrote:
While this ioctl is defined inside dvb/audio.h, it is not docummented
at the API specs, nor implemented on any driver inside the Linux Kernel.
So, it doesn't make sense to keep it here.
As this is not used anywere, removing it is not a regression. So,
there's no need to use the normal features-to-be-removed process.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
index d47bccd..c1b3555 100644
--- a/include/linux/dvb/audio.h
+++ b/include/linux/dvb/audio.h
@@ -118,18 +118,6 @@ typedef __u16 audio_attributes_t;
#define AUDIO_SET_ATTRIBUTES _IOW('o', 17, audio_attributes_t)
#define AUDIO_SET_KARAOKE _IOW('o', 18, audio_karaoke_t)
-/**
- * AUDIO_GET_PTS
- *
- * Read the 33 bit presentation time stamp as defined
- * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
- *
- * The PTS should belong to the currently played
- * frame if possible, but may also be a value close to it
- * like the PTS of the last decoded frame or the last PTS
- * extracted by the PES parser.
- */
-#define AUDIO_GET_PTS _IOR('o', 19, __u64)
#define AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
#endif /* _DVBAUDIO_H_ */
Please don't apply this patch. In general, many ioctls aren't
implemented in mainline drivers, because most if not all supported
devices inside the kernel tree are either PCI or USB add-in devices and
usually quite simple compared to a STB.
This ioctl is used at least by enigma2 in userspace and implemented in
drivers for several generations of the dreambox.
If this is implemented on userspace only, what's the point of having it
inside the kernel API?
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: [PATCH 00/13] Reduce the gap between DVBv5 API and the specs
On 6/9/11, Mauro Carvalho Chehab mche...@redhat.com wrote: There's a huge gap between the DVB specs and the current implementation. This were caused by years of changes that happened at the code but no updates to the specs were done. This patch series tries to reduce this gap. Basically, the headers at include/linux/dvb were included at the API. The Makefile scripting auto-generate references for structs, typedefs and ioctls. With this, it is now easy to identify when something is missing. After adding such logic, I've manually synchronized the specs with the header file and updated the data structures. The work is not complete yet: there are still several ioctl's not documented at the specs: While here, I noticed that one audio ioctl is not used anyware (AUDIO_GET_PTS). There is just the ioctl definition and that's it. I just removed this definition, as removing it won't cause any regression, as no in-kernel driver or dvb-core uses it. Please do not apply this patch; the SAA716x FF DVB driver uses the same ioctl. Best Regards, 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 05/13] [media] dvb/audio.h: Remove definition for AUDIO_GET_PTS
On 06/09/2011 03:04 PM, Mauro Carvalho Chehab wrote:
Hi Andreas,
Em 09-06-2011 09:44, Andreas Oberritter escreveu:
On 06/08/2011 10:23 PM, Mauro Carvalho Chehab wrote:
While this ioctl is defined inside dvb/audio.h, it is not docummented
at the API specs, nor implemented on any driver inside the Linux Kernel.
So, it doesn't make sense to keep it here.
As this is not used anywere, removing it is not a regression. So,
there's no need to use the normal features-to-be-removed process.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/include/linux/dvb/audio.h b/include/linux/dvb/audio.h
index d47bccd..c1b3555 100644
--- a/include/linux/dvb/audio.h
+++ b/include/linux/dvb/audio.h
@@ -118,18 +118,6 @@ typedef __u16 audio_attributes_t;
#define AUDIO_SET_ATTRIBUTES _IOW('o', 17, audio_attributes_t)
#define AUDIO_SET_KARAOKE _IOW('o', 18, audio_karaoke_t)
-/**
- * AUDIO_GET_PTS
- *
- * Read the 33 bit presentation time stamp as defined
- * in ITU T-REC-H.222.0 / ISO/IEC 13818-1.
- *
- * The PTS should belong to the currently played
- * frame if possible, but may also be a value close to it
- * like the PTS of the last decoded frame or the last PTS
- * extracted by the PES parser.
- */
-#define AUDIO_GET_PTS _IOR('o', 19, __u64)
#define AUDIO_BILINGUAL_CHANNEL_SELECT _IO('o', 20)
#endif /* _DVBAUDIO_H_ */
Please don't apply this patch. In general, many ioctls aren't
implemented in mainline drivers, because most if not all supported
devices inside the kernel tree are either PCI or USB add-in devices and
usually quite simple compared to a STB.
This ioctl is used at least by enigma2 in userspace and implemented in
drivers for several generations of the dreambox.
If this is implemented on userspace only, what's the point of having it
inside the kernel API?
... implemented in *kernel* drivers for several generations of the dreambox.
I mentioned enigma2, because a kernel API without a user wouldn't make
much sense either.
Regards,
Andreas
--
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 3.0] soc_camera: OMAP1: stop falling back to dma-sg on single -ENOMEM
On Thu 09 Jun 2011 at 14:07:22 Guennadi Liakhovetski wrote: Hi Janusz On Thu, 9 Jun 2011, Janusz Krzysztofik wrote: Since commit 6d3163ce86dd386b4f7bda80241d7fea2bc0bb1d, mm: check if any page in a pageblock is reserved before marking it MIGRATE_RESERVE, the OMAP1 camera driver behaviour while in videobuf-dma-contig mode can be observed as much more stable than before. Once all application programs are started up and nothing unexpected happens in the system, consecutive device open()s tend to succeed with almost 100% reliability. While the result is still not perfect, still prone to occasional -ENOMEM failures, I think there is no longer a need to fall back to more reliable but less effective, more resource hungry videobuf-dma-sg mode if a single open() fails, as long as users are still able to switch DMA modes from user space over the driver provided sysfs interface, should videobuf-dma-contig mode still happen to keep failing for them. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- Hi, While this patch is not a classic fix, not correcting anything that could be considered as a bug or regression, it is a simple consequence of unexpected but very welcome enhancement introduced during this merge window, so I hope it can be accepted in the rc cycle for that reason. Moreover, it provides no new, but simplifies existing code by removing no longer needed bits. Thanks for the patch. Hm... First of all, I'm not sure I'd try to push this after the -rc2. No problem. Secondly, I'm having a hard time seeing this as an improvement at all... Your driver is capable to work in two modes: contiguous and sg, right? Fortunately also, you are able to automatically switch to the less efficient, but easier to obtain mode at open() time No, not at the just failing open() time, but only on next open(). While developing this feature, I didn't find a better way of implementing it, and I'm probably still not able to, without replicating parts of videobuf-dma-contig layer with custom modifications, because of different pre-open() videobuf setup steps required. - I see this as an advantage. You say, after the quoted commit the contig DMA almost never fails. I believe, it almost never fails in your configuration. But if you put your system under a higher memory pressure, it still will fail repeatedly, right? And I'm not sure, it is always intuitive to the user, that they have to retry starting an application, after it fails with -ENOMEM. They do now, once on first fault, and based on my test results I could expect they might still have to do it only once from 3.0 on, even without auto fall back. If you really want to be able to prohibit falling back to SG, maybe you can add one more module parameter to enforce dma-contig? Is the reason, why you want to do this, because for your situation you'd prefer open() to fail rather to switch to SG? The reason was simple: after system start-up, open() usually fails for me only once, then keeps working quite reliably. But you are right saying that my test results may be not reproducible in a different environment. So, maybe let's forgot about this patch and wait until dma_alloc_coherent() starts working 100% reliably on OMAP1, or a different, more reliable than dma-contig videobuf/videobuf2 option is available. Thanks, Janusz -- 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 00/13] Reduce the gap between DVBv5 API and the specs
Em 09-06-2011 10:06, Manu Abraham escreveu: On 6/9/11, Mauro Carvalho Chehab mche...@redhat.com wrote: There's a huge gap between the DVB specs and the current implementation. This were caused by years of changes that happened at the code but no updates to the specs were done. This patch series tries to reduce this gap. Basically, the headers at include/linux/dvb were included at the API. The Makefile scripting auto-generate references for structs, typedefs and ioctls. With this, it is now easy to identify when something is missing. After adding such logic, I've manually synchronized the specs with the header file and updated the data structures. The work is not complete yet: there are still several ioctl's not documented at the specs: While here, I noticed that one audio ioctl is not used anyware (AUDIO_GET_PTS). There is just the ioctl definition and that's it. I just removed this definition, as removing it won't cause any regression, as no in-kernel driver or dvb-core uses it. Please do not apply this patch; the SAA716x FF DVB driver uses the same ioctl. I'll revert this patch for now, in order to wait for driver submissions that use this ioctl (and the other ioctl's that are not used anywhere inside the Kernel). Thanks, 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: [PATCH 00/13] Reduce the gap between DVBv5 API and the specs
On 6/9/11, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 09-06-2011 10:06, Manu Abraham escreveu: On 6/9/11, Mauro Carvalho Chehab mche...@redhat.com wrote: There's a huge gap between the DVB specs and the current implementation. This were caused by years of changes that happened at the code but no updates to the specs were done. This patch series tries to reduce this gap. Basically, the headers at include/linux/dvb were included at the API. The Makefile scripting auto-generate references for structs, typedefs and ioctls. With this, it is now easy to identify when something is missing. After adding such logic, I've manually synchronized the specs with the header file and updated the data structures. The work is not complete yet: there are still several ioctl's not documented at the specs: While here, I noticed that one audio ioctl is not used anyware (AUDIO_GET_PTS). There is just the ioctl definition and that's it. I just removed this definition, as removing it won't cause any regression, as no in-kernel driver or dvb-core uses it. Please do not apply this patch; the SAA716x FF DVB driver uses the same ioctl. I'll revert this patch for now, in order to wait for driver submissions that use this ioctl (and the other ioctl's that are not used anywhere inside the Kernel). Thanks! Best Regards, 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] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Thu, 9 Jun 2011 16:46:47 +0800 Kassey Lee kassey1...@gmail.com wrote: As Jon will convert cafe_ccic.c to videobuf2 too, I wish He can review this driver too, if it is useful for him. and find the common ccic core. Just Mark it. I do plan to take a close look at the driver; if nothing else, I want to be sure that the core code can support it with minimal pain. I tend to be busy early in the week, but much of today is set aside for work in this area. Thanks, 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 3/3] adp1653: Add driver for LED flash controller
Hi Sakari, On Monday 16 May 2011 15:00:39 Sakari Ailus wrote: This patch adds the driver for the adp1653 LED flash controller. This controller supports a high power led in flash and torch modes and an indicator light, sometimes also called privacy light. The adp1653 is used on the Nokia N900. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Signed-off-by: Tuukka Toivonen tuukka...@gmail.com Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Signed-off-by: David Cohen daco...@gmail.com [snip] + v4l2_ctrl_new_std(flash-ctrls, adp1653_ctrl_ops, + V4L2_CID_FLASH_FAULT, 0, V4L2_FLASH_FAULT_OVER_VOLTAGE + | V4L2_FLASH_FAULT_OVER_TEMPERATURE + | V4L2_FLASH_FAULT_SHORT_CIRCUIT, 0, 0); You need to mark the fault control as volatile. -- 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
[PATCH] [media] ite-cir: 8709 needs to use pnp resource 2
Thanks to the intrepid testing and debugging of Matthijs van Drunen, it
was uncovered that at least some variants of the ITE8709 need to use pnp
resource 2, rather than 0, for things to function properly. Resource 0
has a length of only 1, and if you try to bypass the pnp_port_len check
and use it anyway (with either a length of 1 or 2), the system in
question's trackpad ceased to function.
The circa lirc 0.8.7 lirc_ite8709 driver used resource 2, but the value
was (amusingly) changed to 0 by way of a patch from ITE themselves, so I
don't know if there may be variants where 0 actually *is* correct, but
at least in this case and in the original lirc_ite8709 driver author's
case, it sure looks like 2 is the right value.
This fix should probably be applied to all stable kernels with the
ite-cir driver, lest we nuke more people's trackpads.
Tested-by: Matthijs van Drunen
CC: Juan Jesús García de Soria skanda...@gmail.com
CC: sta...@kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/ite-cir.c | 12 +---
drivers/media/rc/ite-cir.h |3 +++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index e716b93..ecd3d02 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1347,6 +1347,7 @@ static const struct ite_dev_params ite_dev_descs[] = {
{ /* 0: ITE8704 */
.model = ITE8704 CIR transceiver,
.io_region_size = IT87_IOREG_LENGTH,
+ .io_rsrc_no = 0,
.hw_tx_capable = true,
.sample_period = (u32) (10ULL / 115200),
.tx_carrier_freq = 38000,
@@ -1371,6 +1372,7 @@ static const struct ite_dev_params ite_dev_descs[] = {
{ /* 1: ITE8713 */
.model = ITE8713 CIR transceiver,
.io_region_size = IT87_IOREG_LENGTH,
+ .io_rsrc_no = 0,
.hw_tx_capable = true,
.sample_period = (u32) (10ULL / 115200),
.tx_carrier_freq = 38000,
@@ -1395,6 +1397,7 @@ static const struct ite_dev_params ite_dev_descs[] = {
{ /* 2: ITE8708 */
.model = ITE8708 CIR transceiver,
.io_region_size = IT8708_IOREG_LENGTH,
+ .io_rsrc_no = 0,
.hw_tx_capable = true,
.sample_period = (u32) (10ULL / 115200),
.tx_carrier_freq = 38000,
@@ -1420,6 +1423,7 @@ static const struct ite_dev_params ite_dev_descs[] = {
{ /* 3: ITE8709 */
.model = ITE8709 CIR transceiver,
.io_region_size = IT8709_IOREG_LENGTH,
+ .io_rsrc_no = 2,
.hw_tx_capable = true,
.sample_period = (u32) (10ULL / 115200),
.tx_carrier_freq = 38000,
@@ -1461,6 +1465,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct
pnp_device_id
struct rc_dev *rdev = NULL;
int ret = -ENOMEM;
int model_no;
+ int io_rsrc_no;
ite_dbg(%s called, __func__);
@@ -1490,10 +1495,11 @@ static int ite_probe(struct pnp_dev *pdev, const struct
pnp_device_id
/* get the description for the device */
dev_desc = ite_dev_descs[model_no];
+ io_rsrc_no = dev_desc-io_rsrc_no;
/* validate pnp resources */
- if (!pnp_port_valid(pdev, 0) ||
- pnp_port_len(pdev, 0) != dev_desc-io_region_size) {
+ if (!pnp_port_valid(pdev, io_rsrc_no) ||
+ pnp_port_len(pdev, io_rsrc_no) != dev_desc-io_region_size) {
dev_err(pdev-dev, IR PNP Port not valid!\n);
goto failure;
}
@@ -1504,7 +1510,7 @@ static int ite_probe(struct pnp_dev *pdev, const struct
pnp_device_id
}
/* store resource values */
- itdev-cir_addr = pnp_port_start(pdev, 0);
+ itdev-cir_addr = pnp_port_start(pdev, io_rsrc_no);
itdev-cir_irq = pnp_irq(pdev, 0);
/* initialize spinlocks */
diff --git a/drivers/media/rc/ite-cir.h b/drivers/media/rc/ite-cir.h
index 16a19f5..aa899a0 100644
--- a/drivers/media/rc/ite-cir.h
+++ b/drivers/media/rc/ite-cir.h
@@ -57,6 +57,9 @@ struct ite_dev_params {
/* size of the I/O region */
int io_region_size;
+ /* IR pnp I/O resource number */
+ int io_rsrc_no;
+
/* true if the hardware supports transmission */
bool hw_tx_capable;
--
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] [media] keymaps: fix table for pinnacle pctv hd devices
Both consumers of RC_MAP_PINNACLE_PCTV_HD send along full RC-5
scancodes, so this update makes this keymap actually *have* full
scancodes, heisted from rc-dib0700-rc5.c. This should fix out of the box
remote functionality for the Pinnacle PCTV HD 800i (cx88 pci card) and
PCTV HD Pro 801e (em28xx usb stick).
CC: sta...@kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c | 58 +++-
1 files changed, 27 insertions(+), 31 deletions(-)
diff --git a/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c
b/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c
index bb10ffe..8d558ae 100644
--- a/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c
+++ b/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c
@@ -15,43 +15,39 @@
/* Pinnacle PCTV HD 800i mini remote */
static struct rc_map_table pinnacle_pctv_hd[] = {
-
- { 0x0f, KEY_1 },
- { 0x15, KEY_2 },
- { 0x10, KEY_3 },
- { 0x18, KEY_4 },
- { 0x1b, KEY_5 },
- { 0x1e, KEY_6 },
- { 0x11, KEY_7 },
- { 0x21, KEY_8 },
- { 0x12, KEY_9 },
- { 0x27, KEY_0 },
-
- { 0x24, KEY_ZOOM },
- { 0x2a, KEY_SUBTITLE },
-
- { 0x00, KEY_MUTE },
- { 0x01, KEY_ENTER },/* Pinnacle Logo */
- { 0x39, KEY_POWER },
-
- { 0x03, KEY_VOLUMEUP },
- { 0x09, KEY_VOLUMEDOWN },
- { 0x06, KEY_CHANNELUP },
- { 0x0c, KEY_CHANNELDOWN },
-
- { 0x2d, KEY_REWIND },
- { 0x30, KEY_PLAYPAUSE },
- { 0x33, KEY_FASTFORWARD },
- { 0x3c, KEY_STOP },
- { 0x36, KEY_RECORD },
- { 0x3f, KEY_EPG }, /* Labeled ? */
+ /* Key codes for the tiny Pinnacle remote*/
+ { 0x0700, KEY_MUTE },
+ { 0x0701, KEY_MENU }, /* Pinnacle logo */
+ { 0x0739, KEY_POWER },
+ { 0x0703, KEY_VOLUMEUP },
+ { 0x0709, KEY_VOLUMEDOWN },
+ { 0x0706, KEY_CHANNELUP },
+ { 0x070c, KEY_CHANNELDOWN },
+ { 0x070f, KEY_1 },
+ { 0x0715, KEY_2 },
+ { 0x0710, KEY_3 },
+ { 0x0718, KEY_4 },
+ { 0x071b, KEY_5 },
+ { 0x071e, KEY_6 },
+ { 0x0711, KEY_7 },
+ { 0x0721, KEY_8 },
+ { 0x0712, KEY_9 },
+ { 0x0727, KEY_0 },
+ { 0x0724, KEY_ZOOM }, /* 'Square' key */
+ { 0x072a, KEY_SUBTITLE }, /* 'T' key */
+ { 0x072d, KEY_REWIND },
+ { 0x0730, KEY_PLAYPAUSE },
+ { 0x0733, KEY_FASTFORWARD },
+ { 0x0736, KEY_RECORD },
+ { 0x073c, KEY_STOP },
+ { 0x073f, KEY_HELP }, /* '?' key */
};
static struct rc_map_list pinnacle_pctv_hd_map = {
.map = {
.scan= pinnacle_pctv_hd,
.size= ARRAY_SIZE(pinnacle_pctv_hd),
- .rc_type = RC_TYPE_UNKNOWN, /* Legacy IR type */
+ .rc_type = RC_TYPE_RC5,
.name= RC_MAP_PINNACLE_PCTV_HD,
}
};
--
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] [media] lirc_zilog: fix spinning rx thread
We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced in
commit 5bd6b0464b68d429bc8a3fe6595d19c39dfc4d95, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included in,
but alas, stuff happens...
CC: Andy Walls awa...@md.metrocast.net
CC: sta...@kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/staging/lirc/lirc_zilog.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index dd6a57c..4e051f6 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -475,14 +475,14 @@ static int lirc_thread(void *arg)
dprintk(poll thread started\n);
while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
+
/* if device not opened, we can sleep half a second */
if (atomic_read(ir-open_count) == 0) {
schedule_timeout(HZ/2);
continue;
}
- set_current_state(TASK_INTERRUPTIBLE);
-
/*
* This is ~113*2 + 24 + jitter (2*repeat gap + code length).
* We use this interval as the chip resets every time you poll
--
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: linux-next: Tree for June 9 (media/radio/radio-sf16fmr2)
On Thu, 9 Jun 2011 18:09:46 +1000 Stephen Rothwell wrote: Hi all, [The kernel.org mirroring is being slow today] Changes since 20110608: on i386 (X86_32): ERROR: snd_tea575x_init [drivers/media/radio/radio-sf16fmr2.ko] undefined! ERROR: snd_tea575x_exit [drivers/media/radio/radio-sf16fmr2.ko] undefined! full randconfig file is attached. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** config-r7963 Description: Binary data
[cron job] v4l-dvb daily build: 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:Thu Jun 9 19:00:45 CEST 2011 git hash:4f75ad768da3c5952d1e7080045a5b5ce7b0d85d gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 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: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec 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: linux-next: Tree for June 8 (docbook/media)
Hi Randy, Em 08-06-2011 16:52, Randy Dunlap escreveu: On Wed, 8 Jun 2011 16:10:46 +1000 Stephen Rothwell wrote: Hi all, Changes since 20110607: Hi Mauro, The DocBook/media/Makefile seems to be causing too much noise: ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.gif: No such file or directory ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.png: No such file or directory Maybe the cleanmediadocs target could be made silent? I'll take a look on it. FYI, The next build will probably be noisier, as it is now pointing to some documentation gaps at the DVB API. Those gaps should take a longer time to fix, as we need to discuss upstream about what should be done with those API's, that seems to be abandoned upstream (only one legacy DVB driver uses them). However, I was told that some out-of-tree drivers and some drivers under development are using them. So, I intend to wait until the next merge window before either dropping those legacy API specs (or moving them to a deprecated section) or to merge those out-of-tree drivers, with the proper documentation updates. also, where is the mediaindexdocs target defined? Thanks for noticing it. We don't need this target anymore. I'll write a patch removing it. 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: [PATCH 1/2] V4L: mt9m111: propagate higher level abstraction down in functions
On 06/07/2011 12:02 PM, Guennadi Liakhovetski wrote:
On Mon, 6 Jun 2011, Robert Jarzmik wrote:
On 06/06/2011 07:20 PM, Guennadi Liakhovetski wrote:
It is more convenient to propagate the higher level abstraction - the
struct mt9m111 object into functions and then retrieve a pointer to
the i2c client, if needed, than to do the reverse.
Agreed.
One minor point, you ofter replace :
- struct mt9m111 *mt9m111 = to_mt9m111(client);
+ struct mt9m111 *mt9m111 = container_of(sd, struct mt9m111, subdev);
Why haven't you replaced the signature of to_mt9m111() into :
static struct mt9m111 *to_mt9m111(const struct v4l2_subdev *sd)
{
return container_of(sd, struct mt9m111, subdev);
}
This way, each to_mt9m111(client) will become to_mt9m111(sd), and the purpose
of to_mt9m111() will be kept. Wouldn't that be better ?
Because container_of(sd, struct mt9m111, subdev) is still easy enough to
write (copy-paste, of course:)) and understand, whereas
container_of(i2c_get_clientdata(client), struct mt9m111, subdev) is
already too awkward to look at, even though it is now only used at 4
locations.
And copy paste client into sd is even quicker, isn't it ?
A general question to you: from your comments I haven't understood: have
you also tested the patches or only reviewed them?
Only reviewed so far. Test will come Monday.
Cheers.
--
Robert
--
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: linux-next: Tree for June 8 (docbook/media)
Em 09-06-2011 16:25, Mauro Carvalho Chehab escreveu: Em 08-06-2011 16:52, Randy Dunlap escreveu: The DocBook/media/Makefile seems to be causing too much noise: ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.gif: No such file or directory ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.png: No such file or directory Maybe the cleanmediadocs target could be made silent? I'll take a look on it. FYI, The next build will probably be noisier, as it is now pointing to some documentation gaps at the DVB API. Those gaps should take a longer time to fix, as we need to discuss upstream about what should be done with those API's, that seems to be abandoned upstream (only one legacy DVB driver uses them). However, I was told that some out-of-tree drivers and some drivers under development are using them. So, I intend to wait until the next merge window before either dropping those legacy API specs (or moving them to a deprecated section) or to merge those out-of-tree drivers, with the proper documentation updates. also, where is the mediaindexdocs target defined? Thanks for noticing it. We don't need this target anymore. I'll write a patch removing it. This patch should remove the undesired noise. commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1 Author: Mauro Carvalho Chehab mche...@redhat.com Date: Thu Jun 9 16:34:29 2011 -0300 [media] DocBook: Don't be noisy at make cleanmediadocs While here, remove the mediaindexdocs from PHONY. Reported-by: Randy Dunlap randy.dun...@oracle.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 1e909c2..b7627e1 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -21,10 +21,10 @@ MEDIA_TEMP = media-entities.tmpl \ IMGFILES := $(addprefix $(MEDIA_OBJ_DIR)/media/, $(notdir $(shell ls $(MEDIA_SRC_DIR)/*/*.gif $(MEDIA_SRC_DIR)/*/*.png))) GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP)) -PHONY += cleanmediadocs mediaindexdocs +PHONY += cleanmediadocs cleanmediadocs: - -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(IMGFILES) + -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(IMGFILES) 2/dev/null $(obj)/media_api.xml: $(GENFILES) FORCE -- 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
TechniSat SkyStar S2 / CX24120-13Z again
Hello list, I'd like to bring up the discussion about the TechniSat SkyStar S2 PCI DVB-S2 card again. It has been asked once here: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/20733 but was never answered. Information can be found here: http://linuxtv.org/wiki/index.php/TechniSat_SkyStar_S2 There is the mentioned binary driver. And s.o. made a patch against DVB s2-liplianin (http://mercurial.intuxication.org/hg/s2-liplianin/) that adds support for the CX24120. It's not exactly a patch but a run-file with script-header and a tar-archive that extracts the patch and applies it directly. Until linux 2.6.39 I patched the s2-liplianin with the patch (extracted manually) and compiled the driver as module. This worked fine until 2.6.39 where the Big kernel lock (BKL) was dropped. Since then, the s2-liplianin doesn't compile anymore (not related to the CX24120-patch). Is the any chance to get it into mainline? Is there anything I can do but testing? Prepare a patch against mainline with everything needed to get the SkyStar S2 running? Best regards, Jannis -- 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: linux-next: Tree for June 8 (docbook/media)
On 06/09/11 12:43, Mauro Carvalho Chehab wrote: Em 09-06-2011 16:25, Mauro Carvalho Chehab escreveu: Em 08-06-2011 16:52, Randy Dunlap escreveu: The DocBook/media/Makefile seems to be causing too much noise: ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.gif: No such file or directory ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.png: No such file or directory Maybe the cleanmediadocs target could be made silent? I'll take a look on it. FYI, The next build will probably be noisier, as it is now pointing to some documentation gaps at the DVB API. Those gaps should take a longer time to fix, as we need to discuss upstream about what should be done with those API's, that seems to be abandoned upstream (only one legacy DVB driver uses them). However, I was told that some out-of-tree drivers and some drivers under development are using them. So, I intend to wait until the next merge window before either dropping those legacy API specs (or moving them to a deprecated section) or to merge those out-of-tree drivers, with the proper documentation updates. also, where is the mediaindexdocs target defined? Thanks for noticing it. We don't need this target anymore. I'll write a patch removing it. This patch should remove the undesired noise. Doesn't work for me. Did you test it? Even this does not silence the noise for me: cleanmediadocs: -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(IMGFILES) /dev/null 21 commit 75125b9d44456e0cf2d1fbb72ae33c13415299d1 Author: Mauro Carvalho Chehab mche...@redhat.com Date: Thu Jun 9 16:34:29 2011 -0300 [media] DocBook: Don't be noisy at make cleanmediadocs While here, remove the mediaindexdocs from PHONY. Reported-by: Randy Dunlap randy.dun...@oracle.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 1e909c2..b7627e1 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -21,10 +21,10 @@ MEDIA_TEMP = media-entities.tmpl \ IMGFILES := $(addprefix $(MEDIA_OBJ_DIR)/media/, $(notdir $(shell ls $(MEDIA_SRC_DIR)/*/*.gif $(MEDIA_SRC_DIR)/*/*.png))) GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP)) -PHONY += cleanmediadocs mediaindexdocs +PHONY += cleanmediadocs cleanmediadocs: - -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(IMGFILES) + -@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(IMGFILES) 2/dev/null $(obj)/media_api.xml: $(GENFILES) FORCE -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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] [media] lirc_zilog: fix spinning rx thread
Jarod Wilson ja...@redhat.com wrote:
We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced
in
commit 5bd6b0464b68d429bc8a3fe6595d19c39dfc4d95, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included
in,
but alas, stuff happens...
CC: Andy Walls awa...@md.metrocast.net
CC: sta...@kernel.org
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/staging/lirc/lirc_zilog.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index dd6a57c..4e051f6 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -475,14 +475,14 @@ static int lirc_thread(void *arg)
dprintk(poll thread started\n);
while (!kthread_should_stop()) {
+ set_current_state(TASK_INTERRUPTIBLE);
+
/* if device not opened, we can sleep half a second */
if (atomic_read(ir-open_count) == 0) {
schedule_timeout(HZ/2);
continue;
}
- set_current_state(TASK_INTERRUPTIBLE);
-
/*
* This is ~113*2 + 24 + jitter (2*repeat gap + code length).
* We use this interval as the chip resets every time you poll
--
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
Acked-by: Andy Walls awa...@md.metrocast.net
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TechniSat SkyStar S2 / CX24120-13Z again
Jannis Achstetter jannis_achstetter at web.de wrote: [...] There is the mentioned binary driver. And s.o. made a patch against DVB s2-liplianin (http://mercurial.intuxication.org/hg/s2-liplianin/) that adds support for the CX24120. It's not exactly a patch but a run-file with script-header and a tar-archive that extracts the patch and applies it directly. What I forgot: The run-file can be found here: http://linuxdvb.org.ru/wbb/index.php?page=ThreadpostID=16141#post16141 Right now I tried for the first time to apply this patch directly to the mainline linux 2.6.39.1. With some offsets, the patch applied fine and I had the frontend in menuconfig. Compiling throws two warnings but finishes okay. I can't test functionality right now since I'm not at home where the device is but I will test first thing when I get home. Jannis -- 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 4/4] XC4000: removed card_type
On Monday 06 June 2011 22:10:22 you wrote: Please solve the firmware issue before the next merge window. I have already received the Xceive firmware source and the program that builds the firmware for the Linux driver from Devin Heitmueller, and have sent back to him a modified version that builds the complete firmware (including the analog standards) yesterday. If this version does not have bugs, the firmware should be available soon. -- 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
XC5000 and MB86A20S
Hi I'm trying to run the X8507 MyGica plate, as I said in another post. I notice that when I try to tune a channel, the frequency of the XC5000 is different from the central carrier as I would expect to happen. Is this normal? Can someone tell me where is the documentation of the XC5000 and MB86A20S. Below are the results I get. Thanks in advance Alfredo alfredo@linux:~ mplayer -dumpstream dvb://'Encuentro' -dumpfile mplayer-dumpfile.ts MPlayer dev-SVN-r33321-4.5-openSUSE Linux 11.4 (x86_64)-Packman (C) 2000-2011 MPlayer Team Can't open joystick device /dev/input/js0: No such file or directory Can't init input joystick mplayer: could not open config files /home/alfredo/.lircrc and /etc/lirc/lircrc mplayer: No such file or directory Failed to read LIRC config file ~/.lircrc. Loading extension-related profile 'vo.vdpau' Playing dvb://Encuentro. dvb_tune Freq: 521142857 dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 544 bytes dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 900 bytes dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 148 bytes dvb_streaming_read, attempt N. 6 failed with errno 0 when reading 1256 bytes dvb_streaming_read, attempt N. 5 failed with errno 0 when reading 1256 bytes dmesg: [ 2235.637152] mb86a20s: mb86a20s_initfe: [ 2235.722354] mb86a20s: mb86a20s_initfe: Initialization succeeded. [ 2235.722704] xc5000: xc5000_init() [ 2235.723435] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388 [ 2235.723437] xc5000: xc_initialize() [ 2235.963737] xc5000: *** ADC envelope (0-1023) = 152 [ 2235.964451] xc5000: *** Frequency error = 62 Hz [ 2235.965163] xc5000: *** Lock status (0-Wait, 1-Locked, 2-No-signal) = 2 [ 2235.966642] xc5000: *** HW: V03.02, FW: V01.06.0072 [ 2235.967376] xc5000: *** Horizontal sync frequency = 16526 Hz [ 2235.968088] xc5000: *** Frame lines = 570 [ 2235.968851] xc5000: *** Quality (0:8dB, 7:56dB) = 0 [ 2236.069395] mb86a20s: mb86a20s_set_frontend: [ 2236.069749] mb86a20s: mb86a20s_set_frontend: Calling tuner set parameters [ 2236.070487] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388 [ 2236.070493] xc5000: xc5000_set_params() frequency=521142857 (Hz) [ 2236.070497] xc5000: xc5000_set_params() OFDM [ 2236.070501] xc5000: xc5000_set_params() frequency=519392857 (compensated) [ 2236.070505] xc5000: xc_SetSignalSource(0) Source = ANTENNA [ 2236.071793] xc5000: xc_SetTVStandard(0x8002,0x00c0) [ 2236.071796] xc5000: xc_SetTVStandard() Standard = DTV6 [ 2236.081039] xc5000: xc_set_IF_frequency(freq_khz = 3300) freq_code = 0xd33 [ 2236.089762] xc5000: xc_tune_channel(519392857) [ 2236.089764] xc5000: xc_set_RF_frequency(519392857) [ 2236.342767] xc5000: *** ADC envelope (0-1023) = 932 [ 2236.343502] xc5000: *** Frequency error = 0 Hz [ 2236.344204] xc5000: *** Lock status (0-Wait, 1-Locked, 2-No-signal) = 1 [ 2236.345670] xc5000: *** HW: V03.02, FW: V01.06.0072 [ 2236.346399] xc5000: *** Horizontal sync frequency = 15404 Hz [ 2236.347129] xc5000: *** Frame lines = 65535 [ 2236.347925] xc5000: *** Quality (0:8dB, 7:56dB) = 1 [ 2236.350019] mb86a20s: mb86a20s_read_status: [ 2236.351208] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01 [ 2236.361292] mb86a20s: mb86a20s_read_status: [ 2236.362471] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01 [ 2236.372549] mb86a20s: mb86a20s_read_status: [ 2236.373716] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01 [ 2236.383789] mb86a20s: mb86a20s_read_status: [ 2236.384970] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01 [ 2236.395049] mb86a20s: mb86a20s_read_status: [ 2236.396235] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01 [ 2236.400035] mb86a20s: mb86a20s_read_status: [ 2236.401226] mb86a20s: mb86a20s_read_status: val = 2, status = 0x01 [ 2236.401233] mb86a20s: mb86a20s_set_frontend: [ 2236.401581] mb86a20s: mb86a20s_set_frontend: Calling tuner set parameters [ 2236.402298] xc5000: xc5000_is_firmware_loaded() returns True id = 0x1388 [ 2236.402303] xc5000: xc5000_set_params() frequency=521267857 (Hz) [ 2236.402306] xc5000: xc5000_set_params() OFDM [ 2236.402310] xc5000: xc5000_set_params() frequency=519517857 (compensated) [ 2236.402314] xc5000: xc_SetSignalSource(0) Source = ANTENNA [ 2236.403608] xc5000: xc_SetTVStandard(0x8002,0x00c0) [ 2236.403611] xc5000: xc_SetTVStandard() Standard = DTV6 [ 2236.412019] xc5000: xc_set_IF_frequency(freq_khz = 3300) freq_code = 0xd33 [ 2236.420733] xc5000: xc_tune_channel(519517857) [ 2236.420735] xc5000: xc_set_RF_frequency(519517857) [ 2236.625772] xc5000: *** ADC envelope (0-1023) = 896 [ 2236.626507] xc5000: *** Frequency error = 0 Hz [ 2236.627241] xc5000: *** Lock status (0-Wait, 1-Locked, 2-No-signal) = 1 [ 2236.628709] xc5000: *** HW: V03.02, FW: V01.06.0072 [ 2236.629443] xc5000: *** Horizontal sync frequency = 15641 Hz [ 2236.630178] xc5000: *** Frame lines = 65535 [
Re: [PATCH] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Hi, Kassey, I've been looking at the driver some to understand how you're using the hardware. One quick question: The driver is based on soc-camera + videobuf2 frame work, and only USERPTR is supported. Since you're limited to contiguous DMA (does the PXA910 even support scatter/gather mode?), USERPTR is going to be very limiting. Is the application mapping I/O memory elsewhere in the system with the expectation of having the video frames go directly there? Could you tell me how that works? I'd like to understand the use case here. FWIW, I believe that videobuf2 would support the MMAP mode with no additional effort on your part; any reason why you haven't enabled that? Thanks, 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
videobuf2 and VMAs
Hi, I'm finally getting around to trying to really understand videobuf2. In the process I've run into something which has thrown me for a bit of a loop... /** * vb2_get_vma() - acquire and lock the virtual memory area * @vma:given virtual memory area * * This function attempts to acquire an area mapped in the userspace for * the duration of a hardware operation. The area is locked by performing * the same set of operation that are done when process calls fork() and * memory areas are duplicated. * * Returns a copy of a virtual memory region on success or NULL. */ This function makes a copy of the VMA which is completely outside of the knowledge of the mm subsystem. For the life of me, I cannot figure out why that is a wise or necessary thing to do. You are not locking the real VMA in any way. If you're worried about the underlying pages going away somehow, this will not save you. User space can still munmap() the space whenever it feels like it. This kind of operation, it seems, should really be done with get_user_pages(). Except that it seems that you're not really expecting user pages here - it looks like this is an attempt to support memory belonging to a different device which has been mapped into the process's address space? That might be a nice thing to try to document here. If you're worried about the file being closed, it might be better to save a reference directly. But having fake VMAs floating around worries me. Moving on: /** * vb2_get_contig_userptr() - lock physically contiguous userspace mapped memory * @vaddr: starting virtual address of the area to be verified * @size: size of the area * @res_paddr: will return physical address for the given vaddr * @res_vma:will return locked copy of struct vm_area for the given area * * This function will go through memory area of size @size mapped at @vaddr and * verify that the underlying physical pages are contiguous. If they are * contiguous the virtual memory area is locked and a @res_vma is filled with * the copy and @res_pa set to the physical address of the buffer. [...] Since we've determined that you're expecting this buffer to be in somebody's device memory, the loop through the whole thing seems like a bit much. Testing the VMA flags for VM_IO and !VM_NONLINEAR seems like it should suffice? Or am I missing something? (FWIW, user space could conceivably create a contiguous buffer in anonymous memory by using hugepages. The current videobuf2 code won't support that - follow_pfn() will fail. Probably not going to be an issue anytime in the near future, but one never knows...) Thanks, 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: linux-next: Tree for June 8 (docbook/media)
Em 09-06-2011 17:32, Randy Dunlap escreveu: On 06/09/11 12:43, Mauro Carvalho Chehab wrote: Em 09-06-2011 16:25, Mauro Carvalho Chehab escreveu: Em 08-06-2011 16:52, Randy Dunlap escreveu: The DocBook/media/Makefile seems to be causing too much noise: ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.gif: No such file or directory ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.png: No such file or directory Maybe the cleanmediadocs target could be made silent? I'll take a look on it. FYI, The next build will probably be noisier, as it is now pointing to some documentation gaps at the DVB API. Those gaps should take a longer time to fix, as we need to discuss upstream about what should be done with those API's, that seems to be abandoned upstream (only one legacy DVB driver uses them). However, I was told that some out-of-tree drivers and some drivers under development are using them. So, I intend to wait until the next merge window before either dropping those legacy API specs (or moving them to a deprecated section) or to merge those out-of-tree drivers, with the proper documentation updates. also, where is the mediaindexdocs target defined? Thanks for noticing it. We don't need this target anymore. I'll write a patch removing it. This patch should remove the undesired noise. Doesn't work for me. Did you test it? Yes: $ make htmldocs GEN /home/v4l/v4l/patchwork/Documentation/DocBook//v4l2.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//media-entities.tmpl GEN /home/v4l/v4l/patchwork/Documentation/DocBook//media-indices.tmpl GEN /home/v4l/v4l/patchwork/Documentation/DocBook//videodev2.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//audio.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//ca.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//dmx.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//frontend.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//net.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//video.h.xml DOCPROC Documentation/DocBook/media_api.xml HTMLDocumentation/DocBook/media_api.html Error: no ID for constraint linkend: AUDIO_GET_PTS. Error: no ID for constraint linkend: AUDIO_BILINGUAL_CHANNEL_SELECT. Error: no ID for constraint linkend: CA_RESET. Error: no ID for constraint linkend: CA_GET_CAP. Error: no ID for constraint linkend: CA_GET_SLOT_INFO. Error: no ID for constraint linkend: CA_GET_DESCR_INFO. Error: no ID for constraint linkend: CA_GET_MSG. Error: no ID for constraint linkend: CA_SEND_MSG. Error: no ID for constraint linkend: CA_SET_DESCR. Error: no ID for constraint linkend: CA_SET_PID. Error: no ID for constraint linkend: DMX_GET_PES_PIDS. Error: no ID for constraint linkend: DMX_GET_CAPS. Error: no ID for constraint linkend: DMX_SET_SOURCE. Error: no ID for constraint linkend: DMX_ADD_PID. Error: no ID for constraint linkend: DMX_REMOVE_PID. Error: no ID for constraint linkend: NET_ADD_IF. Error: no ID for constraint linkend: NET_REMOVE_IF. Error: no ID for constraint linkend: NET_GET_IF. Error: no ID for constraint linkend: VIDEO_GET_SIZE. Error: no ID for constraint linkend: VIDEO_GET_FRAME_RATE. Error: no ID for constraint linkend: VIDEO_GET_PTS. Error: no ID for constraint linkend: VIDEO_GET_FRAME_COUNT. Error: no ID for constraint linkend: VIDEO_COMMAND. Error: no ID for constraint linkend: VIDEO_TRY_COMMAND. rm -rf Documentation/DocBook/index.html; echo 'h1Linux Kernel HTML Documentation/h1' Documentation/DocBook/index.html echo 'h2Kernel Version: 3.0.0-rc1/h2' Documentation/DocBook/index.html cat Documentation/DocBook/80211.html Documentation/DocBook/alsa-driver-api.html Documentation/DocBook/debugobjects.html Documentation/DocBook/device-drivers.html Documentation/DocBook/deviceiobook.html Documentation/DocBook/drm.html Documentation/DocBook/filesystems.html Documentation/DocBook/gadget.html Documentation/DocBook/genericirq.html Documentation/DocBook/kernel-api.html Documentation/DocBook/kernel-hacking.html Documentation/DocBook/kernel-locking.html Documentation/DocBook/kgdb.html Documentation/DocBook/libata.html Documentation/DocBook/librs.html Documentation/DocBook/lsm.html Documentation/DocBook/mcabook.html Documentation/DocBook/media_api.html Documentation/DocBook/mtdnand.html Documentation/DocBook/networking.html Documentation/DocBook/rapidio.html Docum entation/DocBook/regulator.html Documentation/DocBook/s390-drivers.html Documentation/DocBook/scsi.html Documentation/DocBook/sh.html Documentation/DocBook/tracepoint.html Documentation/DocBook/uio-howto.html Documentation/DocBook/usb.html Documentation/DocBook/writing-an-alsa-driver.html Documentation/DocBook/writing_usb_driver.html Documentation/DocBook/z8530book.html Documentation/DocBook/index.html v4l@pedra ~/v4l/patchwork $ make cleandocs make[1]: [cleanmediadocs] Erro 1
Re: linux-next: Tree for June 8 (docbook/media)
On 06/09/11 16:32, Mauro Carvalho Chehab wrote: Em 09-06-2011 17:32, Randy Dunlap escreveu: On 06/09/11 12:43, Mauro Carvalho Chehab wrote: Em 09-06-2011 16:25, Mauro Carvalho Chehab escreveu: Em 08-06-2011 16:52, Randy Dunlap escreveu: The DocBook/media/Makefile seems to be causing too much noise: ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.gif: No such file or directory ls: cannot access linux-next-20110608/Documentation/DocBook/media/*/*.png: No such file or directory Maybe the cleanmediadocs target could be made silent? I'll take a look on it. FYI, The next build will probably be noisier, as it is now pointing to some documentation gaps at the DVB API. Those gaps should take a longer time to fix, as we need to discuss upstream about what should be done with those API's, that seems to be abandoned upstream (only one legacy DVB driver uses them). However, I was told that some out-of-tree drivers and some drivers under development are using them. So, I intend to wait until the next merge window before either dropping those legacy API specs (or moving them to a deprecated section) or to merge those out-of-tree drivers, with the proper documentation updates. also, where is the mediaindexdocs target defined? Thanks for noticing it. We don't need this target anymore. I'll write a patch removing it. This patch should remove the undesired noise. Doesn't work for me. Did you test it? Yes: $ make htmldocs GEN /home/v4l/v4l/patchwork/Documentation/DocBook//v4l2.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//media-entities.tmpl GEN /home/v4l/v4l/patchwork/Documentation/DocBook//media-indices.tmpl GEN /home/v4l/v4l/patchwork/Documentation/DocBook//videodev2.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//audio.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//ca.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//dmx.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//frontend.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//net.h.xml GEN /home/v4l/v4l/patchwork/Documentation/DocBook//video.h.xml DOCPROC Documentation/DocBook/media_api.xml HTMLDocumentation/DocBook/media_api.html Error: no ID for constraint linkend: AUDIO_GET_PTS. Error: no ID for constraint linkend: AUDIO_BILINGUAL_CHANNEL_SELECT. Error: no ID for constraint linkend: CA_RESET. Error: no ID for constraint linkend: CA_GET_CAP. Error: no ID for constraint linkend: CA_GET_SLOT_INFO. Error: no ID for constraint linkend: CA_GET_DESCR_INFO. Error: no ID for constraint linkend: CA_GET_MSG. Error: no ID for constraint linkend: CA_SEND_MSG. Error: no ID for constraint linkend: CA_SET_DESCR. Error: no ID for constraint linkend: CA_SET_PID. Error: no ID for constraint linkend: DMX_GET_PES_PIDS. Error: no ID for constraint linkend: DMX_GET_CAPS. Error: no ID for constraint linkend: DMX_SET_SOURCE. Error: no ID for constraint linkend: DMX_ADD_PID. Error: no ID for constraint linkend: DMX_REMOVE_PID. Error: no ID for constraint linkend: NET_ADD_IF. Error: no ID for constraint linkend: NET_REMOVE_IF. Error: no ID for constraint linkend: NET_GET_IF. Error: no ID for constraint linkend: VIDEO_GET_SIZE. Error: no ID for constraint linkend: VIDEO_GET_FRAME_RATE. Error: no ID for constraint linkend: VIDEO_GET_PTS. Error: no ID for constraint linkend: VIDEO_GET_FRAME_COUNT. Error: no ID for constraint linkend: VIDEO_COMMAND. Error: no ID for constraint linkend: VIDEO_TRY_COMMAND. rm -rf Documentation/DocBook/index.html; echo 'h1Linux Kernel HTML Documentation/h1' Documentation/DocBook/index.html echo 'h2Kernel Version: 3.0.0-rc1/h2' Documentation/DocBook/index.html cat Documentation/DocBook/80211.html Documentation/DocBook/alsa-driver-api.html Documentation/DocBook/debugobjects.html Documentation/DocBook/device-drivers.html Documentation/DocBook/deviceiobook.html Documentation/DocBook/drm.html Documentation/DocBook/filesystems.html Documentation/DocBook/gadget.html Documentation/DocBook/genericirq.html Documentation/DocBook/kernel-api.html Documentation/DocBook/kernel-hacking.html Documentation/DocBook/kernel-locking.html Documentation/DocBook/kgdb.html Documentation/DocBook/libata.html Documentation/DocBook/librs.html Documentation/DocBook/lsm.html Documentation/DocBook/mcabook.html Documentation/DocBook/media_api.html Documentation/DocBook/mtdnand.html Documentation/DocBook/networking.html Documentation/DocBook/rapidio.html Doc um entation/DocBook/regulator.html Documentation/DocBook/s390-drivers.html Documentation/DocBook/scsi.html Documentation/DocBook/sh.html Documentation/DocBook/tracepoint.html Documentation/DocBook/uio-howto.html Documentation/DocBook/usb.html Documentation/DocBook/writing-an-alsa-driver.html Documentation/DocBook/writing_usb_driver.html
USB mini-summit at LinuxCon Vancouver
I'm pleased to announce a USB mini-summit at LinuxCon Vancouver. What: USB mini-summit When: Tuesday, August 16th, all day Where: At the conference venue, room TBD pending confirmation from Angela Brown. Proposed topics include USB virtualization, and improved bandwidth APIs between the USB core and drivers (especially webcam drivers). See the detailed topic list below. Anyone is also welcome to propose or show up with a USB related topic. MUSB? USB 3.0 gadget drivers? USB-IP? The USB mini-summit does overlap with the virtualization mini-summit by a day, but I'm hoping we can schedule talks so some of the virtualization folks can make it to the USB mini-summit. The other option was on Friday during the conference which was not ideal. Proposed topics: Topic 1 --- The KVM folks suggested that it would be good to get USB and virtualization developers together to talk about how to virtualize the xHCI host controller. The xHCI spec architect worked closely with VMWare to get some extra goodies in the spec to help virtualization, and I'd like to see the other virtualization developers take advantage of that. I'd also like us to hash out any issues they have been finding in the USB core or xHCI driver during the virtualization effort. Topic 2 --- I'd also like to get the V4L and audio developers who work with USB devices together with the core USB folks to talk about bandwidth management under xHCI. One of the issues is that since the xHCI hardware does bandwidth management, not the xHCI driver, a schedule that will take too much bandwidth will get rejected much sooner than any USB driver currently expects (during a call to usb_set_interface). This poses issues, since most USB video drivers negotiate the video size and frame rate after they call usb_set_interface, so they don't know whether they can fall back to a less bandwidth-intensive setting. Currently, they just submit URBs with less and less bandwidth until one interval setting gets accepted that won't work under xHCI. A second issue is that that some drivers need less bandwidth than the device advertises, and the xHCI driver currently uses whatever periodic interval the device advertises in its descriptors. This is not what the video/audio driver wants, especially in the case of buggy high speed devices that advertise the interval in frames, not microframes. There needs to be some way for the drivers to communicate their bandwidth needs to the USB core. We've known about this issue for a while, and I think it's time to get everyone in the same room and hash out an API. (I will send out an API proposal later this month.) Hope to see you there! Sarah Sharp -- 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: USB mini-summit at LinuxCon Vancouver
On Thu, Jun 09, 2011 at 05:21:03PM -0700, Sarah Sharp wrote: Topic 1 --- The KVM folks suggested that it would be good to get USB and virtualization developers together to talk about how to virtualize the xHCI host controller. The xHCI spec architect worked closely with VMWare to get some extra goodies in the spec to help virtualization, and I'd like to see the other virtualization developers take advantage of that. I'd also like us to hash out any issues they have been finding in the USB core or xHCI driver during the virtualization effort. Do people really want to virtualize the whole xHCI controller, or just specific ports or devices to the guest operating system? If just specific ports, would something like usbip be better for virtual machines, with the USB traffic going over the network connection between the guest/host? Hope to see you there! Thanks for putting this together. Do we need to sign up somewhere to give the organizers a sense of how many people will be attending? 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
