Re: where can I report dvb module related bug reports?
Hi, On So, Nov 28, 2010 at 06:05:57 -0600, Jonathan Isom wrote: > Hi >I am not developer however been on this list since move. This is > the appropriate list. > However I search my archive(gmail account) and I didn't get them. I > find it interesting that > they are in the mail-archive archive. I would assume something may > have happened with > the mail server. Hopefully as this reply shows you will get your help. Thats sounds interesting but I received my own messages from the list at that time. Ok anyway maybe somebody can help with the decribed issues? BR. Halim > > Please can you help with the following things: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg12758.html > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg21646.html > > THX > > Regards > > halim > > > > > > -- > > 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 > > > > > > -- > ASUS M4A78 PRO motherboard > Athlon II X4 640 Processor > 4 Gigabytes of DDR2-800 > Gigabyte nVidia 9400gt Graphics adapter > KWorld ATSC 110 TV Capture Card > KWorld ATSC 115 TV Capture Card -- Halim Sahin E-Mail: halim.sahin (at) t-online.de -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Problem of using v4l2 spec with codec function
Hi, On Monday 29 November 2010 08:34:06 Hans Verkuil wrote: > On Monday, November 29, 2010 00:52:15 Jaeryul Oh wrote: > > Hello, everyone. > > > > When it comes to using v4l2 standard spec, I have a question about that. > > > > A month ago, Kamil Debski posted second version for the driver of a hw > > video codec. To be exact, it is decoding function of hw video codec > > which is called MFC(Multi Format Codec). > > > > For members not accustomed to this, refer to link as below. > > > > : http://www.spinics.net/lists/linux-media/msg24682.html > > > > I'm preparing for patch of encoding function of MFC. But simply I could > > say, According to the current version of v4l2 standard, User cannot call > > encoder or decoder differentially. I mean, Kamil designed MFC decoder > > driver using m2m style(not using by m2m framework, but > > V4L2_CAP_VIDEO_OUTPUT, V4L2_CAP_VIDEO_CAPTURE) > > And it would be almost same to implement encoder in terms of using same > > m2m style. But user should be able to call decoder for decoding, Due to > > the same reason, user should be able to call encoder. Of course, some > > different functions b/w encoder & decoder are called. (Driver should > > know what function(enc or dec) is called) > > > > What do you think is the best way to let driver know what function user > > wants to execute ? > > > > 1. VIDIOC_QUERYCAP is mandatory, but it doesn't define about any encoder, > > decoder in the v4l2_capability > > > > : we need new capability for codec such as V4L2_BUF_TYPE_VIDEO_ENCODER, > > : V4L2_BUF_TYPE_VIDEO_DECODER > > The upcoming media controller might be used to signal the capability. I'd > be opposed to use a new buftype for this. Actually, I'm not sure if you > really need this. > > > 2. What about using VIDIOC_S_CTRL, but it requires new defined decoder or > > encoder as a ctrl.id. > > > > Another problem is VIDIOC_S_CTRL is optional > > Wouldn't you have separate video device nodes for the decoder and for the > encoder? Or are they mutually exclusive? I.e., only one or the other can > be running at a time? > > > 3. What about VIDIOC_S_FMT ? it is also optional, which means default > > format will be used if not VIDIOC_S_FMT > > > >called. > > > > Let me know best way such as one among appropriate way that I mentioned > > as above, or any other idea ? > > I have to admit it's not entirely clear to me what your problem is exactly. > > I *think* that what you are saying is that your hardware can have just a > single 'm2m' video instance and so you want to allow the user to switch > between the possible m2m functions (video encoder or decoder) dynamically. > Is that right? > > If so, then I think creating a so-called 'private' control for your > hardware would be the best way to go. As an example of private controls > search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. I would rely on formats. If the input format is YUV and the output format is MPEG, it's pretty obvious that the hardware should be encoding. If the formats are the other way around, then the hardware should be decoding. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] soc_camera: Add the ability to bind regulators to soc_camedra devices
Hi Guennadi,
On dom, 2010-11-28 at 20:05 +0100, Guennadi Liakhovetski wrote:
> On Sun, 28 Nov 2010, Alberto Panizzo wrote:
>
> > In certain machines, camera devices are supplied directly
> > by a number of regulators. This patch add the ability to drive
> > these regulators directly by the soc_camera driver.
>
> IIRC, there has been a discussion a while ago, how to supply power to
> cameras by regulators. Someone has tried to provide a .power() hook in the
> platform code, but the problem was the order of driver loading / probing.
> So, how about doing the following:
>
> 1. in your platform code you register a notifier like
> bus_register_notifier(&soc_camera_bus_type, &cam_notifier);
> 2. in your notifier you verify, that the driver is already available, or
> request_module("my-regulator-driver"), and use another notifier to wait,
> until the driver is probed.
> 3. if the above has been successful, in your .power() method you just use
> the regulator as usual.
>
> Notice, that your current patch doesn't load regulator driver modules, so,
> it also relies on them being already available at the time of camera
> probing. If you can live with that restriction, you can skip loading the
> module and waiting for its probe above too.
The reason I propose this implementation is because in a different
subsystem (mmc) the regulator management is similar and accepted.
In that case, platform code that drive regulators directly is not
considered successful and it is maintained a platform .power() function
that can manage other operations than regulators driving.
The power of binding regulators to devices, I think, is given by the
ability to fine manage these objects in terms of power management.
But of course you are right in some objections:
>
> The reasons why I do not want to add this to the core are: (1) I do not
> want to have two methods for turning power on and off: a platform provided
> .power() hook and and a set of regulators,
Why? The implementation I gave, abstract these power management actions
in a single layer. Of course I had to manage the way of passing
preferred voltage values and the results are not perfect.
> (2) would anyone really want to
> use several regulators for a camera sensor? If so, can it be the case,
> that, for example, the regulators have to be switched off in the reverse
> order to switching on? Or something else?
Well, I'm working on the i.MX31 3 Stack board support and there are 2
regulators that powers the camera and if you consider the digital output
that enable another supplier needed, the total regulators are three..
So, yes a list of regulators is needed in this case, and Yes I did not
considered the order of enabling and disabling operations. Just because
even the freescale drivers didn't.
A practical general rule is to turn off switchers in the reverse order
than the turning on one. And this can be easily implemented here.
But as you rose the question, we can add priorities of turning on and
off.
> (3) regulators can often do
> more, than just set one of two power levels - for on and off. What if a
> need arises to use other voltages?
Well, you are thinking at the possibility to have one camera that have
different voltage levels needs during the ON time (between open and a
close).
IMHO I think that this could be considered only if a power management
event happen and we decide that, in some way, the camera chip can be
maintained powered with a different voltage level instead of turning
it off and reinitializing it on resume.
Is this really the situation you are trying to address?
> Is there any really good reason, why we _have_ to do this in soc-camera
> core?
There are three options in regulators management:
1 Pure platform code.
2 Pure driver code.
3 subsystem code.
The first is the one you are suggesting me, but other subsystems
rejected it.
The third IMHO is better than the first but solve the needs of the
single driver.
The second is the one I proposed and I think is the best way because
add a general framework to manage regulators in this subsystem.
Thanks you!
Alberto!
> >
> > What the machine code have to do to use this functionality is to:
> > 1- Define a number of useful regulator supply descriptions such as:
> >
> > static struct regulator_consumer_supply camera_reg1_consumers[] = {
> > ...
> > REGULATOR_SUPPLY("camera_reg1", "soc-camera-pdrv.0"),
> > ...
> > };
> >
> > (Pay attention at the .N suffix of "soc-camera-pdrv" in case of
> > a system with multiple cameras)
> >
> > 2- Define the list of regulators to bind to a specific instance of
> >soc-camera-pdrv with their voltages:
> >
> > static struct soc_camera_regulator_desc soc_camera_regs[] = {
> > SOCAM_REG_DESC("camera_reg1", 130, 130),
> > SOCAM_REG_DESC("camera_reg2", 280, 280),
> > ...
> > };
> >
> > 3- Add the list to the corresponding soc_camera_link description:
> >
> > static struct soc_camera_lin
Re: [PATCH 2/7] v4l: videobuf2: add generic memory handling routines
Hi Marek,
On Friday 19 November 2010 16:55:39 Marek Szyprowski wrote:
> From: Pawel Osciak
>
> Add generic memory handling routines for userspace pointer handling,
> contiguous memory verification and mapping.
>
> Signed-off-by: Pawel Osciak
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> CC: Pawel Osciak
> ---
> drivers/media/video/Kconfig|3 +
> drivers/media/video/Makefile |1 +
> drivers/media/video/videobuf2-memops.c | 199
> include/media/videobuf2-memops.h |
> 31 +
> 4 files changed, 234 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/videobuf2-memops.c
> create mode 100644 include/media/videobuf2-memops.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index fef6a14..83ce858 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -52,6 +52,9 @@ config V4L2_MEM2MEM_DEV
> config VIDEOBUF2_CORE
> tristate
>
> +config VIDEOBUF2_MEMOPS
> + tristate
> +
> #
> # Multimedia Video device configuration
> #
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 77c4f85..a97a2a0 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -115,6 +115,7 @@ obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o
> obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
>
> obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
> +obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
>
> obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
>
> diff --git a/drivers/media/video/videobuf2-memops.c
> b/drivers/media/video/videobuf2-memops.c new file mode 100644
> index 000..67ebdff
> --- /dev/null
> +++ b/drivers/media/video/videobuf2-memops.c
> @@ -0,0 +1,199 @@
> +/*
> + * videobuf2-memops.c - generic memory handling routines for videobuf2
> + *
> + * Copyright (C) 2010 Samsung Electronics
> + *
> + * Author: Pawel Osciak
> + * Marek Szyprowski
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/**
> + * vb2_contig_verify_userptr() - verify contiguity of a userspace-mapped
> memory + * @vma: virtual memory region which maps the physical memory
> + * to be verified
> + * @vaddr: starting virtual address of the area to be verified
> + * @size:size of the area to be verified
> + * @paddr: will return physical address for the given vaddr
> + *
> + * This function will go through memory area of size size mapped at vaddr
> and + * verify that the underlying physical pages are contiguous.
> + *
> + * Returns 0 on success and a physical address to the memory pointed
> + * to by vaddr in paddr.
> + */
> +int vb2_contig_verify_userptr(struct vm_area_struct *vma,
> + unsigned long vaddr, unsigned long size,
> + unsigned long *paddr)
> +{
> + struct mm_struct *mm = current->mm;
> + unsigned long offset;
> + unsigned long vma_size;
> + unsigned long curr_pfn, prev_pfn;
> + unsigned long num_pages;
> + int ret = -EINVAL;
> + unsigned int i;
> +
> + offset = vaddr & ~PAGE_MASK;
> +
> + down_read(&mm->mmap_sem);
> +
> + vma = find_vma(mm, vaddr);
You're overwriting the vma argument, why do you need it ?
> + if (!vma) {
> + printk(KERN_ERR "Invalid userspace address\n");
> + goto done;
> + }
> +
> + vma_size = vma->vm_end - vma->vm_start;
> +
> + if (size > vma_size - offset) {
> + printk(KERN_ERR "Region too small\n");
> + goto done;
> + }
> + num_pages = (size + offset) >> PAGE_SHIFT;
> +
> + ret = follow_pfn(vma, vaddr, &curr_pfn);
Maybe you could put this call in the loop to avoid code duplication ? Feel
free to steal code from
http://git.linuxtv.org/pinchartl/media.git?a=blob;f=drivers/media/video/isp/ispqueue.c;h=6750f68a6476fc168d44563b332f6b23b2700504;hb=630004a88986b1f8b42c5fddb9a5e5c0d575b464#l358
:-)
> + if (ret) {
> + printk(KERN_ERR "Invalid userspace address\n");
> + goto done;
> + }
> +
> + *paddr = (curr_pfn << PAGE_SHIFT) + offset;
> +
> + for (i = 1; i < num_pages; ++i) {
> + prev_pfn = curr_pfn;
> + vaddr += PAGE_SIZE;
> +
> + ret = follow_pfn(vma, vaddr, &curr_pfn);
> + if (ret || curr_pfn != prev_pfn + 1) {
> + printk(KERN_ERR "Invalid userspace address\n");
> + ret = -EINVAL;
I would use -EFAULT when curr_pfn != prev_pfn + 1.
> + break;
> + }
> + }
> +
> +done:
> + up_read(&mm->mmap_sem);
> + return ret;
> +}
> +
Re: [PATCH 3/7] v4l: videobuf2: add vmalloc allocator
Hi Marek,
On Friday 19 November 2010 16:55:40 Marek Szyprowski wrote:
> From: Pawel Osciak
>
> Add an implementation of contiguous virtual memory allocator and handling
> routines for videobuf2, implemented on top of vmalloc()/vfree() calls.
>
> Signed-off-by: Pawel Osciak
> Signed-off-by: Kyungmin Park
> Signed-off-by: Marek Szyprowski
> CC: Pawel Osciak
> ---
> drivers/media/video/Kconfig |5 +
> drivers/media/video/Makefile|1 +
> drivers/media/video/videobuf2-vmalloc.c | 177
> +++ include/media/videobuf2-vmalloc.h |
> 21
> 4 files changed, 204 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/videobuf2-vmalloc.c
> create mode 100644 include/media/videobuf2-vmalloc.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 83ce858..9351423 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -55,6 +55,11 @@ config VIDEOBUF2_CORE
> config VIDEOBUF2_MEMOPS
> tristate
>
> +config VIDEOBUF2_VMALLOC
> + select VIDEOBUF2_CORE
> + select VIDEOBUF2_MEMOPS
> + tristate
> +
> #
> # Multimedia Video device configuration
> #
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index a97a2a0..538bee9 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -116,6 +116,7 @@ obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
>
> obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
> obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
> +obj-$(CONFIG_VIDEOBUF2_VMALLOC) += videobuf2-vmalloc.o
>
> obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
>
> diff --git a/drivers/media/video/videobuf2-vmalloc.c
> b/drivers/media/video/videobuf2-vmalloc.c new file mode 100644
> index 000..3310900
> --- /dev/null
> +++ b/drivers/media/video/videobuf2-vmalloc.c
> @@ -0,0 +1,177 @@
> +/*
> + * videobuf2-vmalloc.c - vmalloc memory allocator for videobuf2
> + *
> + * Copyright (C) 2010 Samsung Electronics
> + *
> + * Author: Pawel Osciak
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +struct vb2_vmalloc_conf {
> + struct vb2_alloc_ctxalloc_ctx;
> +};
> +
> +struct vb2_vmalloc_buf {
> + void*vaddr;
> + unsigned long size;
> + unsigned intrefcount;
> +};
> +
> +static void *vb2_vmalloc_alloc(const struct vb2_alloc_ctx *alloc_ctx,
> + unsigned long size)
> +{
> + struct vb2_vmalloc_buf *buf;
> +
> + buf = kzalloc(sizeof *buf, GFP_KERNEL);
> + if (!buf)
> + return NULL;
> +
> + buf->size = size;
> + buf->vaddr = vmalloc_user(buf->size);
Some drivers might need vmalloc_32_user instead.
> + if (!buf->vaddr) {
> + printk(KERN_ERR "vmalloc of size %ld failed\n", buf->size);
> + kfree(buf);
> + return NULL;
> + }
> +
> + buf->refcount++;
> + printk(KERN_DEBUG "Allocated vmalloc buffer of size %ld at vaddr=%p\n",
> + buf->size, buf->vaddr);
> +
> + return buf;
> +}
> +
> +static void vb2_vmalloc_put(void *buf_priv)
> +{
> + struct vb2_vmalloc_buf *buf = buf_priv;
> +
> + buf->refcount--;
> +
> + if (0 == buf->refcount) {
> + printk(KERN_DEBUG "%s: Freeing vmalloc mem at vaddr=%p\n",
> + __func__, buf->vaddr);
> + vfree(buf->vaddr);
> + kfree(buf);
> + }
> +}
> +
> +static void *vb2_vmalloc_vaddr(void *buf_priv)
> +{
> + struct vb2_vmalloc_buf *buf = buf_priv;
> +
> + BUG_ON(!buf);
> +
> + if (!buf->vaddr) {
> + printk(KERN_ERR "Address of an unallocated "
> + "plane requested\n");
Can this happen under normal circumstances, or is it a driver bug ? In the
later case a WARN_ON might be better.
> + return NULL;
> + }
> +
> + return buf->vaddr;
> +}
> +
> +static unsigned int vb2_vmalloc_num_users(void *buf_priv)
> +{
> + struct vb2_vmalloc_buf *buf = buf_priv;
> +
> + return buf->refcount;
> +}
> +
> +/* TODO generalize and extract to core as much as possible */
I agree with the TODO :-) This part doesn't seem very clean, and
vm_open/vm_close handling certainly needs documentation.
> +static void vb2_vmalloc_vm_open(struct vm_area_struct *vma)
> +{
> + struct vb2_vmalloc_buf *buf = vma->vm_private_data;
> +
> + printk(KERN_DEBUG "%s vmalloc_priv: %p, refcount: %d, "
> + "vma: %08lx-%08lx\n", __func__, buf, buf->refcount,
> + vma->vm_start, vma->vm_end);
> +
> + buf->refcount++;
> +}
> +
> +static void vb2_vmalloc_vm_close(struct vm_area_st
[GIT PULL FOR 2.6.37] uvcvideo: BKL removal
Hi Mauro, The following changes since commit c796e203229c8c08250f9d372ae4e10c466b1787: [media] kconfig: add an option to determine a menu's visibility (2010-11-22 10:37:56 -0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-stable They complete the BKL removal from the uvcvideo driver. Feedback received from Hans during review has been integrated. Laurent Pinchart (5): uvcvideo: Lock controls mutex when querying menus uvcvideo: Move mutex lock/unlock inside uvc_free_buffers uvcvideo: Move mmap() handler to uvc_queue.c uvcvideo: Lock stream mutex when accessing format-related information uvcvideo: Convert to unlocked_ioctl drivers/media/video/uvc/uvc_ctrl.c | 48 +- drivers/media/video/uvc/uvc_queue.c | 133 +- drivers/media/video/uvc/uvc_v4l2.c | 185 +++--- drivers/media/video/uvc/uvc_video.c |3 - drivers/media/video/uvc/uvcvideo.h | 10 ++- 5 files changed, 222 insertions(+), 157 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Problem of using v4l2 spec with codec function
> Hi, > > On Monday 29 November 2010 08:34:06 Hans Verkuil wrote: >> On Monday, November 29, 2010 00:52:15 Jaeryul Oh wrote: >> > Hello, everyone. >> > >> > When it comes to using v4l2 standard spec, I have a question about >> that. >> > >> > A month ago, Kamil Debski posted second version for the driver of a hw >> > video codec. To be exact, it is decoding function of hw video codec >> > which is called MFC(Multi Format Codec). >> > >> > For members not accustomed to this, refer to link as below. >> > >> > : http://www.spinics.net/lists/linux-media/msg24682.html >> > >> > I'm preparing for patch of encoding function of MFC. But simply I >> could >> > say, According to the current version of v4l2 standard, User cannot >> call >> > encoder or decoder differentially. I mean, Kamil designed MFC decoder >> > driver using m2m style(not using by m2m framework, but >> > V4L2_CAP_VIDEO_OUTPUT, V4L2_CAP_VIDEO_CAPTURE) >> > And it would be almost same to implement encoder in terms of using >> same >> > m2m style. But user should be able to call decoder for decoding, Due >> to >> > the same reason, user should be able to call encoder. Of course, some >> > different functions b/w encoder & decoder are called. (Driver should >> > know what function(enc or dec) is called) >> > >> > What do you think is the best way to let driver know what function >> user >> > wants to execute ? >> > >> > 1. VIDIOC_QUERYCAP is mandatory, but it doesn't define about any >> encoder, >> > decoder in the v4l2_capability >> > >> > : we need new capability for codec such as >> V4L2_BUF_TYPE_VIDEO_ENCODER, >> > : V4L2_BUF_TYPE_VIDEO_DECODER >> >> The upcoming media controller might be used to signal the capability. >> I'd >> be opposed to use a new buftype for this. Actually, I'm not sure if you >> really need this. >> >> > 2. What about using VIDIOC_S_CTRL, but it requires new defined decoder >> or >> > encoder as a ctrl.id. >> > >> > Another problem is VIDIOC_S_CTRL is optional >> >> Wouldn't you have separate video device nodes for the decoder and for >> the >> encoder? Or are they mutually exclusive? I.e., only one or the other can >> be running at a time? >> >> > 3. What about VIDIOC_S_FMT ? it is also optional, which means default >> > format will be used if not VIDIOC_S_FMT >> > >> >called. >> > >> > Let me know best way such as one among appropriate way that I >> mentioned >> > as above, or any other idea ? >> >> I have to admit it's not entirely clear to me what your problem is >> exactly. >> >> I *think* that what you are saying is that your hardware can have just a >> single 'm2m' video instance and so you want to allow the user to switch >> between the possible m2m functions (video encoder or decoder) >> dynamically. >> Is that right? >> >> If so, then I think creating a so-called 'private' control for your >> hardware would be the best way to go. As an example of private controls >> search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. > > I would rely on formats. If the input format is YUV and the output format > is > MPEG, it's pretty obvious that the hardware should be encoding. If the > formats > are the other way around, then the hardware should be decoding. That doesn't work in the general case. Instead of video encoding/decoding you may also have video effects, colorspace conversion or other fancy transformations. That said, in this particular case your suggestion would work. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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: Problem of using v4l2 spec with codec function
Laurent Pinchart wrote: > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > Sent: Monday, November 29, 2010 6:20 PM > To: Hans Verkuil > Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org > Subject: Re: RFC: Problem of using v4l2 spec with codec function > > Hi, > > > If so, then I think creating a so-called 'private' control for your > > hardware would be the best way to go. As an example of private controls > > search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. > > I would rely on formats. If the input format is YUV and the output format is > MPEG, it's pretty obvious that the hardware should be encoding. If the formats > are the other way around, then the hardware should be decoding. Right. But.. If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? In my opinion decoder and encoder can have own control Ids. For example, After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called how to return it ? VIDIOC_S_CTRL has been succeeded because driver cannot know whether decoder or encoder. And then is it right that VIDIOC_S_FMT for encoder is failed due to VIDIOC_S_CTRL for decoder ? Can two nodes(encoder, decoder) be the solution ? BRs, > -- > 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 -- 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: Problem of using v4l2 spec with codec function
Hi, In two nodes case, application cannot know the feature via VIDIOC_QUERYCAP. Because decoder and encoder return the same CAPABILITY. OUTPUT and CAPTURE So application should call VIDIOC_G_FMT to recognize the feature. BRs, > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Jonghun Han > Sent: Monday, November 29, 2010 8:49 PM > To: 'Laurent Pinchart'; 'Hans Verkuil' > Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org > Subject: RE: RFC: Problem of using v4l2 spec with codec function > > > Laurent Pinchart wrote: > > > -Original Message- > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > > Sent: Monday, November 29, 2010 6:20 PM > > To: Hans Verkuil > > Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org > > Subject: Re: RFC: Problem of using v4l2 spec with codec function > > > > Hi, > > > > > > > If so, then I think creating a so-called 'private' control for your > > > hardware would be the best way to go. As an example of private controls > > > search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. > > > > I would rely on formats. If the input format is YUV and the output format is > > MPEG, it's pretty obvious that the hardware should be encoding. If the > > formats > > are the other way around, then the hardware should be decoding. > > Right. But.. > If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? > In my opinion decoder and encoder can have own control Ids. > For example, > After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called > how to return it ? > VIDIOC_S_CTRL has been succeeded because driver cannot know whether > decoder or encoder. > And then is it right that VIDIOC_S_FMT for encoder is failed due to > VIDIOC_S_CTRL for decoder ? > > Can two nodes(encoder, decoder) be the solution ? > > BRs, > > > -- > > 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 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
> > Hi, > > In two nodes case, application cannot know the feature via > VIDIOC_QUERYCAP. > Because decoder and encoder return the same CAPABILITY. OUTPUT and CAPTURE > So application should call VIDIOC_G_FMT to recognize the feature. The current V4L API is not good enough to determine what each video node can do. The upcoming media controller API should help in that. For the time being you should just assume that applications know what they are doing. Anyway, I think having two device nodes is a perfectly valid solution. Particularly for more complex scenarios. Regards, Hans > > BRs, > >> -Original Message- >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> ow...@vger.kernel.org] On Behalf Of Jonghun Han >> Sent: Monday, November 29, 2010 8:49 PM >> To: 'Laurent Pinchart'; 'Hans Verkuil' >> Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org >> Subject: RE: RFC: Problem of using v4l2 spec with codec function >> >> >> Laurent Pinchart wrote: >> >> > -Original Message- >> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart >> > Sent: Monday, November 29, 2010 6:20 PM >> > To: Hans Verkuil >> > Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org >> > Subject: Re: RFC: Problem of using v4l2 spec with codec function >> > >> > Hi, >> > >> >> >> > > If so, then I think creating a so-called 'private' control for your >> > > hardware would be the best way to go. As an example of private >> controls >> > > search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. >> > >> > I would rely on formats. If the input format is YUV and the output >> format is >> > MPEG, it's pretty obvious that the hardware should be encoding. If the >> formats >> > are the other way around, then the hardware should be decoding. >> >> Right. But.. >> If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them >> ? >> In my opinion decoder and encoder can have own control Ids. >> For example, >> After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is >> called >> how to return it ? >> VIDIOC_S_CTRL has been succeeded because driver cannot know whether >> decoder or encoder. >> And then is it right that VIDIOC_S_FMT for encoder is failed due to >> VIDIOC_S_CTRL for decoder ? >> >> Can two nodes(encoder, decoder) be the solution ? >> >> BRs, >> >> > -- >> > 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 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" >> in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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: Problem of using v4l2 spec with codec function
Hi Hans, On Monday 29 November 2010 11:36:03 Hans Verkuil wrote: > > On Monday 29 November 2010 08:34:06 Hans Verkuil wrote: [snip] > >> I *think* that what you are saying is that your hardware can have just a > >> single 'm2m' video instance and so you want to allow the user to switch > >> between the possible m2m functions (video encoder or decoder) > >> dynamically. > >> Is that right? > >> > >> If so, then I think creating a so-called 'private' control for your > >> hardware would be the best way to go. As an example of private controls > >> search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. > > > > I would rely on formats. If the input format is YUV and the output format > > is MPEG, it's pretty obvious that the hardware should be encoding. If the > > formats are the other way around, then the hardware should be decoding. > > That doesn't work in the general case. Instead of video encoding/decoding > you may also have video effects, colorspace conversion or other fancy > transformations. For colorspace conversion we can rely on formats as well. For video effects controls will probably be needed. > That said, in this particular case your suggestion would work. If we think about the general case of a completely programmable system (think DSP), we will need a way to load the right firmware depending on the task at hand. The DSP would then become special purpose hardware, and V4L2 applications won't need to care much about how to select the desired operating mode. Whether the firmware selection/loading mechanism should be part of V4L2 or not is something to be discussed. -- 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: Unsafe to reinsert HVR-1850 kernel modules?
On Sun, 2010-11-28 at 23:49 -0800, David Liontooth wrote: > My HVR-1850 card occasionally jams, meaning it still tunes (according > to gnutv), but no mpeg stream comes through. > > This heals on reboot, but I figured it should also heal on module > reinsertion. > > However, when I remove the CX23885 module, along with the full set of > DVB and related modules, and then reinsert them, I get this error when I > attempt to open the stream -- zvbi-atsc-cc will for instance trigger it: > > kernel:do_IRQ: 5.82 No irq handler for vector (irq -1) This happens when an initial "MSI Data" vector is assigned to the CX23888 chip and written into its PCI config space, and then the kernel assigns a new "MSI Data" vector for the CX23888 and writes the new "MSI Data" vector into its PCI config space. This is what happens at cx23885 module reload with MSI enabled on your system. The CX2388[578] chips ignore the new "MSI Data" vector and continue to use the first assigned one. The kernel doesn't have an IRQ handler function to call for the old vector anymore, so do_IRQ blurts out its message. > If one card was initially jammed, now all the cards are jammed -- I'm > testing five cards at once. They are all still trying to fire interrupts, just with the "wrong" vector, so the kenrel ignores them. > A discussion at > http://www.mail-archive.com/linux-media@vger.kernel.org/msg22375.html > suggested adding the kernel parameter "pci=nommconf", but when I do that > the problem does not go away For a quick band-aid, use "pci=nomsi" on your kernel command line, and reboot to reset the CX23888 hardware. The problem is MSI. The cx23885 driver isn't ready for it. The patch that enabled MSI for cx23885 probably needs to be reverted until some of these issues are sorted out. > -- and I also got this (perhaps unrelated): > > cx25840 15-0044: likely a confused/unresponsive cx2388[578] A/V > decoder found @ 0x88 (cx23885[4]) > cx25840 15-0044: A method to reset it from the cx25840 driver software > is not known at this time > > Is it currently not safe to remove and reinsert the kernel modules for > the HVR-1850, or am I just seeing a quirk? This is unrelated. This happens when the CX2388[578] A/V core device probe fails to complete - usually due to a missing firmware file or some other Linux cx23885 or cx25840 module unhappiness. (Like the bug I found and fixed just yesterday - see my latest GIT pull request.) Once the CX2388[578] A/V core is in this state, it fails to respond to reads over the internal I2C bus. That makes it impossible for the cx25840 module to interrogate the CX2388x A/V core and figure out which type it is talking to, so that it can initialize it. Testing last night indicates that, if the cx25840 module had apriori knowledge of the type of A/V core, it could do the I2C writes anyway to initialize the A/V core and bring it back to a somewhat working condition. Your only course of action right now is, again, a hardware reset to get the CX2388[578] A/V core's I2C interface block back to a sane state. Otherwise, IR and analog video will not work properly for you. Regards, Andy > Cheers, > Dave -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v5 0/9] FM V4L2 drivers for WL128x
From: Manjunatha Halli Mauro and the list, This is the v5 version of the TI WL128x FM V4L2 drivers patchset. Texas Instrument's WL128x chipset packs BT, FM, GPS and WLAN in a single die with BT, FM and GPS being interfaced over a single UART. This driver works on top of the shared transport line discipline driver. This driver can also be made use for the WL127x version of the chip which packs BT, FM and WLAN only. Comments on the last version of the patches have been taken care, such as - Removed the array for opcode handling, instead defined them as macro's. - Moved the error message to fmc_senc_cmd() instead of printing it from all the caller functions. - Use of 'cpu_to_be16' macro instead of using custom macro. Also, Can you please also stage this version? Since the files are becoming big to be posted as patches? Thanks & Regards, Manjunatha. Manjunatha Halli (9): include:linux: videodev2.h: FM Rx control class Documentation:DocBook:v4l: Update the controls.xml for TI FM driver drivers:staging: ti-st: fmdrv common header file drivers:staging: ti-st: fmdrv_v4l2 sources drivers:staging: ti-st: fmdrv_common sources drivers:staging: ti-st: fmdrv_rx sources drivers:staging: ti-st: fmdrv_tx sources drivers:staging: ti-st: Kconfig & Makefile change driver:staging:ti-st: Update TODO for FM V4L2 driver. Documentation/DocBook/v4l/controls.xml | 12 + drivers/staging/ti-st/Kconfig | 10 + drivers/staging/ti-st/Makefile |2 + drivers/staging/ti-st/TODO | 17 +- drivers/staging/ti-st/fmdrv.h | 247 drivers/staging/ti-st/fmdrv_common.c | 2005 drivers/staging/ti-st/fmdrv_common.h | 412 +++ drivers/staging/ti-st/fmdrv_rx.c | 903 ++ drivers/staging/ti-st/fmdrv_rx.h | 59 + drivers/staging/ti-st/fmdrv_tx.c | 420 +++ drivers/staging/ti-st/fmdrv_tx.h | 37 + drivers/staging/ti-st/fmdrv_v4l2.c | 755 drivers/staging/ti-st/fmdrv_v4l2.h | 32 + include/linux/videodev2.h |8 + 14 files changed, 4918 insertions(+), 1 deletions(-) create mode 100644 drivers/staging/ti-st/fmdrv.h create mode 100644 drivers/staging/ti-st/fmdrv_common.c create mode 100644 drivers/staging/ti-st/fmdrv_common.h create mode 100644 drivers/staging/ti-st/fmdrv_rx.c create mode 100644 drivers/staging/ti-st/fmdrv_rx.h create mode 100644 drivers/staging/ti-st/fmdrv_tx.c create mode 100644 drivers/staging/ti-st/fmdrv_tx.h create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v5 1/9] include:linux: videodev2.h: FM Rx control class
From: Manjunatha Halli
Introduce V4L2_CTRL_CLASS_FM_RX for FM receivers similar to
V4L2_CTRL_CLASS_FM_TX.
Few controls such as RSSI threshold, Alternate Frequency are for
now under this class.
Signed-off-by: Manjunatha Halli
---
include/linux/videodev2.h |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 5f6f470..5ab66a9 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -932,6 +932,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
+#define V4L2_CTRL_CLASS_FM_RX 0x009c /* FM Tuner control class */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) & 0x0fffUL)
@@ -1304,6 +1305,10 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
+/* FM Tuner class control IDs */
+#define V4L2_CID_FM_RX_CLASS_BASE(V4L2_CTRL_CLASS_FM_RX | 0x900)
+#define V4L2_CID_FM_RX_CLASS (V4L2_CTRL_CLASS_FM_RX | 1)
+
#define V4L2_CID_RDS_TX_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 1)
#define V4L2_CID_RDS_TX_PI (V4L2_CID_FM_TX_CLASS_BASE + 2)
#define V4L2_CID_RDS_TX_PTY(V4L2_CID_FM_TX_CLASS_BASE + 3)
@@ -1333,6 +1338,9 @@ enum v4l2_preemphasis {
#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FM_TX_CLASS_BASE +
113)
#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 114)
+#define V4L2_CID_RSSI_THRESHOLD(V4L2_CID_FM_RX_CLASS_BASE + 2)
+#define V4L2_CID_TUNE_AF (V4L2_CID_FM_RX_CLASS_BASE + 3)
+
/*
* T U N I N G
*/
--
1.5.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v5 2/9] Documentation:DocBook:v4l: Update the controls.xml for TI FM driver
From: Manjunatha Halli Added entries for following 2 new CID's which are added for TI FM driver: - V4L2_CID_RSSI_THRESHOLD - V4L2_CID_TUNE_AF Signed-off-by: Manjunatha Halli --- Documentation/DocBook/v4l/controls.xml | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 2fae3e8..b560953 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -132,6 +132,18 @@ consumption state. Loudness mode (bass boost). + V4L2_CID_RSSI_THRESHOLD + integer + Set RSSI threshold level. Change the default threshold +level used to select valid frequencies during vidioc_s_hw_freq_seek. + + + V4L2_CID_TUNE_AF + integer + Set Alternative Frequency mode. Enable or disable +alternative frequency mode. + + V4L2_CID_BLACK_LEVEL integer Another name for brightness (not a synonym of -- 1.5.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v5 3/9] drivers:staging: ti-st: fmdrv common header file
From: Manjunatha Halli
These are common headers used in FM submodules (FM V4L2, FM common,
FM Rx,and FM TX).
Signed-off-by: Manjunatha Halli
---
drivers/staging/ti-st/fmdrv.h | 247 +
1 files changed, 247 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv.h
diff --git a/drivers/staging/ti-st/fmdrv.h b/drivers/staging/ti-st/fmdrv.h
new file mode 100644
index 000..080561f
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv.h
@@ -0,0 +1,247 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ *
+ * Common header for all FM driver sub-modules.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#ifndef _FM_DRV_H
+#define _FM_DRV_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FM_DRV_VERSION"0.01"
+/* Should match with FM_DRV_VERSION */
+#define FM_DRV_RADIO_VERSION KERNEL_VERSION(0, 0, 1)
+#define FM_DRV_NAME "ti_fmdrv"
+#define FM_DRV_CARD_SHORT_NAME"TI FM Radio"
+#define FM_DRV_CARD_LONG_NAME "Texas Instruments FM Radio"
+
+/* Flag info */
+#define FM_INTTASK_RUNNING0
+#define FM_INTTASK_SCHEDULE_PENDING 1
+#define FM_FIRMWARE_DW_INPROGRESS 2
+#define FM_CORE_READY 3
+#define FM_CORE_TRANSPORT_READY 4
+#define FM_AF_SWITCH_INPROGRESS 5
+#define FM_CORE_TX_XMITING 6
+
+#define FM_TUNE_COMPLETE 0x1
+#define FM_BAND_LIMIT0x2
+
+#define FM_DRV_TX_TIMEOUT (5*HZ) /* 5 seconds */
+#define FM_DRV_RX_SEEK_TIMEOUT (20*HZ) /* 20 seconds */
+
+#define NO_OF_ENTRIES_IN_ARRAY(array) (sizeof(array) / sizeof(array[0]))
+
+enum {
+ FM_MODE_OFF,
+ FM_MODE_TX,
+ FM_MODE_RX,
+ FM_MODE_ENTRY_MAX
+};
+
+#define FM_RX_RDS_INFO_FIELD_MAX 8 /* 4 Group * 2 Bytes */
+
+/*
+ * define private CIDs for V4L2
+ */
+#define V4L2_CID_CHANNEL_SPACING (V4L2_CID_PRIVATE_BASE + 0)
+
+/* RX RDS data format */
+struct fm_rdsdata_format {
+ union {
+ struct {
+ unsigned char rdsbuff[FM_RX_RDS_INFO_FIELD_MAX];
+ } groupdatabuff;
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned char block_c_byte1;
+ unsigned char block_c_byte2;
+ unsigned char block_d_byte1;
+ unsigned char block_d_byte2;
+ } groupgeneral;
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned char firstaf;
+ unsigned char secondaf;
+ unsigned char firstpsbyte;
+ unsigned char secondpsbyte;
+ } group0A;
+
+ struct {
+ unsigned short pidata;
+ unsigned char block_b_byte1;
+ unsigned char block_b_byte2;
+ unsigned short pidata2;
+ unsigned char firstpsbyte;
+ unsigned char secondpsbyte;
+ } group0B;
+ } rdsdata;
+};
+
+/* FM region (Europe/US, Japan) info */
+struct region_info {
+ unsigned int channel_spacing;
+ unsigned int bottom_frequency;
+ unsigned int top_frequency;
+ unsigned char region_index;
+};
+
+typedef void (*int_handler_prototype) (void *);
+
+/* FM Interrupt processing related info */
+struct fm_irq {
+ unsigned char stage_index;
+ unsigned short flag;/* FM interrupt flag */
+ unsigned short mask;/* FM interrupt mask */
+ /* Interrupt process timeout handler */
+ struct timer_list int_timeout_timer;
+ unsigned char irq_service_timeout_retry;
+ int_handler_prototype *fm_int_handlers;
+};
+
+/* RDS info */
+struct fm_rds {
+ unsigned char flag; /* RX RDS on/off status */
+ unsigned char last_block_index; /* Last received RDS block */
+
+ /* RDS buffer */
+ wait_queue_head_t read_queue;
+ unsigned int buf_size; /* Size is
[RFC v5 4/9] drivers:staging: ti-st: fmdrv_v4l2 sources
From: Manjunatha Halli
This module interfaces V4L2 subsystem and FM common
module. It registers itself with V4L2 as Radio module.
Signed-off-by: Manjunatha Halli
Signed-off-by: Bheemsen Kulkarni
---
drivers/staging/ti-st/fmdrv_v4l2.c | 755
drivers/staging/ti-st/fmdrv_v4l2.h | 32 ++
2 files changed, 787 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.c
create mode 100644 drivers/staging/ti-st/fmdrv_v4l2.h
diff --git a/drivers/staging/ti-st/fmdrv_v4l2.c
b/drivers/staging/ti-st/fmdrv_v4l2.c
new file mode 100644
index 000..c993290
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_v4l2.c
@@ -0,0 +1,755 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This file provides interfaces to V4L2 subsystem.
+ *
+ * This module registers with V4L2 subsystem as Radio
+ * data system interface (/dev/radio). During the registration,
+ * it will expose two set of function pointers.
+ *
+ *1) File operation related API (open, close, read, write, poll...etc).
+ *2) Set of V4L2 IOCTL complaint API.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Raja Mani
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include "fmdrv.h"
+#include "fmdrv_v4l2.h"
+#include "fmdrv_common.h"
+#include "fmdrv_rx.h"
+#include "fmdrv_tx.h"
+
+static struct video_device *gradio_dev;
+static unsigned char radio_disconnected;
+
+/* Query control */
+static struct v4l2_queryctrl fmdrv_v4l2_queryctrl[] = {
+ {
+.id = V4L2_CID_AUDIO_VOLUME,
+.type = V4L2_CTRL_TYPE_INTEGER,
+.name = "Volume",
+.minimum = FM_RX_VOLUME_MIN,
+.maximum = FM_RX_VOLUME_MAX,
+.step = 1,
+.default_value = FM_DEFAULT_RX_VOLUME,
+},
+ {
+.id = V4L2_CID_AUDIO_BALANCE,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+ {
+.id = V4L2_CID_AUDIO_BASS,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+ {
+.id = V4L2_CID_AUDIO_TREBLE,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+ {
+.id = V4L2_CID_AUDIO_MUTE,
+.type = V4L2_CTRL_TYPE_BOOLEAN,
+.name = "Mute",
+.minimum = 0,
+.maximum = 2,
+.step = 1,
+.default_value = FM_MUTE_OFF,
+},
+ {
+.id = V4L2_CID_AUDIO_LOUDNESS,
+.flags = V4L2_CTRL_FLAG_DISABLED,
+},
+};
+
+/* -- V4L2 RADIO (/dev/radioX) device file operation interfaces --- */
+
+/* Read RX RDS data */
+static ssize_t fm_v4l2_fops_read(struct file *file, char __user * buf,
+ size_t count, loff_t *ppos)
+{
+ unsigned char rds_mode;
+ int ret;
+ struct fmdrv_ops *fmdev;
+
+ fmdev = video_drvdata(file);
+
+ if (!radio_disconnected) {
+ pr_err("(fmdrv): FM device is already disconnected\n");
+ return -EIO;
+ }
+
+ /* Turn on RDS mode , if it is disabled */
+ ret = fm_rx_get_rds_mode(fmdev, &rds_mode);
+ if (ret < 0) {
+ pr_err("(fmdrv): Unable to read current rds mode\n");
+ return ret;
+ }
+
+ if (rds_mode == FM_RDS_DISABLE) {
+ ret = fmc_set_rds_mode(fmdev, FM_RDS_ENABLE);
+ if (ret < 0) {
+ pr_err("(fmdrv): Failed to enable rds mode\n");
+ return ret;
+ }
+ }
+
+ /* Copy RDS data from internal buffer to user buffer */
+ ret = fmc_transfer_rds_from_internal_buff(fmdev, file, buf, count);
+
+ return ret;
+}
+
+/* Write TX RDS data */
+static ssize_t fm_v4l2_fops_write(struct file *file, const char __user * buf,
+ size_t count, loff_t *ppos)
+{
+ struct tx_rds rds;
+ int ret;
+ struct fmdrv_ops *fmdev;
+
+ ret = copy_from_user(&rds, buf, sizeof(rds));
+ pr_debug("(fmdrv): (%d)type: %d, text %s, af %d\n",
+ ret, rds.text_type, rds.text, rds.af_freq);
+
+ fmdev = video_drvdata(file);
+ fm_tx_set_radio_text(fmdev, rds.text, rds.text_type);
+ fm_tx_set_af(fmdev, rds.af_freq);
+
+ return 0;
+}
+
+static unsigned int fm_v4l2_fops_poll(struct file *file,
+ struct poll_table_struct *pts)
+{
+ int
[RFC v5 6/9] drivers:staging: ti-st: fmdrv_rx sources
From: Manjunatha Halli
This has implementation for FM RX functionality.
It communicates with FM V4l2 module and FM common module.
Signed-off-by: Manjunatha Halli
Signed-off-by: Bheemsen Kulkarni
---
drivers/staging/ti-st/fmdrv_rx.c | 903 ++
drivers/staging/ti-st/fmdrv_rx.h | 59 +++
2 files changed, 962 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv_rx.c
create mode 100644 drivers/staging/ti-st/fmdrv_rx.h
diff --git a/drivers/staging/ti-st/fmdrv_rx.c b/drivers/staging/ti-st/fmdrv_rx.c
new file mode 100644
index 000..cdf3385
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_rx.c
@@ -0,0 +1,903 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This sub-module of FM driver implements FM RX functionality.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ * Author: Raja Mani
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include "fmdrv.h"
+#include "fmdrv_common.h"
+#include "fmdrv_rx.h"
+
+void fm_rx_reset_rds_cache(struct fmdrv_ops *fmdev)
+{
+ fmdev->rx.rds.flag = FM_RDS_DISABLE;
+ fmdev->rx.rds.last_block_index = 0;
+ fmdev->rx.rds.wr_index = 0;
+ fmdev->rx.rds.rd_index = 0;
+
+ if (fmdev->rx.af_mode == FM_RX_RDS_AF_SWITCH_MODE_ON)
+ fmdev->irq_info.mask |= FM_LEV_EVENT;
+}
+
+void fm_rx_reset_curr_station_info(struct fmdrv_ops *fmdev)
+{
+ fmdev->rx.cur_station_info.picode = FM_NO_PI_CODE;
+ fmdev->rx.cur_station_info.no_of_items_in_afcache = 0;
+ fmdev->rx.cur_station_info.af_list_max = 0;
+}
+
+int fm_rx_set_frequency(struct fmdrv_ops *fmdev, unsigned int freq_to_set)
+{
+ unsigned long timeleft;
+ unsigned short payload, curr_frq, frq_index;
+ unsigned int curr_frq_in_khz;
+ int ret, resp_len;
+
+ if (fmdev->curr_fmmode != FM_MODE_RX)
+ return -EPERM;
+
+ if (freq_to_set < fmdev->rx.region.bottom_frequency ||
+ freq_to_set > fmdev->rx.region.top_frequency) {
+ pr_err("(fmdrv): Invalid frequency %d\n", freq_to_set);
+ return -EINVAL;
+ }
+
+ /* Set audio enable */
+ payload = FM_RX_FM_AUDIO_ENABLE_I2S_AND_ANALOG;
+
+ ret = fmc_send_cmd(fmdev, AUDIO_ENABLE_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Set hilo to automatic selection */
+ payload = FM_RX_IFFREQ_HILO_AUTOMATIC;
+ ret = fmc_send_cmd(fmdev, HILO_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Calculate frequency index to write */
+ frq_index = (freq_to_set - fmdev->rx.region.bottom_frequency) /
+ FM_FREQ_MUL;
+
+ /* Set frequency index */
+ payload = frq_index;
+ ret = fmc_send_cmd(fmdev, FREQ_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Read flags - just to clear any pending interrupts if we had */
+ ret = fmc_send_cmd(fmdev, FLAG_GET, REG_RD, NULL, 2,
+ NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Enable FR, BL interrupts */
+ fmdev->irq_info.mask |= (FM_FR_EVENT | FM_BL_EVENT);
+ payload = fmdev->irq_info.mask;
+ ret = fmc_send_cmd(fmdev, INT_MASK_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Start tune */
+ payload = FM_TUNER_PRESET_MODE;
+ ret = fmc_send_cmd(fmdev, TUNER_MODE_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Wait for tune ended interrupt */
+ init_completion(&fmdev->maintask_completion);
+ timeleft = wait_for_completion_timeout(&fmdev->maintask_completion,
+ FM_DRV_TX_TIMEOUT);
+ if (!timeleft) {
+ pr_err("(fmdrv): Timeout(%d sec),didn't get tune ended int\n",
+ jiffies_to_msecs(FM_DRV_TX_TIMEOUT) / 1000);
+ return -ETIMEDOUT;
+ }
+
+ /* Read freq back to confirm */
+ ret = fmc_send_cm
[RFC v5 7/9] drivers:staging: ti-st: fmdrv_tx sources
From: Manjunatha Halli
This has implementation for FM TX functionality.
It communicates with FM V4l2 module and FM common module.
Signed-off-by: Manjunatha Halli
Signed-off-by: Bheemsen Kulkarni
---
drivers/staging/ti-st/fmdrv_tx.c | 420 ++
drivers/staging/ti-st/fmdrv_tx.h | 37
2 files changed, 457 insertions(+), 0 deletions(-)
create mode 100644 drivers/staging/ti-st/fmdrv_tx.c
create mode 100644 drivers/staging/ti-st/fmdrv_tx.h
diff --git a/drivers/staging/ti-st/fmdrv_tx.c b/drivers/staging/ti-st/fmdrv_tx.c
new file mode 100644
index 000..c9e738e
--- /dev/null
+++ b/drivers/staging/ti-st/fmdrv_tx.c
@@ -0,0 +1,420 @@
+/*
+ * FM Driver for Connectivity chip of Texas Instruments.
+ * This sub-module of FM driver implements FM TX functionality.
+ *
+ * Copyright (C) 2010 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include
+#include "fmdrv.h"
+#include "fmdrv_common.h"
+#include "fmdrv_tx.h"
+
+int fm_tx_set_stereo_mono(struct fmdrv_ops *fmdev, unsigned short mode)
+{
+ unsigned short payload;
+ int ret = 0;
+
+ if (fmdev->curr_fmmode != FM_MODE_TX)
+ return -EPERM;
+
+ if (fmdev->tx_data.aud_mode == mode)
+ return ret;
+
+ pr_debug("stereo mode: %d\n", mode);
+
+ /* Set Stereo/Mono mode */
+ payload = (1 - mode);
+ ret = fmc_send_cmd(fmdev, MONO_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ fmdev->tx_data.aud_mode = mode;
+
+ return ret;
+}
+
+static int __set_rds_text(struct fmdrv_ops *fmdev, unsigned char *rds_text)
+{
+ unsigned short payload;
+ int ret;
+
+ ret = fmc_send_cmd(fmdev, RDS_DATA_SET, REG_WR, rds_text,
+ strlen(rds_text), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Scroll mode */
+ payload = (unsigned short)0x1;
+ ret = fmc_send_cmd(fmdev, DISPLAY_MODE, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int __set_rds_data_mode(struct fmdrv_ops *fmdev, unsigned char mode)
+{
+ unsigned short payload;
+ int ret;
+
+ /* Setting unique PI TODO: how unique? */
+ payload = (unsigned short)0xcafe;
+ ret = fmc_send_cmd(fmdev, PI_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* Set decoder id */
+ payload = (unsigned short)0xa;
+ ret = fmc_send_cmd(fmdev, DI_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* TODO: RDS_MODE_GET? */
+ return 0;
+}
+
+static int __set_rds_len(struct fmdrv_ops *fmdev, unsigned char type,
+ unsigned short len)
+{
+ unsigned short payload;
+ int ret;
+
+ len |= type << 8;
+ payload = len;
+ ret = fmc_send_cmd(fmdev, RDS_CONFIG_DATA_SET, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ /* TODO: LENGTH_GET? */
+ return 0;
+}
+
+int fm_tx_set_rds_mode(struct fmdrv_ops *fmdev, unsigned char rds_en_dis)
+{
+ unsigned short payload;
+ int ret;
+ unsigned char rds_text[] = "Zoom2\n";
+
+ if (fmdev->curr_fmmode != FM_MODE_TX)
+ return -EPERM;
+
+ pr_debug("rds_en_dis:%d(E:%d, D:%d)\n", rds_en_dis,
+ FM_RDS_ENABLE, FM_RDS_DISABLE);
+
+ if (rds_en_dis == FM_RDS_ENABLE) {
+ /* Set RDS length */
+ __set_rds_len(fmdev, 0, strlen(rds_text));
+
+ /* Set RDS text */
+ __set_rds_text(fmdev, rds_text);
+
+ /* Set RDS mode */
+ __set_rds_data_mode(fmdev, 0x0);
+ }
+
+ /* Send command to enable RDS */
+ if (rds_en_dis == FM_RDS_ENABLE)
+ payload = 0x01;
+ else
+ payload = 0x00;
+
+ ret = fmc_send_cmd(fmdev, RDS_DATA_ENB, REG_WR, &payload,
+ sizeof(payload), NULL, NULL);
+ if (ret < 0)
+ return ret;
+
+ if (rds_en_
[RFC v5 9/9] driver:staging:ti-st: Update TODO for FM V4L2 driver.
From: Manjunatha Halli Signed-off-by: Manjunatha Halli --- drivers/staging/ti-st/TODO | 17 - 1 files changed, 16 insertions(+), 1 deletions(-) diff --git a/drivers/staging/ti-st/TODO b/drivers/staging/ti-st/TODO index ebfd6bb..1d004cb 100644 --- a/drivers/staging/ti-st/TODO +++ b/drivers/staging/ti-st/TODO @@ -1,6 +1,21 @@ TODO: -1. Step up and maintain this driver to ensure that it continues +1. Upstreaming BT driver + +2. Upstreaming FM driver + + a. Use the new V4L2 control framework for all the V4L2 controls supported. + + b. Change the interrupt handling mechanism as per comments by 'Hans Verkuil'. + + c. Remove use of new V4L2 CID to set the BAND (US/JAPAN). Instead handle it + in driver. + + d. Remove the new private CID defined for channel spacing instead handle it + in ioctl VIDIOC_S_HW_FREQ_SEEK. + + +3. Step up and maintain this driver to ensure that it continues to work. Having the hardware for this is pretty much a requirement. If this does not happen, the will be removed in the 2.6.35 kernel release. -- 1.5.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v5 8/9] drivers:staging: ti-st: Kconfig & Makefile change
From: Manjunatha Halli Add new menu option in Kconfig and compilation option in Makefile for TI FM driver. Signed-off-by: Manjunatha Halli --- drivers/staging/ti-st/Kconfig | 10 ++ drivers/staging/ti-st/Makefile |2 ++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/staging/ti-st/Kconfig b/drivers/staging/ti-st/Kconfig index 074b8e8..43b6dea 100644 --- a/drivers/staging/ti-st/Kconfig +++ b/drivers/staging/ti-st/Kconfig @@ -11,4 +11,14 @@ config ST_BT This enables the Bluetooth driver for TI BT/FM/GPS combo devices. This makes use of shared transport line discipline core driver to communicate with the BT core of the combo chip. + +config ST_FM +tristate "fm driver for ST" +depends on VIDEO_DEV && RFKILL +select TI_ST +help + This enables the FM driver for TI BT/FM/GPS combo devices. + This makes use of shared transport line discipline core driver to + communicate with the FM core of the combo chip. + endmenu diff --git a/drivers/staging/ti-st/Makefile b/drivers/staging/ti-st/Makefile index 5f11b82..330f95b 100644 --- a/drivers/staging/ti-st/Makefile +++ b/drivers/staging/ti-st/Makefile @@ -3,3 +3,5 @@ # and its protocol drivers (BT, FM, GPS) # obj-$(CONFIG_ST_BT)+= bt_drv.o +obj-$(CONFIG_ST_FM)+= fm_drv.o +fm_drv-objs:= fmdrv_common.o fmdrv_rx.o fmdrv_tx.o fmdrv_v4l2.o -- 1.5.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gnutv: What causes DVR overflow?
On Mon, Nov 29, 2010 at 2:54 AM, David Liontooth wrote: > > I'm seeing great results with gnutv on HVR-1850 cards, but each recording > triggers the message > > DVR overflow > > What is this, and what are the typical causes? What can I do to prevent it > from happening? I don't know about gnutv specifically, but I do know that -EOVERFLOW is returned when an application fails to read the /dev/dvb/adapterX/dvr0 device fast enough. It's the driver signaling to the application that it did not read the file handle often/fast enough and that the driver is going to drop packets to keep up. The driver has a limited amount of buffering, so if you have a delay that is too long between read() calls (or your read buffer is too small to accommodate the data rate) you will encounter this condition. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/7] v4l: videobuf2: add generic memory handling routines
Hello,
On Monday, November 29, 2010 10:39 AM Laurent Pinchart wrote:
> Hi Marek,
>
> On Friday 19 November 2010 16:55:39 Marek Szyprowski wrote:
> > From: Pawel Osciak
> >
> > Add generic memory handling routines for userspace pointer handling,
> > contiguous memory verification and mapping.
> >
> > Signed-off-by: Pawel Osciak
> > Signed-off-by: Marek Szyprowski
> > Signed-off-by: Kyungmin Park
> > CC: Pawel Osciak
> > ---
> > drivers/media/video/Kconfig|3 +
> > drivers/media/video/Makefile |1 +
> > drivers/media/video/videobuf2-memops.c | 199
> > include/media/videobuf2-memops.h |
> > 31 +
> > 4 files changed, 234 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/media/video/videobuf2-memops.c
> > create mode 100644 include/media/videobuf2-memops.h
> >
> > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> > index fef6a14..83ce858 100644
> > --- a/drivers/media/video/Kconfig
> > +++ b/drivers/media/video/Kconfig
> > @@ -52,6 +52,9 @@ config V4L2_MEM2MEM_DEV
> > config VIDEOBUF2_CORE
> > tristate
> >
> > +config VIDEOBUF2_MEMOPS
> > + tristate
> > +
> > #
> > # Multimedia Video device configuration
> > #
> > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> > index 77c4f85..a97a2a0 100644
> > --- a/drivers/media/video/Makefile
> > +++ b/drivers/media/video/Makefile
> > @@ -115,6 +115,7 @@ obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o
> > obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
> >
> > obj-$(CONFIG_VIDEOBUF2_CORE) += videobuf2-core.o
> > +obj-$(CONFIG_VIDEOBUF2_MEMOPS) += videobuf2-memops.o
> >
> > obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
> >
> > diff --git a/drivers/media/video/videobuf2-memops.c
> > b/drivers/media/video/videobuf2-memops.c new file mode 100644
> > index 000..67ebdff
> > --- /dev/null
> > +++ b/drivers/media/video/videobuf2-memops.c
> > @@ -0,0 +1,199 @@
> > +/*
> > + * videobuf2-memops.c - generic memory handling routines for videobuf2
> > + *
> > + * Copyright (C) 2010 Samsung Electronics
> > + *
> > + * Author: Pawel Osciak
> > + *Marek Szyprowski
> > + *
> > + * 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.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +
> > +/**
> > + * vb2_contig_verify_userptr() - verify contiguity of a userspace-mapped
> > memory + * @vma:virtual memory region which maps the physical memory
> > + * to be verified
> > + * @vaddr: starting virtual address of the area to be verified
> > + * @size: size of the area to be verified
> > + * @paddr: will return physical address for the given vaddr
> > + *
> > + * This function will go through memory area of size size mapped at vaddr
> > and + * verify that the underlying physical pages are contiguous.
> > + *
> > + * Returns 0 on success and a physical address to the memory pointed
> > + * to by vaddr in paddr.
> > + */
> > +int vb2_contig_verify_userptr(struct vm_area_struct *vma,
> > + unsigned long vaddr, unsigned long size,
> > + unsigned long *paddr)
> > +{
> > + struct mm_struct *mm = current->mm;
> > + unsigned long offset;
> > + unsigned long vma_size;
> > + unsigned long curr_pfn, prev_pfn;
> > + unsigned long num_pages;
> > + int ret = -EINVAL;
> > + unsigned int i;
> > +
> > + offset = vaddr & ~PAGE_MASK;
> > +
> > + down_read(&mm->mmap_sem);
> > +
> > + vma = find_vma(mm, vaddr);
>
> You're overwriting the vma argument, why do you need it ?
Well, I'm sorry for this. Looks I've missed something here. I will fix this in
the next version.
> > + if (!vma) {
> > + printk(KERN_ERR "Invalid userspace address\n");
> > + goto done;
> > + }
> > +
> > + vma_size = vma->vm_end - vma->vm_start;
> > +
> > + if (size > vma_size - offset) {
> > + printk(KERN_ERR "Region too small\n");
> > + goto done;
> > + }
> > + num_pages = (size + offset) >> PAGE_SHIFT;
> > +
> > + ret = follow_pfn(vma, vaddr, &curr_pfn);
>
> Maybe you could put this call in the loop to avoid code duplication ? Feel
> free to steal code from
> http://git.linuxtv.org/pinchartl/media.git?a=blob;f=drivers/media/video/isp/ispqueue.c;h=6750f68a6476f
> c168d44563b332f6b23b2700504;hb=630004a88986b1f8b42c5fddb9a5e5c0d575b464#l358
> :-)
Ok, Thx :)
>
> > + if (ret) {
> > + printk(KERN_ERR "Invalid userspace address\n");
> > + goto done;
> > + }
> > +
> > + *paddr = (curr_pfn << PAGE_SHIFT) + offset;
> > +
> > + for (i = 1; i < num_pages; ++i) {
> > + prev_pfn = curr_pfn;
> > + vaddr += PAGE_SIZE;
> > +
> > + ret = fo
Re: [PATCH 2/7] v4l: videobuf2: add generic memory handling routines
Hi Marek,
On Monday 29 November 2010 14:24:35 Marek Szyprowski wrote:
> On Monday, November 29, 2010 10:39 AM Laurent Pinchart wrote:
> > On Friday 19 November 2010 16:55:39 Marek Szyprowski wrote:
> > > From: Pawel Osciak
> > >
> > > Add generic memory handling routines for userspace pointer handling,
> > > contiguous memory verification and mapping.
> > >
> > > Signed-off-by: Pawel Osciak
> > > Signed-off-by: Marek Szyprowski
> > > Signed-off-by: Kyungmin Park
> > > CC: Pawel Osciak
[snip]
> > > + if (ret) {
> > > + printk(KERN_ERR "Invalid userspace address\n");
> > > + goto done;
> > > + }
> > > +
> > > + *paddr = (curr_pfn << PAGE_SHIFT) + offset;
> > > +
> > > + for (i = 1; i < num_pages; ++i) {
> > > + prev_pfn = curr_pfn;
> > > + vaddr += PAGE_SIZE;
> > > +
> > > + ret = follow_pfn(vma, vaddr, &curr_pfn);
> > > + if (ret || curr_pfn != prev_pfn + 1) {
> > > + printk(KERN_ERR "Invalid userspace address\n");
> > > + ret = -EINVAL;
> >
> > I would use -EFAULT when curr_pfn != prev_pfn + 1.
>
> I don't think that this situation desires for a EFAULT error code. EINVAL
> is imho enough to let application know that this memory cannot be used for
> the userptr buffer.
-EINVAL is used quite a lot already to report many different error conditions.
-EFAULT would let application know that the issue is about the pointer address
as opposed to the buffer index for instance.
[snip]
> > > + * Returns 0 on success.
> > > + */
> > > +int vb2_mmap_pfn_range(struct vm_area_struct *vma, unsigned long
> > > paddr, + unsigned long size,
> > > + const struct vm_operations_struct *vm_ops,
> > > + void *priv)
> > > +{
> > > + int ret;
> > > +
> > > + size = min_t(unsigned long, vma->vm_end - vma->vm_start, size);
> > > +
> > > + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> >
> > Now we're getting to the dirty part :-) Do we always want to map the
> > memory uncached ?
>
> That's how it is handled by the videobuf1 and probably most of drivers that
> use physically contiguous memory. I don't want to change it right now.
> This will be a way too much for a single step. Once drivers will settle
> down on vb2 we may start thinking of adding support for CACHED vs.
> UNCACHED mappings.
OK.
> > I'm not too sure about what the use cases for this function are. It seems
> > to be used by the DMA coherent and CMA allocators. Are you sure they
> > will always use physically contiguous memory ?
>
> Yes, both of them are designed for physically contiguous memory. I just
> noticed that the videobuf1 used the dma-contig name which is a bit better
> for this case. ;)
OK.
> > > + ret = remap_pfn_range(vma, vma->vm_start, paddr >> PAGE_SHIFT,
> > > + size, vma->vm_page_prot);
> > > + if (ret) {
> > > + printk(KERN_ERR "Remapping memory failed, error: %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + vma->vm_flags |= VM_DONTEXPAND | VM_RESERVED;
> > > + vma->vm_private_data= priv;
> > > + vma->vm_ops = vm_ops;
> > > +
> > > + vm_ops->open(vma);
> > > +
> > > + printk(KERN_DEBUG "%s: mapped paddr 0x%08lx at 0x%08lx, size %ld\n",
> > > + __func__, paddr, vma->vm_start, size);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/**
> > > + * vb2_get_userptr() - acquire an area pointed to by userspace addres
> > > vaddr + * @vaddr: virtual userspace address to the given area
> > > + *
> > > + * This function attempts to acquire an area mapped in the userspace
> > > for + * the duration of a hardware operation.
> > > + *
> > > + * Returns a virtual memory region associated with the given vaddr on
> > > success + * or NULL.
> > > + */
> > > +struct vm_area_struct *vb2_get_userptr(unsigned long vaddr)
> > > +{
> > > + struct mm_struct *mm = current->mm;
> > > + struct vm_area_struct *vma;
> > > + struct vm_area_struct *vma_copy;
> > > +
> > > + vma_copy = kmalloc(sizeof(struct vm_area_struct), GFP_KERNEL);
> > > + if (vma_copy == NULL)
> > > + return NULL;
> > > +
> > > + down_read(&mm->mmap_sem);
> > > +
> > > + vma = find_vma(mm, vaddr);
> > > + if (!vma)
> > > + goto done;
> > > +
> > > + if (vma->vm_ops && vma->vm_ops->open)
> > > + vma->vm_ops->open(vma);
> > > +
> > > + if (vma->vm_file)
> > > + get_file(vma->vm_file);
> >
> > Could you explain what this is for ?
>
> This is called when you access physically contiguous memory from different
> device which has been earlier mmaped by the application. This way
> applications uses userptr mode with dmacontig. When doing this, you must
> ensure somehow that this memory won't be released/freed before you finish.
> This is achieved by calling open() callback and increasing the use count
> of the mmaped file. Same things happen when your application calls fork()
> and a new process gets access to
Re: Disable IR on dvb_usb_af9015
2010/11/29 poma : > Josu Lazkano wrote: >> >> Thanks for your reply. >> >> >> 2010/11/28 Antti Palosaari : >>> >>> There is no module or per device basis option for that. Use option from >>> module dvb-usb. >> >> Sorry, but I don't know how to use the option from module dvb-usb, I >> am new on this. >> >> I want to disable it, because I have problems to assign LIRC which >> input to choose. >> >> Kind regards. >> >>> Antti >>> >>> >>> On 11/28/2010 02:58 PM, Josu Lazkano wrote: Hello list! I have a Kworld U399U twin DVB-T adapter. It has a IR rceiver and I want to disable it from module on "/etc/modprobe.d/options.conf" Is any way to do this? I use to use the modprobe option to assign the number of the adapters: options dvb_usb_af9015 adapter_nr=4,5 It will be great to disable the IR. Thanks for all and best regards. >>> >>> -- >>> http://palosaari.fi/ >>> >> >> >> > > /etc/modprobe.d/options.conf: > options dvb-usb disable_rc_polling=1 > Thanks for the reply, I edit this file, but know I don't have any IR input device. I have an other DVB-T device (Pinnacle one) with a IR receiver, and I want to use it. I solved with this config: options dvb_usb_dib0700 adapter_nr=7 options cx23885 adapter_nr=6 options dvb_usb_af9015 adapter_nr=4,5 disable_rc_polling=1 Thanks and best regards. > Regards, > poma > -- Josu Lazkano -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/7] v4l: videobuf2: add generic memory handling routines
Hello,
On Monday, November 29, 2010 2:41 PM Laurent Pinchart wrote:
> Hi Marek,
>
> On Monday 29 November 2010 14:24:35 Marek Szyprowski wrote:
> > On Monday, November 29, 2010 10:39 AM Laurent Pinchart wrote:
> > > On Friday 19 November 2010 16:55:39 Marek Szyprowski wrote:
> > > > From: Pawel Osciak
> > > >
> > > > Add generic memory handling routines for userspace pointer handling,
> > > > contiguous memory verification and mapping.
> > > >
> > > > Signed-off-by: Pawel Osciak
> > > > Signed-off-by: Marek Szyprowski
> > > > Signed-off-by: Kyungmin Park
> > > > CC: Pawel Osciak
>
> [snip]
>
> > > > + if (ret) {
> > > > + printk(KERN_ERR "Invalid userspace address\n");
> > > > + goto done;
> > > > + }
> > > > +
> > > > + *paddr = (curr_pfn << PAGE_SHIFT) + offset;
> > > > +
> > > > + for (i = 1; i < num_pages; ++i) {
> > > > + prev_pfn = curr_pfn;
> > > > + vaddr += PAGE_SIZE;
> > > > +
> > > > + ret = follow_pfn(vma, vaddr, &curr_pfn);
> > > > + if (ret || curr_pfn != prev_pfn + 1) {
> > > > + printk(KERN_ERR "Invalid userspace address\n");
> > > > + ret = -EINVAL;
> > >
> > > I would use -EFAULT when curr_pfn != prev_pfn + 1.
> >
> > I don't think that this situation desires for a EFAULT error code. EINVAL
> > is imho enough to let application know that this memory cannot be used for
> > the userptr buffer.
>
> -EINVAL is used quite a lot already to report many different error conditions.
> -EFAULT would let application know that the issue is about the pointer address
> as opposed to the buffer index for instance.
The application will not notice it probably in this case, because a default
EFAULT handler will kill it in most of the cases ;)
> > > > +/**
> > > > + * vb2_get_userptr() - acquire an area pointed to by userspace addres
> > > > vaddr + * @vaddr: virtual userspace address to the given area
> > > > + *
> > > > + * This function attempts to acquire an area mapped in the userspace
> > > > for + * the duration of a hardware operation.
> > > > + *
> > > > + * Returns a virtual memory region associated with the given vaddr on
> > > > success + * or NULL.
> > > > + */
> > > > +struct vm_area_struct *vb2_get_userptr(unsigned long vaddr)
> > > > +{
> > > > + struct mm_struct *mm = current->mm;
> > > > + struct vm_area_struct *vma;
> > > > + struct vm_area_struct *vma_copy;
> > > > +
> > > > + vma_copy = kmalloc(sizeof(struct vm_area_struct), GFP_KERNEL);
> > > > + if (vma_copy == NULL)
> > > > + return NULL;
> > > > +
> > > > + down_read(&mm->mmap_sem);
> > > > +
> > > > + vma = find_vma(mm, vaddr);
> > > > + if (!vma)
> > > > + goto done;
> > > > +
> > > > + if (vma->vm_ops && vma->vm_ops->open)
> > > > + vma->vm_ops->open(vma);
> > > > +
> > > > + if (vma->vm_file)
> > > > + get_file(vma->vm_file);
> > >
> > > Could you explain what this is for ?
> >
> > This is called when you access physically contiguous memory from different
> > device which has been earlier mmaped by the application. This way
> > applications uses userptr mode with dmacontig. When doing this, you must
> > ensure somehow that this memory won't be released/freed before you finish.
> > This is achieved by calling open() callback and increasing the use count
> > of the mmaped file. Same things happen when your application calls fork()
> > and a new process gets access to your mmaped device.
>
> Good point.
>
> Don't you also need to pin the pages to memory with get_user_pages() ?
Nope. get_user_pages() doesn't support pfn-type memory at all (it just fails
this that case). PFN-type memory cannot be swapped out anyway so it not a
problem here.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] v4l: videobuf2: add generic memory handling routines
Hi Marek,
On Monday 29 November 2010 15:27:00 Marek Szyprowski wrote:
> Hello,
>
> On Monday, November 29, 2010 2:41 PM Laurent Pinchart wrote:
> > Hi Marek,
> >
> > On Monday 29 November 2010 14:24:35 Marek Szyprowski wrote:
> > > On Monday, November 29, 2010 10:39 AM Laurent Pinchart wrote:
> > > > On Friday 19 November 2010 16:55:39 Marek Szyprowski wrote:
> > > > > From: Pawel Osciak
> > > > >
> > > > > Add generic memory handling routines for userspace pointer
> > > > > handling, contiguous memory verification and mapping.
> > > > >
> > > > > Signed-off-by: Pawel Osciak
> > > > > Signed-off-by: Marek Szyprowski
> > > > > Signed-off-by: Kyungmin Park
> > > > > CC: Pawel Osciak
> >
> > [snip]
> >
> > > > > + if (ret) {
> > > > > + printk(KERN_ERR "Invalid userspace address\n");
> > > > > + goto done;
> > > > > + }
> > > > > +
> > > > > + *paddr = (curr_pfn << PAGE_SHIFT) + offset;
> > > > > +
> > > > > + for (i = 1; i < num_pages; ++i) {
> > > > > + prev_pfn = curr_pfn;
> > > > > + vaddr += PAGE_SIZE;
> > > > > +
> > > > > + ret = follow_pfn(vma, vaddr, &curr_pfn);
> > > > > + if (ret || curr_pfn != prev_pfn + 1) {
> > > > > + printk(KERN_ERR "Invalid userspace address\n");
> > > > > + ret = -EINVAL;
> > > >
> > > > I would use -EFAULT when curr_pfn != prev_pfn + 1.
> > >
> > > I don't think that this situation desires for a EFAULT error code.
> > > EINVAL is imho enough to let application know that this memory cannot
> > > be used for the userptr buffer.
> >
> > -EINVAL is used quite a lot already to report many different error
> > conditions. -EFAULT would let application know that the issue is about
> > the pointer address as opposed to the buffer index for instance.
>
> The application will not notice it probably in this case, because a default
> EFAULT handler will kill it in most of the cases ;)
Will it ? Where ? ioctls can return -EFAULT.
> > > > > +/**
> > > > > + * vb2_get_userptr() - acquire an area pointed to by userspace
> > > > > addres vaddr + * @vaddr: virtual userspace address to the given
> > > > > area + *
> > > > > + * This function attempts to acquire an area mapped in the
> > > > > userspace for + * the duration of a hardware operation.
> > > > > + *
> > > > > + * Returns a virtual memory region associated with the given vaddr
> > > > > on success + * or NULL.
> > > > > + */
> > > > > +struct vm_area_struct *vb2_get_userptr(unsigned long vaddr)
> > > > > +{
> > > > > + struct mm_struct *mm = current->mm;
> > > > > + struct vm_area_struct *vma;
> > > > > + struct vm_area_struct *vma_copy;
> > > > > +
> > > > > + vma_copy = kmalloc(sizeof(struct vm_area_struct), GFP_KERNEL);
> > > > > + if (vma_copy == NULL)
> > > > > + return NULL;
> > > > > +
> > > > > + down_read(&mm->mmap_sem);
> > > > > +
> > > > > + vma = find_vma(mm, vaddr);
> > > > > + if (!vma)
> > > > > + goto done;
> > > > > +
> > > > > + if (vma->vm_ops && vma->vm_ops->open)
> > > > > + vma->vm_ops->open(vma);
> > > > > +
> > > > > + if (vma->vm_file)
> > > > > + get_file(vma->vm_file);
> > > >
> > > > Could you explain what this is for ?
> > >
> > > This is called when you access physically contiguous memory from
> > > different device which has been earlier mmaped by the application.
> > > This way applications uses userptr mode with dmacontig. When doing
> > > this, you must ensure somehow that this memory won't be released/freed
> > > before you finish. This is achieved by calling open() callback and
> > > increasing the use count of the mmaped file. Same things happen when
> > > your application calls fork() and a new process gets access to your
> > > mmaped device.
> >
> > Good point.
> >
> > Don't you also need to pin the pages to memory with get_user_pages() ?
>
> Nope. get_user_pages() doesn't support pfn-type memory at all (it just
> fails this that case). PFN-type memory cannot be swapped out anyway so it
> not a problem here.
But vb2_get_userptr() can be used on non-PFN memory, can't it ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/7] v4l: videobuf2: add generic memory handling routines
Hello,
On Monday, November 29, 2010 3:37 PM Laurent Pinchart wrote:
> On Monday 29 November 2010 15:27:00 Marek Szyprowski wrote:
> > Hello,
> >
> > On Monday, November 29, 2010 2:41 PM Laurent Pinchart wrote:
> > > Hi Marek,
> > >
> > > On Monday 29 November 2010 14:24:35 Marek Szyprowski wrote:
> > > > On Monday, November 29, 2010 10:39 AM Laurent Pinchart wrote:
> > > > > On Friday 19 November 2010 16:55:39 Marek Szyprowski wrote:
> > > > > > From: Pawel Osciak
> > > > > >
> > > > > > Add generic memory handling routines for userspace pointer
> > > > > > handling, contiguous memory verification and mapping.
> > > > > >
> > > > > > Signed-off-by: Pawel Osciak
> > > > > > Signed-off-by: Marek Szyprowski
> > > > > > Signed-off-by: Kyungmin Park
> > > > > > CC: Pawel Osciak
> > >
> > > [snip]
> > >
> > > > > > + if (ret) {
> > > > > > + printk(KERN_ERR "Invalid userspace address\n");
> > > > > > + goto done;
> > > > > > + }
> > > > > > +
> > > > > > + *paddr = (curr_pfn << PAGE_SHIFT) + offset;
> > > > > > +
> > > > > > + for (i = 1; i < num_pages; ++i) {
> > > > > > + prev_pfn = curr_pfn;
> > > > > > + vaddr += PAGE_SIZE;
> > > > > > +
> > > > > > + ret = follow_pfn(vma, vaddr, &curr_pfn);
> > > > > > + if (ret || curr_pfn != prev_pfn + 1) {
> > > > > > + printk(KERN_ERR "Invalid userspace address\n");
> > > > > > + ret = -EINVAL;
> > > > >
> > > > > I would use -EFAULT when curr_pfn != prev_pfn + 1.
> > > >
> > > > I don't think that this situation desires for a EFAULT error code.
> > > > EINVAL is imho enough to let application know that this memory cannot
> > > > be used for the userptr buffer.
> > >
> > > -EINVAL is used quite a lot already to report many different error
> > > conditions. -EFAULT would let application know that the issue is about
> > > the pointer address as opposed to the buffer index for instance.
> >
> > The application will not notice it probably in this case, because a default
> > EFAULT handler will kill it in most of the cases ;)
>
> Will it ? Where ? ioctls can return -EFAULT.
Ok. You are right. I mixed something. Please ignore my previous comment.
> > > > > > +/**
> > > > > > + * vb2_get_userptr() - acquire an area pointed to by userspace
> > > > > > addres vaddr + * @vaddr:virtual userspace address to the given
> > > > > > area + *
> > > > > > + * This function attempts to acquire an area mapped in the
> > > > > > userspace for + * the duration of a hardware operation.
> > > > > > + *
> > > > > > + * Returns a virtual memory region associated with the given vaddr
> > > > > > on success + * or NULL.
> > > > > > + */
> > > > > > +struct vm_area_struct *vb2_get_userptr(unsigned long vaddr)
> > > > > > +{
> > > > > > + struct mm_struct *mm = current->mm;
> > > > > > + struct vm_area_struct *vma;
> > > > > > + struct vm_area_struct *vma_copy;
> > > > > > +
> > > > > > + vma_copy = kmalloc(sizeof(struct vm_area_struct), GFP_KERNEL);
> > > > > > + if (vma_copy == NULL)
> > > > > > + return NULL;
> > > > > > +
> > > > > > + down_read(&mm->mmap_sem);
> > > > > > +
> > > > > > + vma = find_vma(mm, vaddr);
> > > > > > + if (!vma)
> > > > > > + goto done;
> > > > > > +
> > > > > > + if (vma->vm_ops && vma->vm_ops->open)
> > > > > > + vma->vm_ops->open(vma);
> > > > > > +
> > > > > > + if (vma->vm_file)
> > > > > > + get_file(vma->vm_file);
> > > > >
> > > > > Could you explain what this is for ?
> > > >
> > > > This is called when you access physically contiguous memory from
> > > > different device which has been earlier mmaped by the application.
> > > > This way applications uses userptr mode with dmacontig. When doing
> > > > this, you must ensure somehow that this memory won't be released/freed
> > > > before you finish. This is achieved by calling open() callback and
> > > > increasing the use count of the mmaped file. Same things happen when
> > > > your application calls fork() and a new process gets access to your
> > > > mmaped device.
> > >
> > > Good point.
> > >
> > > Don't you also need to pin the pages to memory with get_user_pages() ?
> >
> > Nope. get_user_pages() doesn't support pfn-type memory at all (it just
> > fails this that case). PFN-type memory cannot be swapped out anyway so it
> > not a problem here.
>
> But vb2_get_userptr() can be used on non-PFN memory, can't it ?
I thought that this function is used only by dma-coherent and cma allocators.
dma-sg and iommu allocators will definitely call get_user_pages().
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] v4l: videobuf2: add generic memory handling routines
Hi Marek,
On Monday 29 November 2010 16:13:17 Marek Szyprowski wrote:
> On Monday, November 29, 2010 3:37 PM Laurent Pinchart wrote:
> > On Monday 29 November 2010 15:27:00 Marek Szyprowski wrote:
> > > On Monday, November 29, 2010 2:41 PM Laurent Pinchart wrote:
> > > > On Monday 29 November 2010 14:24:35 Marek Szyprowski wrote:
> > > > > On Monday, November 29, 2010 10:39 AM Laurent Pinchart wrote:
> > > > > > On Friday 19 November 2010 16:55:39 Marek Szyprowski wrote:
> > > > > > > From: Pawel Osciak
> > > > > > >
> > > > > > > Add generic memory handling routines for userspace pointer
> > > > > > > handling, contiguous memory verification and mapping.
> > > > > > >
> > > > > > > Signed-off-by: Pawel Osciak
> > > > > > > Signed-off-by: Marek Szyprowski
> > > > > > > Signed-off-by: Kyungmin Park
> > > > > > > CC: Pawel Osciak
> > > >
> > > > [snip]
> > > >
> > > > > > > + if (ret) {
> > > > > > > + printk(KERN_ERR "Invalid userspace address\n");
> > > > > > > + goto done;
> > > > > > > + }
> > > > > > > +
> > > > > > > + *paddr = (curr_pfn << PAGE_SHIFT) + offset;
> > > > > > > +
> > > > > > > + for (i = 1; i < num_pages; ++i) {
> > > > > > > + prev_pfn = curr_pfn;
> > > > > > > + vaddr += PAGE_SIZE;
> > > > > > > +
> > > > > > > + ret = follow_pfn(vma, vaddr, &curr_pfn);
> > > > > > > + if (ret || curr_pfn != prev_pfn + 1) {
> > > > > > > + printk(KERN_ERR "Invalid userspace address\n");
> > > > > > > + ret = -EINVAL;
> > > > > >
> > > > > > I would use -EFAULT when curr_pfn != prev_pfn + 1.
> > > > >
> > > > > I don't think that this situation desires for a EFAULT error code.
> > > > > EINVAL is imho enough to let application know that this memory
> > > > > cannot be used for the userptr buffer.
> > > >
> > > > -EINVAL is used quite a lot already to report many different error
> > > > conditions. -EFAULT would let application know that the issue is
> > > > about the pointer address as opposed to the buffer index for
> > > > instance.
> > >
> > > The application will not notice it probably in this case, because a
> > > default EFAULT handler will kill it in most of the cases ;)
> >
> > Will it ? Where ? ioctls can return -EFAULT.
>
> Ok. You are right. I mixed something. Please ignore my previous comment.
>
> > > > > > > +/**
> > > > > > > + * vb2_get_userptr() - acquire an area pointed to by userspace
> > > > > > > addres vaddr + * @vaddr: virtual userspace address to the given
> > > > > > > area + *
> > > > > > > + * This function attempts to acquire an area mapped in the
> > > > > > > userspace for + * the duration of a hardware operation.
> > > > > > > + *
> > > > > > > + * Returns a virtual memory region associated with the given
> > > > > > > vaddr on success + * or NULL.
> > > > > > > + */
> > > > > > > +struct vm_area_struct *vb2_get_userptr(unsigned long vaddr)
> > > > > > > +{
> > > > > > > + struct mm_struct *mm = current->mm;
> > > > > > > + struct vm_area_struct *vma;
> > > > > > > + struct vm_area_struct *vma_copy;
> > > > > > > +
> > > > > > > + vma_copy = kmalloc(sizeof(struct vm_area_struct),
> > > > > > > GFP_KERNEL); +if (vma_copy == NULL)
> > > > > > > + return NULL;
> > > > > > > +
> > > > > > > + down_read(&mm->mmap_sem);
> > > > > > > +
> > > > > > > + vma = find_vma(mm, vaddr);
> > > > > > > + if (!vma)
> > > > > > > + goto done;
> > > > > > > +
> > > > > > > + if (vma->vm_ops && vma->vm_ops->open)
> > > > > > > + vma->vm_ops->open(vma);
> > > > > > > +
> > > > > > > + if (vma->vm_file)
> > > > > > > + get_file(vma->vm_file);
> > > > > >
> > > > > > Could you explain what this is for ?
> > > > >
> > > > > This is called when you access physically contiguous memory from
> > > > > different device which has been earlier mmaped by the application.
> > > > > This way applications uses userptr mode with dmacontig. When doing
> > > > > this, you must ensure somehow that this memory won't be
> > > > > released/freed before you finish. This is achieved by calling
> > > > > open() callback and increasing the use count of the mmaped file.
> > > > > Same things happen when your application calls fork() and a new
> > > > > process gets access to your mmaped device.
> > > >
> > > > Good point.
> > > >
> > > > Don't you also need to pin the pages to memory with get_user_pages()
> > > > ?
> > >
> > > Nope. get_user_pages() doesn't support pfn-type memory at all (it just
> > > fails this that case). PFN-type memory cannot be swapped out anyway so
> > > it not a problem here.
> >
> > But vb2_get_userptr() can be used on non-PFN memory, can't it ?
>
> I thought that this function is used only by dma-coherent and cma
> allocators. dma-sg and iommu allocators will definitely call
> get_user_pages().
Then it should probably be renamed to vb2_get_pfn_user_pages().
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-
Re: [PATCH 3/7] v4l: videobuf2: add vmalloc allocator
Hi Marek,
On Friday 19 November 2010 16:55:40 Marek Szyprowski wrote:
> From: Pawel Osciak
>
> Add an implementation of contiguous virtual memory allocator and handling
> routines for videobuf2, implemented on top of vmalloc()/vfree() calls.
>
> Signed-off-by: Pawel Osciak
> Signed-off-by: Kyungmin Park
> Signed-off-by: Marek Szyprowski
> CC: Pawel Osciak
> ---
> drivers/media/video/Kconfig |5 +
> drivers/media/video/Makefile|1 +
> drivers/media/video/videobuf2-vmalloc.c | 177
> +++ include/media/videobuf2-vmalloc.h |
> 21
> 4 files changed, 204 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/videobuf2-vmalloc.c
> create mode 100644 include/media/videobuf2-vmalloc.h
>
[snip]
> +static const struct vb2_mem_ops vb2_vmalloc_ops = {
> + .alloc = vb2_vmalloc_alloc,
> + .put= vb2_vmalloc_put,
> + .vaddr = vb2_vmalloc_vaddr,
> + .mmap = vb2_vmalloc_mmap,
> + .num_users = vb2_vmalloc_num_users,
> +};
No USERPTR support ? :-)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] soc_camera: Add the ability to bind regulators to soc_camedra devices
On Sun, Nov 28, 2010 at 08:05:06PM +0100, Guennadi Liakhovetski wrote: > On Sun, 28 Nov 2010, Alberto Panizzo wrote: > > In certain machines, camera devices are supplied directly > > by a number of regulators. This patch add the ability to drive > > these regulators directly by the soc_camera driver. > IIRC, there has been a discussion a while ago, how to supply power to > cameras by regulators. Someone has tried to provide a .power() hook in the > platform code, but the problem was the order of driver loading / probing. > So, how about doing the following: > 1. in your platform code you register a notifier like > bus_register_notifier(&soc_camera_bus_type, &cam_notifier); FWIW I'm looking at implementing a standard regulator API feature along these lines in the background. This should hopefully mean we don't need driver support for most simple power control applications. No ETA yet. > The reasons why I do not want to add this to the core are: (1) I do not > want to have two methods for turning power on and off: a platform provided > .power() hook and and a set of regulators, (2) would anyone really want to > use several regulators for a camera sensor? If so, can it be the case, > that, for example, the regulators have to be switched off in the reverse > order to switching on? Or something else? (3) regulators can often do > more, than just set one of two power levels - for on and off. What if a > need arises to use other voltages? The way MMC handled this was to provide a standard version of the hook in the core which could be used by platforms with regulators supplying the device - they just assign the appropriate function as their power() operation AIUI. That seems a fairly clean way of keeping stuff in the core without giving up the flexibility. > Is there any really good reason, why we _have_ to do this in soc-camera > core? It does save everyone open coding stuff. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] soc_camera: Add the ability to bind regulators to soc_camedra devices
On Mon, Nov 29, 2010 at 10:34:57AM +0100, Alberto Panizzo wrote:
> On dom, 2010-11-28 at 20:05 +0100, Guennadi Liakhovetski wrote:
> > (2) would anyone really want to
> > use several regulators for a camera sensor? If so, can it be the case,
> > that, for example, the regulators have to be switched off in the reverse
> > order to switching on? Or something else?
> Well, I'm working on the i.MX31 3 Stack board support and there are 2
> regulators that powers the camera and if you consider the digital output
> that enable another supplier needed, the total regulators are three..
> So, yes a list of regulators is needed in this case, and Yes I did not
> considered the order of enabling and disabling operations. Just because
> even the freescale drivers didn't.
> A practical general rule is to turn off switchers in the reverse order
> than the turning on one. And this can be easily implemented here.
> But as you rose the question, we can add priorities of turning on and
> off.
If you use the regulator bulk API it'll reverse the ordering when doing
the power down (or should if it doesn't already).
> > > +static int soc_camera_power_set(struct soc_camera_device *icd,
> > > + struct soc_camera_link *icl,
> > > + int power_on)
> > > +{
> > > + int ret, i;
> > > +
> > > + for (i = 0; i < icd->num_soc_regulators; i++) {
> > > + if (power_on) {
> > > + ret = regulator_set_voltage(icd->soc_regulators[i],
> > > + icl->soc_regulator_descs[i].value_on_min,
> > > + icl->soc_regulator_descs[i].value_on_max);
Unless you're actively varying the voltages at runtime (as Guennadi
mentioned) I'd really expect the voltages to be handled by the regulator
constraints.
--
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 5/6] davinci vpbe: platform specific additions
On Sat, Nov 27, 2010 at 20:52:14, Muralidharan Karicheri wrote:
> > +static int dm644x_set_if_config(enum v4l2_mbus_pixelcode pixcode) {
> > + unsigned int val = 0;
> > + int ret = 0;
> > +
> > + switch (pixcode) {
> > + case V4L2_MBUS_FMT_FIXED:
> > + /* Analog out.do nothing */
> > + break;
> > + case V4L2_MBUS_FMT_YUYV8_2X8:
> > + /* BT656 */
> > + val = (1<<12);
> > + /*set VDMD in VMOD */
> > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > + /* Set YCCTL */
> > + dm644x_reg_modify(venc_ycctl_reg, 1, 1);
> > + break;
> > + case V4L2_MBUS_FMT_YUYV10_1X20:
> > + /* This was VPBE_DIGITAL_IF_YCC16.BT656.Replace the enum
> > +accordingly
> > + * when the right one gets into open source */
> > + val = 0 << 12;
> > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > + dm644x_reg_modify(venc_ycctl_reg, 1, 1);
> > + break;
> > + case V4L2_MBUS_FMT_SGRBG8_1X8:
> > + /* This was VPBE_DIGITAL_IF_PRGB/SRGB.Replace the enum
> > +accordingly
> > + * when the right one gets into open source */
> > + val = 2 << 12;
> > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + break;
> > + }
> > + return ret;
> > +}
>
> The media bus format was added to sub device interface sometime back to
> >configure the media data format (8 bit, 16 bit etc) and there is also a set
> >of APIs to set the pad configuration (done by Laurent) which is being
> >reviewed. In the context of that, I believe the venc VMOD configuration can
> >be handled by implementing s_mbus_fmt() sub device API at venc. Currently
> >OSD sub device has set_layer_config() which consists of setting the pixel
> >format, frame format and sub-frame(crop). I think this can be replaced by
> >s_mbus_fmt(). So on a board file, we could define the pad configuration
> >which will include the mbus code such as V4L2_MBUS_FMT_YUYV8_2X8 + addition
> >pad configurations such as embedded sync enabled etc. So once sub device is
> >selected, vpbe controller will set the pad configuration (obtained from
> >board file for each of the ?). The pad in this case is the link between
> >venc lcd port to external encoder. When S_FMT/S_CROP is called on the video
> >node, the controller calls s_mbus_fmt() on the osd and venc sub device to
> >set the mbus formats.
[Manju] I changed the implementation currently only with the view of reducing
the privately defined enumerations which was one of the comments by Hans. I am
following Laurent's patch series, and it is a good idea to get to s_mbus_fmt
when it gets in. Till then we can keep this. In the same regard, I asked
Laurent to suggest the correct enums for the RGB666 interfaces. I have no
problem in removing this call now and re-introducing it as part of next patch
series. I hope by that time Laurent's patch would get in too.
>
> Since the external encoder support is a TBD, I am okay if you implement this
> after this patch series is merged to the tree.
>
> Murali
> > +
> > +static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
> > +
> > +static struct resource dm644x_v4l2_disp_resources[] = {
> > + {
> > + .start = IRQ_VENCINT,
> > + .end = IRQ_VENCINT,
> > + .flags = IORESOURCE_IRQ,
> > + },
> > + {
> > + .start = 0x01C72400,
> > + .end = 0x01C72400 + 0x180,
> > + .flags = IORESOURCE_MEM,
> > + },
> > +
> > +};
> > +static struct platform_device vpbe_v4l2_display = {
> > + .name = "vpbe-v4l2",
> > + .id = -1,
> > + .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
> > + .resource = dm644x_v4l2_disp_resources,
> > + .dev = {
> > + .dma_mask = &vpbe_display_dma_mask,
> > + .coherent_dma_mask = DMA_BIT_MASK(32),
> > + },
> > +};
> > +struct venc_platform_data dm644x_venc_pdata = {
> > + .venc_type = DM644X_VPBE,
> > + .setup_pinmux = dm644x_vpbe_setup_pinmux,
> > + .setup_clock = dm644x_venc_setup_clock,
> > + .setup_if_config = dm644x_set_if_config, };
> > +
> > +static struct platform_device dm644x_venc_dev = {
> > + .name = VPBE_VENC_SUBDEV_NAME,
> > + .id = -1,
> > + .num_resources = ARRAY_SIZE(dm644x_venc_resources),
> > + .resource = dm644x_venc_resources,
> > + .dev = {
> > + .dma_mask = &dm644x_venc_dma_mask,
> > + .coherent_dma_mask = DMA_BIT_MASK(32),
> > + .platform_data = (void *)&dm644x_venc_pdata,
> > + },
> > +};
> > +
> >
RE: [PATCH v2 5/6] davinci vpbe: platform specific additions
Resending the reply with proper indentation..
On Mon, Nov 29, 2010 at 21:27:39, Hadli, Manjunath wrote:
> On Sat, Nov 27, 2010 at 20:52:14, Muralidharan Karicheri wrote:
> > > +static int dm644x_set_if_config(enum v4l2_mbus_pixelcode pixcode) {
> > > + unsigned int val = 0;
> > > + int ret = 0;
> > > +
> > > + switch (pixcode) {
> > > + case V4L2_MBUS_FMT_FIXED:
> > > + /* Analog out.do nothing */
> > > + break;
> > > + case V4L2_MBUS_FMT_YUYV8_2X8:
> > > + /* BT656 */
> > > + val = (1<<12);
> > > + /*set VDMD in VMOD */
> > > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > > + /* Set YCCTL */
> > > + dm644x_reg_modify(venc_ycctl_reg, 1, 1);
> > > + break;
> > > + case V4L2_MBUS_FMT_YUYV10_1X20:
> > > + /* This was VPBE_DIGITAL_IF_YCC16.BT656.Replace the enum
> > > +accordingly
> > > + * when the right one gets into open source */
> > > + val = 0 << 12;
> > > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > > + dm644x_reg_modify(venc_ycctl_reg, 1, 1);
> > > + break;
> > > + case V4L2_MBUS_FMT_SGRBG8_1X8:
> > > + /* This was VPBE_DIGITAL_IF_PRGB/SRGB.Replace the enum
> > > +accordingly
> > > + * when the right one gets into open source */
> > > + val = 2 << 12;
> > > + dm644x_reg_modify(venc_vmod_reg, val, (7 << 12));
> > > + break;
> > > + default:
> > > + ret = -EINVAL;
> > > + break;
> > > + }
> > > + return ret;
> > > +}
> >
> > The media bus format was added to sub device interface sometime back to
> > >configure the media data format (8 bit, 16 bit etc) and there is also a
> > set >of APIs to set the pad configuration (done by Laurent) which is being
> > >reviewed. In the context of that, I believe the venc VMOD configuration
> > can >be handled by implementing s_mbus_fmt() sub device API at venc.
> > Currently >OSD sub device has set_layer_config() which consists of setting
> > the pixel >format, frame format and sub-frame(crop). I think this can be
> > replaced by >s_mbus_fmt(). So on a board file, we could define the pad
> > configuration >which will include the mbus code such as
> > V4L2_MBUS_FMT_YUYV8_2X8 + addition >pad configurations such as embedded
> > sync enabled etc. So once sub device is >selected, vpbe controller will set
> > the pad configuration (obtained from >board file for each of the ?). The
> > pad in this case is the link between >venc lcd port to external encoder.
> > When S_FMT/S_CROP is called on the video >node, the controller calls
> > s_mbus_fmt() on the osd and venc sub device to >set the mbus formats.
>
[Manju] I changed the implementation currently only with the view
of reducing the privately defined enumerations which was one of the
comments by Hans. I am following Laurent's patch series, and it
is a good idea to get to s_mbus_fmt when it gets in. Till then we
can keep this. In the same regard, I asked Laurent to suggest
the correct enums for the RGB666 interfaces. I have no problem in
removing this call now and re-introducing it as part of next
patch series. I hope by that time Laurent's patch would get in too.
>
> >
> > Since the external encoder support is a TBD, I am okay if you implement
> > this after this patch series is merged to the tree.
> >
> > Murali
> > > +
> > > +static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
> > > +
> > > +static struct resource dm644x_v4l2_disp_resources[] = {
> > > + {
> > > + .start = IRQ_VENCINT,
> > > + .end = IRQ_VENCINT,
> > > + .flags = IORESOURCE_IRQ,
> > > + },
> > > + {
> > > + .start = 0x01C72400,
> > > + .end = 0x01C72400 + 0x180,
> > > + .flags = IORESOURCE_MEM,
> > > + },
> > > +
> > > +};
> > > +static struct platform_device vpbe_v4l2_display = {
> > > + .name = "vpbe-v4l2",
> > > + .id = -1,
> > > + .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
> > > + .resource = dm644x_v4l2_disp_resources,
> > > + .dev = {
> > > + .dma_mask = &vpbe_display_dma_mask,
> > > + .coherent_dma_mask = DMA_BIT_MASK(32),
> > > + },
> > > +};
> > > +struct venc_platform_data dm644x_venc_pdata = {
> > > + .venc_type = DM644X_VPBE,
> > > + .setup_pinmux = dm644x_vpbe_setup_pinmux,
> > > + .setup_clock = dm644x_venc_setup_clock,
> > > + .setup_if_config = dm644x_set_if_config, };
> > > +
> > > +static struct platform_device dm644x_venc_dev = {
> > > + .name = VPBE_VENC_SUBDEV_NAME,
> > > + .id = -1,
> > > + .num_resources = ARRAY_SIZE(dm644x_venc_resources),
> > > +
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Nov 29 19:00:22 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: user accesses in ivtv-fileops.c:ivtv_v4l2_write ?
Dr. David Alan Gilbert wrote: > Hi, > Sparse pointed me at the following line in ivtv-fileops.c's ivtv_v4l2_write: > > ivtv_write_vbi(itv, (const struct v4l2_sliced_vbi_data > *)user_buf, elems); > > Now user_buf is a parameter: > const char __user *user_buf, > > so that is losing the __user, and I don't see what else protects > the accesses that ivtv_write_vbi performs. Ummm, "__user" and similar attributes like "__iomem", don't protect anything -- do they? I thought they were there to help tools like sparse to detect type problems. It looks like the patch that added "__user" attributes in the ivtv driver missed or deliberately ignored this function. > Is there something that makes this safe? Not from what I can see in a few minutes worth of looking. >From include/linux/compiler.h" #ifdef __CHECKER__ # define __user __attribute__((noderef, address_space(1))) # define __kernel __attribute__((address_space(0))) ... # define __iomem__attribute__((noderef, address_space(2))) It would appear that directly dereferencing the user pointer is not a good thing to do. However, as you note, that's exactly what ivtv_write_vbi() does. v4l2_write() and ivtv_v4l2_write() are wrappers that don't do any copy_from_user() calls before passing the data along. Why does the call not induce faults for people? I'm not sure. Without looking too hard through all the copy_from_user() checks, I'm guessing: a. the user_buf for the VBI data is likely allocated properly aligned on a writeable page. b. 23 lines of VBI data for two fields only takes up 64*23*2 = 2944 bytes which likely does not cross a 4096 byte page boundary c. Not many people have PVR-350's and even less use it to send out VBI data to their TV. Patches welcome. :) Regards, Andy -- 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: Problem of using v4l2 spec with codec function
Hi, Thanks for comment. I hope we would submit two nodes driver for encoder, decoder within 2010. BRs, > -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Hans Verkuil > Sent: Monday, November 29, 2010 9:17 PM > To: Jonghun Han > Cc: 'Laurent Pinchart'; jaeryul...@samsung.com; linux-media@vger.kernel.org > Subject: RE: RFC: Problem of using v4l2 spec with codec function > > > > > > Hi, > > > > In two nodes case, application cannot know the feature via > > VIDIOC_QUERYCAP. > > Because decoder and encoder return the same CAPABILITY. OUTPUT and > CAPTURE > > So application should call VIDIOC_G_FMT to recognize the feature. > > The current V4L API is not good enough to determine what each video node > can do. The upcoming media controller API should help in that. For the > time being you should just assume that applications know what they are > doing. > > Anyway, I think having two device nodes is a perfectly valid solution. > Particularly for more complex scenarios. > > Regards, > > Hans > > > > > BRs, > > > >> -Original Message- > >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >> ow...@vger.kernel.org] On Behalf Of Jonghun Han > >> Sent: Monday, November 29, 2010 8:49 PM > >> To: 'Laurent Pinchart'; 'Hans Verkuil' > >> Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org > >> Subject: RE: RFC: Problem of using v4l2 spec with codec function > >> > >> > >> Laurent Pinchart wrote: > >> > >> > -Original Message- > >> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > >> > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > >> > Sent: Monday, November 29, 2010 6:20 PM > >> > To: Hans Verkuil > >> > Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org > >> > Subject: Re: RFC: Problem of using v4l2 spec with codec function > >> > > >> > Hi, > >> > > >> > >> > >> > > If so, then I think creating a so-called 'private' control for your > >> > > hardware would be the best way to go. As an example of private > >> controls > >> > > search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. > >> > > >> > I would rely on formats. If the input format is YUV and the output > >> format is > >> > MPEG, it's pretty obvious that the hardware should be encoding. If the > >> formats > >> > are the other way around, then the hardware should be decoding. > >> > >> Right. But.. > >> If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them > >> ? > >> In my opinion decoder and encoder can have own control Ids. > >> For example, > >> After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is > >> called > >> how to return it ? > >> VIDIOC_S_CTRL has been succeeded because driver cannot know whether > >> decoder or encoder. > >> And then is it right that VIDIOC_S_FMT for encoder is failed due to > >> VIDIOC_S_CTRL for decoder ? > >> > >> Can two nodes(encoder, decoder) be the solution ? > >> > >> BRs, > >> > >> > -- > >> > 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 > >> > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-media" > >> in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > -- > Hans Verkuil - video4linux developer - sponsored by Cisco > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
