Re: [PATCH] omap3isp: video: Don't WARN() on unknown pixel formats
Laurent Pinchart wrote:
Hi Sakari,
On Monday 28 November 2011 17:01:12 Sakari Ailus wrote:
On Mon, Nov 28, 2011 at 12:37:34PM +0100, Laurent Pinchart wrote:
When mapping from a V4L2 pixel format to a media bus format in the
VIDIOC_TRY_FMT and VIDIOC_S_FMT handlers, the requested format may be
unsupported by the driver. Return a hardcoded format instead of
WARN()ing in that case.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/ispvideo.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d100072..ffe7ce9 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -210,14 +210,14 @@ static void isp_video_pix_to_mbus(const struct
v4l2_pix_format *pix,
mbus-width = pix-width;
mbus-height = pix-height;
- for (i = 0; i ARRAY_SIZE(formats); ++i) {
+ /* Skip the last format in the loop so that it will be selected if no
+* match is found.
+*/
+ for (i = 0; i ARRAY_SIZE(formats) - 1; ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
- if (WARN_ON(i == ARRAY_SIZE(formats)))
- return;
-
mbus-code = formats[i].code;
mbus-colorspace = pix-colorspace;
mbus-field = pix-field;
In case of setting or trying an invalid format, instead of selecting a
default format, shouldn't we leave the format unchanced --- the current
setting is valid after all.
TRY/SET operations must succeed. The format we select when an invalid format
is requested isn't specified. We could keep the current format, but wouldn't
that be more confusing for applications ? The format they would get in
response to a TRY/SET operation would then potentially depend on the previous
SET operations.
I don't think a change to something that has nothing to do what was
requested is better than not changing it. The application has requested
a particular format; changing it to something else isn't useful for the
application. And if the application would try more than invalid format
in a row, they both would yield to the same default format.
I would personally not change it.
What I can find in the spec is this:
When the application calls the VIDIOC_S_FMT ioctl with a pointer to a
v4l2_format structure the driver checks and adjusts the parameters
against hardware abilities.
I wonder how other drivers behave.
--
Sakari Ailus
sakari.ai...@iki.fi
--
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] xc5000: unlock on error in xc_load_fw_and_init_tuner()
We recently added locking to this function, but we missed an error path
which needs an unlock.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index 048f489..a3fcc59 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -1009,7 +1009,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend
*fe)
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
ret = xc5000_fwupload(fe);
if (ret != XC_RESULT_SUCCESS)
- return ret;
+ goto out;
}
/* Start the tuner self-calibration process */
@@ -1025,6 +1025,7 @@ static int xc_load_fw_and_init_tuner(struct dvb_frontend
*fe)
/* Default to CABLE mode */
ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
+out:
mutex_unlock(xc5000_list_mutex);
return ret;
--
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: video: uvc: integer overflow in uvc_ioctl_ctrl_map()
Hi Haogang, On Wednesday 30 November 2011 03:28:32 Haogang Chen wrote: The hard limit sounds good to me. OK. But if you want to centralize error handling, please make sure that goto done only frees map, but not map-menu_info in that case. map-menu_info will be NULL, so it's safe to kfree() it. -- 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] s5p-fimc: Prevent deadlock caused by incomplete H/W initialization
The following ioctl sequence causes fimc_dma_run() to start processing without complete scaler and DMA initialization which causes missing interrupt and blocking on DQBUF: S_FMT, STREAMON, QBUF, DQBUF, STREAMOFF, STREAMON, QBUF, DQBUF. Fix this regression caused by moving pm_runtime* calls to start/stop_streaming callback by making sure the fimc_m2m_resume() is always invoked when expected. Reported-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park s.nawro...@samsung.com --- drivers/media/video/s5p-fimc/fimc-core.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/s5p-fimc/fimc-core.c b/drivers/media/video/s5p-fimc/fimc-core.c index 07c6254..567e9ea 100644 --- a/drivers/media/video/s5p-fimc/fimc-core.c +++ b/drivers/media/video/s5p-fimc/fimc-core.c @@ -1709,9 +1709,8 @@ static int fimc_runtime_resume(struct device *dev) /* Resume the capture or mem-to-mem device */ if (fimc_capture_busy(fimc)) return fimc_capture_resume(fimc); - else if (fimc_m2m_pending(fimc)) - return fimc_m2m_resume(fimc); - return 0; + + return fimc_m2m_resume(fimc); } static int fimc_runtime_suspend(struct device *dev) -- 1.7.7.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] [media] V4L: atmel-isi: add code to enable/disable ISI_MCK clock
This patch
- add ISI_MCK clock enable/disable code.
- change field name in isi_platform_data structure
Signed-off-by: Josh Wu josh...@atmel.com
[g.liakhovet...@gmx.de: fix label names]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
Hi, Guennadi
I rebase this patch to current media tree: staging/for_v3.3.
The second patch added the clk_prepare()/clk_unprepare() base on Russell King's
suggestion.
Best Regards,
Josh Wu
drivers/media/video/atmel-isi.c | 31 +--
include/media/atmel-isi.h |4 +++-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index fbc904f..ea4eef4 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -90,7 +90,10 @@ struct atmel_isi {
struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
struct completion complete;
+ /* ISI peripherial clock */
struct clk *pclk;
+ /* ISI_MCK, feed to camera sensor to generate pixel clock */
+ struct clk *mck;
unsigned intirq;
struct isi_platform_data*pdata;
@@ -766,6 +769,12 @@ static int isi_camera_add_device(struct soc_camera_device
*icd)
if (ret)
return ret;
+ ret = clk_enable(isi-mck);
+ if (ret) {
+ clk_disable(isi-pclk);
+ return ret;
+ }
+
isi-icd = icd;
dev_dbg(icd-parent, Atmel ISI Camera driver attached to camera %d\n,
icd-devnum);
@@ -779,6 +788,7 @@ static void isi_camera_remove_device(struct
soc_camera_device *icd)
BUG_ON(icd != isi-icd);
+ clk_disable(isi-mck);
clk_disable(isi-pclk);
isi-icd = NULL;
@@ -874,7 +884,7 @@ static int isi_camera_set_bus_param(struct
soc_camera_device *icd, u32 pixfmt)
if (isi-pdata-has_emb_sync)
cfg1 |= ISI_CFG1_EMB_SYNC;
- if (isi-pdata-isi_full_mode)
+ if (isi-pdata-full_mode)
cfg1 |= ISI_CFG1_FULL_MODE;
isi_writel(isi, ISI_CTRL, ISI_CTRL_DIS);
@@ -912,6 +922,7 @@ static int __devexit atmel_isi_remove(struct
platform_device *pdev)
isi-fb_descriptors_phys);
iounmap(isi-regs);
+ clk_put(isi-mck);
clk_put(isi-pclk);
kfree(isi);
@@ -930,7 +941,7 @@ static int __devinit atmel_isi_probe(struct platform_device
*pdev)
struct isi_platform_data *pdata;
pdata = dev-platform_data;
- if (!pdata || !pdata-data_width_flags) {
+ if (!pdata || !pdata-data_width_flags || !pdata-mck_hz) {
dev_err(pdev-dev,
No config available for Atmel ISI\n);
return -EINVAL;
@@ -959,6 +970,19 @@ static int __devinit atmel_isi_probe(struct
platform_device *pdev)
INIT_LIST_HEAD(isi-video_buffer_list);
INIT_LIST_HEAD(isi-dma_desc_head);
+ /* Get ISI_MCK, provided by programmable clock or external clock */
+ isi-mck = clk_get(dev, isi_mck);
+ if (IS_ERR_OR_NULL(isi-mck)) {
+ dev_err(dev, Failed to get isi_mck\n);
+ ret = isi-mck ? PTR_ERR(isi-mck) : -EINVAL;
+ goto err_clk_get;
+ }
+
+ /* Set ISI_MCK's frequency, it should be faster than pixel clock */
+ ret = clk_set_rate(isi-mck, pdata-mck_hz);
+ if (ret 0)
+ goto err_set_mck_rate;
+
isi-p_fb_descriptors = dma_alloc_coherent(pdev-dev,
sizeof(struct fbd) * MAX_BUFFER_NUM,
isi-fb_descriptors_phys,
@@ -1034,6 +1058,9 @@ err_alloc_ctx:
isi-p_fb_descriptors,
isi-fb_descriptors_phys);
err_alloc_descriptors:
+err_set_mck_rate:
+ clk_put(isi-mck);
+err_clk_get:
kfree(isi);
err_alloc_isi:
clk_put(pclk);
diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h
index 26cece5..6568230 100644
--- a/include/media/atmel-isi.h
+++ b/include/media/atmel-isi.h
@@ -110,10 +110,12 @@ struct isi_platform_data {
u8 hsync_act_low;
u8 vsync_act_low;
u8 pclk_act_falling;
- u8 isi_full_mode;
+ u8 full_mode;
u32 data_width_flags;
/* Using for ISI_CFG1 */
u32 frate;
+ /* Using for ISI_MCK */
+ u32 mck_hz;
};
#endif /* __ATMEL_ISI_H__ */
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RESEND] davinci: dm646x: move vpif related code to driver core header from platform
On Fri, Nov 25, 2011 at 01:36:01, Mauro Carvalho Chehab wrote: Em 24-11-2011 16:22, Nori, Sekhar escreveu: Hi Mauro, On Thu, Nov 24, 2011 at 23:35:24, Mauro Carvalho Chehab wrote: Em 12-11-2011 13:06, Manjunath Hadli escreveu: move vpif related code for capture and display drivers from dm646x platform header file to vpif_types.h as these definitions are related to driver code more than the platform or board. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Manju, Why are you re-sending a patch? My understanding is that you're maintaining the davinci patches, so it is up to you to put those patches on your tree and send me a pull request when they're done. So, please, don't pollute the ML re-sending emails that are for yourself to handle. Since this particular patch touches arch/arm/mach-davinci as well as drivers/media/video, the plan was to queue the patch through ARM tree with your Ack. We did not get your ack the last time around[1] so it was resent. Do let me know if your ack is not needed. Thanks, Sekhar [1] http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg21840.html Hmm.. I missed this email, but just re-sending it without request my ACK doesn't help much ;) If this ever happens again, next time the better is to forward me the patch again, on an email asking for my ack. With regards to the patch: Acked-by: Mauro Carvalho Chehab mche...@redhat.com Thanks Mauro. Queuing this for v3.3 submission. Manju, while committing I changed the subject line to: ARM: davinci: vpif: move code to driver core header from platform to better match the current subject line conventions. Regards, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/5] ARM: davinci: re-arrange definitions to have a common davinci header
Hi Manju, On Thu, Nov 17, 2011 at 15:48:53, Hadli, Manjunath wrote: Re-arrange definitions and remove unnecessary code so that we canx These are two different things and should be done in separate patches. Sergei has already pointed out couple of instances. have a common header for all davinci platforms. This will enable You mean all DMx platforms? DA8x and TNETVx will still have their own header files after this patch set. us to share defines and enable common routines to be used without polluting hardware.h. This patch set forms the base for a later set of patches for having a common system module base address (DAVINCI_SYSTEM_MODULE_BASE). Changes from previous version(As per Sergei's comments): 1. Renamed davinci_common.h to davinci.h. 2. Added extra line whereever appropriate. 3. removed unnecessary header inclusion. Manjunath Hadli (5): ARM: davinci: dm644x: remove the macros from the header to move to c file ARM: davinci: dm365: remove the macros from the header to move to c file ARM: davinci: dm646x: remove the macros from the header to move to c file These headlines should describe the changes better. You are moving _private_ defines to C file (to reduce header file pollution). That should be clear from the headline. ARM: davinci: create new common platform header for davinci ARM: davinci: delete individual platform header files and use a common header arch/arm/mach-davinci/board-dm355-evm.c |2 +- arch/arm/mach-davinci/board-dm355-leopard.c |2 +- arch/arm/mach-davinci/board-dm365-evm.c |2 +- arch/arm/mach-davinci/board-dm644x-evm.c |2 +- arch/arm/mach-davinci/board-dm646x-evm.c |2 +- arch/arm/mach-davinci/board-neuros-osd2.c|2 +- arch/arm/mach-davinci/board-sffsdr.c |2 +- arch/arm/mach-davinci/dm355.c|2 +- arch/arm/mach-davinci/dm365.c| 18 +- arch/arm/mach-davinci/dm644x.c |9 +++- arch/arm/mach-davinci/dm646x.c |9 +++- arch/arm/mach-davinci/include/mach/davinci.h | 88 ++ This file should be placed in arch/arm/mach-davinci itself since the definitions are private to arch/arm/mach-davinci. Russell has been complaining about placing unnecessary files in include/mach. Thanks, Sekhar -- 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] board-dm646x-evm.c: wrong register used in setup_vpif_input_channel_mode
Hi Hans, On Mon, Nov 14, 2011 at 23:50:49, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com The function setup_vpif_input_channel_mode() used the VSCLKDIS register instead of VIDCLKCTL. This meant that when in HD mode videoport channel 0 used a different clock from channel 1. Clearly a copy-and-paste error. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Queuing this for v3.2-rc. I changed the headline to match current convention Being used in ARM: ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode Also, the code in question has not changed for a long time, so added the stable tag. Regards, Sekhar -- 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: Using MT9P031 digital sensor
On 2011-11-28 05:49, Laurent Pinchart wrote: Hi Gary, On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? (*) to build on v3.1, I had to manually add the mt9p031 driver and fix a compile error in drivers/media/video/omap/omap_vout.c Thanks -- Gary Thomas | Consulting for
Re: Using MT9P031 digital sensor
Hi Gary, On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: On 2011-11-28 05:49, Laurent Pinchart wrote: On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being
RE: Using MT9P031 digital sensor
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Wednesday, November 30, 2011 8:01 PM To: Gary Thomas Cc: Javier Martinez Canillas; Linux Media Mailing List Subject: Re: Using MT9P031 digital sensor Hi Gary, On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: On 2011-11-28 05:49, Laurent Pinchart wrote: On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1- OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3
[PULL] git://linuxtv.org/mkrufky/hauppauge.git voyager
Mauro, Please pull from the 'voyager' branch of my 'hauppauge' git tree for some simple USB ID additions for some additional HVR950Q variants. If it's possible to send these to Linus for 3.2, that would be really cool... but it's nothing urgent. The following changes since commit 36d36b884c745c507d9b3f60eb42925749f7d758: Mauro Carvalho Chehab (1): [media] tm6000: Warning cleanup are available in the git repository at: git://linuxtv.org/mkrufky/hauppauge.git voyager Michael Krufky (3): au0828: add missing USB ID 2040:7260 au0828: add missing USB ID 2040:7213 au0828: add missing models 72101, 72201 72261 to the model matrix drivers/media/video/au0828/au0828-cards.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Using MT9P031 digital sensor
On 2011-11-30 07:30, Laurent Pinchart wrote: Hi Gary, On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: On 2011-11-28 05:49, Laurent Pinchart wrote: On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? Because the OMAP3 ISP has alignment requirements. Both the preview engine and the resizer output
Re: Using MT9P031 digital sensor
On 2011-11-30 07:57, Gary Thomas wrote: On 2011-11-30 07:30, Laurent Pinchart wrote: Hi Gary, On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: On 2011-11-28 05:49, Laurent Pinchart wrote: On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? Because the OMAP3 ISP has alignment requirements. Both the preview engine and the resizer output line lenghts must be multiple of 32 bytes. The driver adds padding at end of lines when the output width isn't a multiple of 16 pixels. Any guess which resolution(s) I should change and to what? I
[PATCH 2/5] [media] tm6000: add IR support for HVR-900H
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/tm6000/tm6000-cards.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-cards.c
b/drivers/media/video/tm6000/tm6000-cards.c
index ec2578a..0b54132 100644
--- a/drivers/media/video/tm6000/tm6000-cards.c
+++ b/drivers/media/video/tm6000/tm6000-cards.c
@@ -351,6 +351,7 @@ static struct tm6000_board tm6000_boards[] = {
.tuner_addr = 0xc2 1,
.demod_addr = 0x1e 1,
.type = TM6010,
+ .ir_codes = RC_MAP_HAUPPAUGE,
.caps = {
.has_tuner= 1,
.has_dvb = 1,
--
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
[PATCH 1/5] [media] tuner-xc2028: Better report signal strength
Fix lock bit to better indicate signal strength, from 4096 to 65535. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/common/tuners/tuner-xc2028.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c index 3acbaa0..e531267 100644 --- a/drivers/media/common/tuners/tuner-xc2028.c +++ b/drivers/media/common/tuners/tuner-xc2028.c @@ -891,7 +891,7 @@ static int xc2028_signal(struct dvb_frontend *fe, u16 *strength) /* Frequency is locked */ if (frq_lock == 1) - signal = 32768; + signal = 1 11; /* Get SNR of the video signal */ rc = xc2028_get_reg(priv, 0x0040, signal); -- 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
[PATCH 4/5] [media] tm6000: Allow auto-detecting tm6000 devices
Now that the tm6000 driver is on a good shape, we can enable
device autodetection, based on the USB ID.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/tm6000/tm6000-cards.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-cards.c
b/drivers/media/video/tm6000/tm6000-cards.c
index 0b54132..3873ce4 100644
--- a/drivers/media/video/tm6000/tm6000-cards.c
+++ b/drivers/media/video/tm6000/tm6000-cards.c
@@ -640,6 +640,7 @@ static struct usb_device_id tm6000_id_table[] = {
{ USB_DEVICE(0x6000, 0xdec3), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER_LITE },
{ }
};
+MODULE_DEVICE_TABLE(usb, tm6000_id_table);
/* Control power led for show some activity */
void tm6000_flash_led(struct tm6000_core *dev, u8 state)
--
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
[PATCH 5/5] [media] tm6000: Use a 16 scancode bitmask for IR
This should allow using 24 or 32 bits NEC IR decoding tables with
those devices.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/tm6000/tm6000-input.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-input.c
b/drivers/media/video/tm6000/tm6000-input.c
index 6eaf770..e3467d4 100644
--- a/drivers/media/video/tm6000/tm6000-input.c
+++ b/drivers/media/video/tm6000/tm6000-input.c
@@ -416,6 +416,8 @@ int tm6000_ir_init(struct tm6000_core *dev)
/* input setup */
rc-allowed_protos = RC_TYPE_RC5 | RC_TYPE_NEC;
+ /* Neded, in order to support NEC remotes with 24 or 32 bits */
+ rc-scanmask = 0x;
rc-priv = ir;
rc-change_protocol = tm6000_ir_change_protocol;
if (dev-int_in) {
--
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
[PATCH 3/5] [media] tm6000: rewrite IR support
The IR support were broken on my tests with HVR-900H. Also,
there were several issues on the current implementation.
This patch is a major rewrite of the IR support for this
- Improve debug messages;
- Don't do polling for interrrupt based IR;
- Add proper support for RC-5 protocol;
- Always provide 16 bits for NEC and RC-5;
- Fix polling code;
- Split polling functions from URB Interrupt ones;
- Don't hardcode the XTAL reference for tm6000 IR;
- If a URB submit fails, retries after 100ms;
- etc.
Tested on Hauppauge HVR-900H, with RC-5 and NEC remotes.
Issues on IR handling, on this device:
- Repeat events aren't detected (neither on NEC or RC-5);
- NEC codes are always provided with 16 bits.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/tm6000/tm6000-core.c |2 +-
drivers/media/video/tm6000/tm6000-input.c | 412 +++--
2 files changed, 218 insertions(+), 196 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-core.c
b/drivers/media/video/tm6000/tm6000-core.c
index 6c1fdb5..fa37b5f 100644
--- a/drivers/media/video/tm6000/tm6000-core.c
+++ b/drivers/media/video/tm6000/tm6000-core.c
@@ -541,7 +541,7 @@ static struct reg_init tm6010_init_tab[] = {
{ TM6010_REQ07_RDE_IR_PULSE_CNT1, 0x20 },
{ TM6010_REQ07_RDF_IR_PULSE_CNT0, 0xd0 },
{ REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
- { TM6010_REQ07_RD8_IR, 0x2f },
+ { TM6010_REQ07_RD8_IR, 0x0f },
/* set remote wakeup key:any key wakeup */
{ TM6010_REQ07_RE5_REMOTE_WAKEUP, 0xfe },
diff --git a/drivers/media/video/tm6000/tm6000-input.c
b/drivers/media/video/tm6000/tm6000-input.c
index 8b07b72..6eaf770 100644
--- a/drivers/media/video/tm6000/tm6000-input.c
+++ b/drivers/media/video/tm6000/tm6000-input.c
@@ -31,22 +31,25 @@
static unsigned int ir_debug;
module_param(ir_debug, int, 0644);
-MODULE_PARM_DESC(ir_debug, enable debug message [IR]);
+MODULE_PARM_DESC(ir_debug, debug message level);
static unsigned int enable_ir = 1;
module_param(enable_ir, int, 0644);
MODULE_PARM_DESC(enable_ir, enable ir (default is enable));
-/* number of 50ms for ON-OFF-ON power led */
-/* show IR activity */
-#define PWLED_OFF 2
+static unsigned int ir_clock_mhz = 12;
+module_param(ir_clock_mhz, int, 0644);
+MODULE_PARM_DESC(enable_ir, ir clock, in MHz);
+
+#define URB_SUBMIT_DELAY 100 /* ms - Delay to submit an URB request
on retrial and init */
+#define URB_INT_LED_DELAY 100 /* ms - Delay to turn led on again on
int mode */
#undef dprintk
-#define dprintk(fmt, arg...) \
- if (ir_debug) { \
+#define dprintk(level, fmt, arg...) do {\
+ if (ir_debug = level) \
printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
- }
+ } while (0)
struct tm6000_ir_poll_result {
u16 rc_data;
@@ -62,20 +65,15 @@ struct tm6000_IR {
int polling;
struct delayed_work work;
u8 wait:1;
- u8 key:1;
- u8 pwled:1;
- u8 pwledcnt;
+ u8 pwled:2;
+ u8 submit_urb:1;
u16 key_addr;
struct urb *int_urb;
- u8 *urb_data;
-
- int (*get_key) (struct tm6000_IR *, struct tm6000_ir_poll_result *);
/* IR device properties */
u64 rc_type;
};
-
void tm6000_ir_wait(struct tm6000_core *dev, u8 state)
{
struct tm6000_IR *ir = dev-ir;
@@ -83,62 +81,84 @@ void tm6000_ir_wait(struct tm6000_core *dev, u8 state)
if (!dev-ir)
return;
+ dprintk(2, %s: %i\n,__func__, ir-wait);
+
if (state)
ir-wait = 1;
else
ir-wait = 0;
}
-
static int tm6000_ir_config(struct tm6000_IR *ir)
{
struct tm6000_core *dev = ir-dev;
- u8 buf[10];
- int rc;
+ u32 pulse = 0, leader = 0;
+
+ dprintk(2, %s\n,__func__);
+
+ /*
+* The IR decoder supports RC-5 or NEC, with a configurable timing.
+* The timing configuration there is not that accurate, as it uses
+* approximate values. The NEC spec mentions a 562.5 unit period,
+* and RC-5 uses a 888.8 period.
+* Currently, driver assumes a clock provided by a 12 MHz XTAL, but
+* a modprobe parameter can adjust it.
+* Adjustments are required for other timings.
+* It seems that the 900ms timing for NEC is used to detect a RC-5
+* IR, in order to discard such decoding
+*/
switch (ir-rc_type) {
case RC_TYPE_NEC:
- /* Setup IR decoder for NEC standard 12MHz system clock */
- /* IR_LEADER_CNT = 0.9ms */
- tm6000_set_reg(dev,
LinuxTV ported to Windows
Hello, We have ported linuxtv's cx23885+CAM en50221+Diseq to Windows OS (Vista, XP, win7 tested). Results available under GPL and can be checkout from git repository: https://github.com/netup/netup-dvb-s2-ci-dual Binary builds (ready to install) available in build directory. Currently NetUP Dual DVB-S2 CI card supported ( http://www.netup.tv/en-EN/dual_dvb-s2-ci_card.php ). Driver based on Microsoft BDA standard, but some features (DiSEqC, CI) supported by custom API, for more details see netup_bda_api.h file. Any comments, suggestions are welcome. -- Abylai Ospanaos...@netup.ru NetUP Inc. -- 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 5/5] tm6000: bugfix data check
Hi Stefan and Dmitri,
The entire RC input looked badly implemented. It never worked with HVR-900H,
and it were doing polling even on URB interrupt mode.
I've rewritten the entire code, and fixed it to be more reliable.
I've tested both interrupt and polling modes, with HVR-900H. On HVR-900H,
polling mode returns 0 when a scancode arrives, 0xff otherwise. This is
not the expected behavior on polling mode, but it seems to e due to the
way this device is wired. Anyway, the test were enough to test both ways
of receiving scancodes.
So, I broke the code for interrupt-driven and for polling-driven IR. This
made the code simpler to understand and more reliable. Also, on interrupt
driven mode, the CPU won't need to wake on every 50ms due to IR.
Both NEC and RC-5 protocols were tested, and I tried to make sure that the
driver would support 1 byte scancode, where devices can't provide
two bytes.
Please double check the patches I've made against your devices, in order
to be sure that nothing went wrong. Maybe something more would be needed
for IR on tm5600/tm6000.
I should be applying them upstream later today or tomorrow.
Regards,
Mauro
On 28-11-2011 17:46, linu...@stefanringel.de wrote:
From: Stefan Ringellinu...@stefanringel.de
beholder use a map with 3 bytes, but many rc maps have 2 bytes, so I add a
workaround for beholder rc.
Signed-off-by: Stefan Ringellinu...@stefanringel.de
---
drivers/media/video/tm6000/tm6000-input.c | 21 -
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-input.c
b/drivers/media/video/tm6000/tm6000-input.c
index 405d127..ae7772e 100644
--- a/drivers/media/video/tm6000/tm6000-input.c
+++ b/drivers/media/video/tm6000/tm6000-input.c
@@ -178,9 +178,21 @@ static int default_polling_getkey(struct tm6000_IR *ir,
poll_result-rc_data = ir-urb_data[0];
break;
case RC_TYPE_NEC:
- if (ir-urb_data[1] == ((ir-key_addr 8) 0xff)) {
+ switch (dev-model) {
+ case 10:
+ case 11:
+ case 14:
+ case 15:
Using magic numbers here is a very bad idea.
+ if (ir-urb_data[1] ==
+ ((ir-key_addr 8) 0xff)) {
+ poll_result-rc_data =
+ ir-urb_data[0]
+ | ir-urb_data[1] 8;
+ }
Despite your comment, this is a 2 bytes scancode.
+ break;
+ default:
poll_result-rc_data = ir-urb_data[0]
- | ir-urb_data[1] 8;
+ | ir-urb_data[1] 8;
}
break;
default:
@@ -238,8 +250,6 @@ static void tm6000_ir_handle_key(struct tm6000_IR *ir)
return;
}
- dprintk(ir-get_key result data=%04x\n, poll_result.rc_data);
-
if (ir-pwled) {
if (ir-pwledcnt= PWLED_OFF) {
ir-pwled = 0;
@@ -250,6 +260,7 @@ static void tm6000_ir_handle_key(struct tm6000_IR *ir)
}
if (ir-key) {
+ dprintk(ir-get_key result data=%04x\n, poll_result.rc_data);
rc_keydown(ir-rc, poll_result.rc_data, 0);
ir-key = 0;
ir-pwled = 1;
@@ -333,7 +344,7 @@ int tm6000_ir_int_start(struct tm6000_core *dev)
ir-int_urb-transfer_buffer, size,
tm6000_ir_urb_received, dev,
dev-int_in.endp-desc.bInterval);
- err = usb_submit_urb(ir-int_urb, GFP_KERNEL);
+ err = usb_submit_urb(ir-int_urb, GFP_ATOMIC);
if (err) {
kfree(ir-int_urb-transfer_buffer);
usb_free_urb(ir-int_urb);
--
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: LinuxTV ported to Windows
2011/11/30 Abylay Ospan aos...@netup.ru: Hello, We have ported linuxtv's cx23885+CAM en50221+Diseq to Windows OS (Vista, XP, win7 tested). Results available under GPL and can be checkout from git repository: https://github.com/netup/netup-dvb-s2-ci-dual Binary builds (ready to install) available in build directory. Currently NetUP Dual DVB-S2 CI card supported ( http://www.netup.tv/en-EN/dual_dvb-s2-ci_card.php ). Driver based on Microsoft BDA standard, but some features (DiSEqC, CI) supported by custom API, for more details see netup_bda_api.h file. Any comments, suggestions are welcome. -- Abylai Ospanaos...@netup.ru NetUP Inc. Am I the only one who thinks this is a legally ambigious grey area? Seems like this could be a violation of the GPL as the driver code in question links against a proprietary kernel. I don't want to start a flame war, but I don't see how this is legal. And you could definitely question whether it goes against the intentions of the original authors to see their GPL driver code being used in non-free operating systems. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] af9013
Morjens Mauro, I rewrote whole af9013 demodulator driver in order to decrease I2C load. Please pull that to the next Kernel merge window. Antti The following changes since commit a235af24a74a0fa03ece0a9f5e28a72e4d1e2cad: ce168: remove experimental from Kconfig (2011-11-19 23:07:54 +0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git misc Antti Palosaari (1): af9013: rewrite whole driver drivers/media/dvb/dvb-usb/af9015.c| 82 +- drivers/media/dvb/frontends/af9013.c | 1756 ++--- drivers/media/dvb/frontends/af9013.h | 113 +- drivers/media/dvb/frontends/af9013_priv.h | 93 +- 4 files changed, 1017 insertions(+), 1027 deletions(-) -- http://palosaari.fi/ -- 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/PATCH v2 0/3] 64-bit integer menus
Hi all, This patchset, which I'm sending as RFC since it has not been really tested (including compiling the vivi patch), adds 64-bit integer menu controls. The control items in the integer menu are just like in regular menus but they are 64-bit integers instead of strings. I'm also pondering whether to assign 1 to ctrl-step for menu type controls as well but haven't checked what may have been the original reason to implement it as it is now implemented. The reason why I don't use a union for qmenu and qmenu_int in v4l2_ctrl_config is that a lot of drivers use that field in the initialiser and GCC 4.6 does not support initialisers with anonymous unions. Similar union is created in v4l2_querymenu but I do not see this as a problem since I do not expect initialisers to be used with this field in the user space code. Comments and questions are welcome. --- Changes since RFC/PATCH v1: - Fix documentation according to suggestions from Sylwester and Laurent. - Don't allow creating new standard integer menu controls using v4l2_ctrl_new_std_menu() since we don't have them yet. 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
[RFC/PATCH v2 1/3] v4l: Introduce integer menu controls
Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
controls are just like menu controls but the menu items are 64-bit integers
rather than strings.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/v4l2-ctrls.c | 60 +++--
include/linux/videodev2.h|6 +++-
include/media/v4l2-ctrls.h |6 +++-
3 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0f415da..083bb79 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -804,7 +804,8 @@ static void fill_event(struct v4l2_event *ev, struct
v4l2_ctrl *ctrl, u32 change
ev-u.ctrl.value64 = ctrl-cur.val64;
ev-u.ctrl.minimum = ctrl-minimum;
ev-u.ctrl.maximum = ctrl-maximum;
- if (ctrl-type == V4L2_CTRL_TYPE_MENU)
+ if (ctrl-type == V4L2_CTRL_TYPE_MENU
+ || ctrl-type == V4L2_CTRL_TYPE_INTEGER_MENU)
ev-u.ctrl.step = 1;
else
ev-u.ctrl.step = ctrl-step;
@@ -1035,10 +1036,13 @@ static int validate_new_int(const struct v4l2_ctrl
*ctrl, s32 *pval)
return 0;
case V4L2_CTRL_TYPE_MENU:
+ case V4L2_CTRL_TYPE_INTEGER_MENU:
if (val ctrl-minimum || val ctrl-maximum)
return -ERANGE;
- if (ctrl-qmenu[val][0] == '\0' ||
- (ctrl-menu_skip_mask (1 val)))
+ if (ctrl-menu_skip_mask (1 val))
+ return -EINVAL;
+ if (ctrl-type == V4L2_CTRL_TYPE_MENU
+ ctrl-qmenu[val][0] == '\0')
return -EINVAL;
return 0;
@@ -1295,7 +1299,8 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, const char *name, enum v4l2_ctrl_type type,
s32 min, s32 max, u32 step, s32 def,
- u32 flags, const char * const *qmenu, void *priv)
+ u32 flags, const char * const *qmenu,
+ const s64 *qmenu_int, void *priv)
{
struct v4l2_ctrl *ctrl;
unsigned sz_extra = 0;
@@ -1308,6 +1313,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
(type == V4L2_CTRL_TYPE_INTEGER step == 0) ||
(type == V4L2_CTRL_TYPE_BITMASK max == 0) ||
(type == V4L2_CTRL_TYPE_MENU qmenu == NULL) ||
+ (type == V4L2_CTRL_TYPE_INTEGER_MENU qmenu_int == NULL) ||
(type == V4L2_CTRL_TYPE_STRING max == 0)) {
handler_set_err(hdl, -ERANGE);
return NULL;
@@ -1318,6 +1324,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
}
if ((type == V4L2_CTRL_TYPE_INTEGER ||
type == V4L2_CTRL_TYPE_MENU ||
+type == V4L2_CTRL_TYPE_INTEGER_MENU ||
type == V4L2_CTRL_TYPE_BOOLEAN)
(def min || def max)) {
handler_set_err(hdl, -ERANGE);
@@ -1352,7 +1359,10 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
ctrl-minimum = min;
ctrl-maximum = max;
ctrl-step = step;
- ctrl-qmenu = qmenu;
+ if (type == V4L2_CTRL_TYPE_MENU)
+ ctrl-qmenu = qmenu;
+ else if (type == V4L2_CTRL_TYPE_INTEGER_MENU)
+ ctrl-qmenu_int = qmenu_int;
ctrl-priv = priv;
ctrl-cur.val = ctrl-val = ctrl-default_value = def;
@@ -1379,6 +1389,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
struct v4l2_ctrl *ctrl;
const char *name = cfg-name;
const char * const *qmenu = cfg-qmenu;
+ const s64 *qmenu_int = cfg-qmenu_int;
enum v4l2_ctrl_type type = cfg-type;
u32 flags = cfg-flags;
s32 min = cfg-min;
@@ -1390,18 +1401,24 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
v4l2_ctrl_fill(cfg-id, name, type, min, max, step,
def, flags);
- is_menu = (cfg-type == V4L2_CTRL_TYPE_MENU);
+ is_menu = (cfg-type == V4L2_CTRL_TYPE_MENU ||
+ cfg-type == V4L2_CTRL_TYPE_INTEGER_MENU);
if (is_menu)
WARN_ON(step);
else
WARN_ON(cfg-menu_skip_mask);
- if (is_menu qmenu == NULL)
+ if (cfg-type == V4L2_CTRL_TYPE_MENU qmenu == NULL)
qmenu = v4l2_ctrl_get_menu(cfg-id);
+ else if (cfg-type == V4L2_CTRL_TYPE_INTEGER_MENU
+qmenu_int == NULL) {
+ handler_set_err(hdl, -EINVAL);
+ return NULL;
+ }
ctrl = v4l2_ctrl_new(hdl, cfg-ops, cfg-id, name,
type, min, max,
is_menu ?
[RFC/PATCH v2 3/3] vivi: Add an integer menu test control
Add an integer menu test control for the vivi driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/vivi.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 7d754fb..763ec23 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -177,6 +177,7 @@ struct vivi_dev {
struct v4l2_ctrl *menu;
struct v4l2_ctrl *string;
struct v4l2_ctrl *bitmask;
+ struct v4l2_ctrl *int_menu;
spinlock_t slock;
struct mutex mutex;
@@ -503,6 +504,10 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct
vivi_buffer *buf)
dev-boolean-cur.val,
dev-menu-qmenu[dev-menu-cur.val],
dev-string-cur.string);
+ snprintf(str, sizeof(str), integer_menu %s, value %lld ,
+ dev-int_menu-qmenu[dev-int_menu-cur.val],
+ dev-int64-cur.val64);
+ gen_text(dev, vbuf, line++ * 16, 16, str);
mutex_unlock(dev-ctrl_handler.lock);
gen_text(dev, vbuf, line++ * 16, 16, str);
if (dev-button_pressed) {
@@ -1183,6 +1188,22 @@ static const struct v4l2_ctrl_config vivi_ctrl_bitmask =
{
.step = 0,
};
+static const s64 * const vivi_ctrl_int_menu_values[] = {
+ 1, 1, 2, 3, 5, 8, 13, 21, 42,
+};
+
+static const struct v4l2_ctrl_config vivi_ctrl_string = {
+ .ops = vivi_ctrl_ops,
+ .id = VIDI_CID_CUSTOM_BASE + 7
+ .name = Integer menu,
+ .type = V4L2_CTRL_TYPE_INTEGER_MENU,
+ .min = 1,
+ .max = 8,
+ .def = 4,
+ .menu_skip_mask = 0x02,
+ .qmenu_int = vivi_ctrl_int_menu_values,
+};
+
static const struct v4l2_file_operations vivi_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
--
1.7.2.5
--
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/PATCH v2 2/3] v4l: Document integer menu controls
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/compat.xml | 10 + Documentation/DocBook/media/v4l/v4l2.xml |7 .../DocBook/media/v4l/vidioc-queryctrl.xml | 39 +++- 3 files changed, 54 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index b68698f..569efd1 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.3/title + orderedlist +listitem + paraAdded integer menus, the new type will be + V4L2_CTRL_TYPE_INTEGER_MENU./para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 2ab365c..affe1ba 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the history chapter applications. -- revision + revnumber3.3/revnumber + date2011-11-24/date + authorinitialssa/authorinitials + revremarkAdded V4L2_CTRL_TYPE_INTEGER_MENU./revremark + /revision + + revision revnumber3.2/revnumber date2011-08-26/date authorinitialshv/authorinitials diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml index 0ac0057..02064b0 100644 --- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml +++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml @@ -215,11 +215,12 @@ the array to zero./entry table pgwide=1 frame=none id=v4l2-querymenu titlestruct structnamev4l2_querymenu/structname/title - tgroup cols=3 + tgroup cols=4 cs-str; tbody valign=top row entry__u32/entry + entry/entry entrystructfieldid/structfield/entry entryIdentifies the control, set by the application from the respective v4l2-queryctrl; @@ -227,18 +228,38 @@ from the respective v4l2-queryctrl; /row row entry__u32/entry + entry/entry entrystructfieldindex/structfield/entry entryIndex of the menu item, starting at zero, set by the application./entry /row row + entryunion/entry + entry/entry + entry/entry + entry/entry + /row + row + entry/entry entry__u8/entry entrystructfieldname/structfield[32]/entry entryName of the menu item, a NUL-terminated ASCII -string. This information is intended for the user./entry +string. This information is intended for the user. This field is valid +for constantV4L2_CTRL_FLAG_MENU/constant type controls./entry + /row + row + entry/entry + entry__s64/entry + entrystructfieldvalue/structfield/entry + entry + Value of the integer menu item. This field is valid for + constantV4L2_CTRL_FLAG_INTEGER_MENU/constant type + controls. +/entry /row row entry__u32/entry + entry/entry entrystructfieldreserved/structfield/entry entryReserved for future extensions. Drivers must set the array to zero./entry @@ -292,6 +313,20 @@ the menu items can be enumerated with the constantVIDIOC_QUERYMENU/constant ioctl./entry /row row + entryconstantV4L2_CTRL_TYPE_INTEGER_MENU/constant/entry + entryge; 0/entry + entry1/entry + entryN-1/entry + entry + The control has a menu of N choices. The values of the + menu items can be enumerated with the + constantVIDIOC_QUERYMENU/constant ioctl. This is + similar to constantV4L2_CTRL_TYPE_MENU/constant + except that instead of strings, the menu items are + signed 64-bit integers. +/entry + /row + row entryconstantV4L2_CTRL_TYPE_BITMASK/constant/entry entry0/entry entryn/a/entry -- 1.7.2.5 -- 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: LinuxTV ported to Windows
On 30.11.2011 18:23, Devin Heitmueller wrote: 2011/11/30 Abylay Ospan aos...@netup.ru: Hello, We have ported linuxtv's cx23885+CAM en50221+Diseq to Windows OS (Vista, XP, win7 tested). Results available under GPL and can be checkout from git repository: https://github.com/netup/netup-dvb-s2-ci-dual That's nice to hear, Abylay! Binary builds (ready to install) available in build directory. Currently NetUP Dual DVB-S2 CI card supported ( http://www.netup.tv/en-EN/dual_dvb-s2-ci_card.php ). Driver based on Microsoft BDA standard, but some features (DiSEqC, CI) supported by custom API, for more details see netup_bda_api.h file. Any comments, suggestions are welcome. -- Abylai Ospanaos...@netup.ru NetUP Inc. Am I the only one who thinks this is a legally ambigious grey area? Seems like this could be a violation of the GPL as the driver code in question links against a proprietary kernel. Devin, please! Are you implying that the windows kernel becomes a derived work of the driver, or that it's generally impossible to publish windows drivers under the terms of the GPL? I don't want to start a flame war, but I don't see how this is legal. And you could definitely question whether it goes against the intentions of the original authors to see their GPL driver code being used in non-free operating systems. The GPL doesn't cover such intentions. Regards, Andreas P.S.: The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] [media] tm6000: fix OOPS at tm6000_ir_int_stop() and tm6000_ir_int_start()
[ 3755.608233] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 3755.616360] IP: [a03b80b7] tm6000_ir_int_stop+0x10/0x1b [tm6000]
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/tm6000/tm6000-input.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-input.c
b/drivers/media/video/tm6000/tm6000-input.c
index e3467d4..af4bcf5 100644
--- a/drivers/media/video/tm6000/tm6000-input.c
+++ b/drivers/media/video/tm6000/tm6000-input.c
@@ -377,6 +377,9 @@ int tm6000_ir_int_start(struct tm6000_core *dev)
{
struct tm6000_IR *ir = dev-ir;
+ if (!ir)
+ return;
+
return __tm6000_ir_int_start(ir-rc);
}
@@ -384,6 +387,9 @@ void tm6000_ir_int_stop(struct tm6000_core *dev)
{
struct tm6000_IR *ir = dev-ir;
+ if (!ir || !ir-rc)
+ return;
+
__tm6000_ir_int_stop(ir-rc);
}
--
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
[PATCH 1/2] [media] tm6000: automatically load alsa and dvb modules
All devices should support alsa module. Devices with DVB will
auto-load the dvb module. This way, tm6000-based devices should
now have hot plugin.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/tm6000/tm6000-cards.c | 31 +
drivers/media/video/tm6000/tm6000.h |3 ++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tm6000/tm6000-cards.c
b/drivers/media/video/tm6000/tm6000-cards.c
index 3873ce4..6b74259 100644
--- a/drivers/media/video/tm6000/tm6000-cards.c
+++ b/drivers/media/video/tm6000/tm6000-cards.c
@@ -1052,6 +1052,33 @@ static void use_alternative_detection_method(struct
tm6000_core *dev)
tm6000_boards[model].name, model);
}
+#if defined(CONFIG_MODULES) defined(MODULE)
+static void request_module_async(struct work_struct *work)
+{
+ struct tm6000_core *dev = container_of(work, struct tm6000_core,
+ request_module_wk);
+
+ request_module(tm6000-alsa);
+
+ if (dev-caps.has_dvb)
+ request_module(tm6000-dvb);
+}
+
+static void request_modules(struct tm6000_core *dev)
+{
+ INIT_WORK(dev-request_module_wk, request_module_async);
+ schedule_work(dev-request_module_wk);
+}
+
+static void flush_request_modules(struct tm6000_core *dev)
+{
+ flush_work_sync(dev-request_module_wk);
+}
+#else
+#define request_modules(dev)
+#define flush_request_modules(dev)
+#endif /* CONFIG_MODULES */
+
static int tm6000_init_dev(struct tm6000_core *dev)
{
struct v4l2_frequency f;
@@ -1114,6 +1141,8 @@ static int tm6000_init_dev(struct tm6000_core *dev)
tm6000_ir_init(dev);
+ request_modules(dev);
+
mutex_unlock(dev-lock);
return 0;
@@ -1326,6 +1355,8 @@ static void tm6000_usb_disconnect(struct usb_interface
*interface)
printk(KERN_INFO tm6000: disconnecting %s\n, dev-name);
+ flush_request_modules(dev);
+
tm6000_ir_fini(dev);
if (dev-gpio.power_led) {
diff --git a/drivers/media/video/tm6000/tm6000.h
b/drivers/media/video/tm6000/tm6000.h
index 2777e51..27ba659 100644
--- a/drivers/media/video/tm6000/tm6000.h
+++ b/drivers/media/video/tm6000/tm6000.h
@@ -188,6 +188,9 @@ struct tm6000_core {
/* Device Capabilities*/
struct tm6000_capabilities caps;
+ /* Used to load alsa/dvb */
+struct work_struct request_module_wk;
+
/* Tuner configuration */
int tuner_type; /* type of the
tuner */
int tuner_addr; /* tuner
address */
--
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:Wed Nov 30 19:00:16 CET 2011 git hash:36d36b884c745c507d9b3f60eb42925749f7d758 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: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LinuxTV ported to Windows
Nice! How is the CI implementation? Can both CI's be used by both tuners? Or is one CI bound to one tuner? Walter On Wed, 30 Nov 2011 19:39:34 +0300, Abylay Ospan aos...@netup.ru wrote: Hello, We have ported linuxtv's cx23885+CAM en50221+Diseq to Windows OS (Vista, XP, win7 tested). Results available under GPL and can be checkout from git repository: https://github.com/netup/netup-dvb-s2-ci-dual Binary builds (ready to install) available in build directory. Currently NetUP Dual DVB-S2 CI card supported ( http://www.netup.tv/en-EN/dual_dvb-s2-ci_card.php ). Driver based on Microsoft BDA standard, but some features (DiSEqC, CI) supported by custom API, for more details see netup_bda_api.h file. Any comments, suggestions are welcome. -- 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: LinuxTV ported to Windows
On Wed, Nov 30, 2011 at 1:02 PM, Andreas Oberritter o...@linuxtv.org wrote: Am I the only one who thinks this is a legally ambigious grey area? Seems like this could be a violation of the GPL as the driver code in question links against a proprietary kernel. Devin, please! Are you implying that the windows kernel becomes a derived work of the driver, or that it's generally impossible to publish windows drivers under the terms of the GPL? The simple answer is that I don't know. I'm not a lawyer (and as far as I know, neither are you). Nor have I researched the topic to significant lengths. That said though, whether it was the intention of either copyright holder it's entirely possible that the two software licenses are simply incompatible. For example, while both the Apache group and the FSF never really intended to prevent each others' software from being linked against each other, the net effect is still that you cannot redistribute such software together since the Apache license is incompatible with the GPL. I don't want to start a flame war, but I don't see how this is legal. And you could definitely question whether it goes against the intentions of the original authors to see their GPL driver code being used in non-free operating systems. The GPL doesn't cover such intentions. This isn't necessarily true. Anybody who has written a library and released it under the GPL instead of the LGPL has made a conscious decision that the library is only to be used by software that is GPL compatible. By their actions they have inherently forbidden it's use by non-free software. You could certainly make the same argument about a driver -- that they authors intent was to ensure that it only be linked against other free software. All this said, I don't really have a position one way or the other (I'm not a copyright holder on the drivers in question). But this issue doesn't seem as obvious as you would make it sound. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx: Add Terratec Cinergy HTC Stick
Dear Andreas, On Tuesday, November 29, 2011 01:56:35 PM you wrote: snip 2. I stumbled over http://linux.terratec.de/tv_en.html where they list a NXP TDA18271 as used tuner for H5 and HTC Stick devices. I dont have any experience in this kind of stuff but i am just asking. That's right. So this should be made like the other devices which are using the TDA18271? Or is there no driver for this tuner yet? I don't understand your question. Both TERRATEC H5 and Cinergy HTC Stick are already supported by Linux (at least for digital signals, the latter since the patch you're referring to), so a driver for every relevant chip, including TDA18271, is already involved. If i remember correctly there was used another tuner driver in the out commended code. Is this just a coyp paste leftover? Regards, Jens -- 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: LinuxTV ported to Windows
On 30.11.2011 20:33, Devin Heitmueller wrote: On Wed, Nov 30, 2011 at 1:02 PM, Andreas Oberritter o...@linuxtv.org wrote: Am I the only one who thinks this is a legally ambigious grey area? Seems like this could be a violation of the GPL as the driver code in question links against a proprietary kernel. Devin, please! Are you implying that the windows kernel becomes a derived work of the driver, or that it's generally impossible to publish windows drivers under the terms of the GPL? The simple answer is that I don't know. I'm not a lawyer (and as far as I know, neither are you). Nor have I researched the topic to significant lengths. That said though, whether it was the intention of either copyright holder it's entirely possible that the two software licenses are simply incompatible. For example, while both the Apache group and the FSF never really intended to prevent each others' software from being linked against each other, the net effect is still that you cannot redistribute such software together since the Apache license is incompatible with the GPL. Neither is Abylay distributing Windows together with this driver, nor is this driver a library Windows links against, i.e. Windows is able to run with this driver removed. I don't want to start a flame war, but I don't see how this is legal. And you could definitely question whether it goes against the intentions of the original authors to see their GPL driver code being used in non-free operating systems. The GPL doesn't cover such intentions. This isn't necessarily true. Anybody who has written a library and released it under the GPL instead of the LGPL has made a conscious decision that the library is only to be used by software that is GPL compatible. By their actions they have inherently forbidden it's use by non-free software. You could certainly make the same argument about a driver -- that they authors intent was to ensure that it only be linked against other free software. That's something completely different than being used in non-free operating systems and not necessarily comparable to a driver, which implements a well-defined interface. The point I'm trying to make: Someone made a presumably nice open source port to a new platform and the first thing you're doing is to play the GPL-has-been-violated-card, even though you're admitting that you don't know whether any right is being violated or not. Please don't do that. It's not very encouraging to someone who just announced free software. 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: LinuxTV ported to Windows
On Wed, Nov 30, 2011 at 2:58 PM, Andreas Oberritter o...@linuxtv.org wrote: The point I'm trying to make: Someone made a presumably nice open source port to a new platform and the first thing you're doing is to play the GPL-has-been-violated-card, even though you're admitting that you don't know whether any right is being violated or not. Please don't do that. It's not very encouraging to someone who just announced free software. To be clear, at no point did I say the GPL has been violated. I am *asking* if others think this represents a GPL violation since at first glance it appears that this software very well might. I don't really have a problem with GPL drivers running on Windows. But if I were the original author of one of the drivers Abylay has ported, I might think differently. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v2 0/3] 64-bit integer menus
Hi Sakari, Thanks for the patches. They look good to me. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com On Wednesday 30 November 2011 18:38:21 Sakari Ailus wrote: Hi all, This patchset, which I'm sending as RFC since it has not been really tested (including compiling the vivi patch), adds 64-bit integer menu controls. The control items in the integer menu are just like in regular menus but they are 64-bit integers instead of strings. I'm also pondering whether to assign 1 to ctrl-step for menu type controls as well but haven't checked what may have been the original reason to implement it as it is now implemented. The reason why I don't use a union for qmenu and qmenu_int in v4l2_ctrl_config is that a lot of drivers use that field in the initialiser and GCC 4.6 does not support initialisers with anonymous unions. Similar union is created in v4l2_querymenu but I do not see this as a problem since I do not expect initialisers to be used with this field in the user space code. Comments and questions are welcome. --- Changes since RFC/PATCH v1: - Fix documentation according to suggestions from Sylwester and Laurent. - Don't allow creating new standard integer menu controls using v4l2_ctrl_new_std_menu() since we don't have them yet. Kind regards, -- 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] em28xx: Add Terratec Cinergy HTC Stick
On 30.11.2011 20:39, Jens Erdmann wrote: Dear Andreas, On Tuesday, November 29, 2011 01:56:35 PM you wrote: snip 2. I stumbled over http://linux.terratec.de/tv_en.html where they list a NXP TDA18271 as used tuner for H5 and HTC Stick devices. I dont have any experience in this kind of stuff but i am just asking. That's right. So this should be made like the other devices which are using the TDA18271? Or is there no driver for this tuner yet? I don't understand your question. Both TERRATEC H5 and Cinergy HTC Stick are already supported by Linux (at least for digital signals, the latter since the patch you're referring to), so a driver for every relevant chip, including TDA18271, is already involved. If i remember correctly there was used another tuner driver in the out commended code. Is this just a coyp paste leftover? Hm. When Mauro committed the patch, the description got lost: - Can receive DVB-C and DVB-T. No analogue television or radio yet. - For now it's a copy of the Terratec H5 code with a different name. So, to answer your question: The disabled code was copied from the H5 right above the new code, in the hope that if someone is going to fix analogue TV for the H5, he or she might just fix it for the HTC Stick as well, assuming that there's only little or no difference. HTH, 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
[PATCH 0/3] it913x add support for 9005 versions
Malcolm Priestley (3): [For 3.3] dvb-usb-it913x multi firmware loader [for 3.3] add support for IT9135 9005 devices [For 3.3] it913x dvb-get-firmware update Documentation/dvb/get_dvb_firmware | 22 +- drivers/media/dvb/dvb-usb/dvb-usb-ids.h |1 + drivers/media/dvb/dvb-usb/it913x.c | 69 +- 3 files changed, 70 insertions(+), 22 deletions(-) -- 1.7.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [for 3.3] add support for IT9135 9005 devices.
Support add for IT9135 9005 devices
With this patch IT9135 devices now move to using
dvb-usb-it9135-01.fw firmware
IT9137 remain on previous firmware.
IT9135 devices seem more stable on this firmware.
If the user wishes to remain on it9137 firmware they can change
back using firmware=1 module option.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/dvb-usb-ids.h |1 +
drivers/media/dvb/dvb-usb/it913x.c | 26 --
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
index 18be4b1..3cce13b 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -131,6 +131,7 @@
#define USB_PID_GRANDTEC_DVBT_USB_WARM 0x0fa1
#define USB_PID_INTEL_CE9500 0x9500
#define USB_PID_ITETECH_IT9135 0x9135
+#define USB_PID_ITETECH_IT9135_90050x9005
#define USB_PID_KWORLD_399U0xe399
#define USB_PID_KWORLD_399U_2 0xe400
#define USB_PID_KWORLD_395U0xe396
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index c7bf03c..d7c86c2 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -52,6 +52,11 @@ static int pid_filter;
module_param_named(pid, pid_filter, int, 0644);
MODULE_PARM_DESC(pid, set default 0=on 1=off);
+static int dvb_usb_it913x_firmware;
+module_param_named(firmware, dvb_usb_it913x_firmware, int, 0644);
+MODULE_PARM_DESC(firmware, set firmware 0=auto 1=IT9137 2=IT9135V1);
+
+
int cmd_counter;
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -340,6 +345,10 @@ static int it913x_rc_query(struct dvb_usb_device *d)
return ret;
}
+/* Firmware sets raw */
+const char fw_it9135_v1[] = dvb-usb-it9135-01.fw;
+const char fw_it9137[] = dvb-usb-it9137-01.fw;
+
static int ite_firmware_select(struct usb_device *udev,
struct dvb_usb_device_properties *props)
{
@@ -348,18 +357,27 @@ static int ite_firmware_select(struct usb_device *udev,
if (le16_to_cpu(udev-descriptor.idProduct) ==
USB_PID_ITETECH_IT9135)
sw = IT9135_V1_FW;
+ else if (le16_to_cpu(udev-descriptor.idProduct) ==
+ USB_PID_ITETECH_IT9135_9005)
+ sw = IT9135_V1_FW;
else
sw = IT9137_FW;
+ /* force switch */
+ if (dvb_usb_it913x_firmware != IT9135_AUTO)
+ sw = dvb_usb_it913x_firmware;
+
switch (sw) {
case IT9135_V1_FW:
- it913x_config.firmware_ver = 0;
+ it913x_config.firmware_ver = 1;
it913x_config.adc_x2 = 1;
+ props-firmware = fw_it9135_v1;
break;
case IT9137_FW:
default:
it913x_config.firmware_ver = 0;
it913x_config.adc_x2 = 0;
+ props-firmware = fw_it9137;
}
return 0;
@@ -636,6 +654,7 @@ static struct usb_device_id it913x_table[] = {
{ USB_DEVICE(USB_VID_KWORLD_2, USB_PID_KWORLD_UB499_2T_T09) },
{ USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9135) },
{ USB_DEVICE(USB_VID_KWORLD_2, USB_PID_SVEON_STV22_IT9137) },
+ { USB_DEVICE(USB_VID_ITETECH, USB_PID_ITETECH_IT9135_9005) },
{} /* Terminating entry */
};
@@ -722,6 +741,9 @@ static struct dvb_usb_device_properties it913x_properties =
{
{ Sveon STV22 Dual DVB-T HDTV(IT9137),
{ it913x_table[2], NULL },
},
+ { ITE 9135(9005) Generic,
+ { it913x_table[3], NULL },
+ },
}
};
@@ -755,5 +777,5 @@ module_exit(it913x_module_exit);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
-MODULE_VERSION(1.11);
+MODULE_VERSION(1.14);
MODULE_LICENSE(GPL);
--
1.7.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [For 3.3] it913x dvb-get-firmware update
Changes to extract firmware for it913x devices
./get_dvb_firmware it9135
extracts
dvb-usb-it9135-01.fw
dvb-usb-it9135-02.fw
./get_dvb_firmware it9137
extracts
dvb-usb-it9137-01.fw
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
Documentation/dvb/get_dvb_firmware | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index 0f15ab7..d1d4a17 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -28,7 +28,7 @@ use IO::Handle;
opera1, cx231xx, cx18, cx23885, pvrusb2, mpc718,
af9015, ngene, az6027, lme2510_lg, lme2510c_s7395,
lme2510c_s7395_old, drxk, drxk_terratec_h5,
- drxk_hauppauge_hvr930c, tda10071, it9135 );
+ drxk_hauppauge_hvr930c, tda10071, it9135, it9137);
# Check args
syntax() if (scalar(@ARGV) != 1);
@@ -676,6 +676,26 @@ sub drxk_terratec_h5 {
}
sub it9135 {
+ my $sourcefile = dvb-usb-it9135.zip;
+ my $url = http://www.ite.com.tw/uploads/firmware/v3.6.0.0/$sourcefile;;
+ my $hash = 1e55f6c8833f1d0ae067c2bb2953e6a9;
+ my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 0);
+ my $outfile = dvb-usb-it9135.fw;
+ my $fwfile1 = dvb-usb-it9135-01.fw;
+ my $fwfile2 = dvb-usb-it9135-02.fw;
+
+ checkstandard();
+
+ wgetfile($sourcefile, $url);
+ unzip($sourcefile, $tmpdir);
+ verify($tmpdir/$outfile, $hash);
+ extract($tmpdir/$outfile, 64, 8128, $fwfile1);
+ extract($tmpdir/$outfile, 12866, 5817, $fwfile2);
+
+ $fwfile1 $fwfile2
+}
+
+sub it9137 {
my $url = http://kworld.server261.com/kworld/CD/ITE_TiVme/V1.00/;;
my $zipfile = Driver_V10.323.1.0412.100412.zip;
my $hash = 79b597dc648698ed6820845c0c9d0d37;
--
1.7.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx: Add Terratec Cinergy HTC Stick
On 30-11-2011 18:41, Andreas Oberritter wrote: On 30.11.2011 20:39, Jens Erdmann wrote: Dear Andreas, On Tuesday, November 29, 2011 01:56:35 PM you wrote: snip 2. I stumbled over http://linux.terratec.de/tv_en.html where they list a NXP TDA18271 as used tuner for H5 and HTC Stick devices. I dont have any experience in this kind of stuff but i am just asking. That's right. So this should be made like the other devices which are using the TDA18271? Or is there no driver for this tuner yet? I don't understand your question. Both TERRATEC H5 and Cinergy HTC Stick are already supported by Linux (at least for digital signals, the latter since the patch you're referring to), so a driver for every relevant chip, including TDA18271, is already involved. If i remember correctly there was used another tuner driver in the out commended code. Is this just a coyp paste leftover? Hm. When Mauro committed the patch, the description got lost: - Can receive DVB-C and DVB-T. No analogue television or radio yet. - For now it's a copy of the Terratec H5 code with a different name. Gah! sorry for that. Not sure what happened there. I'll try to remember about it when sending upstream, in order to recover the original comment. Feel free to ping me closer to the next merge window, in order to remind me. So, to answer your question: The disabled code was copied from the H5 right above the new code, in the hope that if someone is going to fix analogue TV for the H5, he or she might just fix it for the HTC Stick as well, assuming that there's only little or no difference. Support for analog is not trivial, as it requires writing a driver for tvf4910b. Not sure if is there any publicly released driver with some code for it. Maybe this could be done via sniffing the USB traffic, but, if this device is as complicated as DRX, then I doubt people would try to do it. HTH, 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 -- 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 FOR 3.2 FIX] af9015: limit I2C access to keep FW happy
On Tue, 2011-11-29 at 02:09 +0200, Antti Palosaari wrote: On 11/15/2011 12:25 AM, Malcolm Priestley wrote: I have tried this patch, while it initially got MythTV working, there is too many call backs and some failed to acquire the lock. The device became unstable on both single and dual devices. The callbacks af9015_af9013_read_status, af9015_af9013_init af9015_af9013_sleep had to be removed. I take your point, a call back can be an alternative. The patch didn't stop the firmware fails either. The af9015 usb bridge on the whole is so unstable in its early stages, especially on a cold boot and when the USB controller has another device on it, such as card reader or wifi device. I am, at the moment looking to see if the fails are due to interface 1 being claimed by HID. I just got af9013 rewrite ready. Feel free to test. http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/misc It reduces typical statistics polling load maybe 1/4 from the original. I see still small glitch when switching to channel. That seems to come from tuner driver I2C load. There is 3 tuners used for dual devices; MXL5005S, MXL5007T and TDA18271. I have only MXL5005S and MXL5007T dual devices here. MXL5005S is worse than MXL5007T but both makes still rather much I/O. I have had a quick test of this patch, it seems a lot better. I will do more testing on my troublesome PC and Mythtv at the weekend. Regards Malcolm -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
Hi folks. I need to warn you that my mail is a bit little longer then I would like to be.But I'm not able to ask my question without some background information. On June 19th, I was sending the driver to the Linux-media mailing list. Original announcement is there: http://www.spinics.net/lists/linux-media/msg34240.html One would say that the code describes very well what it does = adds virtual DVB device. To be more clear on it I have even done some small picture: http://www.nessiedvb.org/wiki/doku.php?id=vtuner_bigpicture I was hoping to get any feedback regarding code implementation. It was my first code for the kernel and I felt very well that some part can be done better or even simpler. What really surprised me badly was that when I read all 54 responses I have counted only two real technical answers!!! All rest were about POLITICAL issues - code was NACKed w/o any technical discussion. Because of fear of possible abusing of driver. I didn't know that there existed very big movement against such code in dvb-core subsystem before. I have one big problem with it. I can even imagine that some bad guys could abuse virtual driver to use it for distribution close-source drivers in the binary blobs. But is it that - worrying about bad boys abusing - the sufficient reason for such aggressive NACK which I did? Then would be better to remove loadable module API fully from kernel. Is it the right way? Please confirm me that worrying about abusive act is enough to NACK particular driver. Then I may be definitely understand I'm doing something wrong and will stay (with such enemy driver) out of tree. I can't understand that because I see very similar drivers in kernel for ages (nbd, or even more similar is usbip) and seems they don't hamper to anybody. I would like to note that I don't want to start any flame-war, so very short answer would be enough for me. Regards Honza PS: Please be so kind and CC the answer/comment to me, I'm only on linux-media ML, not on linux-kernel ML. Thanks. BTW, if accidentally, somebody find it interesting and would like to help me doing code review, there is the code hosted now: http://code.google.com/p/vtuner/source/browse?repo=linux-driver -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Wed, Nov 30, 2011 at 4:38 PM, HoP jpetr...@gmail.com wrote: Hi folks. I need to warn you that my mail is a bit little longer then I would like to be.But I'm not able to ask my question without some background information. On June 19th, I was sending the driver to the Linux-media mailing list. Original announcement is there: http://www.spinics.net/lists/linux-media/msg34240.html One would say that the code describes very well what it does = adds virtual DVB device. To be more clear on it I have even done some small picture: http://www.nessiedvb.org/wiki/doku.php?id=vtuner_bigpicture I was hoping to get any feedback regarding code implementation. It was my first code for the kernel and I felt very well that some part can be done better or even simpler. What really surprised me badly was that when I read all 54 responses I have counted only two real technical answers!!! All rest were about POLITICAL issues - code was NACKed w/o any technical discussion. Because of fear of possible abusing of driver. I didn't know that there existed very big movement against such code in dvb-core subsystem before. I have one big problem with it. I can even imagine that some bad guys could abuse virtual driver to use it for distribution close-source drivers in the binary blobs. But is it that - worrying about bad boys abusing - the sufficient reason for such aggressive NACK which I did? Then would be better to remove loadable module API fully from kernel. Is it the right way? Please confirm me that worrying about abusive act is enough to NACK particular driver. Then I may be definitely understand I'm doing something wrong and will stay (with such enemy driver) out of tree. I can't understand that because I see very similar drivers in kernel for ages (nbd, or even more similar is usbip) and seems they don't hamper to anybody. I would like to note that I don't want to start any flame-war, so very short answer would be enough for me. Regards Honza PS: Please be so kind and CC the answer/comment to me, I'm only on linux-media ML, not on linux-kernel ML. Thanks. BTW, if accidentally, somebody find it interesting and would like to help me doing code review, there is the code hosted now: http://code.google.com/p/vtuner/source/browse?repo=linux-driver Honza, I, for one, would love to see your virtual DVB device driver hosted in a repository for the purposes of experimentation and additional development. I can think of many, many good uses for such a virtual device driver. Unfortunately, however, all the device vendors also have uses for it. It a guarunteed fact that if a driver like that got merged into the kernel, any software company that previously sponsored open-source kernel development would opt instead for closed source userspace drivers that depend on a virtual DVB device. Please don't let that discourage you -- I think you should continue your work on this virtual DVB device driver, and I'd love to play with it myself, and possibly even contribute to it. ...but I will never support the merging of this into the kernel. I do not nack the existence of the driver -- I love the idea, and I encourage more development. I only nack it's merging into any open-source linux kernel. Please accept my answer with the greatest intentions for furthering the development of the open-source community. My opinion is only for the best intentions of continued contributions from companies such as Hauppauge and any others that have contributed thus far to v4l/dvb. Please, keep up the work. I repeat -- I would love to play with your work. Best regards, Mike Krufky -- 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] omap3isp: video: Don't WARN() on unknown pixel formats
Hi Sakari,
On Wednesday 30 November 2011 09:35:38 Sakari Ailus wrote:
Laurent Pinchart wrote:
On Monday 28 November 2011 17:01:12 Sakari Ailus wrote:
On Mon, Nov 28, 2011 at 12:37:34PM +0100, Laurent Pinchart wrote:
When mapping from a V4L2 pixel format to a media bus format in the
VIDIOC_TRY_FMT and VIDIOC_S_FMT handlers, the requested format may be
unsupported by the driver. Return a hardcoded format instead of
WARN()ing in that case.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/omap3isp/ispvideo.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d100072..ffe7ce9 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -210,14 +210,14 @@ static void isp_video_pix_to_mbus(const struct
v4l2_pix_format *pix,
mbus-width = pix-width;
mbus-height = pix-height;
- for (i = 0; i ARRAY_SIZE(formats); ++i) {
+ /* Skip the last format in the loop so that it will be selected if
no
+ * match is found.
+ */
+ for (i = 0; i ARRAY_SIZE(formats) - 1; ++i) {
if (formats[i].pixelformat == pix-pixelformat)
break;
}
- if (WARN_ON(i == ARRAY_SIZE(formats)))
- return;
-
mbus-code = formats[i].code;
mbus-colorspace = pix-colorspace;
mbus-field = pix-field;
In case of setting or trying an invalid format, instead of selecting a
default format, shouldn't we leave the format unchanced --- the current
setting is valid after all.
TRY/SET operations must succeed. The format we select when an invalid
format is requested isn't specified. We could keep the current format,
but wouldn't that be more confusing for applications ? The format they
would get in response to a TRY/SET operation would then potentially
depend on the previous SET operations.
I don't think a change to something that has nothing to do what was
requested is better than not changing it. The application has requested
a particular format; changing it to something else isn't useful for the
application. And if the application would try more than invalid format
in a row, they both would yield to the same default format.
I would personally not change it.
I can agree with you for S_FMT, but I have more doubts about TRY_FMT. Making
TRY_FMT return the current format if the requested format is not supported
seems confusing to me. And if we make TRY_FMT return a fixed format in that
case, why not making S_FMT do the same ? :-)
What I can find in the spec is this:
When the application calls the VIDIOC_S_FMT ioctl with a pointer to a
v4l2_format structure the driver checks and adjusts the parameters
against hardware abilities.
I wonder how other drivers behave.
uvcvideo returns -EINVAL, which I think should be fixed.
The sensor drivers I wrote return a fixed format (this isn't strictly
S_FMT/TRY_FMT, but I think it's related).
--
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: Using MT9P031 digital sensor
Hi Gary, On Wednesday 30 November 2011 15:57:30 Gary Thomas wrote: On 2011-11-30 07:30, Laurent Pinchart wrote: On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: On 2011-11-28 05:49, Laurent Pinchart wrote: On Monday 28 November 2011 13:42:47 Gary Thomas wrote: On 2011-11-28 04:07, Laurent Pinchart wrote: On Friday 25 November 2011 12:50:25 Gary Thomas wrote: On 2011-11-24 04:28, Laurent Pinchart wrote: On Wednesday 16 November 2011 13:03:11 Gary Thomas wrote: On 2011-11-15 18:26, Laurent Pinchart wrote: On Monday 14 November 2011 12:42:54 Gary Thomas wrote: [snip] Here's my pipeline: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 642x483]' The full media-ctl dump is at http://www.mlbassoc.com/misc/pipeline.out When I try to grab from /dev/video6 (output node of resizer), I see only previewer interrupts, no resizer interrrupts. I added a simple printk at each of the previewer/resizer *_isr functions, and I only ever see this one: omap3isp_preview_isr_frame_sync.1373 Can you give me an overview of what events/interrupts should occur so I can try to trace through the ISP to see where it is failing? The CCDC generates VD0, VD1 and HS/VS interrupts regardless of whether it processes video or not, as long as it receives a video stream at its input. The preview engine and resizer will only generate an interrupt after writing an image to memory. With your above configuration VD0, VD1, HS/VS and resizer interrupts should be generated. Your pipeline configuration looks correct, except that the downscaling factor is slightly larger than 4. Could you try to setup the resizer to output a 2574x1935 image instead of 642x483 ? If that works, try to downscale to 660x496. If that works as well, the driver should be fixed to disallow resolutions that won't work. No change. I also tried using only the previewer like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP preview output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP preview:1 [YUYV 2574x1935]' yavta --capture=4 -f YUYV -s 2574x1935 -F /dev/video4 I still only get the frame sync interrupts in the previewer, no buffer interrupts, hence no data flowing to my application. What else can I look at? Do you get VD0 and VD1 interrupts ? Yes, the CCDC is working correctly, but nothing moves through the previewer. Here's a trace of the interrupt sequence I get, repeated over and over. These are printed as __FUNCTION__.__LINE__ --- ccdc_vd0_isr.1615 --- ccdc_hs_vs_isr.1482 --- ccdc_vd1_isr.1664 --- omap3isp_preview_isr_frame_sync.1373 What's the best tree to try this against? 3.2-rc2 doesn't have the BT656 stuff in it yet, so I've been still using my older tree (3.0.0 + drivers/media from your tree) I thought you were using an MT9P031 ? That doesn't require BT656 support. True, but I have one board that supports either sensor and I want to stay with one source tree. Sure, but let's start with a non-BT656 tree to rule out issues caused by BT656 patches. Could you please try mainline v3.1 ? This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting
Re: Using MT9P031 digital sensor
Hi Gary, On Wednesday 30 November 2011 18:00:55 Gary Thomas wrote: On 2011-11-30 07:57, Gary Thomas wrote: On 2011-11-30 07:30, Laurent Pinchart wrote: On Wednesday 30 November 2011 15:13:18 Gary Thomas wrote: [snip] This sort of works(*), but I'm still having issues (at least I can move frames!) When I configure the pipeline like this: media-ctl -r media-ctl -l 'mt9p031 3-005d:0-OMAP3 ISP CCDC:0[1]' media-ctl -l 'OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1]' media-ctl -l 'OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1]' media-ctl -l 'OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' media-ctl -f 'mt9p031 3-005d:0[SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:0 [SGRBG12 2592x1944]' media-ctl -f 'OMAP3 ISP CCDC:1 [SGRBG10 2592x1944]' media-ctl -f 'OMAP3 ISP preview:0 [SGRBG10 2592x1943]' media-ctl -f 'OMAP3 ISP resizer:0 [YUYV 2574x1935]' media-ctl -f 'OMAP3 ISP resizer:1 [YUYV 660x496]' the resulting frames are 24 bytes each instead of 654720 When I tried to grab from the previewer, the frames were 9969120 instead of 9961380 Any ideas what resolution is actually being moved through? Because the OMAP3 ISP has alignment requirements. Both the preview engine and the resizer output line lenghts must be multiple of 32 bytes. The driver adds padding at end of lines when the output width isn't a multiple of 16 pixels. Any guess which resolution(s) I should change and to what? I changed the resizer output to be 672x496 and was able to capture video using ffmpeg. I don't know what to expect with this sensor (I've never seen it in use before), but the image seems to have color balance issues - it's awash in a green hue. It may be the poor lighting in my office... I did try the 9 test patterns which I was able to select via # v4l2-ctl -d /dev/v4l-subdev8 --set-ctrl=test_pattern=N and these looked OK. You can see them at http://www.mlbassoc.com/misc/mt9p031_images/ Neither the sensor nor the OMAP3 ISP implement automatic white balance. The ISP preview engine can be used to modify the white balance, and the statistics engine can be used to extract data useful to compute the white balance parameters, but linking the two needs to be performed in userspace. So this means that your original problem comes from the BT656 patches. Yes, it does look that way. Now that I have something that moves data, I can compare how the ISP is setup between the two versions and come up with a fix. This is next on my plate, but it may take a while to figure it out. Is there some recent tree which will have this digital (mt9p031) part working that also has the BT656 support in it? I'd like to try that rather than spending time figuring out why an older tree isn't working. No, I haven't had time to create one, sorry. It shouldn't be difficult to rebase the BT656 patches on top of the latest OMAP3 ISP and MT9P031 code. -- 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] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On 30.11.2011 22:38, HoP wrote: Hi folks. I need to warn you that my mail is a bit little longer then I would like to be.But I'm not able to ask my question without some background information. On June 19th, I was sending the driver to the Linux-media mailing list. Original announcement is there: http://www.spinics.net/lists/linux-media/msg34240.html One would say that the code describes very well what it does = adds virtual DVB device. To be more clear on it I have even done some small picture: http://www.nessiedvb.org/wiki/doku.php?id=vtuner_bigpicture I was hoping to get any feedback regarding code implementation. It was my first code for the kernel and I felt very well that some part can be done better or even simpler. What really surprised me badly was that when I read all 54 responses I have counted only two real technical answers!!! All rest were about POLITICAL issues - code was NACKed w/o any technical discussion. Because of fear of possible abusing of driver. I didn't know that there existed very big movement against such code in dvb-core subsystem before. I have one big problem with it. I can even imagine that some bad guys could abuse virtual driver to use it for distribution close-source drivers in the binary blobs. But is it that - worrying about bad boys abusing - the sufficient reason for such aggressive NACK which I did? Then would be better to remove loadable module API fully from kernel. Is it the right way? Please confirm me that worrying about abusive act is enough to NACK particular driver. Then I may be definitely understand I'm doing something wrong and will stay (with such enemy driver) out of tree. I can't understand that because I see very similar drivers in kernel for ages (nbd, or even more similar is usbip) and seems they don't hamper to anybody. I would like to note that I don't want to start any flame-war, so very short answer would be enough for me., Hello Honza, I still support the inclusion of your virtual DVB device driver, once the technical issues[1] are solved (design clean interface based on DVBv5 etc.). Mauro promised to consider it for inclusion then[2]. A quick view at your code indicates that this clean-up hasn't happened yet, e.g. there are hacks to support DVB-S2 over DVBv3 which aren't necessary anymore with v5. Regarding the kernellabs.com people[3] lobbying against your contribution: Don't give up! If all attempts of merging your work through the media subsystem are failing, try convincing some major distributions to include your work. This would make their arguments meaningless. On the long run, good code is likely to win over politics. Regards, Andreas [1] http://www.spinics.net/lists/linux-media/msg34349.html [2] http://www.spinics.net/lists/linux-media/msg34352.html [3] http://www.kernellabs.com/blog/?page_id=6 [4] http://code.google.com/p/vtuner/source/browse/vtunerc_proxyfe.c?repo=linux-driver#177 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/11] TWL6030: Add mapping for auxiliary regs
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/mfd/twl-core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index bfbd660..e26b564 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -323,7 +323,7 @@ static struct twl_mapping twl6030_map[] = {
{ SUB_CHIP_ID0, TWL6030_BASEADD_ZERO },
{ SUB_CHIP_ID1, TWL6030_BASEADD_ZERO },
- { SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
+ { SUB_CHIP_ID1, TWL6030_BASEADD_AUX },
{ SUB_CHIP_ID2, TWL6030_BASEADD_ZERO },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
{ SUB_CHIP_ID2, TWL6030_BASEADD_RSV },
--
1.7.7.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 v2 02/11] mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value
The define should be the result of 1 Bit number. Bit number for GPOCTL.GPO3 field is 2, which results in 0x4 value. Signed-off-by: Sergio Aguirre saagui...@ti.com --- include/linux/mfd/twl6040.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h index 2463c261..2a7ff16 100644 --- a/include/linux/mfd/twl6040.h +++ b/include/linux/mfd/twl6040.h @@ -142,7 +142,7 @@ #define TWL6040_GPO1 0x01 #define TWL6040_GPO2 0x02 -#define TWL6040_GPO3 0x03 +#define TWL6040_GPO3 0x04 /* ACCCTL (0x2D) fields */ -- 1.7.7.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 v2 10/11] arm: omap4panda: Add support for omap4iss camera
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig | 27
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda-camera.c | 198 +
3 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f883abb..0fc5ce9 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -358,6 +358,33 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE
+config MACH_OMAP4_PANDA_CAMERA_SUPPORT
+ bool OMAP4 Panda Board Camera support
+ depends on MACH_OMAP4_PANDA
+ select MEDIA_SUPPORT
+ select MEDIA_CONTROLLER
+ select VIDEO_DEV
+ select VIDEO_V4L2_SUBDEV_API
+ select VIDEO_OMAP4
+ help
+ Enable Camera HW support for PandaBoard.
+ This is for using the OMAP4 ISS CSI2A Camera sensor
+ interface.
+
+choice
+ prompt Camera sensor to use
+ depends on MACH_OMAP4_PANDA_CAMERA_SUPPORT
+ default MACH_OMAP4_PANDA_CAM_OV5650
+
+ config MACH_OMAP4_PANDA_CAM_OV5640
+ bool Use OmniVision OV5640 Camera
+ select VIDEO_OV5640
+
+ config MACH_OMAP4_PANDA_CAM_OV5650
+ bool Use OmniVision OV5650 Camera
+ select VIDEO_OV5650
+endchoice
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8bc446a..e80724d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -236,6 +236,7 @@ obj-$(CONFIG_MACH_TI8168EVM)+=
board-ti8168evm.o
# Platform specific device init code
obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT) += board-4430sdp-camera.o
+obj-$(CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT) += board-omap4panda-camera.o
omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
diff --git a/arch/arm/mach-omap2/board-omap4panda-camera.c
b/arch/arm/mach-omap2/board-omap4panda-camera.c
new file mode 100644
index 000..02ef36e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda-camera.c
@@ -0,0 +1,198 @@
+#include linux/gpio.h
+#include linux/clk.h
+#include linux/delay.h
+
+#include plat/i2c.h
+#include plat/omap-pm.h
+
+#include asm/mach-types.h
+
+#include media/ov5640.h
+#include media/ov5650.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap4iss/iss.h
+
+#include control.h
+#include mux.h
+
+#define PANDA_GPIO_CAM_PWRDN 45
+#define PANDA_GPIO_CAM_RESET 83
+
+static struct clk *panda_cam_aux_clk;
+
+static int panda_ov5640_power(struct v4l2_subdev *subdev, int on)
+{
+ struct iss_device *iss = v4l2_dev_to_iss_device(subdev-v4l2_dev);
+ int ret = 0;
+ struct iss_csiphy_dphy_cfg dphy;
+ struct iss_csiphy_lanes_cfg lanes;
+ unsigned int ddr_freq = 480; /* FIXME: Do an actual query for this */
+
+ memset(lanes, 0, sizeof(lanes));
+ memset(dphy, 0, sizeof(dphy));
+
+ lanes.clk.pos = 1;
+ lanes.clk.pol = 0;
+ lanes.data[0].pos = 2;
+ lanes.data[0].pol = 0;
+ lanes.data[1].pos = 3;
+ lanes.data[1].pol = 0;
+
+ dphy.ths_term = 12500 * ddr_freq + 100) / 100) - 1) 0xFF);
+ dphy.ths_settle = 9 * ddr_freq + 100) / 100) + 3)
0xFF);
+ dphy.tclk_term = 0;
+ dphy.tclk_miss = 1;
+ dphy.tclk_settle = 14;
+
+ if (on) {
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 0);
+ clk_enable(panda_cam_aux_clk);
+ mdelay(2);
+
+ iss-platform_cb.csiphy_config(iss-csiphy1, dphy, lanes);
+ } else {
+ clk_disable(panda_cam_aux_clk);
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 1);
+ }
+
+ return ret;
+}
+
+#define OV5640_I2C_ADDRESS (0x3C)
+#define OV5650_I2C_ADDRESS (0x36)
+
+#ifdef CONFIG_MACH_OMAP4_PANDA_CAM_OV5650
+static struct ov5650_platform_data ov_platform_data = {
+#elif defined(CONFIG_MACH_OMAP4_PANDA_CAM_OV5640)
+static struct ov5640_platform_data ov_platform_data = {
+#endif
+ .s_power = panda_ov5640_power,
+};
+
+static struct i2c_board_info ov_camera_i2c_device = {
+#ifdef CONFIG_MACH_OMAP4_PANDA_CAM_OV5650
+ I2C_BOARD_INFO(ov5650, OV5650_I2C_ADDRESS),
+#elif defined(CONFIG_MACH_OMAP4_PANDA_CAM_OV5640)
+ I2C_BOARD_INFO(ov5640, OV5640_I2C_ADDRESS),
+#endif
+ .platform_data = ov_platform_data,
+};
+
+static struct iss_subdev_i2c_board_info ov_camera_subdevs[] = {
+ {
+ .board_info = ov_camera_i2c_device,
+ .i2c_adapter_id = 3,
+ },
+ { NULL, 0, },
+};
+
[PATCH v2 08/11] v4l: Add support for ov5650 sensor
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile|1 +
drivers/media/video/ov5650.c| 524 +++
include/media/ov5650.h | 10 +
include/media/v4l2-chip-ident.h |1 +
5 files changed, 542 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5650.c
create mode 100644 include/media/ov5650.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 3ee4fc9..46076a9 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -473,6 +473,12 @@ config VIDEO_OV5640
help
This is a ov5640 camera driver
+config VIDEO_OV5650
+ tristate OmniVision OV5650 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5650 camera driver
+
config VIDEO_MT9P031
tristate Aptina MT9P031 support
depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index d296c7b..9061cfc 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -64,6 +64,7 @@ obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
+obj-$(CONFIG_VIDEO_OV5650) += ov5650.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/video/ov5650.c b/drivers/media/video/ov5650.c
new file mode 100644
index 000..092d8bf
--- /dev/null
+++ b/drivers/media/video/ov5650.c
@@ -0,0 +1,524 @@
+/*
+ * OmniVision OV5650 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+
+#include media/ov5650.h
+
+/* OV5650 has only one fixed colorspace per pixelcode */
+struct ov5650_datafmt {
+ enum v4l2_mbus_pixelcodecode;
+ enum v4l2_colorspacecolorspace;
+};
+
+enum ov5650_size {
+ OV5650_SIZE_5MP,
+ OV5650_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5650_frmsizes[OV5650_SIZE_LAST] = {
+ { 2592, 1944 },
+};
+
+struct ov5650 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+
+ struct v4l2_mbus_framefmt format;
+
+ const struct ov5650_platform_data *pdata;
+};
+
+static inline struct ov5650 *to_ov5650(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct ov5650, subdev);
+}
+
+/**
+ * struct ov5650_reg - ov5650 register format
+ * @reg: 16-bit offset to register
+ * @val: 8/16/32-bit register value
+ * @length: length of the register
+ *
+ * Define a structure for OV5650 register initialization values
+ */
+struct ov5650_reg {
+ u16 reg;
+ u8 val;
+};
+
+/* TODO: Divide this properly */
+static const struct ov5650_reg configscript_5MP[] = {
+ { 0x3008, 0x82 },
+ { 0x3008, 0x42 },
+ { 0x3103, 0x93 },
+ { 0x3b07, 0x0c },
+ { 0x3017, 0xff },
+ { 0x3018, 0xfc },
+ { 0x3706, 0x41 },
+ { 0x3703, 0xe6 },
+ { 0x3613, 0x44 },
+ { 0x3630, 0x22 },
+ { 0x3605, 0x04 },
+ { 0x3606, 0x3f },
+ { 0x3712, 0x13 },
+ { 0x370e, 0x00 },
+ { 0x370b, 0x40 },
+ { 0x3600, 0x54 },
+ { 0x3601, 0x05 },
+ { 0x3713, 0x22 },
+ { 0x3714, 0x27 },
+ { 0x3631, 0x22 },
+ { 0x3612, 0x1a },
+ { 0x3604, 0x40 },
+ { 0x3705, 0xda },
+ { 0x370a, 0x80 },
+ { 0x370c, 0x00 },
+ { 0x3710, 0x28 },
+ { 0x3702, 0x3a },
+ { 0x3704, 0x18 },
+ { 0x3a18, 0x00 },
+ { 0x3a19, 0xf8 },
+ { 0x3a00, 0x38 },
+ { 0x3800, 0x02 },
+ { 0x3801, 0x54 },
+ { 0x3803, 0x0c },
+ { 0x3808, 0x0a },
+ { 0x3809, 0x20 },
+ { 0x380a, 0x07 },
+ { 0x380b, 0x98 },
+ { 0x380c, 0x0c },
+ { 0x380d, 0xb4 },
+ { 0x380e, 0x07 },
+ { 0x380f, 0xb0 },
+ { 0x3830, 0x50 },
+ { 0x3a08, 0x12 },
+ { 0x3a09, 0x70 },
+ { 0x3a0a, 0x0f },
+ { 0x3a0b, 0x60 },
+ { 0x3a0d, 0x06 },
+ { 0x3a0e, 0x06 },
+ { 0x3a13, 0x54 },
+ { 0x3815, 0x82 },
+ { 0x5059, 0x80 },
+ { 0x505a, 0x0a },
+
[PATCH v2 11/11] arm: Add support for CMA for omap4iss driver
Signed-off-by: Sergio Aguirre saagui...@ti.com --- arch/arm/mach-omap2/devices.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index b48aeea..e411c4e 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -17,6 +17,9 @@ #include linux/err.h #include linux/slab.h #include linux/of.h +#ifdef CONFIG_CMA +#include linux/dma-contiguous.h +#endif #include mach/hardware.h #include mach/irqs.h @@ -246,6 +249,11 @@ int omap4_init_camera(struct iss_platform_data *pdata, struct omap_board_data *b oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt); +#ifdef CONFIG_CMA + /* Create private 32MiB contiguous memory area for omap4iss device */ + dma_declare_contiguous(pdev-dev, 32*SZ_1M, 0, 0); +#endif + return 0; } -- 1.7.7.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 v2 09/11] arm: omap4430sdp: Add support for omap4iss camera
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig| 27
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/board-4430sdp-camera.c | 221
3 files changed, 250 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 5034147..f883abb 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -323,6 +323,33 @@ config MACH_OMAP_4430SDP
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE
+config MACH_OMAP_4430SDP_CAMERA_SUPPORT
+ bool OMAP 4430 SDP board Camera support
+ depends on MACH_OMAP_4430SDP
+ select MEDIA_SUPPORT
+ select MEDIA_CONTROLLER
+ select VIDEO_DEV
+ select VIDEO_V4L2_SUBDEV_API
+ select VIDEO_OMAP4
+ help
+ Enable Camera HW support for OMAP 4430 SDP board
+ This is for using the OMAP4 ISS CSI2A Camera sensor
+ interface.
+
+choice
+ prompt Camera sensor to use
+ depends on MACH_OMAP_4430SDP_CAMERA_SUPPORT
+ default MACH_OMAP_4430SDP_CAM_OV5650
+
+ config MACH_OMAP_4430SDP_CAM_OV5640
+ bool Use OmniVision OV5640 Camera
+ select VIDEO_OV5640
+
+ config MACH_OMAP_4430SDP_CAM_OV5650
+ bool Use OmniVision OV5650 Camera
+ select VIDEO_OV5650
+endchoice
+
config MACH_OMAP4_PANDA
bool OMAP4 Panda Board
default y
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69ab1c0..8bc446a 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -235,6 +235,8 @@ obj-$(CONFIG_MACH_TI8168EVM)+=
board-ti8168evm.o
# Platform specific device init code
+obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT) += board-4430sdp-camera.o
+
omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
obj-y += $(omap-flash-y) $(omap-flash-m)
diff --git a/arch/arm/mach-omap2/board-4430sdp-camera.c
b/arch/arm/mach-omap2/board-4430sdp-camera.c
new file mode 100644
index 000..e62ee50
--- /dev/null
+++ b/arch/arm/mach-omap2/board-4430sdp-camera.c
@@ -0,0 +1,221 @@
+#include linux/gpio.h
+#include linux/clk.h
+#include linux/delay.h
+#include linux/i2c/twl.h
+#include linux/mfd/twl6040.h
+
+#include plat/i2c.h
+#include plat/omap-pm.h
+
+#include asm/mach-types.h
+
+#include media/ov5640.h
+#include media/ov5650.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap4iss/iss.h
+
+#include control.h
+#include mux.h
+
+#define OMAP4430SDP_GPIO_CAM_PDN_C 39
+
+static struct clk *sdp4430_cam_aux_clk;
+
+static int sdp4430_ov5640_power(struct v4l2_subdev *subdev, int on)
+{
+ struct iss_device *iss = v4l2_dev_to_iss_device(subdev-v4l2_dev);
+ int ret = 0;
+ struct iss_csiphy_dphy_cfg dphy;
+ struct iss_csiphy_lanes_cfg lanes;
+#ifdef CONFIG_MACH_OMAP_4430SDP_CAM_OV5650
+ unsigned int ddr_freq = 480; /* FIXME: Do an actual query for this */
+#elif defined(CONFIG_MACH_OMAP_4430SDP_CAM_OV5640)
+ unsigned int ddr_freq = 336; /* FIXME: Do an actual query for this */
+#endif
+
+ memset(lanes, 0, sizeof(lanes));
+ memset(dphy, 0, sizeof(dphy));
+
+ lanes.clk.pos = 1;
+ lanes.clk.pol = 0;
+ lanes.data[0].pos = 2;
+ lanes.data[0].pol = 0;
+#ifdef CONFIG_MACH_OMAP_4430SDP_CAM_OV5650
+ lanes.data[1].pos = 3;
+ lanes.data[1].pol = 0;
+#endif
+
+ dphy.ths_term = 12500 * ddr_freq + 100) / 100) - 1) 0xFF);
+ dphy.ths_settle = 9 * ddr_freq + 100) / 100) + 3)
0xFF);
+ dphy.tclk_term = 0;
+ dphy.tclk_miss = 1;
+ dphy.tclk_settle = 14;
+
+ if (on) {
+ u8 gpoctl = 0;
+
+ /* TWL6030_BASEADD_AUX */
+ twl_i2c_write_u8(15, 0x00, 0xB);
+ twl_i2c_write_u8(15, 0x80, 0x1);
+
+ mdelay(50);
+
+ /* TWL6030_BASEADD_PM_SLAVE_MISC */
+ twl_i2c_write_u8(21, 0xFF, 0x5E);
+ twl_i2c_write_u8(21, 0x13, 0x5F);
+
+ mdelay(50);
+
+ twl_i2c_write_u8(15, 0x40, 0x1);
+
+ twl_i2c_read_u8(TWL_MODULE_AUDIO_VOICE, gpoctl,
+ TWL6040_REG_GPOCTL);
+ twl_i2c_write_u8(TWL_MODULE_AUDIO_VOICE, gpoctl | TWL6040_GPO3,
+ TWL6040_REG_GPOCTL);
+
+ mdelay(10);
+
+ gpio_set_value(OMAP4430SDP_GPIO_CAM_PDN_C, 1);
+ mdelay(10);
+ clk_enable(sdp4430_cam_aux_clk); /* Enable XCLK */
+ mdelay(10);
+
+ iss-platform_cb.csiphy_config(iss-csiphy1, dphy, lanes);
[PATCH v2 03/11] v4l: Introduce sensor operation for getting interface configuration
From: Stanimir Varbanov svarba...@mm-sol.com
Introduce g_interface_parms sensor operation for getting sensor
interface parameters. These parameters are needed from the host side
to determine it's own configuration.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
---
include/media/v4l2-subdev.h | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index f0f3358..0d322ed 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -362,6 +362,42 @@ struct v4l2_subdev_vbi_ops {
int (*s_sliced_fmt)(struct v4l2_subdev *sd, struct
v4l2_sliced_vbi_format *fmt);
};
+/* Which interface the sensor use to provide it's image data */
+enum v4l2_subdev_sensor_iface {
+ V4L2_SUBDEV_SENSOR_PARALLEL,
+ V4L2_SUBDEV_SENSOR_SERIAL,
+};
+
+/* Each interface could use the following modes */
+/* Image sensor provides horizontal and vertical sync signals */
+#define V4L2_SUBDEV_SENSOR_MODE_PARALLEL_SYNC 0
+/* BT.656 interface. Embedded sync */
+#define V4L2_SUBDEV_SENSOR_MODE_PARALLEL_ITU 1
+/* MIPI CSI1 */
+#define V4L2_SUBDEV_SENSOR_MODE_SERIAL_CSI12
+/* MIPI CSI2 */
+#define V4L2_SUBDEV_SENSOR_MODE_SERIAL_CSI23
+
+struct v4l2_subdev_sensor_serial_parms {
+ unsigned char lanes;/* number of lanes used */
+ unsigned char channel; /* virtual channel */
+ unsigned int phy_rate; /* output rate at CSI phy in bps */
+ unsigned int pix_clk; /* pixel clock in Hz */
+};
+
+struct v4l2_subdev_sensor_parallel_parms {
+ unsigned int pix_clk; /* pixel clock in Hz */
+};
+
+struct v4l2_subdev_sensor_interface_parms {
+ enum v4l2_subdev_sensor_iface if_type;
+ unsigned int if_mode;
+ union {
+ struct v4l2_subdev_sensor_serial_parms serial;
+ struct v4l2_subdev_sensor_parallel_parms parallel;
+ } parms;
+};
+
/**
* struct v4l2_subdev_sensor_ops - v4l2-subdev sensor operations
* @g_skip_top_lines: number of lines at the top of the image to be skipped.
@@ -371,10 +407,16 @@ struct v4l2_subdev_vbi_ops {
* @g_skip_frames: number of frames to skip at stream start. This is needed for
*buggy sensors that generate faulty frames when they are
*turned on.
+ * @g_interface_parms: get sensor interface parameters. The sensor subdev
should
+ *fill this structure with current interface params. These
+ *interface parameters are needed on host side to configure
+ *it's own hardware receivers.
*/
struct v4l2_subdev_sensor_ops {
int (*g_skip_top_lines)(struct v4l2_subdev *sd, u32 *lines);
int (*g_skip_frames)(struct v4l2_subdev *sd, u32 *frames);
+ int (*g_interface_parms)(struct v4l2_subdev *sd,
+ struct v4l2_subdev_sensor_interface_parms *parms);
};
/*
--
1.7.7.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 v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support
Hi everyone, This is the second version of the OMAP4 ISS driver, now ported to the Media Controller framework AND supporting videobuf2 framework. This patchset should apply cleanly on top of v3.2-rc3 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) Changes since v1: - Simplification of auxclk handling in board files. (Pointed out by: Roger Quadros) - Cleanup of Camera support enablement for 4430sdp panda. (Pointed out by: Roger Quadros) - Use of HWMOD declaration for assisted platform_device creation. (Pointed out by: Felipe Balbi) - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) - Proper GPO3 handling for CAM_SEL in 4430sdp. Sergio Aguirre (10): TWL6030: Add mapping for auxiliary regs mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Stanimir Varbanov (1): v4l: Introduce sensor operation for getting interface configuration Documentation/video4linux/omap4_camera.txt| 60 ++ arch/arm/mach-omap2/Kconfig | 54 + arch/arm/mach-omap2/Makefile |3 + arch/arm/mach-omap2/board-4430sdp-camera.c| 221 arch/arm/mach-omap2/board-omap4panda-camera.c | 198 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c| 16 +- arch/arm/plat-omap/include/plat/omap4-iss.h | 42 + arch/arm/plat-omap/include/plat/omap44xx.h|9 + drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile |3 + drivers/media/video/omap4iss/Makefile |6 + drivers/media/video/omap4iss/iss.c| 1179 ++ drivers/media/video/omap4iss/iss.h| 133 +++ drivers/media/video/omap4iss/iss_csi2.c | 1324 + drivers/media/video/omap4iss/iss_csi2.h | 166 +++ drivers/media/video/omap4iss/iss_csiphy.c | 215 drivers/media/video/omap4iss/iss_csiphy.h | 69 ++ drivers/media/video/omap4iss/iss_regs.h | 238 + drivers/media/video/omap4iss/iss_video.c | 1192 ++ drivers/media/video/omap4iss/iss_video.h | 205 drivers/media/video/ov5640.c | 972 ++ drivers/media/video/ov5650.c | 524 ++ drivers/mfd/twl-core.c|2 +- include/linux/mfd/twl6040.h |2 +- include/media/ov5640.h| 10 + include/media/ov5650.h| 10 + include/media/v4l2-chip-ident.h |2 + include/media/v4l2-subdev.h | 42 + 29 files changed, 6957 insertions(+), 5 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 arch/arm/plat-omap/include/plat/omap4-iss.h create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644 drivers/media/video/ov5640.c create mode 100644 drivers/media/video/ov5650.c create mode 100644 include/media/ov5640.h create mode 100644 include/media/ov5650.h -- 1.7.7.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 v2 07/11] v4l: Add support for ov5640 sensor
This adds a very limited driver for ov5640, which
only supports:
- 2592x1944 @ ~7.5 fps
- 1920x1080 @ ~15 fps,
- 1280x720 @ ~24 fps,
- 640x480 @ ~24 fps,
- 320x240 @ ~24 fps,
All in YUV422i format, using 1 CSI2 datalane @ 333 MHz.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/Kconfig |6 +
drivers/media/video/Makefile|1 +
drivers/media/video/ov5640.c| 972 +++
include/media/ov5640.h | 10 +
include/media/v4l2-chip-ident.h |1 +
5 files changed, 990 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/ov5640.c
create mode 100644 include/media/ov5640.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index ae2a99d..3ee4fc9 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -467,6 +467,12 @@ config VIDEO_OV7670
OV7670 VGA camera. It currently only works with the M88ALP01
controller.
+config VIDEO_OV5640
+ tristate OmniVision OV5640 sensor support
+ depends on I2C VIDEO_V4L2
+ help
+ This is a ov5640 camera driver
+
config VIDEO_MT9P031
tristate Aptina MT9P031 support
depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index f02a4c4..d296c7b 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_VIDEO_CX25840) += cx25840/
obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o
obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o
obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o
diff --git a/drivers/media/video/ov5640.c b/drivers/media/video/ov5640.c
new file mode 100644
index 000..c93802a
--- /dev/null
+++ b/drivers/media/video/ov5640.c
@@ -0,0 +1,972 @@
+/*
+ * OmniVision OV5640 sensor driver
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/videodev2.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/log2.h
+#include linux/delay.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-subdev.h
+
+#include media/ov5640.h
+
+#define OV5640_BRIGHTNESS_MIN 0
+#define OV5640_BRIGHTNESS_MAX 200
+#define OV5640_BRIGHTNESS_STEP 100
+#define OV5640_BRIGHTNESS_DEF 100
+
+#define OV5640_CONTRAST_MIN0
+#define OV5640_CONTRAST_MAX200
+#define OV5640_CONTRAST_STEP 100
+#define OV5640_CONTRAST_DEF100
+
+/* OV5640 has only one fixed colorspace per pixelcode */
+struct ov5640_datafmt {
+ enum v4l2_mbus_pixelcodecode;
+ enum v4l2_colorspacecolorspace;
+};
+
+struct ov5640_timing_cfg {
+ u16 x_addr_start;
+ u16 y_addr_start;
+ u16 x_addr_end;
+ u16 y_addr_end;
+ u16 h_output_size;
+ u16 v_output_size;
+ u16 h_total_size;
+ u16 v_total_size;
+ u16 isp_h_offset;
+ u16 isp_v_offset;
+ u8 h_odd_ss_inc;
+ u8 h_even_ss_inc;
+ u8 v_odd_ss_inc;
+ u8 v_even_ss_inc;
+};
+
+enum ov5640_size {
+ OV5640_SIZE_QVGA,
+ OV5640_SIZE_VGA,
+ OV5640_SIZE_720P,
+ OV5640_SIZE_1080P,
+ OV5640_SIZE_5MP,
+ OV5640_SIZE_LAST,
+};
+
+static const struct v4l2_frmsize_discrete ov5640_frmsizes[OV5640_SIZE_LAST] = {
+ { 320, 240 },
+ { 640, 480 },
+ { 1280, 720 },
+ { 1920, 1080 },
+ { 2592, 1944 },
+};
+
+/* Find a frame size in an array */
+static int ov5640_find_framesize(u32 width, u32 height)
+{
+ int i;
+
+ for (i = 0; i OV5640_SIZE_LAST; i++) {
+ if ((ov5640_frmsizes[i].width = width)
+ (ov5640_frmsizes[i].height = height))
+ break;
+ }
+
+ /* If not found, select biggest */
+ if (i = OV5640_SIZE_LAST)
+ i = OV5640_SIZE_LAST - 1;
+
+ return i;
+}
+
+struct ov5640 {
+ struct v4l2_subdev subdev;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+ const struct ov5640_platform_data *pdata;
+ int brightness;
+ int contrast;
+ int colorlevel;
+};
+
+static inline struct ov5640
[PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 7695e5d..1b59e2f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2623,8 +2623,18 @@ static struct omap_hwmod_ocp_if *omap44xx_iss_masters[]
= {
static struct omap_hwmod_addr_space omap44xx_iss_addrs[] = {
{
- .pa_start = 0x5200,
- .pa_end = 0x52ff,
+ .pa_start = OMAP44XX_ISS_TOP_BASE,
+ .pa_end = OMAP44XX_ISS_TOP_END,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = OMAP44XX_ISS_CSI2_A_REGS1_BASE,
+ .pa_end = OMAP44XX_ISS_CSI2_A_REGS1_END,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = OMAP44XX_ISS_CAMERARX_CORE1_BASE,
+ .pa_end = OMAP44XX_ISS_CAMERARX_CORE1_END,
.flags = ADDR_TYPE_RT
},
{ }
@@ -5350,7 +5360,7 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[] = {
omap44xx_ipu_c1_hwmod,
/* iss class */
-/* omap44xx_iss_hwmod, */
+ omap44xx_iss_hwmod,
/* iva class */
omap44xx_iva_hwmod,
--
1.7.7.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
Debug output
There are a fair number of debug print statements in the V4L2 code. How
do I turn those on?
For instance, I'd like the following code to print
if ((vfd-debug V4L2_DEBUG_IOCTL)
!(vfd-debug V4L2_DEBUG_IOCTL_ARG)) {
v4l_print_ioctl(vfd-name, cmd);
printk(KERN_CONT \n);
}
so I can trace the IOCTL calls.
Thanks,
David
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/11] v4l2: OMAP4 ISS driver + Sensor + Board support
Hi again, On Wed, Nov 30, 2011 at 6:14 PM, Sergio Aguirre saagui...@ti.com wrote: Hi everyone, This is the second version of the OMAP4 ISS driver, now ported to the Media Controller framework AND supporting videobuf2 framework. This patchset should apply cleanly on top of v3.2-rc3 kernel tag. This driver attempts to provide an fully open source solution to control the OMAP4 Imaging SubSystem (a.k.a. ISS). Starts with just CSI2-A interface support, and pretends to be ready for expansion to add support to the many ISS block modules as possible. Please see newly added documentation for more details: Documentation/video4linux/omap4_camera.txt Any comments/complaints are welcome. :) Changes since v1: - Simplification of auxclk handling in board files. (Pointed out by: Roger Quadros) - Cleanup of Camera support enablement for 4430sdp panda. (Pointed out by: Roger Quadros) - Use of HWMOD declaration for assisted platform_device creation. (Pointed out by: Felipe Balbi) - Videobuf2 migration (Removal of custom iss_queue buffer handling driver) - Proper GPO3 handling for CAM_SEL in 4430sdp. Also, you can pull this as a branch in my git tree here: Web URL: http://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera git URL: git://gitorious.org/omap4-v4l2-camera/omap4-v4l2-camera.git Branch: for3.2-rc3 Regards, Sergio Sergio Aguirre (10): TWL6030: Add mapping for auxiliary regs mfd: twl6040: Fix wrong TWL6040_GPO3 bitfield value OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections OMAP4: Add base addresses for ISS v4l: Add support for omap4iss driver v4l: Add support for ov5640 sensor v4l: Add support for ov5650 sensor arm: omap4430sdp: Add support for omap4iss camera arm: omap4panda: Add support for omap4iss camera arm: Add support for CMA for omap4iss driver Stanimir Varbanov (1): v4l: Introduce sensor operation for getting interface configuration Documentation/video4linux/omap4_camera.txt | 60 ++ arch/arm/mach-omap2/Kconfig | 54 + arch/arm/mach-omap2/Makefile | 3 + arch/arm/mach-omap2/board-4430sdp-camera.c | 221 arch/arm/mach-omap2/board-omap4panda-camera.c | 198 arch/arm/mach-omap2/devices.c | 40 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +- arch/arm/plat-omap/include/plat/omap4-iss.h | 42 + arch/arm/plat-omap/include/plat/omap44xx.h | 9 + drivers/media/video/Kconfig | 25 + drivers/media/video/Makefile | 3 + drivers/media/video/omap4iss/Makefile | 6 + drivers/media/video/omap4iss/iss.c | 1179 ++ drivers/media/video/omap4iss/iss.h | 133 +++ drivers/media/video/omap4iss/iss_csi2.c | 1324 + drivers/media/video/omap4iss/iss_csi2.h | 166 +++ drivers/media/video/omap4iss/iss_csiphy.c | 215 drivers/media/video/omap4iss/iss_csiphy.h | 69 ++ drivers/media/video/omap4iss/iss_regs.h | 238 + drivers/media/video/omap4iss/iss_video.c | 1192 ++ drivers/media/video/omap4iss/iss_video.h | 205 drivers/media/video/ov5640.c | 972 ++ drivers/media/video/ov5650.c | 524 ++ drivers/mfd/twl-core.c | 2 +- include/linux/mfd/twl6040.h | 2 +- include/media/ov5640.h | 10 + include/media/ov5650.h | 10 + include/media/v4l2-chip-ident.h | 2 + include/media/v4l2-subdev.h | 42 + 29 files changed, 6957 insertions(+), 5 deletions(-) create mode 100644 Documentation/video4linux/omap4_camera.txt create mode 100644 arch/arm/mach-omap2/board-4430sdp-camera.c create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c create mode 100644 arch/arm/plat-omap/include/plat/omap4-iss.h create mode 100644 drivers/media/video/omap4iss/Makefile create mode 100644 drivers/media/video/omap4iss/iss.c create mode 100644 drivers/media/video/omap4iss/iss.h create mode 100644 drivers/media/video/omap4iss/iss_csi2.c create mode 100644 drivers/media/video/omap4iss/iss_csi2.h create mode 100644 drivers/media/video/omap4iss/iss_csiphy.c create mode 100644 drivers/media/video/omap4iss/iss_csiphy.h create mode 100644 drivers/media/video/omap4iss/iss_regs.h create mode 100644 drivers/media/video/omap4iss/iss_video.c create mode 100644 drivers/media/video/omap4iss/iss_video.h create mode 100644 drivers/media/video/ov5640.c create mode 100644 drivers/media/video/ov5650.c create mode 100644 include/media/ov5640.h create mode 100644 include/media/ov5650.h -- 1.7.7.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
Re: [Linaro-mm-sig] [RFC 1/2] dma-buf: Introduce dma buffer sharing mechanism
Hi Dave, Daniel, Rob, On Sun, Nov 27, 2011 at 12:29 PM, Rob Clark robdcl...@gmail.com wrote: On Sat, Nov 26, 2011 at 8:00 AM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Nov 25, 2011 at 17:28, Dave Airlie airl...@gmail.com wrote: I've rebuilt my PRIME interface on top of dmabuf to see how it would work, I've got primed gears running again on top, but I expect all my object lifetime and memory ownership rules need fixing up (i.e. leaks like a sieve). http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-prime-dmabuf has the i915/nouveau patches for the kernel to produce the prime interface. I've noticed that your implementations for get_scatterlist (at least for the i915 driver) doesn't return the sg table mapped into the device address space. I've checked and the documentation makes it clear that this should be the case (and we really need this to support certain insane hw), but the get/put_scatterlist names are a bit misleading. Proposal: - use struct sg_table instead of scatterlist like you've already done in you branch. Simply more consistent with the dma api. yup - rename get/put_scatterlist into map/unmap for consistency with all the map/unmap dma api functions. The attachement would then serve as the abstract cookie to the backing storage, similar to how struct page * works as an abstract cookie for dma_map/unmap_page. The only special thing is that struct device * parameter because that's already part of the attachment. yup - add new wrapper functions dma_buf_map_attachment and dma_buf_unmap_attachement to hide all the pointer/vtable-chasing that we currently expose to users of this interface. I thought that was one of the earlier comments on the initial dmabuf patch, but either way: yup Thanks for your comments; I will incorporate all of these in the next version I'll send out. BR, -R BR, Sumit. Comments? Cheers, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch -- 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: Support for multiple section feeds with same PIDs
Hi, Sorry to repeat the question, anyone has an idea on this? I appreciate your feedback. Thank you Hamad -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Hamad Kadmany Sent: Tuesday, November 29, 2011 10:05 AM To: linux-media@vger.kernel.org Subject: Support for multiple section feeds with same PIDs Hello Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c) In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections feeds allocated (allocate_section_feed) with same PID. From my experience, applications might request allocating several section feeds using same PID but with different filters (for example, in DVB standard, SDT and BAT tables have same PID). The current implementation only supports of having multiple filters on the same section feed. Any special reason why it was implemented this way? Thank you Hamad -- 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 v2 10/11] arm: omap4panda: Add support for omap4iss camera
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Thursday, December 01, 2011 5:45 AM
To: linux-media@vger.kernel.org
Cc: linux-o...@vger.kernel.org; laurent.pinch...@ideasonboard.com;
sakari.ai...@iki.fi; Aguirre, Sergio
Subject: [PATCH v2 10/11] arm: omap4panda: Add support for omap4iss camera
This adds support for camera interface with the support for
following sensors:
- OV5640
- OV5650
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/Kconfig | 27
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/board-omap4panda-camera.c | 198
+
3 files changed, 226 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-omap4panda-camera.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f883abb..0fc5ce9 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -358,6 +358,33 @@ config MACH_OMAP4_PANDA
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE
+config MACH_OMAP4_PANDA_CAMERA_SUPPORT
+ bool OMAP4 Panda Board Camera support
+ depends on MACH_OMAP4_PANDA
+ select MEDIA_SUPPORT
+ select MEDIA_CONTROLLER
+ select VIDEO_DEV
+ select VIDEO_V4L2_SUBDEV_API
+ select VIDEO_OMAP4
+ help
+ Enable Camera HW support for PandaBoard.
+ This is for using the OMAP4 ISS CSI2A Camera sensor
+ interface.
+
+choice
+ prompt Camera sensor to use
+ depends on MACH_OMAP4_PANDA_CAMERA_SUPPORT
+ default MACH_OMAP4_PANDA_CAM_OV5650
+
+ config MACH_OMAP4_PANDA_CAM_OV5640
+ bool Use OmniVision OV5640 Camera
+ select VIDEO_OV5640
+
+ config MACH_OMAP4_PANDA_CAM_OV5650
+ bool Use OmniVision OV5650 Camera
+ select VIDEO_OV5650
+endchoice
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8bc446a..e80724d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -236,6 +236,7 @@ obj-$(CONFIG_MACH_TI8168EVM) += board-
ti8168evm.o
# Platform specific device init code
obj-$(CONFIG_MACH_OMAP_4430SDP_CAMERA_SUPPORT) +=
board-4430sdp-camera.o
+obj-$(CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT)+= board-omap4panda-
camera.o
Can't this be merged into single file? Do we really need separate file for
every board here?
I am sure you would have thought about this.
omap-flash-$(CONFIG_MTD_NAND_OMAP2) := board-flash.o
omap-flash-$(CONFIG_MTD_ONENAND_OMAP2) := board-flash.o
diff --git a/arch/arm/mach-omap2/board-omap4panda-camera.c
b/arch/arm/mach-omap2/board-omap4panda-camera.c
new file mode 100644
index 000..02ef36e
--- /dev/null
+++ b/arch/arm/mach-omap2/board-omap4panda-camera.c
@@ -0,0 +1,198 @@
+#include linux/gpio.h
+#include linux/clk.h
+#include linux/delay.h
+
+#include plat/i2c.h
+#include plat/omap-pm.h
+
+#include asm/mach-types.h
+
+#include media/ov5640.h
+#include media/ov5650.h
+
+#include devices.h
+#include ../../../drivers/media/video/omap4iss/iss.h
+
I believe this is not good practice to include files directly from drivers
folder. You should divide the header file such that, driver specific
information stays in driver/... and platform specific goes into include/...
+#include control.h
+#include mux.h
+
+#define PANDA_GPIO_CAM_PWRDN 45
+#define PANDA_GPIO_CAM_RESET 83
+
+static struct clk *panda_cam_aux_clk;
+
+static int panda_ov5640_power(struct v4l2_subdev *subdev, int on)
+{
+ struct iss_device *iss = v4l2_dev_to_iss_device(subdev-v4l2_dev);
+ int ret = 0;
You are not using this variable at all, you can get rid of this.
+ struct iss_csiphy_dphy_cfg dphy;
+ struct iss_csiphy_lanes_cfg lanes;
+ unsigned int ddr_freq = 480; /* FIXME: Do an actual query for this
*/
+
+ memset(lanes, 0, sizeof(lanes));
+ memset(dphy, 0, sizeof(dphy));
+
+ lanes.clk.pos = 1;
+ lanes.clk.pol = 0;
+ lanes.data[0].pos = 2;
+ lanes.data[0].pol = 0;
+ lanes.data[1].pos = 3;
+ lanes.data[1].pol = 0;
+
+ dphy.ths_term = 12500 * ddr_freq + 100) / 100) - 1)
0xFF);
+ dphy.ths_settle = 9 * ddr_freq + 100) / 100) + 3)
0xFF);
+ dphy.tclk_term = 0;
+ dphy.tclk_miss = 1;
+ dphy.tclk_settle = 14;
+
+ if (on) {
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 0);
+ clk_enable(panda_cam_aux_clk);
+ mdelay(2);
+
+ iss-platform_cb.csiphy_config(iss-csiphy1, dphy, lanes);
+ } else {
+ clk_disable(panda_cam_aux_clk);
+ gpio_set_value(PANDA_GPIO_CAM_PWRDN, 1);
+ }
You may
RE: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory sections
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Aguirre, Sergio
Sent: Thursday, December 01, 2011 5:45 AM
To: linux-media@vger.kernel.org
Cc: linux-o...@vger.kernel.org; laurent.pinch...@ideasonboard.com;
sakari.ai...@iki.fi; Aguirre, Sergio
Subject: [PATCH v2 04/11] OMAP4: hwmod: Include CSI2A and CSIPHY1 memory
sections
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-
omap2/omap_hwmod_44xx_data.c
index 7695e5d..1b59e2f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2623,8 +2623,18 @@ static struct omap_hwmod_ocp_if
*omap44xx_iss_masters[] = {
static struct omap_hwmod_addr_space omap44xx_iss_addrs[] = {
{
- .pa_start = 0x5200,
- .pa_end = 0x52ff,
+ .pa_start = OMAP44XX_ISS_TOP_BASE,
+ .pa_end = OMAP44XX_ISS_TOP_END,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = OMAP44XX_ISS_CSI2_A_REGS1_BASE,
+ .pa_end = OMAP44XX_ISS_CSI2_A_REGS1_END,
+ .flags = ADDR_TYPE_RT
+ },
+ {
+ .pa_start = OMAP44XX_ISS_CAMERARX_CORE1_BASE,
+ .pa_end = OMAP44XX_ISS_CAMERARX_CORE1_END,
.flags = ADDR_TYPE_RT
},
This patch will result in build failure, because, the above base addresses
are getting defined in the next patch
[PATCH v2 05/11] OMAP4: Add base addresses for ISS
Thanks,
Vaibhav
{ }
@@ -5350,7 +5360,7 @@ static __initdata struct omap_hwmod
*omap44xx_hwmods[] = {
omap44xx_ipu_c1_hwmod,
/* iss class */
-/* omap44xx_iss_hwmod, */
+ omap44xx_iss_hwmod,
/* iva class */
omap44xx_iva_hwmod,
--
1.7.7.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: LinuxTV ported to Windows
Hi Walter, On 30.11.2011 21:46, Walter Van Eetvelt wrote: Nice! How is the CI implementation? it's ok. Working fine under windows including MMI. Professional CAM's (with multi-PID descramble) are tested. Can both CI's be used by both tuners? Or is one CI bound to one tuner? First CI slot assigned to first tuner/demod and second CI slot assigned for second tuner/demod by hardware. You can't share CI slots between tuners. Walter On Wed, 30 Nov 2011 19:39:34 +0300, Abylay Ospanaos...@netup.ru wrote: Hello, We have ported linuxtv's cx23885+CAM en50221+Diseq to Windows OS (Vista, XP, win7 tested). Results available under GPL and can be checkout from git repository: https://github.com/netup/netup-dvb-s2-ci-dual Binary builds (ready to install) available in build directory. Currently NetUP Dual DVB-S2 CI card supported ( http://www.netup.tv/en-EN/dual_dvb-s2-ci_card.php ). Driver based on Microsoft BDA standard, but some features (DiSEqC, CI) supported by custom API, for more details see netup_bda_api.h file. Any comments, suggestions are welcome. -- Abylai Ospanaos...@netup.ru NetUP Inc. -- 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: LinuxTV ported to Windows
Hi Devin, Thanks for this idea. Need to investigate. Currently we've made porting and released the results without any license violations in mind ... On 30.11.2011 20:23, Devin Heitmueller wrote: 2011/11/30 Abylay Ospanaos...@netup.ru: Hello, We have ported linuxtv's cx23885+CAM en50221+Diseq to Windows OS (Vista, XP, win7 tested). Results available under GPL and can be checkout from git repository: https://github.com/netup/netup-dvb-s2-ci-dual Binary builds (ready to install) available in build directory. Currently NetUP Dual DVB-S2 CI card supported ( http://www.netup.tv/en-EN/dual_dvb-s2-ci_card.php ). Driver based on Microsoft BDA standard, but some features (DiSEqC, CI) supported by custom API, for more details see netup_bda_api.h file. Any comments, suggestions are welcome. -- Abylai Ospanaos...@netup.ru NetUP Inc. Am I the only one who thinks this is a legally ambigious grey area? Seems like this could be a violation of the GPL as the driver code in question links against a proprietary kernel. I don't want to start a flame war, but I don't see how this is legal. And you could definitely question whether it goes against the intentions of the original authors to see their GPL driver code being used in non-free operating systems. Devin -- Abylai Ospanaos...@netup.ru NetUP Inc. -- 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
