RE: videobuf2 user pointer vma release seqeuence
Hello, On Tuesday, August 30, 2011 3:50 AM Tang, Yu wrote: > As we are trying to adapt to videobuf2, we found here is the potential > issue with user pointer VMA release sequence. It is not aligned with > munmap syscalls behavior, (mm/mmap, remove_vma). > > In the current vb2_put_vma implementation, it will release the file first, > then release VMA. If the file handle is closed, and vma is munmap by user > space, then the file ref count could reach 0 and be freed before the VMA > vm_ops->vm_close is called while vm_close is typically assume the file is > valid when it's called. > > If it's agreed as valid concern, I will submit the fix as below soon. > Thanks! You are definitely right! Thanks for pointing this bug! I will add your patch to my videobuf2 fixes branch. 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Florian,
On Monday 29 August 2011 18:41:03 Florian Tobias Schandinat wrote:
> On 08/29/2011 02:32 PM, Laurent Pinchart wrote:
> > On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:
> >>> On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
> > On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
>
> - When using a mode that cannot be represented in the legacy
>
> way,
> >>>
> >>> Definitely.
> >>>
> - But what with modes that can be represented? Legacy software
>
> cannot handle FB_{TYPE,VISUAL}_FOURCC.
> >>>
> >>> My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
> >>> configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called
> >>> with a non-FOURCC format, the driver will report non-FOURCC types
> >>> and visuals.
> >>
> >> Hmm, two use cases:
> >> - The video mode is configured using a FOURCC-aware tool ("fbset
> >> on
> >>
> >> steroids").
> >
> > Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
>
> Yep.
>
> >> Later the user runs a legacy application.
> >>
> >> => Do not retain FOURCC across opening of /dev/fb*.
> >
> > I know about that problem, but it's not that easy to work around. We
> > have no per-open fixed and variable screen info, and FB devices can
> > be opened by multiple applications at the same time.
> >
> >> - Is there an easy way to force FOURCC reporting, so new apps
> >> don't
> >>
> >> have to support parsing the legacy formats? This is useful for new
> >> apps that want to support (a subset of) FOURCC modes only.
> >
> > Not at the moment.
>
> So perhaps we do need new ioctls instead...
> That would also ease an in-kernel translation layer.
> >>>
> >>> Do you mean new ioctls to replace the FOURCC API proposal, or new
> >>> ioctls for the above two operations ?
> >>
> >> New ioctls to replace the FOURCC proposal.
> >
> > *sigh*...
> >
> > I'd like other people's opinion on this before throwing everything away.
> > Florian, Magnus, Guennadi, others, what do you think ?
>
> So, your issue is that some formats can be represented in the new and the
> old way? There are 2 simpler solutions I can think of:
>
> (1) ignore it, just do it the way Laurent proposed. I understand that
> someone might feel uneasy about applications that are trapped because they
> don't know the new format but could work with the old one. But I think
> this is not a big issue as many applications will just try to set their
> own mode. For those that doesn't and rely on the previous mode that is set
> by fbset or similar, we could change fbset to prefer the old format if
> available. But even if we don't do this, I don't have a problem with a
> program failing because it sees an unsuitable mode even if it supports the
> legacy mode. It's not a regression and can be easily fixed in userspace.
I agree with you here. Issues should be fixed in userspace. I don't expect
many issues in practice, as fbdev is often used on systems where userspace
components are developed to work with each other (such as embedded systems).
If such a system is upgraded to use YUV support, all components will likely be
tested and upgraded.
> (2) forbid it, just allow drivers to implement FOURCC for formats that
> cannot be represented in the old scheme. This is my preferred solution if
> anyone has problems with (1).
I'm tempted by that solution. Not that I have an issue with (1), but I'm
wondering if we should try to use the FOURCC API for all formats, or just for
formats that can't be represented by the current API. We currently have no
bitplane FOURCCs, and I'm not sure if it would be worth adding them.
BTW, do recent hardware still support planar (in the bitplane sense) frame
buffers ? If so, is that used in practice on recent devices ? If the answer is
no, (1) might be the best solution, with bit-planar formats supported by the
current API only, and all other formats supported by the FOURCC API.
> I don't see how IOCTLs would help here. The pixel format just belongs into
> var and fix so it has to be represented there anyway and thus set through
> it. We could do an IOCTL that always returns the FOURCC active at the
> moment, if such a FOURCC exists, and always use the legacy API for
> representing it in var/fix, if it exists. But as I see this is not what
> you thought about so please explain what your IOCTLS would look like and
> how they would solve the problem.
>
> And I don't think a in-kernel translation layer is a good idea. Yes, it
> s
Re: [ANN] Meeting minutes of the Cambourne meeting
On Tue, 30 Aug 2011, Laurent Pinchart wrote: > Hi Guennadi, > > On Tuesday 30 August 2011 00:20:09 Guennadi Liakhovetski wrote: > > On Mon, 29 Aug 2011, Laurent Pinchart wrote: > > > > [snip] > > > > > My idea was to let the kernel register all devices based on the DT or > > > board code. When the V4L2 host/bridge driver gets registered, it will > > > then call a V4L2 core function with a list of subdevs it needs. The V4L2 > > > core would store that information and react to bus notifier events to > > > notify the V4L2 host/bridge driver when all subdevs are present. At that > > > point the host/bridge driver will get hold of all the subdevs and call > > > (probably through the V4L2 core) their .registered operation. That's > > > where the subdevs will get access to their clock using clk_get(). > > > > Correct me, if I'm wrong, but this seems to be the case of sensor (and > > other i2c-client) drivers having to succeed their probe() methods without > > being able to actually access the hardware? > > That's right. I'd love to find a better way :-) Note that this is already the > case for many subdev drivers that probe the hardware in the .registered() > operation instead of the probe() method. Then why do you think it is better, than adding devices from bridge drivers? Think about hotpluggable devices - drivers create devices all the time - USB etc. Why cannot we do the same? As a historic reference: soc-camera used to do this too before - probe without hardware access and "really-probe" after the host turns on the clock. Then we switched to registering devices later. I like the present approach better. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Meeting minutes of the Cambourne meeting
Hi Guennadi, On Tuesday 30 August 2011 00:20:09 Guennadi Liakhovetski wrote: > On Mon, 29 Aug 2011, Laurent Pinchart wrote: > > [snip] > > > My idea was to let the kernel register all devices based on the DT or > > board code. When the V4L2 host/bridge driver gets registered, it will > > then call a V4L2 core function with a list of subdevs it needs. The V4L2 > > core would store that information and react to bus notifier events to > > notify the V4L2 host/bridge driver when all subdevs are present. At that > > point the host/bridge driver will get hold of all the subdevs and call > > (probably through the V4L2 core) their .registered operation. That's > > where the subdevs will get access to their clock using clk_get(). > > Correct me, if I'm wrong, but this seems to be the case of sensor (and > other i2c-client) drivers having to succeed their probe() methods without > being able to actually access the hardware? That's right. I'd love to find a better way :-) Note that this is already the case for many subdev drivers that probe the hardware in the .registered() operation instead of the probe() method. -- 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: [ANN] Meeting minutes of the Cambourne meeting
On Mon, 29 Aug 2011, Laurent Pinchart wrote: [snip] > My idea was to let the kernel register all devices based on the DT or board > code. When the V4L2 host/bridge driver gets registered, it will then call a > V4L2 core function with a list of subdevs it needs. The V4L2 core would store > that information and react to bus notifier events to notify the V4L2 > host/bridge driver when all subdevs are present. At that point the > host/bridge > driver will get hold of all the subdevs and call (probably through the V4L2 > core) their .registered operation. That's where the subdevs will get access > to > their clock using clk_get(). Correct me, if I'm wrong, but this seems to be the case of sensor (and other i2c-client) drivers having to succeed their probe() methods without being able to actually access the hardware? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: vb2: dma contig allocator: use dma_addr instread of paddr
On Mon, 29 Aug 2011, Marek Szyprowski wrote:
> Use the correct 'dma_addr' name for the buffer address. 'paddr' suggested
> that this is the physical address in system memory. For most ARM platforms
> these two are the same, but this is not a generic rule. 'dma_addr' will
> also point better to dma-mapping api.
>
> Signed-off-by: Marek Szyprowski
> Signed-off-by: Kyungmin Park
> CC: Pawel Osciak
For atmel-isi.c, mx3_camera.c, sh_mobile_ceu_camera.c:
Acked-by: Guennadi Liakhovetski
Thanks
Guennadi
> ---
> drivers/media/video/atmel-isi.c |2 +-
> drivers/media/video/marvell-ccic/mcam-core.c |4 +-
> drivers/media/video/mx3_camera.c |2 +-
> drivers/media/video/s5p-fimc/fimc-core.c |6 ++--
> drivers/media/video/s5p-mfc/s5p_mfc.c|4 +-
> drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 10
> drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 30
> +-
> drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 14 ++--
> drivers/media/video/s5p-tv/mixer_grp_layer.c |2 +-
> drivers/media/video/s5p-tv/mixer_vp_layer.c |4 +-
> drivers/media/video/sh_mobile_ceu_camera.c |2 +-
> drivers/media/video/videobuf2-dma-contig.c | 16 +++---
> include/media/videobuf2-dma-contig.h |6 ++--
> 13 files changed, 51 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
> index 5a4b2d7..7e1d789 100644
> --- a/drivers/media/video/atmel-isi.c
> +++ b/drivers/media/video/atmel-isi.c
> @@ -341,7 +341,7 @@ static int buffer_prepare(struct vb2_buffer *vb)
>
> /* Initialize the dma descriptor */
> desc->p_fbd->fb_address =
> - vb2_dma_contig_plane_paddr(vb, 0);
> + vb2_dma_contig_plane_dma_addr(vb, 0);
> desc->p_fbd->next_fbd_address = 0;
> set_dma_ctrl(desc->p_fbd, ISI_DMA_CTRL_WB);
>
> diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
> b/drivers/media/video/marvell-ccic/mcam-core.c
> index 744cf37..7abe503 100644
> --- a/drivers/media/video/marvell-ccic/mcam-core.c
> +++ b/drivers/media/video/marvell-ccic/mcam-core.c
> @@ -450,7 +450,7 @@ static void mcam_set_contig_buffer(struct mcam_camera
> *cam, int frame)
> buf = cam->vb_bufs[frame ^ 0x1];
> cam->vb_bufs[frame] = buf;
> mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
> - vb2_dma_contig_plane_paddr(&buf->vb_buf, 0));
> + vb2_dma_contig_plane_dma_addr(&buf->vb_buf, 0));
> set_bit(CF_SINGLE_BUFFER, &cam->flags);
> singles++;
> return;
> @@ -461,7 +461,7 @@ static void mcam_set_contig_buffer(struct mcam_camera
> *cam, int frame)
> buf = list_first_entry(&cam->buffers, struct mcam_vb_buffer, queue);
> list_del_init(&buf->queue);
> mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
> - vb2_dma_contig_plane_paddr(&buf->vb_buf, 0));
> + vb2_dma_contig_plane_dma_addr(&buf->vb_buf, 0));
> cam->vb_bufs[frame] = buf;
> clear_bit(CF_SINGLE_BUFFER, &cam->flags);
> }
> diff --git a/drivers/media/video/mx3_camera.c
> b/drivers/media/video/mx3_camera.c
> index 9ae7785..c8e958a 100644
> --- a/drivers/media/video/mx3_camera.c
> +++ b/drivers/media/video/mx3_camera.c
> @@ -247,7 +247,7 @@ static int mx3_videobuf_prepare(struct vb2_buffer *vb)
> }
>
> if (buf->state == CSI_BUF_NEEDS_INIT) {
> - sg_dma_address(sg) = vb2_dma_contig_plane_paddr(vb, 0);
> + sg_dma_address(sg) = vb2_dma_contig_plane_dma_addr(vb, 0);
> sg_dma_len(sg) = new_size;
>
> buf->txd = ichan->dma_chan.device->device_prep_slave_sg(
> diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
> b/drivers/media/video/s5p-fimc/fimc-core.c
> index 8152756..266d6b9 100644
> --- a/drivers/media/video/s5p-fimc/fimc-core.c
> +++ b/drivers/media/video/s5p-fimc/fimc-core.c
> @@ -457,7 +457,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
> vb2_buffer *vb,
> dbg("memplanes= %d, colplanes= %d, pix_size= %d",
> frame->fmt->memplanes, frame->fmt->colplanes, pix_size);
>
> - paddr->y = vb2_dma_contig_plane_paddr(vb, 0);
> + paddr->y = vb2_dma_contig_plane_dma_addr(vb, 0);
>
> if (frame->fmt->memplanes == 1) {
> switch (frame->fmt->colplanes) {
> @@ -485,10 +485,10 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
> vb2_buffer *vb,
> }
> } else {
> if (frame->fmt->memplanes >= 2)
> - paddr->cb = vb2_dma_contig_plane_paddr(vb, 1);
> + paddr->cb = vb2_dma_contig_plane_dma_addr(vb, 1);
>
> if (frame->fmt->memplanes == 3)
> -
[V4L2]decrement struct v4l2_device refcount on device unregister
commit bedf8bcf6b4f90a6e31add3721a2e71877289381 introduced reference counting for struct v4l2_device. In v4l2_device_register() a call to kref_init() initializes reference count to 1, but in v4l2_device_unregister() there is no corresponding decrement. End result is that reference count never reaches zero and v4l2_device_release() is never called, not even on videodev module unload. Fix this by adding reference counter decrement to v4l2_device_unregister(). Resending due to spurious newlines around the patch in previous message. Signed-off-by: Maciej Szmigiero diff --git a/drivers/media/video/v4l2-device.c b/drivers/media/video/v4l2-device.c index c72856c..eb39af9 100644 --- a/drivers/media/video/v4l2-device.c +++ b/drivers/media/video/v4l2-device.c @@ -131,6 +131,8 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev) } #endif } + + v4l2_device_put(v4l2_dev); } EXPORT_SYMBOL_GPL(v4l2_device_unregister); -- 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
BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
Hi, I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a USB webcam. See below: eeepc kernel: [ 1263.874756] cheese[3402]: segfault at 58 ip 080630b6 sp afc2c840 error 4 in cheese[8048000+24000] eeepc kernel: [ 1393.419370] uvcvideo: Non-zero status (-84) in status completion handler. eeepc kernel: [ 1393.500719] usb 3-2: USB disconnect, device number 4 eeepc kernel: [ 1393.504351] uvcvideo: Failed to resubmit video URB (-19). eeepc kernel: [ 1495.428853] BUG: unable to handle kernel paging request at 6b6b6bcb eeepc kernel: [ 1495.429017] IP: [] dev_get_drvdata+0x17/0x20 eeepc kernel: [ 1495.429017] *pde = eeepc kernel: [ 1495.429017] Oops: [#1] DEBUG_PAGEALLOC eeepc kernel: [ 1495.429017] eeepc kernel: [ 1495.429017] Pid: 3476, comm: cheese Not tainted 3.1.0-rc3-00270-g7a54f5e-dirty #485 ASUSTeK Computer INC. 900/900 eeepc kernel: [ 1495.429017] EIP: 0060:[] EFLAGS: 00010202 CPU: 0 eeepc kernel: [ 1495.429017] EIP is at dev_get_drvdata+0x17/0x20 eeepc kernel: [ 1495.429017] EAX: 6b6b6b6b EBX: eb08d870 ECX: EDX: eb08d930 eeepc kernel: [ 1495.429017] ESI: eb08d870 EDI: eb08d870 EBP: d3249cac ESP: d3249cac eeepc kernel: [ 1495.429017] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 eeepc kernel: [ 1495.429017] Process cheese (pid: 3476, ti=d3248000 task=df46d870 task.ti=d3248000) eeepc kernel: [ 1495.429017] Stack: eeepc kernel: [ 1495.429017] d3249cb8 b03e77a1 d307b840 d3249ccc b03e77d1 d307b840 eb08d870 eb08d830 eeepc kernel: [ 1495.429017] d3249ce4 b03ed3b7 0246 d307b840 eb08d870 d3021b80 d3249cec b03ed565 eeepc kernel: [ 1495.429017] d3249cfc b03e044d e8323d10 b06e013c d3249d18 b0355fb9 fffe d3249d1c eeepc kernel: [ 1495.429017] Call Trace: eeepc kernel: [ 1495.429017] [] v4l2_device_disconnect+0x11/0x30 eeepc kernel: [ 1495.429017] [] v4l2_device_unregister+0x11/0x50 eeepc kernel: [ 1495.429017] [] uvc_delete+0x37/0x110 eeepc kernel: [ 1495.429017] [] uvc_release+0x25/0x30 eeepc kernel: [ 1495.429017] [] v4l2_device_release+0x9d/0xc0 eeepc kernel: [ 1495.429017] [] device_release+0x19/0x90 eeepc kernel: [ 1495.429017] [] ? usb_hcd_unlink_urb+0x7c/0x90 eeepc kernel: [ 1495.429017] [] kobject_release+0x3c/0x90 eeepc kernel: [ 1495.429017] [] ? kobject_del+0x30/0x30 eeepc kernel: [ 1495.429017] [] kref_put+0x2c/0x60 eeepc kernel: [ 1495.429017] [] kobject_put+0x1d/0x50 eeepc kernel: [ 1495.429017] [] ? usb_autopm_put_interface+0x25/0x30 eeepc kernel: [ 1495.429017] [] ? uvc_v4l2_release+0x5d/0xd0 eeepc kernel: [ 1495.429017] [] put_device+0xf/0x20 eeepc kernel: [ 1495.429017] [] v4l2_release+0x56/0x60 eeepc kernel: [ 1495.429017] [] fput+0xcc/0x220 eeepc kernel: [ 1495.429017] [] filp_close+0x44/0x70 eeepc kernel: [ 1495.429017] [] put_files_struct+0x158/0x180 eeepc kernel: [ 1495.429017] [] ? put_files_struct+0x20/0x180 eeepc kernel: [ 1495.429017] [] exit_files+0x40/0x50 eeepc kernel: [ 1495.429017] [] do_exit+0x5a7/0x660 eeepc kernel: [ 1495.429017] [] ? __dequeue_signal+0x12/0x120 eeepc kernel: [ 1495.429017] [] ? _raw_spin_unlock_irq+0x22/0x30 eeepc kernel: [ 1495.429017] [] do_group_exit+0x3c/0xb0 eeepc kernel: [ 1495.429017] [] ? trace_hardirqs_on+0xb/0x10 eeepc kernel: [ 1495.429017] [] get_signal_to_deliver+0x18f/0x570 eeepc kernel: [ 1495.429017] [] do_signal+0x47/0x9e0 eeepc kernel: [ 1495.429017] [] ? _raw_spin_unlock_irq+0x22/0x30 eeepc kernel: [ 1495.429017] [] ? trace_hardirqs_on+0xb/0x10 eeepc kernel: [ 1495.429017] [] ? T.1034+0x30/0xc0 eeepc kernel: [ 1495.429017] [] ? schedule+0x29f/0x640 eeepc kernel: [ 1495.429017] [] do_notify_resume+0x38/0x40 eeepc kernel: [ 1495.429017] [] work_notifysig+0x9/0x11 eeepc kernel: [ 1495.429017] Code: e5 5d 83 f8 01 19 c0 f7 d0 83 e0 f0 c3 8d b4 26 00 00 00 00 55 85 c0 89 e5 75 09 31 c0 5d c3 90 8d 74 26 00 8b 40 04 85 c0 74 f0 <8b> 40 60 5d c3 8d 74 26 00 55 89 e5 53 89 c3 83 ec 04 8b 40 04 eeepc kernel: [ 1495.429017] EIP: [] dev_get_drvdata+0x17/0x20 SS:ESP 0068:d3249cac eeepc kernel: [ 1495.429017] CR2: 6b6b6bcb eeepc kernel: [ 1495.466975] uvcvideo: Failed to resubmit video URB (-27). eeepc kernel: [ 1495.467860] uvcvideo: Failed to resubmit video URB (-27). eeepc kernel: last message repeated 3 times eeepc kernel: [ 1495.512610] ---[ end trace 73ec16848794e5a5 ]--- eeepc kernel: [ 1495.512620] Fixing recursive fault but reboot is needed! -- Sitsofe | http://sucs.org/~sits/ -- 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
[V4L2]decrement struct v4l2_device refcount on device urnegister
commit bedf8bcf6b4f90a6e31add3721a2e71877289381 introduced reference counting for struct v4l2_device. In v4l2_device_register() a call to kref_init() initializes reference count to 1, but in v4l2_device_unregister() there is no corresponding decrement. End result is that reference count never reaches zero and v4l2_device_release() is never called, not even on videodev module unload. Fix this by adding reference counter decrement to v4l2_device_unregister(). Signed-off-by: Maciej Szmigiero diff --git a/drivers/media/video/v4l2-device.c b/drivers/media/video/v4l2-device.c index c72856c..eb39af9 100644 --- a/drivers/media/video/v4l2-device.c +++ b/drivers/media/video/v4l2-device.c @@ -131,6 +131,8 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev) } #endif } + +v4l2_device_put(v4l2_dev); } EXPORT_SYMBOL_GPL(v4l2_device_unregister); -- 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] mfd: Combine MFD_SUPPORT and MFD_CORE
On Mon, Aug 29, 2011 at 12:41 PM, Luciano Coelho wrote: > From: Randy Dunlap > > Combine MFD_SUPPORT (which only enabled the remainder of the MFD > menu) and MFD_CORE. This allows other drivers to select MFD_CORE > without needing to also select MFD_SUPPORT, which fixes some > kconfig unmet dependency warnings. Modeled after I2C kconfig. > > [Forward-ported to 3.1-rc4. This fixes a warning when some drivers, > such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca] > > Signed-off-by: Randy Dunlap > Reported-by: Johannes Berg > Cc: Jean Delvare > Cc: Tony Lindgren > Cc: Grant Likely > Signed-off-by: Luciano Coelho okay by me. g. > --- > > I guess this should fix the problem. I've simple forward-ported > Randy's patch to the latest mainline kernel. I don't know via which > tree this should go in, though. > > NOTE: I have *not* tested this very thoroughly. But at least > omap2plus stuff seems to work okay with this change. MFD_SUPPORT is > also selected by a couple of "tile" platforms defconfigs, but I guess > the Kconfig system should take care of it. > > arch/arm/mach-omap2/Kconfig | 2 +- > drivers/gpio/Kconfig | 3 +- > drivers/mfd/Kconfig | 54 +++--- > 3 files changed, 6 insertions(+), 53 deletions(-) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 57b66d5..1046923 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -14,7 +14,7 @@ config ARCH_OMAP2PLUS_TYPICAL > select SERIAL_OMAP_CONSOLE > select I2C > select I2C_OMAP > - select MFD_SUPPORT > + select MFD_CORE > select MENELAUS if ARCH_OMAP2 > select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 > select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig > index d539efd..fbc5fd4 100644 > --- a/drivers/gpio/Kconfig > +++ b/drivers/gpio/Kconfig > @@ -180,7 +180,7 @@ config GPIO_SCH > > config GPIO_VX855 > tristate "VIA VX855/VX875 GPIO" > - depends on MFD_SUPPORT && PCI > + depends on PCI > select MFD_CORE > select MFD_VX855 > help > @@ -417,7 +417,6 @@ config GPIO_TIMBERDALE > config GPIO_RDC321X > tristate "RDC R-321x GPIO support" > depends on PCI > - select MFD_SUPPORT > select MFD_CORE > select MFD_RDC321X > help > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > index 21574bd..1836cdf 100644 > --- a/drivers/mfd/Kconfig > +++ b/drivers/mfd/Kconfig > @@ -2,10 +2,9 @@ > # Multifunction miscellaneous devices > # > > -menuconfig MFD_SUPPORT > - bool "Multifunction device drivers" > +menuconfig MFD_CORE > + tristate "Multifunction device drivers" > depends on HAS_IOMEM > - default y > help > Multifunction devices embed several functions (e.g. GPIOs, > touchscreens, keyboards, current regulators, power management chips, > @@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT > > This option alone does not add any kernel code. > > -if MFD_SUPPORT > - > -config MFD_CORE > - tristate > - default n > +if MFD_CORE > > config MFD_88PM860X > bool "Support Marvell 88PM8606/88PM8607" > depends on I2C=y && GENERIC_HARDIRQS > - select MFD_CORE > help > This supports for Marvell 88PM8606/88PM8607 Power Management IC. > This includes the I2C driver and the core APIs _only_, you have to > @@ -55,14 +49,12 @@ config MFD_SM501_GPIO > config MFD_ASIC3 > bool "Support for Compaq ASIC3" > depends on GENERIC_HARDIRQS && GPIOLIB && ARM > - select MFD_CORE > ---help--- > This driver supports the ASIC3 multifunction chip found on many > PDAs (mainly iPAQ and HTC based ones) > > config MFD_DAVINCI_VOICECODEC > tristate > - select MFD_CORE > > config MFD_DM355EVM_MSP > bool "DaVinci DM355 EVM microcontroller" > @@ -75,7 +67,6 @@ config MFD_DM355EVM_MSP > config MFD_TI_SSP > tristate "TI Sequencer Serial Port support" > depends on ARCH_DAVINCI_TNETV107X > - select MFD_CORE > ---help--- > Say Y here if you want support for the Sequencer Serial Port > in a Texas Instruments TNETV107X SoC. > @@ -93,7 +84,6 @@ config HTC_EGPIO > > config HTC_PASIC3 > tristate "HTC PASIC3 LED/DS1WM chip support" > - select MFD_CORE > help > This core driver provides register access for the LED/DS1WM > chips labeled "AIC2" and "AIC3", found on HTC Blueangel and > @@ -124,7 +114,6 @@ config TPS6105X > tristate "TPS61050/61052 Boost Converters" > depends on I2C > select REGULATOR > - select MFD_CORE > select REGULATOR_FIXED_VOLTAGE > help > This option enables a driver for the TP61050/TPS61052 > @@ -147,7 +136,6 @@ config TPS65010 > > config TPS6507X >
[PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE
From: Randy Dunlap Combine MFD_SUPPORT (which only enabled the remainder of the MFD menu) and MFD_CORE. This allows other drivers to select MFD_CORE without needing to also select MFD_SUPPORT, which fixes some kconfig unmet dependency warnings. Modeled after I2C kconfig. [Forward-ported to 3.1-rc4. This fixes a warning when some drivers, such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca] Signed-off-by: Randy Dunlap Reported-by: Johannes Berg Cc: Jean Delvare Cc: Tony Lindgren Cc: Grant Likely Signed-off-by: Luciano Coelho --- I guess this should fix the problem. I've simple forward-ported Randy's patch to the latest mainline kernel. I don't know via which tree this should go in, though. NOTE: I have *not* tested this very thoroughly. But at least omap2plus stuff seems to work okay with this change. MFD_SUPPORT is also selected by a couple of "tile" platforms defconfigs, but I guess the Kconfig system should take care of it. arch/arm/mach-omap2/Kconfig |2 +- drivers/gpio/Kconfig|3 +- drivers/mfd/Kconfig | 54 +++--- 3 files changed, 6 insertions(+), 53 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 57b66d5..1046923 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -14,7 +14,7 @@ config ARCH_OMAP2PLUS_TYPICAL select SERIAL_OMAP_CONSOLE select I2C select I2C_OMAP - select MFD_SUPPORT + select MFD_CORE select MENELAUS if ARCH_OMAP2 select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index d539efd..fbc5fd4 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -180,7 +180,7 @@ config GPIO_SCH config GPIO_VX855 tristate "VIA VX855/VX875 GPIO" - depends on MFD_SUPPORT && PCI + depends on PCI select MFD_CORE select MFD_VX855 help @@ -417,7 +417,6 @@ config GPIO_TIMBERDALE config GPIO_RDC321X tristate "RDC R-321x GPIO support" depends on PCI - select MFD_SUPPORT select MFD_CORE select MFD_RDC321X help diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..1836cdf 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -2,10 +2,9 @@ # Multifunction miscellaneous devices # -menuconfig MFD_SUPPORT - bool "Multifunction device drivers" +menuconfig MFD_CORE + tristate "Multifunction device drivers" depends on HAS_IOMEM - default y help Multifunction devices embed several functions (e.g. GPIOs, touchscreens, keyboards, current regulators, power management chips, @@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT This option alone does not add any kernel code. -if MFD_SUPPORT - -config MFD_CORE - tristate - default n +if MFD_CORE config MFD_88PM860X bool "Support Marvell 88PM8606/88PM8607" depends on I2C=y && GENERIC_HARDIRQS - select MFD_CORE help This supports for Marvell 88PM8606/88PM8607 Power Management IC. This includes the I2C driver and the core APIs _only_, you have to @@ -55,14 +49,12 @@ config MFD_SM501_GPIO config MFD_ASIC3 bool "Support for Compaq ASIC3" depends on GENERIC_HARDIRQS && GPIOLIB && ARM - select MFD_CORE ---help--- This driver supports the ASIC3 multifunction chip found on many PDAs (mainly iPAQ and HTC based ones) config MFD_DAVINCI_VOICECODEC tristate - select MFD_CORE config MFD_DM355EVM_MSP bool "DaVinci DM355 EVM microcontroller" @@ -75,7 +67,6 @@ config MFD_DM355EVM_MSP config MFD_TI_SSP tristate "TI Sequencer Serial Port support" depends on ARCH_DAVINCI_TNETV107X - select MFD_CORE ---help--- Say Y here if you want support for the Sequencer Serial Port in a Texas Instruments TNETV107X SoC. @@ -93,7 +84,6 @@ config HTC_EGPIO config HTC_PASIC3 tristate "HTC PASIC3 LED/DS1WM chip support" - select MFD_CORE help This core driver provides register access for the LED/DS1WM chips labeled "AIC2" and "AIC3", found on HTC Blueangel and @@ -124,7 +114,6 @@ config TPS6105X tristate "TPS61050/61052 Boost Converters" depends on I2C select REGULATOR - select MFD_CORE select REGULATOR_FIXED_VOLTAGE help This option enables a driver for the TP61050/TPS61052 @@ -147,7 +136,6 @@ config TPS65010 config TPS6507X tristate "TPS6507x Power Management / Touch Screen chips" - select MFD_CORE depends on I2C help If you say yes here you get support for the TPS6507x series of @@ -160,7 +148,6 @@ config TPS6507X config MFD_TPS6586X bool "TPS6586x Power Management
Re: Afatech AF9013
2011/8/23 Jason Hecker : > Damn, this patch didn't help so maybe forget this patch. Tuner A is > still messed up. > Hello, thanks all to reply this post. I have no idea how to apply the patch on my Debian Squeeze. Can you help to apply the patch? Thanks your all your help. Best regards. -- 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: usb_set_intfdata usage for two subdrivers
Am Montag, 29. August 2011, 05:54:36 schrieb Antti Palosaari: > On 08/29/2011 03:36 AM, Greg KH wrote: > > On Mon, Aug 29, 2011 at 02:30:26AM +0300, Antti Palosaari wrote: > >> I am trying to implement DVB USB device smartcard reader support > >> using USB-serial. > > > > Really? Why? That doesn't seem to make sense, please explain more. > > Since it is old style serial smartcard reader, not CCID PC/SC as new > readers. I see it a little bit overkill to register virtual HCI and > virtual CCID device though it sounds interesting. > > There is already one such similar driver, iuu_phoenix, but without DVB > support ;) Consider situation I have iuu_phoenix integrated to USB DVB > device. Both using same USB enpoint, sharing hardware resources of > communication. Look at struct dvb_usb_device. It has a struct input_dev embedded. I suggest you also add a serial device for smart cards. HTH Oliver -- 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
Beloved
Beloved,I am Deborah Mannings.I write this email to you on my sick bed facing death.I have a substantial sum I would like you to help me distribute to the needy and helpless.God bless you as you reply through mann_...@yahoo.cn -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.2] [media] Fix wrong register mask in gspca/sonixj.c
On Mon, 29 Aug 2011 09:57:26 -0700 (PDT) Luiz Ramos wrote: > Mauro: > > To be fair, this patch itself isn't sufficient to solve the problem described > in the text provided. One other patch is necessary to get this goal > accomplished, named, one published in this same thread in 2011-07-18. > > This later fix is now embedded in a wider patch provided by Jean-François > Moine in 2011-08-10. > > I'd suggest to change the text below, if possible, mentioning only something > like "fix wrong register masking". Hi Mauro, Sorry, I did not notice the automatic commit report. I submitted Luiz's patch and the darkness fix in 2 git patch requests on Wed, 10 Aug for 3.1 and on Fri, 12 Aug for 3.2: gspca - sonixj: Fix wrong register mask for sensor om6802 gspca - sonixj: Fix the darkness of sensor om6802 in 320x240 Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dmaengine: ipu-idmac: add support for the DMA_PAUSE control
On Mon, 29 Aug 2011, Vinod Koul wrote:
> On Thu, 2011-08-25 at 18:45 +0200, Guennadi Liakhovetski wrote:
> > To support multi-size buffers in the mx3_camera V4L2 driver we have to be
> > able to stop DMA on a channel without releasing descriptors and completely
> > halting the hardware. Use the DMA_PAUSE control to implement this mode.
> >
> > Signed-off-by: Guennadi Liakhovetski
> Acked-by Vinod Koul
>
> Do you want this to go thru slave-dma or media tree?
With your above ack I can pull it together with the final form of patch
2/2, when it's ready, via media tree.
Thanks
Guennadi
>
> --
> ~Vinod
> > ---
> > drivers/dma/ipu/ipu_idmac.c | 65
> > +++---
> > 1 files changed, 42 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
> > index c1a125e..42cdf1c 100644
> > --- a/drivers/dma/ipu/ipu_idmac.c
> > +++ b/drivers/dma/ipu/ipu_idmac.c
> > @@ -1306,6 +1306,7 @@ static irqreturn_t idmac_interrupt(int irq, void
> > *dev_id)
> > ipu_submit_buffer(ichan, descnew, sgnew, ichan->active_buffer) < 0)
> > {
> > callback = descnew->txd.callback;
> > callback_param = descnew->txd.callback_param;
> > + list_del_init(&descnew->list);
> > spin_unlock(&ichan->lock);
> > if (callback)
> > callback(callback_param);
> > @@ -1427,39 +1428,58 @@ static int __idmac_control(struct dma_chan *chan,
> > enum dma_ctrl_cmd cmd,
> > {
> > struct idmac_channel *ichan = to_idmac_chan(chan);
> > struct idmac *idmac = to_idmac(chan->device);
> > + struct ipu *ipu = to_ipu(idmac);
> > + struct list_head *list, *tmp;
> > unsigned long flags;
> > int i;
> >
> > - /* Only supports DMA_TERMINATE_ALL */
> > - if (cmd != DMA_TERMINATE_ALL)
> > - return -ENXIO;
> > + switch (cmd) {
> > + case DMA_PAUSE:
> > + spin_lock_irqsave(&ipu->lock, flags);
> > + ipu_ic_disable_task(ipu, chan->chan_id);
> >
> > - ipu_disable_channel(idmac, ichan,
> > - ichan->status >= IPU_CHANNEL_ENABLED);
> > + /* Return all descriptors into "prepared" state */
> > + list_for_each_safe(list, tmp, &ichan->queue)
> > + list_del_init(list);
> >
> > - tasklet_disable(&to_ipu(idmac)->tasklet);
> > + ichan->sg[0] = NULL;
> > + ichan->sg[1] = NULL;
> >
> > - /* ichan->queue is modified in ISR, have to spinlock */
> > - spin_lock_irqsave(&ichan->lock, flags);
> > - list_splice_init(&ichan->queue, &ichan->free_list);
> > + spin_unlock_irqrestore(&ipu->lock, flags);
> >
> > - if (ichan->desc)
> > - for (i = 0; i < ichan->n_tx_desc; i++) {
> > - struct idmac_tx_desc *desc = ichan->desc + i;
> > - if (list_empty(&desc->list))
> > - /* Descriptor was prepared, but not submitted */
> > - list_add(&desc->list, &ichan->free_list);
> > + ichan->status = IPU_CHANNEL_INITIALIZED;
> > + break;
> > + case DMA_TERMINATE_ALL:
> > + ipu_disable_channel(idmac, ichan,
> > + ichan->status >= IPU_CHANNEL_ENABLED);
> >
> > - async_tx_clear_ack(&desc->txd);
> > - }
> > + tasklet_disable(&ipu->tasklet);
> >
> > - ichan->sg[0] = NULL;
> > - ichan->sg[1] = NULL;
> > - spin_unlock_irqrestore(&ichan->lock, flags);
> > + /* ichan->queue is modified in ISR, have to spinlock */
> > + spin_lock_irqsave(&ichan->lock, flags);
> > + list_splice_init(&ichan->queue, &ichan->free_list);
> >
> > - tasklet_enable(&to_ipu(idmac)->tasklet);
> > + if (ichan->desc)
> > + for (i = 0; i < ichan->n_tx_desc; i++) {
> > + struct idmac_tx_desc *desc = ichan->desc + i;
> > + if (list_empty(&desc->list))
> > + /* Descriptor was prepared, but not
> > submitted */
> > + list_add(&desc->list,
> > &ichan->free_list);
> >
> > - ichan->status = IPU_CHANNEL_INITIALIZED;
> > + async_tx_clear_ack(&desc->txd);
> > + }
> > +
> > + ichan->sg[0] = NULL;
> > + ichan->sg[1] = NULL;
> > + spin_unlock_irqrestore(&ichan->lock, flags);
> > +
> > + tasklet_enable(&ipu->tasklet);
> > +
> > + ichan->status = IPU_CHANNEL_INITIALIZED;
> > + break;
> > + default:
> > + return -ENOSYS;
> > + }
> >
> > return 0;
> > }
> > @@ -1662,7 +1682,6 @@ static void __exit ipu_idmac_exit(struct ipu *ipu)
> > struct idmac_channel *ichan = ipu->channel + i;
> >
> > idmac_control(&ichan->dma_chan, DMA_TERMINATE_ALL, 0);
> > - idmac_prep_slave_sg(&ichan->dma_ch
[PATCH/WIP] tvp5150: add v4l2 subdev pad ops
Hi,
attached is a patch (i tested it with kernel 3.1rc3 but applies to
2.6.39 and 3.0 too) that makes the driver register with omap3-isp.
Copied mostly from mt9v032.c.
/dev/video* and v4l-subdev* are registered correctly.
Video capture is still NOT working but i think i'm close to make it
work so some help is welcome!
I'm testing it on an IGEP board with tvp5151 on expansion board.
Issues i see:
root@igep0020:~# ./media-ctl2 --set-format '"tvp5150 2-005c":0 [UYVY 720x628]'
Setting up format UYVY 720x628 on pad tvp5150 2-005c/0
Format set: UYVY 720x628
Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0
Format set: SGRBG10 720x628
and
root@igep0020:~# gst-launch -ve v4l2src device=/dev/video2
queue-size=1 num-buffers=250 ! fakesink
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
getting controls attributes on device '/dev/video2'.
Additional debug info:
v4l2_calls.c(267): gst_v4l2_fill_lists ():
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Failed querying control 9963776 on device '/dev/video2'. (25 -
Inappropriate ioctl for device)
Setting pipeline to NULL ...
Freeing pipeline ...
Maybe the gstreamer issue could be caused by not being compiled with
the proper kernel headers.
media-ctl is compiled from latest ideasonboard git repo, i admit i am
not that sure that i compiled it with correct kernel headers. I don't
know why but every format i try to set on CCDC is always set to
SGRBG10.
I'm not sure that some parameters are correct (like V4L2_FILED_NONE,
colorspace, pixel format...), so i need someone to take a look. Are
the subdev_internal_ops (registered, open, close) needed?
I know the patch is not properly formatted for submission, i'll do
that when capture will work.
Thanks,
Enrico
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index e927d25..bf34e11 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -2,6 +2,7 @@
* tvp5150 - Texas Instruments TVP5150A/AM1 video decoder driver
*
* Copyright (c) 2005,2006 Mauro Carvalho Chehab (mche...@infradead.org)
+ * Copyright (c) 2011 Enrico Butera (ebut...@users.berlios.de)
* This code is placed under the terms of the GNU General Public License v2
*/
@@ -13,9 +14,30 @@
#include
#include
#include
+#include
+#include
#include "tvp5150_reg.h"
+#define TVP5150_PIXEL_ARRAY_HEIGHT 628
+#define TVP5150_PIXEL_ARRAY_WIDTH 720
+
+#define TVP5150_WINDOW_WIDTH_MIN 1
+#define TVP5150_WINDOW_WIDTH_DEF 720
+#define TVP5150_WINDOW_WIDTH_MAX 720
+
+#define TVP5150_WINDOW_HEIGHT_MIN 1
+#define TVP5150_WINDOW_HEIGHT_DEF 628
+#define TVP5150_WINDOW_HEIGHT_MAX 628
+
+#define TVP5150_COLUMN_START_MIN 0
+#define TVP5150_COLUMN_START_DEF 0
+#define TVP5150_COLUMN_START_MAX 720
+
+#define TVP5150_ROW_START_MIN 0
+#define TVP5150_ROW_START_DEF 0
+#define TVP5150_ROW_START_MAX 628
+
MODULE_DESCRIPTION("Texas Instruments TVP5150A video decoder driver");
MODULE_AUTHOR("Mauro Carvalho Chehab");
MODULE_LICENSE("GPL");
@@ -28,6 +50,9 @@ MODULE_PARM_DESC(debug, "Debug level (0-2)");
struct tvp5150 {
struct v4l2_subdev sd;
struct v4l2_ctrl_handler hdl;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+ struct v4l2_rect crop;
v4l2_std_id norm; /* Current set standard */
u32 input;
@@ -779,6 +804,203 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
}
/
+ V4L2 subdev pad ops
+ /
+
+static struct v4l2_mbus_framefmt *
+__tvp5150_get_pad_format(struct tvp5150 *tvp5150, struct v4l2_subdev_fh *fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+switch (which) {
+case V4L2_SUBDEV_FORMAT_TRY:
+return v4l2_subdev_get_try_format(fh, pad);
+case V4L2_SUBDEV_FORMAT_ACTIVE:
+return &tvp5150->format;
+default:
+return NULL;
+}
+}
+
+static struct v4l2_rect *
+__tvp5150_get_pad_crop(struct tvp5150 *tvp5150, struct v4l2_subdev_fh *fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+switch (which) {
+case V4L2_SUBDEV_FORMAT_TRY:
+return v4l2_subdev_get_try_crop(fh, pad);
+case V4L2_SUBDEV_FORMAT_ACTIVE:
+return &tvp5150->crop;
+default:
+return NULL;
+}
+}
+
+static int tvp5150_enum_mbus_code(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+if (code->index > 0)
+return -EINVAL;
+
+code->code = V4L2_MBUS_FMT_UYVY8_1X16;
+return 0;
+}
+
+static int tvp5150_enum_frame_size(struct v4l2_subdev *subdev,
+ struct
Re: Kconfig unmet dependency with RADIO_WL1273
On Mon, 29 Aug 2011 20:02:38 +0300 Luciano Coelho wrote: > Hi Matti, > > Johannes has just reported a problem in the Kconfig of radio-wl1273. It > seems to select MFD_CORE, but if the platform doesn't support MFD, then > MFD_SUPPORT won't be selected and this kind of warning will come out: > > warning: (OLPC_XO1_PM && OLPC_XO1_SCI && I2C_ISCH && GPIO_SCH && GPIO_RDC321X > && RADIO_WL1273) > selects MFD_CORE which has unmet direct dependencies > (MFD_SUPPORT) > > I guess it must depend on MFD_SUPPORT, right? If that's the correct > solution, the following patch should fix the problem: > > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig > index 52798a1..e87f544 100644 > --- a/drivers/media/radio/Kconfig > +++ b/drivers/media/radio/Kconfig > @@ -425,7 +425,7 @@ config RADIO_TIMBERDALE > > config RADIO_WL1273 > tristate "Texas Instruments WL1273 I2C FM Radio" > - depends on I2C && VIDEO_V4L2 > + depends on I2C && VIDEO_V4L2 && MFD_SUPPORT > select MFD_CORE > select MFD_WL1273_CORE > select FW_LOADER > > The same problem is happening with other drivers too, so maybe there is > a better solution to fix all problems at once. ;) > > Reported-by: Johannes Berg Yes, it can depend on MFD_SUPPORT or it can select both MFD_SUPPORT and MFD_CORE or we could do what Jean Delvare suggested last December and combine the MFD_SUPPORT and MFD_CORE symbols, like I2c does. I did a patch for that but never posted it. It's below, but probably needs a good bit of updating since this patch was made in January. --- From: Randy Dunlap Combine MFD_SUPPORT (which only enabled the remainder of the MFD menu) and MFD_CORE. This allows other drivers to select MFD_CORE without needing to also select MFD_SUPPORT, which fixes some kconfig unmet dependency warnings. Modeled after I2C kconfig. Signed-off-by: Randy Dunlap --- drivers/mfd/Kconfig | 42 -- 1 file changed, 4 insertions(+), 38 deletions(-) --- lnx-2637-rc5.orig/drivers/mfd/Kconfig +++ lnx-2637-rc5/drivers/mfd/Kconfig @@ -2,10 +2,9 @@ # Multifunction miscellaneous devices # -menuconfig MFD_SUPPORT - bool "Multifunction device drivers" +menuconfig MFD_CORE + tristate "Multifunction device drivers" depends on HAS_IOMEM - default y help Multifunction devices embed several functions (e.g. GPIOs, touchscreens, keyboards, current regulators, power management chips, @@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT This option alone does not add any kernel code. -if MFD_SUPPORT - -config MFD_CORE - tristate - default n +if MFD_CORE config MFD_88PM860X bool "Support Marvell 88PM8606/88PM8607" depends on I2C=y && GENERIC_HARDIRQS - select MFD_CORE help This supports for Marvell 88PM8606/88PM8607 Power Management IC. This includes the I2C driver and the core APIs _only_, you have to @@ -55,7 +49,6 @@ config MFD_SM501_GPIO config MFD_ASIC3 bool "Support for Compaq ASIC3" depends on GENERIC_HARDIRQS && GPIOLIB && ARM - select MFD_CORE ---help--- This driver supports the ASIC3 multifunction chip found on many PDAs (mainly iPAQ and HTC based ones) @@ -63,7 +56,6 @@ config MFD_ASIC3 config MFD_SH_MOBILE_SDHI bool "Support for SuperH Mobile SDHI" depends on SUPERH || ARCH_SHMOBILE - select MFD_CORE select TMIO_MMC_DMA ---help--- This driver supports the SDHI hardware block found in many @@ -71,7 +63,6 @@ config MFD_SH_MOBILE_SDHI config MFD_DAVINCI_VOICECODEC tristate - select MFD_CORE config MFD_DM355EVM_MSP bool "DaVinci DM355 EVM microcontroller" @@ -91,7 +82,6 @@ config HTC_EGPIO config HTC_PASIC3 tristate "HTC PASIC3 LED/DS1WM chip support" - select MFD_CORE help This core driver provides register access for the LED/DS1WM chips labeled "AIC2" and "AIC3", found on HTC Blueangel and @@ -133,7 +123,6 @@ config TPS65010 config TPS6507X tristate "TPS6507x Power Management / Touch Screen chips" - select MFD_CORE depends on I2C help If you say yes here you get support for the TPS6507x series of @@ -183,7 +172,6 @@ config TWL4030_POWER config TWL4030_CODEC bool depends on TWL4030_CORE - select MFD_CORE default n config TWL6030_PWM @@ -198,7 +186,6 @@ config TWL6030_PWM config MFD_STMPE bool "Support STMicroelectronics STMPE" depends on I2C=y && GENERIC_HARDIRQS - select MFD_CORE help Support for the STMPE family of I/O Expanders from STMicroelectronics. @@ -221,7 +208,6 @@ config MFD_STMPE config MFD_TC35892 bool "Support Toshiba TC35892" depends on I2C=y && GENERIC_HARDIRQS - select MFD_CORE help
Re: DD Cine CT DVB-C/T
On 08/25/2011 06:47 PM, Thomas Kaiser wrote:
Hi
Which modules do I have to build and install to use this card (DD Cine
CT DVB-C/T Rev. V6).
I checkd out:
hg clone http://linuxtv.org/hg/~endriss/media_build_experimental
I would like to build only the needed modules. What do I have to
select in "make menuconfig"?
Regards, Thomas
--
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
Looks like I took the wrong source...
static const struct pci_device_id ddb_id_tbl[] __devinitdata = {
DDB_ID(DDVID, 0x0002, DDVID, 0x0001, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0001, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0002, ddb_octopus_le),
DDB_ID(DDVID, 0x0003, DDVID, 0x0010, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0020, ddb_v6),
/* in case sub-ids got deleted in flash */
DDB_ID(DDVID, 0x0003, PCI_ANY_ID, PCI_ANY_ID, ddb_none),
{0}
};
My card has the _subdev 0x0030!
Where can I find the right source code for this card?
I am ready to help developing and testing.
Thomas
--
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
Kconfig unmet dependency with RADIO_WL1273
Hi Matti, Johannes has just reported a problem in the Kconfig of radio-wl1273. It seems to select MFD_CORE, but if the platform doesn't support MFD, then MFD_SUPPORT won't be selected and this kind of warning will come out: warning: (OLPC_XO1_PM && OLPC_XO1_SCI && I2C_ISCH && GPIO_SCH && GPIO_RDC321X && RADIO_WL1273) selects MFD_CORE which has unmet direct dependencies (MFD_SUPPORT) I guess it must depend on MFD_SUPPORT, right? If that's the correct solution, the following patch should fix the problem: diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 52798a1..e87f544 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -425,7 +425,7 @@ config RADIO_TIMBERDALE config RADIO_WL1273 tristate "Texas Instruments WL1273 I2C FM Radio" - depends on I2C && VIDEO_V4L2 + depends on I2C && VIDEO_V4L2 && MFD_SUPPORT select MFD_CORE select MFD_WL1273_CORE select FW_LOADER The same problem is happening with other drivers too, so maybe there is a better solution to fix all problems at once. ;) Reported-by: Johannes Berg -- Cheers, Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.2] [media] Fix wrong register mask in gspca/sonixj.c
Mauro: To be fair, this patch itself isn't sufficient to solve the problem described in the text provided. One other patch is necessary to get this goal accomplished, named, one published in this same thread in 2011-07-18. This later fix is now embedded in a wider patch provided by Jean-François Moine in 2011-08-10. I'd suggest to change the text below, if possible, mentioning only something like "fix wrong register masking". Thanks, Luiz --- Em dom, 7/8/11, Mauro Carvalho Chehab escreveu: > De: Mauro Carvalho Chehab > Assunto: [git:v4l-dvb/for_v3.2] [media] Fix wrong register mask in > gspca/sonixj.c > Para: linuxtv-comm...@linuxtv.org > Cc: "Jean-François Moine" , "Luiz Carlos Ramos" > > Data: Domingo, 7 de Agosto de 2011, 9:03 > This is an automatic generated email > to let you know that the following patch were queued at the > > http://git.linuxtv.org/media_tree.git > tree: > > Subject: [media] Fix wrong register mask in gspca/sonixj.c > Author: Luiz Ramos > Date: Thu Jul 14 23:08:39 2011 -0300 > > Hello, > > When migrating from Slackware 13.1 to 13.37 (kernel > 2.6.33.x to > 2.6.37.6), there was some sort of regression with the > external webcam > installed at the notebook (0x45:6128, SN9C325+OM6802). > > In the version 2.6.37.6, the images got *very* dark, making > the webcam > almost unusable, unless if used with direct sunlight. > > Tracing back what happened, I concluded that changeset > 0e4d413af > caused some sort of odd effects - including this - to this > specific model. > > Signed-off-by: Luiz Carlos Ramos > Acked-by: Jean-François Moine > Signed-off-by: Mauro Carvalho Chehab > > drivers/media/video/gspca/sonixj.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > --- > > http://git.linuxtv.org/media_tree.git?a=commitdiff;h=d1520c58eb84ad1ec973a257cd835c948215aab5 > > diff --git a/drivers/media/video/gspca/sonixj.c > b/drivers/media/video/gspca/sonixj.c > index 81b8a60..2ad757d 100644 > --- a/drivers/media/video/gspca/sonixj.c > +++ b/drivers/media/video/gspca/sonixj.c > @@ -2386,7 +2386,7 @@ static int sd_start(struct gspca_dev > *gspca_dev) > reg_w1(gspca_dev, > 0x01, 0x22); > msleep(100); > reg01 = SCL_SEL_OD | > S_PDN_INV; > - reg17 &= > MCK_SIZE_MASK; > + reg17 &= > ~MCK_SIZE_MASK; > reg17 |= > 0x04; /* clock / 4 */ > break; > } > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi,
On 08/29/2011 02:32 PM, Laurent Pinchart wrote:
> Hi Geert,
>
> On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:
>>> On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
> On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy
way,
>>>
>>> Definitely.
>>>
- But what with modes that can be represented? Legacy software
cannot handle FB_{TYPE,VISUAL}_FOURCC.
>>>
>>> My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
>>> configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called
>>> with a non-FOURCC format, the driver will report non-FOURCC types
>>> and visuals.
>>
>> Hmm, two use cases:
>> - The video mode is configured using a FOURCC-aware tool ("fbset on
>> steroids").
>
> Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
Yep.
>> Later the user runs a legacy application.
>> => Do not retain FOURCC across opening of /dev/fb*.
>
> I know about that problem, but it's not that easy to work around. We
> have no per-open fixed and variable screen info, and FB devices can
> be opened by multiple applications at the same time.
>
>> - Is there an easy way to force FOURCC reporting, so new apps don't
>> have to support parsing the legacy formats? This is useful for new
>> apps that want to support (a subset of) FOURCC modes only.
>
> Not at the moment.
So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.
>>>
>>> Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls
>>> for the above two operations ?
>>
>> New ioctls to replace the FOURCC proposal.
>
> *sigh*...
>
> I'd like other people's opinion on this before throwing everything away.
> Florian, Magnus, Guennadi, others, what do you think ?
>
So, your issue is that some formats can be represented in the new and the old
way?
There are 2 simpler solutions I can think of:
(1) ignore it, just do it the way Laurent proposed. I understand that someone
might feel uneasy about applications that are trapped because they don't know
the new format but could work with the old one. But I think this is not a big
issue as many applications will just try to set their own mode. For those that
doesn't and rely on the previous mode that is set by fbset or similar, we could
change fbset to prefer the old format if available. But even if we don't do
this, I don't have a problem with a program failing because it sees an
unsuitable mode even if it supports the legacy mode. It's not a regression and
can be easily fixed in userspace.
(2) forbid it, just allow drivers to implement FOURCC for formats that cannot be
represented in the old scheme. This is my preferred solution if anyone has
problems with (1).
I don't see how IOCTLs would help here. The pixel format just belongs into var
and fix so it has to be represented there anyway and thus set through it. We
could do an IOCTL that always returns the FOURCC active at the moment, if such a
FOURCC exists, and always use the legacy API for representing it in var/fix, if
it exists. But as I see this is not what you thought about so please explain
what your IOCTLS would look like and how they would solve the problem.
And I don't think a in-kernel translation layer is a good idea. Yes, it sounds
interesting, but it's tricky and the result will be that the driver and
userspace will permanently see different var and fix structures. Seriously I
think changing every framebuffer driver out there would be easier and much saner
than trying to implement such a thing.
Best regards,
Florian Tobias Schandinat
--
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: Smart card reader support for Anysee DVB devices
On 08/29/2011 06:13 PM, István Váradi wrote: 2011/8/29 Antti Palosaari: On 08/29/2011 05:44 PM, István Váradi wrote: 2011/8/17 Antti Palosaari: On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Only De facto serial smartcard protocol is so called Phoenix/Smartmouse, implementing new protocol is totally dead idea. It will never got any support. There is already such drivers, at least Infinity Unlimited USB Phoenix driver (iuu_phoenix.c). It uses USB-serial driver framework and some small emulation for Phoenix protocol. Look that driver to see which kind of complexity it adds. Anysee have *just* same situation. Phoenix/Smartmouse and CCID are quite different aren't they? So to support Phoenix I would need provide a USB serial device which talks the protocol, but there would be no need for a virtual USB HCI. Is that correct? Yes, CCID and serial are different interfaces. CCID is new interface specified by USB organization that needs "hardware" level interface profile like mass storage profile. Serial is block device interface (/dev/tty). Since Anysee device itself does not have CCID interface it is needed to make virtual USB device in order to get CCID support. I have never seen virtual USB devices like that, but there is VHCI in current kernel staging that actually does something like that over IP. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dmaengine: ipu-idmac: add support for the DMA_PAUSE control
On Thu, 2011-08-25 at 18:45 +0200, Guennadi Liakhovetski wrote:
> To support multi-size buffers in the mx3_camera V4L2 driver we have to be
> able to stop DMA on a channel without releasing descriptors and completely
> halting the hardware. Use the DMA_PAUSE control to implement this mode.
>
> Signed-off-by: Guennadi Liakhovetski
Acked-by Vinod Koul
Do you want this to go thru slave-dma or media tree?
--
~Vinod
> ---
> drivers/dma/ipu/ipu_idmac.c | 65 +++---
> 1 files changed, 42 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
> index c1a125e..42cdf1c 100644
> --- a/drivers/dma/ipu/ipu_idmac.c
> +++ b/drivers/dma/ipu/ipu_idmac.c
> @@ -1306,6 +1306,7 @@ static irqreturn_t idmac_interrupt(int irq, void
> *dev_id)
> ipu_submit_buffer(ichan, descnew, sgnew, ichan->active_buffer) < 0)
> {
> callback = descnew->txd.callback;
> callback_param = descnew->txd.callback_param;
> + list_del_init(&descnew->list);
> spin_unlock(&ichan->lock);
> if (callback)
> callback(callback_param);
> @@ -1427,39 +1428,58 @@ static int __idmac_control(struct dma_chan *chan,
> enum dma_ctrl_cmd cmd,
> {
> struct idmac_channel *ichan = to_idmac_chan(chan);
> struct idmac *idmac = to_idmac(chan->device);
> + struct ipu *ipu = to_ipu(idmac);
> + struct list_head *list, *tmp;
> unsigned long flags;
> int i;
>
> - /* Only supports DMA_TERMINATE_ALL */
> - if (cmd != DMA_TERMINATE_ALL)
> - return -ENXIO;
> + switch (cmd) {
> + case DMA_PAUSE:
> + spin_lock_irqsave(&ipu->lock, flags);
> + ipu_ic_disable_task(ipu, chan->chan_id);
>
> - ipu_disable_channel(idmac, ichan,
> - ichan->status >= IPU_CHANNEL_ENABLED);
> + /* Return all descriptors into "prepared" state */
> + list_for_each_safe(list, tmp, &ichan->queue)
> + list_del_init(list);
>
> - tasklet_disable(&to_ipu(idmac)->tasklet);
> + ichan->sg[0] = NULL;
> + ichan->sg[1] = NULL;
>
> - /* ichan->queue is modified in ISR, have to spinlock */
> - spin_lock_irqsave(&ichan->lock, flags);
> - list_splice_init(&ichan->queue, &ichan->free_list);
> + spin_unlock_irqrestore(&ipu->lock, flags);
>
> - if (ichan->desc)
> - for (i = 0; i < ichan->n_tx_desc; i++) {
> - struct idmac_tx_desc *desc = ichan->desc + i;
> - if (list_empty(&desc->list))
> - /* Descriptor was prepared, but not submitted */
> - list_add(&desc->list, &ichan->free_list);
> + ichan->status = IPU_CHANNEL_INITIALIZED;
> + break;
> + case DMA_TERMINATE_ALL:
> + ipu_disable_channel(idmac, ichan,
> + ichan->status >= IPU_CHANNEL_ENABLED);
>
> - async_tx_clear_ack(&desc->txd);
> - }
> + tasklet_disable(&ipu->tasklet);
>
> - ichan->sg[0] = NULL;
> - ichan->sg[1] = NULL;
> - spin_unlock_irqrestore(&ichan->lock, flags);
> + /* ichan->queue is modified in ISR, have to spinlock */
> + spin_lock_irqsave(&ichan->lock, flags);
> + list_splice_init(&ichan->queue, &ichan->free_list);
>
> - tasklet_enable(&to_ipu(idmac)->tasklet);
> + if (ichan->desc)
> + for (i = 0; i < ichan->n_tx_desc; i++) {
> + struct idmac_tx_desc *desc = ichan->desc + i;
> + if (list_empty(&desc->list))
> + /* Descriptor was prepared, but not
> submitted */
> + list_add(&desc->list,
> &ichan->free_list);
>
> - ichan->status = IPU_CHANNEL_INITIALIZED;
> + async_tx_clear_ack(&desc->txd);
> + }
> +
> + ichan->sg[0] = NULL;
> + ichan->sg[1] = NULL;
> + spin_unlock_irqrestore(&ichan->lock, flags);
> +
> + tasklet_enable(&ipu->tasklet);
> +
> + ichan->status = IPU_CHANNEL_INITIALIZED;
> + break;
> + default:
> + return -ENOSYS;
> + }
>
> return 0;
> }
> @@ -1662,7 +1682,6 @@ static void __exit ipu_idmac_exit(struct ipu *ipu)
> struct idmac_channel *ichan = ipu->channel + i;
>
> idmac_control(&ichan->dma_chan, DMA_TERMINATE_ALL, 0);
> - idmac_prep_slave_sg(&ichan->dma_chan, NULL, 0, DMA_NONE, 0);
> }
>
> dma_async_device_unregister(&idmac->dma);
--
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
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Please treat the patches as RFC. Thx, -manju On Mon, Aug 29, 2011 at 20:37:11, Hadli, Manjunath wrote: > changes from last patch set: > 1. Made changes based on Sakari's feedback mainly: > a. returned early to allow unindenting > b. reformatting to shift the code to left where possible > c. changed hex numbers to lower case > d. corrected the defines according to module names. > e. magic numbers removed. > f. changed non-integer returning functions to void > g. removed unwanted paranthses. > h. fixed error codes. > i. fixed some RESET_BIt code to what it was intended for. > 2. reorganized the header files to move the kernel-only headers along with > the c files and interface headers in the include folder. > > Manjunath Hadli (6): > davinci: vpfe: add dm3xx IPIPEIF hardware support module > davinci: vpfe: add support for CCDC hardware for dm365 > davinci: vpfe: add ccdc driver with media controller interface > davinci: vpfe: add v4l2 video driver support > davinci: vpfe: v4l2 capture driver with media interface > davinci: vpfe: build infrastructure for dm365 > > Nagabhushana Netagunte (2): > davinci: vpfe: add IPIPE hardware layer support > davinci: vpfe: add IPIPE support for media controller driver > > drivers/media/video/davinci/Kconfig | 46 +- > drivers/media/video/davinci/Makefile | 17 +- > drivers/media/video/davinci/ccdc_hw_device.h | 10 +- > drivers/media/video/davinci/ccdc_types.h | 43 + > drivers/media/video/davinci/dm365_ccdc.c | 1519 ++ > drivers/media/video/davinci/dm365_ccdc.h | 88 + > drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ > drivers/media/video/davinci/dm365_def_para.c | 486 +++ > drivers/media/video/davinci/dm365_def_para.h | 39 + > drivers/media/video/davinci/dm365_ipipe.c | 3966 > + > drivers/media/video/davinci/dm365_ipipe.h | 300 ++ > drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++ > drivers/media/video/davinci/dm365_ipipe_hw.h | 539 > drivers/media/video/davinci/dm3xx_ipipeif.c | 317 ++ > drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++ > drivers/media/video/davinci/imp_common.h | 85 + > drivers/media/video/davinci/imp_hw_if.h | 178 ++ > drivers/media/video/davinci/vpfe_capture.c| 793 + > drivers/media/video/davinci/vpfe_capture.h| 104 + > drivers/media/video/davinci/vpfe_ccdc.c | 813 + > drivers/media/video/davinci/vpfe_ccdc.h | 85 + > drivers/media/video/davinci/vpfe_video.c | 1712 +++ > drivers/media/video/davinci/vpfe_video.h | 142 + > include/linux/davinci_vpfe.h | 1223 > include/linux/dm365_ccdc.h| 664 + > include/linux/dm3xx_ipipeif.h | 64 + > include/media/davinci/vpfe.h | 91 + > 27 files changed, 14829 insertions(+), 11 deletions(-) create mode 100644 > drivers/media/video/davinci/ccdc_types.h > create mode 100644 drivers/media/video/davinci/dm365_ccdc.c > create mode 100644 drivers/media/video/davinci/dm365_ccdc.h > create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h > create mode 100644 drivers/media/video/davinci/dm365_def_para.c > create mode 100644 drivers/media/video/davinci/dm365_def_para.h > create mode 100644 drivers/media/video/davinci/dm365_ipipe.c > create mode 100644 drivers/media/video/davinci/dm365_ipipe.h > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c > create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c > create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h > create mode 100644 drivers/media/video/davinci/imp_common.h > create mode 100644 drivers/media/video/davinci/imp_hw_if.h > create mode 100644 drivers/media/video/davinci/vpfe_capture.c > create mode 100644 drivers/media/video/davinci/vpfe_capture.h > create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c > create mode 100644 drivers/media/video/davinci/vpfe_ccdc.h > create mode 100644 drivers/media/video/davinci/vpfe_video.c > create mode 100644 drivers/media/video/davinci/vpfe_video.h > create mode 100644 include/linux/davinci_vpfe.h create mode 100644 > include/linux/dm365_ccdc.h create mode 100644 include/linux/dm3xx_ipipeif.h > create mode 100644 include/media/davinci/vpfe.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
RE: [RFC PATCH 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Sakari,
I have sent a fresh patch-set with your comments fixed and and some
cleanup and reorg of my own- mainly the headers. Please review.
Also, I had to keep one of your comments without code change as I felt it was
Ok to keep it here as it is only a local variable which actually gets the info
from the device specific data structures. I removed the other however.
Looking forward for your comments on further patches as well.
-Manju
On Thu, Jul 14, 2011 at 00:20:50, Sakari Ailus wrote:
> Hi Manju,
>
> Thanks for the patchset!
>
> I have a few comments on this patch below. I haven't read the rest of the
> patches yet so I may have more comments on this one when I do that.
>
> On Thu, Jun 30, 2011 at 06:43:10PM +0530, Manjunath Hadli wrote:
> > add support for dm3xx IPIPEIF hardware setup. This is the lowest
> > software layer for the dm3x vpfe driver which directly accesses
> > hardware. Add support for features like default pixel correction, dark
> > frame substraction and hardware setup.
> >
> > Signed-off-by: Manjunath Hadli
> > Signed-off-by: Nagabhushana Netagunte
> > ---
> > drivers/media/video/davinci/dm3xx_ipipeif.c | 368
> > +++
> > include/media/davinci/dm3xx_ipipeif.h | 292 +
> > 2 files changed, 660 insertions(+), 0 deletions(-) create mode
> > 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
> > create mode 100644 include/media/davinci/dm3xx_ipipeif.h
> >
> > diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
> > b/drivers/media/video/davinci/dm3xx_ipipeif.c
> > new file mode 100644
> > index 000..36cb61b
> > --- /dev/null
> > +++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
> > @@ -0,0 +1,368 @@
---code
> > +#include #include #include
> > + #include #include
> > + #include
> > +
> > +#define DM355 0
> > +#define DM365 1
> > +
> > +static void *__iomem ipipeif_base_addr;
>
> This looks device specific. What about using dev_set/get_drvdata and remove
> this one?
This one is actually gotten from the platform data structure in the manner you
suggested but stored here for local usage.
>
> > +static int device_type;
>
> Ditto. Both should be in a device specific struct.
This one I have removed.
>
> > +static inline u32 regr_if(u32 offset) {
> > + return readl(ipipeif_base_addr + offset); }
> > +
> > +static inline void regw_if(u32 val, u32 offset) {
> > + writel(val, ipipeif_base_addr + offset); }
--
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: Smart card reader support for Anysee DVB devices
2011/8/29 Antti Palosaari : > On 08/29/2011 05:44 PM, István Váradi wrote: >> >> Hi, >> >> 2011/8/17 Antti Palosaari: >>> >>> On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: > > Biggest problem I see whole thing is poor application support. OpenCT > is > rather legacy but there is no good alternative. All this kind of serial > drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. >>> >>> I studied scenario and looks like it is possible to implement way like, >>> register virtual USB HCI (virtual motherboard USB controller) then >>> register virtual PC/SC device to that which hooks all calls to HW via >>> Anysee driver. Some glue surely needed for emulate PC/SC. I think there >>> is not any such driver yet. Anyhow, there is virtual USB HCI driver >>> currently in staging which can be used as example, or even use it to >>> register virtual device. That kind of functionality surely needs more >>> talking... >> >> It maybe that smartcard guys care only for CCID, but wouldn't it be an >> overkill to implement an emulation of that for the driver? It can be >> done, of course, but I think it would be much more complicated than >> the current one. Is it really necessary to put such complexity into >> the kernel? In my opinion, this should be handled in user-space. > > Only De facto serial smartcard protocol is so called Phoenix/Smartmouse, > implementing new protocol is totally dead idea. It will never got any > support. > > There is already such drivers, at least Infinity Unlimited USB Phoenix > driver (iuu_phoenix.c). It uses USB-serial driver framework and some small > emulation for Phoenix protocol. Look that driver to see which kind of > complexity it adds. Anysee have *just* same situation. Phoenix/Smartmouse and CCID are quite different aren't they? So to support Phoenix I would need provide a USB serial device which talks the protocol, but there would be no need for a virtual USB HCI. Is that correct? Regards, Istvan > > regards > Antti > > > -- > http://palosaari.fi/ > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/8] davinci: vpfe: add v4l2 video driver support
add a generic video driver functionality to be used by all the vpfe
drivers for davinci SoCs. The functionality includes all the
standard v4l2 interfaces including streaming.
The video node interface can be used both as an input and output
node for both continuous and single shot modes.Also supports
dv_presets to include HD modes, wth support for both user pointer
IO and mmap.
Signed-off-by: Manjunath Hadli
Signed-off-by: Nagabhushana Netagunte
---
drivers/media/video/davinci/vpfe_video.c | 1712 ++
drivers/media/video/davinci/vpfe_video.h | 142 +++
2 files changed, 1854 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpfe_video.c
create mode 100644 drivers/media/video/davinci/vpfe_video.h
diff --git a/drivers/media/video/davinci/vpfe_video.c
b/drivers/media/video/davinci/vpfe_video.c
new file mode 100644
index 000..bb405fb
--- /dev/null
+++ b/drivers/media/video/davinci/vpfe_video.c
@@ -0,0 +1,1712 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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
+ *
+ * Contributors:-
+ * Manjunath Hadli
+ * Nagabhushana Netagunte
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "vpfe_capture.h"
+#include
+#include "ccdc_hw_device.h"
+
+/* number of buffers supported in single-shot mode */
+#define SS_NUM_BUFFERS 1
+/* minimum number of buffers needed in cont-mode */
+#define CONT_MIN_NUM_BUFFERS 3
+
+static int debug;
+
+/* get v4l2 subdev pointer to external subdev which is active */
+static struct v4l2_subdev *vpfe_get_input_sd(struct vpfe_video_device *video)
+{
+ struct vpfe_device *vpfe_dev = video->vpfe_dev;
+ struct media_pad *remote;
+
+ remote = media_entity_remote_source(&vpfe_dev->vpfe_ccdc.pads[0]);
+ if (remote == NULL) {
+ printk(KERN_ERR "invalid media connection to ccdc\n");
+ return NULL;
+ }
+
+ return media_entity_to_v4l2_subdev(remote->entity);
+}
+
+/* updates external subdev(sensor/decoder) which is active */
+static int vpfe_update_current_ext_subdev(struct vpfe_video_device *video)
+{
+ struct vpfe_device *vpfe_dev = video->vpfe_dev;
+ struct vpfe_config *vpfe_cfg;
+ struct v4l2_subdev *subdev;
+ struct media_pad *remote;
+ int i;
+
+ remote = media_entity_remote_source(&vpfe_dev->vpfe_ccdc.pads[0]);
+ if (remote == NULL) {
+ printk(KERN_ERR "invalid media connection to ccdc\n");
+ return -1;
+ }
+
+ subdev = media_entity_to_v4l2_subdev(remote->entity);
+
+ vpfe_cfg = vpfe_dev->pdev->platform_data;
+
+ for (i = 0; i < vpfe_cfg->num_subdevs; i++) {
+ if (!strcmp(vpfe_cfg->sub_devs[i].module_name, subdev->name)) {
+ video->current_ext_subdev = &vpfe_cfg->sub_devs[i];
+ break;
+ }
+ }
+
+ /* if user not linked decoder/sensor to ccdc */
+ if (i == vpfe_cfg->num_subdevs) {
+ printk(KERN_ERR "invalid media chain connection to ccdc\n");
+ return -1;
+ }
+
+ /* find the v4l2 subdev pointer */
+ for (i = 0; i < vpfe_dev->num_ext_subdevs; i++) {
+ if (!strcmp(video->current_ext_subdev->module_name,
+ vpfe_dev->sd[i]->name))
+ video->current_ext_subdev->subdev = vpfe_dev->sd[i];
+ }
+
+ return 0;
+}
+
+/* get the subdev which is connected to the output video node */
+static struct v4l2_subdev *
+vpfe_video_remote_subdev(struct vpfe_video_device *video, u32 *pad)
+{
+ struct media_pad *remote;
+
+ remote = media_entity_remote_source(&video->pad);
+
+ if (remote == NULL ||
+ remote->entity->type != MEDIA_ENT_T_V4L2_SUBDEV)
+ return NULL;
+
+ if (pad)
+ *pad = remote->index;
+
+ return media_entity_to_v4l2_subdev(remote->entity);
+}
+
+/* get the format set at ouput pad of the adjacent subdev */
+static int
+__vpfe_video_get_format(struct vpfe_video_device *video,
+ struct v4l2_format *format)
+{
+ struct v4l2_subdev_format fmt;
+ struct v4l2_subdev *subdev;
+ struct media_pad *remote;
+ u32 pad;
+ int ret;
+
+ subdev = vpfe_video_remote_subdev(vide
[PATCH v2 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
add support for dm3xx IPIPEIF hardware setup. This is the
lowest software layer for the dm3x vpfe driver which directly
accesses hardware. Add support for features like default
pixel correction, dark frame substraction and hardware setup.
Signed-off-by: Manjunath Hadli
Signed-off-by: Nagabhushana Netagunte
---
drivers/media/video/davinci/dm3xx_ipipeif.c | 317 +++
drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++
include/linux/dm3xx_ipipeif.h | 64 ++
3 files changed, 639 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h
create mode 100644 include/linux/dm3xx_ipipeif.h
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
b/drivers/media/video/davinci/dm3xx_ipipeif.c
new file mode 100644
index 000..ebc8895
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
@@ -0,0 +1,317 @@
+/*
+* Copyright (C) 2011 Texas Instruments Inc
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation version 2.
+*
+* 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
+*
+* ipipe module to hold common functionality across DM355 and DM365
+*/
+#include
+#include
+#include
+#include
+#include
+#include
+#include "dm3xx_ipipeif.h"
+
+static void *__iomem ipipeif_base_addr;
+
+static inline u32 regr_if(u32 offset)
+{
+ return readl(ipipeif_base_addr + offset);
+}
+
+static inline void regw_if(u32 val, u32 offset)
+{
+ writel(val, ipipeif_base_addr + offset);
+}
+
+void ipipeif_set_enable(char en, unsigned int mode)
+{
+ regw_if(1, IPIPEIF_ENABLE);
+}
+
+u32 ipipeif_get_enable(void)
+{
+ return regr_if(IPIPEIF_ENABLE);
+}
+
+int ipipeif_set_address(struct ipipeif *params, unsigned int address)
+{
+ u32 val;
+
+ if (params->source == 0)
+ return -EINVAL;
+
+ val = (params->adofs >> 5) & IPIPEIF_ADOFS_LSB_MASK;
+ regw_if(val, IPIPEIF_ADOFS);
+
+ /* lower sixteen bit */
+ val = (address >> IPIPEIF_ADDRL_SHIFT) & IPIPEIF_ADDRL_MASK;
+ regw_if(val, IPIPEIF_ADDRL);
+
+ /* upper next seven bit */
+ val = (address >> IPIPEIF_ADDRU_SHIFT) & IPIPEIF_ADDRU_MASK;
+ regw_if(val, IPIPEIF_ADDRU);
+
+ return 0;
+}
+
+static void ipipeif_config_dpc(struct ipipeif_dpc *dpc)
+{
+ u32 val;
+
+ /* Intialize val*/
+ val = 0;
+
+ if (dpc->en) {
+ val = (dpc->en & 1) << IPIPEIF_DPC2_EN_SHIFT;
+ val |= dpc->thr & IPIPEIF_DPC2_THR_MASK;
+ }
+
+ regw_if(val, IPIPEIF_DPC2);
+}
+
+#define RD_DATA_15_2 0x7
+/* This function sets up IPIPEIF and is called from
+ * ipipe_hw_setup()
+ */
+int ipipeif_hw_setup(struct ipipeif *params, int device_type)
+{
+ enum v4l2_mbus_pixelcode isif_port_if;
+ unsigned int val;
+
+ if (params == NULL)
+ return -EINVAL;
+
+ /* Enable clock to IPIPEIF and IPIPE */
+ if (device_type == DM365)
+ vpss_enable_clock(VPSS_IPIPEIF_CLOCK, 1);
+
+ /* Combine all the fields to make CFG1 register of IPIPEIF */
+ val = params->mode << ONESHOT_SHIFT;
+ val |= params->source << INPSRC_SHIFT;
+ val |= params->clock_select << CLKSEL_SHIFT;
+ val |= params->avg_filter << AVGFILT_SHIFT;
+ val |= params->decimation << DECIM_SHIFT;
+
+ if (device_type == DM355) {
+ val |= params->var.if_base.ialaw << IALAW_SHIFT;
+ val |= params->var.if_base.pack_mode << PACK8IN_SHIFT;
+ val |= params->var.if_base.clk_div << CLKDIV_SHIFT;
+ val |= params->var.if_base.data_shift << DATASFT_SHIFT;
+ } else {
+ /* DM365 IPIPE 5.1 */
+ val |= params->var.if_5_1.pack_mode << PACK8IN_SHIFT;
+ val |= params->var.if_5_1.source1 << INPSRC1_SHIFT;
+ if (params->source != IPIPEIF_SDRAM_YUV)
+ val |= params->var.if_5_1.data_shift << DATASFT_SHIFT;
+ else
+ val &= ~(RD_DATA_15_2 << DATASFT_SHIFT);
+ }
+ regw_if(val, IPIPEIF_CFG1);
+
+ switch (params->source) {
+ case IPIPEIF_CCDC:
+ regw_if(params->gain, IPIPEIF_GAIN);
+ break;
+ case IPIPEIF_SDRAM_RAW:
+ case IPIPEIF_CCDC_DARKFM:
+ regw_if(params->gain, IPIPEIF_GAIN);
+ /* fall throug
[PATCH v2 2/8] davinci: vpfe: add IPIPE hardware layer support
From: Nagabhushana Netagunte
add dm365 IPIPE hardware support. IPIPE is the hardware IP which
implements the functionality required for resizer, previewer and
the associated feature support. This is built along with the vpfe
driver, and implements hardware setup including coeffcient
programming for various hardware filters, gamma, cfa and clock
enable.
Signed-off-by: Manjunath Hadli
Signed-off-by: Nagabhushana Netagunte
---
drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++
drivers/media/video/davinci/dm365_ipipe_hw.h | 539 +++
2 files changed, 1488 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c
create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h
diff --git a/drivers/media/video/davinci/dm365_ipipe_hw.c
b/drivers/media/video/davinci/dm365_ipipe_hw.c
new file mode 100644
index 000..cb8f6e3
--- /dev/null
+++ b/drivers/media/video/davinci/dm365_ipipe_hw.c
@@ -0,0 +1,949 @@
+/*
+* Copyright (C) 2011 Texas Instruments Inc
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation version 2.
+*
+* 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
+#include
+#include
+#include
+#include "dm365_ipipe.h"
+#include "dm3xx_ipipeif.h"
+#include "dm365_ipipe_hw.h"
+
+static void ipipe_clock_enable(void)
+{
+ /* enable IPIPE MMR for register write access */
+ regw_ip(IPIPE_GCK_MMR_DEFAULT, IPIPE_GCK_MMR);
+ /* enable the clock wb,cfa,dfc,d2f,pre modules */
+ regw_ip(IPIPE_GCK_PIX_DEFAULT, IPIPE_GCK_PIX);
+ /* enable RSZ MMR for register write access */
+}
+
+/* Set input channel format to either 420 Y or C format */
+void rsz_set_in_pix_format(unsigned char y_c)
+{
+ u32 val;
+
+ val = regr_rsz(RSZ_SRC_FMT1);
+ val |= y_c & 1;
+ regw_rsz(val, RSZ_SRC_FMT1);
+}
+
+static void rsz_set_common_params(struct ipipe_params *params)
+{
+ struct rsz_common_params *rsz_common = ¶ms->rsz_common;
+ u32 val;
+
+ /* Set mode */
+ regw_rsz(params->ipipe_mode, RSZ_SRC_MODE);
+
+ /* data source selection and bypass */
+ val = (rsz_common->passthrough << RSZ_BYPASS_SHIFT) |
+ rsz_common->source;
+
+ regw_rsz(val, RSZ_SRC_FMT0);
+ val = regr_rsz(RSZ_SRC_MODE);
+ /* src image selection */
+ val = (rsz_common->raw_flip & 1) |
+ (rsz_common->src_img_fmt << RSZ_SRC_IMG_FMT_SHIFT) |
+ ((rsz_common->y_c & 1) << RSZ_SRC_Y_C_SEL_SHIFT);
+
+ regw_rsz(val, RSZ_SRC_FMT1);
+ regw_rsz(rsz_common->vps & IPIPE_RSZ_VPS_MASK, RSZ_SRC_VPS);
+ regw_rsz(rsz_common->hps & IPIPE_RSZ_HPS_MASK, RSZ_SRC_HPS);
+ regw_rsz(rsz_common->vsz & IPIPE_RSZ_VSZ_MASK, RSZ_SRC_VSZ);
+ regw_rsz(rsz_common->hsz & IPIPE_RSZ_HSZ_MASK, RSZ_SRC_HSZ);
+ regw_rsz(rsz_common->yuv_y_min, RSZ_YUV_Y_MIN);
+ regw_rsz(rsz_common->yuv_y_max, RSZ_YUV_Y_MAX);
+ regw_rsz(rsz_common->yuv_c_min, RSZ_YUV_C_MIN);
+ regw_rsz(rsz_common->yuv_c_max, RSZ_YUV_C_MAX);
+ /* chromatic position */
+ regw_rsz(rsz_common->out_chr_pos, RSZ_YUV_PHS);
+ val = regr_rsz(RSZ_SRC_MODE);
+}
+
+static void rsz_set_rsz_regs(unsigned int rsz_id, struct ipipe_params *params)
+{
+ struct ipipe_rsz_rescale_param *rsc_params;
+ struct ipipe_ext_mem_param *ext_mem;
+ struct ipipe_rsz_resize2rgb *rgb;
+ u32 reg_base;
+ u32 val;
+
+ val = regr_rsz(RSZ_SEQ);
+ rsc_params = ¶ms->rsz_rsc_param[rsz_id];
+ rgb = ¶ms->rsz2rgb[rsz_id];
+ ext_mem = ¶ms->ext_mem_param[rsz_id];
+
+ if (rsz_id == RSZ_A) {
+ val = rsc_params->h_flip << RSZA_H_FLIP_SHIFT;
+ val |= rsc_params->v_flip << RSZA_V_FLIP_SHIFT;
+ reg_base = RSZ_EN_A;
+ } else {
+ val = rsc_params->h_flip << RSZB_H_FLIP_SHIFT;
+ val |= rsc_params->v_flip << RSZB_V_FLIP_SHIFT;
+ reg_base = RSZ_EN_B;
+ }
+ /* update flip settings */
+ regw_rsz(val, RSZ_SEQ);
+
+ regw_rsz(rsc_params->mode, reg_base + RSZ_MODE);
+ val = (rsc_params->cen << RSZ_CEN_SHIFT) | rsc_params->yen;
+ regw_rsz(val, reg_base + RSZ_420);
+ regw_rsz(rsc_params->i_vps & RSZ_VPS_MASK, reg_base + RSZ_I_VPS);
+ regw_rsz(rsc_params->i_hps & RSZ_HPS_MASK, reg_base + RSZ_I_HPS);
+ regw_rsz(rsc_params->o_vsz & RSZ_O_VSZ_MASK, reg_base + RS
[PATCH v2 5/8] davinci: vpfe: add ccdc driver with media controller interface
Add the CCDC driver for davinci Dm3XX SoCs. The driver supports
CCDC as a media entity with 2 pads - 1 input and 1 output. The
driver implements streaming support and subdev interface. The
ccdc supports bayer and YUV formats.
Signed-off-by: Manjunath Hadli
Signed-off-by: Nagabhushana Netagunte
---
drivers/media/video/davinci/ccdc_hw_device.h | 10 +-
drivers/media/video/davinci/vpfe_ccdc.c | 813 ++
drivers/media/video/davinci/vpfe_ccdc.h | 85 +++
3 files changed, 901 insertions(+), 7 deletions(-)
create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c
create mode 100644 drivers/media/video/davinci/vpfe_ccdc.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
index 86b9b35..5394a06 100644
--- a/drivers/media/video/davinci/ccdc_hw_device.h
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -23,8 +23,8 @@
#ifdef __KERNEL__
#include
#include
-#include
-#include
+#include "ccdc_types.h"
+#include
/*
* ccdc hw operations
@@ -57,7 +57,7 @@ struct ccdc_hw_ops {
*/
int (*get_params) (void *params);
/* Pointer to function to configure ccdc */
- int (*configure) (void);
+ int (*configure) (int mode);
/* Pointer to function to set buffer type */
int (*set_buftype) (enum ccdc_buftype buf_type);
@@ -102,9 +102,5 @@ struct ccdc_hw_device {
struct ccdc_hw_ops hw_ops;
};
-/* Used by CCDC module to register & unregister with vpfe capture driver */
-int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
-void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
-
#endif
#endif
diff --git a/drivers/media/video/davinci/vpfe_ccdc.c
b/drivers/media/video/davinci/vpfe_ccdc.c
new file mode 100644
index 000..57d8b3d
--- /dev/null
+++ b/drivers/media/video/davinci/vpfe_ccdc.c
@@ -0,0 +1,813 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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
+ *
+ * Contributors:
+ * Manjunath Hadli
+ * Nagabhushana Netagunte
+ */
+#include
+#include
+#include
+#include
+#include
+#include "vpfe_capture.h"
+
+#include "ccdc_hw_device.h"
+
+#define MAX_WIDTH 4096
+#define MAX_HEIGHT 4096
+
+static const unsigned int ccdc_fmts[] = {
+ V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_YUYV10_1X20,
+ V4L2_MBUS_FMT_SBGGR10_1X10,
+};
+
+/*
+ * CCDC helper functions
+ */
+/* get field id in ccdc hardware */
+enum v4l2_field ccdc_get_fid(struct vpfe_device *vpfe_dev)
+{
+ struct vpfe_ccdc_device *ccdc = &vpfe_dev->vpfe_ccdc;
+ struct ccdc_hw_device *ccdc_dev = ccdc->ccdc_dev;
+
+ return ccdc_dev->hw_ops.getfid();
+}
+
+/* Retrieve active or try pad format based on query */
+static struct v4l2_mbus_framefmt *
+__ccdc_get_format(struct vpfe_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+ if (which == V4L2_SUBDEV_FORMAT_TRY) {
+ struct v4l2_subdev_format fmt;
+
+ fmt.pad = pad;
+ fmt.which = which;
+
+ return v4l2_subdev_get_try_format(fh, pad);
+ } else
+ return &ccdc->formats[pad];
+}
+
+/* configure format in ccdc hardware */
+static int vpfe_config_ccdc_format(struct vpfe_device *vpfe_dev,
+ unsigned int pad)
+{
+ struct ccdc_hw_device *ccdc_dev = vpfe_dev->vpfe_ccdc.ccdc_dev;
+ struct vpfe_ccdc_device *vpfe_ccdc = &vpfe_dev->vpfe_ccdc;
+ enum ccdc_frmfmt frm_fmt = CCDC_FRMFMT_INTERLACED;
+ struct v4l2_pix_format format;
+ int ret = 0;
+
+ v4l2_fill_pix_format(&format, &vpfe_dev->vpfe_ccdc.formats[pad]);
+ mbus_to_pix(&vpfe_dev->vpfe_ccdc.formats[pad], &format);
+
+ if (ccdc_dev->hw_ops.set_pixel_format(
+ format.pixelformat) < 0) {
+ v4l2_err(&vpfe_dev->v4l2_dev,
+ "couldn't set pix format in ccdc\n");
+ return -EINVAL;
+ }
+
+ /* call for s_crop will override these values */
+ vpfe_ccdc->crop.left = 0;
+ vpfe_ccdc->crop.top = 0;
+ vpfe_ccdc->crop.width = format.width;
+ vpfe_ccdc->crop.height = format.height;
+
+ /* configure the image window
[PATCH v2 8/8] davinci: vpfe: build infrastructure for dm365
add build infrastructure for dm365 specific modules such as IPIPE, AEW, AF. Signed-off-by: Manjunath Hadli Signed-off-by: Nagabhushana Netagunte --- drivers/media/video/davinci/Kconfig | 46 - drivers/media/video/davinci/Makefile | 17 +++- 2 files changed, 59 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..6f6da53 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -11,6 +11,48 @@ config DISPLAY_DAVINCI_DM646X_EVM To compile this driver as a module, choose M here: the module will be called vpif_display. +config VIDEO_DM365_3A_HW + tristate "DM365 Auto Focus, Auto Exposure/ White Balance HW module" + depends on ARCH_DAVINCI_DM365 + help + DM365 Auto Focus, Auto Exposure and Auto White Balancing HW module + + This module has functions which configure AEW/AF hardware, high level + AF module and AEW module use these functionalities. It collects metrics + about the image or video data + +config VIDEO_DM365_AF + tristate "DM365 Auto Focus Driver" + depends on ARCH_DAVINCI_DM365 + select VIDEO_DM365_3A_HW + help + DM365 Auto Focus hardware module. + + Auto Focus driver is used to support control loop for Auto Focus. + It collects metrics about the image or video data. This provides + hooks to AF subdevice driver. + +config VIDEO_DM365_AEW + tristate "DM365 Auto exposure /White Balance Driver" + depends on ARCH_DAVINCI_DM365 + select VIDEO_DM365_3A_HW + help + DM365 Auto Exposure and Auto White Balance hardware module. + + This is used to support the control loops for Auto Exposure + and Auto White Balance. It collects metrics about the image + or video data + +config DM365_IPIPE + depends on ARCH_DAVINCI && ARCH_DAVINCI_DM365 + tristate "DM365 IPIPE" + help + dm365 IPIPE hardware module. + + This is the hardware module that implements imp_hw_interface + for DM365. This hardware module provides previewer and resizer + functionality for image processing. + config CAPTURE_DAVINCI_DM646X_EVM tristate "DM646x EVM Video Capture" depends on VIDEO_DEV && MACH_DAVINCI_DM6467_EVM @@ -51,7 +93,7 @@ config VIDEO_VPFE_CAPTURE config VIDEO_DM6446_CCDC tristate "DM6446 CCDC HW module" - depends on VIDEO_VPFE_CAPTURE + depends on VIDEO_VPFE_CAPTURE && ARCH_DAVINCI_DM644x select VIDEO_VPSS_SYSTEM default y help @@ -80,7 +122,7 @@ config VIDEO_DM355_CCDC module will be called vpfe. config VIDEO_ISIF - tristate "ISIF HW module" + tristate "DM365 ISIF HW module" depends on ARCH_DAVINCI_DM365 && VIDEO_VPFE_CAPTURE select VIDEO_VPSS_SYSTEM default y diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..8544040 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -12,7 +12,20 @@ obj-$(CONFIG_CAPTURE_DAVINCI_DM646X_EVM) += vpif_capture.o # Capture: DM6446 and DM355 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o -obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o +obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o vpfe_ccdc.o \ + vpfe_resizer.o vpfe_previewer.o \ + vpfe_aew.o vpfe_af.o vpfe_video.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o -obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_ISIF) += dm365_ccdc.o + +dm365_a3_hw_driver-objs := dm365_a3_hw.o +obj-$(CONFIG_VIDEO_DM365_3A_HW) += dm365_a3_hw_driver.o +dm365_af_driver-objs := dm365_af.o +obj-$(CONFIG_VIDEO_DM365_AF)+= dm365_af_driver.o +dm365_aew_driver-objs := dm365_aew.o +obj-$(CONFIG_VIDEO_DM365_AEW) += dm365_aew_driver.o + +dm365_imp-objs := dm365_ipipe.o dm365_def_para.o \ +dm365_ipipe_hw.o dm3xx_ipipeif.o +obj-$(CONFIG_DM365_IPIPE) += dm365_imp.o -- 1.6.2.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] RFC for Media Controller capture driver for DM365
changes from last patch set: 1. Made changes based on Sakari's feedback mainly: a. returned early to allow unindenting b. reformatting to shift the code to left where possible c. changed hex numbers to lower case d. corrected the defines according to module names. e. magic numbers removed. f. changed non-integer returning functions to void g. removed unwanted paranthses. h. fixed error codes. i. fixed some RESET_BIt code to what it was intended for. 2. reorganized the header files to move the kernel-only headers along with the c files and interface headers in the include folder. Manjunath Hadli (6): davinci: vpfe: add dm3xx IPIPEIF hardware support module davinci: vpfe: add support for CCDC hardware for dm365 davinci: vpfe: add ccdc driver with media controller interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: v4l2 capture driver with media interface davinci: vpfe: build infrastructure for dm365 Nagabhushana Netagunte (2): davinci: vpfe: add IPIPE hardware layer support davinci: vpfe: add IPIPE support for media controller driver drivers/media/video/davinci/Kconfig | 46 +- drivers/media/video/davinci/Makefile | 17 +- drivers/media/video/davinci/ccdc_hw_device.h | 10 +- drivers/media/video/davinci/ccdc_types.h | 43 + drivers/media/video/davinci/dm365_ccdc.c | 1519 ++ drivers/media/video/davinci/dm365_ccdc.h | 88 + drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ drivers/media/video/davinci/dm365_def_para.c | 486 +++ drivers/media/video/davinci/dm365_def_para.h | 39 + drivers/media/video/davinci/dm365_ipipe.c | 3966 + drivers/media/video/davinci/dm365_ipipe.h | 300 ++ drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++ drivers/media/video/davinci/dm365_ipipe_hw.h | 539 drivers/media/video/davinci/dm3xx_ipipeif.c | 317 ++ drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++ drivers/media/video/davinci/imp_common.h | 85 + drivers/media/video/davinci/imp_hw_if.h | 178 ++ drivers/media/video/davinci/vpfe_capture.c| 793 + drivers/media/video/davinci/vpfe_capture.h| 104 + drivers/media/video/davinci/vpfe_ccdc.c | 813 + drivers/media/video/davinci/vpfe_ccdc.h | 85 + drivers/media/video/davinci/vpfe_video.c | 1712 +++ drivers/media/video/davinci/vpfe_video.h | 142 + include/linux/davinci_vpfe.h | 1223 include/linux/dm365_ccdc.h| 664 + include/linux/dm3xx_ipipeif.h | 64 + include/media/davinci/vpfe.h | 91 + 27 files changed, 14829 insertions(+), 11 deletions(-) create mode 100644 drivers/media/video/davinci/ccdc_types.h create mode 100644 drivers/media/video/davinci/dm365_ccdc.c create mode 100644 drivers/media/video/davinci/dm365_ccdc.h create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h create mode 100644 drivers/media/video/davinci/dm365_def_para.c create mode 100644 drivers/media/video/davinci/dm365_def_para.h create mode 100644 drivers/media/video/davinci/dm365_ipipe.c create mode 100644 drivers/media/video/davinci/dm365_ipipe.h create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h create mode 100644 drivers/media/video/davinci/imp_common.h create mode 100644 drivers/media/video/davinci/imp_hw_if.h create mode 100644 drivers/media/video/davinci/vpfe_capture.c create mode 100644 drivers/media/video/davinci/vpfe_capture.h create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c create mode 100644 drivers/media/video/davinci/vpfe_ccdc.h create mode 100644 drivers/media/video/davinci/vpfe_video.c create mode 100644 drivers/media/video/davinci/vpfe_video.h create mode 100644 include/linux/davinci_vpfe.h create mode 100644 include/linux/dm365_ccdc.h create mode 100644 include/linux/dm3xx_ipipeif.h create mode 100644 include/media/davinci/vpfe.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
Re: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Em 29-08-2011 06:24, Laurent Pinchart escreveu: > Hi Mauro, > > On Friday 26 August 2011 19:32:30 Mauro Carvalho Chehab wrote: >> Em 26-08-2011 12:29, Hans Verkuil escreveu: >>> On Friday, August 26, 2011 17:09:02 Mauro Carvalho Chehab wrote: Em 26-08-2011 11:16, Hans Verkuil escreveu: > On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: >> On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: >>> Em 24-08-2011 19:29, Sakari Ailus escreveu: >> [snip] >> The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. >>> >>> IMO, we should create a namespace device mapping for video devices. >>> What I >>> >>> mean is that we should keep the "raw" V4L2 devices as: >>> /dev/video?? >>> >>> But also recommend the creation of a new userspace map, like: >>> /dev/webcam?? >>> /dev/tv?? >>> ... >>> >>> with is an alias for the actual device. >>> >>> Something similar to dvd/cdrom aliases that already happen on most >>> distros: >>> >>> lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom -> sr0 >>> lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw -> sr0 >>> lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd -> sr0 >>> lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw -> sr0 >> >> I've been toying with a similar idea. libv4l currently wraps >> /dev/video* device nodes and assumes a 1:1 relationship between a >> video device node and a video device. Should this assumption be >> somehow removed, replaced by a video device concept that wouldn't be >> tied to a single video device node ? > > Just as background information: the original idea was always that all > v4l drivers would have a MC and that libv4l would use the information > contained there as a helper (such as deciding which nodes would be the > 'default' nodes for generic applications). This is something that libv4l won't do: it is up to the userspace application to choose the device node to open. Ok, libv4l can have helper APIs for that, like the one I wrote, but even adding MC support on it may not solve the issues. > Since there is only one MC device node for each piece of video hardware > that would make it much easier to discover what hardware there is and > what video nodes to use. > > I always liked that idea, although I know Mauro is opposed to having a > MC for all v4l drivers. It doesn't make sense to add MC for all V4L drivers. Not all devices are like ivtv with lots of device drivers. In a matter of fact, most supported devices create just one video node. Adding MC support for those devices will just increase the drivers complexity without _any_ reason, as those devices are fully configurable using the existing ioctl's. >>> >>> It's for consistency so applications know what to expect. >> >> I've already said it before: We won't be implementing an API for a device >> just for "consistency" without any real reason. > > We have a real reason: providing a single API through which applications can > enumerate devices and retrieve information such as device capabilities and > relationships between devices. There's no need to enumerate the relationship for a device with just one video node, and where everything is configured via V4L2 API. Adding MC support will only make things confusing. Also, see bellow. > >>> For all the simple drivers you'd just need some simple core support to add >>> a MC. What I always thought would be handy is for applications to just >>> iterate over all MCs and show which video/dvb/audio hardware the user has >>> in its system. >> >> MC doesn't work for audio yet, > > *yet* > >> as snd-usb-audio doesn't use it. So, it will fail for a large amount of >> devices whose audio is implemented using standard USB Audio Class. Adding MC >> support for it doesn't sound trivial, and won't offer any gain over the >> sysfs equivalent. >> Also, as I said before, and implemented at xawtv and at a v4l-utils library, the code may use sysfs for simpler devices. It shouldn't be hard to implement a mc aware code there, although I don't think that MC API is useful to discover what nodes are meant to be used for TV, encoder, decoder, webcams, etc. The only type information it currently provides is: #define MEDIA_ENT_T_DEVNODE
Re: Smart card reader support for Anysee DVB devices
On 08/29/2011 05:44 PM, István Váradi wrote: Hi, 2011/8/17 Antti Palosaari: On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Only De facto serial smartcard protocol is so called Phoenix/Smartmouse, implementing new protocol is totally dead idea. It will never got any support. There is already such drivers, at least Infinity Unlimited USB Phoenix driver (iuu_phoenix.c). It uses USB-serial driver framework and some small emulation for Phoenix protocol. Look that driver to see which kind of complexity it adds. Anysee have *just* same situation. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Smart card reader support for Anysee DVB devices
Hi, 2011/8/17 Antti Palosaari : > On 08/15/2011 02:14 PM, Antti Palosaari wrote: >> On 08/15/2011 02:51 AM, Antti Palosaari wrote: >>> Biggest problem I see whole thing is poor application support. OpenCT is >>> rather legacy but there is no good alternative. All this kind of serial >>> drivers seems to be OpenCT currently. >> >> I wonder if it is possible to make virtual CCID device since CCID seems >> to be unfortunately the only interface SmartCard guys currently care. > > I studied scenario and looks like it is possible to implement way like, > register virtual USB HCI (virtual motherboard USB controller) then > register virtual PC/SC device to that which hooks all calls to HW via > Anysee driver. Some glue surely needed for emulate PC/SC. I think there > is not any such driver yet. Anyhow, there is virtual USB HCI driver > currently in staging which can be used as example, or even use it to > register virtual device. That kind of functionality surely needs more > talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Regards, Istvan > > > regards, > Antti > -- > http://palosaari.fi/ > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert,
On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:
> > On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
> >> > On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
> >> >> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
> >> >> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> >> >> >> - When using a mode that cannot be represented in the legacy
> >> >> >> way,
> >> >> >
> >> >> > Definitely.
> >> >> >
> >> >> >> - But what with modes that can be represented? Legacy software
> >> >> >> cannot handle FB_{TYPE,VISUAL}_FOURCC.
> >> >> >
> >> >> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
> >> >> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called
> >> >> > with a non-FOURCC format, the driver will report non-FOURCC types
> >> >> > and visuals.
> >> >>
> >> >> Hmm, two use cases:
> >> >> - The video mode is configured using a FOURCC-aware tool ("fbset on
> >> >> steroids").
> >> >
> >> > Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
> >>
> >> Yep.
> >>
> >> >> Later the user runs a legacy application.
> >> >> => Do not retain FOURCC across opening of /dev/fb*.
> >> >
> >> > I know about that problem, but it's not that easy to work around. We
> >> > have no per-open fixed and variable screen info, and FB devices can
> >> > be opened by multiple applications at the same time.
> >> >
> >> >> - Is there an easy way to force FOURCC reporting, so new apps don't
> >> >> have to support parsing the legacy formats? This is useful for new
> >> >> apps that want to support (a subset of) FOURCC modes only.
> >> >
> >> > Not at the moment.
> >>
> >> So perhaps we do need new ioctls instead...
> >> That would also ease an in-kernel translation layer.
> >
> > Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls
> > for the above two operations ?
>
> New ioctls to replace the FOURCC proposal.
*sigh*...
I'd like other people's opinion on this before throwing everything away.
Florian, Magnus, Guennadi, others, what do you think ?
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart
wrote:
> On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
>> > On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
>> >> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
>> >> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
>> >> >> - When using a mode that cannot be represented in the legacy way,
>> >> >
>> >> > Definitely.
>> >> >
>> >> >> - But what with modes that can be represented? Legacy software
>> >> >> cannot handle FB_{TYPE,VISUAL}_FOURCC.
>> >> >
>> >> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
>> >> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with
>> >> > a non-FOURCC format, the driver will report non-FOURCC types and
>> >> > visuals.
>> >>
>> >> Hmm, two use cases:
>> >> - The video mode is configured using a FOURCC-aware tool ("fbset on
>> >> steroids").
>> >
>> > Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
>>
>> Yep.
>>
>> >> Later the user runs a legacy application.
>> >> => Do not retain FOURCC across opening of /dev/fb*.
>> >
>> > I know about that problem, but it's not that easy to work around. We have
>> > no per-open fixed and variable screen info, and FB devices can be opened
>> > by multiple applications at the same time.
>> >
>> >> - Is there an easy way to force FOURCC reporting, so new apps don't
>> >> have to support parsing the legacy formats? This is useful for new apps
>> >> that want to support (a subset of) FOURCC modes only.
>> >
>> > Not at the moment.
>>
>> So perhaps we do need new ioctls instead...
>> That would also ease an in-kernel translation layer.
>
> Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls for
> the above two operations ?
New ioctls to replace the FOURCC proposal.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Usb digital TV
Hi Gabriel, On 8/29/11, Gabriel Sartori wrote: > It there some devices that has more chance to work on a 2.6.35 kernel > version so I can just cross compile the driver to my mx28 board in a > easier way? > > Thanks in advance. > I suggest you using a device based on dib0700, I got it working on Linux <= 2.6.35: https://acassis.wordpress.com/2009/09/18/watching-digital-tv-sbtvd-in-the-linux/ This same device working on i-MXT (Android 2.2 with Linux kernel 2.6.35): http://holoscopio.com/misc/androidtv/ Best Regards, Alan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert,
On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
> > On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
> >> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> >> >> - When using a mode that cannot be represented in the legacy way,
> >> >
> >> > Definitely.
> >> >
> >> >> - But what with modes that can be represented? Legacy software
> >> >> cannot handle FB_{TYPE,VISUAL}_FOURCC.
> >> >
> >> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
> >> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with
> >> > a non-FOURCC format, the driver will report non-FOURCC types and
> >> > visuals.
> >>
> >> Hmm, two use cases:
> >> - The video mode is configured using a FOURCC-aware tool ("fbset on
> >> steroids").
> >
> > Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
>
> Yep.
>
> >> Later the user runs a legacy application.
> >> => Do not retain FOURCC across opening of /dev/fb*.
> >
> > I know about that problem, but it's not that easy to work around. We have
> > no per-open fixed and variable screen info, and FB devices can be opened
> > by multiple applications at the same time.
> >
> >> - Is there an easy way to force FOURCC reporting, so new apps don't
> >> have to support parsing the legacy formats? This is useful for new apps
> >> that want to support (a subset of) FOURCC modes only.
> >
> > Not at the moment.
>
> So perhaps we do need new ioctls instead...
> That would also ease an in-kernel translation layer.
Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls for
the above two operations ?
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart
wrote:
> On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
>> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
>> >> - When using a mode that cannot be represented in the legacy way,
>> >
>> > Definitely.
>> >
>> >> - But what with modes that can be represented? Legacy software cannot
>> >> handle FB_{TYPE,VISUAL}_FOURCC.
>> >
>> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
>> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a
>> > non-FOURCC format, the driver will report non-FOURCC types and visuals.
>>
>> Hmm, two use cases:
>> - The video mode is configured using a FOURCC-aware tool ("fbset on
>> steroids").
>
> Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
Yep.
>> Later the user runs a legacy application.
>> => Do not retain FOURCC across opening of /dev/fb*.
>
> I know about that problem, but it's not that easy to work around. We have no
> per-open fixed and variable screen info, and FB devices can be opened by
> multiple applications at the same time.
>
>> - Is there an easy way to force FOURCC reporting, so new apps don't have
>> to support parsing the legacy formats? This is useful for new apps that
>> want to support (a subset of) FOURCC modes only.
>
> Not at the moment.
So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert,
On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
> >> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> >> - When using a mode that cannot be represented in the legacy way,
> >
> > Definitely.
> >
> >> - But what with modes that can be represented? Legacy software cannot
> >> handle FB_{TYPE,VISUAL}_FOURCC.
> >
> > My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
> > configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a
> > non-FOURCC format, the driver will report non-FOURCC types and visuals.
>
> Hmm, two use cases:
> - The video mode is configured using a FOURCC-aware tool ("fbset on
> steroids").
Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
> Later the user runs a legacy application.
> => Do not retain FOURCC across opening of /dev/fb*.
I know about that problem, but it's not that easy to work around. We have no
per-open fixed and variable screen info, and FB devices can be opened by
multiple applications at the same time.
> - Is there an easy way to force FOURCC reporting, so new apps don't have
> to support parsing the legacy formats? This is useful for new apps that
> want to support (a subset of) FOURCC modes only.
Not at the moment.
--
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
Usb digital TV
Hello, I am from Brazil and my english is not very good. First of all, I am new on the list. I work with embedded system development here in Brazil. I have a lot to learn but I expect to help too! I don't know if it is the right place to ask. Sorry if it is not. I have a i.mx28EVK board and I would like to get a usb digital tv module to work on it. It should work in 1seg. First of all I bought a two usb devices: - pixelview sbtvd hybrid - Leadership The first one uses driver cx231xx and the second one smsdvb. My board have a 2.6.35 kernel with specific paths from freescale. First off all I tried to plug the first device in my pc. It only worked with an newer kernel version 2.6.38 or with some specific pathes for brazil patterns in a 2.6.36. I was able to see some channels here. But It seems very dificult to me to port all these changes and make it work on my old 2.6.35 kernel. The second device has a strange behavior. It worked on my PC with older kernels like 2.6.32. It should work in my mx28 board too. But I cannot scan any channel!?!?!? In dmesg i got: [ 332.620053] smscore_set_device_mode: firmware download success: isdbt_nova_12mhz_b0.inp [ 332.620615] usbcore: registered new interface driver smsusb [ 350.721231] DVB: registering new adapter (Siano Nova B Digital Receiver) [ 350.724588] DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... In my /dev/dvb/adapter0 I have three devices: - demux0 - dvr0 - frontend0 If I tried to scan with: sudo w_scan -ft -x -c BR I got the follow messages: ERROR: Sorry - i couldn't get any working frequency/transponder Can someone help me with this last thing? It seems everything is ok but I cannot scan channel. It there some devices that has more chance to work on a 2.6.35 kernel version so I can just cross compile the driver to my mx28 board in a easier way? Thanks in advance. Gabriel Sartori -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart
wrote:
>> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
>> - When using a mode that cannot be represented in the legacy way,
>
> Definitely.
>
>> - But what with modes that can be represented? Legacy software cannot
>> handle FB_{TYPE,VISUAL}_FOURCC.
>
> My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is configured
> using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a non-FOURCC
> format, the driver will report non-FOURCC types and visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool ("fbset on
steroids").
Later the user runs a legacy application.
=> Do not retain FOURCC across opening of /dev/fb*.
- Is there an easy way to force FOURCC reporting, so new apps don't have to
support parsing the legacy formats? This is useful for new apps that want to
support (a subset of) FOURCC modes only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: [ANN] Meeting minutes of the Cambourne meeting
Hi Sylwester,
On Sunday 28 August 2011 13:28:23 Sylwester Nawrocki wrote:
> On 08/08/2011 05:50 PM, Laurent Pinchart wrote:
> > Subdevs hierachy, Linux device model
> >
> >
> > Preliminary conclusions:
> >
> > - With the move to device tree on ARM (and other platforms), I2C, SPI
> > and
> >
> > platform subdevs should be created from board code, not from
> > bridge/host drivers.
> >
> > - Bus notifiers should be used by bridge/host drivers to wait for all
> >
> > required subdevs. V4L2 core should provide helper functions.
> >
> > - struct clk should be used to handle clocks provided by hosts to
> > subdevs.
>
> I have been investigating recently possible ways to correct the external
> clock handling in Samsung FIMC driver and this led me up to the device
> tree stuff. I.e. in order to be able to register any I2C client device
> there is a need to enable its master clock at the v4l2 host/bridge driver.
To be completely generic, the subdev master clock can come from anywhere, not
only from the V4L2 host/bridge (although that's the usual case).
> There is an issue that the v4l2_device (host)/v4l2_subdev hierarchy is not
> reflected by the linux device tree model, e.g. the host might be a platform
> device while the client an I2C client device. Thus a proper device/driver
> registration order is not assured by the device driver core from v4l2 POV.
>
> I thought about embedding some API in a struct v4l2_device for the subdevs
> to be able to get their master clock(s) as they need it. But this would
> work only when a v4l2_device and v4l2_subdev are matched (registered)
> before I2C client's probe(), or alternatively
> subdev_internal_ops::registered() callback, is called.
>
> Currently such requirement is satisfied when the I2C client/v4l2 subdev
> devices are registered from within a v4l2 bridge/host driver initialization
> routine. But we may need to stop doing this to adhere to the DT rules.
Right, that's my understanding as well.
> I guess above you didn't really mean to create subdevs from board code?
> The I2C client registration is now done at the I2C bus drivers, using the
> OF helpers to retrieve the child devices list from fdt.
I meant registering the I2C board information from board code (for non-DT
platforms) or from the device tree (for DT platforms) instead of V4L2
host/bridge drivers.
> I guess we could try to create some sort of replacement for
> v4l2_i2c_new_subdev_board() function in linux/drivers/of/* (of_i2c.c ?),
> similar to of_i2c_register_devices().
>
> But first we would have somehow to make sure the host drivers are registered
> and initialized first. I'm not sure how to do it.
> Plus such a new subdev registration method would have to obtain a relevant
> struct v4l2_device object reference during the process; which is getting
> a bit cumbersome..
>
> Also, if we used a 'struct clk' to handle clocks provided by hosts to
> subdevs, could we use any subdev operation callback to pass a reference to
> such object from host to subdev? I doubt since the clock may be needed in
> the subdev before it is allocated and fully initialized, (i.e. available
> in the host).
>
> If we have embedded a 'struct clk' pointer into struct v4l2_device, it
> would have probably to be an array of clocks and the subdev would have to
> be able to find out which clock applies to it.
>
> So I thought about doing something like:
>
> diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
> index d61febf..9888f7d 100644
> --- a/include/media/v4l2-device.h
> +++ b/include/media/v4l2-device.h
> @@ -54,6 +54,7 @@ struct v4l2_device {
> /* notify callback called by some sub-devices. */
> void (*notify)(struct v4l2_subdev *sd,
> unsigned int notification, void *arg);
> + const struct clk * (*clock_get)(struct v4l2_subdev *sd);
> /* The control handler. May be NULL. */
> struct v4l2_ctrl_handler *ctrl_handler;
> /* Device's priority state */
>
> This would allow the host to return proper clock for a subdev.
> But it won't work unless the initialization order is assured..
My idea was to let the kernel register all devices based on the DT or board
code. When the V4L2 host/bridge driver gets registered, it will then call a
V4L2 core function with a list of subdevs it needs. The V4L2 core would store
that information and react to bus notifier events to notify the V4L2
host/bridge driver when all subdevs are present. At that point the host/bridge
driver will get hold of all the subdevs and call (probably through the V4L2
core) their .registered operation. That's where the subdevs will get access to
their clock using clk_get().
This is really a rough idea, we will probably run into unexpected issues. I'm
not even sure if this can work out in the end, but I don't really see another
clean solution for now.
--
Regards,
Laurent Pinchart
--
Re: [PATCH 4/5] [media] v4l: fix copying ioctl results on failure
Hi Tomasz,
On Monday 29 August 2011 13:55:31 Tomasz Stanislawski wrote:
> On 08/29/2011 10:56 AM, Laurent Pinchart wrote:
> > On Monday 29 August 2011 10:01:58 Tomasz Stanislawski wrote:
> >> On 08/26/2011 05:09 PM, Laurent Pinchart wrote:
> >>> On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote:
> This patch fix the handling of data passed to V4L2 ioctls. The
> content of the structures is not copied if the ioctl fails. It
> blocks ability to obtain any information about occurred error other
> then errno code. This patch fix this issue.
> >>>
> >>> Does the V4L2 spec say anything on this topic ? We might have
> >>> applications that rely on the ioctl argument structure not being
> >>> touched when a failure occurs.
> >>
> >> Ups.. I missed something. It looks that modifying ioctl content is
> >> illegal if ioctl fails. The spec says:
> >> "When an ioctl that takes an output or read/write parameter fails, the
> >> parameter remains unmodified." (v4l2 ioctl section)
> >> However, there is probably a bug already present in V4L2 framework.
> >> There are some ioctls that takes a pointer to an array as a field in the
> >> argument struct.
> >> The examples are all VIDIOC_*_EXT_CTRLS and VIDIOC_{QUERY/DQ/Q}_BUF
> >> family. The content of such an auxiliary arays is copied even if ioctl
> >> fails. Please take a look to video_usercopy function in v4l2-ioctl.c.
> >> Therefore I think that the spec is already violated. What is your
> >> opinion about this problem?
> >
> > I think it was a bad idea to state that a parameter remains unmodified
> > when the ioctl fails in the first place. I'm fine with not following
> > that for new ioctls, but applications might rely on it for existing
> > ioctls.
> >
> >> Now back to selection case.
> >> This patch was added as proposition of fix to VIDIOC_S_SELECTION, to
> >> return the best-hit rectangle if constraints could not be satisfied. The
> >> ioctl return -ERANGE in this case. Using those return values the
> >> application gets some feedback on loosing constraints.
> >
> > Shouldn't that always be the case ? :-) VIDIOC_S_SELECTION should adjust
> > the rectangle up or down depending on the constraints and always return
> > the best match without any error.
>
> ok.. but what to do if constraints could not be satisfied?
> The configuration should not be applied to the hardware in such a case,
> because it is not what the application desired.
> Therefore the ioctl must fail ... somehow.
> If the ioctl always succeed then the constraint flags becomes actually
> the hints.
That's what currently happens with S_FMT. Is that behaviour too limited in
your opinion ?
> We may need TRY_SELECTION to test rectangles without applying it.
>
> I thought that returning the best-hit rectangle by S_SELECTION might be
> useful because it gives the application some feedback on what the driver
> would accept.
If we indeed need to fail with -ERANGE, I agree with you, the behaviour is
useful. It would make sense in that case to only update the parameter for a
specific set of ioctls. The V4L2 documentation will also need to be fixed.
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert,
On Monday 29 August 2011 13:20:44 Geert Uytterhoeven wrote:
> On Mon, Aug 29, 2011 at 13:08, Laurent Pinchart wrote:
> > On Monday 29 August 2011 13:04:15 Geert Uytterhoeven wrote:
> >> On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart wrote:
> >> > On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote:
> >> >> On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote:
> >> [...]
> >>
> >> > If my understanding is now correct, a V4L2 planar YUV type where Y, U
> >> > and V components are stored in separate byte-oriented planes, with
> >> > each plane storing Y, U or V components packed (such as
> >> > http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html),
> >> > would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would
> >> > be true for an RGB format where each component is stored in a
> >> > separate plane with each plane sotring R, G or B packed.
> >>
> >> Indeed. Currently this cannot be represented.
> >
> > Good, at least I now understand the situation :-)
> >
> >> For ideas from the past, see e.g.
> >> http://comments.gmane.org/gmane.linux.fbdev.devel/10951.
> >>
> >> > If the above is correct, what FB_TYPE_* should a driver report when
> >> > using FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P
> >> > (http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html)
> >> > or V4L2_PIX_FMT_NV12
> >> > (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ?
> >>
> >> We need new types for those. Or always use FOURCC for them.
> >
> > My proposal currently defined FB_VISUAL_FOURCC. What about adding
> > FB_TYPE_FOURCC as well ?
>
> That may make sense.
> When will the driver report FB_{TYPE,VISUAL}_FOURCC?
> - When using a mode that cannot be represented in the legacy way,
Definitely.
> - But what with modes that can be represented? Legacy software cannot
> handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is configured
using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a non-FOURCC
format, the driver will report non-FOURCC types and visuals.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
Hi Guennadi,
On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
> On Mon, 29 Aug 2011, Laurent Pinchart wrote:
> > On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
> > > On Sun, 28 Aug 2011, Laurent Pinchart wrote:
> > >
> > > [snip]
> > >
> > > > > @@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct
> > > > > i2c_client *client) }
> > > > >
> > > > > /* Find a data format by a pixel code in an array */
> > > > >
> > > > > -static const struct ov5642_datafmt
> > > > > - *ov5642_find_datafmt(enum v4l2_mbus_pixelcode
> > > > > code)
> > > > > +static const struct ov5642_datafmt *ov5642_find_datafmt(enum
> > > > > v4l2_mbus_pixelcode code) {
> > > >
> > > > checkpatch.pl won't be happy.
> > >
> > > Since the lift of the hard 80-char limit, I often find lines of 86
> > > characters more acceptable than their split versions.
> >
> > When has that been lifted ?
>
> Sorry, don't have a link at hand, a few months ago, either beginning of
> this or end of last year, perhaps. There has been a lengthy discussion on
> multiple lists, mainly lkml, the common mood was, that 80 chars wasn't
> meaningful anymore, but I'm not sure what exact actions have been executed
> to document this.
I remember the discussion but I wasn't sure if anything had been decided and
set in stone.
> > > [snip]
> > >
> > > > > @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev
> > > > > *sd,
> > > > >
> > > > > ov5642_try_fmt(sd, mf);
> > > > >
> > > > > + priv->out_size.width= mf->width;
> > > > > + priv->out_size.height = mf->height;
> > > >
> > > > It looks like to me (but I may be wrong) that you achieve different
> > > > resolutions using cropping, not scaling. If that's correct you should
> > > > implement s_crop support and refuse changing the resolution through
> > > > s_fmt.
> > >
> > > As the patch explains (I think) on several occasions, currently only
> > > the 1:1 scale is supported, and it was our deliberate choice to
> > > implement this using the scaling API
> >
> > If you implement cropping, you should use the crop API, not the scaling
> > API
> >
> > :-)
>
> It's changing both - input and output sizes.
Sure, but it's still cropping.
--
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 v3] media: vb2: change queue initialization order
On Mon, 29 Aug 2011, Marek Szyprowski wrote: > Hello, > > On Monday, August 29, 2011 2:05 PM Guennadi Liakhovetski wrote: > > > Hi Marek > > > > On Mon, 29 Aug 2011, Marek Szyprowski wrote: > > > > > This patch changes the order of operations during stream on call. Now the > > > buffers are first queued to the driver and then the start_streaming method > > > is called. > > > > > > This resolves the most common case when the driver needs to know buffer > > > addresses to enable dma engine and start streaming. Additional parameter > > > to start_streaming method have been added to simplify drivers code. The > > > driver are now obliged to check if the number of queued buffers is high > > > enough to enable hardware streaming. If not - it can return an error. In > > > such case all the buffers that have been pre-queued are invalidated. > > > > > > This patch also updates all videobuf2 clients to work properly with the > > > changed order of operations. > > > > > > Signed-off-by: Marek Szyprowski > > > Signed-off-by: Kyungmin Park > > > CC: Pawel Osciak > > > CC: Guennadi Liakhovetski > > > CC: Hans Verkuil > > > CC: Tomasz Stanislawski > > > CC: Sylwester Nawrocki > > > CC: Kamil Debski > > > CC: Jonathan Corbet > > > CC: Josh Wu > > > CC: Hans de Goede > > > CC: Paul Mundt > > > --- > > > > > > Hello, > > > > > > This is yet another version of the patch that introduces significant > > > changes in the vb2 streamon operation. I've decided to remove the > > > additional parameter to buf_queue callback and added a few cleanups here > > > and there. This patch also includes an update for all vb2 clients. > > > > Just for the record: These are not all vb2 clients. A simple grep for > > something like vb2_ops gives you also > > > > drivers/media/video/mx3_camera.c > > drivers/media/video/sh_mobile_ceu_camera.c > > Yes, they are also vb2 clients, but since they don't use start_streaming() > callback no changes were needed there. Same applies to mem2mem_testdev driver. Great, thanks for the explanation! Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
On Mon, 29 Aug 2011, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
> > On Sun, 28 Aug 2011, Laurent Pinchart wrote:
> >
> > [snip]
> >
> > > > @@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct
> > > > i2c_client *client) }
> > > >
> > > > /* Find a data format by a pixel code in an array */
> > > >
> > > > -static const struct ov5642_datafmt
> > > > - *ov5642_find_datafmt(enum v4l2_mbus_pixelcode
> > > > code)
> > > > +static const struct ov5642_datafmt *ov5642_find_datafmt(enum
> > > > v4l2_mbus_pixelcode code) {
> > >
> > > checkpatch.pl won't be happy.
> >
> > Since the lift of the hard 80-char limit, I often find lines of 86
> > characters more acceptable than their split versions.
>
> When has that been lifted ?
Sorry, don't have a link at hand, a few months ago, either beginning of
this or end of last year, perhaps. There has been a lengthy discussion on
multiple lists, mainly lkml, the common mood was, that 80 chars wasn't
meaningful anymore, but I'm not sure what exact actions have been executed
to document this.
>
> > [snip]
> >
> > > > @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev *sd,
> > > >
> > > > ov5642_try_fmt(sd, mf);
> > > >
> > > > + priv->out_size.width= mf->width;
> > > > + priv->out_size.height = mf->height;
> > >
> > > It looks like to me (but I may be wrong) that you achieve different
> > > resolutions using cropping, not scaling. If that's correct you should
> > > implement s_crop support and refuse changing the resolution through
> > > s_fmt.
> >
> > As the patch explains (I think) on several occasions, currently only the
> > 1:1 scale is supported, and it was our deliberate choice to implement this
> > using the scaling API
>
> If you implement cropping, you should use the crop API, not the scaling API
> :-)
It's changing both - input and output sizes.
>
> > > > @@ -793,10 +868,12 @@ static int ov5642_g_fmt(struct v4l2_subdev *sd,
> > > >
> > > > mf->code= fmt->code;
> > > > mf->colorspace = fmt->colorspace;
> > > >
> > > > - mf->width = OV5642_WIDTH;
> > > > - mf->height = OV5642_HEIGHT;
> > > > + mf->width = priv->out_size.width;
> > > > + mf->height = priv->out_size.height;
> > > >
> > > > mf->field = V4L2_FIELD_NONE;
> > > >
> > > > + dev_dbg(sd->v4l2_dev->dev, "%s return width: %u heigth: %u\n",
> > > > __func__, + mf->width, mf->height);
> > >
> > > Isn't that a bit too verbose ? Printing the format in a debug message in
> > > the s_fmt handler is useful, but maybe doing it in g_fmt is a bit too
> > > much.
> >
> > This is a dev_dbg()... Personally, as long as they don't clutter the source
> > code needlessly, compile without warnings and have their typos fixed (;-))
>
> Removing it is a good way to fix the typo :-)
>
> > I don't have problems with an odd instance, even if I don't really perceive
> > its output as particularly useful:-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
Hi Guennadi,
On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
> On Sun, 28 Aug 2011, Laurent Pinchart wrote:
>
> [snip]
>
> > > @@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct
> > > i2c_client *client) }
> > >
> > > /* Find a data format by a pixel code in an array */
> > >
> > > -static const struct ov5642_datafmt
> > > - *ov5642_find_datafmt(enum v4l2_mbus_pixelcode code)
> > > +static const struct ov5642_datafmt *ov5642_find_datafmt(enum
> > > v4l2_mbus_pixelcode code) {
> >
> > checkpatch.pl won't be happy.
>
> Since the lift of the hard 80-char limit, I often find lines of 86
> characters more acceptable than their split versions.
When has that been lifted ?
> [snip]
>
> > > @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev *sd,
> > >
> > > ov5642_try_fmt(sd, mf);
> > >
> > > + priv->out_size.width= mf->width;
> > > + priv->out_size.height = mf->height;
> >
> > It looks like to me (but I may be wrong) that you achieve different
> > resolutions using cropping, not scaling. If that's correct you should
> > implement s_crop support and refuse changing the resolution through
> > s_fmt.
>
> As the patch explains (I think) on several occasions, currently only the
> 1:1 scale is supported, and it was our deliberate choice to implement this
> using the scaling API
If you implement cropping, you should use the crop API, not the scaling API
:-)
> > > @@ -793,10 +868,12 @@ static int ov5642_g_fmt(struct v4l2_subdev *sd,
> > >
> > > mf->code= fmt->code;
> > > mf->colorspace = fmt->colorspace;
> > >
> > > - mf->width = OV5642_WIDTH;
> > > - mf->height = OV5642_HEIGHT;
> > > + mf->width = priv->out_size.width;
> > > + mf->height = priv->out_size.height;
> > >
> > > mf->field = V4L2_FIELD_NONE;
> > >
> > > + dev_dbg(sd->v4l2_dev->dev, "%s return width: %u heigth: %u\n",
> > > __func__, + mf->width, mf->height);
> >
> > Isn't that a bit too verbose ? Printing the format in a debug message in
> > the s_fmt handler is useful, but maybe doing it in g_fmt is a bit too
> > much.
>
> This is a dev_dbg()... Personally, as long as they don't clutter the source
> code needlessly, compile without warnings and have their typos fixed (;-))
Removing it is a good way to fix the typo :-)
> I don't have problems with an odd instance, even if I don't really perceive
> its output as particularly useful:-)
--
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 v3] media: vb2: change queue initialization order
Hello, On Monday, August 29, 2011 2:05 PM Guennadi Liakhovetski wrote: > Hi Marek > > On Mon, 29 Aug 2011, Marek Szyprowski wrote: > > > This patch changes the order of operations during stream on call. Now the > > buffers are first queued to the driver and then the start_streaming method > > is called. > > > > This resolves the most common case when the driver needs to know buffer > > addresses to enable dma engine and start streaming. Additional parameter > > to start_streaming method have been added to simplify drivers code. The > > driver are now obliged to check if the number of queued buffers is high > > enough to enable hardware streaming. If not - it can return an error. In > > such case all the buffers that have been pre-queued are invalidated. > > > > This patch also updates all videobuf2 clients to work properly with the > > changed order of operations. > > > > Signed-off-by: Marek Szyprowski > > Signed-off-by: Kyungmin Park > > CC: Pawel Osciak > > CC: Guennadi Liakhovetski > > CC: Hans Verkuil > > CC: Tomasz Stanislawski > > CC: Sylwester Nawrocki > > CC: Kamil Debski > > CC: Jonathan Corbet > > CC: Josh Wu > > CC: Hans de Goede > > CC: Paul Mundt > > --- > > > > Hello, > > > > This is yet another version of the patch that introduces significant > > changes in the vb2 streamon operation. I've decided to remove the > > additional parameter to buf_queue callback and added a few cleanups here > > and there. This patch also includes an update for all vb2 clients. > > Just for the record: These are not all vb2 clients. A simple grep for > something like vb2_ops gives you also > > drivers/media/video/mx3_camera.c > drivers/media/video/sh_mobile_ceu_camera.c Yes, they are also vb2 clients, but since they don't use start_streaming() callback no changes were needed there. Same applies to mem2mem_testdev driver. 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
[GIT PULL FOR 3.2] dvb-usb: add ATSC support for the Hauppauge WinTV-Aero-M
Hello Mauro, Please pull from the aero-m branch of my mxl111sf tree to add ATSC support for the Hauppauge WinTV-Aero-M: The following changes since commit c9f88aa976b79a26561fb7754a1e0e00ff7626fe: Jose Alberto Reguero (1): [media] ttusb2: add support for the dvb-t part of CT-3650 v3 are available in the git repository at: http://git.linuxtv.org/mkrufky/mxl111sf.git aero-m Michael Krufky (2): dvb-usb: add ATSC support for the Hauppauge WinTV-Aero-M mxl111sf: Change adapter FE pointer as array of FE pointers. drivers/media/dvb/dvb-usb/Kconfig |8 + drivers/media/dvb/dvb-usb/Makefile |4 + drivers/media/dvb/dvb-usb/mxl111sf-gpio.c | 763 + drivers/media/dvb/dvb-usb/mxl111sf-gpio.h | 56 ++ drivers/media/dvb/dvb-usb/mxl111sf-i2c.c | 851 +++ drivers/media/dvb/dvb-usb/mxl111sf-i2c.h | 35 ++ drivers/media/dvb/dvb-usb/mxl111sf-phy.c | 342 +++ drivers/media/dvb/dvb-usb/mxl111sf-phy.h | 53 ++ drivers/media/dvb/dvb-usb/mxl111sf-reg.h | 179 ++ drivers/media/dvb/dvb-usb/mxl111sf-tuner.c | 476 drivers/media/dvb/dvb-usb/mxl111sf-tuner.h | 89 +++ drivers/media/dvb/dvb-usb/mxl111sf.c | 854 drivers/media/dvb/dvb-usb/mxl111sf.h | 158 + 13 files changed, 3868 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-gpio.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-gpio.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-i2c.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-i2c.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-phy.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-phy.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-reg.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-tuner.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-tuner.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf.h Thanks & regards, Michael Krufky -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: Add support for arbitrary resolution for the ov5642 camera driver
Hi Laurent
On Sun, 28 Aug 2011, Laurent Pinchart wrote:
[snip]
> > @@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct i2c_client
> > *client) }
> >
> > /* Find a data format by a pixel code in an array */
> > -static const struct ov5642_datafmt
> > - *ov5642_find_datafmt(enum v4l2_mbus_pixelcode code)
> > +static const struct ov5642_datafmt *ov5642_find_datafmt(enum
> > v4l2_mbus_pixelcode code) {
>
> checkpatch.pl won't be happy.
Since the lift of the hard 80-char limit, I often find lines of 86 characters
more acceptable than their split versions.
[snip]
> > @@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev *sd,
> >
> > ov5642_try_fmt(sd, mf);
> >
> > + priv->out_size.width= mf->width;
> > + priv->out_size.height = mf->height;
>
> It looks like to me (but I may be wrong) that you achieve different
> resolutions using cropping, not scaling. If that's correct you should
> implement s_crop support and refuse changing the resolution through s_fmt.
As the patch explains (I think) on several occasions, currently only the
1:1 scale is supported, and it was our deliberate choice to implement this
using the scaling API
> > @@ -793,10 +868,12 @@ static int ov5642_g_fmt(struct v4l2_subdev *sd,
> >
> > mf->code= fmt->code;
> > mf->colorspace = fmt->colorspace;
> > - mf->width = OV5642_WIDTH;
> > - mf->height = OV5642_HEIGHT;
> > + mf->width = priv->out_size.width;
> > + mf->height = priv->out_size.height;
> > mf->field = V4L2_FIELD_NONE;
> >
> > + dev_dbg(sd->v4l2_dev->dev, "%s return width: %u heigth: %u\n", __func__,
> > + mf->width, mf->height);
>
> Isn't that a bit too verbose ? Printing the format in a debug message in the
> s_fmt handler is useful, but maybe doing it in g_fmt is a bit too much.
This is a dev_dbg()... Personally, as long as they don't clutter the source
code needlessly, compile without warnings and have their typos fixed (;-))
I don't have problems with an odd instance, even if I don't really perceive
its output as particularly useful:-)
[snip]
> > + dev_dbg(sd->v4l2_dev->dev, "%s crop width: %u heigth: %u\n", __func__,
> > + rect->width, rect->height);
>
> Same comment as for g_fmt.
same reply:-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] media: vb2: change queue initialization order
Hi Marek On Mon, 29 Aug 2011, Marek Szyprowski wrote: > This patch changes the order of operations during stream on call. Now the > buffers are first queued to the driver and then the start_streaming method > is called. > > This resolves the most common case when the driver needs to know buffer > addresses to enable dma engine and start streaming. Additional parameter > to start_streaming method have been added to simplify drivers code. The > driver are now obliged to check if the number of queued buffers is high > enough to enable hardware streaming. If not - it can return an error. In > such case all the buffers that have been pre-queued are invalidated. > > This patch also updates all videobuf2 clients to work properly with the > changed order of operations. > > Signed-off-by: Marek Szyprowski > Signed-off-by: Kyungmin Park > CC: Pawel Osciak > CC: Guennadi Liakhovetski > CC: Hans Verkuil > CC: Tomasz Stanislawski > CC: Sylwester Nawrocki > CC: Kamil Debski > CC: Jonathan Corbet > CC: Josh Wu > CC: Hans de Goede > CC: Paul Mundt > --- > > Hello, > > This is yet another version of the patch that introduces significant > changes in the vb2 streamon operation. I've decided to remove the > additional parameter to buf_queue callback and added a few cleanups here > and there. This patch also includes an update for all vb2 clients. Just for the record: These are not all vb2 clients. A simple grep for something like vb2_ops gives you also drivers/media/video/mx3_camera.c drivers/media/video/sh_mobile_ceu_camera.c Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 RESEND] media: vb2: change queue initialization order
This patch changes the order of operations during stream on call. Now the
buffers are first queued to the driver and then the start_streaming method
is called.
This resolves the most common case when the driver needs to know buffer
addresses to enable dma engine and start streaming. Additional parameter
to start_streaming method have been added to simplify drivers code. The
driver are now obliged to check if the number of queued buffers is high
enough to enable hardware streaming. If not - it can return an error. In
such case all the buffers that have been pre-queued are invalidated.
This patch also updates all videobuf2 clients to work properly with the
changed order of operations.
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
CC: Pawel Osciak
CC: Guennadi Liakhovetski
CC: Hans Verkuil
CC: Tomasz Stanislawski
CC: Sylwester Nawrocki
CC: Kamil Debski
CC: Jonathan Corbet
CC: Josh Wu
CC: Hans de Goede
CC: Paul Mundt
---
Hello,
This is yet another version of the patch that introduces significant
changes in the vb2 streamon operation. I've decided to remove the
additional parameter to buf_queue callback and added a few cleanups here
and there. This patch also includes an update for all vb2 clients.
Please check if my change didn't break anything.
(I'm sorry for spamming, but previous version had wrong code for
atmel-isi driver).
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
drivers/media/video/atmel-isi.c | 20 --
drivers/media/video/marvell-ccic/mcam-core.c |6 +-
drivers/media/video/pwc/pwc-if.c |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 65 +++---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|2 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c|2 +-
drivers/media/video/s5p-tv/mixer.h |2 -
drivers/media/video/s5p-tv/mixer_video.c | 22 +++---
drivers/media/video/videobuf2-core.c | 97 --
drivers/media/video/vivi.c |2 +-
include/media/videobuf2-core.h | 17 -
11 files changed, 131 insertions(+), 106 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 7e1d789..774715d 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -404,12 +404,13 @@ static void buffer_queue(struct vb2_buffer *vb)
if (isi->active == NULL) {
isi->active = buf;
- start_dma(isi, buf);
+ if (vb2_is_streaming(vb->vb2_queue))
+ start_dma(isi, buf);
}
spin_unlock_irqrestore(&isi->lock, flags);
}
-static int start_streaming(struct vb2_queue *vq)
+static int start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
@@ -431,17 +432,26 @@ static int start_streaming(struct vb2_queue *vq)
ret = wait_event_interruptible(isi->vsync_wq,
isi->state != ISI_STATE_IDLE);
if (ret)
- return ret;
+ goto err;
- if (isi->state != ISI_STATE_READY)
- return -EIO;
+ if (isi->state != ISI_STATE_READY) {
+ ret = -EIO;
+ goto err;
+ }
spin_lock_irq(&isi->lock);
isi->state = ISI_STATE_WAIT_SOF;
isi_writel(isi, ISI_INTDIS, ISI_SR_VSYNC);
+ if (count)
+ start_dma(isi, isi->active);
spin_unlock_irq(&isi->lock);
return 0;
+err:
+ isi->active = NULL;
+ isi->sequence = 0;
+ INIT_LIST_HEAD(&isi->video_buffer_list);
+ return ret;
}
/* abort streaming and wait for last buffer */
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 7abe503..1141b97 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -940,12 +940,14 @@ static void mcam_vb_wait_finish(struct vb2_queue *vq)
/*
* These need to be called with the mutex held from vb2
*/
-static int mcam_vb_start_streaming(struct vb2_queue *vq)
+static int mcam_vb_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct mcam_camera *cam = vb2_get_drv_priv(vq);
- if (cam->state != S_IDLE)
+ if (cam->state != S_IDLE) {
+ INIT_LIST_HEAD(&cam->buffers);
return -EINVAL;
+ }
cam->sequence = 0;
/*
* Videobuf2 sneakily hoards all the buffers and won't
diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c
index a7e4f56..360be22 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -816,7 +816,7 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(&pdev->queued_bufs_lock, flags);
}
-s
Re: [PATCH 4/5] [media] v4l: fix copying ioctl results on failure
On 08/29/2011 10:56 AM, Laurent Pinchart wrote:
Hi Tomasz,
On Monday 29 August 2011 10:01:58 Tomasz Stanislawski wrote:
On 08/26/2011 05:09 PM, Laurent Pinchart wrote:
On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote:
This patch fix the handling of data passed to V4L2 ioctls. The content
of the structures is not copied if the ioctl fails. It blocks ability
to obtain any information about occurred error other then errno code.
This patch fix this issue.
Does the V4L2 spec say anything on this topic ? We might have
applications that rely on the ioctl argument structure not being touched
when a failure occurs.
Ups.. I missed something. It looks that modifying ioctl content is
illegal if ioctl fails. The spec says:
"When an ioctl that takes an output or read/write parameter fails, the
parameter remains unmodified." (v4l2 ioctl section)
However, there is probably a bug already present in V4L2 framework.
There are some ioctls that takes a pointer to an array as a field in the
argument struct.
The examples are all VIDIOC_*_EXT_CTRLS and VIDIOC_{QUERY/DQ/Q}_BUF family.
The content of such an auxiliary arays is copied even if ioctl fails.
Please take a look to video_usercopy function in v4l2-ioctl.c. Therefore
I think that the spec is already violated. What is your opinion about
this problem?
I think it was a bad idea to state that a parameter remains unmodified when
the ioctl fails in the first place. I'm fine with not following that for new
ioctls, but applications might rely on it for existing ioctls.
Now back to selection case.
This patch was added as proposition of fix to VIDIOC_S_SELECTION, to
return the best-hit rectangle if constraints could not be satisfied. The
ioctl return -ERANGE in this case. Using those return values the
application gets some feedback on loosing constraints.
Shouldn't that always be the case ? :-) VIDIOC_S_SELECTION should adjust the
rectangle up or down depending on the constraints and always return the best
match without any error.
ok.. but what to do if constraints could not be satisfied?
The configuration should not be applied to the hardware in such a case,
because it is not what the application desired.
Therefore the ioctl must fail ... somehow.
If the ioctl always succeed then the constraint flags becomes actually
the hints.
We may need TRY_SELECTION to test rectangles without applying it.
I thought that returning the best-hit rectangle by S_SELECTION might be
useful because
it gives the application some feedback on what the driver would accept.
I could remove rectangle returning from the spec and s5p-tv code for now.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] media: vb2: change queue initialization order
This patch changes the order of operations during stream on call. Now the
buffers are first queued to the driver and then the start_streaming method
is called.
This resolves the most common case when the driver needs to know buffer
addresses to enable dma engine and start streaming. Additional parameter
to start_streaming method have been added to simplify drivers code. The
driver are now obliged to check if the number of queued buffers is high
enough to enable hardware streaming. If not - it can return an error. In
such case all the buffers that have been pre-queued are invalidated.
This patch also updates all videobuf2 clients to work properly with the
changed order of operations.
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
CC: Pawel Osciak
CC: Guennadi Liakhovetski
CC: Hans Verkuil
CC: Tomasz Stanislawski
CC: Sylwester Nawrocki
CC: Kamil Debski
CC: Jonathan Corbet
CC: Josh Wu
CC: Hans de Goede
CC: Paul Mundt
---
Hello,
This is yet another version of the patch that introduces significant
changes in the vb2 streamon operation. I've decided to remove the
additional parameter to buf_queue callback and added a few cleanups here
and there. This patch also includes an update for all vb2 clients.
Please check if my change didn't break anything.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
drivers/media/video/atmel-isi.c | 20 --
drivers/media/video/marvell-ccic/mcam-core.c |6 +-
drivers/media/video/pwc/pwc-if.c |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 65 +++---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|2 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c|2 +-
drivers/media/video/s5p-tv/mixer.h |2 -
drivers/media/video/s5p-tv/mixer_video.c | 22 +++---
drivers/media/video/videobuf2-core.c | 97 --
drivers/media/video/vivi.c |2 +-
include/media/videobuf2-core.h | 17 -
11 files changed, 131 insertions(+), 106 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 7e1d789..4f4ee64 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -404,12 +404,13 @@ static void buffer_queue(struct vb2_buffer *vb)
if (isi->active == NULL) {
isi->active = buf;
- start_dma(isi, buf);
+ if (streaming)
+ start_dma(isi, buf);
}
spin_unlock_irqrestore(&isi->lock, flags);
}
-static int start_streaming(struct vb2_queue *vq)
+static int start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
@@ -431,17 +432,26 @@ static int start_streaming(struct vb2_queue *vq)
ret = wait_event_interruptible(isi->vsync_wq,
isi->state != ISI_STATE_IDLE);
if (ret)
- return ret;
+ goto err;
- if (isi->state != ISI_STATE_READY)
- return -EIO;
+ if (isi->state != ISI_STATE_READY) {
+ ret = -EIO;
+ goto err;
+ }
spin_lock_irq(&isi->lock);
isi->state = ISI_STATE_WAIT_SOF;
isi_writel(isi, ISI_INTDIS, ISI_SR_VSYNC);
+ if (count)
+ start_dma(isi, isi->active);
spin_unlock_irq(&isi->lock);
return 0;
+err:
+ isi->active = NULL;
+ isi->sequence = 0;
+ INIT_LIST_HEAD(&isi->video_buffer_list);
+ return ret;
}
/* abort streaming and wait for last buffer */
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 7abe503..1141b97 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -940,12 +940,14 @@ static void mcam_vb_wait_finish(struct vb2_queue *vq)
/*
* These need to be called with the mutex held from vb2
*/
-static int mcam_vb_start_streaming(struct vb2_queue *vq)
+static int mcam_vb_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct mcam_camera *cam = vb2_get_drv_priv(vq);
- if (cam->state != S_IDLE)
+ if (cam->state != S_IDLE) {
+ INIT_LIST_HEAD(&cam->buffers);
return -EINVAL;
+ }
cam->sequence = 0;
/*
* Videobuf2 sneakily hoards all the buffers and won't
diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c
index a7e4f56..360be22 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -816,7 +816,7 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(&pdev->queued_bufs_lock, flags);
}
-static int start_streaming(struct vb2_queue *vq)
+static int start_streaming(struct vb2_queue *vq, unsigned
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
On Mon, Aug 29, 2011 at 13:08, Laurent Pinchart
wrote:
> On Monday 29 August 2011 13:04:15 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart wrote:
>> > On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote:
>> >> On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote:
>> [...]
>>
>> > If my understanding is now correct, a V4L2 planar YUV type where Y, U and
>> > V components are stored in separate byte-oriented planes, with each
>> > plane storing Y, U or V components packed (such as
>> > http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html),
>> > would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would be
>> > true for an RGB format where each component is stored in a separate
>> > plane with each plane sotring R, G or B packed.
>>
>> Indeed. Currently this cannot be represented.
>
> Good, at least I now understand the situation :-)
>
>> For ideas from the past, see e.g.
>> http://comments.gmane.org/gmane.linux.fbdev.devel/10951.
>>
>> > If the above is correct, what FB_TYPE_* should a driver report when using
>> > FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P
>> > (http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html)
>> > or V4L2_PIX_FMT_NV12
>> > (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ?
>>
>> We need new types for those. Or always use FOURCC for them.
>
> My proposal currently defined FB_VISUAL_FOURCC. What about adding
> FB_TYPE_FOURCC as well ?
That may make sense.
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy way,
- But what with modes that can be represented? Legacy software cannot
handle FB_{TYPE,VISUAL}_FOURCC.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert, On Monday 29 August 2011 13:04:15 Geert Uytterhoeven wrote: > On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart wrote: > > On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote: > >> On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote: > [...] > > > If my understanding is now correct, a V4L2 planar YUV type where Y, U and > > V components are stored in separate byte-oriented planes, with each > > plane storing Y, U or V components packed (such as > > http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html), > > would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would be > > true for an RGB format where each component is stored in a separate > > plane with each plane sotring R, G or B packed. > > Indeed. Currently this cannot be represented. Good, at least I now understand the situation :-) > For ideas from the past, see e.g. > http://comments.gmane.org/gmane.linux.fbdev.devel/10951. > > > If the above is correct, what FB_TYPE_* should a driver report when using > > FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P > > (http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html) > > or V4L2_PIX_FMT_NV12 > > (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ? > > We need new types for those. Or always use FOURCC for them. My proposal currently defined FB_VISUAL_FOURCC. What about adding FB_TYPE_FOURCC as well ? -- 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart
wrote:
> On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote:
>> On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote:
[...]
> If my understanding is now correct, a V4L2 planar YUV type where Y, U and V
> components are stored in separate byte-oriented planes, with each plane
> storing Y, U or V components packed (such as http://linuxtv.org/downloads/v4l-
> dvb-apis/V4L2-PIX-FMT-YUV422P.html), would be of neither FB_TYPE_PLANES nor
> FB_TYPE_PACKED. The same would be true for an RGB format where each component
> is stored in a separate plane with each plane sotring R, G or B packed.
Indeed. Currently this cannot be represented.
For ideas from the past, see e.g.
http://comments.gmane.org/gmane.linux.fbdev.devel/10951.
> If the above is correct, what FB_TYPE_* should a driver report when using
> FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P (http://linuxtv.org/downloads/v4l-
> dvb-apis/V4L2-PIX-FMT-YUV422P.html) or V4L2_PIX_FMT_NV12
> (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ?
We need new types for those. Or always use FOURCC for them.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: Getting started with OMAP3 ISP
Hi Gary, On Thursday 25 August 2011 18:07:38 Gary Thomas wrote: > Background: I have working video capture drivers based on the > TI PSP codebase from 2.6.32. In particular, I managed to get > a driver for the TVP5150 (analogue BT656) working with that kernel. > > Now I need to update to Linux 3.0, so I'm trying to get a driver > working with the rewritten ISP code. Sadly, I'm having a hard > time with this - probably just missing something basic. > > I've tried to clone the TVP514x driver which says that it works > with the OMAP3 ISP code. I've updated it to use my decoder device, > but I can't even seem to get into that code from user land. > > Here are the problems I've had so far: >* udev doesn't create any video devices although they have been > registered. I see a full set in /sys/class/video4linux > # ls /sys/class/video4linux/ > v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4 > v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5 > v4l-subdev2 v4l-subdev5 video0 video3 video6 It looks like a udev issue. I don't think that's related to the kernel drivers. > Indeed, if I create /dev/videoX by hand, I can get somewhere, but > I don't really understand how this is supposed to work. e.g. ># v4l2-dbg --info /dev/video3 >Driver info: >Driver name : ispvideo >Card type : OMAP3 ISP CCP2 input >Bus info : media >Driver version: 1 >Capabilities : 0x0402 >Video Output >Streaming > >* If I try to grab video, the ISP layer gets a ton of warnings, but > I never see it call down into my driver, e.g. to check the current > format, etc. I have some of my own code from before which fails > miserably (not a big surprise given the hack level of those programs). > I tried something off-the-shelf which also fails pretty bad: ># ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2 > junk.mp4 > > I've read through Documentation/video4linux/omap3isp.txt without learning > much about what might be wrong. > > Can someone give me some ideas/guidance, please? In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video. Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device. Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor: ./media-ctl -r -l '"mt9t001 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":2->"OMAP3 ISP preview":0[1], "OMAP3 ISP preview":1->"OMAP3 ISP resizer":0[1], "OMAP3 ISP resizer":1->"OMAP3 ISP resizer output":0[1]' ./media-ctl -f '"mt9t001 3-005d":0[SGRBG10 1024x768], "OMAP3 ISP CCDC":2[SGRBG10 1024x767], "OMAP3 ISP preview":1[YUYV 1006x759], "OMAP3 ISP resizer":1[YUYV 800x600]' After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline. -- 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: omap3isp and tvp5150 hangs
Hi Enrico,
On Friday 26 August 2011 17:02:59 Enrico wrote:
> On Fri, Aug 26, 2011 at 12:52 PM, Gary Thomas wrote:
> > On 2011-08-26 04:42, Enrico wrote:
> >> Hi,
> >>
> >> i need some help to debug a kernel hang on an igep board (+ expansion)
> >> when using omap3-isp and tvp5150 video capture. Kernel version is
> >> mainline 3.0.1
> >
> > I found that this driver is not compatible with the [new] v4l2_subdev
> > setup. In particular, it does not define any "pads" and the call to
> > media_entity_create_link()
> > in omap3isp/isp.c:1803 fires a BUG_ON() for this condition.
>
> So basically what is needed is to implement pad functions and do
> something like this:
>
> static struct v4l2_subdev_pad_ops mt9v032_subdev_pad_ops = {
> .enum_mbus_code = mt9v032_enum_mbus_code,
> .enum_frame_size = mt9v032_enum_frame_size,
> .get_fmt = mt9v032_get_format,
> .set_fmt = mt9v032_set_format,
> .get_crop = mt9v032_get_crop,
> .set_crop = mt9v032_set_crop,
> };
>
> and add media init/cleanup functions? Can someone confirm this? Is
> someone already working on this?
That's more or less it, yes. I'm not aware of anyone working on this.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert, On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote: > On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote: > > On Monday 29 August 2011 10:13:07 Geert Uytterhoeven wrote: > >> On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart wrote: > > [snip] > > > >> > +- FB_TYPE_PACKED_PIXELS > >> > + > >> > +Color components (usually RGB or YUV) are packed together into > >> > macropixels +that are stored in a single plane. The exact color > >> > components layout is +described in a visual-dependent way. > >> > + > >> > +Frame buffer visuals that don't use multiple color components per > >> > pixel +(such as monochrome and pseudo-color visuals) are reported as > >> > packed frame +buffer types, even though they don't stricly speaking > >> > pack color components +into macropixels. > >> > >> That's because the "packing" is not about the color components, but > >> about the bits that represent a single pixel. > >> > >> I.e. the bits that make up the pixel (the macropixel) are stored next > >> to each other > >> in memory. > > > > OK, I've modified that last sentence to read > > > > "Frame buffer visuals that don't use multiple color components per pixel > > (such as monochrome and pseudo-color visuals) are also reported as > > packed frame buffer types, as the bits that make up individual pixels > > are packed next to each other in memory." > > Still not correct, as you don't grasp the concept of e.g. bitplanes > yet (see below). > The visual doesn't have anything to do with how the macropixels are stored > in memory. > > >> > +- FB_TYPE_PLANES > >> > + > >> > +Color components are stored in separate planes. Planes are located > >> > +contiguously in memory. > >> > >> The bits that make up a pixel are stored in separate planes. Planes are > >> located contiguously in memory. > > > > I'm not sure to agree with this. You make it sounds like FB_TYPE_PLANES > > stores each bit in a different plane. Is that really the case ? > > Yes. > > First you store all "first" (fbdev does lack a way to specify little > or big endian here) > bits of each pixel in memory, contiguously. Then the second bit of > each pixel, and so on. > > For 8 pixels (A - H) with 4 bits per pixel (0 - 3) (i.e. the first pixel is > [A0 A1 A2 A3]), that would be like: > > A0 B0 C0 D0 E0 F0 G0 H0 A1 B1 C1 D1 E1 F1 G1 H1 A2 B2 C2 D2 E2 F2 G2 H2 > A3 B3 C3 D3 E3 F3 G3 H3 > > http://en.wikipedia.org/wiki/Bit_plane > http://en.wikipedia.org/wiki/Planar_(computer_graphics) > http://en.wikipedia.org/wiki/Color_depth Thank you. That's clearer now. Planar formats in V4L2 are different, hence my initial confusion. If my understanding is now correct, a V4L2 planar YUV type where Y, U and V components are stored in separate byte-oriented planes, with each plane storing Y, U or V components packed (such as http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html), would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would be true for an RGB format where each component is stored in a separate plane with each plane sotring R, G or B packed. If the above is correct, what FB_TYPE_* should a driver report when using FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P (http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html) or V4L2_PIX_FMT_NV12 (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ? > >> - FB_TYPE_INTERLEAVED_PLANES > >> > >> The bits that make up a pixel are stored in separate planes. Planes > >> are interleaved. > >> The interleave factor (the distance in bytes between the planes in > >> memory) is stored in the type_aux field. > > > > That's a bit unclear to me. How are they interleaved ? > > Instead of storing the same bits of all pixels contiguously into memory, > they are interleaved. Typically this is done per line (type_aux is the > length of a line in bytes), > or per word (Atari uses 2 bytes interleaving. > > E.g. for a 320 x 200 display, with FB_TYPE_PLANES, you would store 320 x > 200 = 64000 first bits, followed 64000 second bits, and so on. > > With FB_TYPE_INTERLEAVED_PLANES and type_aux = 320 / 8 = 40, > you store the first line of the screen as 320 first bits, followed by > 320 second bits, and so on. > Then the next line, as 320 first bits, followed by 320 second bits, and so > on... > > Hence the bits that make up a pixel are spread across memory. It was > useful in the days > computers couldn't show many colors, and allows things like 5 or 6 > bits per pixels. > > >> > +- FB_VISUAL_MONO01 > >> > + > >> > +Pixels are black or white and stored on one bit. A bit set to 1 > >> > represents a +black pixel and a bit set to 0 a white pixel. Pixels are > >> > packed together in +bytes with 8 pixels per byte. > >> > >> Actually we do have drivers that use 8 bits per pixel for a monochrome > >> visual. Hence: > >> > >> "Pixels are black or white. A black pixel is represented by all > >> (typically one) bits set to ones, a white pixel by all bits set to > >> ze
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent, On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote: > On Monday 29 August 2011 10:13:07 Geert Uytterhoeven wrote: >> On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart wrote: > > [snip] > >> > +- FB_TYPE_PACKED_PIXELS >> > + >> > +Color components (usually RGB or YUV) are packed together into >> > macropixels +that are stored in a single plane. The exact color >> > components layout is +described in a visual-dependent way. >> > + >> > +Frame buffer visuals that don't use multiple color components per pixel >> > +(such as monochrome and pseudo-color visuals) are reported as packed >> > frame +buffer types, even though they don't stricly speaking pack color >> > components +into macropixels. >> >> That's because the "packing" is not about the color components, but about >> the bits that represent a single pixel. >> >> I.e. the bits that make up the pixel (the macropixel) are stored next >> to each other >> in memory. > > OK, I've modified that last sentence to read > > "Frame buffer visuals that don't use multiple color components per pixel (such > as monochrome and pseudo-color visuals) are also reported as packed frame > buffer types, as the bits that make up individual pixels are packed next to > each other in memory." Still not correct, as you don't grasp the concept of e.g. bitplanes yet (see below). The visual doesn't have anything to do with how the macropixels are stored in memory. >> > +- FB_TYPE_PLANES >> > + >> > +Color components are stored in separate planes. Planes are located >> > +contiguously in memory. >> >> The bits that make up a pixel are stored in separate planes. Planes are >> located contiguously in memory. > > I'm not sure to agree with this. You make it sounds like FB_TYPE_PLANES stores > each bit in a different plane. Is that really the case ? Yes. First you store all "first" (fbdev does lack a way to specify little or big endian here) bits of each pixel in memory, contiguously. Then the second bit of each pixel, and so on. For 8 pixels (A - H) with 4 bits per pixel (0 - 3) (i.e. the first pixel is [A0 A1 A2 A3]), that would be like: A0 B0 C0 D0 E0 F0 G0 H0 A1 B1 C1 D1 E1 F1 G1 H1 A2 B2 C2 D2 E2 F2 G2 H2 A3 B3 C3 D3 E3 F3 G3 H3 http://en.wikipedia.org/wiki/Bit_plane http://en.wikipedia.org/wiki/Planar_(computer_graphics) http://en.wikipedia.org/wiki/Color_depth >> - FB_TYPE_INTERLEAVED_PLANES >> >> The bits that make up a pixel are stored in separate planes. Planes >> are interleaved. >> The interleave factor (the distance in bytes between the planes in >> memory) is stored in the type_aux field. > > That's a bit unclear to me. How are they interleaved ? Instead of storing the same bits of all pixels contiguously into memory, they are interleaved. Typically this is done per line (type_aux is the length of a line in bytes), or per word (Atari uses 2 bytes interleaving. E.g. for a 320 x 200 display, with FB_TYPE_PLANES, you would store 320 x 200 = 64000 first bits, followed 64000 second bits, and so on. With FB_TYPE_INTERLEAVED_PLANES and type_aux = 320 / 8 = 40, you store the first line of the screen as 320 first bits, followed by 320 second bits, and so on. Then the next line, as 320 first bits, followed by 320 second bits, and so on... Hence the bits that make up a pixel are spread across memory. It was useful in the days computers couldn't show many colors, and allows things like 5 or 6 bits per pixels. >> > +- FB_VISUAL_MONO01 >> > + >> > +Pixels are black or white and stored on one bit. A bit set to 1 >> > represents a +black pixel and a bit set to 0 a white pixel. Pixels are >> > packed together in +bytes with 8 pixels per byte. >> >> Actually we do have drivers that use 8 bits per pixel for a monochrome >> visual. Hence: >> >> "Pixels are black or white. A black pixel is represented by all >> (typically one) bits set to ones, a white pixel by all bits set to zeroes." > > OK. I've rephrased it as > > "Pixels are black or white and stored on a number of bits (typically one) > specified by the variable screen information bpp field. > > Black pixels are represented by all bits set to 1 and white pixels by all bits > set to 0. When the number of bits per pixel is smaller than 8, several pixels > are packed together in a byte." OK. >> > +FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only. >> >> ... so this may also not be true (but it is for all current drivers, IIRC). >> There's a strict orthogonality between type (how is a pixel stored in >> memory) and visual (how the bits that represent the pixel are interpreted >> and converted to a color value). > > What about > > "FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only." ? stifb.c seems to use FB_TYPE_PLANES, but it uses bits_per_pixel is 1, so FB_TYPE_PACKED_PIXELS, FB_TYPE_PLANES, and FB_TYPE_INTERLEAVED_PLANES all degenerate to the same case anyway. >> > +- FB_VISUAL_TRUECOLOR >> > + >> > +Pixels are broken into red, green and blue components, and each >> > component +indexe
Re: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, On Friday 26 August 2011 19:32:30 Mauro Carvalho Chehab wrote: > Em 26-08-2011 12:29, Hans Verkuil escreveu: > > On Friday, August 26, 2011 17:09:02 Mauro Carvalho Chehab wrote: > >> Em 26-08-2011 11:16, Hans Verkuil escreveu: > >>> On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: > On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: > > Em 24-08-2011 19:29, Sakari Ailus escreveu: > [snip] > > >> The question I still have on this is that how should the user know > >> which video node to access on an embedded system with a camera: the > >> OMAP 3 ISP, for example, contains some eight video nodes which have > >> different ISP blocks connected to them. Likely two of these nodes > >> are useful for a general purpose application based on which image > >> format it requests. It would make sense to provide generic > >> applications information only on those devices they may > >> meaningfully use. > > > > IMO, we should create a namespace device mapping for video devices. > > What I > > > > mean is that we should keep the "raw" V4L2 devices as: > > /dev/video?? > > > > But also recommend the creation of a new userspace map, like: > > /dev/webcam?? > > /dev/tv?? > > ... > > > > with is an alias for the actual device. > > > > Something similar to dvd/cdrom aliases that already happen on most > > distros: > > > > lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom -> sr0 > > lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw -> sr0 > > lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd -> sr0 > > lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw -> sr0 > > I've been toying with a similar idea. libv4l currently wraps > /dev/video* device nodes and assumes a 1:1 relationship between a > video device node and a video device. Should this assumption be > somehow removed, replaced by a video device concept that wouldn't be > tied to a single video device node ? > >>> > >>> Just as background information: the original idea was always that all > >>> v4l drivers would have a MC and that libv4l would use the information > >>> contained there as a helper (such as deciding which nodes would be the > >>> 'default' nodes for generic applications). > >> > >> This is something that libv4l won't do: it is up to the userspace > >> application to choose the device node to open. Ok, libv4l can have > >> helper APIs for that, like the one I wrote, but even adding MC support > >> on it may not solve the issues. > >> > >>> Since there is only one MC device node for each piece of video hardware > >>> that would make it much easier to discover what hardware there is and > >>> what video nodes to use. > >>> > >>> I always liked that idea, although I know Mauro is opposed to having a > >>> MC for all v4l drivers. > >> > >> It doesn't make sense to add MC for all V4L drivers. Not all devices are > >> like ivtv with lots of device drivers. In a matter of fact, most > >> supported devices create just one video node. Adding MC support for > >> those devices will just increase the drivers complexity without _any_ > >> reason, as those devices are fully configurable using the existing > >> ioctl's. > > > > It's for consistency so applications know what to expect. > > I've already said it before: We won't be implementing an API for a device > just for "consistency" without any real reason. We have a real reason: providing a single API through which applications can enumerate devices and retrieve information such as device capabilities and relationships between devices. > > For all the simple drivers you'd just need some simple core support to add > > a MC. What I always thought would be handy is for applications to just > > iterate over all MCs and show which video/dvb/audio hardware the user has > > in its system. > > MC doesn't work for audio yet, *yet* > as snd-usb-audio doesn't use it. So, it will fail for a large amount of > devices whose audio is implemented using standard USB Audio Class. Adding MC > support for it doesn't sound trivial, and won't offer any gain over the > sysfs equivalent. > > >> Also, as I said before, and implemented at xawtv and at a v4l-utils > >> library, the code may use sysfs for simpler devices. It shouldn't be > >> hard to implement a mc aware code there, although I don't think that MC > >> API is useful to discover what nodes are meant to be used for TV, > >> encoder, decoder, webcams, etc. The only type information it currently > >> provides is: > >> > >> #define MEDIA_ENT_T_DEVNODE_V4L(MEDIA_ENT_T_DEVNODE + 1) > >> #define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2) > >> #define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) > >> #define MEDIA_ENT_T_DEVNODE_DVB(MEDIA_ENT_T_DEVNODE + 4) > > > > That's
Re: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, On Friday 26 August 2011 17:09:02 Mauro Carvalho Chehab wrote: > Em 26-08-2011 11:16, Hans Verkuil escreveu: > > On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: > >> On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: > >>> Em 24-08-2011 19:29, Sakari Ailus escreveu: > >> [snip] > >> > The question I still have on this is that how should the user know > which video node to access on an embedded system with a camera: the > OMAP 3 ISP, for example, contains some eight video nodes which have > different ISP blocks connected to them. Likely two of these nodes are > useful for a general purpose application based on which image format > it requests. It would make sense to provide generic applications > information only on those devices they may meaningfully use. > >>> > >>> IMO, we should create a namespace device mapping for video devices. > >>> What I > >>> > >>> mean is that we should keep the "raw" V4L2 devices as: > >>> /dev/video?? > >>> > >>> But also recommend the creation of a new userspace map, like: > >>> /dev/webcam?? > >>> /dev/tv?? > >>> ... > >>> > >>> with is an alias for the actual device. > >>> > >>> Something similar to dvd/cdrom aliases that already happen on most > >>> distros: > >>> > >>> lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom -> sr0 > >>> lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw -> sr0 > >>> lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd -> sr0 > >>> lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw -> sr0 > >> > >> I've been toying with a similar idea. libv4l currently wraps /dev/video* > >> device nodes and assumes a 1:1 relationship between a video device node > >> and a video device. Should this assumption be somehow removed, replaced > >> by a video device concept that wouldn't be tied to a single video > >> device node ? > > > > Just as background information: the original idea was always that all v4l > > drivers would have a MC and that libv4l would use the information > > contained there as a helper (such as deciding which nodes would be the > > 'default' nodes for generic applications). > > This is something that libv4l won't do: it is up to the userspace > application to choose the device node to open. I think this is one of our fundamental issues. Most applications are actually not interested in video nodes at all. What they want is a video device. Shouldn't libv4l should allow applications to enumerate video devices (as opposed to video nodes) and open them without caring about video nodes ? > Ok, libv4l can have helper APIs for that, like the one I wrote, but even > adding MC support on it may not solve the issues. > > > Since there is only one MC device node for each piece of video hardware > > that would make it much easier to discover what hardware there is and > > what video nodes to use. > > > > I always liked that idea, although I know Mauro is opposed to having a MC > > for all v4l drivers. > > It doesn't make sense to add MC for all V4L drivers. Not all devices are > like ivtv with lots of device drivers. In a matter of fact, most supported > devices create just one video node. Adding MC support for those devices > will just increase the drivers complexity without _any_ reason, as those > devices are fully configurable using the existing ioctl's. Hans' proposal is to handle this in the V4L2 core for most drivers, so those drivers won't become more complex as they won't be modified at all. The MC API for those devices will only offer read-only enumeration, not link configuration. > Also, as I said before, and implemented at xawtv and at a v4l-utils library, > the code may use sysfs for simpler devices. It shouldn't be hard to > implement a mc aware code there, although I don't think that MC API is > useful to discover what nodes are meant to be used for TV, encoder, decoder, > webcams, etc. The only type information it currently provides is: > > #define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1) > #define MEDIA_ENT_T_DEVNODE_FB(MEDIA_ENT_T_DEVNODE + 2) > #define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) > #define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE + 4) > > So, a MC aware application also needs to be a hardware-dependent > application, as it will need to use something else, like the media entity > name, to discover for what purpose a media node is meant to be used. As Hans pointed out, this is because we haven't implemented more detailed information *yet*. It has always been a goal to provide more details through the MC API. > > While I am not opposed to creating such userspace maps I also think it is > > a bit of a poor-man's solution. > > The creation of per-type devices is part of the current API: radio > and vbi nodes are examples of that (except that they aren't aliases, but > real devices, but the idea is the same: different names for differ
[GIT PULL for v3.1-rc] OMAP_VOUT: Fix build failure
Hi Mauro, I missed this patch for last rc release, can you please queue up for next rc. The following changes since commit 55f9c40ff632d03c527d6a6ceddcda0a224587a6: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/sparc are available in the git repository at: git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git for-linux-media-rc Archit Taneja (1): OMAP_VOUT: Fix build break caused by update_mode removal in DSS2 drivers/media/video/omap/omap_vout.c | 13 - 1 files changed, 0 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] [media] v4l: fix copying ioctl results on failure
Hi Tomasz,
On Monday 29 August 2011 10:01:58 Tomasz Stanislawski wrote:
> On 08/26/2011 05:09 PM, Laurent Pinchart wrote:
> > On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote:
> >> This patch fix the handling of data passed to V4L2 ioctls. The content
> >> of the structures is not copied if the ioctl fails. It blocks ability
> >> to obtain any information about occurred error other then errno code.
> >> This patch fix this issue.
> >
> > Does the V4L2 spec say anything on this topic ? We might have
> > applications that rely on the ioctl argument structure not being touched
> > when a failure occurs.
>
> Ups.. I missed something. It looks that modifying ioctl content is
> illegal if ioctl fails. The spec says:
> "When an ioctl that takes an output or read/write parameter fails, the
> parameter remains unmodified." (v4l2 ioctl section)
> However, there is probably a bug already present in V4L2 framework.
> There are some ioctls that takes a pointer to an array as a field in the
> argument struct.
> The examples are all VIDIOC_*_EXT_CTRLS and VIDIOC_{QUERY/DQ/Q}_BUF family.
> The content of such an auxiliary arays is copied even if ioctl fails.
> Please take a look to video_usercopy function in v4l2-ioctl.c. Therefore
> I think that the spec is already violated. What is your opinion about
> this problem?
I think it was a bad idea to state that a parameter remains unmodified when
the ioctl fails in the first place. I'm fine with not following that for new
ioctls, but applications might rely on it for existing ioctls.
> Now back to selection case.
> This patch was added as proposition of fix to VIDIOC_S_SELECTION, to
> return the best-hit rectangle if constraints could not be satisfied. The
> ioctl return -ERANGE in this case. Using those return values the
> application gets some feedback on loosing constraints.
Shouldn't that always be the case ? :-) VIDIOC_S_SELECTION should adjust the
rectangle up or down depending on the constraints and always return the best
match without any error.
> I could remove rectangle returning from the spec and s5p-tv code for now.
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert, Thanks for the review. On Monday 29 August 2011 10:13:07 Geert Uytterhoeven wrote: > On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart wrote: [snip] > > +- FB_TYPE_PACKED_PIXELS > > + > > +Color components (usually RGB or YUV) are packed together into > > macropixels +that are stored in a single plane. The exact color > > components layout is +described in a visual-dependent way. > > + > > +Frame buffer visuals that don't use multiple color components per pixel > > +(such as monochrome and pseudo-color visuals) are reported as packed > > frame +buffer types, even though they don't stricly speaking pack color > > components +into macropixels. > > That's because the "packing" is not about the color components, but about > the bits that represent a single pixel. > > I.e. the bits that make up the pixel (the macropixel) are stored next > to each other > in memory. OK, I've modified that last sentence to read "Frame buffer visuals that don't use multiple color components per pixel (such as monochrome and pseudo-color visuals) are also reported as packed frame buffer types, as the bits that make up individual pixels are packed next to each other in memory." > > +- FB_TYPE_PLANES > > + > > +Color components are stored in separate planes. Planes are located > > +contiguously in memory. > > The bits that make up a pixel are stored in separate planes. Planes are > located contiguously in memory. I'm not sure to agree with this. You make it sounds like FB_TYPE_PLANES stores each bit in a different plane. Is that really the case ? > - FB_TYPE_INTERLEAVED_PLANES > > The bits that make up a pixel are stored in separate planes. Planes > are interleaved. > The interleave factor (the distance in bytes between the planes in > memory) is stored in the type_aux field. That's a bit unclear to me. How are they interleaved ? > > +- FB_VISUAL_MONO01 > > + > > +Pixels are black or white and stored on one bit. A bit set to 1 > > represents a +black pixel and a bit set to 0 a white pixel. Pixels are > > packed together in +bytes with 8 pixels per byte. > > Actually we do have drivers that use 8 bits per pixel for a monochrome > visual. Hence: > > "Pixels are black or white. A black pixel is represented by all > (typically one) bits set to ones, a white pixel by all bits set to zeroes." OK. I've rephrased it as "Pixels are black or white and stored on a number of bits (typically one) specified by the variable screen information bpp field. Black pixels are represented by all bits set to 1 and white pixels by all bits set to 0. When the number of bits per pixel is smaller than 8, several pixels are packed together in a byte." > > +FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only. > > ... so this may also not be true (but it is for all current drivers, IIRC). > There's a strict orthogonality between type (how is a pixel stored in > memory) and visual (how the bits that represent the pixel are interpreted > and converted to a color value). What about "FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only." ? > Same comments for FB_VISUAL_MONO10 Fixed the same way. > > +- FB_VISUAL_TRUECOLOR > > + > > +Pixels are broken into red, green and blue components, and each > > component +indexes a read-only lookup table for the corresponding value. > > Lookup tables +are device-dependent, and provide linear or non-linear > > ramps. > > + > > +Each component is stored in memory according to the variable screen > > +information red, green, blue and transp fields. > > "Each component is stored in a macropixel according to the variable screen > information red, green, blue and transp fields." > > Storage format in memory is determined by the FB_TYPE_* value. How so ? With FB_TYPE_PLANES and FB_VISUAL_TRUECOLOR for an RGB format, how are the R, G and B planes ordered ? Are color components packed or padded inside a plane ? I understand that the design goal was to have orthogonal FB_TYPE_* and FB_VISUAL_* values, but we're missing too much information for that to be truly generic. > > +- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR > > + > > +Pixel values are encoded as indices into a colormap that stores red, > > green and +blue components. The colormap is read-only for > > FB_VISUAL_STATIC_PSEUDOCOLOR +and read-write for FB_VISUAL_PSEUDOCOLOR. > > + > > +Each pixel value is stored in the number of bits reported by the > > variable +screen information bits_per_pixel field. Pixels are contiguous > > in memory. > > Whether pixels are contiguous in memory or not is determined by the > FB_TYPE_* value. How can they not be contiguous in memory ? Can you please give an example ? > > +FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR are used with > > +FB_TYPE_PACKED_PIXELS only. > > Not true. Several drivers use bit planes or interleaved bitplanes. How does that work ? > > +- FB_VISUAL_DIRECTCOLOR > > + > > +Pixels are broken into red, green and blue components, and eac
Re: [PATCH 5/7 v5] V4L: vb2: add support for buffers of different sizes on a single queue
Hi Pawel
Thanks for the review.
On Sun, 28 Aug 2011, Pawel Osciak wrote:
> Hi Guennadi,
>
> On Wed, Aug 24, 2011 at 11:41, Guennadi Liakhovetski
> wrote:
> > The two recently added ioctl()s VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF
> > allow user-space applications to allocate video buffers of different
> > sizes and hand them over to the driver for fast switching between
> > different frame formats. This patch adds support for buffers of different
> > sizes on the same buffer-queue to vb2.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > Cc: Hans Verkuil
> > Cc: Laurent Pinchart
> > Cc: Marek Szyprowski
> > Cc: Mauro Carvalho Chehab
> > Cc: Pawel Osciak
> > Cc: Sakari Ailus
> > ---
> > drivers/media/video/videobuf2-core.c | 278
> > --
> > include/media/videobuf2-core.h | 31 +++--
> > 2 files changed, 252 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/media/video/videobuf2-core.c
> > b/drivers/media/video/videobuf2-core.c
> > index 8a81a89..fed6f2d 100644
> > --- a/drivers/media/video/videobuf2-core.c
> > +++ b/drivers/media/video/videobuf2-core.c
[snip]
> > /**
> > + * vb2_create_bufs() - Allocate buffers and any required auxiliary structs
> > + * @q: videobuf2 queue
> > + * @create: creation parameters, passed from userspace to
> > vidioc_create_bufs
> > + * handler in driver
> > + *
> > + * Should be called from vidioc_create_bufs ioctl handler of a driver.
> > + * This function:
> > + * 1) verifies parameter sanity
> > + * 2) calls the .queue_setup() queue operation
> > + * 3) performs any necessary memory allocations
> > + *
> > + * The return values from this function are intended to be directly
> > returned
> > + * from vidioc_create_bufs handler in driver.
> > + */
> > +int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers
> > *create)
> > +{
> > + unsigned int num_planes, num_buffers = create->count,
> > allocated_buffers;
> > + unsigned long plane_sizes[VIDEO_MAX_PLANES];
> > + int ret = 0;
> > +
> > + if (q->fileio) {
> > + dprintk(1, "%s(): file io in progress\n", __func__);
> > + return -EBUSY;
> > + }
> > +
> > + if (create->memory != V4L2_MEMORY_MMAP
> > + && create->memory != V4L2_MEMORY_USERPTR) {
> > + dprintk(1, "%s(): unsupported memory type\n", __func__);
> > + return -EINVAL;
> > + }
> > +
> > + if (create->format.type != q->type) {
> > + dprintk(1, "%s(): requested type is incorrect\n", __func__);
> > + return -EINVAL;
> > + }
> > +
> > + /*
> > + * Make sure all the required memory ops for given memory type
> > + * are available.
> > + */
> > + if (create->memory == V4L2_MEMORY_MMAP && __verify_mmap_ops(q)) {
> > + dprintk(1, "%s(): MMAP for current setup unsupported\n",
> > __func__);
> > + return -EINVAL;
> > + }
> > +
> > + if (create->memory == V4L2_MEMORY_USERPTR &&
> > __verify_userptr_ops(q)) {
> > + dprintk(1, "%s(): USERPTR for current setup unsupported\n",
> > __func__);
> > + return -EINVAL;
> > + }
> > +
> > + if (q->num_buffers == VIDEO_MAX_FRAME) {
> > + dprintk(1, "%s(): maximum number of buffers already
> > allocated\n",
> > + __func__);
> > + return -ENOBUFS;
> > + }
>
> I think we should be verifying that q->num_buffers + create->count <=
> VIDEO_MAX_FRAME.
Yeah, something like that, thanks. Some of us didn't like this
VIDEO_MAX_FRAME limit at all, but as long as we have it, e-g-. as long as
struct vb2_queue::bufs[] is a fixed-size array with exactly that many
elements, we have to check for it. Increasing / eliminating it could be a
separate patch.
>
> > +
> > + create->index = q->num_buffers;
> > +
> > + if (!q->num_buffers) {
> > + memset(q->alloc_ctx, 0, sizeof(q->alloc_ctx));
> > + q->memory = create->memory;
> > + }
> > +
> > + /*
> > + * Ask the driver, whether the requested number of buffers, planes
> > per
> > + * buffer and their sizes are acceptable
> > + */
> > + ret = call_qop(q, queue_setup, q, &create->format, &num_buffers,
> > + &num_planes, plane_sizes, q->alloc_ctx);
>
> I don't see you zeroing neither num_planes nor plane_sizes[] in
> vb2_create_bufs and vb2_reqbufs. Since instead of always requiring the
> driver to fill them, you've introduced the "non-zero num_planes and/or
> plane_sizes" case (see my comment for queue_setup() documentation in
> videobuf2-core.h), it looks to me that the drivers will be getting
> random values in num_planes and plane_sizes in queue_setup() and will
> have to attempt to use them. Ditto for all other qop calls to
> queue_setup in this file (in vb2_reqbufs as well).
Re: [PATCH/RFC v2 3/3] fbdev: sh_mobile_lcdc: Support FOURCC-based format API
Hi Magnus, On Monday 29 August 2011 02:39:06 Magnus Damm wrote: > On Fri, Aug 19, 2011 at 6:37 PM, Laurent Pinchart wrote: > > Signed-off-by: Laurent Pinchart > > --- > > arch/arm/mach-shmobile/board-ag5evm.c |2 +- > > arch/arm/mach-shmobile/board-ap4evb.c |4 +- > > arch/arm/mach-shmobile/board-mackerel.c |4 +- > > drivers/video/sh_mobile_lcdcfb.c| 342 > > --- include/video/sh_mobile_lcdc.h > > |4 +- > > 5 files changed, 230 insertions(+), 126 deletions(-) > > Hi Laurent, thanks for the patch! > > Since you're changing the LCDC platform data please make sure you also > update the 5 boards using the LCDC under arch/sh. Sure. Sorry for forgetting about that. -- 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
My comments are mainly about the documentation of the "legacy" bits.
On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart
wrote:
> diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
> new file mode 100644
> index 000..6808492
> --- /dev/null
> +++ b/Documentation/fb/api.txt
> +2. Types and visuals
> +
> +
> +Pixels are stored in memory in hardware-dependent formats. Applications need
> +to be aware of the pixel storage format in order to write image data to the
> +frame buffer memory in the format expected by the hardware.
> +
> +Formats are described by frame buffer types and visuals. Some visuals require
> +additional information, which are stored in the variable screen information
> +bits_per_pixel, grayscale, fourcc, red, green, blue and transp fields.
> +
> +The following types and visuals are supported.
> +
> +- FB_TYPE_PACKED_PIXELS
> +
> +Color components (usually RGB or YUV) are packed together into macropixels
> +that are stored in a single plane. The exact color components layout is
> +described in a visual-dependent way.
> +
> +Frame buffer visuals that don't use multiple color components per pixel
> +(such as monochrome and pseudo-color visuals) are reported as packed frame
> +buffer types, even though they don't stricly speaking pack color components
> +into macropixels.
That's because the "packing" is not about the color components, but about the
bits that represent a single pixel.
I.e. the bits that make up the pixel (the macropixel) are stored next
to each other
in memory.
> +- FB_TYPE_PLANES
> +
> +Color components are stored in separate planes. Planes are located
> +contiguously in memory.
The bits that make up a pixel are stored in separate planes. Planes are located
contiguously in memory.
- FB_TYPE_INTERLEAVED_PLANES
The bits that make up a pixel are stored in separate planes. Planes
are interleaved.
The interleave factor (the distance in bytes between the planes in
memory) is stored
in the type_aux field.
> +- FB_VISUAL_MONO01
> +
> +Pixels are black or white and stored on one bit. A bit set to 1 represents a
> +black pixel and a bit set to 0 a white pixel. Pixels are packed together in
> +bytes with 8 pixels per byte.
Actually we do have drivers that use 8 bits per pixel for a monochrome visual.
Hence:
"Pixels are black or white. A black pixel is represented by all
(typically one) bits
set to ones, a white pixel by all bits set to zeroes."
> +FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
... so this may also not be true (but it is for all current drivers, IIRC).
There's a strict orthogonality between type (how is a pixel stored in memory)
and visual (how the bits that represent the pixel are interpreted and converted
to a color value).
Same comments for FB_VISUAL_MONO10
> +- FB_VISUAL_TRUECOLOR
> +
> +Pixels are broken into red, green and blue components, and each component
> +indexes a read-only lookup table for the corresponding value. Lookup tables
> +are device-dependent, and provide linear or non-linear ramps.
> +
> +Each component is stored in memory according to the variable screen
> +information red, green, blue and transp fields.
"Each component is stored in a macropixel according to the variable screen
information red, green, blue and transp fields."
Storage format in memory is determined by the FB_TYPE_* value.
> +- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
> +
> +Pixel values are encoded as indices into a colormap that stores red, green
> and
> +blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
> +and read-write for FB_VISUAL_PSEUDOCOLOR.
> +
> +Each pixel value is stored in the number of bits reported by the variable
> +screen information bits_per_pixel field. Pixels are contiguous in memory.
Whether pixels are contiguous in memory or not is determined by the
FB_TYPE_* value.
> +FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR are used with
> +FB_TYPE_PACKED_PIXELS only.
Not true. Several drivers use bit planes or interleaved bitplanes.
> +- FB_VISUAL_DIRECTCOLOR
> +
> +Pixels are broken into red, green and blue components, and each component
> +indexes a programmable lookup table for the corresponding value.
> +
> +Each component is stored in memory according to the variable screen
> +information red, green, blue and transp fields.
"Each component is stored in a macropixel according to the variable screen
information red, green, blue and transp fields."
> +- FB_VISUAL_FOURCC
> +
> +Pixels are stored in memory as described by the format FOURCC identifier
> +stored in the variable screen information fourcc field.
... stored in memory and interpreted ...
> +struct fb_var_screeninfo {
> + __u32 xres; /* visible resolution */
> + __u32 yres;
> + __u32 xres_virtual; /* virtual resolution */
> + __u32 yres_virtual;
> + __u32 xoffset; /* offset from v
Re: [PATCH 4/5] [media] v4l: fix copying ioctl results on failure
On 08/26/2011 05:09 PM, Laurent Pinchart wrote:
Hi Laurent,
Hi Tomasz,
On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote:
This patch fix the handling of data passed to V4L2 ioctls. The content of
the structures is not copied if the ioctl fails. It blocks ability to
obtain any information about occurred error other then errno code. This
patch fix this issue.
Does the V4L2 spec say anything on this topic ? We might have applications
that rely on the ioctl argument structure not being touched when a failure
occurs.
Ups.. I missed something. It looks that modifying ioctl content is
illegal if ioctl fails. The spec says:
"When an ioctl that takes an output or read/write parameter fails, the
parameter remains unmodified." (v4l2 ioctl section)
However, there is probably a bug already present in V4L2 framework.
There are some ioctls that takes a pointer to an array as a field in the
argument struct.
The examples are all VIDIOC_*_EXT_CTRLS and VIDIOC_{QUERY/DQ/Q}_BUF family.
The content of such an auxiliary arays is copied even if ioctl fails.
Please take a look to video_usercopy function in v4l2-ioctl.c. Therefore
I think that the spec is already violated. What is your opinion about
this problem?
Now back to selection case.
This patch was added as proposition of fix to VIDIOC_S_SELECTION, to
return the best-hit rectangle if constraints could not be satisfied. The
ioctl return -ERANGE in this case. Using those return values the
application gets some feedback
on loosing constraints.
I could remove rectangle returning from the spec and s5p-tv code for now.
Regards,
Tomasz Stanislawski
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ioctl.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c index 543405b..9f54114 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2490,8 +2490,6 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg, err = -EFAULT;
goto out_array_args;
}
- if (err< 0)
- goto out;
out_array_args:
/* Copy results into user buffer */
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: vb2: dma contig allocator: use dma_addr instread of paddr
Use the correct 'dma_addr' name for the buffer address. 'paddr' suggested
that this is the physical address in system memory. For most ARM platforms
these two are the same, but this is not a generic rule. 'dma_addr' will
also point better to dma-mapping api.
Signed-off-by: Marek Szyprowski
Signed-off-by: Kyungmin Park
CC: Pawel Osciak
---
drivers/media/video/atmel-isi.c |2 +-
drivers/media/video/marvell-ccic/mcam-core.c |4 +-
drivers/media/video/mx3_camera.c |2 +-
drivers/media/video/s5p-fimc/fimc-core.c |6 ++--
drivers/media/video/s5p-mfc/s5p_mfc.c|4 +-
drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 10
drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 30 +-
drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 14 ++--
drivers/media/video/s5p-tv/mixer_grp_layer.c |2 +-
drivers/media/video/s5p-tv/mixer_vp_layer.c |4 +-
drivers/media/video/sh_mobile_ceu_camera.c |2 +-
drivers/media/video/videobuf2-dma-contig.c | 16 +++---
include/media/videobuf2-dma-contig.h |6 ++--
13 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 5a4b2d7..7e1d789 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -341,7 +341,7 @@ static int buffer_prepare(struct vb2_buffer *vb)
/* Initialize the dma descriptor */
desc->p_fbd->fb_address =
- vb2_dma_contig_plane_paddr(vb, 0);
+ vb2_dma_contig_plane_dma_addr(vb, 0);
desc->p_fbd->next_fbd_address = 0;
set_dma_ctrl(desc->p_fbd, ISI_DMA_CTRL_WB);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 744cf37..7abe503 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -450,7 +450,7 @@ static void mcam_set_contig_buffer(struct mcam_camera *cam,
int frame)
buf = cam->vb_bufs[frame ^ 0x1];
cam->vb_bufs[frame] = buf;
mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_paddr(&buf->vb_buf, 0));
+ vb2_dma_contig_plane_dma_addr(&buf->vb_buf, 0));
set_bit(CF_SINGLE_BUFFER, &cam->flags);
singles++;
return;
@@ -461,7 +461,7 @@ static void mcam_set_contig_buffer(struct mcam_camera *cam,
int frame)
buf = list_first_entry(&cam->buffers, struct mcam_vb_buffer, queue);
list_del_init(&buf->queue);
mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_paddr(&buf->vb_buf, 0));
+ vb2_dma_contig_plane_dma_addr(&buf->vb_buf, 0));
cam->vb_bufs[frame] = buf;
clear_bit(CF_SINGLE_BUFFER, &cam->flags);
}
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 9ae7785..c8e958a 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -247,7 +247,7 @@ static int mx3_videobuf_prepare(struct vb2_buffer *vb)
}
if (buf->state == CSI_BUF_NEEDS_INIT) {
- sg_dma_address(sg) = vb2_dma_contig_plane_paddr(vb, 0);
+ sg_dma_address(sg) = vb2_dma_contig_plane_dma_addr(vb, 0);
sg_dma_len(sg) = new_size;
buf->txd = ichan->dma_chan.device->device_prep_slave_sg(
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 8152756..266d6b9 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -457,7 +457,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
dbg("memplanes= %d, colplanes= %d, pix_size= %d",
frame->fmt->memplanes, frame->fmt->colplanes, pix_size);
- paddr->y = vb2_dma_contig_plane_paddr(vb, 0);
+ paddr->y = vb2_dma_contig_plane_dma_addr(vb, 0);
if (frame->fmt->memplanes == 1) {
switch (frame->fmt->colplanes) {
@@ -485,10 +485,10 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
}
} else {
if (frame->fmt->memplanes >= 2)
- paddr->cb = vb2_dma_contig_plane_paddr(vb, 1);
+ paddr->cb = vb2_dma_contig_plane_dma_addr(vb, 1);
if (frame->fmt->memplanes == 3)
- paddr->cr = vb2_dma_contig_plane_paddr(vb, 2);
+ paddr->cr = vb2_dma_contig_plane_dma_addr(vb, 2);
}
dbg("PHYS_ADDR: y= 0x%X cb= 0x%X cr= 0x%X ret= %d",
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
b/drivers/media
