Re: [PATCH RFCv3 02/10] [media] videodev2.h: Remove the unused old V4L1 buffer types
On Sun April 21 2013 21:00:31 Mauro Carvalho Chehab wrote: > Those aren't used anywhere for a long time. Drop it. > > Signed-off-by: Mauro Carvalho Chehab Acked-by: Hans Verkuil > --- > include/uapi/linux/videodev2.h | 21 - > 1 file changed, 21 deletions(-) > > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h > index 4aa24c3..5d8ee92 100644 > --- a/include/uapi/linux/videodev2.h > +++ b/include/uapi/linux/videodev2.h > @@ -72,27 +72,6 @@ > #define VIDEO_MAX_FRAME 32 > #define VIDEO_MAX_PLANES 8 > > -#ifndef __KERNEL__ > - > -/* These defines are V4L1 specific and should not be used with the V4L2 API! > - They will be removed from this header in the future. */ > - > -#define VID_TYPE_CAPTURE 1 /* Can capture */ > -#define VID_TYPE_TUNER 2 /* Can tune */ > -#define VID_TYPE_TELETEXT4 /* Does teletext */ > -#define VID_TYPE_OVERLAY 8 /* Overlay onto frame buffer */ > -#define VID_TYPE_CHROMAKEY 16 /* Overlay by chromakey */ > -#define VID_TYPE_CLIPPING32 /* Can clip */ > -#define VID_TYPE_FRAMERAM64 /* Uses the frame buffer memory */ > -#define VID_TYPE_SCALES 128 /* Scalable */ > -#define VID_TYPE_MONOCHROME 256 /* Monochrome only */ > -#define VID_TYPE_SUBCAPTURE 512 /* Can capture subareas of the image */ > -#define VID_TYPE_MPEG_DECODER1024/* Can decode MPEG streams */ > -#define VID_TYPE_MPEG_ENCODER2048/* Can encode MPEG streams */ > -#define VID_TYPE_MJPEG_DECODER 4096/* Can decode MJPEG streams */ > -#define VID_TYPE_MJPEG_ENCODER 8192/* Can encode MJPEG streams */ > -#endif > - > /* > * M I S C E L L A N E O U S > */ > -- 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 RFCv3 01/10] [media] Add initial SDR support at V4L2 API
On Sun April 21 2013 21:00:30 Mauro Carvalho Chehab wrote: > Adds the basic API bits for Software Digital Radio (SDR) at > the V4L2 API. > > A normal radio device is actually radio and hardware demod. As the demod > is in hardware, several things that are required for the demodulate the > signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to > the device and aren't part of the API. > > SDR radio, on the other hand, requires that every control needed by the > tuner to be exposed on userspace, as userspace needs to adjust the > software decoder to match it. > > As proposed at: > > http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/63123 > > Add a new device node for SDR devices, and a VIDIOC_QUERYCAP > capability (V4L2_CAP_SDR) to indicate that a devnode is SDR. > > The stream output format also needs to be different, as it should > output sample data, instead of video streams. As we need to document > SDR, add one initial format there that will be later be used. > > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/DocBook/media/v4l/common.xml | 35 ++ > Documentation/DocBook/media/v4l/pixfmt.xml | 41 > ++ > Documentation/DocBook/media/v4l/v4l2.xml | 1 + > .../DocBook/media/v4l/vidioc-querycap.xml | 7 > drivers/media/v4l2-core/v4l2-dev.c | 3 ++ > include/media/v4l2-dev.h | 3 +- > include/uapi/linux/videodev2.h | 11 ++ > 7 files changed, 100 insertions(+), 1 deletion(-) > > diff --git a/Documentation/DocBook/media/v4l/common.xml > b/Documentation/DocBook/media/v4l/common.xml > index 1ddf354..f59c67d 100644 > --- a/Documentation/DocBook/media/v4l/common.xml > +++ b/Documentation/DocBook/media/v4l/common.xml > @@ -513,6 +513,41 @@ the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; > ioctl when the > device has one or more modulators. > > > + > +Software Digital Radio (SDR) Tuners and Modulators > + > +Those devices are special types of Radio devices that don't s/don't/do not/ 'don't' is a bit too informal IMHO. > +have any analog demodulator. Instead, it samples the radio IF or baseband > +and sends the samples for userspace to demodulate. s/for/to/ > + 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 v2 1/5] V4L2: I2C: ML86V7667 video decoder driver
On Sun April 21 2013 20:40:30 Sergei Shtylyov wrote: > From: Vladimir Barinov > > Add OKI Semiconductor ML86V7667 video decoder driver. > > Signed-off-by: Vladimir Barinov > [Sergei: added v4l2_device_unregister_subdev() call to the error cleanup path > of > ml86v7667_probe(); some cleanup.] > Signed-off-by: Sergei Shtylyov > > --- > Changes since the original posting: > - fixed ACCC_CHROMA_CB_MASK; > - got rid from the autodetection feature; > - removed querystd() method calls from other methods; > - removed deprecated g_chip_ident() method. > > drivers/media/i2c/Kconfig |9 > drivers/media/i2c/Makefile|1 > drivers/media/i2c/ml86v7667.c | 473 > ++ > 3 files changed, 483 insertions(+) > > Index: renesas/drivers/media/i2c/Kconfig > === > --- renesas.orig/drivers/media/i2c/Kconfig > +++ renesas/drivers/media/i2c/Kconfig > @@ -227,6 +227,15 @@ config VIDEO_KS0127 > To compile this driver as a module, choose M here: the > module will be called ks0127. > > +config VIDEO_ML86V7667 > + tristate "OKI ML86V7667 video decoder" > + depends on VIDEO_V4L2 && I2C > + ---help--- > + Support for the OKI Semiconductor ML86V7667 video decoder. > + > + To compile this driver as a module, choose M here: the > + module will be called ml86v7667. > + > config VIDEO_SAA7110 > tristate "Philips SAA7110 video decoder" > depends on VIDEO_V4L2 && I2C > Index: renesas/drivers/media/i2c/Makefile > === > --- renesas.orig/drivers/media/i2c/Makefile > +++ renesas/drivers/media/i2c/Makefile > @@ -64,3 +64,4 @@ obj-$(CONFIG_VIDEO_AS3645A) += as3645a.o > obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o > obj-$(CONFIG_VIDEO_AK881X) += ak881x.o > obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o > +obj-$(CONFIG_VIDEO_ML86V7667)+= ml86v7667.o > Index: renesas/drivers/media/i2c/ml86v7667.c > === > --- /dev/null > +++ renesas/drivers/media/i2c/ml86v7667.c > @@ -0,0 +1,473 @@ > +/* > + * OKI Semiconductor ML86V7667 video decoder driver > + * > + * Author: Vladimir Barinov > + * Copyright (C) 2013 Cogent Embedded, Inc. > + * Copyright (C) 2013 Renesas Solutions Corp. > + * > + * 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 This include should be removed as well. > +#include > +#include > +#include > +#include > + > +#define DRV_NAME "ml86v7667" > + > +/* Subaddresses */ > +#define MRA_REG 0x00 /* Mode Register A */ > +#define MRC_REG 0x02 /* Mode Register C */ > +#define LUMC_REG 0x0C /* Luminance Control */ > +#define CLC_REG 0x10 /* Contrast level control */ > +#define SSEPL_REG0x11 /* Sync separation level */ > +#define CHRCA_REG0x12 /* Chrominance Control A */ > +#define ACCC_REG 0x14 /* ACC Loop filter & Chrominance control */ > +#define ACCRC_REG0x15 /* ACC Reference level control */ > +#define HUE_REG 0x16 /* Hue control */ > +#define ADC2_REG 0x1F /* ADC Register 2 */ > +#define PLLR1_REG0x20 /* PLL Register 1 */ > +#define STATUS_REG 0x2C /* STATUS Register */ > + > +/* Mode Register A register bits */ > +#define MRA_OUTPUT_MODE_MASK (3 << 6) > +#define MRA_ITUR_BT601 (1 << 6) > +#define MRA_ITUR_BT656 (0 << 6) > +#define MRA_INPUT_MODE_MASK (7 << 3) > +#define MRA_PAL_BT601(4 << 3) > +#define MRA_NTSC_BT601 (0 << 3) > +#define MRA_REGISTER_MODE(1 << 0) > + > +/* Mode Register C register bits */ > +#define MRC_AUTOSELECT (1 << 7) > + > +/* Luminance Control register bits */ > +#define LUMC_ONOFF_SHIFT 7 > +#define LUMC_ONOFF_MASK (1 << 7) > + > +/* Contrast level control register bits */ > +#define CLC_CONTRAST_ONOFF (1 << 7) > +#define CLC_CONTRAST_MASK0x0F > + > +/* Sync separation level register bits */ > +#define SSEPL_LUMINANCE_ONOFF(1 << 7) > +#define SSEPL_LUMINANCE_MASK 0x7F > + > +/* Chrominance Control A register bits */ > +#define CHRCA_MODE_SHIFT 6 > +#define CHRCA_MODE_MASK (1 << 6) > + > +/* ACC Loop filter & Chrominance control register bits */ > +#define ACCC_CHROMA_CR_SHIFT 3 > +#define ACCC_CHROMA_CR_MASK (7 << 3) > +#define ACCC_CHROMA_CB_SHIFT 0 > +#define ACCC_CHROMA_CB_MASK (7 << 0) > + > +/* ACC Reference level control register bits */ > +#define ACCRC_CHROMA_MASK0xfc
RE: [PATCH v3] drm/exynos: enable FIMD clocks
Hi, Mr. Vikas
Please fix the below typos Viresh pointed out and my comments.
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: Monday, April 01, 2013 5:51 PM
> To: Vikas Sajjan
> Cc: dri-de...@lists.freedesktop.org; linux-samsung-...@vger.kernel.org;
> jy0922.s...@samsung.com; inki@samsung.com; kgene@samsung.com;
> linaro-ker...@lists.linaro.org; linux-media@vger.kernel.org
> Subject: Re: [PATCH v3] drm/exynos: enable FIMD clocks
>
> On 1 April 2013 14:13, Vikas Sajjan wrote:
> > While migrating to common clock framework (CCF), found that the FIMD
> clocks
>
> s/found/we found/
>
> > were pulled down by the CCF.
> > If CCF finds any clock(s) which has NOT been claimed by any of the
> > drivers, then such clock(s) are PULLed low by CCF.
> >
> > By calling clk_prepare_enable() for FIMD clocks fixes the issue.
>
> s/By calling/Calling/
>
> and
>
> s/the/this
>
> > this patch also replaces clk_disable() with clk_disable_unprepare()
>
> s/this/This
>
> > during exit.
>
> Sorry but your log doesn't say what you are doing. You are just adding
> relevant calls to clk_prepare/unprepare() before calling
> clk_enable/disable.
>
> > Signed-off-by: Vikas Sajjan
> > ---
> > Changes since v2:
> > - moved clk_prepare_enable() and clk_disable_unprepare() from
> > fimd_probe() to fimd_clock() as suggested by Inki Dae
>
> > Changes since v1:
> > - added error checking for clk_prepare_enable() and also
replaced
> > clk_disable() with clk_disable_unprepare() during exit.
> > ---
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > index 9537761..f2400c8 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -799,18 +799,18 @@ static int fimd_clock(struct fimd_context *ctx,
> bool enable)
> > if (enable) {
> > int ret;
> >
> > - ret = clk_enable(ctx->bus_clk);
> > + ret = clk_prepare_enable(ctx->bus_clk);
> > if (ret < 0)
> > return ret;
> >
> > - ret = clk_enable(ctx->lcd_clk);
> > + ret = clk_prepare_enable(ctx->lcd_clk);
> > if (ret < 0) {
> > - clk_disable(ctx->bus_clk);
> > + clk_disable_unprepare(ctx->bus_clk);
> > return ret;
> > }
> > } else {
> > - clk_disable(ctx->lcd_clk);
> > - clk_disable(ctx->bus_clk);
> > + clk_disable_unprepare(ctx->lcd_clk);
> > + clk_disable_unprepare(ctx->bus_clk);
> > }
> >
> > return 0;
> > @@ -981,8 +981,8 @@ static int fimd_remove(struct platform_device *pdev)
> > if (ctx->suspended)
> > goto out;
> >
> > - clk_disable(ctx->lcd_clk);
> > - clk_disable(ctx->bus_clk);
> > + clk_disable_unprepare(ctx->lcd_clk);
> > + clk_disable_unprepare(ctx->bus_clk);
Just remove the above codes. It seems that clk_disable(also
clk_disable_unprepare) isn't needed because it will be done by
pm_runtime_put_sync and please re-post it(probably patch v5??)
Thanks,
Inki Dae
>
> You are doing things at the right place but i have a suggestion. Are you
> doing
> anything in your clk_prepare() atleast for this device? Probably not.
>
> If not, then its better to call clk_prepare/unprepare only once at
> probe/remove
> and keep clk_enable/disable calls as is.
>
> --
> viresh
--
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 RFC] media: videobuf2: fix the length check for mmap
On Fri, Apr 19, 2013 at 4:48 PM, Mauro Carvalho Chehab
wrote:
> Em Fri, 19 Apr 2013 15:16:56 +0530
> Prabhakar lad escreveu:
>
>> From: Lad, Prabhakar
>>
>> From commit 068a0df76023926af958a336a78bef60468d2033
>> "[media] media: vb2: add length check for mmap"
>> patch verifies that the mmap() size requested by userspace
>> doesn't exceed the buffer size.
>>
>> As the mmap() size is rounded up to the next page boundary
>> the check will fail for buffer sizes that are not multiple
>> of the page size.
>>
>> This patch fixes the check by aligning the buffer size to page
>> size during the check. Alongside fixes the vmalloc allocator
>> to round up the size.
>>
>> Signed-off-by: Lad, Prabhakar
>> Cc: Laurent Pinchart
>> Cc: Marek Szyprowski
>> Cc: Seung-Woo Kim
>> Cc: Hans Verkuil
>> Cc: Mauro Carvalho Chehab
>> ---
>> drivers/media/v4l2-core/videobuf2-core.c|2 +-
>> drivers/media/v4l2-core/videobuf2-vmalloc.c |2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
>> b/drivers/media/v4l2-core/videobuf2-core.c
>> index 58c1744..223fcd4 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> @@ -1886,7 +1886,7 @@ int vb2_mmap(struct vb2_queue *q, struct
>> vm_area_struct *vma)
>>
>> vb = q->bufs[buffer];
>>
>> - if (vb->v4l2_planes[plane].length < (vma->vm_end - vma->vm_start)) {
>> + if (PAGE_ALIGN(vb->v4l2_planes[plane].length) < (vma->vm_end -
>> vma->vm_start)) {
>> dprintk(1, "Invalid length\n");
>> return -EINVAL;
>> }
>
> That is tricky, as it assumes that vb->v4l2_planes[plane].length was round
> up to PAGE_SIZE at each memops driver, but the vb2 core doesn't enforce it.
>
> IMO, it would be cleaner to round vb->v4l2_planes[plane].length up
> at VB2 core, before calling the memops alloc functions at the drivers.
>
> Also, VB2 is already complex enough to put it there without proper
> comments (and there's a minor codingstyle issue there: line is bigger
> than 80 cols).
>
>> diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
>> b/drivers/media/v4l2-core/videobuf2-vmalloc.c
>> index 313d977..bf3b95c 100644
>> --- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
>> +++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
>> @@ -44,7 +44,7 @@ static void *vb2_vmalloc_alloc(void *alloc_ctx, unsigned
>> long size, gfp_t gfp_fl
>> return NULL;
>>
>> buf->size = size;
>> - buf->vaddr = vmalloc_user(buf->size);
>> + buf->vaddr = vmalloc_user(PAGE_ALIGN(buf->size));
>
> See? You needed to put an alignment here as well, not because vmalloc
> needs it, but because this is needed by VB2 core.
>
> Also, on the other drivers, buf->size is stored page aligned, while
> here, you're doing different, without any documented reason for doing
> that, instead of doing the same as on the other memops drivers.
>
> That mistake reflects, for example, when the driver prints the failure:
>
> if (!buf->vaddr) {
> pr_debug("vmalloc of size %ld failed\n", buf->size);
>
> as it will show a different size than what you actually required.
> As those memory starving errors can also produce a dump at the mm
> core, the size there won't match the size on the above printed message.
>
> Also, it is a very bad idea to delegate the core's requirement of
> do page alignment from the core to the memops drivers, as other
> patches may change the logic there, or a new memops could be added,
> and the same problem will hit again (and unnoticed, as the check
> routine do page alignments).
>
>> buf->handler.refcount = &buf->refcount;
>> buf->handler.put = vb2_vmalloc_put;
>> buf->handler.arg = buf;
>
> IMO, a cleaner version would be the following (untested) code.
>
> -
>
> [media] videobuf2: fix the length check for mmap
>
> Memory maps typically require that the buffer size to be page
> aligned. Currently, two memops drivers do such alignment
> internally, but videobuf-vmalloc doesn't.
>
> Also, the buffer overflow check doesn't take it into account.
>
> So, instead of doing it at each memops driver, enforce it at
> VB2 core.
>
> Reported-by: Prabhakar lad
> Signed-off-by: Mauro Carvalho Chehab
>
Reported-and-tested-by: Lad, Prabhakar
Regards,
--Prabhakar
--
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] drm/exynos: prepare FIMD clocks
On 21 April 2013 20:13, Tomasz Figa wrote:
> 3) after those two changes, all that remains is to fix compliance with
> Common Clock Framework, in other words:
>
> s/clk_enable/clk_prepare_enable/
>
> and
>
> s/clk_disable/clk_disable_unprepare/
We don't have to call clk_{un}prepare() everytime for your platform as
you aren't doing anything in it. So just call them once at probe/remove and
call clk_enable/disable everywhere else.
--
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 2/4] ARM: shmobile: r8a7779: add VIN support
On Sat, Apr 20, 2013 at 04:10:45AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 04/20/2013 02:32 AM, Sergei Shtylyov wrote:
>
> >From: Vladimir Barinov
> >
> >Add VIN clocks and platform devices for R8A7779 SoC; add function to register
> >the VIN platform devices.
> >
> >Signed-off-by: Vladimir Barinov
> >[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), renamed some
> >variables.]
> >Signed-off-by: Sergei Shtylyov
>
> [...]
>
> >Index: renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> >===
> >--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7779.c
> >+++ renesas/arch/arm/mach-shmobile/setup-r8a7779.c
> >@@ -559,6 +559,33 @@ static struct resource ether_resources[]
> > },
> > };
> >+#define R8A7779_VIN(idx) \
> >+static struct resource vin##idx##_resources[] = { \
> >+DEFINE_RES_MEM(0xffc5 + 0x1000 * (idx), 0x1000),\
> >+DEFINE_RES_IRQ(gic_iid(0x5f + (idx))), \
> >+}; \
> >+\
> >+static struct platform_device_info vin##idx##_info = { \
>
>Hm, probably should have marked this as '__initdata'... maybe
> the resources too.
That doesn't seem to be the case for other devices in
that or other shmobile files. Am I missing something
or should numerous other devices be updated?
>
> >+.parent = &platform_bus,\
> >+.name = "rcar_vin", \
> >+.id = idx, \
> >+.res= vin##idx##_resources, \
> >+.num_res= ARRAY_SIZE(vin##idx##_resources), \
> >+.dma_mask = DMA_BIT_MASK(32), \
> >+}
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OKI ML86V7667 driver and R8A7778/BOCK-W VIN support
On Sun, Apr 21, 2013 at 12:13:45AM +0400, Sergei Shtylyov wrote: > Hello. > >Here's the set of 4 patches against the Simon Horman's 'renesas.git' repo, > 'renesas-next-20130419' tag and my recent yet unapplied patches. Here we > add the OKI ML86V7667 video decoder driver and the VIN platform code working > on > the R8A7778/BOCK-W with ML86V7667. The driver patch also applies (with > offsets) > to Mauro's 'media_tree.git'... > > [1/5] V4L2: I2C: ML86V7667 video decoder driver > [2/5] sh-pfc: r8a7778: add VIN pin groups > [3/5] ARM: shmobile: r8a7778: add VIN support > [4/5] ARM: shmobile: BOCK-W: add VIN and ADV7180 support > [5/5] ARM: shmobile: BOCK-W: enable VIN and ADV7180 in defconfig Hi Sergei, it seems to me that patches 2 and 3 of the series could be applied to my tree without further delay. Would you like me to do that? -- 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 v9 00/12] Driver for Si476x series of chips
On Sun, Apr 21, 2013 at 2:33 AM, Mauro Carvalho Chehab wrote: > Em 21-04-2013 02:53, Andrey Smirnov escreveu: > >>> I applied all the MFD patches from this patchset (All 4 first ones), plus >>> a >>> follow up one for fixing the i2c related warning. >>> I also squashed the REGMAP_I2C dependency into patch #4. >>> It's all in mfd-next now, I'd appreciate if you could double check it's >>> all >>> fine. >> >> >> I checked out latest >> git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git and >> applied patches 5 - 10, 12. There doesn't seem to be any problems, so >> I think MFD part of the driver is good to go. >> >>> >>> Mauro will take the rest, we made sure there won't be any merge conflict >>> between our trees. >> >> >> Mauro, I am not sure if you need me to rebase any of the patches(it >> doesn't seem like you had a chance to make any further changes related >> to this driver in media tree), but if you do, ping me and I'll get on >> it. > > > No, I don't need. The V4L parts are on my experimental tree: > > http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/si476x > > I'll just merge it at the main tree or as a topic branch later today > or (more likely) tomorrow. > > Please ping me today if you find anything wrong there. It looks like everything is there(it's only one patch without mfd part, after all) except patch #12 https://patchwork.kernel.org/patch/2461631/ of this patchset which is a modified version of this guy https://patchwork-mail.kernel.org/patch/2420751/ Other than that I think everything is fine. > > Regards, > Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.10] Camera sensors patches
Hi Mauro, On Wednesday 17 April 2013 11:36:39 Mauro Carvalho Chehab wrote: > Em Wed, 17 Apr 2013 14:55:03 +0100 Mark Brown escreveu: > > On Tue, Apr 16, 2013 at 08:04:52PM +0200, Sylwester Nawrocki wrote: > > > It's probably more clean to provide a dummy clock/regulator in a host > > > driver (platform) than to add something in a sub-device drivers that > > > would resolve which resources should be requested and which not. > > > > Yes, that's the general theory for regulators at least - it allows the > > device driver to just trundle along and not worry about how the board is > > hooked up. The other issue it resolves that you didn't mention is that > > it avoids just ignoring errors which isn't terribly clever. > > I agree. Adding dummy clock/regulator at the host platform driver makes > sense, as the platform driver knows how the board is hooked up; keeping > it at the I2C driver doesn't make sense, so the code needs to be moved > away from it. > > Laurent, > > Could you please work on a patch moving that code to the host platform > driver? I think that Mark's point was that the regulators should be provided by platform code (in the generic sense, it could be DT on ARM, board code, or a USB bridge driver for a webcam that uses the mt9p031 sensor) and used by the sensor driver. That's exactly what my mt9p031 patch does. -- 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] [media] uvcvideo: quirk PROBE_DEF for Dell Studio / OmniVision webcam
Hi Kamal, On Wednesday 17 April 2013 09:38:43 Kamal Mostafa wrote: > On Wed, 2013-04-17 at 01:05 +0200, Laurent Pinchart wrote: > > Hi Kamal, > > > > On Monday 15 April 2013 12:01:51 Kamal Mostafa wrote: > > > BugLink: https://bugs.launchpad.net/bugs/1168430 > > > > > > OminiVision webcam 0x05a9:0x264a (in Dell Studio Hybrid 140g) needs the > > > same UVC_QUIRK_PROBE_DEF as other OmniVision model to be recognized > > > consistently. > > > > > > Signed-off-by: Kamal Mostafa > > > > Thank you for the patch. > > > > Acked-by: Laurent Pinchart > > > > I've taken the patch in my tree and will submit it upstream for v3.11. > > > > Could you please try to get the full 'lsusb -v -d 05a9:264a' output from > > the bug reporter ? > > Thanks Laurent. The requested lsusb dump is now available at > https://launchpadlibrarian.net/137633994/lsusb-omnivision-264a.txt Thank you for the information. -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [PATCH RFC] media: videobuf2: fix the length check for mmap
Hi Mauro,
On Friday 19 April 2013 08:18:01 Mauro Carvalho Chehab wrote:
> Em Fri, 19 Apr 2013 15:16:56 +0530 Prabhakar lad escreveu:
> > From: Lad, Prabhakar
> >
> > From commit 068a0df76023926af958a336a78bef60468d2033
> > "[media] media: vb2: add length check for mmap"
> > patch verifies that the mmap() size requested by userspace
> > doesn't exceed the buffer size.
> >
> > As the mmap() size is rounded up to the next page boundary
> > the check will fail for buffer sizes that are not multiple
> > of the page size.
> >
> > This patch fixes the check by aligning the buffer size to page
> > size during the check. Alongside fixes the vmalloc allocator
> > to round up the size.
> >
> > Signed-off-by: Lad, Prabhakar
> > Cc: Laurent Pinchart
> > Cc: Marek Szyprowski
> > Cc: Seung-Woo Kim
> > Cc: Hans Verkuil
> > Cc: Mauro Carvalho Chehab
> > ---
> >
> > drivers/media/v4l2-core/videobuf2-core.c|2 +-
> > drivers/media/v4l2-core/videobuf2-vmalloc.c |2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> > b/drivers/media/v4l2-core/videobuf2-core.c index 58c1744..223fcd4 100644
> > --- a/drivers/media/v4l2-core/videobuf2-core.c
> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
> > @@ -1886,7 +1886,7 @@ int vb2_mmap(struct vb2_queue *q, struct
> > vm_area_struct *vma)>
> > vb = q->bufs[buffer];
> >
> > - if (vb->v4l2_planes[plane].length < (vma->vm_end - vma->vm_start)) {
> > + if (PAGE_ALIGN(vb->v4l2_planes[plane].length) < (vma->vm_end -
> > vma->vm_start)) {>
> > dprintk(1, "Invalid length\n");
> > return -EINVAL;
> >
> > }
>
> That is tricky, as it assumes that vb->v4l2_planes[plane].length was round
> up to PAGE_SIZE at each memops driver, but the vb2 core doesn't enforce it.
>
> IMO, it would be cleaner to round vb->v4l2_planes[plane].length up
> at VB2 core, before calling the memops alloc functions at the drivers.
I don't think we should round vb->v4l2_planes[plane].length up. That variable
stores the buffer length required by the driver, and will be used to perform
size checks when importing a dmabuf buffer. We don't want to prevent a buffer
large enough for the driver but not page size aligned to be imported.
What we could do is round in the core the size passed to the alloc function,
without storing the rounded value in vb->v4l2_planes[plane].length.
And, reading down, I realize that this is exactly what you meant :-) The
proposed patch looks good to me.
> Also, VB2 is already complex enough to put it there without proper
> comments (and there's a minor codingstyle issue there: line is bigger
> than 80 cols).
A comment is definitely a good idea.
> > diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
> > b/drivers/media/v4l2-core/videobuf2-vmalloc.c index 313d977..bf3b95c
> > 100644
> > --- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
> > +++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
> > @@ -44,7 +44,7 @@ static void *vb2_vmalloc_alloc(void *alloc_ctx, unsigned
> > long size, gfp_t gfp_fl>
> > return NULL;
> >
> > buf->size = size;
> >
> > - buf->vaddr = vmalloc_user(buf->size);
> > + buf->vaddr = vmalloc_user(PAGE_ALIGN(buf->size));
>
> See? You needed to put an alignment here as well, not because vmalloc
> needs it, but because this is needed by VB2 core.
>
> Also, on the other drivers, buf->size is stored page aligned, while
> here, you're doing different, without any documented reason for doing
> that, instead of doing the same as on the other memops drivers.
>
> That mistake reflects, for example, when the driver prints the failure:
>
> if (!buf->vaddr) {
> pr_debug("vmalloc of size %ld failed\n", buf->size);
>
> as it will show a different size than what you actually required.
> As those memory starving errors can also produce a dump at the mm
> core, the size there won't match the size on the above printed message.
>
> Also, it is a very bad idea to delegate the core's requirement of
> do page alignment from the core to the memops drivers, as other
> patches may change the logic there, or a new memops could be added,
> and the same problem will hit again (and unnoticed, as the check
> routine do page alignments).
Agreed. The memory allocator shouldn't need to guess the core requirements.
> > buf->handler.refcount = &buf->refcount;
> > buf->handler.put = vb2_vmalloc_put;
> > buf->handler.arg = buf;
>
> IMO, a cleaner version would be the following (untested) code.
>
> -
>
> [media] videobuf2: fix the length check for mmap
>
> Memory maps typically require that the buffer size to be page
> aligned. Currently, two memops drivers do such alignment
> internally, but videobuf-vmalloc doesn't.
>
> Also, the buffer overflow check doesn't take it into account.
>
> So, instead of doing it at each memops driver, enforce it at
> VB2 core.
>
> Reported-by: Prabhakar lad
>
[PATCH] MAINTAINERS: Add linux-samsung-soc list to all related entries
Several entries in MAINTAINERS file related to Samsung SoCs do not point to linux-samsung-soc mailing list, which is supposed to collect all Samsung SoC-related threads, to ease following of Samsung SoC-related work. This leads to a problem with people skipping this mailing list in their posts, even though they are related to Samsung SoCs. This patch adds pointers to linux-samsung-soc mailing list to affected entries of MAINTAINERS file. Signed-off-by: Tomasz Figa --- MAINTAINERS | 11 +++ 1 file changed, 11 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6c0d68b..07cb8da 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1139,6 +1139,7 @@ F:arch/arm/mach-exynos*/ ARM/SAMSUNG MOBILE MACHINE SUPPORT M: Kyungmin Park L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/mach-s5pv210/mach-aquila.c F: arch/arm/mach-s5pv210/mach-goni.c @@ -1150,6 +1151,7 @@ M:Kyungmin Park M: Kamil Debski L: linux-arm-ker...@lists.infradead.org L: linux-media@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/media/platform/s5p-g2d/ @@ -1158,6 +1160,7 @@ M:Kyungmin Park M: Sylwester Nawrocki L: linux-arm-ker...@lists.infradead.org L: linux-media@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/plat-samsung/include/plat/*fimc* F: drivers/media/platform/s5p-fimc/ @@ -1168,6 +1171,7 @@ M:Kamil Debski M: Jeongtae Park L: linux-arm-ker...@lists.infradead.org L: linux-media@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: arch/arm/plat-samsung/s5p-dev-mfc.c F: drivers/media/platform/s5p-mfc/ @@ -1177,6 +1181,7 @@ M:Kyungmin Park M: Tomasz Stanislawski L: linux-arm-ker...@lists.infradead.org L: linux-media@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/media/platform/s5p-tv/ @@ -2679,6 +2684,7 @@ M:Joonyoung Shim M: Seung-Woo Kim M: Kyungmin Park L: dri-de...@lists.freedesktop.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) T: git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git S: Supported F: drivers/gpu/drm/exynos @@ -3142,6 +3148,7 @@ F:Documentation/extcon/ EXYNOS DP DRIVER M: Jingoo Han L: linux-fb...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/exynos/exynos_dp* F: include/video/exynos_dp* @@ -3151,6 +3158,7 @@ M:Inki Dae M: Donghwa Lee M: Kyungmin Park L: linux-fb...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/exynos/exynos_mipi* F: include/video/exynos_mipi* @@ -6892,12 +6900,14 @@ F: drivers/platform/x86/samsung-laptop.c SAMSUNG AUDIO (ASoC) DRIVERS M: Sangbeom Kim L: alsa-de...@alsa-project.org (moderated for non-subscribers) +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Supported F: sound/soc/samsung SAMSUNG FRAMEBUFFER DRIVER M: Jingoo Han L: linux-fb...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/video/s3c-fb.c @@ -7087,6 +7097,7 @@ F:drivers/mmc/host/sdhci-pltfm.[ch] SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) SAMSUNG DRIVER M: Ben Dooks L: linux-...@vger.kernel.org +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) S: Maintained F: drivers/mmc/host/sdhci-s3c.c -- 1.8.2.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 v2 4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667 support
Hello. On 04/21/2013 10:42 PM, Sergei Shtylyov wrote: From: Vladimir Barinov Add ML86V7667 platform devices on BOCK-W board, configure VIN0/1 pins, and register VIN0/1 devices with the ML86V7667 specific platform data. Signed-off-by: Vladimir Barinov [Sergei: some macro/comment cleanup; updated the copyrights.] Signed-off-by: Sergei Shtylyov --- arch/arm/mach-shmobile/board-bockw.c | 40 +++ 1 file changed, 40 insertions(+) Index: renesas/arch/arm/mach-shmobile/board-bockw.c === --- renesas.orig/arch/arm/mach-shmobile/board-bockw.c +++ renesas/arch/arm/mach-shmobile/board-bockw.c [...] @@ -23,6 +24,8 @@ #include #include #include +#include Noticed just now: this #include is duplicate. It seems I was too fast in resending the series... WBR, Sergei -- 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 RFCv3 00/10] Add SDR at V4L2 API
This is a version 3 of the V4L2 API bits to support Software Digital Radio (SDR). Changes from version 2: - Patches got better described and named; - Merged all SDR analog TV into just one field; - Documented what parts of the [RFC v2013-04-11] SDR API REQUIREMENT SPECIFICATION are being addressed on the patches that touch on the V4L2 external API. With regards to the [RFC v2013-04-11] SDR requirements spec[1], v3 implements: - operation mode inquire (Rx/Tx) - implemented via VIDIOC_QUERYCAP; - get/set doesn't make sense, as different devnodes are used for RX and TX; - sampling resolution - implemented via VIDIOC_ENUM_FMT/VIDIOC_G_FMT/VIDIOC_S_FMT. - sampling rate - get/set - implemented via VIDIOC_G_TUNER/VIDIOC_S_TUNER. - inquire HW - TODO (planning is to also use the same ioctl's for it); - It may make sense to move it out of TUNER ioctl, as this is actually ADC/DAC settings. For the initial tests, I'll likely use as is, but IMO, the beter is to split it out of VIDIOC_G_TUNER/VIDIOC_S_TUNER. - inversion - TODO. If needed, probably will use VIDIOC_G_TUNER. - RF frequency - implemented using VIDIOC_S_FREQUENCY/VIDIOC_G_FREQUENCY - scale: 62.5 Hz. - TODO: add a lower scale, for very low freqs. - IF frequency - implemented via VIDIOC_G_TUNER/VIDIOC_S_TUNER. - tuner lock (frequency synthesizer / PLL) - TODO. May eventually use tuner->strength - tuner gains - TODO (V4L2 controls). - enable/disable auto gain - TODO (V4L2 controls). - tuner filters - TODO (V4L2 controls). - pass RF standard to tuner? - Partially implemented. It doesn't pass V4L2 analog TV types yet. - TODO: add VIDIOC_S_STD support for SDR radio - antenna switch - implemented via VIDIOC_G_TUNER/VIDIOC_S_TUNER. - external LNA - TODO (maybe there's already a V4L2 control for it) - device locking between multiple APIs - TODO (well, there are resource locking already between DVB and V4L at driver level) [1] http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/63323 TODO: - check if VB2 require changes (might require trivial ones, due to the new buffer type); - add a SDR driver testing the new features - likely a cx88 driver, but as cx88 doesn't use VB2, I might use some other driver. The advantage of using cx88 is that it has 2 ADC, one baseband and another IF that can be used at the same time, 8-bits or 10-bits and up to ~35 MHz of sampling rate. Mauro Carvalho Chehab (10): [media] Add initial SDR support at V4L2 API [media] videodev2.h: Remove the unused old V4L1 buffer types [media] V4L2 api: Add a buffer capture type for SDR [media] V4L2 sdr API: Add fields for VIDIOC_[G|S]_TUNER [media] v4l2-ioctl: Add tuner ioctl support for SDR radio type [media] tuner-core: consider SDR as radio [media] tuner-core: add SDR support for g_tuner [media] tuner-core: store tuner ranges at tuner struct [media] tuner-core: add support to get the tuner frequency range [media] tuner-core: add support for SDR set_tuner Documentation/DocBook/media/v4l/common.xml | 35 +++ Documentation/DocBook/media/v4l/dev-capture.xml| 26 +- Documentation/DocBook/media/v4l/io.xml | 6 + Documentation/DocBook/media/v4l/pixfmt.xml | 41 +++ Documentation/DocBook/media/v4l/v4l2.xml | 1 + Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 30 ++- .../DocBook/media/v4l/vidioc-querycap.xml | 7 + drivers/media/dvb-core/dvb_frontend.h | 2 + drivers/media/tuners/tuner-xc2028.c| 2 + drivers/media/v4l2-core/tuner-core.c | 297 ++--- drivers/media/v4l2-core/v4l2-dev.c | 3 + drivers/media/v4l2-core/v4l2-ioctl.c | 121 +++-- include/media/v4l2-dev.h | 3 +- include/media/v4l2-ioctl.h | 8 + include/uapi/linux/videodev2.h | 79 -- 15 files changed, 503 insertions(+), 158 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 08/10] [media] tuner-core: store tuner ranges at tuner struct
Instead of using global values for tuner ranges, store them
internally. That fixes the need of using a different range
for SDR radio, and will help to latter add a tuner ops to
retrieve the tuner range for SDR mode.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/tuner-core.c | 59 ++--
1 file changed, 37 insertions(+), 22 deletions(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index e54b5ae..abdcda4 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -67,8 +67,8 @@ static char secam[] = "--";
static char ntsc[] = "-";
module_param_named(debug, tuner_debug, int, 0644);
-module_param_array(tv_range, int, NULL, 0644);
-module_param_array(radio_range, int, NULL, 0644);
+module_param_array(tv_range, int, NULL, 0444);
+module_param_array(radio_range, int, NULL, 0444);
module_param_string(pal, pal, sizeof(pal), 0644);
module_param_string(secam, secam, sizeof(secam), 0644);
module_param_string(ntsc, ntsc, sizeof(ntsc), 0644);
@@ -134,6 +134,8 @@ struct tuner {
unsigned inttype; /* chip type id */
void*config;
const char *name;
+
+ u32 radio_range[2], tv_range[2], sdr_range[2];
};
/*
@@ -266,7 +268,7 @@ static void set_type(struct i2c_client *c, unsigned int
type,
struct dvb_tuner_ops *fe_tuner_ops = &t->fe.ops.tuner_ops;
struct analog_demod_ops *analog_ops = &t->fe.ops.analog_ops;
unsigned char buffer[4];
- int tune_now = 1;
+ int i, tune_now = 1;
if (type == UNSET || type == TUNER_ABSENT) {
tuner_dbg("tuner 0x%02x: Tuner type absent\n", c->addr);
@@ -451,6 +453,13 @@ static void set_type(struct i2c_client *c, unsigned int
type,
set_tv_freq(c, t->tv_freq);
}
+ /* Initializes the tuner ranges from modprobe parameters */
+ for (i = 0; i < 2; i++) {
+ t->radio_range[i] = radio_range[i] * 16000;
+ t->sdr_range[i] = tv_range[i] * 16000;
+ t->tv_range[i] = tv_range[i] * 16;
+ }
+
tuner_dbg("%s %s I2C addr 0x%02x with type %d used for 0x%02x\n",
c->adapter->name, c->driver->driver.name, c->addr << 1, type,
t->mode_mask);
@@ -831,16 +840,16 @@ static void set_tv_freq(struct i2c_client *c, unsigned
int freq)
tuner_warn("Tuner has no way to set tv freq\n");
return;
}
- if (freq < tv_range[0] * 16 || freq > tv_range[1] * 16) {
+ if (freq < t->tv_range[0] || freq > t->tv_range[1]) {
tuner_dbg("TV freq (%d.%02d) out of range (%d-%d)\n",
- freq / 16, freq % 16 * 100 / 16, tv_range[0],
- tv_range[1]);
+ freq / 16, freq % 16 * 100 / 16, t->tv_range[0] / 16,
+ t->tv_range[1] / 16);
/* V4L2 spec: if the freq is not possible then the closest
possible value should be selected */
- if (freq < tv_range[0] * 16)
- freq = tv_range[0] * 16;
+ if (freq < t->tv_range[0])
+ freq = t->tv_range[0];
else
- freq = tv_range[1] * 16;
+ freq = t->tv_range[1];
}
params.frequency = freq;
tuner_dbg("tv freq set to %d.%02d\n",
@@ -957,7 +966,7 @@ static void set_radio_freq(struct i2c_client *c, unsigned
int freq)
{
struct tuner *t = to_tuner(i2c_get_clientdata(c));
struct analog_demod_ops *analog_ops = &t->fe.ops.analog_ops;
-
+ u32 *range;
struct analog_parameters params = {
.mode = t->mode,
.audmode = t->audmode,
@@ -972,16 +981,22 @@ static void set_radio_freq(struct i2c_client *c, unsigned
int freq)
tuner_warn("tuner has no way to set radio frequency\n");
return;
}
- if (freq < radio_range[0] * 16000 || freq > radio_range[1] * 16000) {
+
+ if (V4L2_TUNER_IS_SDR(t->mode))
+ range = t->sdr_range;
+ else
+ range = t->radio_range;
+
+ if (freq < range[0] || freq > range[1]) {
tuner_dbg("radio freq (%d.%02d) out of range (%d-%d)\n",
freq / 16000, freq % 16000 * 100 / 16000,
- radio_range[0], radio_range[1]);
+ range[0] / 16000, range[1] / 16000);
/* V4L2 spec: if the freq is not possible then the closest
possible value should be selected */
- if (freq < radio_range[0] * 16000)
- freq = radio_range[0] * 16000;
+ if (freq < range[0])
+ freq = range[0];
else
- freq = radio_range[1
[PATCH RFCv3 03/10] [media] V4L2 api: Add a buffer capture type for SDR
As SDR devices are not video, VBI or RDS devices, it needs
its own buffer type for capture.
Also, as discussed at:
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/63123
It should be a way to enumerate and select the formats that the
hardware supports, as one hardware may accept more than one format
(cx88, for example, can likely support several different formats,
as it will depend on how the RISC code for it will be written).
So, add a a new stream type (V4L2_BUF_TYPE_SDR_CAPTURE) at the
V4L2 API, and the corresponding buffer function handlers.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/DocBook/media/v4l/dev-capture.xml | 26
Documentation/DocBook/media/v4l/io.xml | 6 +
drivers/media/v4l2-core/v4l2-ioctl.c| 32 +
include/media/v4l2-ioctl.h | 8 +++
include/uapi/linux/videodev2.h | 3 ++-
5 files changed, 64 insertions(+), 11 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/dev-capture.xml
b/Documentation/DocBook/media/v4l/dev-capture.xml
index e1c5f94..7797d2d 100644
--- a/Documentation/DocBook/media/v4l/dev-capture.xml
+++ b/Documentation/DocBook/media/v4l/dev-capture.xml
@@ -44,7 +44,7 @@ all video capture devices.
-Image Format Negotiation
+Streaming Format Negotiation
The result of a capture operation is determined by
cropping and image format parameters. The former select an area of the
@@ -65,13 +65,18 @@ linkend="crop" />.
To query the current image format applications set the
type field of a &v4l2-format; to
-V4L2_BUF_TYPE_VIDEO_CAPTURE or
-V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE and call the
-&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill
-the &v4l2-pix-format; pix or the
-&v4l2-pix-format-mplane; pix_mp member of the
+V4L2_BUF_TYPE_VIDEO_CAPTURE,
+V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE or
+V4L2_BUF_TYPE_VIDEO_SDR_CAPTURE or
+and call the &VIDIOC-G-FMT; ioctl with a pointer to this structure.
+
+Video drivers fill the &v4l2-pix-format; pix
+or the &v4l2-pix-format-mplane; pix_mp member of the
fmt union.
+SDR drivers fill the &v4l2-sdr-format; sdr
+member of the fmt union.
+
To request different parameters applications set the
type field of a &v4l2-format; as above and
initialize all fields of the &v4l2-pix-format;
@@ -87,8 +92,9 @@ adjust the parameters and finally return the actual
parameters as
without disabling I/O or possibly time consuming hardware
preparations.
-The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane;
-are discussed in . See also the specification of the
+The contents of &v4l2-pix-format;, &v4l2-pix-format-mplane; and
+&v4l2-sdr-format; are discussed in .
+See also the specification of the
VIDIOC_G_FMT, VIDIOC_S_FMT
and VIDIOC_TRY_FMT ioctls for details. Video
capture devices must implement both the
@@ -100,9 +106,9 @@ returns default parameters as
VIDIOC_G_FMT does.
-Reading Images
+Reading streams
-A video capture device may support the A video capture device or an SDR device may support the read() function and/or streaming (memory mapping or user pointer) I/O. See
Buffer for video output overlay (OSD), see .
+
+ V4L2_BUF_TYPE_SDR_CAPTURE
+ 8
+ Buffer for Software Digital Radio (SDR) receivers, see .
+
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index f81bda1..fd853da 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -150,6 +150,7 @@ const char *v4l2_type_names[] = {
[V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY] = "vid-out-overlay",
[V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE] = "vid-cap-mplane",
[V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE] = "vid-out-mplane",
+ [V4L2_BUF_TYPE_SDR_CAPTURE] = "sdr-cap",
};
EXPORT_SYMBOL(v4l2_type_names);
@@ -242,6 +243,7 @@ static void v4l_print_format(const void *arg, bool
write_only)
const struct v4l2_pix_format_mplane *mp;
const struct v4l2_vbi_format *vbi;
const struct v4l2_sliced_vbi_format *sliced;
+ const struct v4l2_sdr_format *sdr;
const struct v4l2_window *win;
const struct v4l2_clip *clip;
unsigned i;
@@ -323,6 +325,14 @@ static void v4l_print_format(const void *arg, bool
write_only)
sliced->service_lines[0][i],
sliced->service_lines[1][i]);
break;
+ case V4L2_BUF_TYPE_SDR_CAPTURE:
+ sdr = &p->fmt.sdr;
+ pr_cont("format=%c%c%c%c\n",
+ (sdr->sampleformat & 0xff),
+ (sdr->sampleformat >> 8) & 0xff,
+ (sdr->sampleformat >> 16) & 0xff,
+ (sdr->sampleformat >> 24) & 0xff);
+ break;
}
}
@@
[PATCH RFCv3 10/10] [media] tuner-core: add support for SDR set_tuner
Most SDR devices use TV tuners. Those generally require
to know what is the type of the envelope, in order to
adjust their PLL's and filters.
Add support to tune them via tuner-core.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/tuner-core.c | 220 ++-
1 file changed, 141 insertions(+), 79 deletions(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index 28bbcad..2b9eed6 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -121,10 +121,12 @@ struct tuner {
struct list_headlist;
/* keep track of the current settings */
- v4l2_std_id std;
+ v4l2_std_id std, sdr_std;
unsigned inttv_freq;
unsigned intradio_freq;
+ unsigned intsdr_freq;
unsigned intaudmode;
+ u32 bandwidth;
enum v4l2_tuner_type mode;
unsigned intmode_mask; /* Combination of allowable modes */
@@ -142,8 +144,9 @@ struct tuner {
* Function prototypes
*/
-static void set_tv_freq(struct i2c_client *c, unsigned int freq);
-static void set_radio_freq(struct i2c_client *c, unsigned int freq);
+static void set_freq(struct tuner *t, unsigned int freq);
+static void set_tv_freq(struct tuner *t, struct analog_parameters *params);
+static void set_radio_freq(struct tuner *t, struct analog_parameters *params);
/*
* tuner attach/detach logic
@@ -440,19 +443,6 @@ static void set_type(struct i2c_client *c, unsigned int
type,
t->mode_mask = new_mode_mask;
- /* Some tuners require more initialization setup before use,
- such as firmware download or device calibration.
- trying to set a frequency here will just fail
- FIXME: better to move set_freq to the tuner code. This is needed
- on analog tuners for PLL to properly work
-*/
- if (tune_now) {
- if (V4L2_TUNER_IS_RADIO(t->mode))
- set_radio_freq(c, t->radio_freq);
- else
- set_tv_freq(c, t->tv_freq);
- }
-
/* Initializes the tuner ranges from modprobe parameters */
for (i = 0; i < 2; i++) {
t->radio_range[i] = radio_range[i] * 16000;
@@ -466,6 +456,28 @@ static void set_type(struct i2c_client *c, unsigned int
type,
t->sdr_range[0] = min / 16;
t->sdr_range[1] = max / 16;
}
+ /*
+* FIXME: It is possible that, for some SDR devices, the analog
+* standard needs to be better known. In this case, it should use
+* V4L2 VIDIOC_S_STD to change the content of t->sdr_std to reflect
+* what type of RF is expected.
+* Adding support for it would require additional changes at
+* v4l2-dev, as tuner-core needs to know if the request comes from
+* a SDR devnode or from an analog TV devnode, because, a TV s_std
+* ops cause the tuner to switch modes.
+*/
+ t->sdr_std = V4L2_STD_ALL;
+
+ /*
+* Some tuners require more initialization setup before use,
+* such as firmware download or device calibration.
+* trying to set a frequency here will just fail
+*
+* FIXME: better to move set_freq to the tuner code. This is needed
+*on analog tuners for PLL to properly work
+*/
+ if (tune_now)
+ set_freq(t, 0);
tuner_dbg("%s %s I2C addr 0x%02x with type %d used for 0x%02x\n",
c->adapter->name, c->driver->driver.name, c->addr << 1, type,
@@ -805,16 +817,81 @@ static int set_mode(struct tuner *t, enum v4l2_tuner_type
mode)
*/
static void set_freq(struct tuner *t, unsigned int freq)
{
- struct i2c_client *client = v4l2_get_subdevdata(&t->sd);
+ struct analog_parameters params;
+ struct dtv_frontend_properties *c = &t->fe.dtv_property_cache;
+ struct dvb_tuner_ops *fe_tuner_ops = &t->fe.ops.tuner_ops;
+ bool is_analog = true;
- if (V4L2_TUNER_IS_RADIO(t->mode)) {
+ if (t->type == UNSET) {
+ tuner_warn("tuner type not set\n");
+ return;
+ }
+
+ memset(¶ms, 0, sizeof(params));
+
+ switch (t->mode) {
+ case V4L2_TUNER_ANALOG_TV:
+ if (!freq)
+ freq = t->tv_freq;
+
+ params.mode = t->mode;
+ params.audmode = t->audmode;
+ params.std = t->std;
+ params.frequency = freq;
+ set_tv_freq(t, ¶ms);
+ t->tv_freq = params.frequency;
+ return;
+ case V4L2_TUNER_RADIO:
if (!freq)
freq = t->radio_freq;
- set_radio_freq(client, freq);
+ params.mode = V4L2_TUNER_RADIO;
+ params.audmode = t->audmode;
+
[PATCH RFCv3 04/10] [media] V4L2 sdr API: Add fields for VIDIOC_[G|S]_TUNER
As discussed at:
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/63123
SDR radio require some other things at to set. VIDIOC_[G|S]_TUNER
is currently not enough.
I proposed there to create an extra ioctl for it, but the thing
is that VIDIOC_[G|S]_TUNER is meant to set what's needed to configure
the tuner. So, add there the missing bits to:
- set/get the tuner sampling rate;
- set/get the tuner low pass bandwidth filter;
- get the tuner IF.
VIDIOC_[G|S]_TUNER already provides:
- tuner input switch;
- tuner input name;
- tuner capability flags;
- tuner range;
- signal strength;
- afc.
There are still 3 u32 reserved fields there that may be used for
SDR in the future, and may be neded at the final version.
For example, it may make sense to add a SDR flag with:
- bandwidth inversion flag;
- tuner PLL lock flag (or reuse signal strength for that).
It also makes sense to add sample_rate range there.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 30 ++---
drivers/media/tuners/tuner-xc2028.c| 2 ++
include/uapi/linux/videodev2.h | 38 --
3 files changed, 63 insertions(+), 7 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
index 6cc8201..b8a3bcf 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
@@ -200,9 +200,10 @@ audio
_SAP flag is cleared in the
capability field, the corresponding
V4L2_TUNER_SUB_ flag must not be set
-here.This field is valid only if this is the tuner of the
+here.
+This field is valid only for if this is the tuner of the
current video input, or when the structure refers to a radio
-tuner.
+tuner. This field is not used by SDR tuners.
__u32
@@ -216,7 +217,7 @@ unless the requested mode is invalid or unsupported. See
Currently this is the only field of struct
v4l2_tuner applications can
-change.
+change. This field is not used by SDR tuners.
__u32
@@ -234,7 +235,28 @@ settles at zero, &ie; range is what? -->
__u32
- reserved[4]
+ sample_rate
+ Sampling rate used by a SDR tuner, in Hz.
+ This value is valid only for SDR tuners.
+
+
+ __u32
+ bandwidth
+ Bandwidth allowed by the SDR tuner
+ low-pass saw filter, in Hz. This value is valid only for
+ SDR tuners.
+
+
+ __u32
+ int_freq
+ Intermediate Frequency (IF) used by
+ the tuner, in Hz. This value is valid only for
+ VIDIOC_G_TUNER, and it is valid only
+ on SDR tuners.
+
+
+ __u32
+ reserved[3]
Reserved for future extensions. Drivers and
applications must set the array to zero.
diff --git a/drivers/media/tuners/tuner-xc2028.c
b/drivers/media/tuners/tuner-xc2028.c
index 878d2c4..c61163f 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1020,6 +1020,8 @@ static int generic_set_freq(struct dvb_frontend *fe, u32
freq /* in HZ */,
* Maybe this might also be needed for DTV.
*/
switch (new_type) {
+ default:/* SDR currently not supported */
+ goto ret;
case V4L2_TUNER_ANALOG_TV:
rc = send_seq(priv, {0x00, 0x00});
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 974c49d..c002030 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -160,6 +160,22 @@ enum v4l2_tuner_type {
V4L2_TUNER_RADIO = 1,
V4L2_TUNER_ANALOG_TV = 2,
V4L2_TUNER_DIGITAL_TV= 3,
+/*
+ * Even not decoding the signal, SDR tuners may require to adjust IF,
+ * low pass filters, center frequency, etc based on the signal envelope,
+ * and its bandwidth. While we might be using here the V4L2_STD_*
+ * types, plus DVB delsys, that doesn't seem to be the better thing to
+ * do, as:
+ * 1) it would require 64 bits for V4L2 std + 32 bits for DVB std;
+ * 2) non-TV types of envelopes won't work.
+ *
+ * So, add a separate enum to describe the possible types of SDR envelopes.
+ */
+ V4L2_TUNER_SDR_RADIO = 10, /* Generic non-optimized Radio range */
+ V4L2_TUNER_SDR_ATV, /* Optimize for Analog TV */
+ V4L2_TUNER_SDR_DTV_ATSC,/* Optimize for Digital TV, ATSC */
+ V4L2_TUNER_SDR_DTV_DVBT,/* Optimize for Digital TV, DVB-T */
+ V4L2_TUNER_SDR_DTV_ISDBT, /* Optimize for Digital TV, ISDB-T */
};
enum v4l2_
[PATCH RFCv3 06/10] [media] tuner-core: consider SDR as radio
There are several tests at tuner-core for radio. Extend it to
also cover SDR radio.
Some of the changes here may need to be reviewed, SDR support will
actually be implemented there.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/tuner-core.c | 22 --
include/uapi/linux/videodev2.h | 3 +++
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index ddc9379..b97ec63 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -445,7 +445,7 @@ static void set_type(struct i2c_client *c, unsigned int
type,
on analog tuners for PLL to properly work
*/
if (tune_now) {
- if (V4L2_TUNER_RADIO == t->mode)
+ if (V4L2_TUNER_IS_RADIO(t->mode))
set_radio_freq(c, t->radio_freq);
else
set_tv_freq(c, t->tv_freq);
@@ -743,7 +743,7 @@ static int tuner_remove(struct i2c_client *client)
static inline int check_mode(struct tuner *t, enum v4l2_tuner_type mode)
{
int t_mode;
- if (mode == V4L2_TUNER_RADIO)
+ if (V4L2_TUNER_IS_RADIO(mode))
t_mode = T_RADIO;
else
t_mode = T_ANALOG_TV;
@@ -791,7 +791,7 @@ static void set_freq(struct tuner *t, unsigned int freq)
{
struct i2c_client *client = v4l2_get_subdevdata(&t->sd);
- if (t->mode == V4L2_TUNER_RADIO) {
+ if (V4L2_TUNER_IS_RADIO(t->mode)) {
if (!freq)
freq = t->radio_freq;
set_radio_freq(client, freq);
@@ -1024,11 +1024,13 @@ static void tuner_status(struct dvb_frontend *fe)
p = "digital TV";
break;
case V4L2_TUNER_ANALOG_TV:
- default:
p = "analog TV";
break;
+ default:
+ p = "SDR";
+ break;
}
- if (t->mode == V4L2_TUNER_RADIO) {
+ if (V4L2_TUNER_IS_RADIO(t->mode)) {
freq = t->radio_freq / 16000;
freq_fraction = (t->radio_freq % 16000) * 100 / 16000;
} else {
@@ -1039,7 +1041,7 @@ static void tuner_status(struct dvb_frontend *fe)
t->standby ? " on standby mode" : "");
tuner_info("Frequency: %lu.%02lu MHz\n", freq, freq_fraction);
tuner_info("Standard:0x%08lx\n", (unsigned long)t->std);
- if (t->mode != V4L2_TUNER_RADIO)
+ if (!V4L2_TUNER_IS_RADIO(t->mode))
return;
if (fe_tuner_ops->get_status) {
u32 tuner_status;
@@ -1144,11 +1146,11 @@ static int tuner_g_frequency(struct v4l2_subdev *sd,
struct v4l2_frequency *f)
u32 abs_freq;
fe_tuner_ops->get_frequency(&t->fe, &abs_freq);
- f->frequency = (V4L2_TUNER_RADIO == t->mode) ?
+ f->frequency = (V4L2_TUNER_IS_RADIO(t->mode)) ?
DIV_ROUND_CLOSEST(abs_freq * 2, 125) :
DIV_ROUND_CLOSEST(abs_freq, 62500);
} else {
- f->frequency = (V4L2_TUNER_RADIO == f->type) ?
+ f->frequency = (V4L2_TUNER_IS_RADIO(f->type)) ?
t->radio_freq : t->tv_freq;
}
return 0;
@@ -1180,7 +1182,7 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
if (!analog_ops->has_signal(&t->fe, &signal))
vt->signal = signal;
}
- if (vt->type != V4L2_TUNER_RADIO) {
+ if (!V4L2_TUNER_IS_RADIO(vt->type)) {
vt->capability |= V4L2_TUNER_CAP_NORM;
vt->rangelow = tv_range[0] * 16;
vt->rangehigh = tv_range[1] * 16;
@@ -1224,7 +1226,7 @@ static int tuner_s_tuner(struct v4l2_subdev *sd, const
struct v4l2_tuner *vt)
if (set_mode(t, vt->type))
return 0;
- if (t->mode == V4L2_TUNER_RADIO) {
+ if (V4L2_TUNER_IS_RADIO(t->mode)) {
t->audmode = vt->audmode;
/*
* For radio audmode can only be mono or stereo. Map any
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index e2cc369..9d18af7 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -182,6 +182,9 @@ enum v4l2_tuner_type {
#define V4L2_TUNER_IS_SDR(type)\
(((type) >= V4L2_TUNER_SDR_RADIO) || ((type) < V4L2_TUNER_SDR_MAX))
+#define V4L2_TUNER_IS_RADIO(type) \
+ (((type) == V4L2_TUNER_RADIO) || V4L2_TUNER_IS_SDR(type))
+
enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR = 2,
--
1.8.1.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.ker
[PATCH RFCv3 01/10] [media] Add initial SDR support at V4L2 API
Adds the basic API bits for Software Digital Radio (SDR) at the V4L2 API. A normal radio device is actually radio and hardware demod. As the demod is in hardware, several things that are required for the demodulate the signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to the device and aren't part of the API. SDR radio, on the other hand, requires that every control needed by the tuner to be exposed on userspace, as userspace needs to adjust the software decoder to match it. As proposed at: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/63123 Add a new device node for SDR devices, and a VIDIOC_QUERYCAP capability (V4L2_CAP_SDR) to indicate that a devnode is SDR. The stream output format also needs to be different, as it should output sample data, instead of video streams. As we need to document SDR, add one initial format there that will be later be used. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/common.xml | 35 ++ Documentation/DocBook/media/v4l/pixfmt.xml | 41 ++ Documentation/DocBook/media/v4l/v4l2.xml | 1 + .../DocBook/media/v4l/vidioc-querycap.xml | 7 drivers/media/v4l2-core/v4l2-dev.c | 3 ++ include/media/v4l2-dev.h | 3 +- include/uapi/linux/videodev2.h | 11 ++ 7 files changed, 100 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 1ddf354..f59c67d 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -513,6 +513,41 @@ the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl when the device has one or more modulators. + +Software Digital Radio (SDR) Tuners and Modulators + +Those devices are special types of Radio devices that don't +have any analog demodulator. Instead, it samples the radio IF or baseband +and sends the samples for userspace to demodulate. + + Tuners + + SDR receivers can have one or more tuners sampling RF signals. +Each tuner is associated with one or more inputs, depending on the number +of RF connectors on the tuner. The type field of +the respective &v4l2-input; returned by the &VIDIOC-ENUMINPUT; ioctl is set to +V4L2_INPUT_TYPE_TUNER and its +tuner field contains the index number of +the tuner input. + +To query and change tuner properties applications use the +&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The +&v4l2-tuner; returned by VIDIOC_G_TUNER also +contains signal status information applicable when the tuner of the +current SDR input is queried. In order to change the SDR input, +VIDIOC_S_TUNER with a new SDR index should be called. +Drivers must support both ioctls and set the +V4L2_CAP_SDR and V4L2_CAP_TUNER +flags in the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl. + + + + Modulators + To be defined. + + + + Radio Frequency diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 99b8d2a..e30075e 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -203,6 +203,47 @@ codes can be used. + + SDR format struture + +struct v4l2_sdr_format + + &cs-str; + + + __u32 + sampleformat + The format of the samples used by the SDR device. +This is a little endian + +four character code. + + + + + +SDR formats + + &cs-str; + + + V4L2_SDR_FMT_I8Q8 + Samples are given by a sequence of 8 bits in-phase(I) and + 8 bits quadrature (Q) samples taken from a + signal(t) represented by the following +expression: + +signal(t) = I cos(2π f t) - Q sin(2π f t) +signal(t) = I * cos(2π fc t) - Q * sin(2π fc t) + + + + + + + + + Standard Image Formats diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index bfc93cd..b53a5cf 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -521,6 +521,7 @@ and discussions on the V4L mailing list. &sub-dev-teletext; &sub-dev-radio; &sub-dev-rds; + &sub-dev-sdr; &sub-dev-event; &sub-dev-subdev; diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index d5a3c97..97bb25a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -296,6 +296,13 @@ modulator programming see .
[PATCH RFCv3 02/10] [media] videodev2.h: Remove the unused old V4L1 buffer types
Those aren't used anywhere for a long time. Drop it. Signed-off-by: Mauro Carvalho Chehab --- include/uapi/linux/videodev2.h | 21 - 1 file changed, 21 deletions(-) diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index 4aa24c3..5d8ee92 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -72,27 +72,6 @@ #define VIDEO_MAX_FRAME 32 #define VIDEO_MAX_PLANES 8 -#ifndef __KERNEL__ - -/* These defines are V4L1 specific and should not be used with the V4L2 API! - They will be removed from this header in the future. */ - -#define VID_TYPE_CAPTURE 1 /* Can capture */ -#define VID_TYPE_TUNER 2 /* Can tune */ -#define VID_TYPE_TELETEXT 4 /* Does teletext */ -#define VID_TYPE_OVERLAY 8 /* Overlay onto frame buffer */ -#define VID_TYPE_CHROMAKEY 16 /* Overlay by chromakey */ -#define VID_TYPE_CLIPPING 32 /* Can clip */ -#define VID_TYPE_FRAMERAM 64 /* Uses the frame buffer memory */ -#define VID_TYPE_SCALES128 /* Scalable */ -#define VID_TYPE_MONOCHROME256 /* Monochrome only */ -#define VID_TYPE_SUBCAPTURE512 /* Can capture subareas of the image */ -#define VID_TYPE_MPEG_DECODER 1024/* Can decode MPEG streams */ -#define VID_TYPE_MPEG_ENCODER 2048/* Can encode MPEG streams */ -#define VID_TYPE_MJPEG_DECODER 4096/* Can decode MJPEG streams */ -#define VID_TYPE_MJPEG_ENCODER 8192/* Can encode MJPEG streams */ -#endif - /* * M I S C E L L A N E O U S */ -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 07/10] [media] tuner-core: add SDR support for g_tuner
Properly initialize the fields for VIDIOC_G_TUNER, if the
device is in SDR mode.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/tuner-core.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index b97ec63..e54b5ae 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -1190,7 +1190,31 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
}
/* radio mode */
- if (vt->type == t->mode) {
+ vt->capability |= V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
+
+ if (V4L2_TUNER_IS_SDR(vt->type)) {
+ vt->rangelow = tv_range[0] * 16000;
+ vt->rangehigh = tv_range[1] * 16000;
+ else {
+ vt->rangelow = radio_range[0] * 16000;
+ vt->rangehigh = radio_range[1] * 16000;
+ }
+ /* Check if the radio device is active */
+ if (vt->type != t->mode)
+ return 0;
+
+ if (V4L2_TUNER_IS_SDR(vt->type)) {
+ if (fe_tuner_ops->get_bandwidth)
+ fe_tuner_ops->get_bandwidth(&t->fe,
+ &vt->bandwidth);
+ if (fe_tuner_ops->get_if_frequency)
+ fe_tuner_ops->get_if_frequency(&t->fe,
+ &vt->int_freq);
+ /*
+ * Sampe rate is not a tuner props - it is up to the
+ * bridge driver to fill it.
+ */
+ } else {
vt->rxsubchans = V4L2_TUNER_SUB_MONO | V4L2_TUNER_SUB_STEREO;
if (fe_tuner_ops->get_status) {
u32 tuner_status;
@@ -1203,9 +1227,6 @@ static int tuner_g_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
}
vt->audmode = t->audmode;
}
- vt->capability |= V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO;
- vt->rangelow = radio_range[0] * 16000;
- vt->rangehigh = radio_range[1] * 16000;
return 0;
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFCv3 05/10] [media] v4l2-ioctl: Add tuner ioctl support for SDR radio type
The tuner ioctl's are optimized to handle internally the
differences between TV and normal AM/FM radio.
SDR is different than both, so it needs its own way of doing things.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/v4l2-core/v4l2-ioctl.c | 89 ++--
include/uapi/linux/videodev2.h | 5 ++
2 files changed, 70 insertions(+), 24 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index fd853da..f8bb171 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1296,6 +1296,19 @@ static int v4l_streamoff(const struct v4l2_ioctl_ops
*ops,
return ops->vidioc_streamoff(file, fh, *(unsigned int *)arg);
}
+static u32 v4l_device_type(struct video_device *vfd)
+{
+ switch (vfd->vfl_type) {
+ case VFL_TYPE_RADIO:
+ return V4L2_TUNER_RADIO;
+ case VFL_TYPE_SDR:
+ /* May be overriden by the driver */
+ return V4L2_TUNER_SDR_RADIO;
+ default:
+ return V4L2_TUNER_ANALOG_TV;
+ }
+}
+
static int v4l_g_tuner(const struct v4l2_ioctl_ops *ops,
struct file *file, void *fh, void *arg)
{
@@ -1303,8 +1316,7 @@ static int v4l_g_tuner(const struct v4l2_ioctl_ops *ops,
struct v4l2_tuner *p = arg;
int err;
- p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+ p->type = v4l_device_type(vfd);
err = ops->vidioc_g_tuner(file, fh, p);
if (!err)
p->capability |= V4L2_TUNER_CAP_FREQ_BANDS;
@@ -1316,9 +1328,18 @@ static int v4l_s_tuner(const struct v4l2_ioctl_ops *ops,
{
struct video_device *vfd = video_devdata(file);
struct v4l2_tuner *p = arg;
+ u32 type;
+
+ /*
+* For non-SDR devices, the type is defined by the dev type;
+* For SDR devices, if the type is not an SDR type return error
+*/
+ type = v4l_device_type(vfd);
+ if (type != VFL_TYPE_SDR)
+ p->type = type;
+ else if (!V4L2_TUNER_IS_SDR(p->type))
+ return -EINVAL;
- p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
return ops->vidioc_s_tuner(file, fh, p);
}
@@ -1340,8 +1361,7 @@ static int v4l_g_frequency(const struct v4l2_ioctl_ops
*ops,
struct video_device *vfd = video_devdata(file);
struct v4l2_frequency *p = arg;
- p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+ p->type = v4l_device_type(vfd);
return ops->vidioc_g_frequency(file, fh, p);
}
@@ -1352,10 +1372,13 @@ static int v4l_s_frequency(const struct v4l2_ioctl_ops
*ops,
const struct v4l2_frequency *p = arg;
enum v4l2_tuner_type type;
- type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
- if (p->type != type)
+ type = v4l_device_type(vfd);
+ if (type != VFL_TYPE_SDR) {
+ if (p->type != type)
+ return -EINVAL;
+ } else if (!V4L2_TUNER_IS_SDR(p->type))
return -EINVAL;
+
return ops->vidioc_s_frequency(file, fh, p);
}
@@ -1457,10 +1480,13 @@ static int v4l_s_hw_freq_seek(const struct
v4l2_ioctl_ops *ops,
struct v4l2_hw_freq_seek *p = arg;
enum v4l2_tuner_type type;
- type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
- if (p->type != type)
+ type = v4l_device_type(vfd);
+ if (type != VFL_TYPE_SDR) {
+ if (p->type != type)
+ return -EINVAL;
+ } else if (!V4L2_TUNER_IS_SDR(p->type))
return -EINVAL;
+
return ops->vidioc_s_hw_freq_seek(file, fh, p);
}
@@ -1974,12 +2000,19 @@ static int v4l_enum_freq_bands(const struct
v4l2_ioctl_ops *ops,
struct v4l2_frequency_band *p = arg;
enum v4l2_tuner_type type;
int err;
+ bool is_sdr;
- type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
- V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+ type = v4l_device_type(vfd);
+ if (type != VFL_TYPE_SDR) {
+ if (p->type != type)
+ return -EINVAL;
+ is_sdr = false;
+ } else {
+ if (!V4L2_TUNER_IS_SDR(type))
+ return -EINVAL;
+ is_sdr = true;
+ }
- if (type != p->type)
- return -EINVAL;
if (ops->vidioc_enum_freq_bands)
return ops->vidioc_enum_freq_bands(file, fh, p);
if (is_valid_ioctl(vfd, VIDIOC_G_TUNER)) {
@@ -1988,7 +2021,7 @@ static int v4l_enum_freq_bands(const struct
v4l2_ioctl_ops *ops,
.type = type,
[PATCH RFCv3 09/10] [media] tuner-core: add support to get the tuner frequency range
For SDR, the tuner range is different than TV or radio
ranges. Only the actual tuner driver knows what's the
range supported by the device. So, call the tuner to
get it, if the tuner supports. Otherwise, keep the TV
range, as is it broader than the radio one.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-core/dvb_frontend.h | 2 ++
drivers/media/v4l2-core/tuner-core.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 371b6ca..74a50e6 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -215,6 +215,8 @@ struct dvb_tuner_ops {
int (*get_frequency)(struct dvb_frontend *fe, u32 *frequency);
int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
int (*get_if_frequency)(struct dvb_frontend *fe, u32 *frequency);
+ int (*get_tuner_freq_range)(struct dvb_frontend *fe,
+ u32 *min_freq, u32 *max_freq);
#define TUNER_STATUS_LOCKED 1
#define TUNER_STATUS_STEREO 2
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index abdcda4..28bbcad 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -460,6 +460,13 @@ static void set_type(struct i2c_client *c, unsigned int
type,
t->tv_range[i] = tv_range[i] * 16;
}
+ if (fe_tuner_ops->get_tuner_freq_range) {
+ u32 min, max;
+ fe_tuner_ops->get_tuner_freq_range(&t->fe, &min, &max);
+ t->sdr_range[0] = min / 16;
+ t->sdr_range[1] = max / 16;
+ }
+
tuner_dbg("%s %s I2C addr 0x%02x with type %d used for 0x%02x\n",
c->adapter->name, c->driver->driver.name, c->addr << 1, type,
t->mode_mask);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/5] ARM: shmobile: BOCK-W: enable VIN and ML86V7667 in defconfig
From: Vladimir Barinov Add the VIN and ML86V7667 drivers to 'bockw_defconfig'. Signed-off-by: Vladimir Barinov Signed-off-by: Sergei Shtylyov --- arch/arm/configs/bockw_defconfig |7 +++ 1 file changed, 7 insertions(+) Index: renesas/arch/arm/configs/bockw_defconfig === --- renesas.orig/arch/arm/configs/bockw_defconfig +++ renesas/arch/arm/configs/bockw_defconfig @@ -76,6 +76,13 @@ CONFIG_SERIAL_SH_SCI_CONSOLE=y # CONFIG_HWMON is not set CONFIG_I2C=y CONFIG_I2C_RCAR=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_V4L_PLATFORM_DRIVERS=y +CONFIG_SOC_CAMERA=y +CONFIG_VIDEO_RCAR_VIN=y +# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set +CONFIG_VIDEO_ML86V7667=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_EHCI_HCD=y -- 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 4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667 support
From: Vladimir Barinov
Add ML86V7667 platform devices on BOCK-W board, configure VIN0/1 pins, and
register VIN0/1 devices with the ML86V7667 specific platform data.
Signed-off-by: Vladimir Barinov
[Sergei: some macro/comment cleanup; updated the copyrights.]
Signed-off-by: Sergei Shtylyov
---
arch/arm/mach-shmobile/board-bockw.c | 40 +++
1 file changed, 40 insertions(+)
Index: renesas/arch/arm/mach-shmobile/board-bockw.c
===
--- renesas.orig/arch/arm/mach-shmobile/board-bockw.c
+++ renesas/arch/arm/mach-shmobile/board-bockw.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2013 Renesas Solutions Corp.
* Copyright (C) 2013 Kuninori Morimoto
+ * Copyright (C) 2013 Cogent Embedded, Inc.
*
* 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
@@ -23,6 +24,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -56,12 +59,41 @@ static struct resource smsc911x_resource
static struct rcar_phy_platform_data usb_phy_platform_data;
+static struct rcar_vin_platform_data vin_platform_data = {
+ .flags = RCAR_VIN_BT656,
+};
+
+/* In the default configuration both decoders reside on I2C bus 0 */
+#define BOCKW_CAMERA(idx) \
+static struct i2c_board_info camera##idx##_info = {\
+ I2C_BOARD_INFO("ml86v7667", 0x41 + 2 * (idx)), \
+}; \
+ \
+static struct soc_camera_link iclink##idx##_ml86v7667 = { \
+ .bus_id = idx, \
+ .i2c_adapter_id = 0,\
+ .board_info = &camera##idx##_info, \
+};
+
+BOCKW_CAMERA(0);
+BOCKW_CAMERA(1);
+
static const struct pinctrl_map bockw_pinctrl_map[] = {
/* SCIF0 */
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
"scif0_data_a", "scif0"),
PIN_MAP_MUX_GROUP_DEFAULT("sh-sci.0", "pfc-r8a7778",
"scif0_ctrl", "scif0"),
+ /* VIN0 */
+ PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
+ "vin0_clk", "vin0"),
+ PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.0", "pfc-r8a7778",
+ "vin0_data8", "vin0"),
+ /* VIN1 */
+ PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
+ "vin1_clk", "vin1"),
+ PIN_MAP_MUX_GROUP_DEFAULT("rcar_vin.1", "pfc-r8a7778",
+ "vin1_data8", "vin1"),
};
#define FPGA 0x1820
@@ -74,6 +106,14 @@ static void __init bockw_init(void)
r8a7778_init_irq_extpin(1);
r8a7778_add_standard_devices();
r8a7778_add_usb_phy_device(&usb_phy_platform_data);
+ r8a7778_add_vin_device(0, &vin_platform_data);
+ r8a7778_add_vin_device(1, &vin_platform_data);
+ platform_device_register_data(&platform_bus, "soc-camera-pdrv", 0,
+ &iclink0_ml86v7667,
+ sizeof(iclink0_ml86v7667));
+ platform_device_register_data(&platform_bus, "soc-camera-pdrv", 1,
+ &iclink1_ml86v7667,
+ sizeof(iclink1_ml86v7667));
pinctrl_register_mappings(bockw_pinctrl_map,
ARRAY_SIZE(bockw_pinctrl_map));
--
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 3/5] ARM: shmobile: r8a7778: add VIN support
From: Vladimir Barinov
Add VIN clocks and platform devices on R8A7778 SoC; add function to register
the VIN platform devices.
Signed-off-by: Vladimir Barinov
[Sergei: added 'id' parameter check to r8a7779_add_vin_device(), used '*pdata'
in *sizeof* operator there, renamed some variables, marked 'vin[01]_info' as
'__initdata'.]
Signed-off-by: Sergei Shtylyov
---
arch/arm/mach-shmobile/clock-r8a7778.c|5 +++
arch/arm/mach-shmobile/include/mach/r8a7778.h |3 ++
arch/arm/mach-shmobile/setup-r8a7778.c| 33 ++
3 files changed, 41 insertions(+)
Index: renesas/arch/arm/mach-shmobile/clock-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7778.c
@@ -106,6 +106,7 @@ static struct clk *main_clks[] = {
enum {
MSTP323, MSTP322, MSTP321,
MSTP114,
+ MSTP110, MSTP109,
MSTP100,
MSTP030, MSTP029,
MSTP028, MSTP027, MSTP026, MSTP025, MSTP024, MSTP023, MSTP022, MSTP021,
@@ -117,6 +118,8 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP322] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 22, 0), /* SDHI1 */
[MSTP321] = SH_CLK_MSTP32(&p_clk, MSTPCR3, 21, 0), /* SDHI2 */
[MSTP114] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 14, 0), /* Ether */
+ [MSTP110] = SH_CLK_MSTP32(&s_clk, MSTPCR1, 10, 0), /* VIN0 */
+ [MSTP109] = SH_CLK_MSTP32(&s_clk, MSTPCR1, 9, 0), /* VIN1 */
[MSTP100] = SH_CLK_MSTP32(&p_clk, MSTPCR1, 0, 0), /* USB0/1 */
[MSTP030] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 30, 0), /* I2C0 */
[MSTP029] = SH_CLK_MSTP32(&p_clk, MSTPCR0, 29, 0), /* I2C1 */
@@ -140,6 +143,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP322]), /* SDHI1 */
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP321]), /* SDHI2 */
CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP114]), /* Ether */
+ CLKDEV_DEV_ID("rcar_vin.0", &mstp_clks[MSTP110]), /* VIN0 */
+ CLKDEV_DEV_ID("rcar_vin.1", &mstp_clks[MSTP109]), /* VIN1 */
CLKDEV_DEV_ID("ehci-platform", &mstp_clks[MSTP100]), /* USB EHCI
port0/1 */
CLKDEV_DEV_ID("ohci-platform", &mstp_clks[MSTP100]), /* USB OHCI
port0/1 */
CLKDEV_DEV_ID("i2c-rcar.0", &mstp_clks[MSTP030]), /* I2C0 */
Index: renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
===
--- renesas.orig/arch/arm/mach-shmobile/include/mach/r8a7778.h
+++ renesas/arch/arm/mach-shmobile/include/mach/r8a7778.h
@@ -21,11 +21,14 @@
#include
#include
#include
+#include
extern void r8a7778_add_standard_devices(void);
extern void r8a7778_add_standard_devices_dt(void);
extern void r8a7778_add_ether_device(struct sh_eth_plat_data *pdata);
extern void r8a7778_add_usb_phy_device(struct rcar_phy_platform_data *pdata);
+extern void r8a7778_add_vin_device(int id,
+ struct rcar_vin_platform_data *pdata);
extern void r8a7778_init_late(void);
extern void r8a7778_init_delay(void);
extern void r8a7778_init_irq(void);
Index: renesas/arch/arm/mach-shmobile/setup-r8a7778.c
===
--- renesas.orig/arch/arm/mach-shmobile/setup-r8a7778.c
+++ renesas/arch/arm/mach-shmobile/setup-r8a7778.c
@@ -265,6 +265,39 @@ void __init r8a7778_sdhi_init(int id,
info, sizeof(*info));
}
+/* VIN */
+#define R8A7778_VIN(idx) \
+static struct resource vin##idx##_resources[] = { \
+ DEFINE_RES_MEM(0xffc5 + 0x1000 * (idx), 0x1000),\
+ DEFINE_RES_IRQ(gic_iid(0x5a)), \
+}; \
+ \
+static struct platform_device_info vin##idx##_info __initdata = { \
+ .parent = &platform_bus,\
+ .name = "rcar_vin", \
+ .id = idx, \
+ .res= vin##idx##_resources, \
+ .num_res= ARRAY_SIZE(vin##idx##_resources), \
+ .dma_mask = DMA_BIT_MASK(32), \
+}
+
+R8A7778_VIN(0);
+R8A7778_VIN(1);
+
+static struct platform_device_info *vin_info_table[] __initdata = {
+ &vin0_info,
+ &vin1_info,
+};
+
+void __init r8a7778_add_vin_device(int id, struct rcar_vin_platform_data
*pdata)
+{
+ BUG_ON(id < 0 || id > 1);
+
+ vin_info_table[id]->data = pdata;
+ vin_info_table[id]->size_data = sizeof(*pdata);
+ platform_device_register_full(vin_info_table[id]);
+}
+
void __init r8a7778_add_standard_devices(void)
{
int i;
--
To unsubscri
[PATCH v2 1/5] V4L2: I2C: ML86V7667 video decoder driver
From: Vladimir Barinov Add OKI Semiconductor ML86V7667 video decoder driver. Signed-off-by: Vladimir Barinov [Sergei: added v4l2_device_unregister_subdev() call to the error cleanup path of ml86v7667_probe(); some cleanup.] Signed-off-by: Sergei Shtylyov --- Changes since the original posting: - fixed ACCC_CHROMA_CB_MASK; - got rid from the autodetection feature; - removed querystd() method calls from other methods; - removed deprecated g_chip_ident() method. drivers/media/i2c/Kconfig |9 drivers/media/i2c/Makefile|1 drivers/media/i2c/ml86v7667.c | 473 ++ 3 files changed, 483 insertions(+) Index: renesas/drivers/media/i2c/Kconfig === --- renesas.orig/drivers/media/i2c/Kconfig +++ renesas/drivers/media/i2c/Kconfig @@ -227,6 +227,15 @@ config VIDEO_KS0127 To compile this driver as a module, choose M here: the module will be called ks0127. +config VIDEO_ML86V7667 + tristate "OKI ML86V7667 video decoder" + depends on VIDEO_V4L2 && I2C + ---help--- + Support for the OKI Semiconductor ML86V7667 video decoder. + + To compile this driver as a module, choose M here: the + module will be called ml86v7667. + config VIDEO_SAA7110 tristate "Philips SAA7110 video decoder" depends on VIDEO_V4L2 && I2C Index: renesas/drivers/media/i2c/Makefile === --- renesas.orig/drivers/media/i2c/Makefile +++ renesas/drivers/media/i2c/Makefile @@ -64,3 +64,4 @@ obj-$(CONFIG_VIDEO_AS3645A) += as3645a.o obj-$(CONFIG_VIDEO_SMIAPP_PLL) += smiapp-pll.o obj-$(CONFIG_VIDEO_AK881X) += ak881x.o obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o +obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o Index: renesas/drivers/media/i2c/ml86v7667.c === --- /dev/null +++ renesas/drivers/media/i2c/ml86v7667.c @@ -0,0 +1,473 @@ +/* + * OKI Semiconductor ML86V7667 video decoder driver + * + * Author: Vladimir Barinov + * Copyright (C) 2013 Cogent Embedded, Inc. + * Copyright (C) 2013 Renesas Solutions Corp. + * + * 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 + +#define DRV_NAME "ml86v7667" + +/* Subaddresses */ +#define MRA_REG0x00 /* Mode Register A */ +#define MRC_REG0x02 /* Mode Register C */ +#define LUMC_REG 0x0C /* Luminance Control */ +#define CLC_REG0x10 /* Contrast level control */ +#define SSEPL_REG 0x11 /* Sync separation level */ +#define CHRCA_REG 0x12 /* Chrominance Control A */ +#define ACCC_REG 0x14 /* ACC Loop filter & Chrominance control */ +#define ACCRC_REG 0x15 /* ACC Reference level control */ +#define HUE_REG0x16 /* Hue control */ +#define ADC2_REG 0x1F /* ADC Register 2 */ +#define PLLR1_REG 0x20 /* PLL Register 1 */ +#define STATUS_REG 0x2C /* STATUS Register */ + +/* Mode Register A register bits */ +#define MRA_OUTPUT_MODE_MASK (3 << 6) +#define MRA_ITUR_BT601 (1 << 6) +#define MRA_ITUR_BT656 (0 << 6) +#define MRA_INPUT_MODE_MASK(7 << 3) +#define MRA_PAL_BT601 (4 << 3) +#define MRA_NTSC_BT601 (0 << 3) +#define MRA_REGISTER_MODE (1 << 0) + +/* Mode Register C register bits */ +#define MRC_AUTOSELECT (1 << 7) + +/* Luminance Control register bits */ +#define LUMC_ONOFF_SHIFT 7 +#define LUMC_ONOFF_MASK(1 << 7) + +/* Contrast level control register bits */ +#define CLC_CONTRAST_ONOFF (1 << 7) +#define CLC_CONTRAST_MASK 0x0F + +/* Sync separation level register bits */ +#define SSEPL_LUMINANCE_ONOFF (1 << 7) +#define SSEPL_LUMINANCE_MASK 0x7F + +/* Chrominance Control A register bits */ +#define CHRCA_MODE_SHIFT 6 +#define CHRCA_MODE_MASK(1 << 6) + +/* ACC Loop filter & Chrominance control register bits */ +#define ACCC_CHROMA_CR_SHIFT 3 +#define ACCC_CHROMA_CR_MASK(7 << 3) +#define ACCC_CHROMA_CB_SHIFT 0 +#define ACCC_CHROMA_CB_MASK(7 << 0) + +/* ACC Reference level control register bits */ +#define ACCRC_CHROMA_MASK 0xfc +#define ACCRC_CHROMA_SHIFT 2 + +/* ADC Register 2 register bits */ +#define ADC2_CLAMP_VOLTAGE_MASK(7 << 1) +#define ADC2_CLAMP_VOLTAGE(n) ((n & 7) << 1) + +/* PLL Register 1 register bits */ +#define PLLR1_FIXED_CLOCK (1 << 7) + +/* STATUS Register register bits */ +#define STATUS_HLOCK_DETECT(1 << 3) +#def
[PATCH v2 0/5] OKI ML86V7667 driver and R8A7778/BOCK-W VIN support
Hello. Here's the set of 5 patches against the Simon Horman's 'renesas.git' repo, 'renesas-next-20130419' tag and my recent yet unapplied patches. Here we add the OKI ML86V7667 video decoder driver and the VIN platform code working on the R8A7778/BOCK-W with ML86V7667. The driver patch also applies (with offsets) to Mauro's 'media_tree.git'... [1/5] V4L2: I2C: ML86V7667 video decoder driver [2/5] sh-pfc: r8a7778: add VIN pin groups [3/5] ARM: shmobile: r8a7778: add VIN support [4/5] ARM: shmobile: BOCK-W: add VIN and ML86V7667 support [5/5] ARM: shmobile: BOCK-W: enable VIN and ML86V7667 in defconfig WBR, Sergei -- 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: Sun Apr 21 19:00:22 CEST 2013 git branch: test git hash: 6695be6863b75620ffa6d422965680ce785cb7c8 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: OK linux-3.9-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] [media] media: info leak in media_device_enum_entities()
On Sun, Apr 21, 2013 at 01:51:56PM +0200, walter harms wrote:
>
>
> Am 21.04.2013 13:10, schrieb Dan Carpenter:
> > The last part of the "u_ent.name" buffer isn't cleared so it still has
> > uninitialized stack memory.
> >
> > Signed-off-by: Dan Carpenter
> >
> > diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> > index 99b80b6..1957c0d 100644
> > --- a/drivers/media/media-device.c
> > +++ b/drivers/media/media-device.c
> > @@ -102,9 +102,12 @@ static long media_device_enum_entities(struct
> > media_device *mdev,
> > return -EINVAL;
> >
> > u_ent.id = ent->id;
> > - u_ent.name[0] = '\0';
> > - if (ent->name)
> > - strlcpy(u_ent.name, ent->name, sizeof(u_ent.name));
> > + if (ent->name) {
> > + strncpy(u_ent.name, ent->name, sizeof(u_ent.name));
> > + u_ent.name[sizeof(u_ent.name) - 1] = '\0';
> > + } else {
> > + memset(u_ent.name, 0, sizeof(u_ent.name));
> > + }
>
> I would always memset()
> and then do strncpy() for sizeof(u_ent.name) - 1
> the rest is always zero.
Both ways are fine. You'd still have to test for "if (ent->name)",
of course. This way is a little faster because I do the test first.
Mauro, if you want I can redo it?
regards,
dan carpenter
--
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 RFCv1] [media] V4L2 sdr API: Add fields for VIDIOC_[G|S]_TUNER
Em 20-04-2013 17:10, Mauro Carvalho Chehab escreveu:
SDR radio requires some other things at VIDIOC_[G|S]_TUNER.
Change the ioctl to support them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 30 +---
drivers/media/tuners/tuner-xc2028.c| 2 ++
include/uapi/linux/videodev2.h | 40 --
3 files changed, 65 insertions(+), 7 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
index 6cc8201..b8a3bcf 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
@@ -200,9 +200,10 @@ audio
_SAP flag is cleared in the
capability field, the corresponding
V4L2_TUNER_SUB_ flag must not be set
-here.This field is valid only if this is the tuner of the
+here.
+This field is valid only for if this is the tuner of the
current video input, or when the structure refers to a radio
-tuner.
+tuner. This field is not used by SDR tuners.
__u32
@@ -216,7 +217,7 @@ unless the requested mode is invalid or unsupported. See
Currently this is the only field of struct
v4l2_tuner applications can
-change.
+change. This field is not used by SDR tuners.
__u32
@@ -234,7 +235,28 @@ settles at zero, &ie; range is what? -->
__u32
- reserved[4]
+ sample_rate
+ Sampling rate used by a SDR tuner, in Hz.
+ This value is valid only for SDR tuners.
+
+
+ __u32
+ bandwidth
+ Bandwidth allowed by the SDR tuner
+ low-pass saw filter, in Hz. This value is valid only for
+ SDR tuners.
+
+
+ __u32
+ int_freq
+ Intermediate Frequency (IF) used by
+ the tuner, in Hz. This value is valid only for
+ VIDIOC_G_TUNER, and it is valid only
+ on SDR tuners.
+
+
+ __u32
+ reserved[3]
Reserved for future extensions. Drivers and
applications must set the array to zero.
diff --git a/drivers/media/tuners/tuner-xc2028.c
b/drivers/media/tuners/tuner-xc2028.c
index 878d2c4..c61163f 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1020,6 +1020,8 @@ static int generic_set_freq(struct dvb_frontend *fe, u32
freq /* in HZ */,
* Maybe this might also be needed for DTV.
*/
switch (new_type) {
+ default:/* SDR currently not supported */
+ goto ret;
case V4L2_TUNER_ANALOG_TV:
rc = send_seq(priv, {0x00, 0x00});
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 974c49d..765b646 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -160,6 +160,24 @@ enum v4l2_tuner_type {
V4L2_TUNER_RADIO = 1,
V4L2_TUNER_ANALOG_TV = 2,
V4L2_TUNER_DIGITAL_TV= 3,
+/*
+ * Even not decoding the signal, SDR tuners may require to adjust IF,
+ * low pass filters, center frequency, etc based on the signal envelope,
+ * and its bandwidth. While we might be using here the V4L2_STD_*
+ * types, plus DVB delsys, that doesn't seem to be the better thing to
+ * do, as:
+ * 1) it would require 64 bits for V4L2 std + 32 bits for DVB std;
+ * 2) non-TV types of envelopes won't work.
+ *
+ * So, add a separate enum to describe the possible types of SDR envelopes.
+ */
+ V4L2_TUNER_SDR_RADIO, /* Generic non-optimized Radio range */
+ V4L2_TUNER_SDR_ATV_PAL, /* Optimize for Analog TV, PAL */
+ V4L2_TUNER_SDR_ATV_NTSC,/* Optimize for Analog TV, NTSC */
+ V4L2_TUNER_SDR_ATV_SECAM, /* Optimize for Analog TV, SECAM */
Hmm... this will not work. There are several tuners that require to know
more about the standard than just the color encoding.
Ok, there are several tuners that also do PLL lock on the audio sub-carrier,
as they have there audio decoder like tda9887 (on analog tuners)
or an equivalent IP block on silicon tuners. I'm not even sure if such
tuners will work properly as SDR. Perhaps it is possible to program them
on a generic mode.
So, I'm starting to suspect that, in order to support SDR devices with
a TV tuner, it will need to allow selecting an analog standard.
Perhaps the best way is to use here, instead just one type for analog TV,
and accept VIDIOC_*_STD ioctls to fine tune, if tuner needs it.
On the next RFC, I'll just merge those three into:
V4L2_TUNER_SDR_ATV
+ V4L2_TUNER_SDR_DTV_ATSC,/* Optimize for Digital TV, ATSC */
+ V4L2_TUNER_SDR_DTV_DVBT,/* Optimize for Digital TV, DVB-T */
+ V4L2_TUNER_SDR_
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
Hi Inki,
On Sunday 21 of April 2013 22:36:08 Inki Dae wrote:
> 2013/4/21 Tomasz Figa
>
> > Hi,
> >
> > On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> > > On 8 April 2013 16:37, Vikas Sajjan wrote:
> > > > While migrating to common clock framework (CCF), I found that the
> > > > FIMD
> > > > clocks were pulled down by the CCF.
> > > > If CCF finds any clock(s) which has NOT been claimed by any of the
> > > > drivers, then such clock(s) are PULLed low by CCF.
> > > >
> > > > Calling clk_prepare() for FIMD clocks fixes the issue.
> > > >
> > > > This patch also replaces clk_disable() with clk_unprepare() during
> > > > exit, since clk_prepare() is called in fimd_probe().
> > >
> > > I asked you about fixing your commit log too.. It still looks
> > > incorrect
> > > to me.
> > >
> > > This patch doesn't have anything to do with CCF pulling clocks down,
> > > but calling clk_prepare() before clk_enable() is must now.. that's
> > > it.. nothing more.
> >
> > I fully agree.
> >
> > The message should be something like:
> >
> > Common Clock Framework introduced the need to prepare clocks before
> > enabling them, otherwise clk_enable() fails. This patch adds
> > clk_prepare calls to the driver.
> >
> > and that's all.
> >
> > What you are observing as "CCF pulling clocks down" is the fact that
> > clk_enable() fails if the clock is not prepared and so the clock is
> > not
> > enabled in result.
> >
> > Another thing is that CCF is not pulling anything down. GPIO pins can
> > be pulled down (or up or not pulled), but clocks can be masked, gated
> > or simply disabled - this does not imply their signal level.
> >
> > > > Signed-off-by: Vikas Sajjan
> > > > ---
> > > >
> > > > Changes since v3:
> > > > - added clk_prepare() in fimd_probe() and clk_unprepare()
> > > > in
> > > > fimd_remove()>
> > > >
> > > > as suggested by Viresh Kumar
> > > >
> > > > Changes since v2:
> > > > - moved clk_prepare_enable() and clk_disable_unprepare()
> > > > from
> > > > fimd_probe() to fimd_clock() as suggested by Inki Dae
> > > > >
> > > >
> > > > Changes since v1:
> > > > - added error checking for clk_prepare_enable() and also
> > > > replaced
> > > > clk_disable() with clk_disable_unprepare() during exit.
> > > >
> > > > ---
> > > >
> > > > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
> > > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..aa22370
> > > > 100644
> > > > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > > > @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device
> > > > *pdev)>
> > > >
> > > > return ret;
> > > >
> > > > }
> > > >
> > > > + ret = clk_prepare(ctx->bus_clk);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > +
> > > > + ret = clk_prepare(ctx->lcd_clk);
> > > > + if (ret < 0) {
> > > > + clk_unprepare(ctx->bus_clk);
> > > > + return ret;
> > > > + }
> > > > +
> >
> > Why not just simply use clk_prepare_enable() instead of all calls to
> > clk_enable() in the driver?
> >
> > Same goes for s/clk_disable/clk_disable_unprepare/ .
>
> I agree with you. Using clk_prepare_enable() is more clear. Actually I
> had already commented on this. Please see the patch v2. But this way
> also looks good to me.
Well, both versions are technically correct and will have the same effect
for Exynos SoC clocks, since only enable/disable ops change hardware
state.
However if we look at general meaning of those generic ops, the clock will
remain prepared for all the time the driver is loaded, even if the device
is runtime suspended. Again on Exynos SoCs this won't have any effect, but
I think we should respect general Common Clock Framework semantics anyway.
> > > > ctx->vidcon0 = pdata->vidcon0;
> > > > ctx->vidcon1 = pdata->vidcon1;
> > > > ctx->default_win = pdata->default_win;
> > > >
> > > > @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device
> > > > *pdev)>
> > > >
> > > > if (ctx->suspended)
> > > >
> > > > goto out;
> > > >
> > > > - clk_disable(ctx->lcd_clk);
> > > > - clk_disable(ctx->bus_clk);
> > > > + clk_unprepare(ctx->lcd_clk);
> > > > + clk_unprepare(ctx->bus_clk);
> > >
> > > This looks wrong again.. You still need to call clk_disable() to
> > > make
> > > clk enabled
> > > count zero...
> >
> > Viresh is right again here.
>
> Ok, you two guys say together this looks wrong so I'd like to take more
> checking. I thought that clk->clk_enable is 1 at here and it would be 0
> by pm_runtimg_put_sync(). Is there any my missing point?
You're reas
Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API
Em 21-04-2013 09:03, Antti Palosaari escreveu: You just jumped over all my previous hard work and introduced implementation, as I tried still to study and finalize all requirements As it is posted on the topics, this is RFC. I'm sure changes will be needed there before having it on some state that it can be merged. http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt Well, we discussed there already: http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/63123 And I proposed several a few implementation details there. I'm just going deeper and writing RFC patches to start test/implement it. I don't like that. I want just study all requirements and implement those as a once and correctly. Ok, there are topics there yet to study, but in order to to that, a real implementation is needed. Only implementing it is possible to cover all that it is needed. That one does not meet very many of those listed requirements. True. It doesn't cover anything that IMO it should be covered by V4L2 controls. My focus right now is to implement support for: - set/get frequency; - get IF; - set/get standard envelope/bandwidth; - set/get sample rate (the real code will only show up when start implementing a SDR driver - I'm yet far behind this point); - get tuner frequency range. Adding new controls are the easy task, as it doesn't require core changes (well, except for a table there with the control names). However, adding core support for SDR is harder, as it requires to work on several layers at the V4L2 core. I'm working today on more patches for it, at tuner-core. Lots of changes are required there, in order to allow supporting the existing tuner. My current plan is to test SDR with cx88, so, I need tuner-core to work fine with it. I've coded only ~50% of what's needed, and that represents: 15 files changed, 379 insertions(+), 94 deletions(-) Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Motion Detection API
On Fri, 12 Apr 2013 17:36:16 +0200 Hans Verkuil wrote: > This RFC looks at adding support for motion detection to V4L2. This > is the main missing piece that prevents the go7007 and solo6x10 > drivers from being moved into mainline from the staging directory. <...> > Comment? Questions? +1. I like it :). signature.asc Description: PGP signature
Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API
You just jumped over all my previous hard work and introduced implementation, as I tried still to study and finalize all requirements http://palosaari.fi/linux/kernel_sdr_api_requirement_specification.txt I don't like that. I want just study all requirements and implement those as a once and correctly. That one does not meet very many of those listed requirements. Antti On 04/21/2013 02:10 PM, Mauro Carvalho Chehab wrote: Em 21-04-2013 07:34, Hans Verkuil escreveu: On Sun April 21 2013 12:09:51 Mauro Carvalho Chehab wrote: Em 21-04-2013 06:34, Hans Verkuil escreveu: Hi Mauro, On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote: This is a version 2 of the V4L2 API bits to support Software Digital Radio (SDR). It looks pretty good to me. Just one question though: what is your rationale for choosing a new device name (/dev/sdrX) instead of using the existing /dev/radioX? I'm not saying I'm opposed to it, in fact I agree with it, but I think the reasons for it should be stated explicitly. Because a SDR radio is different than a normal radio device: A normal radio device is actually radio and hardware demod. As the demod is in hardware, several things that are required for the demodulate the signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to the device and aren't part of the API. SDR radio, on the other hand, requires that every control needed by the tuner to be exposed on userspace, as userspace needs to adjust the software decoder to match them. So, they're different. Btw, it is also possible that the same device to offer analog TV, digital TV, hardware-decoded radio and SDR. One example of such devices are cx88. The existing drivers supports already hardware demodulers, but the device also allows to export the collected samples to userspace. It is just a matter of programming the cx88 RISC code to do that. Internally, cx2388x has 2 10 bits ADC, one for baseband (composite inputs) and another one for IF signal capable of working up to 35.44 MHz sampling rate (on "8x FSC PAL" supported mode). It would be easy to export its output to userspace. Btw, while seeking for more data about SDR this weekend, I discovered one project doing exactly that: http://www.geocities.ws/how_chee/cx23881fc6.htm I did a very quick look at its source code. It is limited, as it works only at a fixed sample rate of 27 MHz provides only 8 bits samples[1], and I'm not sure if it allows using both ADCs. Yet, It shows that it is possible that a driver/subdrivers to offer the 4 different types of devices: - analog TV; - digital TV; - radio; - SDR. So, IMO we should not abuse of /dev/radio for SDR. I agree. I just wanted to have it explicit :-) Sure. I'll summarize the above at the commit patch on a next version. I also think we should provide and maintain a library doing the decoding for SDR that is part of v4l-utils. Otherwise you'll end up with a big userspace mess. I partially agree. I've seen some SDR usages that are experimental app-specific stuff like GSM and ADSB receivers. You can see a sample of such projects that use one of the existing userspace libraries at: http://sdr.osmocom.org/trac/wiki/rtl-sdr#KnownApps In principle, I don't think it is worth to invest our time handling all sorts of possible decoders at v4l-apps[1]. It makes more sense to offer instead low level library there to allow applications to abstract from hardware differences, like doing fourcc conversions. There are at least two ways of outputting data on the known devices: - simple ADC samples in time domain; - IF using in-phase/quadrature (I/Q) samples. Also, the number of bits can vary from device to device, being 8 bits and 10 bits the most common ones. I think I saw some analog TV devices using a 12 bits sampler somewhere, but I can't remember if it is flexible enough to output sampled data to the DMA engine, or if they're just simple I2C devices that output only decoded data via I2S. Anyway, the low-level library should take care of those differences, just like it is done at libv4l for image standards. With time, the library may also provide a basic set of decoders for more common analog radio standards: FM, AM DSB-FC, AM DSB-SC, AM SSB. It may also provide analog TV decoders and even digital TV ones, but writing them may take a lot of time. It could be good projects for Google's Summer of Code and similar events. I would love to have a set of those decodes there, as they can offer a nice set of instrumentation tools to test what is being received on some place and calibrate device drivers. I would love even more to have SDR TX devices. With both TX and RX working, one could send us a sample of what they're receiving on some place, and this signal could be used by the developer to test their devices, improving the driver to better receive such signals. I suspect that low-cost SDR TX devices will come with time. [1] Ok, if someone wants to ad
Re: [patch] [media] media: info leak in media_device_enum_entities()
Am 21.04.2013 13:10, schrieb Dan Carpenter:
> The last part of the "u_ent.name" buffer isn't cleared so it still has
> uninitialized stack memory.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
> index 99b80b6..1957c0d 100644
> --- a/drivers/media/media-device.c
> +++ b/drivers/media/media-device.c
> @@ -102,9 +102,12 @@ static long media_device_enum_entities(struct
> media_device *mdev,
> return -EINVAL;
>
> u_ent.id = ent->id;
> - u_ent.name[0] = '\0';
> - if (ent->name)
> - strlcpy(u_ent.name, ent->name, sizeof(u_ent.name));
> + if (ent->name) {
> + strncpy(u_ent.name, ent->name, sizeof(u_ent.name));
> + u_ent.name[sizeof(u_ent.name) - 1] = '\0';
> + } else {
> + memset(u_ent.name, 0, sizeof(u_ent.name));
> + }
I would always memset()
and then do strncpy() for sizeof(u_ent.name) - 1
the rest is always zero.
re,
wh
> u_ent.type = ent->type;
> u_ent.revision = ent->revision;
> u_ent.flags = ent->flags;
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" 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
[patch] [media] media: info leak in media_device_enum_entities()
The last part of the "u_ent.name" buffer isn't cleared so it still has
uninitialized stack memory.
Signed-off-by: Dan Carpenter
diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 99b80b6..1957c0d 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -102,9 +102,12 @@ static long media_device_enum_entities(struct media_device
*mdev,
return -EINVAL;
u_ent.id = ent->id;
- u_ent.name[0] = '\0';
- if (ent->name)
- strlcpy(u_ent.name, ent->name, sizeof(u_ent.name));
+ if (ent->name) {
+ strncpy(u_ent.name, ent->name, sizeof(u_ent.name));
+ u_ent.name[sizeof(u_ent.name) - 1] = '\0';
+ } else {
+ memset(u_ent.name, 0, sizeof(u_ent.name));
+ }
u_ent.type = ent->type;
u_ent.revision = ent->revision;
u_ent.flags = ent->flags;
--
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 RFC v2 0/3] Add SDR at V4L2 API
Em 21-04-2013 07:34, Hans Verkuil escreveu: On Sun April 21 2013 12:09:51 Mauro Carvalho Chehab wrote: Em 21-04-2013 06:34, Hans Verkuil escreveu: Hi Mauro, On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote: This is a version 2 of the V4L2 API bits to support Software Digital Radio (SDR). It looks pretty good to me. Just one question though: what is your rationale for choosing a new device name (/dev/sdrX) instead of using the existing /dev/radioX? I'm not saying I'm opposed to it, in fact I agree with it, but I think the reasons for it should be stated explicitly. Because a SDR radio is different than a normal radio device: A normal radio device is actually radio and hardware demod. As the demod is in hardware, several things that are required for the demodulate the signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to the device and aren't part of the API. SDR radio, on the other hand, requires that every control needed by the tuner to be exposed on userspace, as userspace needs to adjust the software decoder to match them. So, they're different. Btw, it is also possible that the same device to offer analog TV, digital TV, hardware-decoded radio and SDR. One example of such devices are cx88. The existing drivers supports already hardware demodulers, but the device also allows to export the collected samples to userspace. It is just a matter of programming the cx88 RISC code to do that. Internally, cx2388x has 2 10 bits ADC, one for baseband (composite inputs) and another one for IF signal capable of working up to 35.44 MHz sampling rate (on "8x FSC PAL" supported mode). It would be easy to export its output to userspace. Btw, while seeking for more data about SDR this weekend, I discovered one project doing exactly that: http://www.geocities.ws/how_chee/cx23881fc6.htm I did a very quick look at its source code. It is limited, as it works only at a fixed sample rate of 27 MHz provides only 8 bits samples[1], and I'm not sure if it allows using both ADCs. Yet, It shows that it is possible that a driver/subdrivers to offer the 4 different types of devices: - analog TV; - digital TV; - radio; - SDR. So, IMO we should not abuse of /dev/radio for SDR. I agree. I just wanted to have it explicit :-) Sure. I'll summarize the above at the commit patch on a next version. I also think we should provide and maintain a library doing the decoding for SDR that is part of v4l-utils. Otherwise you'll end up with a big userspace mess. I partially agree. I've seen some SDR usages that are experimental app-specific stuff like GSM and ADSB receivers. You can see a sample of such projects that use one of the existing userspace libraries at: http://sdr.osmocom.org/trac/wiki/rtl-sdr#KnownApps In principle, I don't think it is worth to invest our time handling all sorts of possible decoders at v4l-apps[1]. It makes more sense to offer instead low level library there to allow applications to abstract from hardware differences, like doing fourcc conversions. There are at least two ways of outputting data on the known devices: - simple ADC samples in time domain; - IF using in-phase/quadrature (I/Q) samples. Also, the number of bits can vary from device to device, being 8 bits and 10 bits the most common ones. I think I saw some analog TV devices using a 12 bits sampler somewhere, but I can't remember if it is flexible enough to output sampled data to the DMA engine, or if they're just simple I2C devices that output only decoded data via I2S. Anyway, the low-level library should take care of those differences, just like it is done at libv4l for image standards. With time, the library may also provide a basic set of decoders for more common analog radio standards: FM, AM DSB-FC, AM DSB-SC, AM SSB. It may also provide analog TV decoders and even digital TV ones, but writing them may take a lot of time. It could be good projects for Google's Summer of Code and similar events. I would love to have a set of those decodes there, as they can offer a nice set of instrumentation tools to test what is being received on some place and calibrate device drivers. I would love even more to have SDR TX devices. With both TX and RX working, one could send us a sample of what they're receiving on some place, and this signal could be used by the developer to test their devices, improving the driver to better receive such signals. I suspect that low-cost SDR TX devices will come with time. [1] Ok, if someone wants to add support for those app-specific decoders, maintain it there and it doesn't offer any legal issues that would restrict v4l-utils distribution, I'm not against to add it there. And we want this checked by v4l2-compliance, and qv4l2 should be able to use the library so we have at least one application that can handle it. Regards, Hans Regards, Mauro [1] The trick is to program the cx88 RISC to
Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API
On Sun April 21 2013 12:09:51 Mauro Carvalho Chehab wrote: > Em 21-04-2013 06:34, Hans Verkuil escreveu: > > Hi Mauro, > > > > On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote: > >> This is a version 2 of the V4L2 API bits to support Software Digital > >> Radio (SDR). > > > > It looks pretty good to me. Just one question though: what is your rationale > > for choosing a new device name (/dev/sdrX) instead of using the existing > > /dev/radioX? > > > > I'm not saying I'm opposed to it, in fact I agree with it, but I think the > > reasons for it should be stated explicitly. > > Because a SDR radio is different than a normal radio device: > > A normal radio device is actually radio and hardware demod. As the demod > is in hardware, several things that are required for the demodulate the > signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to > the device and aren't part of the API. > > SDR radio, on the other hand, requires that every control needed by the > tuner to be exposed on userspace, as userspace needs to adjust the > software decoder to match them. > > So, they're different. > > Btw, it is also possible that the same device to offer analog TV, > digital TV, hardware-decoded radio and SDR. One example of such devices > are cx88. The existing drivers supports already hardware demodulers, > but the device also allows to export the collected samples to userspace. > It is just a matter of programming the cx88 RISC code to do that. > > Internally, cx2388x has 2 10 bits ADC, one for baseband (composite inputs) > and another one for IF signal capable of working up to 35.44 MHz sampling > rate (on "8x FSC PAL" supported mode). It would be easy to export its > output to userspace. > > Btw, while seeking for more data about SDR this weekend, I discovered > one project doing exactly that: > > http://www.geocities.ws/how_chee/cx23881fc6.htm > > I did a very quick look at its source code. It is limited, as it works > only at a fixed sample rate of 27 MHz provides only 8 bits samples[1], and > I'm not sure if it allows using both ADCs. > > Yet, It shows that it is possible that a driver/subdrivers to offer > the 4 different types of devices: > - analog TV; > - digital TV; > - radio; > - SDR. > > So, IMO we should not abuse of /dev/radio for SDR. I agree. I just wanted to have it explicit :-) I also think we should provide and maintain a library doing the decoding for SDR that is part of v4l-utils. Otherwise you'll end up with a big userspace mess. And we want this checked by v4l2-compliance, and qv4l2 should be able to use the library so we have at least one application that can handle it. Regards, Hans > > Regards, > Mauro > > [1] The trick is to program the cx88 RISC to output data from the > samplers, instead of from the demods. We do that already for the > audio standard detection. > > I've no idea if cx88 has any upper DMA maximum bandwidth. If it has, > that might be the reason to limit to 27MHz, 8 bits, but I suspect > that it was done that way just because it was easier. > > Btw, I'm almost sure that other Conexant designs can also offer > similar interfaces. > > > > > > Regards, > > > > Hans > > > >> > >> > >> The changes from version 1 are: > >>- fix compilation; > >>- add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE), > >> with the corresponding documentation; > >>- remove legacy V4L1 buffer types from videobuf2.h. > >> > >> With regards to VIDIOC_S_TUNER, what's currently defined there is > >> that, in contrary to what a radio device does, this ioctl would > >> set the input. > >> > >> This patch adds the very basic stuff for SDR: > >> > >>- a separate devnode; > >>- an VIDIOC_QUERYCAP caps for SDR; > >>- a fourcc group for SDR; > >>- a few DocBook bits. > >> > >> What's missing: > >>- SDR specific controls; > >>- Sample rate config; > >>... > >> > >> As discussing DocBook changes inside the patch is hard, I'm adding here > >> the DocBook formatted changes. > >> > >> The DocBook changes add the following bits: > >> > >> At Chapter 1. Common API Elements, it adds: > >> > >> > >> Software Digital Radio (SDR) Tuners and Modulators > >> == > >> > >> Those devices are special types of Radio devices that don't have any > >> analog demodulator. Instead, it samples the radio IF or baseband and > >> sends the samples for userspace to demodulate. > >> > >> Tuners > >> == > >> > >> SDR receivers can have one or more tuners sampling RF signals. Each > >> tuner is associated with one or more inputs, depending on the number of > >> RF connectors on the tuner. The type field of the respective struct > >> v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to > >> V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of > >> the tuner input. > >> > >> To query and change tuner properties applications use
Re: [PATCH v4] drm/exynos: prepare FIMD clocks
Hi,
On Monday 08 of April 2013 16:41:54 Viresh Kumar wrote:
> On 8 April 2013 16:37, Vikas Sajjan wrote:
> > While migrating to common clock framework (CCF), I found that the FIMD
> > clocks were pulled down by the CCF.
> > If CCF finds any clock(s) which has NOT been claimed by any of the
> > drivers, then such clock(s) are PULLed low by CCF.
> >
> > Calling clk_prepare() for FIMD clocks fixes the issue.
> >
> > This patch also replaces clk_disable() with clk_unprepare() during
> > exit, since clk_prepare() is called in fimd_probe().
>
> I asked you about fixing your commit log too.. It still looks incorrect
> to me.
>
> This patch doesn't have anything to do with CCF pulling clocks down, but
> calling clk_prepare() before clk_enable() is must now.. that's it..
> nothing more.
>
I fully agree.
The message should be something like:
Common Clock Framework introduced the need to prepare clocks before
enabling them, otherwise clk_enable() fails. This patch adds clk_prepare
calls to the driver.
and that's all.
What you are observing as "CCF pulling clocks down" is the fact that
clk_enable() fails if the clock is not prepared and so the clock is not
enabled in result.
Another thing is that CCF is not pulling anything down. GPIO pins can be
pulled down (or up or not pulled), but clocks can be masked, gated or
simply disabled - this does not imply their signal level.
> > Signed-off-by: Vikas Sajjan
> > ---
> >
> > Changes since v3:
> > - added clk_prepare() in fimd_probe() and clk_unprepare() in
> > fimd_remove()>
> > as suggested by Viresh Kumar
> >
> > Changes since v2:
> > - moved clk_prepare_enable() and clk_disable_unprepare() from
> > fimd_probe() to fimd_clock() as suggested by Inki Dae
> > >
> > Changes since v1:
> > - added error checking for clk_prepare_enable() and also
> > replaced
> > clk_disable() with clk_disable_unprepare() during exit.
> >
> > ---
> >
> > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9537761..aa22370
> > 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> > @@ -934,6 +934,16 @@ static int fimd_probe(struct platform_device
> > *pdev)>
> > return ret;
> >
> > }
> >
> > + ret = clk_prepare(ctx->bus_clk);
> > + if (ret < 0)
> > + return ret;
> > +
> > + ret = clk_prepare(ctx->lcd_clk);
> > + if (ret < 0) {
> > + clk_unprepare(ctx->bus_clk);
> > + return ret;
> > + }
> > +
Why not just simply use clk_prepare_enable() instead of all calls to
clk_enable() in the driver?
Same goes for s/clk_disable/clk_disable_unprepare/ .
> >
> > ctx->vidcon0 = pdata->vidcon0;
> > ctx->vidcon1 = pdata->vidcon1;
> > ctx->default_win = pdata->default_win;
> >
> > @@ -981,8 +991,8 @@ static int fimd_remove(struct platform_device
> > *pdev)>
> > if (ctx->suspended)
> >
> > goto out;
> >
> > - clk_disable(ctx->lcd_clk);
> > - clk_disable(ctx->bus_clk);
> > + clk_unprepare(ctx->lcd_clk);
> > + clk_unprepare(ctx->bus_clk);
>
> This looks wrong again.. You still need to call clk_disable() to make
> clk enabled
> count zero...
Viresh is right again here.
Best regards,
Tomasz
--
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] V4L2: I2C: ML86V7667 video decoder driver
Hi Sylwester,
Thank you for the review.
Sylwester Nawrocki wrote
+static struct v4l2_subdev_video_ops ml86v7667_subdev_video_ops = {
+.querystd = ml86v7667_querystd,
+.g_input_status = ml86v7667_g_input_status,
+.enum_mbus_fmt = ml86v7667_enum_mbus_fmt,
+.try_mbus_fmt = ml86v7667_try_mbus_fmt,
+.g_mbus_fmt = ml86v7667_g_mbus_fmt,
+.s_mbus_fmt = ml86v7667_s_mbus_fmt,
+.cropcap = ml86v7667_cropcap,
+.g_mbus_config = ml86v7667_g_mbus_config,
+};
Why do you need .cropcap when there is no s_crop/g_crop ops ? Is it
only for pixel aspect ratio ?
Yes it is.
Also, new drivers are supposed to use the selections API instead
(set/get_selection ops). However this requires pad level ops support
in your host driver, hence might be a bigger issue.
Yes, since the host driver (rcar_vin is already send for review) is
designed for soc-camera layer that does not use the pad level ops but
needs at least cropcap to get the pixel aspect ratio.
The soc-camera has it's own set/get_selection in soc_camera_host_ops and
it is possible to use it like all i2c/soc_camera sensors can/do.
But we would not like to design the ml86v7667 as soc-camera device since
it will not be available for all non soc-camera v4l2 hosts.
Regards,
Vladimir
--
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 RFC v2 0/3] Add SDR at V4L2 API
Em 21-04-2013 06:34, Hans Verkuil escreveu: Hi Mauro, On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote: This is a version 2 of the V4L2 API bits to support Software Digital Radio (SDR). It looks pretty good to me. Just one question though: what is your rationale for choosing a new device name (/dev/sdrX) instead of using the existing /dev/radioX? I'm not saying I'm opposed to it, in fact I agree with it, but I think the reasons for it should be stated explicitly. Because a SDR radio is different than a normal radio device: A normal radio device is actually radio and hardware demod. As the demod is in hardware, several things that are required for the demodulate the signal (IF, bandwidth, sample rate, RF/IF filters, etc) are internal to the device and aren't part of the API. SDR radio, on the other hand, requires that every control needed by the tuner to be exposed on userspace, as userspace needs to adjust the software decoder to match them. So, they're different. Btw, it is also possible that the same device to offer analog TV, digital TV, hardware-decoded radio and SDR. One example of such devices are cx88. The existing drivers supports already hardware demodulers, but the device also allows to export the collected samples to userspace. It is just a matter of programming the cx88 RISC code to do that. Internally, cx2388x has 2 10 bits ADC, one for baseband (composite inputs) and another one for IF signal capable of working up to 35.44 MHz sampling rate (on "8x FSC PAL" supported mode). It would be easy to export its output to userspace. Btw, while seeking for more data about SDR this weekend, I discovered one project doing exactly that: http://www.geocities.ws/how_chee/cx23881fc6.htm I did a very quick look at its source code. It is limited, as it works only at a fixed sample rate of 27 MHz provides only 8 bits samples[1], and I'm not sure if it allows using both ADCs. Yet, It shows that it is possible that a driver/subdrivers to offer the 4 different types of devices: - analog TV; - digital TV; - radio; - SDR. So, IMO we should not abuse of /dev/radio for SDR. Regards, Mauro [1] The trick is to program the cx88 RISC to output data from the samplers, instead of from the demods. We do that already for the audio standard detection. I've no idea if cx88 has any upper DMA maximum bandwidth. If it has, that might be the reason to limit to 27MHz, 8 bits, but I suspect that it was done that way just because it was easier. Btw, I'm almost sure that other Conexant designs can also offer similar interfaces. Regards, Hans The changes from version 1 are: - fix compilation; - add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE), with the corresponding documentation; - remove legacy V4L1 buffer types from videobuf2.h. With regards to VIDIOC_S_TUNER, what's currently defined there is that, in contrary to what a radio device does, this ioctl would set the input. This patch adds the very basic stuff for SDR: - a separate devnode; - an VIDIOC_QUERYCAP caps for SDR; - a fourcc group for SDR; - a few DocBook bits. What's missing: - SDR specific controls; - Sample rate config; ... As discussing DocBook changes inside the patch is hard, I'm adding here the DocBook formatted changes. The DocBook changes add the following bits: At Chapter 1. Common API Elements, it adds: Software Digital Radio (SDR) Tuners and Modulators == Those devices are special types of Radio devices that don't have any analog demodulator. Instead, it samples the radio IF or baseband and sends the samples for userspace to demodulate. Tuners == SDR receivers can have one or more tuners sampling RF signals. Each tuner is associated with one or more inputs, depending on the number of RF connectors on the tuner. The type field of the respective struct v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of the tuner input. To query and change tuner properties applications use the VIDIOC_G_TUNER and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned by VIDIOC_G_TUNER also contains signal status information applicable when the tuner of the current SDR input is queried. In order to change the SDR input, VIDIOC_S_TUNER with a new SDR index should be called. Drivers must support both ioctls and set the V4L2_CAP_SDR and V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Modulators == To be defined. At the end of Chapter 2. Image Formats, it adds: SDR format struture === Table 2.4. struct v4l2_sdr_format = __u32 sampleformatThe format of the samples used by the SDR device. This is a little endian four
Re: [PATCH RFC v2 0/3] Add SDR at V4L2 API
Hi Mauro, On Sat April 20 2013 19:51:11 Mauro Carvalho Chehab wrote: > This is a version 2 of the V4L2 API bits to support Software Digital > Radio (SDR). It looks pretty good to me. Just one question though: what is your rationale for choosing a new device name (/dev/sdrX) instead of using the existing /dev/radioX? I'm not saying I'm opposed to it, in fact I agree with it, but I think the reasons for it should be stated explicitly. Regards, Hans > > > The changes from version 1 are: > - fix compilation; > - add a new capture type for SDR (V4L2_BUF_TYPE_SDR_CAPTURE), > with the corresponding documentation; > - remove legacy V4L1 buffer types from videobuf2.h. > > With regards to VIDIOC_S_TUNER, what's currently defined there is > that, in contrary to what a radio device does, this ioctl would > set the input. > > This patch adds the very basic stuff for SDR: > > - a separate devnode; > - an VIDIOC_QUERYCAP caps for SDR; > - a fourcc group for SDR; > - a few DocBook bits. > > What's missing: > - SDR specific controls; > - Sample rate config; > ... > > As discussing DocBook changes inside the patch is hard, I'm adding here > the DocBook formatted changes. > > The DocBook changes add the following bits: > > At Chapter 1. Common API Elements, it adds: > > > Software Digital Radio (SDR) Tuners and Modulators > == > > Those devices are special types of Radio devices that don't have any > analog demodulator. Instead, it samples the radio IF or baseband and > sends the samples for userspace to demodulate. > > Tuners > == > > SDR receivers can have one or more tuners sampling RF signals. Each > tuner is associated with one or more inputs, depending on the number of > RF connectors on the tuner. The type field of the respective struct > v4l2_input returned by the VIDIOC_ENUMINPUT ioctl is set to > V4L2_INPUT_TYPE_TUNER and its tuner field contains the index number of > the tuner input. > > To query and change tuner properties applications use the VIDIOC_G_TUNER > and VIDIOC_S_TUNER ioctl, respectively. The struct v4l2_tuner returned > by VIDIOC_G_TUNER also contains signal status information applicable > when the tuner of the current SDR input is queried. In order to change > the SDR input, VIDIOC_S_TUNER with a new SDR index should be called. > Drivers must support both ioctls and set the V4L2_CAP_SDR and > V4L2_CAP_TUNER flags in the struct v4l2_capability returned by the > VIDIOC_QUERYCAP ioctl. > > Modulators > == > > To be defined. > > > At the end of Chapter 2. Image Formats, it adds: > > > SDR format struture > === > > Table 2.4. struct v4l2_sdr_format > = > > __u32 sampleformatThe format of the samples used by the SDR device. > This is a little endian four character code. > > Table 2.5. SDR formats > == > > V4L2_SDR_FMT_I8Q8 Samples are given by a sequence of 8 bits in-phase(I) > and 8 bits quadrature (Q) samples taken from a > signal(t) represented by the following expression: > signal(t) = I * cos(2Ï fc t) - Q * sin(2Ï fc t) > > > Of course, other formats will be needed at Table 2.5, as SDR could also > be taken baseband samples, being, for example, a simple sequence of > equally time-spaced digitalized samples of the signal in time. > SDR samples could also use other resolutions, use a non-linear > (A-law, u-law) ADC, or even compress the samples (with ADPCM, for > example). So, this table will grow as newer devices get added, and an > userspace library may be required to convert them into some common > format. > > At "Chapter 4. Interfaces", it adds the following text: > > > Software Digital Radio(SDR) Interface > = > > This interface is intended for Software Digital Radio (SDR) receivers > and transmitters. > > Conventionally V4L2 SDR devices are accessed through character device > special files named /dev/sdr0 to/dev/radio255 and uses a dynamically > allocated major/minor number. > > Querying Capabilities > = > > Devices supporting the radio interface set the V4L2_CAP_SDR and > V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of > struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl. Other > combinations of capability flags are reserved for future extensions. > > Supplemental Functions > == > > SDR receivers should support tuner ioctls. > > SDR transmitter ioctl's will be defined in the future. > > SDR devices should also support one or more of the following I/O ioctls: > read or write, memory mapped IO, user memory IO and/or DMA buffers. > > SDR devices can also support controls ioctls. > > The SDR Input/Output are A/D or D/A samples
Re: [PATCH v9 00/12] Driver for Si476x series of chips
Em 21-04-2013 02:53, Andrey Smirnov escreveu: I applied all the MFD patches from this patchset (All 4 first ones), plus a follow up one for fixing the i2c related warning. I also squashed the REGMAP_I2C dependency into patch #4. It's all in mfd-next now, I'd appreciate if you could double check it's all fine. I checked out latest git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-next.git and applied patches 5 - 10, 12. There doesn't seem to be any problems, so I think MFD part of the driver is good to go. Mauro will take the rest, we made sure there won't be any merge conflict between our trees. Mauro, I am not sure if you need me to rebase any of the patches(it doesn't seem like you had a chance to make any further changes related to this driver in media tree), but if you do, ping me and I'll get on it. No, I don't need. The V4L parts are on my experimental tree: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/si476x I'll just merge it at the main tree or as a topic branch later today or (more likely) tomorrow. Please ping me today if you find anything wrong there. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v1] Add SDR at V4L2 API
Em 21-04-2013 06:16, Oliver Schinagl escreveu: On 04/20/13 23:44, Oliver Schinagl wrote: -- 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 Not sure what happened there, I know I typed a bit more then that :p :) What I was wondering, how relevant the name will be with extensions like SDR. Maybe for V4l3 it could be renamed to M4L (Media for Linux)? Since Video would imply only video, not even audio let alone radio. I know it's just a name so who cares right? Since very early, radio support was part of V4L. Not sure why this was not renamed on V4L on that time, but it is now too late to change it, as it would require an entire renaming at the core and at userspace API with no technical gain. With regards to a V4L3, I prefer if we never do that... radical changes like that mean a lot of hard work. We took ~10 years to finish the transition from V4L1 to V4L2. It is easier to just extend it where it needed than to rewrite it from scratch. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v1] Add SDR at V4L2 API
On 04/20/13 23:44, Oliver Schinagl wrote: -- 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 Not sure what happened there, I know I typed a bit more then that :p What I was wondering, how relevant the name will be with extensions like SDR. Maybe for V4l3 it could be renamed to M4L (Media for Linux)? Since Video would imply only video, not even audio let alone radio. I know it's just a name so who cares right? -- 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
