Re: [PATCH for 3.2 URGENT] gspca: Fix bulk mode cameras no longer working (regression fix)
Hi, On 12/31/2011 08:08 PM, Theodore Kilgore wrote: snip Jean-Francois, Hans, Without addressing finer points, please let me add the following: 1. I figured out what was holding me back from getting 3.2 to work (it was a config error, apparently originating between keyboard and chair). 2. Based upon my testing today, something like this patch is clearly necessary. Namely, I tested a mass storage camera. Without this patch it would not stream. When I applied the patch, it did. Therefore, I hope very much that the problem which occasioned this patch gets fixed. No worries, this patch has already found its way into Linus' tree. 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: [PULL] soc-camera for 3.3
Hi Guennadi, On 29 December 2011 09:38, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Mauro Please pull a couple of soc-camera patches for 3.3. This is going to be a _much_ quieter pull, than the previous one:-) I didn't have time to continue the work on the soc-camera Media Controller conversion, so, that will have to wait at least until 3.4. Interestingly, Javier Martin has fixed field_count handling in mx2_camera, but, apparently, it also has to be fixed in other soc-camera drivers. So, a patch for that might follow later in the 3.3 cycle. The following changes since commit 1a5cd29631a6b75e49e6ad8a770ab9d69cda0fa2: [media] tda10021: Add support for DVB-C Annex C (2011-12-20 14:01:08 -0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.3 Guennadi Liakhovetski (4): V4L: soc-camera: remove redundant parameter from the .set_bus_param() method V4L: mt9m111: cleanly separate register contexts V4L: mt9m111: power down most circuits when suspended V4L: mt9m111: properly implement .s_crop and .s_fmt(), reset on STREAMON Javier Martin (2): media i.MX27 camera: add support for YUV420 format. media i.MX27 camera: Fix field_count handling. So, you already applied my patch related to field_count handling. I was preparing a v3 for that patch to fix the frame_count type issue and to really provide frame loss detection but I can prepare it on top of the old one if you want. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] soc-camera for 3.3
Hi Javier On Mon, 2 Jan 2012, javier Martin wrote: Hi Guennadi, On 29 December 2011 09:38, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Mauro Please pull a couple of soc-camera patches for 3.3. This is going to be a _much_ quieter pull, than the previous one:-) I didn't have time to continue the work on the soc-camera Media Controller conversion, so, that will have to wait at least until 3.4. Interestingly, Javier Martin has fixed field_count handling in mx2_camera, but, apparently, it also has to be fixed in other soc-camera drivers. So, a patch for that might follow later in the 3.3 cycle. The following changes since commit 1a5cd29631a6b75e49e6ad8a770ab9d69cda0fa2: [media] tda10021: Add support for DVB-C Annex C (2011-12-20 14:01:08 -0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.3 Guennadi Liakhovetski (4): V4L: soc-camera: remove redundant parameter from the .set_bus_param() method V4L: mt9m111: cleanly separate register contexts V4L: mt9m111: power down most circuits when suspended V4L: mt9m111: properly implement .s_crop and .s_fmt(), reset on STREAMON Javier Martin (2): media i.MX27 camera: add support for YUV420 format. media i.MX27 camera: Fix field_count handling. So, you already applied my patch related to field_count handling. I was preparing a v3 for that patch to fix the frame_count type issue and to really provide frame loss detection but I can prepare it on top of the old one if you want. Yes, the type issue is not that severe. Matching a type of another variable or a struct field, with which this variable is connected, is a valid reason, so, we can keep u32, if you like. As for frame loss detection - yes, please, provide it as an incremental patch. 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
[PATCH] media i.MX27 camera: properly detect frame loss.
As V4L2 specification states, frame_count must also
regard lost frames so that the user can handle that
case properly.
This patch adds a mechanism to increment the frame
counter even when a video buffer is not available
and a discard buffer is used.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 54 --
1 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index ca76dd2..b244714 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -256,6 +256,7 @@ struct mx2_camera_dev {
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
u32 frame_count;
+ unsigned intfirstirq;
};
/* buffer for one video frame */
@@ -370,6 +371,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
pcdev-icd = icd;
pcdev-frame_count = 0;
+ pcdev-firstirq = 1;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -572,6 +574,7 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
struct soc_camera_host *ici =
to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
unsigned long flags;
@@ -584,6 +587,26 @@ static void mx2_videobuf_queue(struct videobuf_queue *vq,
list_add_tail(vb-queue, pcdev-capture);
if (mx27_camera_emma(pcdev)) {
+ if (prp-cfg.channel == 1) {
+ writel(PRP_CNTL_CH1EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH1_LEN |
+ PRP_CNTL_CH1BYP |
+ PRP_CNTL_CH1_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ } else {
+ writel(PRP_CNTL_CH2EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH2_LEN |
+ PRP_CNTL_CH2_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ }
goto out;
} else { /* cpu_is_mx25() */
u32 csicr3, dma_inten = 0;
@@ -747,16 +770,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
writel(pcdev-discard_buffer_dma,
pcdev-base_emma + PRP_DEST_RGB2_PTR);
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
-
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_SRC_FRAME_SIZE);
writel((icd-user_width 16) | icd-user_height,
@@ -784,15 +797,6 @@ static void mx27_camera_emma_buf_init(struct
soc_camera_device *icd,
pcdev-base_emma + PRP_SOURCE_CR_PTR);
}
- writel(PRP_CNTL_CH2EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH2_LEN |
- PRP_CNTL_CH2_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
-
writel((icd-user_width 16) | icd-user_height,
pcdev-base_emma + PRP_SRC_FRAME_SIZE);
@@ -1214,7 +1218,6 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
vb-state = state;
do_gettimeofday(vb-ts);
vb-field_count = pcdev-frame_count * 2;
- pcdev-frame_count++;
wake_up(vb-done);
}
@@ -1239,6 +1242,17 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
return;
}
+ /*
+* According to V4L2 specification, first valid sequence number must
+* be 0. However, by design the first received frame is written to the
+* discard buffer even when a video buffer is available. For that reason
+
Re: [PATCH v4 0/2] Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.
Hi, do you have any more concerns or comments on this patch? I can't find it in media_tree. Has it been merged somewhere else? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control
Hi,
On 12/28/2011 02:35 PM, Sylwester Nawrocki wrote:
On 12/28/2011 07:23 AM, HeungJun, Kim wrote:
It adds the new CID for setting White Balance Preset. This CID is provided as
menu type using the following items:
How about adding
V4L2_WHITE_BALANCE_PRESET_NONE or
V4L2_WHITE_BALANCE_PRESET_UNDEFINED
to this menu ? It might cover Manual Mode entry in pwc_auto_whitebal_qmenu.
Also it might be useful not only as a read-only item for applications,
when there are multiple means of setting up white balance supported by a
driver, i.e. blue/red balance, component gains, etc.
0 - V4L2_WHITE_BALANCE_INCANDESCENT,
1 - V4L2_WHITE_BALANCE_FLUORESCENT,
2 - V4L2_WHITE_BALANCE_DAYLIGHT,
3 - V4L2_WHITE_BALANCE_CLOUDY,
4 - V4L2_WHITE_BALANCE_SHADE,
I have been also investigating those white balance presets recently and
noticed
they're also needed for the pwc driver. Looking at
drivers/media/video/pwc/pwc-v4l2.c there is something like:
const char * const pwc_auto_whitebal_qmenu[] = {
Indoor (Incandescant Lighting) Mode,
Outdoor (Sunlight) Mode,
Indoor (Fluorescent Lighting) Mode,
Manual Mode,
Auto Mode,
NULL
};
Regards,
--
Sylwester Nawrocki
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MEM2MEM devices: how to handle sequence number?
Hi, i've just arrived the office after holidays and it seems you have agreed some solution to the sequence number issue. As I understand, for a case where there is 1:1 correspondence between input and output (which is my case) I should do the following: - keep an internal frame counter associated with the output queue. - return the frame number when the user calls VIDIOC_QBUF on the output. - pass the output frame number to the capture queue in a 1:1 basis So in my chain of three processed nodes each node has its own internal frame counter and frame loss should be checked at the video source. Is that OK? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: vb2: vmalloc-based allocator user pointer handling
Hi, what is the status of this patch? Did you finally merge it in any tree? I am willing to extend it so that it can support pfn mappings as soon as it's ready. Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] media: vb2: vmalloc-based allocator user pointer handling
Hello Javier, On Monday, January 02, 2012 11:45 AM You wrote: what is the status of this patch? Did you finally merge it in any tree? I am willing to extend it so that it can support pfn mappings as soon as it's ready. This patch has been merged to media-next kernel branch. You can download it here: http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.3 Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type
On 02-01-2012 05:31, Manu Abraham wrote: On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: This is likely the last patch series from my series of DVB cleanups. I still intend to work on DRX-K frontend merge patch, but this will need to wait until my return to my home town. Of course, if you're hurry with this, patches are welcome. This series changes dvb_frontend to use ops-delsys instead of ops-info.type, as the source for the frontend support. With this series: 1) the first delivery system is reported as info.type for DVBv3 apps; 2) all subsequent checks are made against the current delivery system (c-delivery_system); 3) An attempt to use an un-suported delivery system will either return an error, or enter into the emulation mode, if the frontend is using a newer delivery system. 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call shouldn't fill the DVBv3 structs. Still, as events are generated, the event will dynamically generate a DVBv3 compat struct. The emulation logic is not perfect (but it were not perfect before this patch series). The emulation will work worse for devices that have support for different ops-info.type, as there's no way for a DVBv3 application to work properly with those devices. TODO: There are a few things left to do, with regards to DVB frontend cleanup. They're more related to the DVBv5 API, so they were out of the scope of this series. Maybe some work for this upcoming year! They are: 1) Fix the capabilities flags. There are several capabilities not reported, like several modulations, etc. There are not enough flags for them. It was suggested that the delivery system (DTV_ENUM_DELSYS) would be enough, but it doesn't seem so. For example, there are several SYS_ATSC devices that only support VSB_8. So, we'll end by needing to either extend the current way (but we lack bits) or to implement a DVBv5 way for that; If an ATSC device supports fewer modulations, things should be even simpler. Just return INVALID Frontend setup if it is trying to setup something invalid, that which is not supported. Advertising the available modulations doesn't help in any sense. A53 spec talks about devices supporting 2 modes, Terrestrial mode and High data rate mode. It is unlikely and yet maybe some devices don't adhere to specifications supporting only 8VSB, but even in those cases, just returning -EINVAL would be sufficient for 16VSB. What you suggest, just adds confusion alone to applications as to what to do with all the exported fields/flags. Returning -EINVAL works from kernel POV, but at least one userpsace application developer sent me an email those days complaining that applications need to know what are the supported capabilities, in order to provide a proper userspace gui. 2) The DVBv3 events call (FE_GET_EVENT) is not ok for newer delivery system. We'll likely need to replace it by a DVBv5 way; It should be noted that there is no DVBv5 way, If you are implying to replace ioctl calls with a get/set interface, it doesn't make sense at all. By DVBv5 way, I'm meaning to say that it should be replaced by some way that allow reporting events not only for the 4 delivery systems supported by DVBv3 API. This could be as easy as adding a DTV_GET_EVENT command for FE_GET_PROPERTY. Alternatively, events could be reported via a poll() ops at the frontend node. 3) The stats API needs to be extended. Delivery systems like ISDB can report a per-layer set of statistics. This is currently not supported. Also, it is desirable to get the stats together with a set of other properties. The per layer statistics is a myth and can be ignored. Each of the layers are much higher above and simply RF/demodulation parameters don't exist/layer; Even if you argue that they do exist, it would be exactly sufficient to read stats after setting up the relevant layer for filtering (since you cannot read demodulation statistics, without setting up proper demodulation parameters). Take a look at: http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#isdb-hierq-layers Each layer has a group of OFDM carriers, each group have its own modulation, viterbi and red-salomon decoders. And all of them can be decoded simultaneously. So, the statistics for each layer will be different. That's said, I haven't seen any broadcaster using more than one layer yet, so, there's no pressure for adding such feature yet. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: tvp5150: Add mbus_fmt callbacks.
Hi Mauro, any more comments on this? Will you please merge the last version which includes the fixes you requested? Thank you. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MEM2MEM devices: how to handle sequence number?
Hi Javier, On Monday 02 January 2012 11:22:54 javier Martin wrote: Hi, i've just arrived the office after holidays and it seems you have agreed some solution to the sequence number issue. As I understand, for a case where there is 1:1 correspondence between input and output (which is my case) I should do the following: - keep an internal frame counter associated with the output queue. - return the frame number when the user calls VIDIOC_QBUF on the output. - pass the output frame number to the capture queue in a 1:1 basis That's right. So in my chain of three processed nodes each node has its own internal frame counter and frame loss should be checked at the video source. You can use an internal frame counter for each node if needed for internal operation, but that's not required from the userspace point of view. Is that OK? -- 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
Re: [RFC/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control
Hi Sylwester, On Sunday 01 January 2012 17:49:11 Sylwester Nawrocki wrote: On 12/31/2011 01:00 PM, Sakari Ailus wrote: On Sat, Dec 10, 2011 at 03:42:41PM +0100, Sylwester Nawrocki wrote: On 12/10/2011 11:33 AM, Sakari Ailus wrote: On Sun, Dec 04, 2011 at 04:16:12PM +0100, Sylwester Nawrocki wrote: Change the V4L2_CID_FOCUS_AUTO control type from boolean to a menu type. In case of boolean control we had values 0 and 1 corresponding to manual and automatic focus respectively. The V4L2_CID_FOCUS_AUTO menu control has currently following items: 0 - V4L2_FOCUS_MANUAL, 1 - V4L2_FOCUS_AUTO, 2 - V4L2_FOCUS_AUTO_MACRO, 3 - V4L2_FOCUS_AUTO_CONTINUOUS. I would put the macro mode to a separate menu since it's configuration for how the regular AF works rather than really different mode. Yes, makes sense. Most likely there could be also continuous macro auto focus.. I don't have yet an idea what could be a name for that new menu though. V4L2_CID_FOCUS_AUTO_DISTANCE? It could then have choices FULL or MACRO. How about V4L2_CID_FOCUS_AUTO_SCAN_RANGE ? Which would then have choices: NORMAL, MACRO, INFINITY ? Many Samsung devices have also something like guided auto focus, where the application can specify location in the frame for focusing on. IIRC this could be also single-shot or continuous. So it could make sense to group MACRO and guided auto focus in one menu, what do you think ? I think it could be a separate menu. It's not connected to the distance OK, let me summarize * controls for starting/stopping auto focusing (V4L2_CID_FOCUS_AUTO == false) V4L2_CID_START_AUTO_FOCUS (button) - start auto focusing, V4L2_CID_STOP_AUTO_FOCUS (button) - stop auto focusing (might be also useful in V4L2_FOCUS_AUTO == true), Maybe V4L2_CID_AUTO_FOCUS_START and V4L2_CID_AUTO_FOCUS_STOP to be consistent with the other proposed controls ? * auto focus status V4L2_CID_AUTO_FOCUS_STATUS (menu, read-only) - whether focusing is in progress or not, possible entries: - V4L2_AUTO_FOCUS_STATUS_IDLE,// auto focusing not enabled or force stopped - V4L2_AUTO_FOCUS_STATUS_BUSY,// focusing in progress - V4L2_AUTO_FOCUS_STATUS_SUCCESS, // single-shot auto focusing succeed // or continuous AF in progress - V4L2_AUTO_FOCUS_STATUS_FAIL,// auto focusing failed * V4L2_CID_FOCUS_AUTO would retain its current semantics: V4L2_CID_FOCUS_AUTO (boolean) - selects auto/manual focus false - manual true - auto continuous * AF algorithm scan range, V4L2_CID_FOCUS_AUTO_SCAN_RANGE with choices: - V4L2_AUTO_FOCUS_SCAN_RANGE_NORMAL, - V4L2_AUTO_FOCUS_SCAN_RANGE_MACRO, - V4L2_AUTO_FOCUS_SCAN_RANGE_INFINITY New menu control to choose behaviour of auto focus (either single-shot or continuous): * select auto focus mode V4L2_CID_AUTO_FOCUS_MODE V4L2_AUTO_FOCUS_MODE_NORMAL - normal auto focus (whole frame?) V4L2_AUTO_FOCUS_MODE_SPOT - spot location passed with other controls or selection API V4L2_AUTO_FOCUS_MODE_RECTANGLE - rectangle passed with other controls or selection API Soudns good to me. parameter. We also need to discuss how the af statistics window configuration is done. I'm not certain there could even be a standardised Do we need multiple windows for AF statistics ? If not, I'm inclined to use four separate controls for window configuration. (X, Y, WIDTH, HEIGHT). This was Hans' preference in previous discussions [1]. For the OMAP3 ISP we need multiple statistics windows. AEWB can use more than 32 windows. Having separate controls for that wouldn't be practical. interface which could be used to control it all. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg25647.html -- 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
Re: [PATCH 2/2] v4l2: add new pixel formats supported on dm365
Hi Sakari,
On Wednesday 28 December 2011 12:16:27 Sakari Ailus wrote:
On Wed, Dec 21, 2011 at 11:23:26PM +0100, Laurent Pinchart wrote:
On Wednesday 21 December 2011 14:56:36 Hadli, Manjunath wrote:
On Wed, Dec 21, 2011 at 05:32:08, Laurent Pinchart wrote:
On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer
format frames compressed by A-LAW alogorithm.
add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/videodev2.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
Could you please also document these formats in
Documentation/DocBook/media/v4l ?
I will. Sorry to have missed that out.
diff --git a/include/linux/videodev2.h
b/include/linux/videodev2.h index 4b752d5..969112d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -338,6 +338,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2')
/* 8 YUV
4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1
line uv interleaved */
+/* Chrominance formats */
+#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ')
/* 8 UV 4:4 */ +
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2')
/* 12 Y/CbCr
4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V',
'2', '1') /* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct
v4l2_pix_format { #define V4L2_PIX_FMT_SRGGB12
v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */ /*
10bit raw bayer DPCM compressed to 8 bits */ #define
V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+ /* 10bit raw bayer a-law compressed to 8 bits */ #define
+V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
+
That's not very future-proof, how would you describe SGBRG10ALAW8
for instance ?
Maybe it's time to standardize FOURCCs for Bayer new formats. We
have 4 characters, we could start with 'B' to denote Bayer,
followed by one character for the order, one for the
compression, and one for the number of bits.
I agree.
May be ('B', 'G', 'A', '8') is fine for the above?
We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use
'B', 'g', 'G' and 'R' respectively for the second character. The
third character would be 'A' for A-law and 'D' for DPCM, and the
fourth character could describe the bus width in bits from 0 to 15
with '0' - '9', 'A' - 'F'. However, I suspect that we will need
16-bit wide busses for raw Bayer at some point, and a 0 width is
definitely not useful. We could thus offset the width by some value.
This is just a preliminary idea, I'm open to suggestions.
I think it is a very good suggestion that we can go with.
B : BGGR
g : GBRG
G : GRBG
R : RGGB
and 0-F can signify 1-16.
Hans, Guennadi, Sakari, any opinion on that as well ?
I think four letters simply aren't enough to universally describe a media
bus format in a human-readable way. We can aim to that, but we will have to
make compromises.
For example, DPCM compressed format has two important parameters beyond
pixel order and the colour space, the uncompressed depth and the compressed
depth. Typically one doesn't compress the data too much, but things like
10-to-6 bits are well possible.
Could we use a single letter to tell that a format is both bayer and DPCM
compressed? I'd go for 'b'. Raw bayer alaw could be denoted by 'a'.
Then raw bayer, GBRG pixel order 10-to-7 bits would be called bgA7. The
same in Alaw would be agA7.
What do you think?
We can't come up with a naming scheme that will handle all possible
combinations. I'm fine as long as the names we select have some kind of
structure and handle the raw patterns currently available. I'd still like to
hear Hans' opinion on this.
--
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
Re: [PATCH 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type
On 02-01-2012 08:55, Mauro Carvalho Chehab wrote: On 02-01-2012 05:31, Manu Abraham wrote: On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: This is likely the last patch series from my series of DVB cleanups. I still intend to work on DRX-K frontend merge patch, but this will need to wait until my return to my home town. Of course, if you're hurry with this, patches are welcome. This series changes dvb_frontend to use ops-delsys instead of ops-info.type, as the source for the frontend support. With this series: 1) the first delivery system is reported as info.type for DVBv3 apps; 2) all subsequent checks are made against the current delivery system (c-delivery_system); 3) An attempt to use an un-suported delivery system will either return an error, or enter into the emulation mode, if the frontend is using a newer delivery system. 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call shouldn't fill the DVBv3 structs. Still, as events are generated, the event will dynamically generate a DVBv3 compat struct. The emulation logic is not perfect (but it were not perfect before this patch series). The emulation will work worse for devices that have support for different ops-info.type, as there's no way for a DVBv3 application to work properly with those devices. TODO: There are a few things left to do, with regards to DVB frontend cleanup. They're more related to the DVBv5 API, so they were out of the scope of this series. Maybe some work for this upcoming year! They are: 1) Fix the capabilities flags. There are several capabilities not reported, like several modulations, etc. There are not enough flags for them. It was suggested that the delivery system (DTV_ENUM_DELSYS) would be enough, but it doesn't seem so. For example, there are several SYS_ATSC devices that only support VSB_8. So, we'll end by needing to either extend the current way (but we lack bits) or to implement a DVBv5 way for that; If an ATSC device supports fewer modulations, things should be even simpler. Just return INVALID Frontend setup if it is trying to setup something invalid, that which is not supported. Advertising the available modulations doesn't help in any sense. A53 spec talks about devices supporting 2 modes, Terrestrial mode and High data rate mode. It is unlikely and yet maybe some devices don't adhere to specifications supporting only 8VSB, but even in those cases, just returning -EINVAL would be sufficient for 16VSB. What you suggest, just adds confusion alone to applications as to what to do with all the exported fields/flags. Returning -EINVAL works from kernel POV, but at least one userpsace application developer sent me an email those days complaining that applications need to know what are the supported capabilities, in order to provide a proper userspace gui. 2) The DVBv3 events call (FE_GET_EVENT) is not ok for newer delivery system. We'll likely need to replace it by a DVBv5 way; It should be noted that there is no DVBv5 way, If you are implying to replace ioctl calls with a get/set interface, it doesn't make sense at all. By DVBv5 way, I'm meaning to say that it should be replaced by some way that allow reporting events not only for the 4 delivery systems supported by DVBv3 API. This could be as easy as adding a DTV_GET_EVENT command for FE_GET_PROPERTY. Alternatively, events could be reported via a poll() ops at the frontend node. 3) The stats API needs to be extended. Delivery systems like ISDB can report a per-layer set of statistics. This is currently not supported. Also, it is desirable to get the stats together with a set of other properties. The per layer statistics is a myth and can be ignored. Each of the layers are much higher above and simply RF/demodulation parameters don't exist/layer; Even if you argue that they do exist, it would be exactly sufficient to read stats after setting up the relevant layer for filtering (since you cannot read demodulation statistics, without setting up proper demodulation parameters). Take a look at: http://linuxtv.org/downloads/v4l-dvb-apis/FE_GET_SET_PROPERTY.html#isdb-hierq-layers Each layer has a group of OFDM carriers, each group have its own modulation, viterbi and red-salomon decoders. And all of them can be decoded simultaneously. So, the statistics for each layer will be different. That's said, I haven't seen any broadcaster using more than one layer yet, so, there's no pressure for adding such feature yet. I spoke too early. I modified my dvbv5-zap tool[1] to show what's beeing detected by a dibcom 8000 frontend. [1] http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils Tuning into two different frequencies: $ ./dvbv5-zap globo\ hd using demug '/dev/dvb/adapter0/demux0' reading channels from file '/home/v4l/.tzap/channels.conf' Device
Re: MEM2MEM devices: how to handle sequence number?
Just one more question about this. The v4l2 encoder, which is the last element in my processing chain, is an H.264 encoder that has to know about previous frames to encode. For these kind of devices it is very useful to know whether a frame has been lost to introduce a skip frame and improve the encoding process. But, with the current approach we don't have any way to communicate this to the device. One option would be that the user specified a sequence number when issuing VIDIOC_QBUF at the output queue so that the device could detect any discontinuity and introduce a skip frame. But this would break your rule that sequence number introduced at the output queue has to be ignored by the driver. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type
On Mon, Jan 2, 2012 at 4:25 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: On 02-01-2012 05:31, Manu Abraham wrote: On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: This is likely the last patch series from my series of DVB cleanups. I still intend to work on DRX-K frontend merge patch, but this will need to wait until my return to my home town. Of course, if you're hurry with this, patches are welcome. This series changes dvb_frontend to use ops-delsys instead of ops-info.type, as the source for the frontend support. With this series: 1) the first delivery system is reported as info.type for DVBv3 apps; 2) all subsequent checks are made against the current delivery system (c-delivery_system); 3) An attempt to use an un-suported delivery system will either return an error, or enter into the emulation mode, if the frontend is using a newer delivery system. 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call shouldn't fill the DVBv3 structs. Still, as events are generated, the event will dynamically generate a DVBv3 compat struct. The emulation logic is not perfect (but it were not perfect before this patch series). The emulation will work worse for devices that have support for different ops-info.type, as there's no way for a DVBv3 application to work properly with those devices. TODO: There are a few things left to do, with regards to DVB frontend cleanup. They're more related to the DVBv5 API, so they were out of the scope of this series. Maybe some work for this upcoming year! They are: 1) Fix the capabilities flags. There are several capabilities not reported, like several modulations, etc. There are not enough flags for them. It was suggested that the delivery system (DTV_ENUM_DELSYS) would be enough, but it doesn't seem so. For example, there are several SYS_ATSC devices that only support VSB_8. So, we'll end by needing to either extend the current way (but we lack bits) or to implement a DVBv5 way for that; If an ATSC device supports fewer modulations, things should be even simpler. Just return INVALID Frontend setup if it is trying to setup something invalid, that which is not supported. Advertising the available modulations doesn't help in any sense. A53 spec talks about devices supporting 2 modes, Terrestrial mode and High data rate mode. It is unlikely and yet maybe some devices don't adhere to specifications supporting only 8VSB, but even in those cases, just returning -EINVAL would be sufficient for 16VSB. What you suggest, just adds confusion alone to applications as to what to do with all the exported fields/flags. Returning -EINVAL works from kernel POV, but at least one userpsace application developer sent me an email those days complaining that applications need to know what are the supported capabilities, in order to provide a proper userspace gui. FWIW, userapps shouldn't really bother about all the hardware details. If user application were to really bother about all the tiny intricacies (I can point out a large amount of tiny intricacies that which might sound pretty, as you are stating) then there wouldn't be the need for a driver API -- the application itself can contain the driver code. In short, providing too much information to application is also not nice. The user application should simply set the parameters and try to demodulate, return error if it cannot. Having unnecessary fields just causes confusion alone. I don't see how providing all the modulations under a delivery system can improve a GUI application especially when it is according to the specifications. 2) The DVBv3 events call (FE_GET_EVENT) is not ok for newer delivery system. We'll likely need to replace it by a DVBv5 way; It should be noted that there is no DVBv5 way, If you are implying to replace ioctl calls with a get/set interface, it doesn't make sense at all. By DVBv5 way, I'm meaning to say that it should be replaced by some way that allow reporting events not only for the 4 delivery systems supported by DVBv3 API. This could be as easy as adding a DTV_GET_EVENT command for FE_GET_PROPERTY. Alternatively, events could be reported via a poll() ops at the frontend node. I am unable to see the advantage in adding a new DTV_GET_EVENT call instead of FE_GET_PROPERTY improve anything at all. 3) The stats API needs to be extended. Delivery systems like ISDB can report a per-layer set of statistics. This is currently not supported. Also, it is desirable to get the stats together with a set of other properties. The per layer statistics is a myth and can be ignored. Each of the layers are much higher above and simply RF/demodulation parameters don't exist/layer; Even if you argue that they do exist, it would be exactly sufficient to read stats after setting up the relevant layer for filtering (since you cannot read demodulation
[PATCH] s5p-g2d: fixed a bug in controls setting function
Signed-off-by: Kamil Debski k.deb...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/s5p-g2d/g2d.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/s5p-g2d/g2d.c b/drivers/media/video/s5p-g2d/g2d.c index 1f156c8..22e15e5 100644 --- a/drivers/media/video/s5p-g2d/g2d.c +++ b/drivers/media/video/s5p-g2d/g2d.c @@ -184,6 +184,7 @@ static int g2d_s_ctrl(struct v4l2_ctrl *ctrl) ctx-rop = ROP4_INVERT; else ctx-rop = ROP4_COPY; + break; default: v4l2_err(ctx-dev-v4l2_dev, unknown control\n); return -EINVAL; -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media: vb2: support userptr for PFN mappings.
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/videobuf2-vmalloc.c | 66 +++---
1 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 03aa62f..5bc7cec 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -15,6 +15,7 @@
#include linux/sched.h
#include linux/slab.h
#include linux/vmalloc.h
+#include linux/io.h
#include media/videobuf2-core.h
#include media/videobuf2-memops.h
@@ -71,6 +72,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ unsigned long int physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +83,34 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr,
offset = vaddr ~PAGE_MASK;
buf-size = size;
- first = vaddr PAGE_SHIFT;
- last = (vaddr + size - 1) PAGE_SHIFT;
- buf-n_pages = last - first + 1;
- buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf-pages)
- goto fail_pages_array_alloc;
-
- /* current-mm-mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
- buf-n_pages, write, 1, /* force */
- buf-pages, NULL);
- if (n_pages != buf-n_pages)
- goto fail_get_user_pages;
-
- buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
- if (!buf-vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current-mm, vaddr);
+ if (vma (vma-vm_flags VM_IO) (vma-vm_pgoff)) {
+ physp = (vma-vm_pgoff PAGE_SHIFT) + (vaddr - vma-vm_start);
+ buf-vaddr = ioremap_nocache(physp, size);
+ if (!buf-vaddr)
+ goto fail_pages_array_alloc;
+ } else {
+ first = vaddr PAGE_SHIFT;
+ last = (vaddr + size - 1) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *),
+GFP_KERNEL);
+ if (!buf-pages)
+ goto fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current-mm,
+vaddr PAGE_MASK, buf-n_pages,
+write,1, /* force */
+buf-pages, NULL);
+ if (n_pages != buf-n_pages)
+ goto fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf-vaddr)
+ goto fail_get_user_pages;
+ }
buf-vaddr += offset;
return buf;
@@ -120,14 +134,18 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf-vaddr PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf-n_pages);
- for (i = 0; i buf-n_pages; ++i) {
- if (buf-write)
- set_page_dirty_lock(buf-pages[i]);
- put_page(buf-pages[i]);
+ if (buf-pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+ put_page(buf-pages[i]);
+ }
+ kfree(buf-pages);
+ } else {
+ iounmap(buf-vaddr);
}
- kfree(buf-pages);
kfree(buf);
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] uvcvideo: Allow userptr IO mode.
Userptr can be very useful if a UVC camera
is requested to use video buffers allocated
by another processing device. So that
buffers don't need to be copied.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/uvc/uvc_queue.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index 518f77d..8f54e24 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -126,7 +126,7 @@ void uvc_queue_init(struct uvc_video_queue *queue, enum
v4l2_buf_type type,
int drop_corrupted)
{
queue-queue.type = type;
- queue-queue.io_modes = VB2_MMAP;
+ queue-queue.io_modes = VB2_MMAP | VB2_USERPTR;
queue-queue.drv_priv = queue;
queue-queue.buf_struct_size = sizeof(struct uvc_buffer);
queue-queue.ops = uvc_queue_qops;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type
On Mon, Jan 2, 2012 at 8:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: On 02-01-2012 09:48, Manu Abraham wrote: On Mon, Jan 2, 2012 at 4:25 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: On 02-01-2012 05:31, Manu Abraham wrote: On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: This is likely the last patch series from my series of DVB cleanups. I still intend to work on DRX-K frontend merge patch, but this will need to wait until my return to my home town. Of course, if you're hurry with this, patches are welcome. This series changes dvb_frontend to use ops-delsys instead of ops-info.type, as the source for the frontend support. With this series: 1) the first delivery system is reported as info.type for DVBv3 apps; 2) all subsequent checks are made against the current delivery system (c-delivery_system); 3) An attempt to use an un-suported delivery system will either return an error, or enter into the emulation mode, if the frontend is using a newer delivery system. 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call shouldn't fill the DVBv3 structs. Still, as events are generated, the event will dynamically generate a DVBv3 compat struct. The emulation logic is not perfect (but it were not perfect before this patch series). The emulation will work worse for devices that have support for different ops-info.type, as there's no way for a DVBv3 application to work properly with those devices. TODO: There are a few things left to do, with regards to DVB frontend cleanup. They're more related to the DVBv5 API, so they were out of the scope of this series. Maybe some work for this upcoming year! They are: 1) Fix the capabilities flags. There are several capabilities not reported, like several modulations, etc. There are not enough flags for them. It was suggested that the delivery system (DTV_ENUM_DELSYS) would be enough, but it doesn't seem so. For example, there are several SYS_ATSC devices that only support VSB_8. So, we'll end by needing to either extend the current way (but we lack bits) or to implement a DVBv5 way for that; If an ATSC device supports fewer modulations, things should be even simpler. Just return INVALID Frontend setup if it is trying to setup something invalid, that which is not supported. Advertising the available modulations doesn't help in any sense. A53 spec talks about devices supporting 2 modes, Terrestrial mode and High data rate mode. It is unlikely and yet maybe some devices don't adhere to specifications supporting only 8VSB, but even in those cases, just returning -EINVAL would be sufficient for 16VSB. What you suggest, just adds confusion alone to applications as to what to do with all the exported fields/flags. Returning -EINVAL works from kernel POV, but at least one userpsace application developer sent me an email those days complaining that applications need to know what are the supported capabilities, in order to provide a proper userspace gui. FWIW, userapps shouldn't really bother about all the hardware details. If user application were to really bother about all the tiny intricacies (I can point out a large amount of tiny intricacies that which might sound pretty, as you are stating) then there wouldn't be the need for a driver API -- the application itself can contain the driver code. In short, providing too much information to application is also not nice. The user application should simply set the parameters and try to demodulate, return error if it cannot. -EINVAL could mean an error on any parameter, not just on modulation. This suggestion of FE_CAN_MODULATION_X/Y/Z just follows an earlier discussion about the FE_CAN_ bits where almost everyone came to the conclusion and eventually agreed that those are superfluous and such fine grained-ness is not useful. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] dvb_frontend: Don't rely on drivers filling ops-info.type
On Mon, Jan 2, 2012 at 8:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: On 02-01-2012 09:48, Manu Abraham wrote: On Mon, Jan 2, 2012 at 4:25 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: On 02-01-2012 05:31, Manu Abraham wrote: On Mon, Jan 2, 2012 at 1:41 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: This is likely the last patch series from my series of DVB cleanups. I still intend to work on DRX-K frontend merge patch, but this will need to wait until my return to my home town. Of course, if you're hurry with this, patches are welcome. This series changes dvb_frontend to use ops-delsys instead of ops-info.type, as the source for the frontend support. With this series: 1) the first delivery system is reported as info.type for DVBv3 apps; 2) all subsequent checks are made against the current delivery system (c-delivery_system); 3) An attempt to use an un-suported delivery system will either return an error, or enter into the emulation mode, if the frontend is using a newer delivery system. 4) Lots of cleanup at the cache sync logic. Now, a pure DVBv5 call shouldn't fill the DVBv3 structs. Still, as events are generated, the event will dynamically generate a DVBv3 compat struct. The emulation logic is not perfect (but it were not perfect before this patch series). The emulation will work worse for devices that have support for different ops-info.type, as there's no way for a DVBv3 application to work properly with those devices. TODO: There are a few things left to do, with regards to DVB frontend cleanup. They're more related to the DVBv5 API, so they were out of the scope of this series. Maybe some work for this upcoming year! They are: 1) Fix the capabilities flags. There are several capabilities not reported, like several modulations, etc. There are not enough flags for them. It was suggested that the delivery system (DTV_ENUM_DELSYS) would be enough, but it doesn't seem so. For example, there are several SYS_ATSC devices that only support VSB_8. So, we'll end by needing to either extend the current way (but we lack bits) or to implement a DVBv5 way for that; If an ATSC device supports fewer modulations, things should be even simpler. Just return INVALID Frontend setup if it is trying to setup something invalid, that which is not supported. Advertising the available modulations doesn't help in any sense. A53 spec talks about devices supporting 2 modes, Terrestrial mode and High data rate mode. It is unlikely and yet maybe some devices don't adhere to specifications supporting only 8VSB, but even in those cases, just returning -EINVAL would be sufficient for 16VSB. What you suggest, just adds confusion alone to applications as to what to do with all the exported fields/flags. Returning -EINVAL works from kernel POV, but at least one userpsace application developer sent me an email those days complaining that applications need to know what are the supported capabilities, in order to provide a proper userspace gui. FWIW, userapps shouldn't really bother about all the hardware details. If user application were to really bother about all the tiny intricacies (I can point out a large amount of tiny intricacies that which might sound pretty, as you are stating) then there wouldn't be the need for a driver API -- the application itself can contain the driver code. In short, providing too much information to application is also not nice. The user application should simply set the parameters and try to demodulate, return error if it cannot. -EINVAL could mean an error on any parameter, not just on modulation. Having unnecessary fields just causes confusion alone. I don't see how providing all the modulations under a delivery system can improve a GUI application especially when it is according to the specifications. 2) The DVBv3 events call (FE_GET_EVENT) is not ok for newer delivery system. We'll likely need to replace it by a DVBv5 way; It should be noted that there is no DVBv5 way, If you are implying to replace ioctl calls with a get/set interface, it doesn't make sense at all. By DVBv5 way, I'm meaning to say that it should be replaced by some way that allow reporting events not only for the 4 delivery systems supported by DVBv3 API. This could be as easy as adding a DTV_GET_EVENT command for FE_GET_PROPERTY. Alternatively, events could be reported via a poll() ops at the frontend node. I am unable to see the advantage in adding a new DTV_GET_EVENT call instead of FE_GET_PROPERTY improve anything at all. Huh? DTV_foo is the name of the properties used by FE_GET_PROPERTY. What I'm meaning is that: 1) in order to have just one ioctl providing both FE status and DTV properties, some new properties are needed there (status and likely stats); 2) It makes sense to have something that will only return to
[PATCH] [BUG] it913x ver 1.20. PID filter problems.
Fixes issues with PID filter
Stalling of some channels when PID is on.
PID filter not turning off fully.
PID filter can now turn on and off each index.
Removed PID_RST from it913x_pid_filter_ctrl.
Replaced with PID_EN removed from it913x_pid_filter
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/it913x.c | 22 +-
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index 8d1cfac..ad7013c 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -259,15 +259,15 @@ static u32 it913x_query(struct usb_device *udev, u8 pro)
static int it913x_pid_filter_ctrl(struct dvb_usb_adapter *adap, int onoff)
{
- int ret = 0;
+ struct usb_device *udev = adap-dev-udev;
+ int ret;
u8 pro = (adap-id == 0) ? DEV_0_DMOD : DEV_1_DMOD;
if (mutex_lock_interruptible(adap-dev-i2c_mutex) 0)
return -EAGAIN;
deb_info(1, PID_C (%02x), onoff);
- if (!onoff)
- ret = it913x_wr_reg(adap-dev-udev, pro, PID_RST, 0x1);
+ ret = it913x_wr_reg(udev, pro, PID_EN, onoff);
mutex_unlock(adap-dev-i2c_mutex);
return ret;
@@ -277,24 +277,20 @@ static int it913x_pid_filter(struct dvb_usb_adapter *adap,
int index, u16 pid, int onoff)
{
struct usb_device *udev = adap-dev-udev;
- int ret = 0;
+ int ret;
u8 pro = (adap-id == 0) ? DEV_0_DMOD : DEV_1_DMOD;
if (mutex_lock_interruptible(adap-dev-i2c_mutex) 0)
return -EAGAIN;
deb_info(1, PID_F (%02x), onoff);
- if (onoff) {
- ret = it913x_wr_reg(udev, pro, PID_EN, 0x1);
- ret |= it913x_wr_reg(udev, pro, PID_LSB, (u8)(pid 0xff));
+ ret = it913x_wr_reg(udev, pro, PID_LSB, (u8)(pid 0xff));
- ret |= it913x_wr_reg(udev, pro, PID_MSB, (u8)(pid 8));
+ ret |= it913x_wr_reg(udev, pro, PID_MSB, (u8)(pid 8));
- ret |= it913x_wr_reg(udev, pro, PID_INX_EN, (u8)onoff);
+ ret |= it913x_wr_reg(udev, pro, PID_INX_EN, (u8)onoff);
- ret |= it913x_wr_reg(udev, pro, PID_INX, (u8)(index 0x1f));
-
- }
+ ret |= it913x_wr_reg(udev, pro, PID_INX, (u8)(index 0x1f));
mutex_unlock(adap-dev-i2c_mutex);
return 0;
@@ -844,5 +840,5 @@ module_exit(it913x_module_exit);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
-MODULE_VERSION(1.18);
+MODULE_VERSION(1.20);
MODULE_LICENSE(GPL);
--
1.7.7.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Mon Jan 2 19:00:16 CET 2012 git hash:1e73fa5d56333230854ae9460579eb2fcee8af02 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK 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: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-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: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][BUG] it913x ver 1.21 Fixed for issue with 9006 and warm boot.
Some channels appear weak signal after warm boot.
Because tuner id is not present in eprom 0x38 is
assigned.
9006 devices are now always assigned 0x60.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/it913x.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index ad7013c..4db9124 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -395,9 +395,10 @@ static int ite_firmware_select(struct usb_device *udev,
USB_PID_ITETECH_IT9135_9005)
sw = IT9135_V1_FW;
else if (le16_to_cpu(udev-descriptor.idProduct) ==
- USB_PID_ITETECH_IT9135_9006)
+ USB_PID_ITETECH_IT9135_9006) {
sw = IT9135_V2_FW;
- else
+ it913x_config.tuner_id_0 = 0x60;
+ } else
sw = IT9137_FW;
/* force switch */
@@ -840,5 +841,5 @@ module_exit(it913x_module_exit);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
-MODULE_VERSION(1.20);
+MODULE_VERSION(1.21);
MODULE_LICENSE(GPL);
--
1.7.7.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 subdevice query
Hi Vinay,
On Mon, Dec 19, 2011 at 12:08:31PM -0800, vka...@codeaurora.org wrote:
Hi
I am trying to implement a video encoder v4l2 device and
need your help to find answers to some of the questions.
There is one hardware core which can do multiple sessions
(multiple file handles) of encode simultaneously.
The encode functionalty needs to be exposed to userspace
as well as kernel through standard set of APIs. Userspace
should be able to use this functionality through V4l2 interface
and another kernel module should be able to use encoder
as a subdevice. I am trying to explore the framework to achieve this
and have following questions:
Is there a physical link (a bus) between the device which the another kernel
module drives, and the video encoder? Memory does not count. I have never
seen a video encoder which would be connected to somewhere else, e.g. an
ISP.
Typically video encoders will have to access the image data in tiles that do
not match with the linear read of the sensor's pixel array, which is the
same order as the output of ISPs. This requires an intermediate buffer, at
least, which is typically the system memory.
Any further technical information on the encoder, its connections to the
rest of the SoC and the SoC itself would be helpful.
1. I am planning to create a V4L2 device and also initializing
it as a subdev in the probe function i.e the probe function
of this driver will have:
struct venc_device {
struct v4l2_device v4l2_dev;
struct v4l2_subdev sd;
};
struct venc_device *vdev;
v4l2_device_register(vdev-v4l2_dev);
v4l2_subdev_init(vdev-sd, venc_sd_ops);
How do other modules discover this subdevice. Is there an API
I can use to find module by name?
2. Most of the subdevice interface functions have input parameters
as struct v4l2_subdev *sd and another API specific structure.
How do I distinguish between different instances (file handles)
of a subdevice. Do I always need to pass file handle/instance
specific information in void *arg of the ioctl subdev core ops.
The subdev API, as it stands currently, is intended for configuring hardware
devices which only can have a single, global configuration.
If you implement your video encoder as a memory-to-memory device, I think
the interface has exactly what you'll need. By default everything in
memory-to-memory devices is file handle specific.
3. Controls are instance specific, eg: one encoder application might
encode at bitrate of 4Mbps and another at 128kbps, so I want controls
to be specific to file handles. I see that the control handler has been
moved to v4l2_fh structure for this purpose. How do I do it for
subdevices
so that the v4l2 device using this subdevice inherits the instance
specific controls defined by the subdevice.
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] uvcvideo: Allow userptr IO mode.
Hi Javier,
Thanks for the patch.
On Monday 02 January 2012 15:12:23 Javier Martin wrote:
Userptr can be very useful if a UVC camera
is requested to use video buffers allocated
by another processing device. So that
buffers don't need to be copied.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
I'll push the patch through my tree when 1/2 will be acked.
---
drivers/media/video/uvc/uvc_queue.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c index 518f77d..8f54e24 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -126,7 +126,7 @@ void uvc_queue_init(struct uvc_video_queue *queue, enum
v4l2_buf_type type, int drop_corrupted)
{
queue-queue.type = type;
- queue-queue.io_modes = VB2_MMAP;
+ queue-queue.io_modes = VB2_MMAP | VB2_USERPTR;
queue-queue.drv_priv = queue;
queue-queue.buf_struct_size = sizeof(struct uvc_buffer);
queue-queue.ops = uvc_queue_qops;
--
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
[resend][patch] em28xx: Add Plextor ConvertX PX-AV100U to em28xx-cards.c
This a followup to my already submitted patch 9280, which has the right
margins truncated (therefore I am resubmitting from my Comcast account
configured with a POP3 client, instead of Gmail's web interface).
This adds support for the Plextor ConvertX PX-AV100U, which uses the
eMPIA EM2820 chip. The device has a device_id of '0x093b, 0xa003'. I
am using the existing EM2820_BOARD_PINNACLE_DVC_90 board profile, as
the Pinnacle Dazzle DVC 90/100/101/107, Kaiser Baas Video to DVD
maker, and Kworld DVD Maker 2 were already mapped to it. Some more
background on the device and my testing can be found at
http://www.donkramer.net/plextor_122710.pdf
Signed-off-by: Don Kramer dgkra...@comcast.net
---
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 6cab22d..b30ea94 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1270,7 +1270,7 @@ struct em28xx_board em28xx_boards[] = {
},
[EM2820_BOARD_PINNACLE_DVC_90] = {
.name = Pinnacle Dazzle DVC 90/100/101/107 / Kaiser
Baas Video to DVD maker
- / Kworld DVD Maker 2,
+ / Kworld DVD Maker 2 / Plextor ConvertX
PX-AV100U,
.tuner_type = TUNER_ABSENT, /* capture only board */
.decoder = EM28XX_SAA711X,
.input= { {
@@ -2019,6 +2019,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2880_BOARD_PINNACLE_PCTV_HD_PRO },
{ USB_DEVICE(0x0413, 0x6023),
.driver_info = EM2800_BOARD_LEADTEK_WINFAST_USBII },
+ { USB_DEVICE(0x093b, 0xa003),
+ .driver_info = EM2820_BOARD_PINNACLE_DVC_90 },
{ USB_DEVICE(0x093b, 0xa005),
.driver_info = EM2861_BOARD_PLEXTOR_PX_TV100U },
{ USB_DEVICE(0x04bb, 0x0515),
---
--
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] libv4l: add hflip quirk for dealextreme cam sku #44507
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
lib/libv4lconvert/control/libv4lcontrol.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/libv4lconvert/control/libv4lcontrol.c
b/lib/libv4lconvert/control/libv4lcontrol.c
index 12fa874..a9908ac 100644
--- a/lib/libv4lconvert/control/libv4lcontrol.c
+++ b/lib/libv4lconvert/control/libv4lcontrol.c
@@ -51,6 +51,8 @@ static const struct v4lcontrol_flags_info v4lcontrol_flags[]
= {
/* Genius E-M 112 (also want whitebalance by default) */
{ 0x093a, 0x2476, 0, NULL, NULL,
V4LCONTROL_HFLIPPED|V4LCONTROL_VFLIPPED | V4LCONTROL_WANTS_WB,
1500 },
+ /* uvc-compatible cam from dealextreme (sku #44507) */
+ { 0x18ec, 0x3366, 0, NULL, NULL, V4LCONTROL_HFLIPPED },
/* Laptops (and all in one PC's) */
{ 0x0402, 0x5606, 0,
--
1.7.8.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control
Hi Laurent, On 01/02/2012 12:16 PM, Laurent Pinchart wrote: * controls for starting/stopping auto focusing (V4L2_CID_FOCUS_AUTO == false) V4L2_CID_START_AUTO_FOCUS (button) - start auto focusing, V4L2_CID_STOP_AUTO_FOCUS (button) - stop auto focusing (might be also useful in V4L2_FOCUS_AUTO == true), Maybe V4L2_CID_AUTO_FOCUS_START and V4L2_CID_AUTO_FOCUS_STOP to be consistent with the other proposed controls ? Yes, you're right, I'll change them to make consistent with others. I've noticed that too, but a little bit too late:) * auto focus status V4L2_CID_AUTO_FOCUS_STATUS (menu, read-only) - whether focusing is in progress or not, possible entries: - V4L2_AUTO_FOCUS_STATUS_IDLE,// auto focusing not enabled or force stopped - V4L2_AUTO_FOCUS_STATUS_BUSY,// focusing in progress - V4L2_AUTO_FOCUS_STATUS_SUCCESS, // single-shot auto focusing succeed // or continuous AF in progress - V4L2_AUTO_FOCUS_STATUS_FAIL,// auto focusing failed * V4L2_CID_FOCUS_AUTO would retain its current semantics: V4L2_CID_FOCUS_AUTO (boolean) - selects auto/manual focus false - manual true - auto continuous * AF algorithm scan range, V4L2_CID_FOCUS_AUTO_SCAN_RANGE with choices: - V4L2_AUTO_FOCUS_SCAN_RANGE_NORMAL, - V4L2_AUTO_FOCUS_SCAN_RANGE_MACRO, - V4L2_AUTO_FOCUS_SCAN_RANGE_INFINITY ... * select auto focus mode V4L2_CID_AUTO_FOCUS_MODE V4L2_AUTO_FOCUS_MODE_NORMAL - normal auto focus (whole frame?) V4L2_AUTO_FOCUS_MODE_SPOT - spot location passed with other controls or selection API V4L2_AUTO_FOCUS_MODE_RECTANGLE - rectangle passed with other controls or selection API Soudns good to me. parameter. We also need to discuss how the af statistics window configuration is done. I'm not certain there could even be a standardised Do we need multiple windows for AF statistics ? If not, I'm inclined to use four separate controls for window configuration. (X, Y, WIDTH, HEIGHT). This was Hans' preference in previous discussions [1]. For the OMAP3 ISP we need multiple statistics windows. AEWB can use more than 32 windows. Having separate controls for that wouldn't be practical. OK, so the control API in current form doesn't seem capable of setting up the statistics windows. There is also little space in struct v4l2_ext_control for any major extensions. We might need to define dedicated set of selection targets in the selection API for handling multiple windows. Yet, to avoid forcing applications to use the selection API where rectangles aren't needed - only single spot coordinates, how about defining following two controls ? * AF spot coordinates when focus mode is set to V4L2_AUTO_FOCUS_MODE_SPOT - V4L2_CID_AUTO_FOCUS_POSITION_X - horizontal position in pixels relative to the left of frame - V4L2_CID_AUTO_FOCUS_POSITION_Y - vertical position in pixels relative to the top of frame -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: em28xx: new board id [eb1a:5051]
On Sun, 2012-01-01 at 20:40 -0800, okonomiyaki...@my180.net wrote: On Sat, 2011-12-31 at 17:01 -0800, Reuben Stokes wrote: On Saturday 31 December 2011 01:51:45 Gareth Williams wrote: On Fri, 2011-12-30 at 15:16 -0800, Reuben Stokes wrote: On Friday 30 December 2011 14:27:57 Gareth Williams wrote: On Fri, 2011-12-30 at 05:04 -0800, Reuben Stokes wrote: On Friday 30 December 2011 02:01:35 you wrote: On Thu, 2011-12-29 at 15:13 -0800, Reuben Stokes wrote: Hi, Not nearly as linux-savvy as most of the users here, but I attempted to operate a Raygo USB Video Recorder (audio/video capture device). Don't know if my efforts qualify as a test. Model Number: R12-41373 Display name: USB 2861 Device lsusb: Bus 001 Device 002: ID eb1a:5051 eMPIA Technology, Inc. dmesg: [ 7182.076058] usb 1-1: new high speed USB device using ehci_hcd and address 3 [ 7182.212702] usb 1-1: New USB device found, idVendor=eb1a, idProduct=5051 [ 7182.212714] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 7182.212723] usb 1-1: Product: USB 2861 Device [ 7182.212729] usb 1-1: SerialNumber: 0 System: HP Pavilion dv6910 laptop AMD Turion X2 CPU (64 bit) Mepis 11; 64 bit( based on Debian Squeeze) Tried --- * Installed em28xx drivers using instructions found at linuxtv.org. I note however that this particular vendor/product ID is not validated in the em28xx devices list. * As new drivers do not automatically load, I use command: modprobe em28xx After this modprobe -l | grep em28xx yields kernel/drivers/media/video/em28xx/em28xx-alsa.ko kernel/drivers/media/video/em28xx/em28xx.ko kernel/drivers/media/video/em28xx/em28xx-dvb.ko * Device comes with a driver CD for Windows which does work in Windows. End result is the device is not recognized as a capture device option in any software tried including vlc, cheese, guvcview, kdenlive. Any help getting this to work in Linux would be appreciated as it completely sucks in my bloated, memory-hogging, 32-bit Windows Vista. Reuben okonomiyaki...@gohighspeed.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Reuben, If you're willing, then open up the device and see what the chips within are. You believe it's em28xx based, but there may well be additional devices in there for audio and video. Once you've found out what's inside it will be easier to get it working. It may be as simple as getting the driver to recognise the USB Vendor ID or it may require much more work. Regards, Gareth -- 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 Thank you very much for the response. Okay, opening it was easier than first suspected. The main (biggest) chip reads with nice big letters and a logo: eMPIA EM2860 P86J3-011 201047-01AG Less useful information inlcudes: A smaller chip on the flip side of the circuit board, in letters visible only through a magnifying glass, reads: eMPIA TECHNOLOGY EMP202 T10164 1052 The circuit board itself is stamped: PM22860-2GOB Again, thank you. Reuben Reuben, Was there another chip on there? The EMP202 is an audio chip that can covert analogue audio to digital PCM (and vice versa). The EM2860 sends this digital audio along with digital video over USB. For this to work though, the device will need to convert analogue video to digital and will need another chip to do this. An example would be a SAA7113 from Philips. Have another look and post back here. The two chips you've identified are commonly used in for this type of device and should be easily configurable in the em28xx driver. We just need the video chip now! And a tail wind... Regards, Gareth -- 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 Good call. There is another chip.
Re: [PATCH v4 0/2] Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.
Hi Javier, On 01/02/2012 10:31 AM, javier Martin wrote: Hi, do you have any more concerns or comments on this patch? I can't find it in media_tree. Has it been merged somewhere else? If you think your driver is good enough for merging, if you didn't do so already, you should normally send Mauro a git pull request. Please see: http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#how_to_submit_a_-git_pull_request And here you can find some examples: http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=PULLarchive=both -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/4] v4l: Add V4L2_CID_PRESET_WHITE_BALANCE menu control
Hi HeungJun, On 01/02/2012 05:38 AM, Kim, Heungjun wrote: On 2011년 12월 30일 19:30, Sylwester Nawrocki wrote: On 12/29/2011 06:08 AM, HeungJun, Kim wrote: I guess the WBP menu controls of pwc driver is probably defined in the other headers, for users being well known the PWC hardware. So it should be managed separately to videodev2.h. Is it right? Even if the way might be slightly different, it can't avoid to be managed separately. It means the users being not well known the specific hardware like PWC, have difficulty to use that driver well. And, at least, It doesn't looks generic API for me. In this case, the unfamiliar user with such unique hardware, can use whatever he wants to use finally, after finding looking around the headers. Applications can query drivers for supported controls and populate user control panels dynamically, based on information from VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU ioctls. Not needing to rely on menu items definition in videodev2.h. I had a feeling you weren't considering such case. :) You're right in that meaning. And it might be a good point. But, I think these 2 ioctl can not handle about this issue. Before using VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU, the user should know which CID name is used in the videodev2.h, and anyway it can not be avoidable the user find out this name in it. :) Yes, in many cases it is required to know the CID in advance, however it is not mandatory for all applications. At least I've seen nobody makes the application just to open(), queryctrl(), querymenu(), and close(), only for scanning the specific control is existed or not. Until now, I have known these 2 ioctl is generally used for formating the UI componets like button, menu, and etc, on the screen. Yup. So, it's safe to say that the user who knows that specific control is also know the CID name, the user knows such specific controls don't need even VIDIOC_QUERYCTRL and VIDIOC_QUERYMENU. I respectfully disagree. Properly written applications must use VIDIOC_QUERYCTRL/ VIDIOC_QUERYMENU ioctls, as many v4l2 controls have now driver-specific value range. Please see this application for instance [1], it doesn't hard code any control IDs in it, it only uses V4L2_CID_BASE, V4L2_CID_PRIVATE_BASE and V4L2_CID_LASTP1. Yet, it can handle any control, as long as it supports the control's type. And IMHO, this is not related about pulling out the hidden(?) controls generally used in the camera, on the videodev2.h. I think it's only generic defined in videodev2.h. I really had wondered why the controls I thought very general for camera is in hidden(?) the specific driver, not in the videodev2.h. It was just start to consider this issues. I think you misunderstood me, I didn't mean to force anyone to use private controls for common features. :) Regards, Heungjun Kim Perhaps it's uncommon in embedded systems though. [1] http://sourceforge.net/projects/v4l2ucp/files/v4l2ucp/2.0/ -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] s5p-mfc: Fix volatile controls setup
Hi Kamil,
On Tuesday 27 December 2011 15:07:24 Kamil Debski wrote:
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c index 844a4d7..c25ec02 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
@@ -165,7 +165,7 @@ static struct mfc_control controls[] = {
.maximum = 32,
.step = 1,
.default_value = 1,
- .flags = V4L2_CTRL_FLAG_VOLATILE,
+ .is_volatile = 1,
},
};
Why so ? is_volatile got removed in commit
88365105d683187e02a4f75220eaf51fd0c0b6e0.
--
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
Re: Multiple channel capture support in V4l2 layer
Hi Dilip, On Friday 23 December 2011 19:57:22 Dilip Mannil wrote: Hi, I am trying to implement v4l2 slave driver for ML86V76654 digital video decoder that converts NTSC, PAL, SECAM analog video signals into the YCbCr standard digital format. This codec takes 4 analog inputs(2 analog camera + 2 ext video in) and encodes in to digital(only one at a time). The driver should be able to switch between capture channels upon request from user space application. I couldn't find the support for multiple capture channels on a single device in v4l2 layer. Please correct me if I am wrong. Ideally I want the v4l2 slave driver to have following feature. 1. ioctl that can be used to enumerate/get/set the capture channels on the video encoder. 2. Able to capture video from the currently set capture channel and pass to higher layers. Which is the best way to implement this support? VIDIOC_ENUMINPUT and VIDIOC_[GS]_INPUT seem to be what you're looking for. -- 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
Re: em28xx: new board id [eb1a:5051]
On Monday 02 January 2012 13:04:01 Gareth Williams wrote: On Sun, 2012-01-01 at 20:40 -0800, okonomiyaki...@my180.net wrote: On Sat, 2011-12-31 at 17:01 -0800, Reuben Stokes wrote: On Saturday 31 December 2011 01:51:45 Gareth Williams wrote: On Fri, 2011-12-30 at 15:16 -0800, Reuben Stokes wrote: On Friday 30 December 2011 14:27:57 Gareth Williams wrote: On Fri, 2011-12-30 at 05:04 -0800, Reuben Stokes wrote: On Friday 30 December 2011 02:01:35 you wrote: On Thu, 2011-12-29 at 15:13 -0800, Reuben Stokes wrote: Hi, Not nearly as linux-savvy as most of the users here, but I attempted to operate a Raygo USB Video Recorder (audio/video capture device). Don't know if my efforts qualify as a test. Model Number: R12-41373 Display name: USB 2861 Device lsusb: Bus 001 Device 002: ID eb1a:5051 eMPIA Technology, Inc. dmesg: [ 7182.076058] usb 1-1: new high speed USB device using ehci_hcd and address 3 [ 7182.212702] usb 1-1: New USB device found, idVendor=eb1a, idProduct=5051 [ 7182.212714] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=2 [ 7182.212723] usb 1-1: Product: USB 2861 Device [ 7182.212729] usb 1-1: SerialNumber: 0 System: HP Pavilion dv6910 laptop AMD Turion X2 CPU (64 bit) Mepis 11; 64 bit( based on Debian Squeeze) Tried --- * Installed em28xx drivers using instructions found at linuxtv.org. I note however that this particular vendor/product ID is not validated in the em28xx devices list. * As new drivers do not automatically load, I use command: modprobe em28xx After this modprobe -l | grep em28xx yields kernel/drivers/media/video/em28xx/em28xx-alsa.ko kernel/drivers/media/video/em28xx/em28xx.ko kernel/drivers/media/video/em28xx/em28xx-dvb.ko * Device comes with a driver CD for Windows which does work in Windows. End result is the device is not recognized as a capture device option in any software tried including vlc, cheese, guvcview, kdenlive. Any help getting this to work in Linux would be appreciated as it completely sucks in my bloated, memory-hogging, 32-bit Windows Vista. Reuben okonomiyaki...@gohighspeed.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Reuben, If you're willing, then open up the device and see what the chips within are. You believe it's em28xx based, but there may well be additional devices in there for audio and video. Once you've found out what's inside it will be easier to get it working. It may be as simple as getting the driver to recognise the USB Vendor ID or it may require much more work. Regards, Gareth -- 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 Thank you very much for the response. Okay, opening it was easier than first suspected. The main (biggest) chip reads with nice big letters and a logo: eMPIA EM2860 P86J3-011 201047-01AG Less useful information inlcudes: A smaller chip on the flip side of the circuit board, in letters visible only through a magnifying glass, reads: eMPIA TECHNOLOGY EMP202 T10164 1052 The circuit board itself is stamped: PM22860-2GOB Again, thank you. Reuben Reuben, Was there another chip on there? The EMP202 is an audio chip that can covert analogue audio to digital PCM (and vice versa). The EM2860 sends this digital audio along with digital video over USB. For this to work though, the device will need to convert analogue video to digital and will need another chip to do this. An example would be a SAA7113 from Philips. Have another look and post back here. The two chips you've identified are commonly used in for this type of device and should be easily configurable in the em28xx driver. We just need the video chip now! And a tail wind... Regards, Gareth -- To unsubscribe from this list: send the line
Re: [PATCH v4 0/2] Add support form eMMa-PrP in i.MX2 chips as a mem2mem device.
On 2 January 2012 22:12, Sylwester Nawrocki snj...@gmail.com wrote: Hi Javier, On 01/02/2012 10:31 AM, javier Martin wrote: Hi, do you have any more concerns or comments on this patch? I can't find it in media_tree. Has it been merged somewhere else? If you think your driver is good enough for merging, if you didn't do so already, you should normally send Mauro a git pull request. Please see: http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#how_to_submit_a_-git_pull_request And here you can find some examples: http://patchwork.linuxtv.org/project/linux-media/list/?state=*q=PULLarchive=both Do you mean I have to set up a public GIT repository? Is this mandatory? I am not a subsystem maintainer, just casual developer. What about this? http://linuxtv.org/wiki/index.php/Maintaining_Git_trees#Patches_submitted_via_email -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] media: vb2: support userptr for PFN mappings.
Hi Laurent,
thank you for your review.
On 2 January 2012 20:00, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Javier,
Thanks for the patch.
On Monday 02 January 2012 15:12:22 Javier Martin wrote:
Some video devices need to use contiguous memory
which is not backed by pages as it happens with
vmalloc. This patch provides userptr handling for
those devices.
What's your main use case ? Capturing to the frame buffer ?
My main use case is capturing to my mx2_emmaprp mem2mem driver which
converts from YUV422 to YUV420 format in HW.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/videobuf2-vmalloc.c | 66
+++--- 1 files changed, 42 insertions(+), 24
deletions(-)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c index 03aa62f..5bc7cec 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -15,6 +15,7 @@
#include linux/sched.h
#include linux/slab.h
#include linux/vmalloc.h
+#include linux/io.h
Please keep headers sorted alphabetically.
OK. I didn't know that was the rule.
#include media/videobuf2-core.h
#include media/videobuf2-memops.h
@@ -71,6 +72,8 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr, struct vb2_vmalloc_buf *buf;
unsigned long first, last;
int n_pages, offset;
+ struct vm_area_struct *vma;
+ unsigned long int physp;
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
@@ -80,23 +83,34 @@ static void *vb2_vmalloc_get_userptr(void *alloc_ctx,
unsigned long vaddr, offset = vaddr ~PAGE_MASK;
buf-size = size;
- first = vaddr PAGE_SHIFT;
- last = (vaddr + size - 1) PAGE_SHIFT;
- buf-n_pages = last - first + 1;
- buf-pages = kzalloc(buf-n_pages * sizeof(struct page *), GFP_KERNEL);
- if (!buf-pages)
- goto fail_pages_array_alloc;
-
- /* current-mm-mmap_sem is taken by videobuf2 core */
- n_pages = get_user_pages(current, current-mm, vaddr PAGE_MASK,
- buf-n_pages, write, 1, /* force */
- buf-pages, NULL);
- if (n_pages != buf-n_pages)
- goto fail_get_user_pages;
-
- buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1, PAGE_KERNEL);
- if (!buf-vaddr)
- goto fail_get_user_pages;
+ vma = find_vma(current-mm, vaddr);
+ if (vma (vma-vm_flags VM_IO) (vma-vm_pgoff)) {
+ physp = (vma-vm_pgoff PAGE_SHIFT) + (vaddr -
vma-vm_start);
+ buf-vaddr = ioremap_nocache(physp, size);
+ if (!buf-vaddr)
+ goto fail_pages_array_alloc;
What if the region spans multiple VMAs ? Shouldn't you at least verify that
the region is physically contiguous, and that all VMAs share the same flags ?
That's what the OMAP3 ISP driver does (in ispqueue.c). Maybe it's overkill
though.
If you do that, the could might be cleaner if you split this function in two,
as in the OMAP3 ISP driver.
Yes, I suspected this could probably be troublesome. I'll take a look
at OMAP3 ISP and see what I can do.
+ } else {
+ first = vaddr PAGE_SHIFT;
+ last = (vaddr + size - 1) PAGE_SHIFT;
+ buf-n_pages = last - first + 1;
+ buf-pages = kzalloc(buf-n_pages * sizeof(struct page *),
+ GFP_KERNEL);
+ if (!buf-pages)
+ goto fail_pages_array_alloc;
+
+ /* current-mm-mmap_sem is taken by videobuf2 core */
+ n_pages = get_user_pages(current, current-mm,
+ vaddr PAGE_MASK, buf-n_pages,
+ write,1, /* force */
+ buf-pages, NULL);
+ if (n_pages != buf-n_pages)
+ goto fail_get_user_pages;
+
+ buf-vaddr = vm_map_ram(buf-pages, buf-n_pages, -1,
+ PAGE_KERNEL);
+ if (!buf-vaddr)
+ goto fail_get_user_pages;
+ }
buf-vaddr += offset;
return buf;
@@ -120,14 +134,18 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
unsigned long vaddr = (unsigned long)buf-vaddr PAGE_MASK;
unsigned int i;
- if (vaddr)
- vm_unmap_ram((void *)vaddr, buf-n_pages);
- for (i = 0; i buf-n_pages; ++i) {
- if (buf-write)
- set_page_dirty_lock(buf-pages[i]);
- put_page(buf-pages[i]);
+ if (buf-pages) {
+ if (vaddr)
+ vm_unmap_ram((void *)vaddr, buf-n_pages);
+ for (i = 0; i buf-n_pages; ++i) {
+ if (buf-write)
+ set_page_dirty_lock(buf-pages[i]);
+
Re: [PATCHv2 00/94] Only use DVBv5 internally on frontend drivers
On 01/01/2012 09:12 PM, Mauro Carvalho Chehab wrote: On 01-01-2012 13:23, Sylwester Nawrocki wrote: On 12/30/2011 05:45 PM, Mauro Carvalho Chehab wrote: On 30-12-2011 14:36, Sylwester Nawrocki wrote: On 12/30/2011 04:06 PM, Mauro Carvalho Chehab wrote: This patch series comes after the previous series of 47 patches. Basically, changes all DVB frontend drivers to work directly with the DVBv5 structure. This warrants that all drivers will be Is there any git tree available with all these patches ? It would be easier to pull rather than applying almost 150 patches. :) I know I don't need them all, but just to be sure I have all the relevant changes in place for testing. Forgot to mention, and to update them on my tree. The latest version are at the branch DVB_v5_v5 on my experimental tree: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/DVB_v5_v5 (yeah, I know: the name become weird... It were DVB_v5, meaning DVB API v5, then, for each rebase, I added a new branch there) Just for the record, I've tested it with as102 driver (pctv74e usb stick) and MeTV and didn't notice any runtime problems. Thank you for testing it, Sylvester! I wrote yet another set of patches (this is a shorter one) meant to finish the DVB cleanup. The new series addresses some issues inside dvb_frontend.c. It is at: git://linuxtv.org/mchehab/experimental.git DVBv5-v7 I've tested this one in same way and didn't find any regressions. -- Thanks, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
