[GIT FIXES FOR v3.2] Adp1653 fix
Hi Mauro, The following changes since commit 699cc1962c85351689c27dd46e598e4204fdd105: [media] TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder (2011-09-21 17:06:56 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.2-adp1653-1 Andy Shevchenko (1): adp1653: set media entity type drivers/media/video/adp1653.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patches at patchwork.linuxtv.org (127 patches)
On Wednesday, September 21, 2011 22:44:20 Mauro Carvalho Chehab wrote: > Em 21-09-2011 17:40, Mauro Carvalho Chehab escreveu: > > As announced on Sept, 18, we moved our patch queue to patchwork.linuxtv.org. > > > > As we were without access to the old patchwork instance, I simply sent all > > emails I had locally stored on my local mahine to the new instance and > > reviewed > > all patches again. Basically, for old patches, I basically did some > > scripting > > that were marking old patches as "superseded", if they didn't apply anymore. > > I also preserved the patches that were marked as "under review" from > > patchwork > > time, using some scripting and a local control file. > > > > So, we're basically close to what we had before kernel.org troubles (except > > for > > a series of patches that I've already applied today). > > > > My intention is to finish review all patches marked as "new" until the end > > of this > > week, and set a new tree for linux-next with our stuff (as the old one were > > at > > git.kernel.org). > > > > Please let me know if something is missed or if some patch from the list > > bellow > > is obsolete and can be marked with a different status. > > > > Thanks! > > Mauro > > > > > > == New patches == > > Gah! forgot to update the URL on my script. the patch list with the right URL > is: > > == Patches for Hans Verkuil check == > > Aug, 3 2010: [1/2] TVP7002: Return V4L2_DV_INVALID if any of the errors > occur. http://patchwork.linuxtv.org/patch/4064 Mats Randgaard > > Aug, 3 2010: [2/2] TVP7002: Changed register values. > http://patchwork.linuxtv.org/patch/4063 Mats Randgaard > As already mentioned earlier in an email, these two can be merged. So: Acked-by: Hans Verkuil Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
Hi, On Wednesday 21 September 2011 07:04 PM, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:31 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr Currently, in omap_vout_isr(), if the panel type is DPI, and if we get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the current buffers state to VIDEOBUF_DONE and prepare to display the next frame in the queue. On OMAP4, because we have 2 LCD managers, the panel type itself is not sufficient to tell if we have received the correct irq, i.e, we shouldn't proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2 interrupt for LCD manager. Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager to VSYNC2 interrupt. Signed-off-by: Archit Taneja --- drivers/media/video/omap/omap_vout.c | 14 +++--- 1 files changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index c5f2ea0..20638c3 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -566,8 +566,8 @@ err: static void omap_vout_isr(void *arg, unsigned int irqstatus) { - int ret, fid; - u32 addr; + int ret, fid, mgr_id; + u32 addr, irq; struct omap_overlay *ovl; struct timeval timevalue; struct omapvideo_info *ovid; @@ -583,6 +583,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) if (!ovl->manager || !ovl->manager->device) return; + mgr_id = ovl->manager->id; cur_display = ovl->manager->device; spin_lock(&vout->vbq_lock); @@ -590,7 +591,14 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) switch (cur_display->type) { case OMAP_DISPLAY_TYPE_DPI: - if (!(irqstatus& (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) + if (mgr_id == OMAP_DSS_CHANNEL_LCD) + irq = DISPC_IRQ_VSYNC; + else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) + irq = DISPC_IRQ_VSYNC2; + else + goto vout_isr_err; + + if (!(irqstatus& irq)) goto vout_isr_err; break; I understand what this patch meant for, but I am more curious to know What is value addition of this patch? if (!(irqstatus& (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) Vs if (mgr_id == OMAP_DSS_CHANNEL_LCD) irq = DISPC_IRQ_VSYNC; else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) irq = DISPC_IRQ_VSYNC2; Isn't this same, because we are not doing anything separate and special for VSYNC and VSYNC2? Consider a use case where the primary LCD panel(connected to LCD manager) is configured at a 60 Hz refresh rate, and the secondary panel(connected to LCD2) refreshes at 30 Hz. Let the overlay configuration be something like this: /dev/video1->overlay1->LCD manager->Primary panel(60 Hz) /dev/video2->overlay2->LCD2 manager->Secondary Panel(30 Hz) Now if we are doing streaming on both video1 and video2, since we deque on either VSYNC or VSYNC2, video2 buffers will deque faster than the panels refresh, which is incorrect. So for video2, we should only deque when we get a VSYNC2 interrupt. Thats why there is a need to correlate the interrupt and the overlay manager. Regards, Archit Thanks, Vaibhav case OMAP_DISPLAY_TYPE_VENC: -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] at91: add Atmel ISI and ov2640 support on sam9m10/sam9g45 board.
This patch 1. add ISI_MCK parent setting code when add ISI device. 2. add ov2640 support on board file. 3. define isi_mck clock in sam9g45 chip file. Signed-off-by: Josh Wu --- arch/arm/mach-at91/at91sam9g45.c |3 + arch/arm/mach-at91/at91sam9g45_devices.c | 105 +- arch/arm/mach-at91/board-sam9m10g45ek.c | 85 - arch/arm/mach-at91/include/mach/board.h |3 +- 4 files changed, 193 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c index e04c5fb..5e23d6d 100644 --- a/arch/arm/mach-at91/at91sam9g45.c +++ b/arch/arm/mach-at91/at91sam9g45.c @@ -201,6 +201,7 @@ static struct clk *periph_clocks[] __initdata = { // irq0 }; +static struct clk pck1; static struct clk_lookup periph_clocks_lookups[] = { /* One additional fake clock for ohci */ CLKDEV_CON_ID("ohci_clk", &uhphs_clk), @@ -215,6 +216,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk), CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + /* ISI_MCK, which is provided by programmable clock(PCK1) */ + CLKDEV_CON_DEV_ID("isi_mck", "atmel_isi.0", &pck1), }; static struct clk_lookup usart_clocks_lookups[] = { diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c index 600bffb..82eeac8 100644 --- a/arch/arm/mach-at91/at91sam9g45_devices.c +++ b/arch/arm/mach-at91/at91sam9g45_devices.c @@ -16,7 +16,7 @@ #include #include #include - +#include #include #include @@ -28,6 +28,8 @@ #include #include +#include + #include "generic.h" @@ -863,6 +865,107 @@ void __init at91_add_device_ac97(struct ac97c_platform_data *data) void __init at91_add_device_ac97(struct ac97c_platform_data *data) {} #endif +/* + * Image Sensor Interface + * */ +#if defined(CONFIG_VIDEO_ATMEL_ISI) || defined(CONFIG_VIDEO_ATMEL_ISI_MODULE) +static u64 isi_dmamask = DMA_BIT_MASK(32); +static struct isi_platform_data isi_data; + +struct resource isi_resources[] = { + [0] = { + .start = AT91SAM9G45_BASE_ISI, + .end= AT91SAM9G45_BASE_ISI + SZ_16K - 1, + .flags = IORESOURCE_MEM, + }, + [1] = { + .start = AT91SAM9G45_ID_ISI, + .end= AT91SAM9G45_ID_ISI, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct platform_device at91sam9g45_isi_device = { + .name = "atmel_isi", + .id = 0, + .dev= { + .dma_mask = &isi_dmamask, + .coherent_dma_mask = DMA_BIT_MASK(32), + .platform_data = &isi_data, + }, + .resource = isi_resources, + .num_resources = ARRAY_SIZE(isi_resources), +}; + +static int __init isi_set_clk_parent(void) +{ + struct clk *pck1; + struct clk *plla; + int ret; + + /* ISI_MCK is supplied by PCK1 - set parent for it. */ + pck1 = clk_get(NULL, "pck1"); + if (IS_ERR(pck1)) { + printk(KERN_ERR "Failed to get PCK1\n"); + ret = PTR_ERR(pck1); + goto err; + } + + plla = clk_get(NULL, "plla"); + if (IS_ERR(plla)) { + printk(KERN_ERR "Failed to get PLLA\n"); + ret = PTR_ERR(plla); + goto err_pck1; + } + ret = clk_set_parent(pck1, plla); + clk_put(plla); + if (ret != 0) { + printk(KERN_ERR "Failed to set PCK1 parent\n"); + goto err_pck1; + } + return ret; + +err_pck1: + clk_put(pck1); +err: + return ret; +} + +void __init at91_add_device_isi(struct isi_platform_data * data) +{ + if (!data) + return; + isi_data = *data; + + at91_set_A_periph(AT91_PIN_PB20, 0);/* ISI_D0 */ + at91_set_A_periph(AT91_PIN_PB21, 0);/* ISI_D1 */ + at91_set_A_periph(AT91_PIN_PB22, 0);/* ISI_D2 */ + at91_set_A_periph(AT91_PIN_PB23, 0);/* ISI_D3 */ + at91_set_A_periph(AT91_PIN_PB24, 0);/* ISI_D4 */ + at91_set_A_periph(AT91_PIN_PB25, 0);/* ISI_D5 */ + at91_set_A_periph(AT91_PIN_PB26, 0);/* ISI_D6 */ + at91_set_A_periph(AT91_PIN_PB27, 0);/* ISI_D7 */ + at91_set_A_periph(AT91_PIN_PB28, 0);/* ISI_PCK */ + at91_set_A_periph(AT91_PIN_PB30, 0);/* ISI_HSYNC */ + at91_set_A_periph(AT91_PIN_PB29, 0);/* ISI_VSYNC */ + at91_set_B_periph(AT91_PIN_PB31, 0);/* ISI_MCK (PCK1) */ + at91_set_B_periph(AT91_PIN_PB8, 0); /* ISI_PD8 */ + at91_set_B_periph(AT91_PIN_PB9, 0); /* ISI_PD9 */
[PATCH v3 1/2][media] Add code to enable/disable ISI_MCK clock.
This patch add code to enable/disable ISI_MCK clock when add/remove soc camera device.it also set ISI_MCK frequence before using it. Signed-off-by: Josh Wu --- drivers/media/video/atmel-isi.c | 30 -- include/media/atmel-isi.h |2 ++ 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c index 7b89f00..888234a 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, provided by Programmable clock */ + struct clk *mck; unsigned intirq; struct isi_platform_data*pdata; @@ -763,6 +766,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); @@ -776,6 +785,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; @@ -897,6 +907,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); @@ -915,7 +926,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->isi_mck_hz) { dev_err(&pdev->dev, "No config available for Atmel ISI\n"); return -EINVAL; @@ -944,6 +955,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, which is provided by Programmable clock */ + isi->mck = clk_get(dev, "isi_mck"); + if (IS_ERR(isi->mck)) { + dev_err(dev, "Failed to get isi_mck\n"); + ret = PTR_ERR(isi->mck); + goto err_alloc_descriptors; + } + + /* Set ISI_MCK's frequency, it should be faster than pixel clock */ + ret = clk_set_rate(isi->mck, pdata->isi_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, @@ -951,7 +975,7 @@ static int __devinit atmel_isi_probe(struct platform_device *pdev) if (!isi->p_fb_descriptors) { ret = -ENOMEM; dev_err(&pdev->dev, "Can't allocate descriptors!\n"); - goto err_alloc_descriptors; + goto err_set_mck_rate; } for (i = 0; i < MAX_BUFFER_NUM; i++) { @@ -1013,6 +1037,8 @@ err_alloc_ctx: sizeof(struct fbd) * MAX_BUFFER_NUM, isi->p_fb_descriptors, isi->fb_descriptors_phys); +err_set_mck_rate: + clk_put(isi->mck); err_alloc_descriptors: kfree(isi); err_alloc_isi: diff --git a/include/media/atmel-isi.h b/include/media/atmel-isi.h index 26cece5..a0229a6 100644 --- a/include/media/atmel-isi.h +++ b/include/media/atmel-isi.h @@ -114,6 +114,8 @@ struct isi_platform_data { u32 data_width_flags; /* Using for ISI_CFG1 */ u32 frate; + /* Using for ISI_MCK, provided by Programmable clock */ + u32 isi_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 v2] [media] at91: add code to initialize and manage the ISI_MCK for Atmel ISI driver.
Hi, Nicolas On Friday, September 09, 2011 6:05 PM, Nicolas Ferre wrote: > Le 06/09/2011 08:54, Guennadi Liakhovetski : >> On Tue, 6 Sep 2011, Josh Wu wrote: >> >>> This patch enable the configuration for ISI_MCK, which is provided by >>> programmable clock. >>> >>> Signed-off-by: Josh Wu >>> --- >>> drivers/media/video/atmel-isi.c | 60 >>> ++- >>> include/media/atmel-isi.h |4 ++ >>> 2 files changed, 63 insertions(+), 1 deletions(-) >>> >>> diff --git a/drivers/media/video/atmel-isi.c >>> b/drivers/media/video/atmel-isi.c > [..] >>> /* >>> - >>> --*/ >>> +/* Initialize ISI_MCK clock, called by atmel_isi_probe() function */ >>> +static int initialize_mck(struct platform_device *pdev, >>> + struct atmel_isi *isi) >>> +{ >>> + struct device *dev = &pdev->dev; >>> + struct isi_platform_data *pdata = dev->platform_data; >>> + struct clk *pck_parent; >>> + int ret; >>> + >>> + if (!strlen(pdata->pck_name) || !strlen(pdata->pck_parent_name)) >>> + return -EINVAL; >>> + >>> + /* ISI_MCK is provided by PCK clock */ >>> + isi->mck = clk_get(dev, pdata->pck_name); >> >> I think, it's still not what Russell meant. Look at >> drivers/mmc/host/atmel-mci.c: >> >> host->mck = clk_get(&pdev->dev, "mci_clk"); >> >> and in arch/arm/mach-at91/at91sam9g45.c they've got >> >> CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk), >> CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk), >> >> where >> >> #define CLKDEV_CON_DEV_ID(_con_id, _dev_id, _clk)\ >> { \ >> .con_id = _con_id, \ >> .dev_id = _dev_id, \ >> .clk = _clk,\ >> } >> >> I.e., in the device driver (mmc in this case) you only use the >> (platform) device instance, whose dev_name(dev) is then matched >> against one of clock lookups above, and a connection ID, which is used >> in case your device is using more than one clock. In the ISI case, >> your pck1 clock, that you seem to need here, doesn't have a clock >> lookup object, so, you might have to add one, and then use its connection ID. >> >>> + if (IS_ERR(isi->mck)) { >>> + dev_err(dev, "Failed to get PCK: %s\n", pdata->pck_name); >>> + return PTR_ERR(isi->mck); >>> + } >>> + >>> + pck_parent = clk_get(dev, pdata->pck_parent_name); >>> + if (IS_ERR(pck_parent)) { >>> + ret = PTR_ERR(pck_parent); >>> + dev_err(dev, "Failed to get PCK parent: %s\n", >>> + pdata->pck_parent_name); >>> + goto err_init_mck; >>> + } >>> + >>> + ret = clk_set_parent(isi->mck, pck_parent); >> >> I'm not entirely sure on this one, but as we had a similar situation >> with clocks, we decided to extablish the clock hierarchy in the board >> code, and only deal with the actual device clocks in the driver >> itself. I.e., we moved all clk_set_parent() and setting up the parent clock >> into the board. >> And I do think, this makes more sense, than doing this in the driver, >> not all users of this driver will need to manage the parent clock, right? > Exactly. > > Josh, for the two comments by Guennadi above, you can take > sound/soc/atmel/sam9g20_wm8731.c as an example of using PCK and parent > clocks. You will also find how to use named clocks and how to set the > programmable clocks rate... According to sam9g20_wm8731.c file, and combined Guennadi and J.C's advices, I'd like to only add clk_set_rate() and enable/disble isi_mck code in ISI driver. Also I will define isi_mck clock in soc chip file(at91sam9g45.c). Then I will move all setting up the parent clock code into the at91sam9g45_devices.c, where there are code to add Atmel ISI device. I will generate the new version patch for it soon. >>> + clk_put(pck_parent); >>> + if (ret) >>> + goto err_init_mck; >>> + >>> + ret = clk_set_rate(isi->mck, pdata->isi_mck_hz); >>> + if (ret < 0) >>> + goto err_init_mck; >>> + >>> + return 0; >>> + >>> +err_init_mck: >>> + clk_put(isi->mck); >>> + return ret; >>> +} >>> + >>> static int __devexit atmel_isi_remove(struct platform_device *pdev) >>> { >>> struct soc_camera_host *soc_host = to_soc_camera_host(&pdev->dev); >>> @@ -897,6 +948,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); > [..] > Best regards, > -- > Nicolas Ferre Best Regards, Josh Wu -- To unsubscribe from this list: send the line "unsubscribe 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] [ver 1.06] it913x-fe - correct tuner settings. Resend
Correct tuner settings for more accuracy. This now makes the tuner section more compatible with other versions of the IT913X series. TODOs Version 2 chip Patch sent last week appears to be mangled and marked superseded. Signed-off-by: Malcolm Priestley --- drivers/media/dvb/frontends/it913x-fe-priv.h | 24 + drivers/media/dvb/frontends/it913x-fe.c | 139 -- 2 files changed, 113 insertions(+), 50 deletions(-) diff --git a/drivers/media/dvb/frontends/it913x-fe-priv.h b/drivers/media/dvb/frontends/it913x-fe-priv.h index b80634ab..40e1d9b 100644 --- a/drivers/media/dvb/frontends/it913x-fe-priv.h +++ b/drivers/media/dvb/frontends/it913x-fe-priv.h @@ -316,27 +316,13 @@ static struct it913xset it9137_set[] = { {0xff, 0x, {0x00}, 0x00}, /* Terminating Entry */ }; -static struct it913xset it9137_tuner[] = { - {PRO_DMOD, 0xec57, {0x00}, 0x01}, - {PRO_DMOD, 0xec58, {0x00}, 0x01}, - {PRO_DMOD, 0xec40, {0x00}, 0x01}, - {PRO_DMOD, 0xec02, {0x00, 0x0c, 0x00, 0x40, 0x00, 0x80, 0x80, - 0x00, 0x00, 0x00, 0x00 }, 0x0b}, - {PRO_DMOD, 0xec0d, {0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, - 0x00, 0x00, 0x00, 0x00 }, 0x0b}, - {PRO_DMOD, 0xec19, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, - 0x00, 0x00}, 0x08}, - {PRO_DMOD, 0xec22, {0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, - 0x00, 0x00, 0x00}, 0x0a}, - {PRO_DMOD, 0xec3f, {0x01}, 0x01}, - /* Clear any existing tune */ - {PRO_DMOD, 0xec4c, {0xa8, 0x00, 0x00, 0x00, 0x00}, 0x05}, - {0xff, 0x, {0x00}, 0x00}, /* Terminating Entry */ -}; - static struct it913xset set_it9137_template[] = { {PRO_DMOD, 0xee06, {0x00}, 0x01}, {PRO_DMOD, 0xec56, {0x00}, 0x01}, - {PRO_DMOD, 0xec4c, {0x00, 0x00, 0x00, 0x00, 0x00}, 0x05}, + {PRO_DMOD, 0xec4c, {0x00}, 0x01}, + {PRO_DMOD, 0xec4d, {0x00}, 0x01}, + {PRO_DMOD, 0xec4e, {0x00}, 0x01}, + {PRO_DMOD, 0xec4f, {0x00}, 0x01}, + {PRO_DMOD, 0xec50, {0x00}, 0x01}, {0xff, 0x, {0x00}, 0x00}, /* Terminating Entry */ }; diff --git a/drivers/media/dvb/frontends/it913x-fe.c b/drivers/media/dvb/frontends/it913x-fe.c index c92b3ec..02839a8b7 100644 --- a/drivers/media/dvb/frontends/it913x-fe.c +++ b/drivers/media/dvb/frontends/it913x-fe.c @@ -58,6 +58,10 @@ struct it913x_fe_state { u8 tuner_type; struct adctable *table; fe_status_t it913x_status; + u16 tun_xtal; + u8 tun_fdiv; + u8 tun_clk_mode; + u32 tun_fn_min; }; static int it913x_read_reg(struct it913x_fe_state *state, @@ -159,13 +163,74 @@ static int it913x_fe_script_loader(struct it913x_fe_state *state, return 0; } +static int it913x_init_tuner(struct it913x_fe_state *state) +{ + int ret, i, reg; + u8 val, nv_val; + u8 nv[] = {48, 32, 24, 16, 12, 8, 6, 4, 2}; + u8 b[2]; + + reg = it913x_read_reg_u8(state, 0xec86); + switch (reg) { + case 0: + state->tun_clk_mode = reg; + state->tun_xtal = 2000; + state->tun_fdiv = 3; + val = 16; + break; + case -ENODEV: + return -ENODEV; + case 1: + default: + state->tun_clk_mode = reg; + state->tun_xtal = 640; + state->tun_fdiv = 1; + val = 6; + break; + } + + reg = it913x_read_reg_u8(state, 0xed03); + + if (reg < 0) + return -ENODEV; + else if (reg < sizeof(nv)) + nv_val = nv[reg]; + else + nv_val = 2; + + for (i = 0; i < 50; i++) { + ret = it913x_read_reg(state, 0xed23, &b[0], sizeof(b)); + reg = (b[1] << 8) + b[0]; + if (reg > 0) + break; + if (ret < 0) + return -ENODEV; + udelay(2000); + } + state->tun_fn_min = state->tun_xtal * reg; + state->tun_fn_min /= (state->tun_fdiv * nv_val); + deb_info("Tuner fn_min %d", state->tun_fn_min); + + for (i = 0; i < 50; i++) { + reg = it913x_read_reg_u8(state, 0xec82); + if (reg > 0) + break; + if (reg < 0) + return -ENODEV; + udelay(2000); + } + + return it913x_write_reg(state, PRO_DMOD, 0xed81, val); +} + static int it9137_set_tuner(struct it913x_fe_state *state, enum fe_bandwidth bandwidth, u32 frequency_m) { struct it913xset *set_tuner = set_it9137_template; - int ret; + int ret, reg; u32 frequency = frequency_m / 1000; - u32 freq; + u32 freq, temp_f, tmp; + u16 iqik_m_cal; u16 n_div; u8 n; u8 l_band; @@ -218,10 +2
[PATCH] [VER 1.06] it913x add remote control support.
Add remote support for KWORLD UB499-2T-T09 The remote supplied is the same as KWORLD_315U. Signed-off-by: Malcolm Priestley --- drivers/media/dvb/dvb-usb/it913x.c | 34 +- 1 files changed, 33 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/it913x.c b/drivers/media/dvb/dvb-usb/it913x.c index 6d2f281..f027a2c 100644 --- a/drivers/media/dvb/dvb-usb/it913x.c +++ b/drivers/media/dvb/dvb-usb/it913x.c @@ -306,6 +306,30 @@ static struct i2c_algorithm it913x_i2c_algo = { }; /* Callbacks for DVB USB */ +#define IT913X_POLL 250 +static int it913x_rc_query(struct dvb_usb_device *d) +{ + u8 ibuf[4]; + int ret; + u32 key; + /* Avoid conflict with frontends*/ + if (mutex_lock_interruptible(&d->i2c_mutex) < 0) + return -EAGAIN; + + ret = it913x_io(d->udev, READ_LONG, PRO_LINK, CMD_IR_GET, + 0, 0, &ibuf[0], sizeof(ibuf)); + + if ((ibuf[2] + ibuf[3]) == 0xff) { + key = ibuf[2]; + key += ibuf[0] << 8; + deb_info(1, "INT Key =%08x", key); + if (d->rc_dev != NULL) + rc_keydown(d->rc_dev, key, 0); + } + mutex_unlock(&d->i2c_mutex); + + return ret; +} static int it913x_identify_state(struct usb_device *udev, struct dvb_usb_device_properties *props, struct dvb_usb_device_description **desc, @@ -575,6 +599,14 @@ static struct dvb_usb_device_properties it913x_properties = { } }, .identify_state = it913x_identify_state, + .rc.core = { + .protocol = RC_TYPE_NEC, + .module_name= "it913x", + .rc_query = it913x_rc_query, + .rc_interval= IT913X_POLL, + .allowed_protos = RC_TYPE_NEC, + .rc_codes = RC_MAP_KWORLD_315U, + }, .i2c_algo = &it913x_i2c_algo, .num_device_descs = 1, .devices = { @@ -615,5 +647,5 @@ module_exit(it913x_module_exit); MODULE_AUTHOR("Malcolm Priestley "); MODULE_DESCRIPTION("it913x USB 2 Driver"); -MODULE_VERSION("1.05"); +MODULE_VERSION("1.06"); MODULE_LICENSE("GPL"); -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.2] uvcvideo patches
Hi Mauro, The following changes since commit e27412f5a5966629e3d4213c78a539068ca0ea26: [media] mmp_camera: add MODULE_ALIAS (2011-09-18 08:05:43 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Al Cooper (1): media: Fix a UVC performance problem on systems with non-coherent DMA. Arne Caspari (1): uvcvideo: Detect The Imaging Source CCD cameras by vendor and product ID Laurent Pinchart (2): uvcvideo: Remove deprecated UVCIOC ioctls USB: export video.h to the includes available for userspace Stephan Lachowsky (1): uvcvideo: Add a mapping for H.264 payloads Documentation/feature-removal-schedule.txt | 23 -- drivers/media/video/uvc/uvc_driver.c | 13 drivers/media/video/uvc/uvc_v4l2.c | 54 +-- drivers/media/video/uvc/uvc_video.c| 17 - drivers/media/video/uvc/uvcvideo.h | 104 ++- include/linux/usb/Kbuild |1 + 6 files changed, 40 insertions(+), 172 deletions(-) -- 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: Patches at patchwork.linuxtv.org (127 patches)
Hi Mauro, On Thursday 22 September 2011 00:20:09 Mauro Carvalho Chehab wrote: > Em 21-09-2011 18:58, Laurent Pinchart escreveu: > >> Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats > >> http://patchwork.linuxtv.org/patch/7630 > > > > This one has been superseeded. Speaking of this, the next version of the > > patch will be needed for an fbdev driver that should make it to v3.3. > > Should I push NV24 support through your tree for v3.2 to make sure > > compilation won't break during the v3.3 merge window ? > > The better is to submit both patches to the same tree, getting the > maintainer's ack from the other side. I'm ok with either direction. If you > opt to sent the patches via fbdev tree, send me the latest version of it > for me to review and ack. linux-media has already been CC'ed. "[PATCH v3 2/3] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats" http://patchwork.linuxtv.org/patch/306/ > >> Sep, 5 2011: BUG: unable to handle kernel paging request at 6b6b6bcb > >> (v4l2_device_d > >> http://patchwork.linuxtv.org/patch/7779 > > > > Superseeded as well. > > > >> Sep,12 2011: [GIT,PULL,FOR,v3.1] v4l and uvcvideo fixes > >> http://patchwork.linuxtv.org/patch/7835 > > > > Please pull that :-) It's for v3.1, there's not much time left. > > I will. Thank you. > >>== Patches waiting for Laurent Pinchart review == > > > > [snip] > > > >> Jul,12 2011: v4l: mem2mem: add wait_{prepare,finish} ops to m2m_testdev > >> http://patchwork.linuxtv.org/patch/7431 > > > > I don't think that one is for me. > > > >> Jul,10 2011: [3/3] Make use of 8-bit and 16-bit YCrCb media bus pixel > >> codes in adv7 > >> http://patchwork.linuxtv.org/patch/7425 > > > > I don't think this one is for me either. > > Hmm.. not sure why I put those two for you. Will fix that on my control > files. > > Thank you! You're welcome. Thank you for your work on this, and the speed at which you got it running. -- 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: Patches at patchwork.linuxtv.org (127 patches)
Em 21-09-2011 18:58, Laurent Pinchart escreveu: >> Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats >> http://patchwork.linuxtv.org/patch/7630 > > This one has been superseeded. Speaking of this, the next version of the > patch > will be needed for an fbdev driver that should make it to v3.3. Should I push > NV24 support through your tree for v3.2 to make sure compilation won't break > during the v3.3 merge window ? The better is to submit both patches to the same tree, getting the maintainer's ack from the other side. I'm ok with either direction. If you opt to sent the patches via fbdev tree, send me the latest version of it for me to review and ack. > >> Sep, 5 2011: BUG: unable to handle kernel paging request at 6b6b6bcb >> (v4l2_device_d >> http://patchwork.linuxtv.org/patch/7779 > > Superseeded as well. > >> Sep,12 2011: [GIT,PULL,FOR,v3.1] v4l and uvcvideo fixes >> http://patchwork.linuxtv.org/patch/7835 > > Please pull that :-) It's for v3.1, there's not much time left. I will. >> == Patches waiting for Laurent Pinchart review == > > [snip] > >> Jul,12 2011: v4l: mem2mem: add wait_{prepare,finish} ops to m2m_testdev >> http://patchwork.linuxtv.org/patch/7431 > > I don't think that one is for me. > >> Jul,10 2011: [3/3] Make use of 8-bit and 16-bit YCrCb media bus pixel >> codes in adv7 >> http://patchwork.linuxtv.org/patch/7425 > > I don't think this one is for me either. Hmm.. not sure why I put those two for you. Will fix that on my control files. Thank you! Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patches at patchwork.linuxtv.org (127 patches)
Em 21-09-2011 18:09, Sylwester Nawrocki escreveu: > Hi Mauro, > Updated accordingly, thanks! >> Sep,19 2011: [GIT,PATCHES,FOR,3.2] noon010pc30 conversion to the pad level >> ops http://patchwork.linuxtv.org/patch/7877 Sylwester >> Nawrocki > not really a patch This patchwork version is capable of getting git pull requests, when generated with git request-pull. I'm planning to change my scripts to recognize those requests and use it. An unique queue helps me to apply patches at the arrival order. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patches at patchwork.linuxtv.org (127 patches)
Hi Mauro, On Wednesday 21 September 2011 22:44:20 Mauro Carvalho Chehab wrote: > Em 21-09-2011 17:40, Mauro Carvalho Chehab escreveu: > > As announced on Sept, 18, we moved our patch queue to > > patchwork.linuxtv.org. Thank you for working on that. [snip] > Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats > http://patchwork.linuxtv.org/patch/7630 This one has been superseeded. Speaking of this, the next version of the patch will be needed for an fbdev driver that should make it to v3.3. Should I push NV24 support through your tree for v3.2 to make sure compilation won't break during the v3.3 merge window ? > Sep, 5 2011: BUG: unable to handle kernel paging request at 6b6b6bcb > (v4l2_device_d > http://patchwork.linuxtv.org/patch/7779 Superseeded as well. > Sep,12 2011: [GIT,PULL,FOR,v3.1] v4l and uvcvideo fixes > http://patchwork.linuxtv.org/patch/7835 Please pull that :-) It's for v3.1, there's not much time left. > == Patches waiting for Laurent Pinchart review == [snip] > Jul,12 2011: v4l: mem2mem: add wait_{prepare,finish} ops to m2m_testdev > http://patchwork.linuxtv.org/patch/7431 I don't think that one is for me. > Jul,10 2011: [3/3] Make use of 8-bit and 16-bit YCrCb media bus pixel > codes in adv7 > http://patchwork.linuxtv.org/patch/7425 I don't think this one is for me either. -- 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: Patches at patchwork.linuxtv.org (127 patches)
Hi Mauro, On 09/21/2011 10:44 PM, Mauro Carvalho Chehab wrote: > Em 21-09-2011 17:40, Mauro Carvalho Chehab escreveu: >> As announced on Sept, 18, we moved our patch queue to patchwork.linuxtv.org. >> >> As we were without access to the old patchwork instance, I simply sent all >> emails I had locally stored on my local mahine to the new instance and >> reviewed >> all patches again. Basically, for old patches, I basically did some scripting >> that were marking old patches as "superseded", if they didn't apply anymore. >> I also preserved the patches that were marked as "under review" from >> patchwork >> time, using some scripting and a local control file. >> >> So, we're basically close to what we had before kernel.org troubles (except >> for >> a series of patches that I've already applied today). >> >> My intention is to finish review all patches marked as "new" until the end >> of this >> week, and set a new tree for linux-next with our stuff (as the old one were >> at >> git.kernel.org). >> >> Please let me know if something is missed or if some patch from the list >> bellow >> is obsolete and can be marked with a different status. >> >> Thanks! >> Mauro >> ... > == New patches == > > Aug, 6 2011: [1/7] move ati_remote driver from input/misc to media/rc > http://patchwork.linuxtv.org/patch/255Anssi > Hannula > Aug, 6 2011: [3/7] ati_remote: parent input devices to usb interface > http://patchwork.linuxtv.org/patch/251Anssi > Hannula > Aug, 6 2011: [4/7] ati_remote: fix check for a weird byte > http://patchwork.linuxtv.org/patch/253Anssi > Hannula > Aug, 6 2011: [5/7] ati_remote: add keymap for Medion X10 RF remote > http://patchwork.linuxtv.org/patch/250Anssi > Hannula > Aug, 6 2011: [6/7] ati_remote: add support for SnapStream Firefly remote > http://patchwork.linuxtv.org/patch/252Anssi > Hannula > Aug, 6 2011: [7/7] ati_remote: update Kconfig description > http://patchwork.linuxtv.org/patch/254Anssi > Hannula > Aug,20 2011: [2/6] Fix memory leak on disconnect or error. > http://patchwork.linuxtv.org/patch/270Chris > Rankin > Aug,20 2011: [1/2] EM28xx - fix race on disconnect > http://patchwork.linuxtv.org/patch/275Chris > Rankin > Aug,20 2011: [2/2] EM28xx - fix deadlock when unplugging and replugging a DVB > adapt http://patchwork.linuxtv.org/patch/276Chris > Rankin > Aug,20 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB > adapt http://patchwork.linuxtv.org/patch/278Chris > Rankin > Aug,21 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB > adapt http://patchwork.linuxtv.org/patch/279Chris > Rankin > Aug,27 2011: OMAP_VOUT: Fix check in reqbuf& mmap for buf_size allocation > http://patchwork.linuxtv.org/patch/304Archit Taneja > Sep,16 2011: [1/5] : OMAP_VOUT: Fix check in reqbuf& mmap for buf_size > allocation http://patchwork.linuxtv.org/patch/353Archit > Taneja > Sep,16 2011: [2/5] : OMAP_VOUT: CLEANUP: Remove redundant code from > omap_vout_isr http://patchwork.linuxtv.org/patch/354Archit > Taneja > Aug, 4 2011: [21/21,staging] tm6000: Remove unnecessary workaround. > http://patchwork.linuxtv.org/patch/7088 Thierry > Reding > Aug, 5 2011: [1/1] Add driver support for ITE IT9135 device > http://patchwork.linuxtv.org/patch/7090 > jasondong > May,23 2011: Alternate setting 1 must be selected for interface 0 on the > model that http://patchwork.linuxtv.org/patch/7179 Hans Petter > Selasky > Jul, 7 2011: V4L2: OMAP: VOUT: Changes to support NV12-color format on OMAP4 > http://patchwork.linuxtv.org/patch/7414 Amber Jain > Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats > http://patchwork.linuxtv.org/patch/7630 Laurent Pinchart Pinchart> > Aug,27 2011: vp702x_fe_set_frontend+0x156/0x1a0 [dvb_usb_vp702x] > http://patchwork.linuxtv.org/patch/7683 Florian > Mickler > Aug,29 2011: [GIT,PULL,for,v3.1-rc] OMAP_VOUT: Fix build failure > http://patchwork.linuxtv.org/patch/7687 Hiremath, > Vaibhav > Aug,29 2011: tvp5150: add v4l2 subdev pad ops > http://patchwork.linuxtv.org/patch/7700 > Enrico > Aug,29 2011: [V4L2] decrement struct v4l2_device refcount on device > unregister http://patchwork.linuxtv.org/patch/7701 Maciej > Szmigiero > Aug,31 2011: TT CT-3650 CI support > http://patchwork.linuxtv.org/patch/7732 > Sep, 4 2011: Medion 95700 analog video support > http://patchwork.linuxtv.org/patch/7767 Maciej Szmigiero > Sep, 5 2011: Add support for PCTV452E. >
Re: Patches at patchwork.linuxtv.org (127 patches)
Em 21-09-2011 17:40, Mauro Carvalho Chehab escreveu: > As announced on Sept, 18, we moved our patch queue to patchwork.linuxtv.org. > > As we were without access to the old patchwork instance, I simply sent all > emails I had locally stored on my local mahine to the new instance and > reviewed > all patches again. Basically, for old patches, I basically did some scripting > that were marking old patches as "superseded", if they didn't apply anymore. > I also preserved the patches that were marked as "under review" from patchwork > time, using some scripting and a local control file. > > So, we're basically close to what we had before kernel.org troubles (except > for > a series of patches that I've already applied today). > > My intention is to finish review all patches marked as "new" until the end of > this > week, and set a new tree for linux-next with our stuff (as the old one were at > git.kernel.org). > > Please let me know if something is missed or if some patch from the list > bellow > is obsolete and can be marked with a different status. > > Thanks! > Mauro > > > == New patches == Gah! forgot to update the URL on my script. the patch list with the right URL is: == New patches == Aug, 6 2011: [1/7] move ati_remote driver from input/misc to media/rc http://patchwork.linuxtv.org/patch/255Anssi Hannula Aug, 6 2011: [3/7] ati_remote: parent input devices to usb interface http://patchwork.linuxtv.org/patch/251Anssi Hannula Aug, 6 2011: [4/7] ati_remote: fix check for a weird byte http://patchwork.linuxtv.org/patch/253Anssi Hannula Aug, 6 2011: [5/7] ati_remote: add keymap for Medion X10 RF remote http://patchwork.linuxtv.org/patch/250Anssi Hannula Aug, 6 2011: [6/7] ati_remote: add support for SnapStream Firefly remote http://patchwork.linuxtv.org/patch/252Anssi Hannula Aug, 6 2011: [7/7] ati_remote: update Kconfig description http://patchwork.linuxtv.org/patch/254Anssi Hannula Aug,20 2011: [2/6] Fix memory leak on disconnect or error. http://patchwork.linuxtv.org/patch/270Chris Rankin Aug,20 2011: [1/2] EM28xx - fix race on disconnect http://patchwork.linuxtv.org/patch/275Chris Rankin Aug,20 2011: [2/2] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/276Chris Rankin Aug,20 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/278Chris Rankin Aug,21 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.linuxtv.org/patch/279Chris Rankin Aug,27 2011: OMAP_VOUT: Fix check in reqbuf & mmap for buf_size allocation http://patchwork.linuxtv.org/patch/304Archit Taneja Sep,16 2011: [1/5] : OMAP_VOUT: Fix check in reqbuf & mmap for buf_size allocation http://patchwork.linuxtv.org/patch/353Archit Taneja Sep,16 2011: [2/5] : OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr http://patchwork.linuxtv.org/patch/354Archit Taneja Aug, 4 2011: [21/21,staging] tm6000: Remove unnecessary workaround. http://patchwork.linuxtv.org/patch/7088 Thierry Reding Aug, 5 2011: [1/1] Add driver support for ITE IT9135 device http://patchwork.linuxtv.org/patch/7090 jasondong May,23 2011: Alternate setting 1 must be selected for interface 0 on the model that http://patchwork.linuxtv.org/patch/7179 Hans Petter Selasky Jul, 7 2011: V4L2: OMAP: VOUT: Changes to support NV12-color format on OMAP4 http://patchwork.linuxtv.org/patch/7414 Amber Jain Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats http://patchwork.linuxtv.org/patch/7630 Laurent Pinchart > Aug,27 2011: vp702x_fe_set_frontend+0x156/0x1a0 [dvb_usb_vp702x] http://patchwork.linuxtv.org/patch/7683 Florian Mickler Aug,29 2011: [GIT,PULL,for,v3.1-rc] OMAP_VOUT: Fix build failure http://patchwork.linuxtv.org/patch/7687 Hiremath, Vaibhav Aug,29 2011: tvp5150: add v4l2 subdev pad ops http://patchwork.linuxtv.org/patch/7700 Enrico Aug,29 2011: [V4L2] decrement struct v4l2_device refcount on device unregister http://patchwork.linuxtv.org/patch/7701 Maciej Szmigiero Aug,31 2011: TT CT-3650 CI support http://patchwork.linuxtv.org/patch/7732 Sep, 4 2011: Medion 95700 analog video support http://patchwork.linuxtv.org/patch/7767 Maciej Szmigiero Sep, 5 2011: Add support for PCTV452E. http://patchwork.linuxtv.org/patch/7778 Oliver Freyermuth Sep, 5 2011: BUG: unable to handle kernel
Patches at patchwork.linuxtv.org (127 patches)
As announced on Sept, 18, we moved our patch queue to patchwork.linuxtv.org. As we were without access to the old patchwork instance, I simply sent all emails I had locally stored on my local mahine to the new instance and reviewed all patches again. Basically, for old patches, I basically did some scripting that were marking old patches as "superseded", if they didn't apply anymore. I also preserved the patches that were marked as "under review" from patchwork time, using some scripting and a local control file. So, we're basically close to what we had before kernel.org troubles (except for a series of patches that I've already applied today). My intention is to finish review all patches marked as "new" until the end of this week, and set a new tree for linux-next with our stuff (as the old one were at git.kernel.org). Please let me know if something is missed or if some patch from the list bellow is obsolete and can be marked with a different status. Thanks! Mauro == New patches == Aug, 6 2011: [1/7] move ati_remote driver from input/misc to media/rc http://patchwork.kernel.org/patch/255 Anssi Hannula Aug, 6 2011: [3/7] ati_remote: parent input devices to usb interface http://patchwork.kernel.org/patch/251 Anssi Hannula Aug, 6 2011: [4/7] ati_remote: fix check for a weird byte http://patchwork.kernel.org/patch/253 Anssi Hannula Aug, 6 2011: [5/7] ati_remote: add keymap for Medion X10 RF remote http://patchwork.kernel.org/patch/250 Anssi Hannula Aug, 6 2011: [6/7] ati_remote: add support for SnapStream Firefly remote http://patchwork.kernel.org/patch/252 Anssi Hannula Aug, 6 2011: [7/7] ati_remote: update Kconfig description http://patchwork.kernel.org/patch/254 Anssi Hannula Aug,20 2011: [2/6] Fix memory leak on disconnect or error. http://patchwork.kernel.org/patch/270 Chris Rankin Aug,20 2011: [1/2] EM28xx - fix race on disconnect http://patchwork.kernel.org/patch/275 Chris Rankin Aug,20 2011: [2/2] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.kernel.org/patch/276 Chris Rankin Aug,20 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.kernel.org/patch/278 Chris Rankin Aug,21 2011: [1/1] EM28xx - fix deadlock when unplugging and replugging a DVB adapt http://patchwork.kernel.org/patch/279 Chris Rankin Aug,27 2011: OMAP_VOUT: Fix check in reqbuf & mmap for buf_size allocation http://patchwork.kernel.org/patch/304 Archit Taneja Sep,16 2011: [1/5] : OMAP_VOUT: Fix check in reqbuf & mmap for buf_size allocation http://patchwork.kernel.org/patch/353 Archit Taneja Sep,16 2011: [2/5] : OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr http://patchwork.kernel.org/patch/354 Archit Taneja Aug, 4 2011: [21/21,staging] tm6000: Remove unnecessary workaround. http://patchwork.kernel.org/patch/7088Thierry Reding Aug, 5 2011: [1/1] Add driver support for ITE IT9135 device http://patchwork.kernel.org/patch/7090jasondong May,23 2011: Alternate setting 1 must be selected for interface 0 on the model that http://patchwork.kernel.org/patch/7179Hans Petter Selasky Jul, 7 2011: V4L2: OMAP: VOUT: Changes to support NV12-color format on OMAP4 http://patchwork.kernel.org/patch/7414Amber Jain Aug,19 2011: v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats http://patchwork.kernel.org/patch/7630Laurent Pinchart > Aug,27 2011: vp702x_fe_set_frontend+0x156/0x1a0 [dvb_usb_vp702x] http://patchwork.kernel.org/patch/7683Florian Mickler Aug,29 2011: [GIT,PULL,for,v3.1-rc] OMAP_VOUT: Fix build failure http://patchwork.kernel.org/patch/7687Hiremath, Vaibhav Aug,29 2011: tvp5150: add v4l2 subdev pad ops http://patchwork.kernel.org/patch/7700Enrico Aug,29 2011: [V4L2] decrement struct v4l2_device refcount on device unregister http://patchwork.kernel.org/patch/7701Maciej Szmigiero Aug,31 2011: TT CT-3650 CI support http://patchwork.kernel.org/patch/7732 Sep, 4 2011: Medion 95700 analog video support http://patchwork.kernel.org/patch/7767Maciej Szmigiero Sep, 5 2011: Add support for PCTV452E. http://patchwork.kernel.org/patch/7778Oliver Freyermuth Sep, 5 2011: BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_d http://patchwork.kernel.org/patch/7779Sitsofe Wheeler Sep, 6 2011: [v2] at91: add code to initialize and manage the ISI_MCK for Atmel ISI http://patchwork.kernel.org/patch/7780
Re: [GIT PATCHES FOR 3.2] gspca for_v3.2
Em 12-08-2011 05:37, Jean-Francois Moine escreveu: > The following changes since commit > 9bed77ee2fb46b74782d0d9d14b92e9d07f3df6e: > > [media] tuner_xc2028: Allow selection of the frequency adjustment code for > XC3028 (2011-08-06 09:52:47 -0300) > > are available in the git repository at: > git://linuxtv.org/jfrancois/gspca.git for_v3.2 Jean-François, The last 3 patches didn't apply. Could you please re-base them over the current tree? Thanks! Mauro > > Jean-François Moine (15): > gspca - ov519: Fix LED inversion of some ov519 webcams > gspca - sonixj: Fix the darkness of sensor om6802 in 320x240 > gspca - jeilinj: Cleanup code > gspca - sonixj: Adjust the contrast control > gspca - sonixj: Increase the exposure for sensor soi768 > gspca - sonixj: Cleanup source and remove useless instructions > gspca - benq: Remove the useless function sd_isoc_init > gspca - kinect: Remove the gspca_debug definition > gspca - ov534_9: Use the new control mechanism > gspca - ov534_9: New sensor ov9712 and new webcam 05a9:8065 > gspca - main: Fix the isochronous transfer interval > gspca - main: Better values for V4L2_FMT_FLAG_COMPRESSED > gspca - main: Use a better altsetting for image transfer > gspca - main: Handle the xHCI error on usb_set_interface() > gspca - tp6800: New subdriver for Topro webcams > > Luiz Carlos Ramos (1): > gspca - sonixj: Fix wrong register mask for sensor om6802 > > Documentation/video4linux/gspca.txt |3 + > drivers/media/video/gspca/Kconfig |9 + > drivers/media/video/gspca/Makefile |2 + > drivers/media/video/gspca/benq.c| 15 - > drivers/media/video/gspca/gspca.c | 234 ++- > drivers/media/video/gspca/jeilinj.c | 10 +- > drivers/media/video/gspca/kinect.c |5 - > drivers/media/video/gspca/ov519.c | 22 +- > drivers/media/video/gspca/ov534_9.c | 504 ++-- > drivers/media/video/gspca/sonixj.c | 29 +- > drivers/media/video/gspca/tp6800.c | 4989 > +++ > 11 files changed, 5430 insertions(+), 392 deletions(-) > create mode 100644 drivers/media/video/gspca/tp6800.c > -- To unsubscribe from this list: send the line "unsubscribe 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: cx231xx: DMA problem on ARM
Hello Devin, Thanks for your quick reply. Le Wed, 21 Sep 2011 08:04:52 -0400, Devin Heitmueller a écrit : > I ran into the same issue on em28xx in the past (which is what those > parts of cx231xx are based on). Yes, just adding > URB_NO_TRANSFER_DMA_MAP should result in it starting to work. Please > try that out, and assuming it works feel free to submit a patch which > can be included upstream. Ok, we'll try this out and report the results, and if those are positive, the corresponding patch. Regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.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: frame grabber INT-1461 under Linux
What's strange? card=77 is for "GrandTec Multi Capture Card (Bt878)", according to the "http://linuxtv.org/hg/v4l-dvb/file/tip/linux/Documentation/video4linux/CARD LIST.bttv". Sensoray has a Model 311 (http://www.sensoray.com/products/311.htm), with card=73. I knew that the INT-1461 is very similar to Sensoray's Model 311. So, you may try card=73. -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Pavel Andris Sent: Wednesday, September 21, 2011 2:33 AM To: linux-media@vger.kernel.org Subject: frame grabber INT-1461 under Linux Hi, dmesg has asked me to mail you. Here's the essential part of the message: [1.806495] Linux video capture interface: v2.00 [1.806607] bttv: driver version 0.9.18 loaded [1.806613] bttv: using 8 buffers with 2080k (520 pages) each for capture [1.806669] bttv: Bt8xx card found (0). [1.806692] bttv :01:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [1.806710] bttv0: Bt878 (rev 17) at :01:01.0, irq: 17, latency: 64, mmio: 0xfdfff000 [1.806753] bttv0: subsystem: 1766: (UNKNOWN) [1.806758] please mail id, board name and the correct card= insmod option to linux-media@vger.kernel.org [1.806766] bttv0: using: GrandTec Multi Capture Card (Bt878) [card=77,insmod option] [1.806839] bttv0: gpio: en=, out= in=00e31fff [init] [1.807003] bttv0: tuner absent [1.807086] bttv0: registered device video0 [1.807179] bttv0: registered device vbi0 [1.807204] bttv0: PLL: 28636363 => 35468950 .. ok [1.847974] bt878: AUDIO driver version 0.0.0 loaded I use bttv.card=77 kernel parameter. With no parameter, the frame grabber works, but in a strange way. Info about my frame grabber: INT-1461 PC/104-Plus Frame Grabber w/ 4 CVBS Inputs & 24 DIO The INT-1461 video frame grabber is a low-cost, high-performance solution for capturing analog broadcast signals across the PCI bus. Based around the Conexant FusionTM 878A video decoder, this compact PC/104-Plus form factor board supports NTSC, PAL, and SECAM video formats at capture resolutions of up to 768 x 576 pixels and 30 frames per second. It can also sub-sample, scale, crop, and clip images at various resolutions and frame rates. You can easily find more info on the net. Thank you for writing and supporting media drivers. Regards, -- .. Pavel Andris | tel: +421 2 5941 1167 Institute of Informatics | fax: +421 2 5477 3271 Slovak Academy of Sciences | Dubravska cesta 9 | e-mail: utrra...@savba.sk SK - 845 07 Bratislava | Slovak republic| .. "One hundred thousand lemmings cannot be wrong." Graffiti .. -- To unsubscribe from this list: send the line "unsubscribe 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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
Mauro, On Wed, Sep 21, 2011 at 10:14 PM, Mauro Carvalho Chehab wrote: > Em 04-05-2011 08:27, Lutz Sammer escreveu: >> On 05/04/11 01:16, Mauro Carvalho Chehab wrote: >>> Em 13-04-2011 21:05, Lutz Sammer escreveu: > On 05/04/11 21:07, Steffen Barszus wrote: >> On Tue, 05 Apr 2011 13:00:14 +0200 >> "Issa Gorissen" wrote: >> >>> Hi, >>> >>> Eutelsat made a recent migration from DVB-S to DVB-S2 (since >>> 31/3/2011) on two transponders on HB13E >>> >>> - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 >>> Msymb/s 0.2 Pilot off Polar H >>> >>> - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 >>> Msymb/s 0.2 Pilot off Polar H >>> >>> >>> Before those changes, with my TT S2 3200, I was able to watch TV on >>> those transponders. Now, I cannot even tune on those transponders. I >>> have tried with scan-s2 and w_scan and the latest drivers from git. >>> They both find the transponders but cannot tune onto it. >>> >>> Something noteworthy is that my other card, a DuoFlex S2 can tune >>> fine on those transponders. >>> >>> My question is; can someone try this as well with a TT S2 3200 and >>> post the results ? >> i read something about it lately here (german!): >> http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 >> >> It says in stb0899_drv.c function: >> static void stb0899_set_iterations(struct stb0899_state *state) >> >> This: >> reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); >> STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); >> stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, >> STB0899_OFF0_MAX_ITER, reg); >> >> should be replaced with this: >> >> reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); >> STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); >> stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, >> STB0899_OFF0_MAX_ITER, reg); >> >> Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines >> affected. >> >> Kind Regards >> >> Steffen > Hi Steffen, > > Unfortunately, it does not help in my case. Thx anyway. Try my locking fix. With above patch I can lock the channels without problem. >>> >>> Can someone confirm that such patch would fix the issue? If so, please >>> forward it in a way that it could be applied (patch is currently >>> line-wrapped), >>> and submit with some comments/description and your SOB. >>> >>> As the patch is currently broken, I'm just marking it as rejected at >>> patchwork. >>> >>> Manu, >>> >>> Please take a look on this trouble report. >>> >> >> Sorry, the things are mixed here. My patch (resend and hopefully this >> time not broken) handles only DVB-S transponders. >> >> The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz for >> me. But I have very weak receiption, >> >> Johns > > Manu, > > We're still missing your review on this patch[1], or it were eventually > missed. Please review it. > > Thanks, > Mauro > > [1] http://patchwork.linuxtv.org/patch/6511/ > Patch is good and correct. Thanks. Reviewed-by: Manu Abraham -- To unsubscribe from this list: send the line "unsubscribe 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: WARNINGS
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 Sep 21 19:00:16 CEST 2011 git hash:e553000a14ead0e265a8aa4d241c7b3221e233e3 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.3-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: 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-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-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
[PATCH v2 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
This driver exposes preview mode operation of the S5K6AAFX sensor with embedded SoC ISP. It uses one of the five user predefined configuration register sets. There is yet no support for capture (snapshot) operation. Following controls are supported: manual/auto exposure and gain, power line frequency (anti-flicker), saturation, sharpness, brightness, contrast, white balance temperature, color effects, horizontal/vertical image flip, frame interval. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1482 ++ include/media/s5k6aa.h | 51 ++ 4 files changed, 1541 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5k6aa.c create mode 100644 include/media/s5k6aa.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 9da6044..ccc8172 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -496,6 +496,13 @@ config VIDEO_TCM825X This is a driver for the Toshiba TCM825x VGA camera sensor. It is used for example in Nokia N800. +config VIDEO_S5K6AA + tristate "Samsung S5K6AAFX sensor support" + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API + ---help--- + This is a V4L2 sensor-level driver for Samsung S5K6AA(FX) 1.3M + camera sensor with an embedded SoC image signal processor. + comment "Flash devices" config VIDEO_ADP1653 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index f52a771..526cb32 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_M5MOLS) += m5mols/ +obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o obj-$(CONFIG_VIDEO_ADP1653)+= adp1653.o obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o diff --git a/drivers/media/video/s5k6aa.c b/drivers/media/video/s5k6aa.c new file mode 100644 index 000..43b7dac --- /dev/null +++ b/drivers/media/video/s5k6aa.c @@ -0,0 +1,1482 @@ +/* + * Driver for Samsung S5K6AAFX SXGA 1/6" 1.3M CMOS Image Sensor + * with embedded SoC ISP. + * + * Copyright (C) 2011, Samsung Electronics Co., Ltd. + * Author: Sylwester Nawrocki + * + * Based on a driver authored by Dongsoo Nathaniel Kim. + * Copyright (C) 2009, Dongsoo Nathaniel Kim + * + * 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; either version 2 of the License, or + * (at your option) any later version. + * + * TODO: + * - add set/get_crop operations + * - add capture (snapshot) mode support + */ + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include + +static int debug; +module_param(debug, int, 0644); + +#define DRIVER_NAME"S5K6AA" + +/* The token to indicate array termination */ +#define S5K6AA_TERM0x +#define S5K6AA_OUT_WIDTH_DEF 640 +#define S5K6AA_OUT_HEIGHT_DEF 480 +#define S5K6AA_WIN_WIDTH_MAX 1280 +#define S5K6AA_WIN_HEIGHT_MAX 1024 +#define S5K6AA_WIN_WIDTH_MIN 8 +#define S5K6AA_WIN_HEIGHT_MIN 8 + +/* + * H/W register Interface (0xD000 - 0xDFFF) + */ +#define AHB_MSB_ADDR_PTR 0xfcfc +#define GEN_REG_OFFSH 0xd000 +#define REG_SW_RESET 0x0010 +#define REG_SW_LOAD_COMPLETE 0x0014 +#define REG_CMDWR_ADDRH0x0028 +#define REG_CMDWR_ADDRL0x002a +#define REG_CMDRD_ADDRH0x002c +#define REG_CMDRD_ADDRL0x002e + +#define REG_CMDBUF0_ADDR 0x0f12 +#define REG_CMDBUF1_ADDR 0x0f10 + +/* + * Host S/W Register interface (0x7000 - 0x70002000) + * The value of the two most significant address bytes is 0x7000, + * (HOST_SWIF_OFFS_H). The register addresses below specify 2 LSBs. + */ +#define HOST_SWIF_OFFSH0x7000 + +/* Initialization parameters */ +/* Master clock frequency in KHz */ +#define REG_I_INCLK_FREQ_L 0x01b8 +#define REG_I_INCLK_FREQ_H 0x01ba +#define REG_I_USE_NPVI_CLOCKS 0x01c6 +#define REG_I_USE_NMIPI_CLOCKS 0x01c8 + +/* Clock configurations, n = 0..3. REG_I_* frequency unit is 4 kHz. */ +#define REG_I_OPCLK_4KHZ(n)((n) * 6 + 0x01cc) +#define REG_I_MIN_OUTRATE_4KHZ(n) ((n) * 6 + 0x01ce) +#define REG_I_MAX_OUTRATE_4KHZ(n) ((n) * 6 + 0x01d0) +#define REG_I_INIT_PARAMS_UPDATED 0x01e0 +#define MIN_MCLK_FREQ_KHZ 6000U +#define MAX_MCLK_FREQ_KHZ 27000
[PATCH v2 0/3] Add v4l2 subdev driver for S5K6AAFX sensor
Hello The following change set adds subdev driver for S5K6AAFX sensor with embedded ISP SoC, and minor v4l2 control API enhancement. Changes since v1: - improved s5k6aa_initialize_ctrls() - fixed pixel resolution update issue which in some cases resulted in cropping where scaling was expected - used V4L2_COLORFX_SKY_BLUE instead of V4L2_COLORFX_AQUA - dropped patch adding V4L2_COLORFX_AQUA entry for V4L2_CID_COLORFX control - patch 2/2 - no changes Sylwester Nawrocki (2): v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control v4l: Add v4l2 subdev driver for S5K6AAFX sensor Documentation/DocBook/media/v4l/controls.xml |5 +- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/s5k6aa.c | 1482 ++ drivers/media/video/v4l2-ctrls.c |1 + include/linux/videodev2.h|1 + include/media/s5k6aa.h | 51 + 7 files changed, 1546 insertions(+), 2 deletions(-) create mode 100644 drivers/media/video/s5k6aa.c create mode 100644 include/media/s5k6aa.h Thanks, -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct a driver what is the power line frequency so an appropriate filter can be used by the device to cancel flicker by compensating the light intensity ripple. Currently in the menu we have entries for 50 Hz and 60 Hz and for entirely disabling the anti-flicker filter. However some devices are capable of automatically detecting the frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Acked-by: Laurent Pinchart --- Documentation/DocBook/media/v4l/controls.xml |5 +++-- drivers/media/video/v4l2-ctrls.c |1 + include/linux/videodev2.h|1 + 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 23fdf79..3bc5ee8 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -232,8 +232,9 @@ control is deprecated. New drivers and applications should use the Enables a power line frequency filter to avoid flicker. Possible values for enum v4l2_power_line_frequency are: V4L2_CID_POWER_LINE_FREQUENCY_DISABLED (0), -V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1) and -V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2). +V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1), +V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2) and +V4L2_CID_POWER_LINE_FREQUENCY_AUTO (3). V4L2_CID_HUE_AUTO diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c index 06b6014..20abe5d 100644 --- a/drivers/media/video/v4l2-ctrls.c +++ b/drivers/media/video/v4l2-ctrls.c @@ -210,6 +210,7 @@ const char * const *v4l2_ctrl_get_menu(u32 id) "Disabled", "50 Hz", "60 Hz", + "Auto", NULL }; static const char * const camera_exposure_auto[] = { diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h index a5359c6..b433968 100644 --- a/include/linux/videodev2.h +++ b/include/linux/videodev2.h @@ -1125,6 +1125,7 @@ enum v4l2_power_line_frequency { V4L2_CID_POWER_LINE_FREQUENCY_DISABLED = 0, V4L2_CID_POWER_LINE_FREQUENCY_50HZ = 1, V4L2_CID_POWER_LINE_FREQUENCY_60HZ = 2, + V4L2_CID_POWER_LINE_FREQUENCY_AUTO = 3, }; #define V4L2_CID_HUE_AUTO (V4L2_CID_BASE+25) #define V4L2_CID_WHITE_BALANCE_TEMPERATURE (V4L2_CID_BASE+26) -- 1.7.6.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 V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Em 21-09-2011 14:31, Guennadi Liakhovetski escreveu: > Hi Mauro > > On Wed, 21 Sep 2011, Mauro Carvalho Chehab wrote: > >> Em 08-06-2011 07:29, Kassey Lee escreveu: >>> This driver exports a video device node per each CCIC >>> (CMOS Camera Interface Controller) >>> device contained in Marvell Mobile PXA910 SoC >>> The driver is based on soc-camera + videobuf2 frame >>> work, and only USERPTR is supported. >> >> Hi Guennadi, >> >> Would you mind reviewing this patch[1]? > > Indeed I would (mind);-) AFAIU, Jon has converted the cafe-ccic driver to > be usable for other implementations, using the same core, this driver has > to be converted to re-use the common code, and so far this has not been > done, or am I missing something? Ah, yes. Ok, I've marked it as superseded at patchwork. As you know, I've migrated all patches to Linuxtv patchwork, and taking the opportunity to double-check if something got missed by all those troubles at kernel.org. It is hard to recover the history of some patches, like this one ;) Thanks! Mauro > > Thanks > Guennadi > >> >> [1] http://patchwork.linuxtv.org/patch/7210/ >> >> Thanks, >> Mauro. >> >>> >>> Signed-off-by: Kassey Lee >>> --- >>> arch/arm/mach-mmp/include/mach/camera.h | 37 ++ >>> drivers/media/video/Kconfig |7 + >>> drivers/media/video/Makefile|1 + >>> drivers/media/video/mv_camera.c | 1071 >>> +++ >>> 4 files changed, 1116 insertions(+), 0 deletions(-) >>> create mode 100644 arch/arm/mach-mmp/include/mach/camera.h >>> create mode 100644 drivers/media/video/mv_camera.c >>> >>> diff --git a/arch/arm/mach-mmp/include/mach/camera.h >>> b/arch/arm/mach-mmp/include/mach/camera.h >>> new file mode 100644 >>> index 000..ff8cde1 >>> --- /dev/null >>> +++ b/arch/arm/mach-mmp/include/mach/camera.h >>> @@ -0,0 +1,37 @@ >>> +/* >>> + * Copyright (C) 2011, Marvell International Ltd. >>> + * Kassey Lee >>> + * Angela Wan >>> + * Lei Wen >>> + * >>> + * 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; either version 2 of the License, or >>> + * (at your option) any later version. >>> + * >>> + */ >>> + >>> +#ifndef __ASM_ARCH_CAMERA_H__ >>> +#define __ASM_ARCH_CAMERA_H__ >>> + >>> +#define MV_CAMERA_MASTER 1 >>> +#define MV_CAMERA_DATAWIDTH_8 8 >>> +#define MV_CAMERA_DATAWIDTH_10 0x20 >>> +#define MV_CAMERA_PCLK_EN 0x40 >>> +#define MV_CAMERA_MCLK_EN 0x80 >>> +#define MV_CAMERA_PCP 0x100 >>> +#define MV_CAMERA_HSP 0x200 >>> +#define MV_CAMERA_VSP 0x400 >>> + >>> +struct mv_cam_pdata { >>> + int dphy[3]; >>> + unsigned long flags; >>> + int dma_burst; >>> + int mclk_min; >>> + int mclk_src; >>> + int (*init_clk) (struct device *dev, int init); >>> + void (*enable_clk) (struct device *dev, int on); >>> + int (*get_mclk_src) (int src); >>> +}; >>> + >>> +#endif >>> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig >>> index 3be180b..18ab3a5 100644 >>> --- a/drivers/media/video/Kconfig >>> +++ b/drivers/media/video/Kconfig >>> @@ -891,6 +891,13 @@ config VIDEO_MX3 >>> ---help--- >>> This is a v4l2 driver for the i.MX3x Camera Sensor Interface >>> >>> +config VIDEO_MV_CCIC >>> + tristate "Marvell CMOS Camera Interface Controller driver" >>> + depends on VIDEO_DEV && CPU_PXA910 && SOC_CAMERA >>> + select VIDEOBUF2_DMA_CONTIG >>> + ---help--- >>> + This is a v4l2 driver for the Marvell CCIC Interface >>> + >>> config VIDEO_PXA27x >>> tristate "PXA27x Quick Capture Interface driver" >>> depends on VIDEO_DEV && PXA27x && SOC_CAMERA >>> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile >>> index 9519160..e3251c3 100644 >>> --- a/drivers/media/video/Makefile >>> +++ b/drivers/media/video/Makefile >>> @@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += >>> soc_camera_platform.o >>> obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o >>> obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o >>> obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o >>> +obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o >>> obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o >>> obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o >>> obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o >>> diff --git a/drivers/media/video/mv_camera.c >>> b/drivers/media/video/mv_camera.c >>> new file mode 100644 >>> index 000..ed2397f >>> --- /dev/null >>> +++ b/drivers/media/video/mv_camera.c >>> @@ -0,0 +1,1071 @@ >>> +/* >>> + * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC >>> + * (CMOS Capture Interface Controller) >>> + * >>> + * This driver is based on soc_camera and videobuf2 >>> + * framework, but part of the low level register function >>> + * is base on cafe_ccic.c >>> + * >>> + * Copyright (C)
Re: [PATCH V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
On Wed, 21 Sep 2011 19:31:21 +0200 (CEST) Guennadi Liakhovetski wrote: > Indeed I would (mind);-) AFAIU, Jon has converted the cafe-ccic driver to > be usable for other implementations, using the same core, this driver has > to be converted to re-use the common code, and so far this has not been > done, or am I missing something? That is, indeed, how I think it should be done. I'm fully aware that I've not quite finished my part of that - in particular, I've not fixed the ov7670-only problem. That would move up on my tragically long priority list if I knew that there would be a need for it in the near future. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
Em 04-05-2011 08:27, Lutz Sammer escreveu: > On 05/04/11 01:16, Mauro Carvalho Chehab wrote: >> Em 13-04-2011 21:05, Lutz Sammer escreveu: On 05/04/11 21:07, Steffen Barszus wrote: > On Tue, 05 Apr 2011 13:00:14 +0200 > "Issa Gorissen" wrote: > >> Hi, >> >> Eutelsat made a recent migration from DVB-S to DVB-S2 (since >> 31/3/2011) on two transponders on HB13E >> >> - HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500 >> Msymb/s 0.2 Pilot off Polar H >> >> - HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500 >> Msymb/s 0.2 Pilot off Polar H >> >> >> Before those changes, with my TT S2 3200, I was able to watch TV on >> those transponders. Now, I cannot even tune on those transponders. I >> have tried with scan-s2 and w_scan and the latest drivers from git. >> They both find the transponders but cannot tune onto it. >> >> Something noteworthy is that my other card, a DuoFlex S2 can tune >> fine on those transponders. >> >> My question is; can someone try this as well with a TT S2 3200 and >> post the results ? > i read something about it lately here (german!): > http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938 > > It says in stb0899_drv.c function: > static void stb0899_set_iterations(struct stb0899_state *state) > > This: > reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER); > STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); > stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER, > STB0899_OFF0_MAX_ITER, reg); > > should be replaced with this: > > reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER); > STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale); > stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER, > STB0899_OFF0_MAX_ITER, reg); > > Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines > affected. > > Kind Regards > > Steffen Hi Steffen, Unfortunately, it does not help in my case. Thx anyway. >>> >>> Try my locking fix. With above patch I can lock the >>> channels without problem. >> >> Can someone confirm that such patch would fix the issue? If so, please >> forward it in a way that it could be applied (patch is currently >> line-wrapped), >> and submit with some comments/description and your SOB. >> >> As the patch is currently broken, I'm just marking it as rejected at >> patchwork. >> >> Manu, >> >> Please take a look on this trouble report. >> > > Sorry, the things are mixed here. My patch (resend and hopefully this > time not broken) handles only DVB-S transponders. > > The FEC fix patch fixed locking on 11,681 Ghz, but not on 12,692 Ghz for > me. But I have very weak receiption, > > Johns Manu, We're still missing your review on this patch[1], or it were eventually missed. Please review it. Thanks, Mauro [1] http://patchwork.linuxtv.org/patch/6511/ -- To unsubscribe from this list: send the line "unsubscribe 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 10/10] rc-core: move timeout and checks to lirc
Em 28-04-2011 12:14, David Härdeman escreveu: > The lirc TX functionality expects the process which writes (TX) data to > the lirc dev to sleep until the actual data has been transmitted by the > hardware. > > Since the same timeout calculation is duplicated in more than one driver > (and would have to be duplicated in even more drivers as they gain TX > support), it makes sense to move this timeout calculation to the lirc > layer instead. > > At the same time, centralize some of the sanity checks. This patch[1] were never applied, nor I'm seeing any comments about it at the ML. Jarod, would you care to review it? Thanks, Mauro [1] http://patchwork.linuxtv.org/patch/6468/ > > Signed-off-by: David Härdeman > --- > drivers/media/rc/ir-lirc-codec.c | 33 + > drivers/media/rc/mceusb.c| 18 -- > drivers/media/rc/rc-loopback.c | 12 > 3 files changed, 29 insertions(+), 34 deletions(-) > > diff --git a/drivers/media/rc/ir-lirc-codec.c > b/drivers/media/rc/ir-lirc-codec.c > index ac54139..a58c7fe 100644 > --- a/drivers/media/rc/ir-lirc-codec.c > +++ b/drivers/media/rc/ir-lirc-codec.c > @@ -106,6 +106,12 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, > const char *buf, > unsigned int *txbuf; /* buffer with values to transmit */ > ssize_t ret = 0; > size_t count; > + ktime_t start; > + s64 towait; > + unsigned int duration = 0; /* signal duration in us */ > + int i; > + > + start = ktime_get(); > > lirc = lirc_get_pdata(file); > if (!lirc) > @@ -128,11 +134,30 @@ static ssize_t ir_lirc_transmit_ir(struct file *file, > const char *buf, > goto out; > } > > - if (dev->tx_ir) > - ret = dev->tx_ir(dev, txbuf, count); > + if (!dev->tx_ir) { > + ret = -ENOSYS; > + goto out; > + } > + > + ret = dev->tx_ir(dev, txbuf, (u32)n); > + if (ret < 0) > + goto out; > + > + for (i = 0; i < ret; i++) > + duration += txbuf[i]; > > - if (ret > 0) > - ret *= sizeof(unsigned); > + ret *= sizeof(unsigned int); > + > + /* > + * The lircd gap calculation expects the write function to > + * wait for the actual IR signal to be transmitted before > + * returning. > + */ > + towait = ktime_us_delta(ktime_add_us(start, duration), ktime_get()); > + if (towait > 0) { > + set_current_state(TASK_INTERRUPTIBLE); > + schedule_timeout(usecs_to_jiffies(towait)); > + } > > out: > kfree(txbuf); > diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c > index c1cd00d..7b08797 100644 > --- a/drivers/media/rc/mceusb.c > +++ b/drivers/media/rc/mceusb.c > @@ -671,10 +671,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned > *txbuf, unsigned count) > int i, ret = 0; > int cmdcount = 0; > unsigned char *cmdbuf; /* MCE command buffer */ > - long signal_duration = 0; /* Singnal length in us */ > - struct timeval start_time, end_time; > - > - do_gettimeofday(&start_time); > > cmdbuf = kzalloc(sizeof(unsigned) * MCE_CMDBUF_SIZE, GFP_KERNEL); > if (!cmdbuf) > @@ -687,7 +683,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned > *txbuf, unsigned count) > > /* Generate mce packet data */ > for (i = 0; (i < count) && (cmdcount < MCE_CMDBUF_SIZE); i++) { > - signal_duration += txbuf[i]; > txbuf[i] = txbuf[i] / MCE_TIME_UNIT; > > do { /* loop to support long pulses/spaces > 127*50us=6.35ms */ > @@ -730,19 +725,6 @@ static int mceusb_tx_ir(struct rc_dev *dev, unsigned > *txbuf, unsigned count) > /* Transmit the command to the mce device */ > mce_async_out(ir, cmdbuf, cmdcount); > > - /* > - * The lircd gap calculation expects the write function to > - * wait the time it takes for the ircommand to be sent before > - * it returns. > - */ > - do_gettimeofday(&end_time); > - signal_duration -= (end_time.tv_usec - start_time.tv_usec) + > -(end_time.tv_sec - start_time.tv_sec) * 100; > - > - /* delay with the closest number of ticks */ > - set_current_state(TASK_INTERRUPTIBLE); > - schedule_timeout(usecs_to_jiffies(signal_duration)); > - > out: > kfree(cmdbuf); > return ret ? ret : count; > diff --git a/drivers/media/rc/rc-loopback.c b/drivers/media/rc/rc-loopback.c > index fb8ca81..5cb7057 100644 > --- a/drivers/media/rc/rc-loopback.c > +++ b/drivers/media/rc/rc-loopback.c > @@ -105,18 +105,9 @@ static int loop_tx_ir(struct rc_dev *dev, unsigned > *txbuf, unsigned count) > { > struct loopback_dev *lodev = dev->priv; > u32 rxmask; > - unsigned total_duration = 0; > unsigned i; > DEFINE_IR_RAW_EVENT(rawir); > > - for (i = 0; i < count; i++) > - total_duration += abs(
Re: [PATCH V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Hi Mauro On Wed, 21 Sep 2011, Mauro Carvalho Chehab wrote: > Em 08-06-2011 07:29, Kassey Lee escreveu: > > This driver exports a video device node per each CCIC > > (CMOS Camera Interface Controller) > > device contained in Marvell Mobile PXA910 SoC > > The driver is based on soc-camera + videobuf2 frame > > work, and only USERPTR is supported. > > Hi Guennadi, > > Would you mind reviewing this patch[1]? Indeed I would (mind);-) AFAIU, Jon has converted the cafe-ccic driver to be usable for other implementations, using the same core, this driver has to be converted to re-use the common code, and so far this has not been done, or am I missing something? Thanks Guennadi > > [1] http://patchwork.linuxtv.org/patch/7210/ > > Thanks, > Mauro. > > > > > Signed-off-by: Kassey Lee > > --- > > arch/arm/mach-mmp/include/mach/camera.h | 37 ++ > > drivers/media/video/Kconfig |7 + > > drivers/media/video/Makefile|1 + > > drivers/media/video/mv_camera.c | 1071 > > +++ > > 4 files changed, 1116 insertions(+), 0 deletions(-) > > create mode 100644 arch/arm/mach-mmp/include/mach/camera.h > > create mode 100644 drivers/media/video/mv_camera.c > > > > diff --git a/arch/arm/mach-mmp/include/mach/camera.h > > b/arch/arm/mach-mmp/include/mach/camera.h > > new file mode 100644 > > index 000..ff8cde1 > > --- /dev/null > > +++ b/arch/arm/mach-mmp/include/mach/camera.h > > @@ -0,0 +1,37 @@ > > +/* > > + * Copyright (C) 2011, Marvell International Ltd. > > + * Kassey Lee > > + * Angela Wan > > + * Lei Wen > > + * > > + * 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; either version 2 of the License, or > > + * (at your option) any later version. > > + * > > + */ > > + > > +#ifndef __ASM_ARCH_CAMERA_H__ > > +#define __ASM_ARCH_CAMERA_H__ > > + > > +#define MV_CAMERA_MASTER 1 > > +#define MV_CAMERA_DATAWIDTH_8 8 > > +#define MV_CAMERA_DATAWIDTH_10 0x20 > > +#define MV_CAMERA_PCLK_EN 0x40 > > +#define MV_CAMERA_MCLK_EN 0x80 > > +#define MV_CAMERA_PCP 0x100 > > +#define MV_CAMERA_HSP 0x200 > > +#define MV_CAMERA_VSP 0x400 > > + > > +struct mv_cam_pdata { > > + int dphy[3]; > > + unsigned long flags; > > + int dma_burst; > > + int mclk_min; > > + int mclk_src; > > + int (*init_clk) (struct device *dev, int init); > > + void (*enable_clk) (struct device *dev, int on); > > + int (*get_mclk_src) (int src); > > +}; > > + > > +#endif > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > > index 3be180b..18ab3a5 100644 > > --- a/drivers/media/video/Kconfig > > +++ b/drivers/media/video/Kconfig > > @@ -891,6 +891,13 @@ config VIDEO_MX3 > > ---help--- > > This is a v4l2 driver for the i.MX3x Camera Sensor Interface > > > > +config VIDEO_MV_CCIC > > + tristate "Marvell CMOS Camera Interface Controller driver" > > + depends on VIDEO_DEV && CPU_PXA910 && SOC_CAMERA > > + select VIDEOBUF2_DMA_CONTIG > > + ---help--- > > + This is a v4l2 driver for the Marvell CCIC Interface > > + > > config VIDEO_PXA27x > > tristate "PXA27x Quick Capture Interface driver" > > depends on VIDEO_DEV && PXA27x && SOC_CAMERA > > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > > index 9519160..e3251c3 100644 > > --- a/drivers/media/video/Makefile > > +++ b/drivers/media/video/Makefile > > @@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += > > soc_camera_platform.o > > obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o > > obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o > > obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o > > +obj-$(CONFIG_VIDEO_MV_CCIC)+= mv_camera.o > > obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o > > obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o > > obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o > > diff --git a/drivers/media/video/mv_camera.c > > b/drivers/media/video/mv_camera.c > > new file mode 100644 > > index 000..ed2397f > > --- /dev/null > > +++ b/drivers/media/video/mv_camera.c > > @@ -0,0 +1,1071 @@ > > +/* > > + * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC > > + * (CMOS Capture Interface Controller) > > + * > > + * This driver is based on soc_camera and videobuf2 > > + * framework, but part of the low level register function > > + * is base on cafe_ccic.c > > + * > > + * Copyright (C) 2011, Marvell International Ltd. > > + * Kassey Lee > > + * Angela Wan > > + * Lei Wen > > + * > > + * Copyright 2006 One Laptop Per Child Association, Inc. > > + * Copyright 2006-7 Jonathan Corbet > > + * > > + * 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
uk-EmleyMoor update
The Emley Moor transmitter in the UK completed digital switchover today, making the existing transmitter file: http://linuxtv.org/hg/dvb-apps/file/tip/util/scan/dvb-t/uk-EmleyMoor obsolete. Attached is a patch which I've just successfully used with dvbscan to obtain a new channels.conf. Thanks, -- Andii :-) --- /usr/share/dvb/dvb-t/uk-EmleyMoor 2010-08-02 19:17:04.302416402 +0100 +++ /home/andrew/.tzap/uk-EmleyMoor 2011-09-21 18:11:02.936106090 +0100 @@ -1,10 +1,7 @@ # UK, Emley Moor -# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html -# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy -T 722167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 625833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 649833000 8MHz 2/3 NONE QAM64 2k 1/32 NONE -T 673833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 705833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE -T 697833000 8MHz 3/4 NONE QAM16 2k 1/32 NONE +T 68200 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # PSB1/BBCA +T 65800 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # PSB2/D3&4 +T 71400 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM4/SDN +T 72200 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM5/ARQA +T 69000 8MHz 2/3 1/2 QAM64 8k 1/32 NONE # COM6/ARQB
Re: [PATCH V3] V4L/DVB: v4l: Add driver for Marvell PXA910 CCIC
Em 08-06-2011 07:29, Kassey Lee escreveu: > This driver exports a video device node per each CCIC > (CMOS Camera Interface Controller) > device contained in Marvell Mobile PXA910 SoC > The driver is based on soc-camera + videobuf2 frame > work, and only USERPTR is supported. Hi Guennadi, Would you mind reviewing this patch[1]? [1] http://patchwork.linuxtv.org/patch/7210/ Thanks, Mauro. > > Signed-off-by: Kassey Lee > --- > arch/arm/mach-mmp/include/mach/camera.h | 37 ++ > drivers/media/video/Kconfig |7 + > drivers/media/video/Makefile|1 + > drivers/media/video/mv_camera.c | 1071 > +++ > 4 files changed, 1116 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-mmp/include/mach/camera.h > create mode 100644 drivers/media/video/mv_camera.c > > diff --git a/arch/arm/mach-mmp/include/mach/camera.h > b/arch/arm/mach-mmp/include/mach/camera.h > new file mode 100644 > index 000..ff8cde1 > --- /dev/null > +++ b/arch/arm/mach-mmp/include/mach/camera.h > @@ -0,0 +1,37 @@ > +/* > + * Copyright (C) 2011, Marvell International Ltd. > + * Kassey Lee > + * Angela Wan > + * Lei Wen > + * > + * 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; either version 2 of the License, or > + * (at your option) any later version. > + * > + */ > + > +#ifndef __ASM_ARCH_CAMERA_H__ > +#define __ASM_ARCH_CAMERA_H__ > + > +#define MV_CAMERA_MASTER 1 > +#define MV_CAMERA_DATAWIDTH_8 8 > +#define MV_CAMERA_DATAWIDTH_10 0x20 > +#define MV_CAMERA_PCLK_EN 0x40 > +#define MV_CAMERA_MCLK_EN 0x80 > +#define MV_CAMERA_PCP 0x100 > +#define MV_CAMERA_HSP 0x200 > +#define MV_CAMERA_VSP 0x400 > + > +struct mv_cam_pdata { > + int dphy[3]; > + unsigned long flags; > + int dma_burst; > + int mclk_min; > + int mclk_src; > + int (*init_clk) (struct device *dev, int init); > + void (*enable_clk) (struct device *dev, int on); > + int (*get_mclk_src) (int src); > +}; > + > +#endif > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > index 3be180b..18ab3a5 100644 > --- a/drivers/media/video/Kconfig > +++ b/drivers/media/video/Kconfig > @@ -891,6 +891,13 @@ config VIDEO_MX3 > ---help--- > This is a v4l2 driver for the i.MX3x Camera Sensor Interface > > +config VIDEO_MV_CCIC > + tristate "Marvell CMOS Camera Interface Controller driver" > + depends on VIDEO_DEV && CPU_PXA910 && SOC_CAMERA > + select VIDEOBUF2_DMA_CONTIG > + ---help--- > + This is a v4l2 driver for the Marvell CCIC Interface > + > config VIDEO_PXA27x > tristate "PXA27x Quick Capture Interface driver" > depends on VIDEO_DEV && PXA27x && SOC_CAMERA > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 9519160..e3251c3 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -161,6 +161,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o > obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o > obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o > obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o > +obj-$(CONFIG_VIDEO_MV_CCIC) += mv_camera.o > obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o > obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o > obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)+= sh_mobile_ceu_camera.o > diff --git a/drivers/media/video/mv_camera.c b/drivers/media/video/mv_camera.c > new file mode 100644 > index 000..ed2397f > --- /dev/null > +++ b/drivers/media/video/mv_camera.c > @@ -0,0 +1,1071 @@ > +/* > + * V4L2 Driver for Marvell Mobile SoC PXA910 CCIC > + * (CMOS Capture Interface Controller) > + * > + * This driver is based on soc_camera and videobuf2 > + * framework, but part of the low level register function > + * is base on cafe_ccic.c > + * > + * Copyright (C) 2011, Marvell International Ltd. > + * Kassey Lee > + * Angela Wan > + * Lei Wen > + * > + * Copyright 2006 One Laptop Per Child Association, Inc. > + * Copyright 2006-7 Jonathan Corbet > + * > + * 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; either version 2 of the License, or > + * (at your option) any later version. > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include "cafe_ccic-regs.h" > + > +/* Register definition for PXA910 */ > + > +#define REG_U0BAR 0x0c > +#define REG_U1BAR 0x10 > +#define
Re: [PATCH v1 2/3] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
On Wed, Sep 21, 2011 at 02:47:29PM +0200, Laurent Pinchart wrote: > Hi Sylwester, Hi Laurent and Sylwester, > On Wednesday 21 September 2011 14:28:25 Sylwester Nawrocki wrote: > > On 09/21/2011 12:17 AM, Sakari Ailus wrote: > > > On Tue, Sep 20, 2011 at 11:25:31PM +0200, Sylwester Nawrocki wrote: > > >> On 09/20/2011 10:57 PM, Sakari Ailus wrote: > > >>> On Tue, Sep 20, 2011 at 01:58:58PM +0200, Sylwester Nawrocki wrote: > > V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct > > a driver what is the power line frequency so an appropriate filter > > can be used by the device to cancel flicker by compensating the light > > intensity ripple and thus. Currently in the menu we have entries for > > 50 and 60 Hz and for entirely disabling the anti-flicker filter. > > However some devices are capable of automatically detecting the > > frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them. > > > > Signed-off-by: Sylwester Nawrocki > > Signed-off-by: Kyungmin Park > > Acked-by: Laurent Pinchart > > --- > > > > Documentation/DocBook/media/v4l/controls.xml |5 +++-- > > drivers/media/video/v4l2-ctrls.c |1 + > > include/linux/videodev2.h|1 + > > 3 files changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > > b/Documentation/DocBook/media/v4l/controls.xml index 2420e4a..c6b3c46 > > 100644 > > --- a/Documentation/DocBook/media/v4l/controls.xml > > +++ b/Documentation/DocBook/media/v4l/controls.xml > > @@ -232,8 +232,9 @@ control is deprecated. New drivers and > > applications should use the > > > > Enables a power line frequency filter to avoid > > > > flicker. Possible values forenum > > v4l2_power_line_frequency are: > > V4L2_CID_POWER_LINE_FREQUENCY_DISABLED (0), > > > > -V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1) and > > -V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2). > > +V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1), > > +V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2) and > > +V4L2_CID_POWER_LINE_FREQUENCY_AUTO (3). > > >>> > > >>> A stupid question: wouldn't this be a case for a new control for > > >>> automatic power line frequency, in other words enabling or disabling > > >>> it? > > >> > > >> IMO this would complicate things in kernel and user land, without any > > >> reasonable positive effects. AUTO seems to fit well here, it's just > > >> another mode of operation of a power line noise filter. Why make things > > >> more complicated than they need to be ? > > > > > > The advantage would be to be able to get the power line frquency if > > > that's supported by the hardware. This implementation excludes that. > > > Such information might be interesting to add e.g. to the image's exif > > > data. > > > > AFAIU, the power line frequency filter just modifies frame exposure time to > > be multiple of half of the mains frequency period. So it's the exposure > > time that gets finally affected. Maybe there is some hardware that > > supports retrieving of the detected frequency, however I'm not aware of > > it. And it doesn't seem useful unless you want to use camera as some > > non-standard measurement tool. It also takes some time until the detection > > algorithm locks, during this time an undefined frequency value would be > > read. > > > > I believe the filter settings do not really apply to still capture as it > > involves periodic operation, like preview. Even if we had this as meta > > data tag, there are more direct raw image parameters than the PL noise > > filter frequency. > > > > I feel uncomfortable with having 2 controls, where one can disable the > > filter and the other enable it with AUTO setting. > > Let's say the sensor supports 4 distinct settings of the filter: OFF, 50HZ, > > 60HZ, AUTO. (there is already one sensor driver in mainline that support > > it - ov519). How do we map this onto 2 controls ? > > > > What do we return from the menu control that covers { OFF, 50HZ, 60HZ } > > when AUTO mode is enabled through the other control and H/W doesn't allow > > to read the detected frequency ? > > > > I think, for the 2 controls we would need the DISABLED entry not to belong > > to V4L2_CID_POWER_LINE_FREQUENCY at first place. > > > > > Not sure if that's important, though. > > > > I would say no, but someone can prove me wrong. And who knows what kind of > > strange H/W future brings. > > I think it all boils down to whether V4L2_CID_POWER_LINE_FREQUENCY is the > power line frequency filter control or the power line frequency control. In > the first case it doesn't make sense to use two separate controls. In the > second case it could. > > I don't think we need two controls for this, but that's just a personal > opinion of the "I don't think we need to bother
[PATCH 2/2] V4L: sh_mobile_ceu_camera: simplify scaling and cropping algorithms
With the pad-level API scaling and cropping will be configured on each entity separately. To prepare for the conversion remove all attempts to optimise scaling and cropping on the host and clients, as has previously been done by the sh_mobile_ceu_camera driver. Signed-off-by: Guennadi Liakhovetski --- This removes ugliest optimisation attempts and makes the driver 170 lines shorter. drivers/media/video/sh_mobile_ceu_camera.c | 876 +++- 1 files changed, 352 insertions(+), 524 deletions(-) diff --git a/drivers/media/video/sh_mobile_ceu_camera.c b/drivers/media/video/sh_mobile_ceu_camera.c index 955947a..d54c72b 100644 --- a/drivers/media/video/sh_mobile_ceu_camera.c +++ b/drivers/media/video/sh_mobile_ceu_camera.c @@ -112,7 +112,6 @@ struct sh_mobile_ceu_dev { u32 cflcr; - enum v4l2_field field; int sequence; unsigned int image_mode:1; @@ -121,20 +120,16 @@ struct sh_mobile_ceu_dev { }; struct sh_mobile_ceu_cam { - /* CEU offsets within the camera output, before the CEU scaler */ - unsigned int ceu_left; - unsigned int ceu_top; + /* Client cropping rectangle */ + struct v4l2_rect rect; /* Client output, as seen by the CEU */ unsigned int width; unsigned int height; /* -* User window from S_CROP / G_CROP, produced by client cropping and -* scaling, CEU scaling and CEU cropping, mapped back onto the client -* input window +* CEU offsets and sizes within the camera output, before the CEU +* scaling filter */ - struct v4l2_rect subrect; - /* Camera cropping rectangle */ - struct v4l2_rect rect; + struct v4l2_rect ceu_rect; const struct soc_mbus_pixelfmt *extra_fmt; enum v4l2_mbus_pixelcode code; }; @@ -303,7 +298,7 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev *pcdev) if (!pcdev->active) return ret; - if (V4L2_FIELD_INTERLACED_BT == pcdev->field) { + if (V4L2_FIELD_INTERLACED_BT == icd->field) { top1= CDBYR; top2= CDBCR; bottom1 = CDAYR; @@ -329,7 +324,7 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev *pcdev) } ceu_write(pcdev, top1, phys_addr_top); - if (V4L2_FIELD_NONE != pcdev->field) { + if (V4L2_FIELD_NONE != icd->field) { if (planar) phys_addr_bottom = phys_addr_top + icd->user_width; else @@ -343,7 +338,7 @@ static int sh_mobile_ceu_capture(struct sh_mobile_ceu_dev *pcdev) phys_addr_top += icd->user_width * icd->user_height; ceu_write(pcdev, top2, phys_addr_top); - if (V4L2_FIELD_NONE != pcdev->field) { + if (V4L2_FIELD_NONE != icd->field) { phys_addr_bottom = phys_addr_top + icd->user_width; ceu_write(pcdev, bottom2, phys_addr_bottom); } @@ -517,7 +512,7 @@ static irqreturn_t sh_mobile_ceu_irq(int irq, void *data) ret = sh_mobile_ceu_capture(pcdev); do_gettimeofday(&vb->v4l2_buf.timestamp); if (!ret) { - vb->v4l2_buf.field = pcdev->field; + vb->v4l2_buf.field = pcdev->icd->field; vb->v4l2_buf.sequence = pcdev->sequence++; } vb2_buffer_done(vb, ret < 0 ? VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE); @@ -659,17 +654,18 @@ static void sh_mobile_ceu_set_rect(struct soc_camera_device *icd) u32 camor; dev_geo(icd->parent, "Crop %ux%u@%u:%u\n", - icd->user_width, icd->user_height, cam->ceu_left, cam->ceu_top); + icd->user_width, icd->user_height, cam->ceu_rect.left, cam->ceu_rect.top); - left_offset = cam->ceu_left; - top_offset = cam->ceu_top; + left_offset = cam->ceu_rect.left; + top_offset = cam->ceu_rect.top; WARN_ON(icd->user_width & 3 || icd->user_height & 3); width = icd->user_width; + in_width = min(2560U, cam->width); + if (pcdev->image_mode) { - in_width = cam->width; if (!pcdev->is_16bit) { in_width *= 2; left_offset *= 2; @@ -688,7 +684,7 @@ static void sh_mobile_ceu_set_rect(struct soc_camera_device *icd) w_factor = 1; } - in_width = cam->width * w_factor; + in_width *= w_factor; left_offset *= w_factor; if (bytes_per_line < 0) @@ -698,8 +694,8 @@ static void sh_mobile_ceu_set_rect(struct soc_camera_device *icd) } height = icd->user_height; - in_height = cam->height; - if (V4L2_FIELD_NONE != pcdev->field) { + in_height = min(1920U, cam->height); + if (V4L2_FIELD_NONE != icd->field) {
[PATCH 1/2] V4L: soc-camera: add a function to lookup xlate by mediabus code
In addition to a helper function, performing a format translation table lookup by a fourcc value, a similar function is now needed to lookup translation table entries by mediabus codes. Signed-off-by: Guennadi Liakhovetski --- drivers/media/video/soc_camera.c | 14 +- include/media/soc_camera.h |5 - 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c index d1ced8f..b62f2fe 100644 --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -112,7 +112,7 @@ static int soc_camera_power_off(struct soc_camera_device *icd, } const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc( - struct soc_camera_device *icd, unsigned int fourcc) + const struct soc_camera_device *icd, unsigned int fourcc) { unsigned int i; @@ -123,6 +123,18 @@ const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc( } EXPORT_SYMBOL(soc_camera_xlate_by_fourcc); +const struct soc_camera_format_xlate *soc_camera_xlate_by_mcode( + const struct soc_camera_device *icd, enum v4l2_mbus_pixelcode code) +{ + unsigned int i; + + for (i = 0; i < icd->num_user_formats; i++) + if (icd->user_formats[i].code == code) + return icd->user_formats + i; + return NULL; +} +EXPORT_SYMBOL(soc_camera_xlate_by_mcode); + /** * soc_camera_apply_board_flags() - apply platform SOCAM_SENSOR_INVERT_* flags * @icl: camera platform parameters diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h index b1377b9..fe7e8ad 100644 --- a/include/media/soc_camera.h +++ b/include/media/soc_camera.h @@ -174,7 +174,10 @@ int soc_camera_host_register(struct soc_camera_host *ici); void soc_camera_host_unregister(struct soc_camera_host *ici); const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc( - struct soc_camera_device *icd, unsigned int fourcc); + const struct soc_camera_device *icd, unsigned int fourcc); + +const struct soc_camera_format_xlate *soc_camera_xlate_by_mcode( + const struct soc_camera_device *icd, enum v4l2_mbus_pixelcode code); /** * struct soc_camera_format_xlate - match between host and sensor formats -- 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
[PATCH 0/2] soc-camera: prepare sh_mobile_ceu_camera for MC
Hi all Of the following 2 patches the first one just adds a helper function to soc-camera core, and the second one removes the worst cases of "coffee-ground reading" from the driver. By this I mean optimisation attempts, trying to combine client (e.g., camera sensor driver) and host (CEU, bridge) cropping and scaling to achieve best results. Where "best results" meant as close to user-requesed configuration as possible with minimum bandwidth waste. Even though the results were pretty good, the implementation made the driver very complex, hard to maintain and loaded with calculations less trivial, than what we like to have in the kernel. With the move to the Media Controller these optimisations can and shall be carried out in the user-space with each driver being configured separately for its specific cropping and scaling tasks. Even though we want to preserve the ability to work with standard V4L2 applications even without the need for an initial set up, we can now remove all those optimisations and only keep a couple of simple cases for backwards compatibility. These "simple" cases include situations, where the CEU driver forwards an S_CROP or an S_FMT to the subdevice driver(s), then checks the result and if there is a _simple_ way to improve it, then it does that. Most importantly all cases of cropping (on CEU / bridge) on top of scaling (subdevice), which lead to the need to calculate subdevice scaling factors and use them to calculate host cropping and its projection on the sensor plane... I don't think we manage to get these patches in 3.2, especially, since they mostly make sense in conmbination with the soc-camera Media Controller patches, which also are not quite finished yet. So, these patches are an early preview. They should be applied on top of what will become the soc-camera 3.2 pull, an almost final version of which is available at git://linuxtv.org/gliakhovetski/v4l-dvb.git rc1-for-3.2 Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] fixup! mm: alloc_contig_freed_pages() added
On Wed, 2011-09-21 at 18:26 +0200, Michal Nazarewicz wrote: > - page += 1 << order; > + > + if (zone_pfn_same_memmap(pfn - count, pfn)) > + page += count; > + else > + page = pfn_to_page(pfn); > } That all looks sane to me and should fix the bug I brought up. -- Dave -- To unsubscribe from this list: send the line "unsubscribe 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/3] fixup! mm: alloc_contig_freed_pages() added
From: Michal Nazarewicz Signed-off-by: Michal Nazarewicz --- include/asm-generic/memory_model.h | 17 ++ include/linux/page-isolation.h |4 ++- mm/page_alloc.c| 43 +++ 3 files changed, 53 insertions(+), 11 deletions(-) > On Wed, 2011-09-21 at 17:19 +0200, Michal Nazarewicz wrote: >> I wanted to avoid calling pfn_to_page() each time as it seem fairly >> expensive in sparsemem and disctontig modes. At the same time, the >> macro trickery is so that users of sparsemem-vmemmap and flatmem won't >> have to pay the price. On Wed, 21 Sep 2011 17:45:59 +0200, Dave Hansen wrote: > Personally, I'd say the (incredibly minuscule) runtime cost is worth the > cost of making folks' eyes bleed when they see those macros. I think > there are some nicer ways to do it. Yeah. I wasn't amazed by them either. > Is there a reason you can't logically do? > page = pfn_to_page(pfn); > for (;;) { > if (pfn_to_section_nr(pfn) == pfn_to_section_nr(pfn+1)) > page++; > else > page = pfn_to_page(pfn+1); > } Done. Thanks for the suggestions! >> +#define __contig_next_page(page, pageblock_left, pfn, increment)\ >> +(likely((pageblock_left) -= (increment)) ? (page) + (increment) \ >> + : (((pageblock_left) = pageblock_nr_pages), pfn_to_page(pfn))) >> + >> +#define __contig_first_page(pageblock_left, pfn) ( \ >> +((pageblock_left) = pageblock_nr_pages -\ >> + ((pfn) & (pageblock_nr_pages - 1))), \ >> +pfn_to_page(pfn)) >> + >> +#endif > For the love of Pete, please make those in to functions if you're going > to keep them. That was tricky because they modify pageblock_left. Not relevant now anyways though. diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h index fb2d63f..900da88 100644 --- a/include/asm-generic/memory_model.h +++ b/include/asm-generic/memory_model.h @@ -69,6 +69,23 @@ }) #endif /* CONFIG_FLATMEM/DISCONTIGMEM/SPARSEMEM */ +#if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP) + +/* + * Both PFNs must be from the same zone! If this function returns + * true, pfn_to_page(pfn1) + (pfn2 - pfn1) == pfn_to_page(pfn2). + */ +static inline bool zone_pfn_same_memmap(unsigned long pfn1, unsigned long pfn2) +{ + return pfn_to_section_nr(pfn1) == pfn_to_section_nr(pfn2); +} + +#else + +#define zone_pfn_same_memmap(pfn1, pfn2) (true) + +#endif + #define page_to_pfn __page_to_pfn #define pfn_to_page __pfn_to_page diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h index b2a81fd..003c52f 100644 --- a/include/linux/page-isolation.h +++ b/include/linux/page-isolation.h @@ -46,11 +46,13 @@ static inline void unset_migratetype_isolate(struct page *page) { __unset_migratetype_isolate(page, MIGRATE_MOVABLE); } + +/* The below functions must be run on a range from a single zone. */ extern unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end, gfp_t flag); extern int alloc_contig_range(unsigned long start, unsigned long end, gfp_t flags, unsigned migratetype); -extern void free_contig_pages(struct page *page, int nr_pages); +extern void free_contig_pages(unsigned long pfn, unsigned nr_pages); /* * For migration. diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 46e78d4..bc200a9 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5725,31 +5725,46 @@ unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end, int order; VM_BUG_ON(!pfn_valid(start)); - zone = page_zone(pfn_to_page(start)); + page = pfn_to_page(start); + zone = page_zone(page); spin_lock_irq(&zone->lock); - page = pfn_to_page(pfn); for (;;) { - VM_BUG_ON(page_count(page) || !PageBuddy(page)); + VM_BUG_ON(!page_count(page) || !PageBuddy(page) || + page_zone(page) != zone); + list_del(&page->lru); order = page_order(page); + count = 1UL << order; zone->free_area[order].nr_free--; rmv_page_order(page); - __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order)); - pfn += 1 << order; + __mod_zone_page_state(zone, NR_FREE_PAGES, -(long)count); + + pfn += count; if (pfn >= end) break; VM_BUG_ON(!pfn_valid(pfn)); - page += 1 << order; + + if (zone_pfn_same_memmap(pfn - count, pfn)) + page += count; + else + page = pfn_to_page(pfn); } spin_unlock_irq(&zone->lock); /* After this,
Re: [PATCH 1/3] fixup! mm: alloc_contig_freed_pages() added
On Wed, 2011-09-21 at 17:19 +0200, Michal Nazarewicz wrote: > Do the attached changes seem to make sense? The logic looks OK. > I wanted to avoid calling pfn_to_page() each time as it seem fairly > expensive in sparsemem and disctontig modes. At the same time, the > macro trickery is so that users of sparsemem-vmemmap and flatmem won't > have to pay the price. Personally, I'd say the (incredibly minuscule) runtime cost is worth the cost of making folks' eyes bleed when they see those macros. I think there are some nicer ways to do it. Is there a reason you can't logically do? page = pfn_to_page(pfn); for (;;) { if (pfn_to_section_nr(pfn) == pfn_to_section_nr(pfn+1)) page++; else page = pfn_to_page(pfn+1); } pfn_to_section_nr() is a register shift. Our smallest section size on x86 is 128MB and on ppc64 16MB. So, at *WORST* (64k pages on ppc64), you're doing pfn_to_page() one of every 256 loops. My suggestion would be put put a macro up in the sparsemem headers that does something like: #ifdef VMEMMAP #define zone_pfn_same_memmap(pfn1, pfn2) (1) #elif SPARSEMEM_OTHER static inline int zone_pfn_same_memmap(unsigned long pfn1, unsigned long pfn2) { return (pfn_to_section_nr(pfn1) == pfn_to_section_nr(pfn2)); } #else #define zone_pfn_same_memmap(pfn1, pfn2) (1) #endif The zone_ bit is necessary in the naming because DISCONTIGMEM's pfns are at least contiguous within a zone. Only the non-VMEMMAP sparsemem case isn't. Other folks would probably have a use for something like that. Although most of the previous users have gotten to this point, given up, and just done pfn_to_page() on each loop. :) > +#if defined(CONFIG_FLATMEM) || defined(CONFIG_SPARSEMEM_VMEMMAP) > + > +/* > + * In FLATMEM and CONFIG_SPARSEMEM_VMEMMAP we can safely increment the page > + * pointer and get the same value as if we were to get by calling > + * pfn_to_page() on incremented pfn counter. > + */ > +#define __contig_next_page(page, pageblock_left, pfn, increment) \ > + ((page) + (increment)) > + > +#define __contig_first_page(pageblock_left, pfn) pfn_to_page(pfn) > + > +#else > + > +/* > + * If we cross pageblock boundary, make sure we get a valid page pointer. If > + * we are within pageblock, incrementing the pointer is good enough, and is > + * a bit of an optimisation. > + */ > +#define __contig_next_page(page, pageblock_left, pfn, increment) \ > + (likely((pageblock_left) -= (increment)) ? (page) + (increment) \ > + : (((pageblock_left) = pageblock_nr_pages), pfn_to_page(pfn))) > + > +#define __contig_first_page(pageblock_left, pfn) ( \ > + ((pageblock_left) = pageblock_nr_pages -\ > + ((pfn) & (pageblock_nr_pages - 1))), \ > + pfn_to_page(pfn)) > + > + > +#endif For the love of Pete, please make those in to functions if you're going to keep them. They're really unreadable like that. You might also want to look at mm/internal.h's mem_map_offset() and mem_map_next(). They're not _quite_ what you need, but they're close. -- Dave -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] sr030pc30: Remove empty s_stream op
On 09/21/2011 05:22 PM, Mauro Carvalho Chehab wrote: > Em 19-01-2011 23:44, Sylwester Nawrocki escreveu: >> s_stream does nothing in current form so remove it. >> >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> drivers/media/video/sr030pc30.c |6 -- >> 1 files changed, 0 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/media/video/sr030pc30.c >> b/drivers/media/video/sr030pc30.c >> index c901721..e1eced1 100644 >> --- a/drivers/media/video/sr030pc30.c >> +++ b/drivers/media/video/sr030pc30.c >> @@ -714,11 +714,6 @@ static int sr030pc30_base_config(struct v4l2_subdev *sd) >> return ret; >> } >> >> -static int sr030pc30_s_stream(struct v4l2_subdev *sd, int enable) >> -{ >> -return 0; >> -} >> - >> static int sr030pc30_s_power(struct v4l2_subdev *sd, int on) >> { >> struct i2c_client *client = v4l2_get_subdevdata(sd); >> @@ -761,7 +756,6 @@ static const struct v4l2_subdev_core_ops >> sr030pc30_core_ops = { >> }; >> >> static const struct v4l2_subdev_video_ops sr030pc30_video_ops = { >> -.s_stream = sr030pc30_s_stream, >> .g_mbus_fmt = sr030pc30_g_fmt, >> .s_mbus_fmt = sr030pc30_s_fmt, >> .try_mbus_fmt = sr030pc30_try_fmt, > > Hmm... > this patch[1] were never merged. It seems a cleanup, though. > > Care to review it? Indeed, it is still worth to apply. There was some ongoing work at the control framework and other patches form this series need some more modifications. But this one alone can be merged. > > Thanks! > Mauro > > [1] http://patchwork.linuxtv.org/patch/5631/ > > Thank you, -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.2] noon010pc30 conversion to the pad (v2)
Hi Mauro, here is an updated pull request. Additionally I have appended a Kconfig cleanup patch to it. The following changes since commit de2fb698c6fb1e968a5ed9cc449024f119ad3853: [media] saa7164: Adding support for HVR2200 card id 0x8953 (2011-09-21 10:16:31 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung v4l_noon010pc30 Sylwester Nawrocki (4): noon010pc30: Conversion to the media controller API noon010pc30: Improve s_power operation handling noon010pc30: Remove g_chip_ident operation handler v4l: Move SR030PC30, NOON010PC30, M5MOLS drivers to the right location drivers/media/video/Kconfig | 28 ++-- drivers/media/video/noon010pc30.c | 263 +++-- include/media/v4l2-chip-ident.h |3 - 3 files changed, 180 insertions(+), 114 deletions(-) Thank you, -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] sr030pc30: Remove empty s_stream op
Em 19-01-2011 23:44, Sylwester Nawrocki escreveu: > s_stream does nothing in current form so remove it. > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park > --- > drivers/media/video/sr030pc30.c |6 -- > 1 files changed, 0 insertions(+), 6 deletions(-) > > diff --git a/drivers/media/video/sr030pc30.c b/drivers/media/video/sr030pc30.c > index c901721..e1eced1 100644 > --- a/drivers/media/video/sr030pc30.c > +++ b/drivers/media/video/sr030pc30.c > @@ -714,11 +714,6 @@ static int sr030pc30_base_config(struct v4l2_subdev *sd) > return ret; > } > > -static int sr030pc30_s_stream(struct v4l2_subdev *sd, int enable) > -{ > - return 0; > -} > - > static int sr030pc30_s_power(struct v4l2_subdev *sd, int on) > { > struct i2c_client *client = v4l2_get_subdevdata(sd); > @@ -761,7 +756,6 @@ static const struct v4l2_subdev_core_ops > sr030pc30_core_ops = { > }; > > static const struct v4l2_subdev_video_ops sr030pc30_video_ops = { > - .s_stream = sr030pc30_s_stream, > .g_mbus_fmt = sr030pc30_g_fmt, > .s_mbus_fmt = sr030pc30_s_fmt, > .try_mbus_fmt = sr030pc30_try_fmt, Hmm... this patch[1] were never merged. It seems a cleanup, though. Care to review it? Thanks! Mauro [1] http://patchwork.linuxtv.org/patch/5631/ -- To unsubscribe from this list: send the line "unsubscribe 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/3] fixup! mm: alloc_contig_freed_pages() added
From: Michal Nazarewicz Signed-off-by: Michal Nazarewicz --- include/linux/page-isolation.h |4 ++- mm/page_alloc.c| 66 ++- 2 files changed, 60 insertions(+), 10 deletions(-) > On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote: >> +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned >> long end, >> + gfp_t flag) >> +{ >> +unsigned long pfn = start, count; >> +struct page *page; >> +struct zone *zone; >> +int order; >> + >> +VM_BUG_ON(!pfn_valid(start)); >> +zone = page_zone(pfn_to_page(start)); On Thu, 08 Sep 2011 20:05:52 +0200, Dave Hansen wrote: > This implies that start->end are entirely contained in a single zone. > What enforces that? If some higher layer enforces that, I think we > probably need at least a VM_BUG_ON() in here and a comment about who > enforces it. >> +spin_lock_irq(&zone->lock); >> + >> +page = pfn_to_page(pfn); >> +for (;;) { >> +VM_BUG_ON(page_count(page) || !PageBuddy(page)); >> +list_del(&page->lru); >> +order = page_order(page); >> +zone->free_area[order].nr_free--; >> +rmv_page_order(page); >> +__mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order)); >> +pfn += 1 << order; >> +if (pfn >= end) >> +break; >> +VM_BUG_ON(!pfn_valid(pfn)); >> +page += 1 << order; >> +} > This 'struct page *'++ stuff is OK, but only for small, aligned areas. > For at least some of the sparsemem modes (non-VMEMMAP), you could walk > off of the end of the section_mem_map[] when you cross a MAX_ORDER > boundary. I'd feel a little bit more comfortable if pfn_to_page() was > being done each time, or only occasionally when you cross a section > boundary. Do the attached changes seem to make sense? I wanted to avoid calling pfn_to_page() each time as it seem fairly expensive in sparsemem and disctontig modes. At the same time, the macro trickery is so that users of sparsemem-vmemmap and flatmem won't have to pay the price. diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h index b2a81fd..003c52f 100644 --- a/include/linux/page-isolation.h +++ b/include/linux/page-isolation.h @@ -46,11 +46,13 @@ static inline void unset_migratetype_isolate(struct page *page) { __unset_migratetype_isolate(page, MIGRATE_MOVABLE); } + +/* The below functions must be run on a range from a single zone. */ extern unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end, gfp_t flag); extern int alloc_contig_range(unsigned long start, unsigned long end, gfp_t flags, unsigned migratetype); -extern void free_contig_pages(struct page *page, int nr_pages); +extern void free_contig_pages(unsigned long pfn, unsigned nr_pages); /* * For migration. diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 46e78d4..32fda5d 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -5716,9 +5716,41 @@ out: spin_unlock_irqrestore(&zone->lock, flags); } +#if defined(CONFIG_FLATMEM) || defined(CONFIG_SPARSEMEM_VMEMMAP) + +/* + * In FLATMEM and CONFIG_SPARSEMEM_VMEMMAP we can safely increment the page + * pointer and get the same value as if we were to get by calling + * pfn_to_page() on incremented pfn counter. + */ +#define __contig_next_page(page, pageblock_left, pfn, increment) \ + ((page) + (increment)) + +#define __contig_first_page(pageblock_left, pfn) pfn_to_page(pfn) + +#else + +/* + * If we cross pageblock boundary, make sure we get a valid page pointer. If + * we are within pageblock, incrementing the pointer is good enough, and is + * a bit of an optimisation. + */ +#define __contig_next_page(page, pageblock_left, pfn, increment) \ + (likely((pageblock_left) -= (increment)) ? (page) + (increment) \ +: (((pageblock_left) = pageblock_nr_pages), pfn_to_page(pfn))) + +#define __contig_first_page(pageblock_left, pfn) ( \ + ((pageblock_left) = pageblock_nr_pages -\ +((pfn) & (pageblock_nr_pages - 1))), \ + pfn_to_page(pfn)) + + +#endif + unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end, gfp_t flag) { + unsigned long pageblock_left __unused; unsigned long pfn = start, count; struct page *page; struct zone *zone; @@ -5729,27 +5761,37 @@ unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end, spin_lock_irq(&zone->lock); - page = pfn_to_page(pfn); + page = __contig_first_page(pageblock_left, pfn); for (;;) { - VM_BUG_ON(page_count(page) || !PageBuddy(page)); + VM_BUG_ON(!page_count(page) || !Pa
[PATCH] drivers/media/video/stk-webcam.c: webcam LED bug fix [IMPROVED]
This is an improved version of the patch I sent a little ago. The problem was: On my DC-1125 webcam chip from Syntek, whenever the webcam turns on, the LED light on it is turned on also and never turns off again unless system is shut downed or restarted. The previous version seemed to break some other laptop webcam work. Thanks to Andrea Anacleto for the bug report and solution. Signed-off-by: Andrea Anacleto Signed-off-by: Arvydas Sidorenko --- drivers/media/video/stk-webcam.c | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/stk-webcam.c b/drivers/media/video/stk-webcam.c index d1a2cef..af57d80 100644 --- a/drivers/media/video/stk-webcam.c +++ b/drivers/media/video/stk-webcam.c @@ -55,6 +55,8 @@ MODULE_AUTHOR("Jaime Velasco Juan and Nicolas VIVIEN"); MODULE_DESCRIPTION("Syntek DC1125 webcam driver"); +/* bool for webcam LED management */ +int first_init = 1; /* Some cameras have audio interfaces, we aren't interested in those */ static struct usb_device_id stkwebcam_table[] = { @@ -561,6 +563,12 @@ static int v4l_stk_open(struct file *fp) if (dev == NULL || !is_present(dev)) { return -ENXIO; } + + if (!first_init) + stk_camera_write_reg(dev, 0x0, 0x24); + else + first_init = 0; + fp->private_data = dev; usb_autopm_get_interface(dev->interface); @@ -574,6 +582,7 @@ static int v4l_stk_release(struct file *fp) if (dev->owner == fp) { stk_stop_stream(dev); stk_free_buffers(dev); + stk_camera_write_reg(dev, 0x0, 0x49); /* turn off the LED */ dev->owner = NULL; } @@ -1350,6 +1359,7 @@ static int stk_camera_resume(struct usb_interface *intf) return 0; unset_initialised(dev); stk_initialise(dev); + stk_camera_write_reg(dev, 0x0, 0x49); stk_setup_format(dev); if (is_streaming(dev)) stk_start_stream(dev); -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH for 2.6.37] cx23885, cx25840: Provide IR Rx timeout event reports
Em 19-12-2010 21:10, Andy Walls escreveu: > (Resending because Mauro reported losing some emails on IRC) > > Provide CX2388[578] IR receive timeout (RTO) reports in the > final space raw event sent up the chain to the raw IR pulse > decoders. This should allow the lirc decoder to actually > measure the inter-transmission gap properly. Hi Andy, I've no idea what's happened with this patch[1], but it seems that it were never applied. Is this patch still valid? [1] http://patchwork.linuxtv.org/patch/5133/ Thanks, Mauro > > Signed-off-by: Andy Walls > --- > drivers/media/video/cx23885/cx23888-ir.c | 12 > drivers/media/video/cx25840/cx25840-ir.c | 12 > 2 files changed, 16 insertions(+), 8 deletions(-) > > diff --git a/drivers/media/video/cx23885/cx23888-ir.c > b/drivers/media/video/cx23885/cx23888-ir.c > index e37be6f..bb1ce34 100644 > --- a/drivers/media/video/cx23885/cx23888-ir.c > +++ b/drivers/media/video/cx23885/cx23888-ir.c > @@ -673,7 +673,7 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8 > *buf, size_t count, > > unsigned int i, n; > union cx23888_ir_fifo_rec *p; > - unsigned u, v; > + unsigned u, v, w; > > n = count / sizeof(union cx23888_ir_fifo_rec) > * sizeof(union cx23888_ir_fifo_rec); > @@ -692,11 +692,12 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, > u8 *buf, size_t count, > if ((p->hw_fifo_data & FIFO_RXTX_RTO) == FIFO_RXTX_RTO) { > /* Assume RTO was because of no IR light input */ > u = 0; > - v4l2_dbg(2, ir_888_debug, sd, "rx read: end of rx\n"); > + w = 1; > } else { > u = (p->hw_fifo_data & FIFO_RXTX_LVL) ? 1 : 0; > if (invert) > u = u ? 0 : 1; > + w = 0; > } > > v = (unsigned) pulse_width_count_to_ns( > @@ -707,9 +708,12 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8 > *buf, size_t count, > init_ir_raw_event(&p->ir_core_data); > p->ir_core_data.pulse = u; > p->ir_core_data.duration = v; > + p->ir_core_data.timeout = w; > > - v4l2_dbg(2, ir_888_debug, sd, "rx read: %10u ns %s\n", > - v, u ? "mark" : "space"); > + v4l2_dbg(2, ir_888_debug, sd, "rx read: %10u ns %s %s\n", > + v, u ? "mark" : "space", w ? "(timed out)" : ""); > + if (w) > + v4l2_dbg(2, ir_888_debug, sd, "rx read: end of rx\n"); > } > return 0; > } > diff --git a/drivers/media/video/cx25840/cx25840-ir.c > b/drivers/media/video/cx25840/cx25840-ir.c > index 627926f..b210c29 100644 > --- a/drivers/media/video/cx25840/cx25840-ir.c > +++ b/drivers/media/video/cx25840/cx25840-ir.c > @@ -668,7 +668,7 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8 > *buf, size_t count, > u16 divider; > unsigned int i, n; > union cx25840_ir_fifo_rec *p; > - unsigned u, v; > + unsigned u, v, w; > > if (ir_state == NULL) > return -ENODEV; > @@ -694,11 +694,12 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, > u8 *buf, size_t count, > if ((p->hw_fifo_data & FIFO_RXTX_RTO) == FIFO_RXTX_RTO) { > /* Assume RTO was because of no IR light input */ > u = 0; > - v4l2_dbg(2, ir_debug, sd, "rx read: end of rx\n"); > + w = 1; > } else { > u = (p->hw_fifo_data & FIFO_RXTX_LVL) ? 1 : 0; > if (invert) > u = u ? 0 : 1; > + w = 0; > } > > v = (unsigned) pulse_width_count_to_ns( > @@ -709,9 +710,12 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8 > *buf, size_t count, > init_ir_raw_event(&p->ir_core_data); > p->ir_core_data.pulse = u; > p->ir_core_data.duration = v; > + p->ir_core_data.timeout = w; > > - v4l2_dbg(2, ir_debug, sd, "rx read: %10u ns %s\n", > - v, u ? "mark" : "space"); > + v4l2_dbg(2, ir_debug, sd, "rx read: %10u ns %s %s\n", > + v, u ? "mark" : "space", w ? "(timed out)" : ""); > + if (w) > + v4l2_dbg(2, ir_debug, sd, "rx read: end of rx\n"); > } > return 0; > } > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info
Re: [PATCH v3 1/2] v4l2: Add the polarity flags for parallel camera bus FIELD signal
On 09/21/2011 03:24 PM, Sylwester Nawrocki wrote: > Hi Laurent, > > On 09/21/2011 01:12 AM, Laurent Pinchart wrote: >> Hi Sylwester, >> >> Thanks for the patch. >> >> On Monday 19 September 2011 19:07:55 Sylwester Nawrocki wrote: >>> FIELD is an Even/Odd field selection signal, as specified in ITU-R BT.601 >>> standard. Add corresponding flag for configuring the FIELD signal polarity. >>> Also add a comment about usage of V4L2_MBUS_[HV]SYNC* flags for the >>> hardware that uses [HV]REF signals. >> >> I like this approach better. >> > ... >>> +/* Field selection signal for interlaced scan mode */ >>> +#define V4L2_MBUS_FIELD_ACTIVE_HIGH(1 << 10) >>> +#define V4L2_MBUS_FIELD_ACTIVE_LOW (1 << 11) >> >> What does this mean ? The FIELD signal is used to select between odd and >> even >> fields. Does "active high" mean that the field is odd or even when the >> signal >> has a high level ? The comment should make it explicit, or we could even >> rename those two constants to FIELD_ODD_HIGH/FIELD_ODD_LOW (or >> FIELD_EVEN_HIGH/FIELD_EVEN_LOW). > > Yes, certainly I didn't think enough about this. I silently assumed that for > V4L2_MBUS_FIELD_ACTIVE_HIGH FIELD = 0 selects Field1 (odd) and FIELD = 1 > selects > Field2 (even). > I think it would be good to construct the macro so it is possibly > self-explanatory, > rather than requiring often to dig in the documentation. > > So I would go for V4L2_MBUS_FIELD_ODD_LOW/V4L2_MBUS_FIELD_ODD_HIGH. > Unless someone proposes something different/better I'll send an amended > version > tomorrow. Thinking some more of it, V4L2_MBUS_FIELD_EVEN_HIGH/V4L2_MBUS_FIELD_EVEN_LOW is perhaps more in line with other defines where *HIGH means standard, non-inverted case. So it seems better to me. -- To unsubscribe from this list: send the line "unsubscribe 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: Oops in 2.6.37-rc{3,4,5}
Em 21-09-2011 11:45, Mauro Carvalho Chehab escreveu: > Em 12-12-2010 09:15, Chris Clayton escreveu: >> On Sunday 12 December 2010, Dave Young wrote: >>> On Fri, Dec 10, 2010 at 10:34:06PM +, Chris Clayton wrote: I'm not subscribed, so please cc me on any reply. With rc kernels from 2.6.37, X frequently (approx 3 boots out of every 4) fails to start. dmesg shows the oops below. I can bisect over the weekend - probably Sunday - if no answer comes up in the meantime. I get the same oops with rc3, rc and rc5. rc2 doesn't get as far as trying to start X. Happy to test patches or provide additional diagnostics, but I'll be off line soon until 20:00 or so UK time tomorrow. >> >> >> [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] __mutex_lock_slowpath+0x9f/0x170 *pdpt = 34676001 *pde = Oops: 0002 [#1] PREEMPT SMP last sysfs file: /sys/module/drm_kms_helper/initstate Modules linked in: i915 drm_kms_helper drm fb fbdev cfbcopyarea video backlight output cfbimgblt cfbfillrect xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 saa7134_alsa tda10048 saa7134_dvb videobuf_dvb dvb_core mt20xx tea5767 tda9887 msp3400 gspca_zc3xx gspca_main tda18271 tda8290 ir_lirc_codec tuner lirc_dev bttv i2c_algo_bit btcx_risc snd_bt87x ir_common uhci_hcd ir_core saa7134 v4l2_common videodev v4l1_compat ehci_hcd videobuf_dma_sg videobuf_core tveeprom evdev [last unloaded: floppy] Pid: 1725, comm: X Not tainted 2.6.37-rc5+ #476 EG41MF-US2H/EG41MF-US2H EIP: 0060:[] EFLAGS: 00013246 CPU: 3 EIP is at __mutex_lock_slowpath+0x9f/0x170 EAX: EBX: f4403410 ECX: f4403420 EDX: f4641dd8 ESI: f4403414 EDI: EBP: f4403418 ESP: f4641dd4 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process X (pid: 1725, ti=f464 task=f3c67390 task.ti=f464) Stack: f3c67390 f4403418 f46a3800 f4403410 f4fd14f0 f425f600 f4403400 c13228a6 f4fd1000 f4fd14f0 f8841b6c c10aabb2 0514 f4c34000 f4df72c0 c10aabf7 f4403410 0001 f425f600 ffed f425f604 f46bfe40 Call Trace: [] ? mutex_lock+0x16/0x30 [] ? bttv_open+0xac/0x280 [bttv] [] ? cdev_get+0x52/0x90 [] ? exact_lock+0x7/0x10 [] ? v4l2_open+0xb7/0xd0 [videodev] [] ? chrdev_open+0xda/0x1b0 [] ? __dentry_open+0xd5/0x280 [] ? nameidata_to_filp+0x68/0x70 [] ? chrdev_open+0x0/0x1b0 [] ? do_last.clone.32+0x34f/0x5a0 [] ? do_filp_open+0x383/0x550 [] ? getname+0x28/0xf0 [] ? do_sys_open+0x58/0x110 [] ? filp_close+0x49/0x70 [] ? sys_open+0x2c/0x40 [] ? sysenter_do_call+0x12/0x26 [] ? timer_cpu_notify+0x1b4/0x233 Code: 83 78 18 63 7f b6 8d b6 00 00 00 00 8d 73 04 8d 6b 08 89 f0 e8 f3 10 00 00 8b 43 0c 8d 54 24 04 89 44 24 08 89 53 0c 89 6c 24 04 <89> 10 8b 04 24 ba ff ff ff ff 89 44 24 0c 89 d0 87 03 83 f8 01 EIP: [] __mutex_lock_slowpath+0x9f/0x170 SS:ESP 0068:f4641dd4 CR2: ---[ end trace 5ac4e44ad0dc7959 ]--- >> >> >> >>> Could you try following patch? >>> >>> --- linux-2.6.orig/drivers/media/video/bt8xx/bttv-driver.c 2010-11-27 >>> 11:21:30.0 +0800 +++ >>> linux-2.6/drivers/media/video/bt8xx/bttv-driver.c 2010-12-12 >>> 16:31:39.63338 +0800 @@ -3291,6 +3291,8 @@ static int bttv_open(struct >>> file *file) >>> fh = kmalloc(sizeof(*fh), GFP_KERNEL); >>> if (unlikely(!fh)) >>> return -ENOMEM; >>> + >>> + mutex_init(&fh->cap.vb_lock); >>> file->private_data = fh; >>> >>> /* >> >> Yes Dave, that's fixed it thanks. Six successful boots, which never happened >> without the patch. >> >> Tested-by: Chris Clayton >> > > It seems we missed this patch. It looks right on my eyes, so I'm > applying it. My mistake. This patch were superseded by some changes at vb_lock. > > Thanks, > Mauro > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe 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: Oops in 2.6.37-rc{3,4,5}
Em 12-12-2010 09:15, Chris Clayton escreveu: > On Sunday 12 December 2010, Dave Young wrote: >> On Fri, Dec 10, 2010 at 10:34:06PM +, Chris Clayton wrote: >>> I'm not subscribed, so please cc me on any reply. >>> >>> With rc kernels from 2.6.37, X frequently (approx 3 boots out of every 4) >>> fails to start. dmesg shows the oops below. I can bisect over the weekend >>> - probably Sunday - if no answer comes up in the meantime. I get the same >>> oops with rc3, rc and rc5. rc2 doesn't get as far as trying to start X. >>> Happy to test patches or provide additional diagnostics, but I'll be off >>> line soon until 20:00 or so UK time tomorrow. > > > >>> >>> [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 >>> BUG: unable to handle kernel NULL pointer dereference at (null) >>> IP: [] __mutex_lock_slowpath+0x9f/0x170 >>> *pdpt = 34676001 *pde = >>> Oops: 0002 [#1] PREEMPT SMP >>> last sysfs file: /sys/module/drm_kms_helper/initstate >>> Modules linked in: i915 drm_kms_helper drm fb fbdev cfbcopyarea video >>> backlight output cfbimgblt cfbfillrect xt_state iptable_filter >>> ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack >>> nf_defrag_ipv4 saa7134_alsa tda10048 saa7134_dvb videobuf_dvb dvb_core >>> mt20xx tea5767 tda9887 msp3400 gspca_zc3xx gspca_main tda18271 tda8290 >>> ir_lirc_codec tuner lirc_dev bttv i2c_algo_bit btcx_risc snd_bt87x >>> ir_common uhci_hcd ir_core saa7134 v4l2_common videodev v4l1_compat >>> ehci_hcd videobuf_dma_sg videobuf_core tveeprom evdev [last unloaded: >>> floppy] >>> >>> Pid: 1725, comm: X Not tainted 2.6.37-rc5+ #476 EG41MF-US2H/EG41MF-US2H >>> EIP: 0060:[] EFLAGS: 00013246 CPU: 3 >>> EIP is at __mutex_lock_slowpath+0x9f/0x170 >>> EAX: EBX: f4403410 ECX: f4403420 EDX: f4641dd8 >>> ESI: f4403414 EDI: EBP: f4403418 ESP: f4641dd4 >>> DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 >>> Process X (pid: 1725, ti=f464 task=f3c67390 task.ti=f464) >>> Stack: >>> f3c67390 f4403418 f46a3800 f4403410 f4fd14f0 f425f600 f4403400 >>> c13228a6 f4fd1000 f4fd14f0 f8841b6c c10aabb2 0514 f4c34000 >>> f4df72c0 c10aabf7 f4403410 0001 f425f600 ffed f425f604 f46bfe40 >>> Call Trace: >>> [] ? mutex_lock+0x16/0x30 >>> [] ? bttv_open+0xac/0x280 [bttv] >>> [] ? cdev_get+0x52/0x90 >>> [] ? exact_lock+0x7/0x10 >>> [] ? v4l2_open+0xb7/0xd0 [videodev] >>> [] ? chrdev_open+0xda/0x1b0 >>> [] ? __dentry_open+0xd5/0x280 >>> [] ? nameidata_to_filp+0x68/0x70 >>> [] ? chrdev_open+0x0/0x1b0 >>> [] ? do_last.clone.32+0x34f/0x5a0 >>> [] ? do_filp_open+0x383/0x550 >>> [] ? getname+0x28/0xf0 >>> [] ? do_sys_open+0x58/0x110 >>> [] ? filp_close+0x49/0x70 >>> [] ? sys_open+0x2c/0x40 >>> [] ? sysenter_do_call+0x12/0x26 >>> [] ? timer_cpu_notify+0x1b4/0x233 >>> Code: 83 78 18 63 7f b6 8d b6 00 00 00 00 8d 73 04 8d 6b 08 89 f0 e8 f3 >>> 10 00 00 8b 43 0c 8d 54 24 04 89 44 24 08 89 53 0c 89 6c 24 04 <89> 10 8b >>> 04 24 ba ff ff ff ff 89 44 24 0c 89 d0 87 03 83 f8 01 >>> EIP: [] __mutex_lock_slowpath+0x9f/0x170 SS:ESP 0068:f4641dd4 >>> CR2: >>> ---[ end trace 5ac4e44ad0dc7959 ]--- > > > >> Could you try following patch? >> >> --- linux-2.6.orig/drivers/media/video/bt8xx/bttv-driver.c 2010-11-27 >> 11:21:30.0 +0800 +++ >> linux-2.6/drivers/media/video/bt8xx/bttv-driver.c2010-12-12 >> 16:31:39.63338 +0800 @@ -3291,6 +3291,8 @@ static int bttv_open(struct >> file *file) >> fh = kmalloc(sizeof(*fh), GFP_KERNEL); >> if (unlikely(!fh)) >> return -ENOMEM; >> + >> +mutex_init(&fh->cap.vb_lock); >> file->private_data = fh; >> >> /* > > Yes Dave, that's fixed it thanks. Six successful boots, which never happened > without the patch. > > Tested-by: Chris Clayton > It seems we missed this patch. It looks right on my eyes, so I'm applying it. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] noon010pc30: Conversion to the media controller API
Hi Sylwester, Thanks for the patch. On Wednesday 21 September 2011 16:26:00 Sylwester Nawrocki wrote: > Replace g/s_mbus_fmt ops with the pad level get/set_fmt operations. > Add media entity initialization and set subdev flags so the host driver > creates a subdev device node for the driver. > A mutex was added for serializing the subdev operations. When setting > format is attempted during streaming an (EBUSY) error will be returned. > > After the device is powered up it will now remain in "power sleep" > mode until s_stream(1) is called. The "power sleep" mode is used > to suspend/resume frame generation at the sensor's output through > s_stream op. > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park Acked-by: Laurent Pinchart -- 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 v4] noon010pc30: Conversion to the media controller API
Replace g/s_mbus_fmt ops with the pad level get/set_fmt operations. Add media entity initialization and set subdev flags so the host driver creates a subdev device node for the driver. A mutex was added for serializing the subdev operations. When setting format is attempted during streaming an (EBUSY) error will be returned. After the device is powered up it will now remain in "power sleep" mode until s_stream(1) is called. The "power sleep" mode is used to suspend/resume frame generation at the sensor's output through s_stream op. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Addresing Laurent's comments, changes since v3: - set constant default TRY format in subdev open() internal op rather than the currently set format --- drivers/media/video/Kconfig |2 +- drivers/media/video/noon010pc30.c | 221 +--- 2 files changed, 154 insertions(+), 69 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 6279663..75bb46f 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -755,7 +755,7 @@ config VIDEO_VIA_CAMERA config VIDEO_NOON010PC30 tristate "NOON010PC30 CIF camera sensor support" - depends on I2C && VIDEO_V4L2 + depends on I2C && VIDEO_V4L2 && EXPERIMENTAL && VIDEO_V4L2_SUBDEV_API ---help--- This driver supports NOON010PC30 CIF camera from Siliconfile diff --git a/drivers/media/video/noon010pc30.c b/drivers/media/video/noon010pc30.c index 35f722a..1a874ec 100644 --- a/drivers/media/video/noon010pc30.c +++ b/drivers/media/video/noon010pc30.c @@ -1,7 +1,7 @@ /* * Driver for SiliconFile NOON010PC30 CIF (1/11") Image Sensor with ISP * - * Copyright (C) 2010 Samsung Electronics + * Copyright (C) 2010 - 2011 Samsung Electronics Co., Ltd. * Contact: Sylwester Nawrocki, * * Initial register configuration based on a driver authored by @@ -10,7 +10,7 @@ * 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; either version 2 of the License, or - * (at your option) any later vergsion. + * (at your option) any later version. */ #include @@ -131,17 +131,24 @@ static const char * const noon010_supply_name[] = { struct noon010_info { struct v4l2_subdev sd; + struct media_pad pad; struct v4l2_ctrl_handler hdl; const struct noon010pc30_platform_data *pdata; + struct regulator_bulk_data supply[NOON010_NUM_SUPPLIES]; + u32 gpio_nreset; + u32 gpio_nstby; + + /* Protects the struct members below */ + struct mutex lock; + const struct noon010_format *curr_fmt; const struct noon010_frmsize *curr_win; + unsigned int apply_new_cfg:1; + unsigned int streaming:1; unsigned int hflip:1; unsigned int vflip:1; unsigned int power:1; u8 i2c_reg_page; - struct regulator_bulk_data supply[NOON010_NUM_SUPPLIES]; - u32 gpio_nreset; - u32 gpio_nstby; }; struct i2c_regval { @@ -313,6 +320,7 @@ static int noon010_enable_autowhitebalance(struct v4l2_subdev *sd, int on) return ret; } +/* Called with struct noon010_info.lock mutex held */ static int noon010_set_flip(struct v4l2_subdev *sd, int hflip, int vflip) { struct noon010_info *info = to_noon010(sd); @@ -340,21 +348,18 @@ static int noon010_set_flip(struct v4l2_subdev *sd, int hflip, int vflip) static int noon010_set_params(struct v4l2_subdev *sd) { struct noon010_info *info = to_noon010(sd); - int ret; - if (!info->curr_win) - return -EINVAL; - - ret = cam_i2c_write(sd, VDO_CTL_REG(0), info->curr_win->vid_ctl1); - - if (!ret && info->curr_fmt) - ret = cam_i2c_write(sd, ISP_CTL_REG(0), - info->curr_fmt->ispctl1_reg); - return ret; + int ret = cam_i2c_write(sd, VDO_CTL_REG(0), + info->curr_win->vid_ctl1); + if (ret) + return ret; + return cam_i2c_write(sd, ISP_CTL_REG(0), +info->curr_fmt->ispctl1_reg); } /* Find nearest matching image pixel size. */ -static int noon010_try_frame_size(struct v4l2_mbus_framefmt *mf) +static int noon010_try_frame_size(struct v4l2_mbus_framefmt *mf, + const struct noon010_frmsize **size) { unsigned int min_err = ~0; int i = ARRAY_SIZE(noon010_sizes); @@ -374,11 +379,14 @@ static int noon010_try_frame_size(struct v4l2_mbus_framefmt *mf) if (match) { mf->width = match->width; mf->height = match->height; + if (size) + *size = match; return 0; } return -EINVAL; } +/* Called with info.lock mutex held */ static int power_enable(struct noon010_
Re: [PATCH 2/8] mm: alloc_contig_freed_pages() added
On Wed, 2011-09-21 at 15:17 +0200, Michal Nazarewicz wrote: > > This 'struct page *'++ stuff is OK, but only for small, aligned areas. > > For at least some of the sparsemem modes (non-VMEMMAP), you could walk > > off of the end of the section_mem_map[] when you cross a MAX_ORDER > > boundary. I'd feel a little bit more comfortable if pfn_to_page() was > > being done each time, or only occasionally when you cross a section > > boundary. > > I'm fine with that. I've used pointer arithmetic for performance reasons > but if that may potentially lead to bugs then obviously pfn_to_page() > should be used pfn_to_page() on x86 these days is usually: #define __pfn_to_page(pfn) (vmemmap + (pfn)) Even for the non-vmemmap sparsemem it stays pretty quick because the section array is in cache as you run through the loop. There are ways to _minimize_ the number of pfn_to_page() calls by checking when you cross a section boundary, or even at a MAX_ORDER_NR_PAGES boundary. But, I don't think it's worth the trouble. -- Dave -- To unsubscribe from this list: send the line "unsubscribe 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 1/3] noon010pc30: Conversion to the media controller API
Hi Laurent, thanks for the review. On 09/21/2011 12:18 AM, Laurent Pinchart wrote: > Hi Sylwester, > > Thanks for the patch. > > On Friday 16 September 2011 17:59:54 Sylwester Nawrocki wrote: >> Replace g/s_mbus_fmt ops with the pad level get/set_fmt operations. >> Add media entity initialization and set subdev flags so the host driver >> creates a subdev device node for the driver. >> A mutex was added for serializing the subdev operations. When setting >> format is attempted during streaming an (EBUSY) error will be returned. >> >> After the device is powered up it will now remain in "power sleep" >> mode until s_stream(1) is called. The "power sleep" mode is used >> to suspend/resume frame generation at the sensor's output through >> s_stream op. >> >> While at here simplify the colorspace parameter handling. >> >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park > > [snip] > >> diff --git a/drivers/media/video/noon010pc30.c >> b/drivers/media/video/noon010pc30.c index 35f722a..115d976 100644 >> --- a/drivers/media/video/noon010pc30.c >> +++ b/drivers/media/video/noon010pc30.c > > [snip] > >> @@ -599,6 +641,22 @@ static int noon010_log_status(struct v4l2_subdev *sd) >> return 0; >> } >> >> +static int noon010_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh) >> +{ >> +struct v4l2_mbus_framefmt *mf = v4l2_subdev_get_try_format(fh, 0); >> +struct noon010_info *info = to_noon010(sd); >> + >> +mutex_lock(&info->lock); >> +noon010_get_current_fmt(to_noon010(sd), mf); > > Should you initialize mf with a constant default format instead of retrieving > the current format from the sensor ? A non-constant default would probably > confuse userspace application. Sure, I could change to it. But I don't quite see the problem, the applications should call set_fmt(TRY) anyway, rather than relying on the format gotten right after opening the device, shouldn't they ? Anyway I guess it's better to have all drivers behaving consistently. Regards, -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 7/8] ARM: integrate CMA with DMA-mapping subsystem
Hello, On Thursday, September 08, 2011 7:27 PM Mike Frysinger wrote: > On Fri, Aug 19, 2011 at 10:27, Marek Szyprowski wrote: > > arch/arm/include/asm/device.h |3 + > > arch/arm/include/asm/dma-contiguous.h | 33 +++ > > seems like these would be good asm-generic/ additions rather than arm Only some of them can be really moved to asm-generic imho. The following lines are definitely architecture specific: void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size); Some other archs might define empty fixup function. Right now only ARM architecture is the real client of the CMA. IMHO if any other arch stats using CMA, some of the CMA definitions can be then moved to asm-generic. Right now I wanted to keep it as simple as possible. Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr
> -Original Message- > From: Taneja, Archit > Sent: Friday, September 16, 2011 3:31 PM > To: Hiremath, Vaibhav > Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux- > me...@vger.kernel.org; Taneja, Archit > Subject: [PATCH 3/5] [media]: OMAP_VOUT: Fix VSYNC IRQ handling in > omap_vout_isr > > Currently, in omap_vout_isr(), if the panel type is DPI, and if we > get either VSYNC or VSYNC2 interrupts, we proceed ahead to set the > current buffers state to VIDEOBUF_DONE and prepare to display the > next frame in the queue. > > On OMAP4, because we have 2 LCD managers, the panel type itself is not > sufficient to tell if we have received the correct irq, i.e, we shouldn't > proceed ahead if we get a VSYNC interrupt for LCD2 manager, or a VSYNC2 > interrupt for LCD manager. > > Fix this by correlating LCD manager to VSYNC interrupt and LCD2 manager > to VSYNC2 interrupt. > > Signed-off-by: Archit Taneja > --- > drivers/media/video/omap/omap_vout.c | 14 +++--- > 1 files changed, 11 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/video/omap/omap_vout.c > b/drivers/media/video/omap/omap_vout.c > index c5f2ea0..20638c3 100644 > --- a/drivers/media/video/omap/omap_vout.c > +++ b/drivers/media/video/omap/omap_vout.c > @@ -566,8 +566,8 @@ err: > > static void omap_vout_isr(void *arg, unsigned int irqstatus) > { > - int ret, fid; > - u32 addr; > + int ret, fid, mgr_id; > + u32 addr, irq; > struct omap_overlay *ovl; > struct timeval timevalue; > struct omapvideo_info *ovid; > @@ -583,6 +583,7 @@ static void omap_vout_isr(void *arg, unsigned int > irqstatus) > if (!ovl->manager || !ovl->manager->device) > return; > > + mgr_id = ovl->manager->id; > cur_display = ovl->manager->device; > > spin_lock(&vout->vbq_lock); > @@ -590,7 +591,14 @@ static void omap_vout_isr(void *arg, unsigned int > irqstatus) > > switch (cur_display->type) { > case OMAP_DISPLAY_TYPE_DPI: > - if (!(irqstatus & (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) > + if (mgr_id == OMAP_DSS_CHANNEL_LCD) > + irq = DISPC_IRQ_VSYNC; > + else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) > + irq = DISPC_IRQ_VSYNC2; > + else > + goto vout_isr_err; > + > + if (!(irqstatus & irq)) > goto vout_isr_err; > break; I understand what this patch meant for, but I am more curious to know What is value addition of this patch? if (!(irqstatus & (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) Vs if (mgr_id == OMAP_DSS_CHANNEL_LCD) irq = DISPC_IRQ_VSYNC; else if (mgr_id == OMAP_DSS_CHANNEL_LCD2) irq = DISPC_IRQ_VSYNC2; Isn't this same, because we are not doing anything separate and special for VSYNC and VSYNC2? Thanks, Vaibhav > case OMAP_DISPLAY_TYPE_VENC: > -- > 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] v4l2: Add the polarity flags for parallel camera bus FIELD signal
Hi Laurent, On 09/21/2011 01:12 AM, Laurent Pinchart wrote: > Hi Sylwester, > > Thanks for the patch. > > On Monday 19 September 2011 19:07:55 Sylwester Nawrocki wrote: >> FIELD is an Even/Odd field selection signal, as specified in ITU-R BT.601 >> standard. Add corresponding flag for configuring the FIELD signal polarity. >> Also add a comment about usage of V4L2_MBUS_[HV]SYNC* flags for the >> hardware that uses [HV]REF signals. > > I like this approach better. > ... >> +/* Field selection signal for interlaced scan mode */ >> +#define V4L2_MBUS_FIELD_ACTIVE_HIGH (1 << 10) >> +#define V4L2_MBUS_FIELD_ACTIVE_LOW (1 << 11) > > What does this mean ? The FIELD signal is used to select between odd and even > fields. Does "active high" mean that the field is odd or even when the signal > has a high level ? The comment should make it explicit, or we could even > rename those two constants to FIELD_ODD_HIGH/FIELD_ODD_LOW (or > FIELD_EVEN_HIGH/FIELD_EVEN_LOW). Yes, certainly I didn't think enough about this. I silently assumed that for V4L2_MBUS_FIELD_ACTIVE_HIGH FIELD = 0 selects Field1 (odd) and FIELD = 1 selects Field2 (even). I think it would be good to construct the macro so it is possibly self-explanatory, rather than requiring often to dig in the documentation. So I would go for V4L2_MBUS_FIELD_ODD_LOW/V4L2_MBUS_FIELD_ODD_HIGH. Unless someone proposes something different/better I'll send an amended version tomorrow. Thanks, -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL for v3.2] [media] saa7164: Adding support for HVR2200 card id 0x8953
Em 17-09-2011 18:35, Steven Toth escreveu: > Hi Mauro, > > Please pull 92aa36f8f9d19b7c47ad3daca15aa0932254246b from > git://git.kernellabs.com/stoth/saa7164-dev.git I need to know from what branch I need to pull. As this is auto-generated when a git request-pull is used, I suspect that you're preparing the pull request by hand or by some script you wrote. The better way is to just run: git request-pull $ORIGIN $URL where $ORIGIN is the reference branch/object for the pull (for example, remotes/media/staging/v3.2) and $URL is the http/git/ssh URL for your tree. This time, I've verified it manually, but please use git request-pull next time, as it makes my life easier, and will allow patchwork to get your pull request. > > Another SAA7164 HVR220 card profile. > > http://git.kernellabs.com/?p=stoth/saa7164-dev.git;a=commit;h=92aa36f8f9d19b7c47ad3daca15aa0932254246b Applied, thanks! > > drivers/media/video/saa7164/saa7164-cards.c | 62 +++ > drivers/media/video/saa7164/saa7164-dvb.c |1 + > drivers/media/video/saa7164/saa7164.h |1 + > > Thanks, > Thanks, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] mm: alloc_contig_freed_pages() added
On Thu, 08 Sep 2011 20:05:52 +0200, Dave Hansen wrote: On Fri, 2011-08-19 at 16:27 +0200, Marek Szyprowski wrote: +unsigned long alloc_contig_freed_pages(unsigned long start, unsigned long end, + gfp_t flag) +{ + unsigned long pfn = start, count; + struct page *page; + struct zone *zone; + int order; + + VM_BUG_ON(!pfn_valid(start)); + zone = page_zone(pfn_to_page(start)); This implies that start->end are entirely contained in a single zone. What enforces that? In case of CMA, the __cma_activate_area() function from 6/8 has the check: 151 VM_BUG_ON(!pfn_valid(pfn)); 152 VM_BUG_ON(page_zone(pfn_to_page(pfn)) != zone); This guarantees that CMA will never try to call alloc_contig_freed_pages() on a region that spans multiple regions. If some higher layer enforces that, I think we probably need at least a VM_BUG_ON() in here and a comment about who enforces it. Agreed. + spin_lock_irq(&zone->lock); + + page = pfn_to_page(pfn); + for (;;) { + VM_BUG_ON(page_count(page) || !PageBuddy(page)); + list_del(&page->lru); + order = page_order(page); + zone->free_area[order].nr_free--; + rmv_page_order(page); + __mod_zone_page_state(zone, NR_FREE_PAGES, -(1UL << order)); + pfn += 1 << order; + if (pfn >= end) + break; + VM_BUG_ON(!pfn_valid(pfn)); + page += 1 << order; + } This 'struct page *'++ stuff is OK, but only for small, aligned areas. For at least some of the sparsemem modes (non-VMEMMAP), you could walk off of the end of the section_mem_map[] when you cross a MAX_ORDER boundary. I'd feel a little bit more comfortable if pfn_to_page() was being done each time, or only occasionally when you cross a section boundary. I'm fine with that. I've used pointer arithmetic for performance reasons but if that may potentially lead to bugs then obviously pfn_to_page() should be used. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe 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 v1 2/3] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
Hi Sylwester, On Wednesday 21 September 2011 14:28:25 Sylwester Nawrocki wrote: > On 09/21/2011 12:17 AM, Sakari Ailus wrote: > > On Tue, Sep 20, 2011 at 11:25:31PM +0200, Sylwester Nawrocki wrote: > >> On 09/20/2011 10:57 PM, Sakari Ailus wrote: > >>> On Tue, Sep 20, 2011 at 01:58:58PM +0200, Sylwester Nawrocki wrote: > V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct > a driver what is the power line frequency so an appropriate filter > can be used by the device to cancel flicker by compensating the light > intensity ripple and thus. Currently in the menu we have entries for > 50 and 60 Hz and for entirely disabling the anti-flicker filter. > However some devices are capable of automatically detecting the > frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them. > > Signed-off-by: Sylwester Nawrocki > Signed-off-by: Kyungmin Park > Acked-by: Laurent Pinchart > --- > > Documentation/DocBook/media/v4l/controls.xml |5 +++-- > drivers/media/video/v4l2-ctrls.c |1 + > include/linux/videodev2.h|1 + > 3 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml index 2420e4a..c6b3c46 > 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -232,8 +232,9 @@ control is deprecated. New drivers and > applications should use the > > Enables a power line frequency filter to avoid > > flicker. Possible values forenum > v4l2_power_line_frequency are: > V4L2_CID_POWER_LINE_FREQUENCY_DISABLED (0), > > -V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1) and > -V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2). > +V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1), > +V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2) and > +V4L2_CID_POWER_LINE_FREQUENCY_AUTO (3). > >>> > >>> A stupid question: wouldn't this be a case for a new control for > >>> automatic power line frequency, in other words enabling or disabling > >>> it? > >> > >> IMO this would complicate things in kernel and user land, without any > >> reasonable positive effects. AUTO seems to fit well here, it's just > >> another mode of operation of a power line noise filter. Why make things > >> more complicated than they need to be ? > > > > The advantage would be to be able to get the power line frquency if > > that's supported by the hardware. This implementation excludes that. > > Such information might be interesting to add e.g. to the image's exif > > data. > > AFAIU, the power line frequency filter just modifies frame exposure time to > be multiple of half of the mains frequency period. So it's the exposure > time that gets finally affected. Maybe there is some hardware that > supports retrieving of the detected frequency, however I'm not aware of > it. And it doesn't seem useful unless you want to use camera as some > non-standard measurement tool. It also takes some time until the detection > algorithm locks, during this time an undefined frequency value would be > read. > > I believe the filter settings do not really apply to still capture as it > involves periodic operation, like preview. Even if we had this as meta > data tag, there are more direct raw image parameters than the PL noise > filter frequency. > > I feel uncomfortable with having 2 controls, where one can disable the > filter and the other enable it with AUTO setting. > Let's say the sensor supports 4 distinct settings of the filter: OFF, 50HZ, > 60HZ, AUTO. (there is already one sensor driver in mainline that support > it - ov519). How do we map this onto 2 controls ? > > What do we return from the menu control that covers { OFF, 50HZ, 60HZ } > when AUTO mode is enabled through the other control and H/W doesn't allow > to read the detected frequency ? > > I think, for the 2 controls we would need the DISABLED entry not to belong > to V4L2_CID_POWER_LINE_FREQUENCY at first place. > > > Not sure if that's important, though. > > I would say no, but someone can prove me wrong. And who knows what kind of > strange H/W future brings. I think it all boils down to whether V4L2_CID_POWER_LINE_FREQUENCY is the power line frequency filter control or the power line frequency control. In the first case it doesn't make sense to use two separate controls. In the second case it could. I don't think we need two controls for this, but that's just a personal opinion of the "I don't think we need to bother" type :-) -- 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 v1 2/3] v4l: Add AUTO option for the V4L2_CID_POWER_LINE_FREQUENCY control
Hi Sakari, On 09/21/2011 12:17 AM, Sakari Ailus wrote: > On Tue, Sep 20, 2011 at 11:25:31PM +0200, Sylwester Nawrocki wrote: >> On 09/20/2011 10:57 PM, Sakari Ailus wrote: >>> On Tue, Sep 20, 2011 at 01:58:58PM +0200, Sylwester Nawrocki wrote: V4L2_CID_POWER_LINE_FREQUENCY control allows applications to instruct a driver what is the power line frequency so an appropriate filter can be used by the device to cancel flicker by compensating the light intensity ripple and thus. Currently in the menu we have entries for 50 and 60 Hz and for entirely disabling the anti-flicker filter. However some devices are capable of automatically detecting the frequency, so add V4L2_CID_POWER_LINE_FREQUENCY_AUTO entry for them. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Acked-by: Laurent Pinchart --- Documentation/DocBook/media/v4l/controls.xml |5 +++-- drivers/media/video/v4l2-ctrls.c |1 + include/linux/videodev2.h|1 + 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 2420e4a..c6b3c46 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -232,8 +232,9 @@ control is deprecated. New drivers and applications should use the Enables a power line frequency filter to avoid flicker. Possible values forenum v4l2_power_line_frequency are: V4L2_CID_POWER_LINE_FREQUENCY_DISABLED (0), -V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1) and -V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2). +V4L2_CID_POWER_LINE_FREQUENCY_50HZ (1), +V4L2_CID_POWER_LINE_FREQUENCY_60HZ (2) and +V4L2_CID_POWER_LINE_FREQUENCY_AUTO (3). >>> >>> A stupid question: wouldn't this be a case for a new control for automatic >>> power line frequency, in other words enabling or disabling it? >> >> IMO this would complicate things in kernel and user land, without any >> reasonable >> positive effects. AUTO seems to fit well here, it's just another mode of >> operation >> of a power line noise filter. Why make things more complicated than they >> need to be ? > > The advantage would be to be able to get the power line frquency if that's > supported by the hardware. This implementation excludes that. Such > information might be interesting to add e.g. to the image's exif data. AFAIU, the power line frequency filter just modifies frame exposure time to be multiple of half of the mains frequency period. So it's the exposure time that gets finally affected. Maybe there is some hardware that supports retrieving of the detected frequency, however I'm not aware of it. And it doesn't seem useful unless you want to use camera as some non-standard measurement tool. It also takes some time until the detection algorithm locks, during this time an undefined frequency value would be read. I believe the filter settings do not really apply to still capture as it involves periodic operation, like preview. Even if we had this as meta data tag, there are more direct raw image parameters than the PL noise filter frequency. I feel uncomfortable with having 2 controls, where one can disable the filter and the other enable it with AUTO setting. Let's say the sensor supports 4 distinct settings of the filter: OFF, 50HZ, 60HZ, AUTO. (there is already one sensor driver in mainline that support it - ov519). How do we map this onto 2 controls ? What do we return from the menu control that covers { OFF, 50HZ, 60HZ } when AUTO mode is enabled through the other control and H/W doesn't allow to read the detected frequency ? I think, for the 2 controls we would need the DISABLED entry not to belong to V4L2_CID_POWER_LINE_FREQUENCY at first place. > > Not sure if that's important, though. I would say no, but someone can prove me wrong. And who knows what kind of strange H/W future brings. Regards, -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] v4l2: add vb2_get_unmapped_area in vb2 core
Hello, On Friday, September 09, 2011 12:12 AM Scott Jiang wrote: > no mmu system needs get_unmapped_area file operations to do mmap > > Signed-off-by: Scott Jiang The patch looks fine, I will add it to my videobuf2 fixes branch. Thanks for your contribution! > --- > drivers/media/video/videobuf2-core.c | 31 +++ > include/media/videobuf2-core.h |7 +++ > 2 files changed, 38 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/video/videobuf2-core.c > b/drivers/media/video/videobuf2-core.c > index 3015e60..02a0ec6 100644 > --- a/drivers/media/video/videobuf2-core.c > +++ b/drivers/media/video/videobuf2-core.c > @@ -1344,6 +1344,37 @@ int vb2_mmap(struct vb2_queue *q, struct > vm_area_struct *vma) > } > EXPORT_SYMBOL_GPL(vb2_mmap); > > +#ifndef CONFIG_MMU > +unsigned long vb2_get_unmapped_area(struct vb2_queue *q, > + unsigned long addr, > + unsigned long len, > + unsigned long pgoff, > + unsigned long flags) > +{ > + unsigned long off = pgoff << PAGE_SHIFT; > + struct vb2_buffer *vb; > + unsigned int buffer, plane; > + int ret; > + > + if (q->memory != V4L2_MEMORY_MMAP) { > + dprintk(1, "Queue is not currently set up for mmap\n"); > + return -EINVAL; > + } > + > + /* > + * Find the plane corresponding to the offset passed by userspace. > + */ > + ret = __find_plane_by_offset(q, off, &buffer, &plane); > + if (ret) > + return ret; > + > + vb = q->bufs[buffer]; > + > + return (unsigned long)vb2_plane_vaddr(vb, plane); > +} > +EXPORT_SYMBOL_GPL(vb2_get_unmapped_area); > +#endif > + > static int __vb2_init_fileio(struct vb2_queue *q, int read); > static int __vb2_cleanup_fileio(struct vb2_queue *q); > > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h > index f87472a..5c7b5b4 100644 > --- a/include/media/videobuf2-core.h > +++ b/include/media/videobuf2-core.h > @@ -302,6 +302,13 @@ int vb2_streamon(struct vb2_queue *q, enum v4l2_buf_type > type); > int vb2_streamoff(struct vb2_queue *q, enum v4l2_buf_type type); > > int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma); > +#ifndef CONFIG_MMU > +unsigned long vb2_get_unmapped_area(struct vb2_queue *q, > + unsigned long addr, > + unsigned long len, > + unsigned long pgoff, > + unsigned long flags); > +#endif > unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table > *wait); > size_t vb2_read(struct vb2_queue *q, char __user *data, size_t count, > loff_t *ppos, int nonblock); > -- > 1.7.0.4 Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx231xx: DMA problem on ARM
On Wed, Sep 21, 2011 at 7:56 AM, Thomas Petazzoni wrote: > Hello, > > On an x86 platform, we have managed to use a Hauppauge USB Live 2 > capture device with the cx231xx on a 3.0 kernel with the patch at [1]. > Things work nicely. > > However, using a similar 3.0 kernel with the exact same device on an > ARM platform (BeagleBoard-XM), starting a V4L application to capture > the video immediately triggers the following BUG_ON in > arch/arm/mm/dma-mapping.c: > > 429 void ___dma_single_cpu_to_dev(const void *kaddr, size_t size, > 430 enum dma_data_direction dir) > 431 { > 432 unsigned long paddr; > 433 > 434 BUG_ON(!virt_addr_valid(kaddr) || !virt_addr_valid(kaddr + size - > 1)); > > This problem looks similar to the problem fixed on the gspca driver by: > > commit 882787ff8fdeb0be790547ee9b22b281095e95da > Author: Jason Wang > Date: Fri Sep 3 06:57:19 2010 -0300 > > V4L/DVB: gspca - main: Fix a crash of some webcams on ARM arch > > When plugging some webcams on ARM, the system crashes. > This is because we alloc buffer for an urb through usb_buffer_alloc, > the alloced buffer is already in DMA coherent region, so we should > set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when > we submit this urb, the hcd core will handle this address as an > non-DMA address and call dma_map_single/sg to map it. On arm > architecture, dma_map_single a DMA coherent address will be catched > by a BUG_ON(). > > Signed-off-by: Jason Wang > Signed-off-by: Jean-François Moine > Cc: sta...@kernel.org > Signed-off-by: Mauro Carvalho Chehab > > I guess the cx231xx driver is trying to DMA-map buffers whose location > is not appropriate for DMA-mapping, because they are already in an DMA > coherent region. Is the fix just to add the same > URB_NO_TRANSFER_DMA_MAP to the urb->transfer_flags ? Or is it something > completely different ? Hi Thomas, I ran into the same issue on em28xx in the past (which is what those parts of cx231xx are based on). Yes, just adding URB_NO_TRANSFER_DMA_MAP should result in it starting to work. Please try that out, and assuming it works feel free to submit a patch which can be included upstream. Regards, 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
cx231xx: DMA problem on ARM
Hello, On an x86 platform, we have managed to use a Hauppauge USB Live 2 capture device with the cx231xx on a 3.0 kernel with the patch at [1]. Things work nicely. However, using a similar 3.0 kernel with the exact same device on an ARM platform (BeagleBoard-XM), starting a V4L application to capture the video immediately triggers the following BUG_ON in arch/arm/mm/dma-mapping.c: 429 void ___dma_single_cpu_to_dev(const void *kaddr, size_t size, 430 enum dma_data_direction dir) 431 { 432 unsigned long paddr; 433 434 BUG_ON(!virt_addr_valid(kaddr) || !virt_addr_valid(kaddr + size - 1)); This problem looks similar to the problem fixed on the gspca driver by: commit 882787ff8fdeb0be790547ee9b22b281095e95da Author: Jason Wang Date: Fri Sep 3 06:57:19 2010 -0300 V4L/DVB: gspca - main: Fix a crash of some webcams on ARM arch When plugging some webcams on ARM, the system crashes. This is because we alloc buffer for an urb through usb_buffer_alloc, the alloced buffer is already in DMA coherent region, so we should set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when we submit this urb, the hcd core will handle this address as an non-DMA address and call dma_map_single/sg to map it. On arm architecture, dma_map_single a DMA coherent address will be catched by a BUG_ON(). Signed-off-by: Jason Wang Signed-off-by: Jean-François Moine Cc: sta...@kernel.org Signed-off-by: Mauro Carvalho Chehab I guess the cx231xx driver is trying to DMA-map buffers whose location is not appropriate for DMA-mapping, because they are already in an DMA coherent region. Is the fix just to add the same URB_NO_TRANSFER_DMA_MAP to the urb->transfer_flags ? Or is it something completely different ? Thanks! Thomas [1] https://github.com/torvalds/linux/commit/992299e84a4891275ea5924e30b66ce39a701e5e#drivers/media/video/cx231xx -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf & mmap for buf_size allocation
Hi, On Wednesday 21 September 2011 02:10 PM, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:30 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf& mmap for buf_size allocation The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap prevent requesting a larger size buffer than what is allocated at kernel boot during omap_vout_probe. The requested size is compared with vout->buffer_size, this isn't correct as vout->buffer_size is later set to the size requested in reqbuf. When the video device is opened the next time, this check will prevent us to allocate a buffer which is larger than what we requested the last time. Don't use vout->buffer_size, always check with the parameters video1_bufsize or video2_bufsize. Signed-off-by: Archit Taneja --- drivers/media/video/omap/omap_vout.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 95daf98..e14c82b 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, u32 phy_addr = 0, virt_addr = 0; struct omap_vout_device *vout = q->priv_data; struct omapvideo_info *ovid =&vout->vid_info; + int vid_max_buf_size; if (!vout) return -EINVAL; + vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : + video2_bufsize; + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type) return -EINVAL; @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, video1_numbuffers : video2_numbuffers; /* Check the size of the buffer */ - if (*size> vout->buffer_size) { + if (*size> vid_max_buf_size) { Good catch !!! v4l2_err(&vout->vid_dev->v4l2_dev, "buffer allocation mismatch [%u] [%u]\n", *size, vout->buffer_size); @@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) unsigned long size = (vma->vm_end - vma->vm_start); struct omap_vout_device *vout = file->private_data; struct videobuf_queue *q =&vout->vbq; + int vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : + video2_bufsize; v4l2_dbg(1, debug,&vout->vid_dev->v4l2_dev, " %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n", __func__, @@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) return -EINVAL; } /* Check the size of the buffer */ - if (size> vout->buffer_size) { + if (size> vid_max_buf_size) { Don't you think in case of mmap we should still check for the vout->buffer_size, since this is the size user has requested in req_buf. Ah, you are right, the check for the maximum size should only be in the reqbuf path. vout->buffer_size would have been updated correctly at time of mmap. I'll change this back to vout->buffer_size. Thanks, Archit Thanks, Vaibhav v4l2_err(&vout->vid_dev->v4l2_dev, "insufficient memory [%lu] [%u]\n", size, vout->buffer_size); -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
Hi, On Wednesday 21 September 2011 03:35 PM, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:31 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr Currently, there is a lot of redundant code is between DPI and VENC panels, this can be made common by moving out field/interlace specific code to a separate function called omapvid_handle_interlace_display(). There is no functional change made. Signed-off-by: Archit Taneja --- drivers/media/video/omap/omap_vout.c | 172 - - 1 files changed, 82 insertions(+), 90 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index e14c82b..c5f2ea0 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct omap_vout_device *vout) return 0; } +static int omapvid_handle_interlace_display(struct omap_vout_device *vout, + unsigned int irqstatus, struct timeval timevalue) +{ + u32 fid; + + if (vout->first_int) { + vout->first_int = 0; + goto err; + } + + if (irqstatus& DISPC_IRQ_EVSYNC_ODD) + fid = 1; + else if (irqstatus& DISPC_IRQ_EVSYNC_EVEN) + fid = 0; + else + goto err; + + vout->field_id ^= 1; + if (fid != vout->field_id) { + /* reset field ID */ + vout->field_id = 0; [Hiremath, Vaibhav] You should check whether fid == 0 before resetting it. + } else if (0 == fid) { [Hiremath, Vaibhav] This is not matching with the original code, probably I have to be more careful here. I need to spend more time here... If you do a dry run of it you'll see that it does the same thing functionally. If fid was 1, vout->field_id would have been 0 anyway. So the check for fid == 0 looked a bit redundant to me. However, if you think that doing this makes the code less clear, we can surely keep this check. + if (vout->cur_frm == vout->next_frm) + goto err; + + vout->cur_frm->ts = timevalue; + vout->cur_frm->state = VIDEOBUF_DONE; + wake_up_interruptible(&vout->cur_frm->done); + vout->cur_frm = vout->next_frm; + } else { + if (list_empty(&vout->dma_queue) || + (vout->cur_frm != vout->next_frm)) + goto err; + } + + return vout->field_id; +err: + return 0; +} + static void omap_vout_isr(void *arg, unsigned int irqstatus) { - int ret; - u32 addr, fid; + int ret, fid; + u32 addr; struct omap_overlay *ovl; struct timeval timevalue; struct omapvideo_info *ovid; @@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) spin_lock(&vout->vbq_lock); do_gettimeofday(&timevalue); - if (cur_display->type != OMAP_DISPLAY_TYPE_VENC) { - switch (cur_display->type) { - case OMAP_DISPLAY_TYPE_DPI: - if (!(irqstatus& (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) - goto vout_isr_err; - break; - case OMAP_DISPLAY_TYPE_HDMI: - if (!(irqstatus& DISPC_IRQ_EVSYNC_EVEN)) - goto vout_isr_err; - break; - default: + switch (cur_display->type) { + case OMAP_DISPLAY_TYPE_DPI: + if (!(irqstatus& (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) goto vout_isr_err; - } - if (!vout->first_int&& (vout->cur_frm != vout->next_frm)) { - vout->cur_frm->ts = timevalue; - vout->cur_frm->state = VIDEOBUF_DONE; - wake_up_interruptible(&vout->cur_frm->done); - vout->cur_frm = vout->next_frm; - } - vout->first_int = 0; - if (list_empty(&vout->dma_queue)) + break; + case OMAP_DISPLAY_TYPE_VENC: + fid = omapvid_handle_interlace_display(vout, irqstatus, + timevalue); + if (!fid) goto vout_isr_err; [Hiremath, Vaibhav] Have you tested TV out functionality? I haven't checked it yet to be totally honest. Its hard to find a VENC TV! I wanted to anyway get some kind of Ack from you before starting to test this. Since you also feel that this clean up is needed, I'll start testing this out :) + break; + case OMAP_DISPLAY_TYPE_HDMI: +
Re: [PATCH v1 3/3] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
Hi Sakari, On 09/21/2011 12:10 AM, Sakari Ailus wrote: > On Tue, Sep 20, 2011 at 01:58:59PM +0200, Sylwester Nawrocki wrote: >> This driver exposes preview mode operation of the S5K6AAFX sensor with >> embedded SoC ISP. It uses one of the five user predefined configuration >> register sets. There is yet no support for capture (snapshot) operation. >> Following controls are supported: >> manual/auto exposure and gain, power line frequency (anti-flicker), >> saturation, sharpness, brightness, contrast, white balance temperature, >> color effects. horizontal/vertical image flip, frame interval. > > Thanks for the patch, Sylwester! > > [clip] >> +v4l2_ctrl_new_std_menu(hdl, ops, V4L2_CID_POWER_LINE_FREQUENCY, >> + V4L2_CID_POWER_LINE_FREQUENCY_AUTO, 0, >> + V4L2_CID_POWER_LINE_FREQUENCY_50HZ); >> + >> +v4l2_ctrl_new_std_menu(hdl, ops, V4L2_CID_COLORFX, >> + V4L2_COLORFX_SKETCH, 0x3D0, V4L2_COLORFX_NONE); > > New items may be added to standard menus so you should mask out also > undefined bits. Say, ~0x42f (hope I got that right). Sure, that's an important detail. ~0x42 look like the right value. Thanks for pointing this out. > > Youd also don't need to check for invalid menu ids; the control framework > does this for you. Right, good catch. I'll modify accordingly. > >> +v4l2_ctrl_new_std(hdl, ops, V4L2_CID_WHITE_BALANCE_TEMPERATURE, >> + 0, 256, 1, 0); >> + >> +v4l2_ctrl_new_std(hdl, ops, V4L2_CID_SATURATION, -127, 127, 1, 0); >> +v4l2_ctrl_new_std(hdl, ops, V4L2_CID_SHARPNESS, -127, 127, 1, 0); >> +v4l2_ctrl_new_std(hdl, ops, V4L2_CID_BRIGHTNESS, -127, 127, 1, 0); >> +v4l2_ctrl_new_std(hdl, ops, V4L2_CID_CONTRAST, -127, 127, 1, 0); >> + >> +s5k6aa->sd.ctrl_handler = hdl; > > Shoudln't this assignment be done after checking for the error? Indeed, seems much more appropriate. > >> +if (hdl->error) { >> +ret = hdl->error; >> +v4l2_ctrl_handler_free(hdl); >> +} >> +return ret; -- Thanks! Sylwester -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
> -Original Message- > From: Taneja, Archit > Sent: Friday, September 16, 2011 3:31 PM > To: Hiremath, Vaibhav > Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux- > me...@vger.kernel.org; Taneja, Archit > Subject: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code > from omap_vout_isr > > Currently, there is a lot of redundant code is between DPI and VENC panels, > this > can be made common by moving out field/interlace specific code to a > separate > function called omapvid_handle_interlace_display(). There is no functional > change made. > > Signed-off-by: Archit Taneja > --- > drivers/media/video/omap/omap_vout.c | 172 - > - > 1 files changed, 82 insertions(+), 90 deletions(-) > > diff --git a/drivers/media/video/omap/omap_vout.c > b/drivers/media/video/omap/omap_vout.c > index e14c82b..c5f2ea0 100644 > --- a/drivers/media/video/omap/omap_vout.c > +++ b/drivers/media/video/omap/omap_vout.c > @@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct > omap_vout_device *vout) > return 0; > } > > +static int omapvid_handle_interlace_display(struct omap_vout_device *vout, > + unsigned int irqstatus, struct timeval timevalue) > +{ > + u32 fid; > + > + if (vout->first_int) { > + vout->first_int = 0; > + goto err; > + } > + > + if (irqstatus & DISPC_IRQ_EVSYNC_ODD) > + fid = 1; > + else if (irqstatus & DISPC_IRQ_EVSYNC_EVEN) > + fid = 0; > + else > + goto err; > + > + vout->field_id ^= 1; > + if (fid != vout->field_id) { > + /* reset field ID */ > + vout->field_id = 0; [Hiremath, Vaibhav] You should check whether fid == 0 before resetting it. > + } else if (0 == fid) { [Hiremath, Vaibhav] This is not matching with the original code, probably I have to be more careful here. I need to spend more time here... > + if (vout->cur_frm == vout->next_frm) > + goto err; > + > + vout->cur_frm->ts = timevalue; > + vout->cur_frm->state = VIDEOBUF_DONE; > + wake_up_interruptible(&vout->cur_frm->done); > + vout->cur_frm = vout->next_frm; > + } else { > + if (list_empty(&vout->dma_queue) || > + (vout->cur_frm != vout->next_frm)) > + goto err; > + } > + > + return vout->field_id; > +err: > + return 0; > +} > + > static void omap_vout_isr(void *arg, unsigned int irqstatus) > { > - int ret; > - u32 addr, fid; > + int ret, fid; > + u32 addr; > struct omap_overlay *ovl; > struct timeval timevalue; > struct omapvideo_info *ovid; > @@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int > irqstatus) > spin_lock(&vout->vbq_lock); > do_gettimeofday(&timevalue); > > - if (cur_display->type != OMAP_DISPLAY_TYPE_VENC) { > - switch (cur_display->type) { > - case OMAP_DISPLAY_TYPE_DPI: > - if (!(irqstatus & (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) > - goto vout_isr_err; > - break; > - case OMAP_DISPLAY_TYPE_HDMI: > - if (!(irqstatus & DISPC_IRQ_EVSYNC_EVEN)) > - goto vout_isr_err; > - break; > - default: > + switch (cur_display->type) { > + case OMAP_DISPLAY_TYPE_DPI: > + if (!(irqstatus & (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) > goto vout_isr_err; > - } > - if (!vout->first_int && (vout->cur_frm != vout->next_frm)) { > - vout->cur_frm->ts = timevalue; > - vout->cur_frm->state = VIDEOBUF_DONE; > - wake_up_interruptible(&vout->cur_frm->done); > - vout->cur_frm = vout->next_frm; > - } > - vout->first_int = 0; > - if (list_empty(&vout->dma_queue)) > + break; > + case OMAP_DISPLAY_TYPE_VENC: > + fid = omapvid_handle_interlace_display(vout, irqstatus, > + timevalue); > + if (!fid) > goto vout_isr_err; [Hiremath, Vaibhav] Have you tested TV out functionality? > + break; > + case OMAP_DISPLAY_TYPE_HDMI: > + if (!(irqstatus & DISPC_IRQ_EVSYNC_EVEN)) > + goto vout_isr_err; > + break; > + default: > + goto vout_isr_err; > + } > > - vout->next_frm = list_entry(vout->dma_queue.next, > - struct videobuf_buffer, queue); > - list_del(&vout->next_frm->queue); > - > - vout->next_frm->state = VIDEOBUF_ACTIVE; > - > - addr = (unsigned long) vout->queued_buf_addr[vout->next_frm- > >i] > - +
frame grabber INT-1461 under Linux
Hi, dmesg has asked me to mail you. Here's the essential part of the message: [1.806495] Linux video capture interface: v2.00 [1.806607] bttv: driver version 0.9.18 loaded [1.806613] bttv: using 8 buffers with 2080k (520 pages) each for capture [1.806669] bttv: Bt8xx card found (0). [1.806692] bttv :01:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [1.806710] bttv0: Bt878 (rev 17) at :01:01.0, irq: 17, latency: 64, mmio: 0xfdfff000 [1.806753] bttv0: subsystem: 1766: (UNKNOWN) [1.806758] please mail id, board name and the correct card= insmod option to linux-media@vger.kernel.org [1.806766] bttv0: using: GrandTec Multi Capture Card (Bt878) [card=77,insmod option] [1.806839] bttv0: gpio: en=, out= in=00e31fff [init] [1.807003] bttv0: tuner absent [1.807086] bttv0: registered device video0 [1.807179] bttv0: registered device vbi0 [1.807204] bttv0: PLL: 28636363 => 35468950 .. ok [1.847974] bt878: AUDIO driver version 0.0.0 loaded I use bttv.card=77 kernel parameter. With no parameter, the frame grabber works, but in a strange way. Info about my frame grabber: INT-1461 PC/104-Plus Frame Grabber w/ 4 CVBS Inputs & 24 DIO The INT-1461 video frame grabber is a low-cost, high-performance solution for capturing analog broadcast signals across the PCI bus. Based around the Conexant FusionTM 878A video decoder, this compact PC/104-Plus form factor board supports NTSC, PAL, and SECAM video formats at capture resolutions of up to 768 x 576 pixels and 30 frames per second. It can also sub-sample, scale, crop, and clip images at various resolutions and frame rates. You can easily find more info on the net. Thank you for writing and supporting media drivers. Regards, -- .. Pavel Andris | tel: +421 2 5941 1167 Institute of Informatics | fax: +421 2 5477 3271 Slovak Academy of Sciences | Dubravska cesta 9 | e-mail: utrra...@savba.sk SK - 845 07 Bratislava | Slovak republic| .. "One hundred thousand lemmings cannot be wrong." Graffiti .. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats
Hi Deepthy, On Wednesday 21 September 2011 07:32:44 Ravi, Deepthy wrote: > On Wednesday, September 21, 2011 4:56 AM Laurent Pinchart wrote: > > On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote: > >> Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE > >> register for UYVY8_2X8 and YUYV8_2X8 formats. > >> > >> Signed-off-by: Deepthy Ravi > >> --- > >> > >> drivers/media/video/omap3isp/ispccdc.c | 11 --- > >> 1 files changed, 8 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/media/video/omap3isp/ispccdc.c > >> b/drivers/media/video/omap3isp/ispccdc.c index 418ba65..1dcf180 100644 > >> --- a/drivers/media/video/omap3isp/ispccdc.c > >> +++ b/drivers/media/video/omap3isp/ispccdc.c > >> @@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct > >> isp_ccdc_device > >> *ccdc, > >> > >> syn_mode &= ~ISPCCDC_SYN_MODE_INPMOD_MASK; > >> if (format->code == V4L2_MBUS_FMT_YUYV8_2X8 || > >> > >> - format->code == V4L2_MBUS_FMT_UYVY8_2X8) > >> - syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8; > >> + format->code == V4L2_MBUS_FMT_UYVY8_2X8){ > >> + if (pdata && pdata->bt656) > >> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8; > >> + else > >> + syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16; > >> + } > >> > >> else if (format->code == V4L2_MBUS_FMT_YUYV8_1X16 || > >> > >>format->code == V4L2_MBUS_FMT_UYVY8_1X16) > >> > >> syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16; > >> > >> @@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device > >> *ccdc) syn_mode &= ~ISPCCDC_SYN_MODE_SDR2RSZ; > >> > >> /* Use PACK8 mode for 1byte per pixel formats. */ > >> > >> - if (omap3isp_video_format_info(format->code)->width <= 8) > >> + if ((omap3isp_video_format_info(format->code)->width <= 8) && > >> + (omap3isp_video_format_info(format->code)->bpp <= > >> 8)) > > > > I'm not sure to follow you. This will clear the PACK8 bit for the > > YUYV8_2X8 formats. Those formats are 8 bits wide, shouldn't PACK8 be set > > to store samples on 8 bits instead of 16 bits ? > > > > Is this patch intended to support YUYV8_2X8 sensors in non BT.656 mode > > with the bridge enabled ? In that case, what would you think about setting > > the CCDC input format to YUYV8_1X16 instead ? This would better reflect > > the reality, as the bridge converts YUYV8_2X8 to YUYV8_1X16, and the CCDC > > is then fed with YUYV8_1X16. > > Yes this is intended for YUYV8_2X8 sensors in non BT.656 with 8 to 16 bit > bridge enabled. So the data has to be stored as 16 bits per sample. Thats > why PACK8 is cleared . I am not sure about using YUYV8_1X16. My original idea when I wrote the YV support patches was to implement this use case with YUYV8_2X8 at the sensor output and YUYV8_1X16 at the CCDC input. The ISP driver could then enable the bridge automatically. I'm not sure if that's the best solution though, it might be confusing for the users. What I would like to keep, however, is the idea of enabling the bridge automatically. Sakari, any opinion on this ? > >> syn_mode |= ISPCCDC_SYN_MODE_PACK8; > >> else > >> syn_mode &= ~ISPCCDC_SYN_MODE_PACK8; -- 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 1/5] [media]: OMAP_VOUT: Fix check in reqbuf & mmap for buf_size allocation
> -Original Message- > From: Taneja, Archit > Sent: Friday, September 16, 2011 3:30 PM > To: Hiremath, Vaibhav > Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux- > me...@vger.kernel.org; Taneja, Archit > Subject: [PATCH 1/5] [media]: OMAP_VOUT: Fix check in reqbuf & mmap for > buf_size allocation > > The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf and mmap > prevent > requesting a larger size buffer than what is allocated at kernel boot > during > omap_vout_probe. > > The requested size is compared with vout->buffer_size, this isn't correct > as > vout->buffer_size is later set to the size requested in reqbuf. When the > video > device is opened the next time, this check will prevent us to allocate a > buffer > which is larger than what we requested the last time. > > Don't use vout->buffer_size, always check with the parameters > video1_bufsize > or video2_bufsize. > > Signed-off-by: Archit Taneja > --- > drivers/media/video/omap/omap_vout.c | 10 -- > 1 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/video/omap/omap_vout.c > b/drivers/media/video/omap/omap_vout.c > index 95daf98..e14c82b 100644 > --- a/drivers/media/video/omap/omap_vout.c > +++ b/drivers/media/video/omap/omap_vout.c > @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct > videobuf_queue *q, unsigned int *count, > u32 phy_addr = 0, virt_addr = 0; > struct omap_vout_device *vout = q->priv_data; > struct omapvideo_info *ovid = &vout->vid_info; > + int vid_max_buf_size; > > if (!vout) > return -EINVAL; > > + vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : > + video2_bufsize; > + > if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type) > return -EINVAL; > > @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct > videobuf_queue *q, unsigned int *count, > video1_numbuffers : video2_numbuffers; > > /* Check the size of the buffer */ > - if (*size > vout->buffer_size) { > + if (*size > vid_max_buf_size) { Good catch !!! > v4l2_err(&vout->vid_dev->v4l2_dev, > "buffer allocation mismatch [%u] [%u]\n", > *size, vout->buffer_size); > @@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct > vm_area_struct *vma) > unsigned long size = (vma->vm_end - vma->vm_start); > struct omap_vout_device *vout = file->private_data; > struct videobuf_queue *q = &vout->vbq; > + int vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : > + video2_bufsize; > > v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, > " %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n", __func__, > @@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct > vm_area_struct *vma) > return -EINVAL; > } > /* Check the size of the buffer */ > - if (size > vout->buffer_size) { > + if (size > vid_max_buf_size) { Don't you think in case of mmap we should still check for the vout->buffer_size, since this is the size user has requested in req_buf. Thanks, Vaibhav > v4l2_err(&vout->vid_dev->v4l2_dev, > "insufficient memory [%lu] [%u]\n", > size, vout->buffer_size); > -- > 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] v4l: Extend V4L2_CID_COLORFX control with AQUA effect
Hi Laurent, On 09/21/2011 12:23 AM, Laurent Pinchart wrote: > On Monday 19 September 2011 13:26:39 Sylwester Nawrocki wrote: >> On 09/19/2011 08:08 AM, Subash Patel wrote: >>> Hi Laurent, >>> >>> I am not representing Sylwester :), But with a similar sensor I use, Aqua >>> means cool tone which is Cb/Cr manipulations. >>> >>> On 09/19/2011 04:38 AM, Laurent Pinchart wrote: On Friday 16 September 2011 19:05:28 Sylwester Nawrocki wrote: > Add V4L2_COLORFX_AQUA image effect in the V4L2_CID_COLORFX menu. What's the aqua effect ? >> >> Aqua means cool tone, as Subash explained. It's somehow opposite to Sepia >> which is warm tone. I'll improve the commit description in the next patch >> version. >> I tried to make a table with short description of each color effect in the >> DocBook but it was taking me too long so I dropped it for a moment. >> >> I have attached an image presenting the color effects. Maybe it's worth >> to add something like this to the DocBook, or perhaps just the >> descriptions. > > Thanks for the information. I think it would indeed be useful to add > descriptions to the documentation. Sure, I'll try to find some time to complete this. And I wonder, what BLUE_SKY effect is ? I suspect it's very much same as the Aqua effect which is present in our sensor ISP. Does anyone know exactly ? Perhaps I could just use it instead of adding new menu entry. Regards, -- Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about USB interface index restriction in gspca
On Mon, 19 Sep 2011 22:13:12 +0200 Frank Schäfer wrote: > > So, if your webcam is in the 99.99% which use the interface 0, use > > gspca_dev_probe(), otherwise, YOU know the right interface, so, call > > gspca_dev_probe2(). > > Isn't it also possible that we don't know the right interface and it is > not interface 0 ? ;-) I hope that the interface does not change each time you unplug/replug the webcam :), but if different webcams with a same device ID may use different interfaces, you should have to develop specific code in the subdriver... -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
The USB device VID in Linux is difference with in Windows
hi, guys, I have a Hauppauge product, but it can't support on Linux, and I'd like have a try to compose a new driver for it. the product details info: - name: Hauppauge DMB-T MiniStick(it only use on HongKong and China) - VID: 2040 - PID: 5020 ... I got the above info from Win 7, but when I hot plug it into Linux, it can't enable but with these info: $ dmesg ... ... [406600.393164] usb 1-8: new high speed USB device using ehci_hcd and address 13 [406600.507446] usb 1-8: config 1 interface 0 altsetting 1 bulk endpoint 0x81 has invalid maxpacket 64 [406600.507454] usb 1-8: config 1 interface 0 altsetting 1 bulk endpoint 0x1 has invalid maxpacket 64 [406600.507459] usb 1-8: config 1 interface 0 altsetting 1 bulk endpoint 0x2 has invalid maxpacket 64 [406600.507464] usb 1-8: config 1 interface 0 altsetting 1 bulk endpoint 0x8A has invalid maxpacket 64 [406600.507687] usb 1-8: New USB device found, idVendor=3344, idProduct=5020 [406600.507692] usb 1-8: New USB device strings: Mfr=0, Product=0, SerialNumber=3 [406600.507695] usb 1-8: SerialNumber: 䥈児 yes, the idVendor is 3344, not 2040, but I'm sure it's 2040 in Windows, and the Hauppauge's vendor id is 2040, and it can't read out the SerialNumber. so I'm doubt the firmware in the product has some special data. I'm a newer to usb, can anyone know why? or what's the trouble with it? any comments are welcome. thanks, best Regards. Zhouping -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html