Media system Summit
Em 11-07-2012 05:09, James Bottomley escreveu: > Hi All, > > We have set aside the second day of the kernel summit (Tuesday 28 > August) as mini-summit day. So far we have only the PCI mini summit on > this day Not sure what happened (or maybe my proposal were not clear enough), but I've submitted a proposal to have a media system summit on KS/2011. Last year was very productive for media developers, so we'd like to do it again ;) Message-ID: <4fec74ab.6070...@redhat.com> Date: Thu, 28 Jun 2012 12:13:47 -0300 From: Mauro Carvalho Chehab [Ksummit-2012-discuss] [ATTEND] media subsystem I'd like to have media subsystem discussions this year's at kernel summit. The media subsystem is one of the most active driver subsystem, and there are lots of things there that require face-to-face discussions, not only between subsystem developers, but also with other maintainers. In special, during KS/2011, it was identified the need of interacting with video and audio system people, in order to solve some common issues, like HDMI CEC and audio/video synchronization. The increasing complexity of SoC designs used by media devices requires API extensions at the media APIs in order to proper expose and control all hardware functionality on a standard way. A new API to better allow negotiating userspace and Kernelspace capabilities seem to be required. More discussions with regards to shared resources locking is needed, on devices that implement multiple API's, but not a the same time. The incompatibility between udev-182 and the existing drivers will also require lots of discussions, as that affects 64 media drivers, and changing them to comply with the current requirement of using request_firmware_nowait() won't work on several drivers. So, a solution (or a set of solutions) needs to be found, in order to fix such incompatibility. Thanks, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] v4l: Export v4l2-common.h in include/linux/Kbuild
Hi Sakari, On Mon, 9 Jul 2012 12:10:26 +0300 Sakari Ailus wrote: > > v4l2-common.h is a header file that's used in user space, thus it must be > exported using header-y. > > Signed-off-by: Sakari Ailus > --- > Hi Stephen, > > Could you try is this patch fixes your issue? The header file indeed should > be exported which wasn't done previously. I have added this as a merge fixup in linux-next today and it fixes the problem. Mauro, please put this into the v4l-dvb tree. Reported-by: Stephen Rothwell Tested-by: Stephen Rothwell > include/linux/Kbuild |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/include/linux/Kbuild b/include/linux/Kbuild > index d38b3a8..ef4cc94 100644 > --- a/include/linux/Kbuild > +++ b/include/linux/Kbuild > @@ -382,6 +382,7 @@ header-y += usbdevice_fs.h > header-y += utime.h > header-y += utsname.h > header-y += uvcvideo.h > +header-y += v4l2-common.h > header-y += v4l2-dv-timings.h > header-y += v4l2-mediabus.h > header-y += v4l2-subdev.h -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpmHVfvUDUzo.pgp Description: PGP signature
[PATCH RFC] add LNA support for DVB API
Signed-off-by: Antti Palosaari
---
drivers/media/dvb/dvb-core/dvb_frontend.c |5 +
drivers/media/dvb/dvb-core/dvb_frontend.h |1 +
include/linux/dvb/frontend.h |4 +++-
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index b54c297..fe22aaa 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1020,6 +1020,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {
_DTV_CMD(DTV_ISDBS_TS_ID, 1, 0),
_DTV_CMD(DTV_DVBT2_PLP_ID, 1, 0),
+ _DTV_CMD(DTV_LNA, 1, 0),
/* Get */
_DTV_CMD(DTV_DISEQC_SLAVE_REPLY, 0, 1),
@@ -1723,6 +1724,10 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_INTERLEAVING:
c->interleaving = tvp->u.data;
break;
+ case DTV_LNA:
+ if (fe->ops.set_lna)
+ r = fe->ops.set_lna(fe, tvp->u.data);
+ break;
/* ISDB-T Support here */
case DTV_ISDBT_PARTIAL_RECEPTION:
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 31a3d1c..628a821 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -302,6 +302,7 @@ struct dvb_frontend_ops {
int (*dishnetwork_send_legacy_command)(struct dvb_frontend* fe,
unsigned long cmd);
int (*i2c_gate_ctrl)(struct dvb_frontend* fe, int enable);
int (*ts_bus_ctrl)(struct dvb_frontend* fe, int acquire);
+ int (*set_lna)(struct dvb_frontend *, int);
/* These callbacks are for devices that implement their own
* tuning algorithms, rather than a simple swzigzag
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 2dd5823..e28802a 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -350,8 +350,9 @@ struct dvb_frontend_event {
#define DTV_ATSCMH_SCCC_CODE_MODE_D59
#define DTV_INTERLEAVING 60
+#define DTV_LNA61
-#define DTV_MAX_COMMANDDTV_INTERLEAVING
+#define DTV_MAX_COMMANDDTV_LNA
typedef enum fe_pilot {
PILOT_ON,
@@ -424,6 +425,7 @@ enum atscmh_rs_code_mode {
ATSCMH_RSCODE_RES= 3,
};
+#define LNA_AUTO INT_MIN
struct dtv_cmds_h {
char*name; /* A display name for debugging purposes */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Make menuconfig doesn't work anymore
On Wed, Jul 11, 2012 at 2:30 PM, Martin Herrman wrote: >> Actually I got the exact same error when compiling a new 3.4.4 kernel. > > It always feels good to know that you're not alone ;-) Yes, it's a good thing usually! >> I assume the api_version.patch is bad or needs to be updated. I simple >> just commented out the "add api_version.patch" line in >> backports/backports.txt and crossed my fingers the drivers I use still >> worked -- which they did so all is well here (afaik). But, yeah it >> does need a proper fix and I only recommend my cheap workaround with a >> YMMV warning. > > thanks, this solved the first part of the problem. I can now do a make > menuconfig, but the frontend modules I need cannot be selected, > although the file > /usr/src/media_build_experimental/linux/drivers/media/dvb/frontends/tda18212dd.c > etc. do exist. > > I have also looked into the staging drivers and enabled drivers not > supported by this kernel, but stil no luck. > > Did you have this problem as well? No, the drivers I need were already there but I just checked my menuconfig and I see: Multimedia support -> Customize TV tuners -> NXP TDA18212 silicon tuner Is that what you're looking for? If so, all you need, I think, is "DVB for Linux" and "Customize analog and hybrid tuner modules to build" to get the "Customize TV tuners" option. -- 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] dma-fence: dma-buf synchronization
On Wed, Jul 11, 2012 at 6:49 PM, Maarten Lankhorst
wrote:
> Op 12-07-12 00:29, Rob Clark schreef:
>> From: Rob Clark
>>
>> A dma-fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device. For example, userspace can call page_flip ioctl to display the
>> next frame of graphics after kicking the GPU but while the GPU is still
>> rendering. The display device sharing the buffer with the GPU would
>> attach a callback to get notified when the GPU's rendering-complete IRQ
>> fires, to update the scan-out address of the display, without having to
>> wake up userspace.
>>
>> A dma-fence is transient, one-shot deal. It is allocated and attached
>> to dma-buf's list of fences. When the one that attached it is done,
>> with the pending operation, it can signal the fence removing it from the
>> dma-buf's list of fences:
>>
>> + dma_buf_attach_fence()
>> + dma_fence_signal()
>>
>> Other drivers can access the current fence on the dma-buf (if any),
>> which increment's the fences refcnt:
>>
>> + dma_buf_get_fence()
>> + dma_fence_put()
>>
>> The one pending on the fence can add an async callback (and optionally
>> cancel it.. for example, to recover from GPU hangs):
>>
>> + dma_fence_add_callback()
>> + dma_fence_cancel_callback()
>>
>> Or wait synchronously (optionally with timeout or from atomic context):
>>
>> + dma_fence_wait()
> Waiting for an undefined time from atomic context is probably
> not a good idea. However just checking non-blocking if the fence
> has passed would be fine.
yeah, the intention was to use short timeout or no-blocking if from
atomic ctxt, or interruptible with whatever timeout if non-atomic (for
example, to implement a CPU_PREP sort of ioctl)
>> A default software-only implementation is provided, which can be used
>> by drivers attaching a fence to a buffer when they have no other means
>> for hw sync. But a memory backed fence is also envisioned, because it
>> is common that GPU's can write to, or poll on some memory location for
>> synchronization. For example:
>>
>> fence = dma_buf_get_fence(dmabuf);
>> if (fence->ops == &mem_dma_fence_ops) {
>> dma_buf *fence_buf;
>> mem_dma_fence_get_buf(fence, &fence_buf, &offset);
>> ... tell the hw the memory location to wait on ...
>> } else {
>> /* fall-back to sw sync * /
>> dma_fence_add_callback(fence, my_cb);
>> }
> This will probably have to be done on dma-buf attach time instead,
> so drivers that support both know if an interrupt needs to be inserted
> in the command stream or not.
probably a hint, ie. add a flags parameter to attach() would do the job?
>> The memory location is itself backed by dma-buf, to simplify mapping
>> to the device's address space, an idea borrowed from Maarten Lankhorst.
>>
>> NOTE: the memory location fence is not implemented yet, the above is
>> just for explaining how it would work.
>>
>> On SoC platforms, if some other hw mechanism is provided for synchronizing
>> between IP blocks, it could be supported as an alternate implementation
>> with it's own fence ops in a similar way.
>>
>> The other non-sw implementations would wrap the add/cancel_callback and
>> wait fence ops, so that they can keep track if a device not supporting
>> hw sync is waiting on the fence, and in this case should arrange to
> Standardizing an errno in case the device already signalled the fence
> would be nice.
I was just using EINVAL, but perhaps there is a better choice?
>> call dma_fence_signal() at some point after the condition has changed,
>> to notify other devices waiting on the fence. If there are no sw
>> waiters, this can be skipped to avoid waking the CPU unnecessarily.
> Can this be done inside interrupt context? I could insert some
> semaphores into intel that would block execution, but I would
> save a context switch if intel could release the command blocking
> from inside irq context.
yeah, it was the intention that signal() could be from irq handler
directly (and that registered cb's can be called from atomic ctxt..
which is sufficient if they just have to bang a register or two,
otherwise they can schedule a worker)
>> The intention is to provide a userspace interface (presumably via eventfd)
>> later, to be used in conjunction with dma-buf's mmap support for sw access
>> to buffers (or for userspace apps that would prefer to do their own
>> synchronization).
> I'll have to look at this more in the morning but I see no barrier for
> this being used with dmabufmgr right now.
>
> The fence lock should probably not be static but shared with the
> dmabufmgr code, with _locked variants.
> Oh and in your example code I noticed inconsistent use of spin_lock
> and spin_lock_irqsave, do you intend it to be used in hardirq context?
oh, whoops, I started w/ spin_lock() an then realized I wanted
signal() from irq handlers and forgot to update all the other places
where spin_loc
Re: [PATCH] dma-fence: dma-buf synchronization
Op 12-07-12 00:29, Rob Clark schreef:
> From: Rob Clark
>
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A dma-fence is transient, one-shot deal. It is allocated and attached
> to dma-buf's list of fences. When the one that attached it is done,
> with the pending operation, it can signal the fence removing it from the
> dma-buf's list of fences:
>
> + dma_buf_attach_fence()
> + dma_fence_signal()
>
> Other drivers can access the current fence on the dma-buf (if any),
> which increment's the fences refcnt:
>
> + dma_buf_get_fence()
> + dma_fence_put()
>
> The one pending on the fence can add an async callback (and optionally
> cancel it.. for example, to recover from GPU hangs):
>
> + dma_fence_add_callback()
> + dma_fence_cancel_callback()
>
> Or wait synchronously (optionally with timeout or from atomic context):
>
> + dma_fence_wait()
Waiting for an undefined time from atomic context is probably
not a good idea. However just checking non-blocking if the fence
has passed would be fine.
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync. But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization. For example:
>
> fence = dma_buf_get_fence(dmabuf);
> if (fence->ops == &mem_dma_fence_ops) {
> dma_buf *fence_buf;
> mem_dma_fence_get_buf(fence, &fence_buf, &offset);
> ... tell the hw the memory location to wait on ...
> } else {
> /* fall-back to sw sync * /
> dma_fence_add_callback(fence, my_cb);
> }
This will probably have to be done on dma-buf attach time instead,
so drivers that support both know if an interrupt needs to be inserted
in the command stream or not.
> The memory location is itself backed by dma-buf, to simplify mapping
> to the device's address space, an idea borrowed from Maarten Lankhorst.
>
> NOTE: the memory location fence is not implemented yet, the above is
> just for explaining how it would work.
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> The other non-sw implementations would wrap the add/cancel_callback and
> wait fence ops, so that they can keep track if a device not supporting
> hw sync is waiting on the fence, and in this case should arrange to
Standardizing an errno in case the device already signalled the fence
would be nice.
> call dma_fence_signal() at some point after the condition has changed,
> to notify other devices waiting on the fence. If there are no sw
> waiters, this can be skipped to avoid waking the CPU unnecessarily.
Can this be done inside interrupt context? I could insert some
semaphores into intel that would block execution, but I would
save a context switch if intel could release the command blocking
from inside irq context.
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
I'll have to look at this more in the morning but I see no barrier for
this being used with dmabufmgr right now.
The fence lock should probably not be static but shared with the
dmabufmgr code, with _locked variants.
Oh and in your example code I noticed inconsistent use of spin_lock
and spin_lock_irqsave, do you intend it to be used in hardirq context?
~Maarten
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/01] media: gscaler: Add new driver for generic scaler
On 07/12/2012 12:39 AM, Sylwester Nawrocki wrote:
+int gsc_hw_get_input_buf_mask_status(struct gsc_dev *dev)
+{
+ u32 cfg, status, bits = 0;
+
+ cfg = readl(dev->regs + GSC_IN_BASE_ADDR_Y_MASK);
return hweight32(cfg & GSC_IN_BASE_ADDR_MASK);
+ status = cfg& GSC_IN_BASE_ADDR_MASK;
+ while (status) {
+ status = status& (status - 1);
+ bits++;
+ }
+ return bits;
+}
[...]
+
+int gsc_hw_get_nr_unmask_bits(struct gsc_dev *dev)
+{
+ u32 bits = 0;
+ u32 mask_bits = readl(dev->regs + GSC_OUT_BASE_ADDR_Y_MASK);
Care to add an empty line? It might also look better to order
declarations in decending line order.
+ mask_bits&= GSC_OUT_BASE_ADDR_MASK;
+
+ while (mask_bits) {
+ mask_bits = mask_bits& (mask_bits - 1);
+ bits++;
+ }
It seems you are computing a Hamming weight here, then it could
be simplified to a built-in function:
bits = hweight32(mask_bits);
But it's not quite clear to me, why you're subtracting it
from 16 ?
+ bits = 16 - bits;
return 16 - bits;
+
+ return bits;
+}
--
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] mceusb: Add Twisted Melon USB IDs
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: Mark Lord
---
Mauro, please queue this up for inclusion in linux-3.6.
Patch is also attached to bypass emailer mangling.
Thanks.
--- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23:56.0
-0400
+++ new/drivers/media/rc/mceusb.c 2012-07-11 18:44:03.113727658 -0400
@@ -199,6 +199,7 @@
#define VENDOR_REALTEK 0x0bda
#define VENDOR_TIVO0x105a
#define VENDOR_CONEXANT0x0572
+#define VENDOR_TWISTEDMELON0x2596
enum mceusb_model_type {
MCE_GEN2 = 0, /* Most boards */
@@ -391,6 +392,12 @@
/* Conexant Hybrid TV RDU253S Polaris */
{ USB_DEVICE(VENDOR_CONEXANT, 0x58a5),
.driver_info = CX_HYBRID_TV },
+ /* Twisted Melon Inc. - Manta Mini Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8008) },
+ /* Twisted Melon Inc. - Manta Pico Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8016) },
+ /* Twisted Melon Inc. - Manta Transceiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8042) },
/* Terminating entry */
{ }
};
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: Mark Lord
---
Mauro, please queue this up for inclusion in linux-3.6.
Thanks.
--- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23:56.0 -0400
+++ new/drivers/media/rc/mceusb.c 2012-07-11 18:44:03.113727658 -0400
@@ -199,6 +199,7 @@
#define VENDOR_REALTEK 0x0bda
#define VENDOR_TIVO 0x105a
#define VENDOR_CONEXANT 0x0572
+#define VENDOR_TWISTEDMELON 0x2596
enum mceusb_model_type {
MCE_GEN2 = 0, /* Most boards */
@@ -391,6 +392,12 @@
/* Conexant Hybrid TV RDU253S Polaris */
{ USB_DEVICE(VENDOR_CONEXANT, 0x58a5),
.driver_info = CX_HYBRID_TV },
+ /* Twisted Melon Inc. - Manta Mini Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8008) },
+ /* Twisted Melon Inc. - Manta Pico Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8016) },
+ /* Twisted Melon Inc. - Manta Transceiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8042) },
/* Terminating entry */
{ }
};
Re: [RFC] dma-fence: dma-buf synchronization
oh, btw, this should be an [RFC]
On Wed, Jul 11, 2012 at 5:29 PM, Rob Clark wrote:
> From: Rob Clark
>
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A dma-fence is transient, one-shot deal. It is allocated and attached
> to dma-buf's list of fences. When the one that attached it is done,
> with the pending operation, it can signal the fence removing it from the
> dma-buf's list of fences:
>
> + dma_buf_attach_fence()
> + dma_fence_signal()
>
> Other drivers can access the current fence on the dma-buf (if any),
> which increment's the fences refcnt:
>
> + dma_buf_get_fence()
> + dma_fence_put()
>
> The one pending on the fence can add an async callback (and optionally
> cancel it.. for example, to recover from GPU hangs):
>
> + dma_fence_add_callback()
> + dma_fence_cancel_callback()
>
> Or wait synchronously (optionally with timeout or from atomic context):
>
> + dma_fence_wait()
>
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync. But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization. For example:
>
> fence = dma_buf_get_fence(dmabuf);
> if (fence->ops == &mem_dma_fence_ops) {
> dma_buf *fence_buf;
> mem_dma_fence_get_buf(fence, &fence_buf, &offset);
> ... tell the hw the memory location to wait on ...
> } else {
> /* fall-back to sw sync * /
> dma_fence_add_callback(fence, my_cb);
> }
>
> The memory location is itself backed by dma-buf, to simplify mapping
> to the device's address space, an idea borrowed from Maarten Lankhorst.
>
> NOTE: the memory location fence is not implemented yet, the above is
> just for explaining how it would work.
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> The other non-sw implementations would wrap the add/cancel_callback and
> wait fence ops, so that they can keep track if a device not supporting
> hw sync is waiting on the fence, and in this case should arrange to
> call dma_fence_signal() at some point after the condition has changed,
> to notify other devices waiting on the fence. If there are no sw
> waiters, this can be skipped to avoid waking the CPU unnecessarily.
>
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
> ---
> drivers/base/Makefile |2 +-
> drivers/base/dma-buf.c|3 +
> drivers/base/dma-fence.c | 325
> +
> include/linux/dma-buf.h |3 +
> include/linux/dma-fence.h | 118
> 5 files changed, 450 insertions(+), 1 deletion(-)
> create mode 100644 drivers/base/dma-fence.c
> create mode 100644 include/linux/dma-fence.h
>
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 5aa2d70..6e9f217 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
> obj-y += power/
> obj-$(CONFIG_HAS_DMA) += dma-mapping.o
> obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
> -obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
> +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o
> obj-$(CONFIG_ISA) += isa.o
> obj-$(CONFIG_FW_LOADER)+= firmware_class.o
> obj-$(CONFIG_NUMA) += node.o
> diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
> index 24e88fe..b053236 100644
> --- a/drivers/base/dma-buf.c
> +++ b/drivers/base/dma-buf.c
> @@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file
> *file)
>
> dmabuf = file->private_data;
>
> + WARN_ON(!list_empty(&dmabuf->fence_list));
> +
> dmabuf->ops->release(dmabuf);
> kfree(dmabuf);
> return 0;
> @@ -119,6 +121,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
> dma_buf_ops *ops,
>
> mutex_init(&dmabuf->lock);
> INIT_LIST_HEAD(&dmabuf->attachments);
> + INIT_LIST_HEAD(&dmabuf->fence_list);
>
> return dmabuf;
> }
> diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
> new file mode 100644
> index 000..a94ed01
> --
[PATCH] dma-fence: dma-buf synchronization
From: Rob Clark
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A dma-fence is transient, one-shot deal. It is allocated and attached
to dma-buf's list of fences. When the one that attached it is done,
with the pending operation, it can signal the fence removing it from the
dma-buf's list of fences:
+ dma_buf_attach_fence()
+ dma_fence_signal()
Other drivers can access the current fence on the dma-buf (if any),
which increment's the fences refcnt:
+ dma_buf_get_fence()
+ dma_fence_put()
The one pending on the fence can add an async callback (and optionally
cancel it.. for example, to recover from GPU hangs):
+ dma_fence_add_callback()
+ dma_fence_cancel_callback()
Or wait synchronously (optionally with timeout or from atomic context):
+ dma_fence_wait()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = dma_buf_get_fence(dmabuf);
if (fence->ops == &mem_dma_fence_ops) {
dma_buf *fence_buf;
mem_dma_fence_get_buf(fence, &fence_buf, &offset);
... tell the hw the memory location to wait on ...
} else {
/* fall-back to sw sync * /
dma_fence_add_callback(fence, my_cb);
}
The memory location is itself backed by dma-buf, to simplify mapping
to the device's address space, an idea borrowed from Maarten Lankhorst.
NOTE: the memory location fence is not implemented yet, the above is
just for explaining how it would work.
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
The other non-sw implementations would wrap the add/cancel_callback and
wait fence ops, so that they can keep track if a device not supporting
hw sync is waiting on the fence, and in this case should arrange to
call dma_fence_signal() at some point after the condition has changed,
to notify other devices waiting on the fence. If there are no sw
waiters, this can be skipped to avoid waking the CPU unnecessarily.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
---
drivers/base/Makefile |2 +-
drivers/base/dma-buf.c|3 +
drivers/base/dma-fence.c | 325 +
include/linux/dma-buf.h |3 +
include/linux/dma-fence.h | 118
5 files changed, 450 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/dma-fence.c
create mode 100644 include/linux/dma-fence.h
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 5aa2d70..6e9f217 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_CMA) += dma-contiguous.o
obj-y += power/
obj-$(CONFIG_HAS_DMA) += dma-mapping.o
obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o
+obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o dma-fence.o
obj-$(CONFIG_ISA) += isa.o
obj-$(CONFIG_FW_LOADER)+= firmware_class.o
obj-$(CONFIG_NUMA) += node.o
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 24e88fe..b053236 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -39,6 +39,8 @@ static int dma_buf_release(struct inode *inode, struct file
*file)
dmabuf = file->private_data;
+ WARN_ON(!list_empty(&dmabuf->fence_list));
+
dmabuf->ops->release(dmabuf);
kfree(dmabuf);
return 0;
@@ -119,6 +121,7 @@ struct dma_buf *dma_buf_export(void *priv, const struct
dma_buf_ops *ops,
mutex_init(&dmabuf->lock);
INIT_LIST_HEAD(&dmabuf->attachments);
+ INIT_LIST_HEAD(&dmabuf->fence_list);
return dmabuf;
}
diff --git a/drivers/base/dma-fence.c b/drivers/base/dma-fence.c
new file mode 100644
index 000..a94ed01
--- /dev/null
+++ b/drivers/base/dma-fence.c
@@ -0,0 +1,325 @@
+/*
+ * Fence mechanism for dma-buf to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of th
Re: Make menuconfig doesn't work anymore
2012/7/11 VDR User : > Actually I got the exact same error when compiling a new 3.4.4 kernel. It always feels good to know that you're not alone ;-) > I assume the api_version.patch is bad or needs to be updated. I simple > just commented out the "add api_version.patch" line in > backports/backports.txt and crossed my fingers the drivers I use still > worked -- which they did so all is well here (afaik). But, yeah it > does need a proper fix and I only recommend my cheap workaround with a > YMMV warning. thanks, this solved the first part of the problem. I can now do a make menuconfig, but the frontend modules I need cannot be selected, although the file /usr/src/media_build_experimental/linux/drivers/media/dvb/frontends/tda18212dd.c etc. do exist. I have also looked into the staging drivers and enabled drivers not supported by this kernel, but stil no luck. Did you have this problem as well? -- 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
Q: FE set_property() and get_property callbacks
I was playing with the DVB API LNA support and ended up looking common dvb-frontend code. There is struct dvb_frontend_ops: int (*set_property)(struct dvb_frontend* fe, struct dtv_property* tvp); int (*get_property)(struct dvb_frontend* fe, struct dtv_property* tvp); What I can see from the dvb-core comments those are used for validating parameters. Why? Naming is very misleading. For me those names sounds like setting and getting parameters is something what average coder can think. For example if I wish to set LNA I would like to implement set_property() to my driver and expect to catch DTV_LNA command and handle it. But what now is done is to add new callback "set_lna()" to struct dvb_frontend_ops, add new parameter "lna" to struct dtv_frontend_properties, cache value here and use new callback to set value. Due to that selected implementation it goes complex and "struct dvb_frontend_ops" and "struct dtv_frontend_properties" grows all the time when new parameter is added. It looks even more weird as you grep current use of set_property() and get_property(). There is only two drivers, stv0288 and stv6110, defining those callbacks. And both of those seems to have quite nonsense implementation. So whats happening here? 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Wed Jul 11 19:00:18 CEST 2012 git hash:b7e386360922a15f943b2fbe8d77a19bb86f2e6f gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
On Wed, Jul 11, 2012 at 1:01 PM, Hans Verkuil wrote: > Hi Hans, > > Thanks for the patch. > > I've CC-ed Halli as well. > > On Wed July 11 2012 17:47:34 Hans de Goede wrote: >> To allow apps to limit a hw-freq-seek to a specific band, for further >> info see the documentation this patch adds for these new fields. >> >> Signed-off-by: Hans de Goede >> --- >> .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 44 >> >> include/linux/videodev2.h |5 ++- >> 2 files changed, 40 insertions(+), 9 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml >> b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml >> index f4db44d..50dc9f8 100644 >> --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml >> +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml >> @@ -52,11 +52,21 @@ >> Start a hardware frequency seek from the current frequency. >> To do this applications initialize the tuner, >> type, seek_upward, >> -spacing and >> -wrap_around fields, and zero out the >> -reserved array of a &v4l2-hw-freq-seek; and >> -call the VIDIOC_S_HW_FREQ_SEEK ioctl with a pointer >> -to this structure. >> +wrap_around, spacing, >> +rangelow and rangehigh >> +fields, and zero out the reserved array of a >> +&v4l2-hw-freq-seek; and call the VIDIOC_S_HW_FREQ_SEEK >> +ioctl with a pointer to this structure. >> + >> +The rangelow and >> +rangehigh fields can be set to a non-zero value >> to >> +tell the driver to search a specific band. If the &v4l2-tuner; >> +capability field has the >> +V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag set, these values >> +must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If >> +the V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag is not set, >> +then these values must exactly match those of one of the bands returned by >> +&VIDIOC-ENUM-FREQ-BANDS;. > > OK, I have some questions here: > > 1) If you have a multiband tuner, what should happen if both low and high are > zero? Currently it is undefined, other than that the seek should start from > the current frequency until it reaches some limit. > > Halli, what does your hardware do? In particular, is the hwseek limited by the > US/Europe or Japan band range or can it do the full range? If I'm not mistaken > it is the former, right? You are right... my hardware seek is limited by the japan/US band range > If it is the former, then you need to explicitly set low + high to ensure that > the hwseek uses the correct range because the driver can't guess which of the > overlapping bands to use. Yes in my driver I will take care of this :) > > 2) What happens if the current frequency is outside the low/high range? The > hwseek spec says that the seek starts from the current frequency, so that > might > mean that hwseek returns -ERANGE in this case. > > Regards, > > Hans -- Regards Halli -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
Hi Hans, On 07/11/2012 08:01 PM, Hans Verkuil wrote: Hi Hans, Thanks for the patch. I've CC-ed Halli as well. On Wed July 11 2012 17:47:34 Hans de Goede wrote: To allow apps to limit a hw-freq-seek to a specific band, for further info see the documentation this patch adds for these new fields. Signed-off-by: Hans de Goede --- .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 44 include/linux/videodev2.h |5 ++- 2 files changed, 40 insertions(+), 9 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index f4db44d..50dc9f8 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -52,11 +52,21 @@ Start a hardware frequency seek from the current frequency. To do this applications initialize the tuner, type, seek_upward, -spacing and -wrap_around fields, and zero out the -reserved array of a &v4l2-hw-freq-seek; and -call the VIDIOC_S_HW_FREQ_SEEK ioctl with a pointer -to this structure. +wrap_around, spacing, +rangelow and rangehigh +fields, and zero out the reserved array of a +&v4l2-hw-freq-seek; and call the VIDIOC_S_HW_FREQ_SEEK +ioctl with a pointer to this structure. + +The rangelow and +rangehigh fields can be set to a non-zero value to +tell the driver to search a specific band. If the &v4l2-tuner; +capability field has the +V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag set, these values +must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If +the V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag is not set, +then these values must exactly match those of one of the bands returned by +&VIDIOC-ENUM-FREQ-BANDS;. OK, I have some questions here: 1) If you have a multiband tuner, what should happen if both low and high are zero? Currently it is undefined, other than that the seek should start from the current frequency until it reaches some limit. That would be driver specific, we could add the same "If rangelow/high is zero a reasonable default value is used." language as used for the spacing. For example for the si470x if both are zero I simply switch to the "Japan wide" band which covers all frequencies handled by the other bands, but if there is no such covers all ranges band, then the logical thing todo would just keep the band as is (so as determined by the last s_freq). Halli, what does your hardware do? In particular, is the hwseek limited by the US/Europe or Japan band range or can it do the full range? If I'm not mistaken it is the former, right? If it is the former, then you need to explicitly set low + high to ensure that the hwseek uses the correct range because the driver can't guess which of the overlapping bands to use. 2) What happens if the current frequency is outside the low/high range? The hwseek spec says that the seek starts from the current frequency, so that might mean that hwseek returns -ERANGE in this case. What the si470x code currently does is just clamp the frequency to the new range before seeking, but -ERANGE works for me too. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: video: USB webcam fails since kernel 3.2
2012/7/11 Jean-Francois Moine : > On Wed, 11 Jul 2012 16:43:47 +0300 > Martin-Éric Racine wrote: > >> > Jean-Francois, can you perhaps make a patch against my latest tree for >> > the po / PO3130 changes in your tarbal? >> >> Noted. Hopefully, the Debian kernel team can contribute to the >> backporting part, since it's needed for the upcoming stable release. > > I had many problems with the vc032x driver, and the source code is very > different from the code in the official kernels. > > As I have no webcam, Martin-Éric, may I ask you to test the backport > I will do? It will be done only in the vc032x driver, so you could keep > the working gspca_vc032x.ko file you have and restore it between the > tests. I still lack the sensor type of your webcam. May you send me the > result of: > > dmesg | fgrep gspca [ 11.834852] gspca_main: v2.15.18 registered [ 11.844262] gspca_main: vc032x-2.15.18 probing 0ac8:0321 [ 11.844682] gspca_vc032x: vc0321 check sensor header 2c [ 11.850304] gspca_vc032x: Sensor ID 3130 (0) [ 11.850309] gspca_vc032x: Find Sensor PO3130NC [ 11.851809] gspca_main: video0 created Backport would be needed against 3.2.21 as this is what Debian will (probably) release with. Cheers! Martin-Éric -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
Hi Hans, Thanks for the patch. I've CC-ed Halli as well. On Wed July 11 2012 17:47:34 Hans de Goede wrote: > To allow apps to limit a hw-freq-seek to a specific band, for further > info see the documentation this patch adds for these new fields. > > Signed-off-by: Hans de Goede > --- > .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 44 > > include/linux/videodev2.h |5 ++- > 2 files changed, 40 insertions(+), 9 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml > b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml > index f4db44d..50dc9f8 100644 > --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml > +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml > @@ -52,11 +52,21 @@ > Start a hardware frequency seek from the current frequency. > To do this applications initialize the tuner, > type, seek_upward, > -spacing and > -wrap_around fields, and zero out the > -reserved array of a &v4l2-hw-freq-seek; and > -call the VIDIOC_S_HW_FREQ_SEEK ioctl with a pointer > -to this structure. > +wrap_around, spacing, > +rangelow and rangehigh > +fields, and zero out the reserved array of a > +&v4l2-hw-freq-seek; and call the VIDIOC_S_HW_FREQ_SEEK > +ioctl with a pointer to this structure. > + > +The rangelow and > +rangehigh fields can be set to a non-zero value to > +tell the driver to search a specific band. If the &v4l2-tuner; > +capability field has the > +V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag set, these values > +must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If > +the V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag is not set, > +then these values must exactly match those of one of the bands returned by > +&VIDIOC-ENUM-FREQ-BANDS;. OK, I have some questions here: 1) If you have a multiband tuner, what should happen if both low and high are zero? Currently it is undefined, other than that the seek should start from the current frequency until it reaches some limit. Halli, what does your hardware do? In particular, is the hwseek limited by the US/Europe or Japan band range or can it do the full range? If I'm not mistaken it is the former, right? If it is the former, then you need to explicitly set low + high to ensure that the hwseek uses the correct range because the driver can't guess which of the overlapping bands to use. 2) What happens if the current frequency is outside the low/high range? The hwseek spec says that the seek starts from the current frequency, so that might mean that hwseek returns -ERANGE in this case. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: video: USB webcam fails since kernel 3.2
On Wed, 11 Jul 2012 16:43:47 +0300 Martin-Éric Racine wrote: > > Jean-Francois, can you perhaps make a patch against my latest tree for > > the po / PO3130 changes in your tarbal? > > Noted. Hopefully, the Debian kernel team can contribute to the > backporting part, since it's needed for the upcoming stable release. I had many problems with the vc032x driver, and the source code is very different from the code in the official kernels. As I have no webcam, Martin-Éric, may I ask you to test the backport I will do? It will be done only in the vc032x driver, so you could keep the working gspca_vc032x.ko file you have and restore it between the tests. I still lack the sensor type of your webcam. May you send me the result of: dmesg | fgrep gspca I'll contact you directly (with copy to Hans de Goede) as soon as I will have something to propose. Thanks by advance. -- 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] V4L: soc-camera: add selection API host operations
Hi Laurent
On Fri, 6 Jul 2012, Laurent Pinchart wrote:
> Hi Guennadi,
>
> Thanks for the patch.
>
> On Friday 22 June 2012 18:40:08 Guennadi Liakhovetski wrote:
> > Add .get_selection() and .set_selection() soc-camera host driver
> > operations. Additionally check, that the user is not trying to change the
> > output sizes during a running capture.
>
> How will that interact with the crop operations ? The goal is to move away
> from crop operations to selection operations, so we need to establish clear
> rules.
Nicely:-) My understanding is, that the V4L2 core now is doing a large
part (all of?) compatibility / conversion work? As you know, soc-camera is
a kind of a glue layer between the V4L2 core and host drivers with some
helper functionality for client drivers. All V4L2 API calls go via the
soc-camera core and most of them are passed, possibly after some
preprocessing, to host drivers. Same holds for cropping and selection
calls. They are passed on to host drivers. As long as drivers use the
cropping API, the soc-camera core has to support it. Only after all host
drivers have been ported over, the soc-camera core can abandon it too. I
don't see another way out, do you?
Thanks
Guennadi
> > Signed-off-by: Guennadi Liakhovetski
> > ---
> > diff --git a/drivers/media/video/soc_camera.c
> > b/drivers/media/video/soc_camera.c index 0421bf9..72798d2 100644
> > --- a/drivers/media/video/soc_camera.c
> > +++ b/drivers/media/video/soc_camera.c
> > @@ -902,6 +902,65 @@ static int soc_camera_s_crop(struct file *file, void
> > *fh, return ret;
> > }
> >
> > +static int soc_camera_g_selection(struct file *file, void *fh,
> > + struct v4l2_selection *s)
> > +{
> > + struct soc_camera_device *icd = file->private_data;
> > + struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
> > +
> > + /* With a wrong type no need to try to fall back to cropping */
> > + if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> > + return -EINVAL;
> > +
> > + if (!ici->ops->get_selection)
> > + return -ENOTTY;
> > +
> > + return ici->ops->get_selection(icd, s);
> > +}
> > +
> > +static int soc_camera_s_selection(struct file *file, void *fh,
> > + struct v4l2_selection *s)
> > +{
> > + struct soc_camera_device *icd = file->private_data;
> > + struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
> > + int ret;
> > +
> > + /* In all these cases cropping emulation will not help */
> > + if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE ||
> > + (s->target != V4L2_SEL_TGT_COMPOSE_ACTIVE &&
> > +s->target != V4L2_SEL_TGT_CROP_ACTIVE))
> > + return -EINVAL;
> > +
> > + if (s->target == V4L2_SEL_TGT_COMPOSE_ACTIVE) {
> > + /* No output size change during a running capture! */
> > + if (is_streaming(ici, icd) &&
> > + (icd->user_width != s->r.width ||
> > +icd->user_height != s->r.height))
> > + return -EBUSY;
> > +
> > + /*
> > +* Only one user is allowed to change the output format, touch
> > +* buffers, start / stop streaming, poll for data
> > +*/
> > + if (icd->streamer && icd->streamer != file)
> > + return -EBUSY;
> > + }
> > +
> > + if (!ici->ops->set_selection)
> > + return -ENOTTY;
> > +
> > + ret = ici->ops->set_selection(icd, s);
> > + if (!ret &&
> > + s->target == V4L2_SEL_TGT_COMPOSE_ACTIVE) {
> > + icd->user_width = s->r.width;
> > + icd->user_height = s->r.height;
> > + if (!icd->streamer)
> > + icd->streamer = file;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > static int soc_camera_g_parm(struct file *file, void *fh,
> > struct v4l2_streamparm *a)
> > {
> > @@ -1405,6 +1464,8 @@ static const struct v4l2_ioctl_ops
> > soc_camera_ioctl_ops = { .vidioc_cropcap = soc_camera_cropcap,
> > .vidioc_g_crop = soc_camera_g_crop,
> > .vidioc_s_crop = soc_camera_s_crop,
> > + .vidioc_g_selection = soc_camera_g_selection,
> > + .vidioc_s_selection = soc_camera_s_selection,
> > .vidioc_g_parm = soc_camera_g_parm,
> > .vidioc_s_parm = soc_camera_s_parm,
> > .vidioc_g_chip_ident = soc_camera_g_chip_ident,
> > diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> > index d865dcf..f997d6a 100644
> > --- a/include/media/soc_camera.h
> > +++ b/include/media/soc_camera.h
> > @@ -86,6 +86,8 @@ struct soc_camera_host_ops {
> > int (*cropcap)(struct soc_camera_device *, struct v4l2_cropcap *);
> > int (*get_crop)(struct soc_camera_device *, struct v4l2_crop *);
> > int (*set_crop)(struct soc_camera_device *, struct v4l2_crop *);
> > + int (*get_selection)(struct soc_camera_device *, struct v4l2_selection
> *);
> > + int (*set_selection)(s
[PATCH 2/5] radio-si470x: restore ctrl settings after suspend/resume
Signed-off-by: Hans de Goede
---
drivers/media/radio/si470x/radio-si470x-usb.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c
b/drivers/media/radio/si470x/radio-si470x-usb.c
index 40b963c..0204cf4 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -792,11 +792,16 @@ static int si470x_usb_driver_suspend(struct usb_interface
*intf,
static int si470x_usb_driver_resume(struct usb_interface *intf)
{
struct si470x_device *radio = usb_get_intfdata(intf);
+ int ret;
dev_info(&intf->dev, "resuming now...\n");
/* start radio */
- return si470x_start_usb(radio);
+ ret = si470x_start_usb(radio);
+ if (ret == 0)
+ v4l2_ctrl_handler_setup(&radio->hdl);
+
+ return ret;
}
--
1.7.10.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 4/5] radio-si470x: Add support for the new band APIs
Signed-off-by: Hans de Goede
---
drivers/media/radio/si470x/radio-si470x-common.c | 215 +-
drivers/media/radio/si470x/radio-si470x-i2c.c|1 +
drivers/media/radio/si470x/radio-si470x-usb.c|1 +
drivers/media/radio/si470x/radio-si470x.h|1 +
4 files changed, 126 insertions(+), 92 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-common.c
b/drivers/media/radio/si470x/radio-si470x-common.c
index 84ab3d57..9e38132 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -4,6 +4,7 @@
* Driver for radios with Silicon Labs Si470x FM Radio Receivers
*
* Copyright (c) 2009 Tobias Lorenz
+ * Copyright (c) 2012 Hans de Goede
*
* 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
@@ -127,14 +128,6 @@ static unsigned short space = 2;
module_param(space, ushort, 0444);
MODULE_PARM_DESC(space, "Spacing: 0=200kHz 1=100kHz *2=50kHz*");
-/* Bottom of Band (MHz) */
-/* 0: 87.5 - 108 MHz (USA, Europe)*/
-/* 1: 76 - 108 MHz (Japan wide band) */
-/* 2: 76 - 90 MHz (Japan) */
-static unsigned short band = 1;
-module_param(band, ushort, 0444);
-MODULE_PARM_DESC(band, "Band: 0=87.5..108MHz *1=76..108MHz* 2=76..90MHz");
-
/* De-emphasis */
/* 0: 75 us (USA) */
/* 1: 50 us (Europe, Australia, Japan) */
@@ -152,13 +145,61 @@ static unsigned int seek_timeout = 5000;
module_param(seek_timeout, uint, 0644);
MODULE_PARM_DESC(seek_timeout, "Seek timeout: *5000*");
-
+static const struct v4l2_frequency_band bands[] = {
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 0,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 87500 * 16,
+ .rangehigh = 108000 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 1,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 76000 * 16,
+ .rangehigh = 108000 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+ {
+ .type = V4L2_TUNER_RADIO,
+ .index = 2,
+ .capability = V4L2_TUNER_CAP_LOW | V4L2_TUNER_CAP_STEREO |
+ V4L2_TUNER_CAP_RDS | V4L2_TUNER_CAP_RDS_BLOCK_IO |
+ V4L2_TUNER_CAP_HWSEEK_BOUNDED |
+ V4L2_TUNER_CAP_HWSEEK_WRAP,
+ .rangelow = 76000 * 16,
+ .rangehigh = 9 * 16,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+};
/**
* Generic Functions
**/
/*
+ * si470x_set_band - set the band
+ */
+static int si470x_set_band(struct si470x_device *radio, int band)
+{
+ if (radio->band == band)
+ return 0;
+
+ radio->band = band;
+ radio->registers[SYSCONFIG2] &= ~SYSCONFIG2_BAND;
+ radio->registers[SYSCONFIG2] |= radio->band << 6;
+ return si470x_set_register(radio, SYSCONFIG2);
+}
+
+/*
* si470x_set_chan - set the channel
*/
static int si470x_set_chan(struct si470x_device *radio, unsigned short chan)
@@ -194,48 +235,39 @@ done:
return retval;
}
-
/*
- * si470x_get_freq - get the frequency
+ * si470x_get_step - get channel spacing
*/
-static int si470x_get_freq(struct si470x_device *radio, unsigned int *freq)
+static unsigned int si470x_get_step(struct si470x_device *radio)
{
- unsigned int spacing, band_bottom;
- unsigned short chan;
- int retval;
-
/* Spacing (kHz) */
switch ((radio->registers[SYSCONFIG2] & SYSCONFIG2_SPACE) >> 4) {
/* 0: 200 kHz (USA, Australia) */
case 0:
- spacing = 0.200 * FREQ_MUL; break;
+ return 200 * 16;
/* 1: 100 kHz (Europe, Japan) */
case 1:
- spacing = 0.100 * FREQ_MUL; break;
+ return 100 * 16;
/* 2: 50 kHz */
default:
- spacing = 0.050 * FREQ_MUL; break;
+ return 50 * 16;
};
+}
- /* Bottom of Band (MHz) */
- switch ((radio->registers[SYSCONFIG2] & SYSCONFIG2_BAND) >> 6) {
- /* 0: 87.5 - 108 MHz (USA, Europe) */
- case 0:
- band_bottom = 87.5 * FREQ_MUL; break;
-
[PATCH 5/5] radio-si470x: Lower firmware version requirements
Testing with a firmware version 12 usb radio stick has shown version 12
to work fine too.
Reported-by: Antti Palosaari
Signed-off-by: Hans de Goede
---
drivers/media/radio/si470x/radio-si470x.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/radio/si470x/radio-si470x.h
b/drivers/media/radio/si470x/radio-si470x.h
index 8e3a62f..2f089b4 100644
--- a/drivers/media/radio/si470x/radio-si470x.h
+++ b/drivers/media/radio/si470x/radio-si470x.h
@@ -190,7 +190,7 @@ struct si470x_device {
* Firmware Versions
**/
-#define RADIO_FW_VERSION 14
+#define RADIO_FW_VERSION 12
--
1.7.10.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 3/5] radio-si470x: Fix band selection
The mask was wrong resulting in band 0 and 1 always ending up as band 0 in the register. Signed-off-by: Hans de Goede --- drivers/media/radio/si470x/radio-si470x.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/radio/si470x/radio-si470x.h b/drivers/media/radio/si470x/radio-si470x.h index b3b612f..11f14b6 100644 --- a/drivers/media/radio/si470x/radio-si470x.h +++ b/drivers/media/radio/si470x/radio-si470x.h @@ -87,7 +87,7 @@ #define SYSCONFIG2 5 /* System Configuration 2 */ #define SYSCONFIG2_SEEKTH 0xff00 /* bits 15..08: RSSI Seek Threshold */ -#define SYSCONFIG2_BAND0x0080 /* bits 07..06: Band Select */ +#define SYSCONFIG2_BAND0x00c0 /* bits 07..06: Band Select */ #define SYSCONFIG2_SPACE 0x0030 /* bits 05..04: Channel Spacing */ #define SYSCONFIG2_VOLUME 0x000f /* bits 03..00: Volume */ -- 1.7.10.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 1/5] v4l2: Add rangelow and rangehigh fields to the v4l2_hw_freq_seek struct
To allow apps to limit a hw-freq-seek to a specific band, for further
info see the documentation this patch adds for these new fields.
Signed-off-by: Hans de Goede
---
.../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml| 44
include/linux/videodev2.h |5 ++-
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
index f4db44d..50dc9f8 100644
--- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
@@ -52,11 +52,21 @@
Start a hardware frequency seek from the current frequency.
To do this applications initialize the tuner,
type, seek_upward,
-spacing and
-wrap_around fields, and zero out the
-reserved array of a &v4l2-hw-freq-seek; and
-call the VIDIOC_S_HW_FREQ_SEEK ioctl with a pointer
-to this structure.
+wrap_around, spacing,
+rangelow and rangehigh
+fields, and zero out the reserved array of a
+&v4l2-hw-freq-seek; and call the VIDIOC_S_HW_FREQ_SEEK
+ioctl with a pointer to this structure.
+
+The rangelow and
+rangehigh fields can be set to a non-zero value to
+tell the driver to search a specific band. If the &v4l2-tuner;
+capability field has the
+V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag set, these values
+must fall within one of the bands returned by &VIDIOC-ENUM-FREQ-BANDS;. If
+the V4L2_TUNER_CAP_HWSEEK_PROG_LIM flag is not set,
+then these values must exactly match those of one of the bands returned by
+&VIDIOC-ENUM-FREQ-BANDS;.
If an error is returned, then the original frequency will
be restored.
@@ -102,7 +112,23 @@ field and the &v4l2-tuner;
index field.
__u32
- reserved[7]
+ rangelow
+ If non-zero, the lowest tunable frequency of the band to
+search in units of 62.5 kHz, or if the &v4l2-tuner;
+capability field has the
+V4L2_TUNER_CAP_LOW flag set, in units of 62.5 Hz.
+
+
+ __u32
+ rangehigh
+ If non-zero, the highest tunable frequency of the band to
+search in units of 62.5 kHz, or if the &v4l2-tuner;
+capability field has the
+V4L2_TUNER_CAP_LOW flag set, in units of 62.5 Hz.
+
+
+ __u32
+ reserved[5]
Reserved for future extensions. Applications
must set the array to zero.
@@ -119,8 +145,10 @@ field and the &v4l2-tuner;
index field.
EINVAL
The tuner index is out of
-bounds, the wrap_around value is not supported or the value in the
type field is
-wrong.
+bounds, the wrap_around value is not supported or
+one of the values in the type,
+rangelow or rangehigh
+fields is wrong.
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 9fa822a..1c6aa63 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2029,6 +2029,7 @@ struct v4l2_modulator {
#define V4L2_TUNER_CAP_RDS_BLOCK_IO0x0100
#define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
#define V4L2_TUNER_CAP_FREQ_BANDS 0x0400
+#define V4L2_TUNER_CAP_HWSEEK_PROG_LIM 0x0800
/* Flags for the 'rxsubchans' field */
#define V4L2_TUNER_SUB_MONO0x0001
@@ -2074,7 +2075,9 @@ struct v4l2_hw_freq_seek {
__u32 seek_upward;
__u32 wrap_around;
__u32 spacing;
- __u32 reserved[7];
+ __u32 rangelow;
+ __u32 rangehigh;
+ __u32 reserved[5];
};
/*
--
1.7.10.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
RFC: Add support for limiting hw freq seeks to a certain band
This patchset, which builds on top of hverkuil's bands2 branch, which adds the VIDIOC_ENUM_FREQ_BANDS API, add support for limiting hw freq seeks to one of the bands from VIDIOC_ENUM_FREQ_BANDS, or a subset there of. The first patch introduces the new API and documents its, the other patches are patches to the si470x radio driver, implementing the new API, and removing the band module parameter as this is no longer needed with this new API. A git tree with all hverkuils patches included is here: http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/media-for_v3.6-wip A git tree of xawtv3 with its radio app modified to support the new API is here: http://git.linuxtv.org/hgoede/xawtv3.git/shortlog/refs/heads/band-support Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] media: mx2_camera: Fix mbus format handling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
From: Javier Martin
Do not use MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags. The driver
must negotiate with the attached sensor whether the mbus format is UYUV or
YUYV and set CSICR1 configuration accordingly.
This is needed for the video function on mach-imx27_visstrim_m10.c to
perform properly, since an earlier version of this patch has been proven
wrong and has been reverted and a commit, depending on it: "[media]
i.MX27: visstrim_m10: Remove use of MX2_CAMERA_SWAP16" is in the mainline.
Signed-off-by: Javier Martin
Reviewed-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
[g.liakhovet...@gmx.de: move a macro definition to a more logical place]
Signed-off-by: Guennadi Liakhovetski
- ---
Hi Linus
Please, apply this patch to 3.5. Normally it would go via Mauro's media
tree, but he is on a holiday atm. and might not return in time for the 3.5
final release. Mauro has reviewed an earlier version of this patch and
confirmed, that the breakage risk is sufficiently low, so, he agreed to me
sending this patch directly to you with an ack from one more active V4L2
maintainer (Laurent).
Thanks
Guennadi
drivers/media/video/mx2_camera.c | 27 ++-
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 41f9a25..637bde8 100644
- --- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -83,6 +83,7 @@
#define CSICR1_INV_DATA(1 << 3)
#define CSICR1_INV_PCLK(1 << 2)
#define CSICR1_REDGE (1 << 1)
+#define CSICR1_FMT_MASK(CSICR1_PACK_DIR | CSICR1_SWAP16_EN)
#define SHIFT_STATFF_LEVEL 22
#define SHIFT_RXFF_LEVEL 19
@@ -230,6 +231,7 @@ struct mx2_prp_cfg {
u32 src_pixel;
u32 ch1_pixel;
u32 irq_flags;
+ u32 csicr1;
};
/* prp resizing parameters */
@@ -330,6 +332,7 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
.ch1_pixel = 0x2ca00565, /* RGB565 */
.irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
PRP_INTR_CH1FC | PRP_INTR_LBOVF,
+ .csicr1 = 0,
}
},
{
@@ -343,6 +346,21 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
.irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
PRP_INTR_CH2FC | PRP_INTR_LBOVF |
PRP_INTR_CH2OVF,
+ .csicr1 = CSICR1_PACK_DIR,
+ }
+ },
+ {
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUV420,
+ .cfg= {
+ .channel= 2,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
+ PRP_INTR_CH2FC | PRP_INTR_LBOVF |
+ PRP_INTR_CH2OVF,
+ .csicr1 = CSICR1_SWAP16_EN,
}
},
};
@@ -1015,14 +1033,14 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
return ret;
}
+ csicr1 = (csicr1 & ~CSICR1_FMT_MASK) | pcdev->emma_prp->cfg.csicr1;
+
if (common_flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
if (common_flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_HSYNC_POL;
- - if (pcdev->platform_flags & MX2_CAMERA_SWAP16)
- - csicr1 |= CSICR1_SWAP16_EN;
if (pcdev->platform_flags & MX2_CAMERA_EXT_VSYNC)
csicr1 |= CSICR1_EXT_VSYNC;
if (pcdev->platform_flags & MX2_CAMERA_CCIR)
@@ -1033,8 +1051,6 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
csicr1 |= CSICR1_GCLK_MODE;
if (pcdev->platform_flags & MX2_CAMERA_INV_DATA)
csicr1 |= CSICR1_INV_DATA;
- - if (pcdev->platform_flags & MX2_CAMERA_PACK_DIR_MSB)
- - csicr1 |= CSICR1_PACK_DIR;
pcdev->csicr1 = csicr1;
@@ -1109,7 +1125,8 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
return 0;
}
- - if (code == V4L2_MBUS_FMT_YUYV8_2X8) {
+ if (code == V4L2_MBUS_FMT_YUYV8_2X8 ||
+ code == V4L2_MBUS_FMT_UYVY8_2X8) {
formats++;
if (xlate) {
/*
- --
1.7.2.5
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU
[PATCH] [media] adv7180.c: convert to v4l2 control framework
Signed-off-by: Federico Vaga
---
drivers/media/video/adv7180.c | 235 +++--
1 file changed, 84 insertions(+), 151 deletions(-)
diff --git a/drivers/media/video/adv7180.c b/drivers/media/video/adv7180.c
index 174bffa..07bb550 100644
--- a/drivers/media/video/adv7180.c
+++ b/drivers/media/video/adv7180.c
@@ -26,11 +26,10 @@
#include
#include
#include
+#include
#include
#include
-#define DRIVER_NAME "adv7180"
-
#define ADV7180_INPUT_CONTROL_REG 0x00
#define ADV7180_INPUT_CONTROL_AD_PAL_BG_NTSC_J_SECAM 0x00
#define ADV7180_INPUT_CONTROL_AD_PAL_BG_NTSC_J_SECAM_PED 0x10
@@ -55,21 +54,21 @@
#define ADV7180_AUTODETECT_ENABLE_REG 0x07
#define ADV7180_AUTODETECT_DEFAULT 0x7f
-
+/* Contrast */
#define ADV7180_CON_REG0x08/*Unsigned */
-#define CON_REG_MIN0
-#define CON_REG_DEF128
-#define CON_REG_MAX255
-
+#define ADV7180_CON_MIN0
+#define ADV7180_CON_DEF128
+#define ADV7180_CON_MAX255
+/* Brightness*/
#define ADV7180_BRI_REG0x0a/*Signed */
-#define BRI_REG_MIN-128
-#define BRI_REG_DEF0
-#define BRI_REG_MAX127
-
+#define ADV7180_BRI_MIN-128
+#define ADV7180_BRI_DEF0
+#define ADV7180_BRI_MAX127
+/* Hue */
#define ADV7180_HUE_REG0x0b/*Signed, inverted */
-#define HUE_REG_MIN-127
-#define HUE_REG_DEF0
-#define HUE_REG_MAX128
+#define ADV7180_HUE_MIN-127
+#define ADV7180_HUE_DEF0
+#define ADV7180_HUE_MAX128
#define ADV7180_ADI_CTRL_REG 0x0e
#define ADV7180_ADI_CTRL_IRQ_SPACE 0x20
@@ -98,12 +97,12 @@
#define ADV7180_ICONF1_ACTIVE_LOW 0x01
#define ADV7180_ICONF1_PSYNC_ONLY 0x10
#define ADV7180_ICONF1_ACTIVE_TO_CLR 0xC0
-
+/* Saturation */
#define ADV7180_SD_SAT_CB_REG 0xe3/*Unsigned */
#define ADV7180_SD_SAT_CR_REG 0xe4/*Unsigned */
-#define SAT_REG_MIN0
-#define SAT_REG_DEF128
-#define SAT_REG_MAX255
+#define ADV7180_SAT_MIN0
+#define ADV7180_SAT_DEF128
+#define ADV7180_SAT_MAX255
#define ADV7180_IRQ1_LOCK 0x01
#define ADV7180_IRQ1_UNLOCK0x02
@@ -121,18 +120,18 @@
#define ADV7180_NTSC_V_BIT_END_MANUAL_NVEND0x4F
struct adv7180_state {
+ struct v4l2_ctrl_handler ctrl_hdl;
struct v4l2_subdev sd;
struct work_struct work;
struct mutexmutex; /* mutual excl. when accessing chip */
int irq;
v4l2_std_id curr_norm;
boolautodetect;
- s8 brightness;
- s16 hue;
- u8 contrast;
- u8 saturation;
u8 input;
};
+#define to_adv7180_sd(_ctrl) &container_of(_ctrl->handler, \
+ struct adv7180_state,\
+ ctrl_hdl)->sd
static v4l2_std_id adv7180_std_to_v4l2(u8 status1)
{
@@ -237,7 +236,7 @@ static int adv7180_s_routing(struct v4l2_subdev *sd, u32
input,
if (ret)
return ret;
- /*We cannot discriminate between LQFP and 40-pin LFCSP, so accept
+ /* We cannot discriminate between LQFP and 40-pin LFCSP, so accept
* all inputs and let the card driver take care of validation
*/
if ((input & ADV7180_INPUT_CONTROL_INSEL_MASK) != input)
@@ -316,117 +315,39 @@ out:
return ret;
}
-static int adv7180_queryctrl(struct v4l2_subdev *sd, struct v4l2_queryctrl *qc)
-{
- switch (qc->id) {
- case V4L2_CID_BRIGHTNESS:
- return v4l2_ctrl_query_fill(qc, BRI_REG_MIN, BRI_REG_MAX,
- 1, BRI_REG_DEF);
- case V4L2_CID_HUE:
- return v4l2_ctrl_query_fill(qc, HUE_REG_MIN, HUE_REG_MAX,
- 1, HUE_REG_DEF);
- case V4L2_CID_CONTRAST:
- return v4l2_ctrl_query_fill(qc, CON_REG_MIN, CON_REG_MAX,
- 1, CON_REG_DEF);
- case V4L2_CID_SATURATION:
- return v4l2_ctrl_query_fill(qc, SAT_REG_MIN, SAT_REG_MAX,
- 1, SAT_REG_DEF);
- default:
- break;
- }
-
- return -EINVAL;
-}
-
-static int adv7180_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
-{
- struct adv7180_state *state = to_state(sd);
- int ret = mutex_lock_interruptible(&state->mutex);
- if (ret)
- return ret;
-
- switch (ctrl->id) {
- case V4L2_CID_BRIGHTNESS:
[RFC] media DT bindings
Hi all
Background
==
With ARM adoption of flat Device Trees a need arises to move platform
device descriptions and their data from platform files to DT. This has
also to be done for media devices, e.g., video capture and output
interfaces, data processing devices, camera sensors, TV decoders and
encoders. This RFC is trying to spawn a discussion to define standard V4L
DT bindings. The first version will concentrate on the capture path,
mostly taking care of simple capture-interface - camera sensor / TV
decoder configurations. Since the author is not working intensively yet
with the Media Controller API, pad-level configuration, these topics might
be underrepresented in this RFC. I hope others, actively working in these
areas, will fill me in on them.
Overview
As mentioned above, typical configurations, that we'll be dealing with
consist of a DMA data capture engine, one or more data sources like camera
sensors, possibly some data processing units. Data capture and processing
engines are usually platform devices, whereas data source devices are
typically I2C slaves. Apart from defining each device we'll also describe
connections between them as well as properties of those connections.
Capture devices
==
These are usually platform devices, integrated into respective SoCs. There
also exist external image processing devices, but they are rare. Obvious
differences between them and integrated devices include a different bus
attribution and a need to explicitly describe the connection to the SoC.
As far as capture devices are concerned, their configuration will
typically include a few device-specific bindings, as well as standard
ones. Standard bindings will include the usual "reg," "interrupts,"
"clock-frequency" properties.
It is more complex to describe external links. We need to describe
configurations, used with various devices, attached to various pads. It is
proposed to describe such links as child nodes. Each such link will
reference a client pad, a local pad and specify the bus configuration. The
media bus can be either parallel or serial, e.g., MIPI CSI-2. It is
proposed to describe both the bus-width in the parallel case and the
number of lanes in the serial case, using the standard "bus-width"
property.
On the parallel bus common properties include signal polarities, possibly
data line shift (8 if lines 15:8 are used, 2 if 9:2, and 0 if lines 7:0),
protocol (e.g., BT.656). Additionally device-specific properties can be
defined.
A MIPI CSI-2 bus common properties would include, apart from the number of
lanes, routed to that client, the clock frequency, a channel number,
possibly CRC and ECC flags.
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = "renesas,sh-mobile-ceu";
reg = <0xfe91 0xa0>;
interrupts = <0x880>;
bus-width = <16>; /* #lines routed on the board */
clock-frequency = <5000>; /* max clock */
#address-cells = <1>;
#size-cells = <0>;
...
ov772x-1 = {
reg = <0>;
client = <&ov772x@0x21-0>;
local-pad = "parallel-sink";
remote-pad = "parallel-source";
bus-width = <8>;/* used data lines */
data-shift = <0>; /* lines 7:0 are used */
hsync-active = <1>; /* active high */
vsync-active = <1>; /* active high */
pclk-sample = <1>; /* rising */
clock-frequency = <2400>;
};
};
Client devices
==
Client nodes are children on their respective busses, e.g., i2c. This
placement leads to these devices being possibly probed before respective
host interfaces, which will fail due to known reasons. Therefore client
drivers have to be adapted to request a delayed probing, as long as the
respective video host hasn't probed.
Client nodes will include all the properties, usual for their busses.
Additionally they will specify properties private to this device type and
common for all V4L2 client devices - device global and per-link. I think,
we should make it possible to define client devices, that can at run-time
be connected to different sinks, even though such configurations might not
be very frequent. To achieve this we also specify link information in
child devices, similar to those in host nodes above. This also helps
uniformity and will let us implement and use a universal link-binding
parser. So, a node, that has been referenced above could look like
ov772x@0x21-0 = {
compatible = "omnivision,ov772x";
reg = <0x21>;
vdd-supply = <®ulator>;
b
Add V4l2 camera driver for Marvell PXA910/PXA688/PXA2128 CCIC
Hi, Guennadi & Jonathan As we have discussed 2 months ago, we make the updated version of mmp_camera driver which based on kernel 3.4 for support Marvell MMP soc family. So could you please find time to take a look at this patch? Thank you very much! Thanks Albert Wang 86-21-61092656 -Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Sunday, 13 May, 2012 03:05 To: Albert Wang Cc: Jonathan Corbet; Linux Media Mailing List; Mauro Carvalho Chehab; Chao Xie; Angela Wan; Kassey Lee; Albert Subject: RE: marvell-ccic: lacks of some features Hi Albert On Fri, 11 May 2012, Albert Wang wrote: > Hi, Jonathan > > Nice to meet you! > > We must clarify that it's not our target to replace your marvell-ccic > by our mv_camera in the tree > > We just hope you can help to review our mv_camera patches and discuss > if can put it in tree, because it may support more and better for > Marvell Soc chips. > There is no conflict between your marvell-ccic which support OLPC and > our mv_camera which support most Marvell platforms. > Actually we are willing to add support on OLPC. :) Thanks for continuing your work on the mv_camera driver and for your effort to integrate it into the mainline! We certainly want to support new hardware types and features. So, we're certainly glad to hear, that your driver supports features, not presently available in the mainline. As you certainly understand, we also want to reuse kernel code as much as possible. Drivers for the same IP block in different packaging, with different interfaces even with slight differences in functionality is one such example. Therefore, we certainly would _very much_ prefer having your driver and marvell-ccic share as much code as possible. It would be interesting to know: have you actually tried to build your driver around the marvell-ccic code-base? If yes - how did it go? What difficulties did you encounter? If no - have you considered doing so? If yes - why have you decided against it? Have you considered a possibility of building your driver as an soc-camera driver, while still reusing the core functionality from marvell-ccic? Thanks Guennadi > OK, we will provide the patches for discussing. > Thank you very much! > > > Thanks > Albert Wang > -Original Message- > From: Jonathan Corbet [mailto:cor...@lwn.net] > Sent: Saturday, 12 May, 2012 00:28 > To: Albert Wang > Cc: 'Guennadi Liakhovetski'; Linux Media Mailing List; Mauro Carvalho > Chehab; Chao Xie; Angela Wan; Kassey Lee; Albert > Subject: Re: marvell-ccic: lacks of some features > > On Fri, 11 May 2012 09:02:26 -0700 > Albert Wang wrote: > > > Hi, Jonathan & Guennadi > > > > We used the marvell-ccic code and found it lacks of some features, > > but our Marvell Camera driver (mv_camera.c) which based on > > soc_camera can support all these features: > > The marvell-ccic driver has the features that were needed by the people doing > the work and that I had the documentation and hardware to support. > Of course it's incomplete. > > I'll go through your list, but, first: is the purpose of your message to > argue for a replacement of the marvell-ccic driver by your mv_camera driver? > I am not necessarily opposed to that idea if mv_camera can support deployed > systems back to the OLPC XO 1.0 and if it seems clear that a replacement > makes more sense than adding features to the in-tree driver. > > > 1. marvell-ccic only support MMP2 (PXA688), it can’t support other > > Marvell SOC chips Our mv_camera can support such as MMP3 (PXA2128), > > TD > > (PXA910/920) and so on besides MMP2 > > Which is cool. It is nice that Marvell is finally providing Linux support > for its camera controllers after all these years. For the last several > years, I've necessarily been limited in the controllers I could support. > Is it Marvell's intention to provide upstream maintenance and support going > forward? > > > 2. marvell-ccic only support parallel (DVP) mode, can’t support MIPI > > mode Our mv_camera can support both DVP mode and MIPI mode, MIPI > > interface is the trend of current camera sensors with high > > resolution > > Adding MIPI doesn't look that hard, I've just never had a reason (or > hardware) to do it. > > > > > 3. marvell-ccic only support ccic1 controller, can’t support ccic2 > > or dual ccic controllers As you known, both MMP2 and MMP3 have 2 > > ccic controllers, ccic2 is different with ccic1 Sometimes we need > > use both > > 2 ccic controllers for connecting 2 camera sensors Actually, we have > > used 2 ccic controllers' cases in our platforms Our mv_camera can > > support these cases: only use ccic1, only use ccic2 and use ccic1 + > > ccic2 > > It doesn't support two because nobody has asked for it, but the driver was > written with that in mind. I don't see supporting the second controller as a > big job. > > > 4. marvell-ccic only support camera sensor OV7670 It's an old and >
[PATCH 1/7] media: mmp_camera: Add V4l2 camera driver for Marvell PXA910/PXA688/PXA2128 CCIC
This v4l2 camera driver is based on soc-camera and videobuf2 framework
Support Marvell MMP Soc family TD-PXA910/MMP2-PXA688/MMP3-PXA2128 CCIC
Support Dual CCIC controllers on PXA688/PXA2128
Support MIPI-CSI2 mode and DVP-Parallel mode
Change-Id: I0d6156e29a278108dfb26dc1e891ca069e31666c
Signed-off-by: Albert Wang
---
arch/arm/mach-mmp/include/mach/camera.h| 21 +
arch/arm/mach-mmp/include/mach/regs-apmu.h |7 +-
drivers/media/video/Kconfig|9 +
drivers/media/video/Makefile |1 +
drivers/media/video/mmp_camera.c | 1134
drivers/media/video/mmp_camera.h | 241 ++
6 files changed, 1412 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-mmp/include/mach/camera.h
create mode 100644 drivers/media/video/mmp_camera.c
create mode 100644 drivers/media/video/mmp_camera.h
diff --git a/arch/arm/mach-mmp/include/mach/camera.h
b/arch/arm/mach-mmp/include/mach/camera.h
new file mode 100644
index 000..d13cd91
--- /dev/null
+++ b/arch/arm/mach-mmp/include/mach/camera.h
@@ -0,0 +1,21 @@
+#ifndef __ASM_ARCH_CAMERA_H__
+#define __ASM_ARCH_CAMERA_H__
+
+struct mmp_cam_pdata {
+ struct clk *clk[3]; /* CCIC_GATE, CCIC_RST, CCIC_DBG clocks */
+ char *name;
+ int clk_enabled;
+ int dphy[3];/* DPHY: CSI2_DPHY3, CSI2_DPHY5, CSI2_DPHY6 */
+ int bus_type;
+ int mipi_enabled; /* MIPI enabled flag */
+ int lane; /* ccic used lane number; 0 means DVP mode */
+ int dma_burst;
+ int mclk_min;
+ int mclk_src;
+ int mclk_div;
+ int (*init_clk)(struct device *dev, int init);
+ void (*enable_clk)(struct device *dev, int on);
+};
+
+#endif
+
diff --git a/arch/arm/mach-mmp/include/mach/regs-apmu.h
b/arch/arm/mach-mmp/include/mach/regs-apmu.h
index 8447ac6..5616340 100644
--- a/arch/arm/mach-mmp/include/mach/regs-apmu.h
+++ b/arch/arm/mach-mmp/include/mach/regs-apmu.h
@@ -19,7 +19,12 @@
/* Clock Reset Control */
#define APMU_IRE APMU_REG(0x048)
#define APMU_LCD APMU_REG(0x04c)
-#define APMU_CCIC APMU_REG(0x050)
+#define APMU_CCIC_GATE APMU_REG(0x028)
+#define APMU_CCIC_RST APMU_REG(0x050)
+#define APMU_CCIC_DBG APMU_REG(0x088)
+#define APMU_CCIC2_GATE APMU_REG(0x118)
+#define APMU_CCIC2_RST APMU_REG(0x0f4)
+#define APMU_CCIC2_DBG APMU_REG(0x088)
#define APMU_SDH0 APMU_REG(0x054)
#define APMU_SDH1 APMU_REG(0x058)
#define APMU_USB APMU_REG(0x05c)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index ce1e7ba..244d418 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1087,6 +1087,15 @@ config VIDEO_PXA27x
---help---
This is a v4l2 driver for the PXA27x Quick Capture Interface
+config VIDEO_MMP
+ tristate "Marvell MMP CCIC driver based on SOC_CAMERA"
+ depends on VIDEO_DEV && SOC_CAMERA
+ select VIDEOBUF2_DMA_CONTIG
+ ---help---
+ This is a v4l2 driver for the Marvell PXA910/PXA688/PXA2128 CCIC
+ To compile this driver as a module, choose M here: the module will
+ be called mmp_camera.
+
config VIDEO_SH_MOBILE_CSI2
tristate "SuperH Mobile MIPI CSI-2 Interface driver"
depends on VIDEO_DEV && SOC_CAMERA && HAVE_CLK
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index a6282a3..12defa7 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -178,6 +178,7 @@ obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
+obj-$(CONFIG_VIDEO_MMP)+= mmp_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
obj-$(CONFIG_VIDEO_OMAP1) += omap1_camera.o
diff --git a/drivers/media/video/mmp_camera.c b/drivers/media/video/mmp_camera.c
new file mode 100644
index 000..2e6cc5c
--- /dev/null
+++ b/drivers/media/video/mmp_camera.c
@@ -0,0 +1,1134 @@
+/*
+ * V4L2 Driver for Marvell Mobile SoC PXA910/PXA688/PXA2128 CCIC
+ * (CMOS Camera Interface Controller)
+ *
+ * This driver is based on soc_camera and videobuf2 framework,
+ * but part of the low level register function is base on cafe-driver.c
+ *
+ * Copyright 2006 One Laptop Per Child Association, Inc.
+ * Copyright 2006-7 Jonathan Corbet
+ *
+ * Copyright (C) 2011-2012, Marvell International Ltd.
+ * Kassey Lee
+ * Angela Wan
+ * Albert Wang
+ * Lei Wen
+ * Fangsuo Wu
+ * Sarah Zhang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later versio
Re: [PATCH RFC] [media] adv7180.c: convert to v4l2 control framework
On Wed 11 July 2012 16:19:02 Federico Vaga wrote:
> > > > @@ -445,9 +402,9 @@ static const struct v4l2_subdev_video_ops
> > > > adv7180_video_ops = {>
> > > > static const struct v4l2_subdev_core_ops adv7180_core_ops = {
> > > >
> > > > .g_chip_ident = adv7180_g_chip_ident,
> > > > .s_std = adv7180_s_std,
> > > >
> > > > - .queryctrl = adv7180_queryctrl,
> > > > - .g_ctrl = adv7180_g_ctrl,
> > > > - .s_ctrl = adv7180_s_ctrl,
> > > > + .queryctrl = v4l2_subdev_queryctrl,
> > > > + .g_ctrl = v4l2_subdev_g_ctrl,
> > > > + .s_ctrl = v4l2_subdev_s_ctrl,
> > >
> > > I'm not sure to undestand this point. I "grepped" for the adv7180
> > > and it seem that I'm the only user of the adv7180 (sta2x11 VIP
> > > driver). In the VIP driver I don't use the control framework (there
> > > aren't controls), so I think these lines must be there. Am I wrong?
> >
> > Correct. But once sta2x11 is converted to using the control framework,
> > then these lines can be dropped since no one else is using this
> > subdevice driver.
>
> What do you suggest? I re-submit this patch and when sta2x11 is fixed a
> I submit a new patch to remove these lines; or wait the full conversion
> of the sta2x11 driver and submit both patch?
Choice 1: when sta2x11 is fixed submit a new patch to remove those lines.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] [media] adv7180.c: convert to v4l2 control framework
> > > @@ -445,9 +402,9 @@ static const struct v4l2_subdev_video_ops
> > > adv7180_video_ops = {>
> > > static const struct v4l2_subdev_core_ops adv7180_core_ops = {
> > >
> > > .g_chip_ident = adv7180_g_chip_ident,
> > > .s_std = adv7180_s_std,
> > >
> > > - .queryctrl = adv7180_queryctrl,
> > > - .g_ctrl = adv7180_g_ctrl,
> > > - .s_ctrl = adv7180_s_ctrl,
> > > + .queryctrl = v4l2_subdev_queryctrl,
> > > + .g_ctrl = v4l2_subdev_g_ctrl,
> > > + .s_ctrl = v4l2_subdev_s_ctrl,
> >
> > I'm not sure to undestand this point. I "grepped" for the adv7180
> > and it seem that I'm the only user of the adv7180 (sta2x11 VIP
> > driver). In the VIP driver I don't use the control framework (there
> > aren't controls), so I think these lines must be there. Am I wrong?
>
> Correct. But once sta2x11 is converted to using the control framework,
> then these lines can be dropped since no one else is using this
> subdevice driver.
What do you suggest? I re-submit this patch and when sta2x11 is fixed a
I submit a new patch to remove these lines; or wait the full conversion
of the sta2x11 driver and submit both patch?
--
Federico Vaga
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] [media] adv7180.c: convert to v4l2 control framework
On Wed 11 July 2012 15:36:25 Federico Vaga wrote:
> Hi Hans,
>
> Thank you for your review
>
> > > +static int adv7180_init_controls(struct adv7180_state *state)
> > > +{
> > > + v4l2_ctrl_handler_init(&state->ctrl_hdl, 2);
> >
> > 2 -> 4, since there are 4 controls. It's a hint only, but it helps
> > optimizing the internal hash data structure.
>
> Sure :)
>
> > >
> > > @@ -445,9 +402,9 @@ static const struct v4l2_subdev_video_ops
> > > adv7180_video_ops = {>
> > > static const struct v4l2_subdev_core_ops adv7180_core_ops = {
> > >
> > > .g_chip_ident = adv7180_g_chip_ident,
> > > .s_std = adv7180_s_std,
> > >
> > > - .queryctrl = adv7180_queryctrl,
> > > - .g_ctrl = adv7180_g_ctrl,
> > > - .s_ctrl = adv7180_s_ctrl,
> > > + .queryctrl = v4l2_subdev_queryctrl,
> > > + .g_ctrl = v4l2_subdev_g_ctrl,
> > > + .s_ctrl = v4l2_subdev_s_ctrl,
> >
> > If adv7180 is currently *only* used by bridge/platform drivers that
> > also use the control framework, then you can remove
> > queryctrl/g/s_ctrl altogether.
>
> I'm not sure to undestand this point. I "grepped" for the adv7180 and it
> seem that I'm the only user of the adv7180 (sta2x11 VIP driver). In the
> VIP driver I don't use the control framework (there aren't controls), so
> I think these lines must be there. Am I wrong?
Correct. But once sta2x11 is converted to using the control framework, then
these lines can be dropped since no one else is using this subdevice driver.
> I think you are thinking at the "Inheriting Controls" section of the
> v4l2-controls.txt document. Right?
Right.
Regards,
Hans
>
>
> > > - ret = i2c_smbus_write_byte_data(client, ADV7180_HUE_REG,
> > > state->hue); +ret = i2c_smbus_write_byte_data(client,
> > > ADV7180_HUE_REG,
> > > + ADV7180_HUE_DEF);
> >
> > It shouldn't be necessary to initialize the controls since
> > v4l2_ctrl_handler_setup does that for you already.
>
> Removed
>
>
--
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 v1 2/2] [media] v4l: Add control definitions for new H264 encoder features
From: Jeongtae Park New controls are added for supporting H264 encoding features like - MVC frame packing - Flexible macroblock ordering - Arbitrary slice ordering - Hierarchial coding Signed-off-by: Jeongtae Park Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: Arun Kumar K Cc: Marek Szyprowski Cc: Kamil Debski --- Documentation/DocBook/media/v4l/controls.xml | 268 +- drivers/media/video/v4l2-ctrls.c | 42 include/linux/videodev2.h| 41 3 files changed, 350 insertions(+), 1 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 676bc46..a25582a 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -1581,7 +1581,6 @@ frame counter of the frame that is currently displayed (decoded). This value is the decoder is started. - V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE @@ -2265,6 +2264,14 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders. + + V4L2_CID_MPEG_VIDEO_VBV_DELAY + integer + Sets the initial delay in milliseconds for +VBV buffer control. + + + V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE integer @@ -2329,6 +2336,265 @@ Applicable to the MPEG4 decoder. vop_time_increment value for MPEG4. Applicable to the MPEG4 encoder. + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING + boolean + + Enable generation of frame packing supplemental enhancement information in the encoded bitstream. +The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0 + boolean + + Sets current frame as frame0 in frame packing SEI. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE + enum v4l2_mpeg_video_h264_sei_fp_arrangement_type + + Frame packing arrangement type for H264 SEI. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD + Pixels are alternatively from L and R. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN + L and R are interlaced by column. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW + L and R are interlaced by row. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE + L is on the left, R on the right. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM + L is on top, R on bottom. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL + One view per frame. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO + boolean + + Enables flexible macroblock ordering in the encoded bitstream. It is a technique +used for restructuring the ordering of macroblocks in pictures. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE + enum v4l2_mpeg_video_h264_fmo_map_type + + When using FMO, the map type divides the image in different scan patterns of macroblocks. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES + Slices are interleaved one after other with macroblocks in run length order. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES + Scatters the macroblocks based on a mathematical function known to both encoder and decoder. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER + Macroblocks arranged in re
[PATCH v1 1/2] [media] v4l: Add fourcc definitions for new formats
From: Jeongtae Park
Adds the following new fourcc definitions.
For multiplanar YCbCr
- V4L2_PIX_FMT_NV21M
- V4L2_PIX_FMT_NV12MT_16X16
and compressed formats
- V4L2_PIX_FMT_H264_MVC
- V4L2_PIX_FMT_VP8
Signed-off-by: Jeongtae Park
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: Arun Kumar K
Cc: Marek Szyprowski
Cc: Kamil Debski
---
Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 17 -
Documentation/DocBook/media/v4l/pixfmt.xml | 10 ++
include/linux/videodev2.h|4
3 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
index 5274c24..a990b34 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
@@ -1,11 +1,13 @@
-
+
- V4L2_PIX_FMT_NV12M ('NM12')
+ V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M
('NM21'), V4L2_PIX_FMT_NV12MT_16X16
&manvol;
-V4L2_PIX_FMT_NV12M
- Variation of V4L2_PIX_FMT_NV12 with
planes
+ V4L2_PIX_FMT_NV12M
+ V4L2_PIX_FMT_NV21M
+ V4L2_PIX_FMT_NV12MT_16X16
+ Variation of V4L2_PIX_FMT_NV12 and
V4L2_PIX_FMT_NV21 with planes
non contiguous in memory.
@@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane
(and of the image),
but is half as tall in pixels. Each CbCr pair belongs to four pixels. For
example,
Cb0/Cr0 belongs to
Y'00, Y'01,
-Y'10, Y'11.
+Y'10, Y'11.
+V4L2_PIX_FMT_NV12MT_16X16 is the tiled version of
+V4L2_PIX_FMT_NV12M with 16x16 macroblock tiles. Here
pixels
+are arranged in 16x16 2D tiles and tiles are arranged in linear order in
memory.
+V4L2_PIX_FMT_NV21M is the same as
V4L2_PIX_FMT_NV12M
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte.
V4L2_PIX_FMT_NV12M is intended to be
used only in drivers and applications that support the multi-planar API,
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
b/Documentation/DocBook/media/v4l/pixfmt.xml
index e58934c..424b335 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -757,6 +757,11 @@ extended control
V4L2_CID_MPEG_STREAM_TYPE, see
'AVC1'
H264 video elementary stream without start codes.
+
+ V4L2_PIX_FMT_H264_MVC
+ 'MVC'
+ H264 MVC video elementary stream.
+
V4L2_PIX_FMT_H263
'H263'
@@ -792,6 +797,11 @@ extended control
V4L2_CID_MPEG_STREAM_TYPE, see
'VC1L'
VC1, SMPTE 421M Annex L compliant stream.
+
+ V4L2_PIX_FMT_VP8
+ 'VP8'
+ VP8 video elementary stream.
+
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index f79d0cc..e23e6a7 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -359,7 +359,9 @@ struct v4l2_pix_format {
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 */
+#define V4L2_PIX_FMT_NV21M v4l2_fourcc('N', 'M', '2', '1') /* 21 Y/CrCb
4:2:0 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr
4:2:0 64x32 macroblocks */
+#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
/* three non contiguous planes - Y, Cb, Cr */
#define V4L2_PIX_FMT_YUV420M v4l2_fourcc('Y', 'M', '1', '2') /* 12 YUV420
planar */
@@ -395,6 +397,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4
Multiplexed */
#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264 with
start codes */
#define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264
without start codes */
+#define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 MVC */
#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263
*/
#define V4L2_PIX_FMT_MPEG1v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1 ES
*/
#define V4L2_PIX_FMT_MPEG2v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2 ES
*/
@@ -402,6 +405,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /* Xvid
*/
#define V4L2_PIX_FMT_VC1_ANNEX_G v4l2_fourcc('V', 'C', '1', 'G') /* SMPTE 421M
Annex G compliant stream */
#define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE 421M
Annex L compliant stream */
+#define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
/* Vendor-specific formats */
#define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
--
1.7.0.4
--
To u
[PATCH v1 0/2] Add new fourcc definitions and H264 codec controls
This patch set adds new control and fourcc definitions which will be used by samsung s5p-mfc driver. Patch 1 adds new fourcc definitions for YCbCr and compressed formats. Patch 2 adds control definitions for new H264 encoder features. The review comments given in [1] are addressed. [1] http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/45197 Jeongtae Park (2): [media] v4l: Add fourcc definitions for new formats [media] v4l: Add control definitions for new H264 encoder features Documentation/DocBook/media/v4l/controls.xml | 268 +- Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 17 +- Documentation/DocBook/media/v4l/pixfmt.xml | 10 + drivers/media/video/v4l2-ctrls.c | 42 include/linux/videodev2.h| 45 5 files changed, 376 insertions(+), 6 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: video: USB webcam fails since kernel 3.2
2012/7/11 Hans de Goede : > On 07/11/2012 02:01 PM, Martin-Éric Racine wrote: >> >> 2012/7/11 Jean-Francois Moine : >>> >>> On Wed, 11 Jul 2012 14:14:24 +0300 >>> Martin-Éric Racine wrote: >>> CC [M] /home/perkelix/gspca-2.15.18/build/ov534_9.o /home/perkelix/gspca-2.15.18/build/ov534_9.c: In function ‘sd_init’: /home/perkelix/gspca-2.15.18/build/ov534_9.c:1353:3: error: implicit declaration of function ‘err’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [/home/perkelix/gspca-2.15.18/build/ov534_9.o] Virhe 1 make[1]: *** [_module_/home/perkelix/gspca-2.15.18/build] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-3.5.0-rc6+' make: *** [modules] Error 2 >>> >>> >>> Sorry, I did not compile yet with kernel >= 3.4. >>> >>> So, please, edit the file build/ov534_9.c (and possibly other sources), >>> changing the calls to 'err' to 'pr_err'. >> >> >> This was was required for both build/ov534_9.c and build/spca505.c to >> build agaist 3.5. >> >> Sure enough, this seems to fix support for this camera in both Cheese >> and Skype. Hurray! :-) > > > Ok, so it seems that increasing the bandwidth we claim for the camera > (which is what my suggested "return 2000 * 2000 * 120;" change does, helps > a bit, where as the changes to vc032x which are in Jean-Francois Moine's > gspca-2.15.18 tarbal fix the problem entirely, correct? As far as I can tell, yes, the modules in Jean-François' tarball work as-is to fix the problem. >> Now, the only thing that remains is for this to be merged in the 3.5 >> tree, then backported to the 3.2 tree that is used for Debian's >> upcoming Wheezy stable release (and for Ubuntu's recently released >> Precise also). > > > Well we first need to turn the changes made in gspca-2.15.18 into > a patch will which apply to the latest gspca tree: > http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/media-for_v3.6 > > And then apply them there, before the can be backported to older > kernels. Unfortunately I'm leaving for a week vacation Friday, and I > probably won't get around to this before then. > > Jean-Francois, can you perhaps make a patch against my latest tree for > the po / PO3130 changes in your tarbal? Noted. Hopefully, the Debian kernel team can contribute to the backporting part, since it's needed for the upcoming stable release. Martin-Éric -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] [media] adv7180.c: convert to v4l2 control framework
Hi Hans,
Thank you for your review
> > +static int adv7180_init_controls(struct adv7180_state *state)
> > +{
> > + v4l2_ctrl_handler_init(&state->ctrl_hdl, 2);
>
> 2 -> 4, since there are 4 controls. It's a hint only, but it helps
> optimizing the internal hash data structure.
Sure :)
> >
> > @@ -445,9 +402,9 @@ static const struct v4l2_subdev_video_ops
> > adv7180_video_ops = {>
> > static const struct v4l2_subdev_core_ops adv7180_core_ops = {
> >
> > .g_chip_ident = adv7180_g_chip_ident,
> > .s_std = adv7180_s_std,
> >
> > - .queryctrl = adv7180_queryctrl,
> > - .g_ctrl = adv7180_g_ctrl,
> > - .s_ctrl = adv7180_s_ctrl,
> > + .queryctrl = v4l2_subdev_queryctrl,
> > + .g_ctrl = v4l2_subdev_g_ctrl,
> > + .s_ctrl = v4l2_subdev_s_ctrl,
>
> If adv7180 is currently *only* used by bridge/platform drivers that
> also use the control framework, then you can remove
> queryctrl/g/s_ctrl altogether.
I'm not sure to undestand this point. I "grepped" for the adv7180 and it
seem that I'm the only user of the adv7180 (sta2x11 VIP driver). In the
VIP driver I don't use the control framework (there aren't controls), so
I think these lines must be there. Am I wrong?
I think you are thinking at the "Inheriting Controls" section of the
v4l2-controls.txt document. Right?
> > - ret = i2c_smbus_write_byte_data(client, ADV7180_HUE_REG,
> > state->hue); + ret = i2c_smbus_write_byte_data(client,
> > ADV7180_HUE_REG,
> > + ADV7180_HUE_DEF);
>
> It shouldn't be necessary to initialize the controls since
> v4l2_ctrl_handler_setup does that for you already.
Removed
--
Federico Vaga
--
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: video: USB webcam fails since kernel 3.2
Hi, On 07/11/2012 02:01 PM, Martin-Éric Racine wrote: 2012/7/11 Jean-Francois Moine : On Wed, 11 Jul 2012 14:14:24 +0300 Martin-Éric Racine wrote: CC [M] /home/perkelix/gspca-2.15.18/build/ov534_9.o /home/perkelix/gspca-2.15.18/build/ov534_9.c: In function ‘sd_init’: /home/perkelix/gspca-2.15.18/build/ov534_9.c:1353:3: error: implicit declaration of function ‘err’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [/home/perkelix/gspca-2.15.18/build/ov534_9.o] Virhe 1 make[1]: *** [_module_/home/perkelix/gspca-2.15.18/build] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-3.5.0-rc6+' make: *** [modules] Error 2 Sorry, I did not compile yet with kernel >= 3.4. So, please, edit the file build/ov534_9.c (and possibly other sources), changing the calls to 'err' to 'pr_err'. This was was required for both build/ov534_9.c and build/spca505.c to build agaist 3.5. Sure enough, this seems to fix support for this camera in both Cheese and Skype. Hurray! :-) Ok, so it seems that increasing the bandwidth we claim for the camera (which is what my suggested "return 2000 * 2000 * 120;" change does, helps a bit, where as the changes to vc032x which are in Jean-Francois Moine's gspca-2.15.18 tarbal fix the problem entirely, correct? Now, the only thing that remains is for this to be merged in the 3.5 tree, then backported to the 3.2 tree that is used for Debian's upcoming Wheezy stable release (and for Ubuntu's recently released Precise also). Well we first need to turn the changes made in gspca-2.15.18 into a patch will which apply to the latest gspca tree: http://git.linuxtv.org/hgoede/gspca.git/shortlog/refs/heads/media-for_v3.6 And then apply them there, before the can be backported to older kernels. Unfortunately I'm leaving for a week vacation Friday, and I probably won't get around to this before then. Jean-Francois, can you perhaps make a patch against my latest tree for the po / PO3130 changes in your tarbal? Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] media: mx2_camera: Fix mbus format handling
On Wednesday 11 July 2012 13:00:19 Javier Martin wrote:
> Do not use MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.
> The driver must negotiate with the attached sensor whether the
> mbus format is UYUV or YUYV and set CSICR1 configuration
> accordingly.
>
> Signed-off-by: Javier Martin
Acked-by: Laurent Pinchart
Could you please also send a patch for v3.6 that remove the MX2_CAMERA_SWAP16
and MX2_CAMERA_PACK_DIR_MSB flags from the header file ?
> ---
> drivers/media/video/mx2_camera.c | 28 +++-
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/video/mx2_camera.c
> b/drivers/media/video/mx2_camera.c index 11a9353..0f01e7b 100644
> --- a/drivers/media/video/mx2_camera.c
> +++ b/drivers/media/video/mx2_camera.c
> @@ -118,6 +118,8 @@
> #define CSISR_ECC_INT(1 << 1)
> #define CSISR_DRDY (1 << 0)
>
> +#define CSICR1_FMT_MASK (CSICR1_PACK_DIR | CSICR1_SWAP16_EN)
> +
> #define CSICR1 0x00
> #define CSICR2 0x04
> #define CSISR(cpu_is_mx27() ? 0x08 : 0x18)
> @@ -230,6 +232,7 @@ struct mx2_prp_cfg {
> u32 src_pixel;
> u32 ch1_pixel;
> u32 irq_flags;
> + u32 csicr1;
> };
>
> /* prp resizing parameters */
> @@ -330,6 +333,7 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
> .ch1_pixel = 0x2ca00565, /* RGB565 */
> .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
> PRP_INTR_CH1FC | PRP_INTR_LBOVF,
> + .csicr1 = 0,
> }
> },
> {
> @@ -343,6 +347,21 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
> .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
> PRP_INTR_CH2FC | PRP_INTR_LBOVF |
> PRP_INTR_CH2OVF,
> + .csicr1 = CSICR1_PACK_DIR,
> + }
> + },
> + {
> + .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
> + .out_fmt= V4L2_PIX_FMT_YUV420,
> + .cfg= {
> + .channel= 2,
> + .in_fmt = PRP_CNTL_DATA_IN_YUV422,
> + .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
> + .src_pixel = 0x22000888, /* YUV422 (YUYV) */
> + .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
> + PRP_INTR_CH2FC | PRP_INTR_LBOVF |
> + PRP_INTR_CH2OVF,
> + .csicr1 = CSICR1_SWAP16_EN,
> }
> },
> };
> @@ -1018,14 +1037,14 @@ static int mx2_camera_set_bus_param(struct
> soc_camera_device *icd) return ret;
> }
>
> + csicr1 = (csicr1 & ~CSICR1_FMT_MASK) | pcdev->emma_prp->cfg.csicr1;
> +
> if (common_flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
> csicr1 |= CSICR1_REDGE;
> if (common_flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
> csicr1 |= CSICR1_SOF_POL;
> if (common_flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> csicr1 |= CSICR1_HSYNC_POL;
> - if (pcdev->platform_flags & MX2_CAMERA_SWAP16)
> - csicr1 |= CSICR1_SWAP16_EN;
> if (pcdev->platform_flags & MX2_CAMERA_EXT_VSYNC)
> csicr1 |= CSICR1_EXT_VSYNC;
> if (pcdev->platform_flags & MX2_CAMERA_CCIR)
> @@ -1036,8 +1055,6 @@ static int mx2_camera_set_bus_param(struct
> soc_camera_device *icd) csicr1 |= CSICR1_GCLK_MODE;
> if (pcdev->platform_flags & MX2_CAMERA_INV_DATA)
> csicr1 |= CSICR1_INV_DATA;
> - if (pcdev->platform_flags & MX2_CAMERA_PACK_DIR_MSB)
> - csicr1 |= CSICR1_PACK_DIR;
>
> pcdev->csicr1 = csicr1;
>
> @@ -1112,7 +1129,8 @@ static int mx2_camera_get_formats(struct
> soc_camera_device *icd, return 0;
> }
>
> - if (code == V4L2_MBUS_FMT_YUYV8_2X8) {
> + if (code == V4L2_MBUS_FMT_YUYV8_2X8 ||
> + code == V4L2_MBUS_FMT_UYVY8_2X8) {
> formats++;
> if (xlate) {
> /*
--
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
[GIT PULL FOR v3.5] VIDIOC_DV_TIMINGS_CAP fixes
Hi Mauro, In 3.5 the VIDIOC_DV_TIMINGS_CAP doesn't work at the moment due to a missing line in v4l2-dev.c. I hope this can still be fixed before 3.5 is released. If not, then it has to go to stable. Luckily nobody is really using this ioctl at the moment, which is why it wasn't noticed until I added test code for this ioctl to v4l2-compliance. Regards, Hans The following changes since commit b7e386360922a15f943b2fbe8d77a19bb86f2e6f: media: Revert "[media] Terratec Cinergy S2 USB HD Rev.2" (2012-07-07 00:19:20 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git fixes for you to fetch changes up to 8f8487266893eadf99a4198889fbec3c301213e9: v4l2-ioctl.c: zero the v4l2_dv_timings_cap struct. (2012-07-11 14:15:06 +0200) Hans Verkuil (2): v4l2-dev: forgot to add VIDIOC_DV_TIMINGS_CAP. v4l2-ioctl.c: zero the v4l2_dv_timings_cap struct. drivers/media/video/v4l2-dev.c |1 + drivers/media/video/v4l2-ioctl.c |2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- 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: video: USB webcam fails since kernel 3.2
Martin-Éric Racine wrote: > PS: Jonathan, do you feel like investigating why > arch/x86/Makefile_32.cpu wasn't included in the > linux-headers-3.5.0-rc6+_3.5.0-rc6+-1_i386.deb package that was > generated by the 'make deb-pkg' target? MAINTAINERS tells me that linux-kbu...@vger.kernel.org is the list to contact. You might also want to cc the kernel team at debian-ker...@lists.debian.org since there are likely to be some familiar people among them. -- 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: video: USB webcam fails since kernel 3.2
2012/7/11 Jean-Francois Moine : > On Wed, 11 Jul 2012 14:14:24 +0300 > Martin-Éric Racine wrote: > >> CC [M] /home/perkelix/gspca-2.15.18/build/ov534_9.o >> /home/perkelix/gspca-2.15.18/build/ov534_9.c: In function ‘sd_init’: >> /home/perkelix/gspca-2.15.18/build/ov534_9.c:1353:3: error: implicit >> declaration of function ‘err’ [-Werror=implicit-function-declaration] >> cc1: some warnings being treated as errors >> make[2]: *** [/home/perkelix/gspca-2.15.18/build/ov534_9.o] Virhe 1 >> make[1]: *** [_module_/home/perkelix/gspca-2.15.18/build] Error 2 >> make[1]: Leaving directory `/usr/src/linux-headers-3.5.0-rc6+' >> make: *** [modules] Error 2 > > Sorry, I did not compile yet with kernel >= 3.4. > > So, please, edit the file build/ov534_9.c (and possibly other sources), > changing the calls to 'err' to 'pr_err'. This was was required for both build/ov534_9.c and build/spca505.c to build agaist 3.5. Sure enough, this seems to fix support for this camera in both Cheese and Skype. Hurray! :-) Now, the only thing that remains is for this to be merged in the 3.5 tree, then backported to the 3.2 tree that is used for Debian's upcoming Wheezy stable release (and for Ubuntu's recently released Precise also). Thanks again to everyone for the hand-holding! Cheers! Martin-Éric PS: Jonathan, do you feel like investigating why arch/x86/Makefile_32.cpu wasn't included in the linux-headers-3.5.0-rc6+_3.5.0-rc6+-1_i386.deb package that was generated by the 'make deb-pkg' target? -- 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 for v3.6] Fix DV_TIMINGS_CAP documentation
This patch fixes the DV_TIMINGS_CAP documentation: part of it was copy-and-paste from the ENUM_DV_TIMINGS documentation. Regards, Hans Signed-off-by: Hans Verkuil diff --git a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml index 6673ce5..cd7720d 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml @@ -54,15 +54,9 @@ interface and may change in the future. -To query the available timings, applications initialize the -index field and zero the reserved array of &v4l2-dv-timings-cap; -and call the VIDIOC_DV_TIMINGS_CAP ioctl with a pointer to this -structure. Drivers fill the rest of the structure or return an -&EINVAL; when the index is out of bounds. To enumerate all supported DV timings, -applications shall begin at index zero, incrementing by one until the -driver returns EINVAL. Note that drivers may enumerate a -different set of DV timings after switching the video input or -output. +To query the capabilities of the DV receiver/transmitter applications can call +this ioctl and the driver will fill in the structure. Note that drivers may return +different values after switching the video input or output. struct v4l2_bt_timings_cap @@ -115,7 +109,7 @@ output. __u32 reserved[16] - + Reserved for future extensions. Drivers must set the array to zero. -- 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: video: USB webcam fails since kernel 3.2
On Wed, 11 Jul 2012 14:14:24 +0300 Martin-Éric Racine wrote: > CC [M] /home/perkelix/gspca-2.15.18/build/ov534_9.o > /home/perkelix/gspca-2.15.18/build/ov534_9.c: In function ‘sd_init’: > /home/perkelix/gspca-2.15.18/build/ov534_9.c:1353:3: error: implicit > declaration of function ‘err’ [-Werror=implicit-function-declaration] > cc1: some warnings being treated as errors > make[2]: *** [/home/perkelix/gspca-2.15.18/build/ov534_9.o] Virhe 1 > make[1]: *** [_module_/home/perkelix/gspca-2.15.18/build] Error 2 > make[1]: Leaving directory `/usr/src/linux-headers-3.5.0-rc6+' > make: *** [modules] Error 2 Sorry, I did not compile yet with kernel >= 3.4. So, please, edit the file build/ov534_9.c (and possibly other sources), changing the calls to 'err' to 'pr_err'. -- 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: video: USB webcam fails since kernel 3.2
2012/7/11 Jean-Francois Moine : > On Wed, 11 Jul 2012 13:21:55 +0300 > Martin-Éric Racine wrote: > >> I installed them. That still doesn't fix it: >> >> $ LC_ALL=C make >> make -C /lib/modules/3.5.0-rc6+/build >> M=/home/perkelix/gspca-2.15.18/build modules >> make[1]: Entering directory `/usr/src/linux-headers-3.5.0-rc6+' >> /usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile:39: >> /usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile_32.cpu: No such >> file or directory >> make[1]: *** No rule to make target > > Strange. The file arch/x86/Makefile_32.cpu is in the linux 3.5.0 tree. > It should have been forgotten in the Debian package. You may copy it > from any other kernel source/header you have. That would be a bug in upstream GIT's built-in support for producing Debian packages then. Anyhow, after copying the missing file, the build successfully launches then breaks as follow: CC [M] /home/perkelix/gspca-2.15.18/build/ov534_9.o /home/perkelix/gspca-2.15.18/build/ov534_9.c: In function ‘sd_init’: /home/perkelix/gspca-2.15.18/build/ov534_9.c:1353:3: error: implicit declaration of function ‘err’ [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[2]: *** [/home/perkelix/gspca-2.15.18/build/ov534_9.o] Virhe 1 make[1]: *** [_module_/home/perkelix/gspca-2.15.18/build] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-3.5.0-rc6+' make: *** [modules] Error 2 -- Martin-Éric -- 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 v6] media: mx2_camera: Fix mbus format handling
Do not use MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.
The driver must negotiate with the attached sensor whether the
mbus format is UYUV or YUYV and set CSICR1 configuration
accordingly.
Signed-off-by: Javier Martin
---
drivers/media/video/mx2_camera.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 11a9353..0f01e7b 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -118,6 +118,8 @@
#define CSISR_ECC_INT (1 << 1)
#define CSISR_DRDY (1 << 0)
+#define CSICR1_FMT_MASK (CSICR1_PACK_DIR | CSICR1_SWAP16_EN)
+
#define CSICR1 0x00
#define CSICR2 0x04
#define CSISR (cpu_is_mx27() ? 0x08 : 0x18)
@@ -230,6 +232,7 @@ struct mx2_prp_cfg {
u32 src_pixel;
u32 ch1_pixel;
u32 irq_flags;
+ u32 csicr1;
};
/* prp resizing parameters */
@@ -330,6 +333,7 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
.ch1_pixel = 0x2ca00565, /* RGB565 */
.irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
PRP_INTR_CH1FC | PRP_INTR_LBOVF,
+ .csicr1 = 0,
}
},
{
@@ -343,6 +347,21 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
.irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
PRP_INTR_CH2FC | PRP_INTR_LBOVF |
PRP_INTR_CH2OVF,
+ .csicr1 = CSICR1_PACK_DIR,
+ }
+ },
+ {
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUV420,
+ .cfg= {
+ .channel= 2,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
+ PRP_INTR_CH2FC | PRP_INTR_LBOVF |
+ PRP_INTR_CH2OVF,
+ .csicr1 = CSICR1_SWAP16_EN,
}
},
};
@@ -1018,14 +1037,14 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
return ret;
}
+ csicr1 = (csicr1 & ~CSICR1_FMT_MASK) | pcdev->emma_prp->cfg.csicr1;
+
if (common_flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
if (common_flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_HSYNC_POL;
- if (pcdev->platform_flags & MX2_CAMERA_SWAP16)
- csicr1 |= CSICR1_SWAP16_EN;
if (pcdev->platform_flags & MX2_CAMERA_EXT_VSYNC)
csicr1 |= CSICR1_EXT_VSYNC;
if (pcdev->platform_flags & MX2_CAMERA_CCIR)
@@ -1036,8 +1055,6 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
csicr1 |= CSICR1_GCLK_MODE;
if (pcdev->platform_flags & MX2_CAMERA_INV_DATA)
csicr1 |= CSICR1_INV_DATA;
- if (pcdev->platform_flags & MX2_CAMERA_PACK_DIR_MSB)
- csicr1 |= CSICR1_PACK_DIR;
pcdev->csicr1 = csicr1;
@@ -1112,7 +1129,8 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
return 0;
}
- if (code == V4L2_MBUS_FMT_YUYV8_2X8) {
+ if (code == V4L2_MBUS_FMT_YUYV8_2X8 ||
+ code == V4L2_MBUS_FMT_UYVY8_2X8) {
formats++;
if (xlate) {
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] media: mx2_camera: Fix mbus format handling
Hi Javier, On Wednesday 11 July 2012 12:37:05 javier Martin wrote: > On 11 July 2012 12:08, Laurent Pinchart wrote: > > On Wednesday 11 July 2012 09:56:49 Javier Martin wrote: > >> Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags > >> so that the driver can negotiate with the attached sensor > >> whether the mbus format needs convertion from UYUV to YUYV > >> or not. > > > > The commit message doesn't really match the content of the patch anymore, > > as you don't remove the MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB > > flags but just stop using them. > > > > Could you please fix the commit message, and submit a patch that removes > > the flag from arch/arm/plat-mxc/include/mach/mx2_cam.h for v3.6 ? > > > > Please don't forget to add your SoB line. > > Ok. > > >> --- > >> > >> drivers/media/video/mx2_camera.c | 28 +++- > >> 1 file changed, 23 insertions(+), 5 deletions(-) > >> > >> diff --git a/drivers/media/video/mx2_camera.c > >> b/drivers/media/video/mx2_camera.c index 11a9353..0f01e7b 100644 > >> --- a/drivers/media/video/mx2_camera.c > >> +++ b/drivers/media/video/mx2_camera.c [snip] > >> @@ -1018,14 +1037,14 @@ static int mx2_camera_set_bus_param(struct > >> soc_camera_device *icd) return ret; > >> > >> } > >> > >> + csicr1 = (csicr1 & ~CSICR1_FMT_MASK) | pcdev->emma_prp->cfg.csicr1; > >> + > >> > >> if (common_flags & V4L2_MBUS_PCLK_SAMPLE_RISING) > >> csicr1 |= CSICR1_REDGE; > >> if (common_flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH) > >> csicr1 |= CSICR1_SOF_POL; > >> if (common_flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH) > >> csicr1 |= CSICR1_HSYNC_POL; > > > > This is a completely different issue (and thus v3.6 material, if needed), > > but can common_flags change between invocations ? If so you should clear > > the CSICR1_* flags before conditionally setting them. > > No, this is precisely the aim of this patch. The problem is that these > flags have to be set according to the format that is being used and > not according to the platform code. > So, this chunk is needed. I haven't expressed myself clearly enough, sorry. The "completely" different issue refers to the REDGE, SOF_POL and HSYNC_POL flags. > 'common_flags' cannot change between invocations since it depends on > the platform code which is static. Then the code that computes the csicr1 flags that only depend on static platform data should probably be moved to a different function, called at initialization time, to avoid recomputing them at each mx2_camera_set_bus_param() invocation. This would be v3.6 material. > >> - if (pcdev->platform_flags & MX2_CAMERA_SWAP16) > >> - csicr1 |= CSICR1_SWAP16_EN; > >> if (pcdev->platform_flags & MX2_CAMERA_EXT_VSYNC) > >> csicr1 |= CSICR1_EXT_VSYNC; > >> if (pcdev->platform_flags & MX2_CAMERA_CCIR) -- 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: video: USB webcam fails since kernel 3.2
On Wed, 11 Jul 2012 13:21:55 +0300 Martin-Éric Racine wrote: > I installed them. That still doesn't fix it: > > $ LC_ALL=C make > make -C /lib/modules/3.5.0-rc6+/build > M=/home/perkelix/gspca-2.15.18/build modules > make[1]: Entering directory `/usr/src/linux-headers-3.5.0-rc6+' > /usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile:39: > /usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile_32.cpu: No such > file or directory > make[1]: *** No rule to make target Strange. The file arch/x86/Makefile_32.cpu is in the linux 3.5.0 tree. It should have been forgotten in the Debian package. You may copy it from any other kernel source/header you have. -- 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 v5] media: mx2_camera: Fix mbus format handling
Hi,
On 11 July 2012 12:08, Laurent Pinchart
wrote:
> Hi Javier,
>
> Thanks for the patch.
>
> On Wednesday 11 July 2012 09:56:49 Javier Martin wrote:
>> Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags
>> so that the driver can negotiate with the attached sensor
>> whether the mbus format needs convertion from UYUV to YUYV
>> or not.
>
> The commit message doesn't really match the content of the patch anymore, as
> you don't remove the MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags but
> just stop using them.
>
> Could you please fix the commit message, and submit a patch that removes the
> flag from arch/arm/plat-mxc/include/mach/mx2_cam.h for v3.6 ?
>
> Please don't forget to add your SoB line.
Ok.
>> ---
>> drivers/media/video/mx2_camera.c | 28 +++-
>> 1 file changed, 23 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/media/video/mx2_camera.c
>> b/drivers/media/video/mx2_camera.c index 11a9353..0f01e7b 100644
>> --- a/drivers/media/video/mx2_camera.c
>> +++ b/drivers/media/video/mx2_camera.c
>> @@ -118,6 +118,8 @@
>> #define CSISR_ECC_INT(1 << 1)
>> #define CSISR_DRDY (1 << 0)
>>
>> +#define CSICR1_FMT_MASK (CSICR1_PACK_DIR | CSICR1_SWAP16_EN)
>> +
>> #define CSICR1 0x00
>> #define CSICR2 0x04
>> #define CSISR(cpu_is_mx27() ? 0x08 : 0x18)
>> @@ -230,6 +232,7 @@ struct mx2_prp_cfg {
>> u32 src_pixel;
>> u32 ch1_pixel;
>> u32 irq_flags;
>> + u32 csicr1;
>> };
>>
>> /* prp resizing parameters */
>> @@ -330,6 +333,7 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
>> .ch1_pixel = 0x2ca00565, /* RGB565 */
>> .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
>> PRP_INTR_CH1FC |
>> PRP_INTR_LBOVF,
>> + .csicr1 = 0,
>> }
>> },
>> {
>> @@ -343,6 +347,21 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
>> .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
>> PRP_INTR_CH2FC | PRP_INTR_LBOVF |
>> PRP_INTR_CH2OVF,
>> + .csicr1 = CSICR1_PACK_DIR,
>> + }
>> + },
>> + {
>> + .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
>> + .out_fmt= V4L2_PIX_FMT_YUV420,
>> + .cfg= {
>> + .channel= 2,
>> + .in_fmt = PRP_CNTL_DATA_IN_YUV422,
>> + .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
>> + .src_pixel = 0x22000888, /* YUV422 (YUYV) */
>> + .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
>> + PRP_INTR_CH2FC | PRP_INTR_LBOVF |
>> + PRP_INTR_CH2OVF,
>> + .csicr1 = CSICR1_SWAP16_EN,
>> }
>
> Have you tested this patch with both YUYV8_2X8 and UYVY8_2X8 ? I'm not
> familiar with the hardware, so I can't really comment on this specific hunk.
> Knowing that it has been tested would be enough for me to ack the patch (after
> fixing the commit message of course).
Yes, with ov7670 and tvp5150.
>> },
>> };
>> @@ -1018,14 +1037,14 @@ static int mx2_camera_set_bus_param(struct
>> soc_camera_device *icd) return ret;
>> }
>>
>> + csicr1 = (csicr1 & ~CSICR1_FMT_MASK) | pcdev->emma_prp->cfg.csicr1;
>> +
>> if (common_flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
>> csicr1 |= CSICR1_REDGE;
>> if (common_flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
>> csicr1 |= CSICR1_SOF_POL;
>> if (common_flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
>> csicr1 |= CSICR1_HSYNC_POL;
>
> This is a completely different issue (and thus v3.6 material, if needed), but
> can common_flags change between invocations ? If so you should clear the
> CSICR1_* flags before conditionally setting them.
No, this is precisely the aim of this patch. The problem is that these
flags have to be set according to the format that is being used and
not according to the platform code.
So, this chunk is needed.
'common_flags' cannot change between invocations since it depends on
the platform code which is static.
>> - if (pcdev->platform_flags & MX2_CAMERA_SWAP16)
>> - csicr1 |= CSICR1_SWAP16_EN;
>> if (pcdev->platform_flags & MX2_CAMERA_EXT_VSYNC)
>> csicr1 |= CSICR1_EXT_VSYNC;
>> if (pcdev->platform_flags & MX2_CAMERA_CCIR)
>> @@ -1036,8 +1055,6 @@ static int mx2_camera_set_bus_param(struct
>> soc_camera_device *icd) csicr1 |= CSICR1_GCLK_MODE;
>> if (pcdev->platform_flags & MX2_CAMERA_INV_DATA)
>> csicr1 |= CSICR1_INV_DATA;
>> - if (pcdev->platform_flags & MX2_CAMERA_PACK_DIR_MSB)
>> -
Re: video: USB webcam fails since kernel 3.2
2012/7/11 Jean-Francois Moine : > On Wed, 11 Jul 2012 10:02:27 +0300 > Martin-Éric Racine wrote: > [snip] >> > wget http://moinejf.free.fr/gspca-2.15.18.tar.gz >> > tar -zxf gspca-2.15.18.tar.gz >> > cd gspca-2.15.18 >> > make >> >> $ LC_ALL=C make >> make -C /lib/modules/3.5.0-rc6+/build >> M=/home/perkelix/gspca-2.15.18/build modules >> make: *** /lib/modules/3.5.0-rc6+/build: No such file or directory. Stop. >> make: *** [modules] Error 2 > > You need the linux headers of your running kernel to compile the tarball. I installed them. That still doesn't fix it: $ LC_ALL=C make make -C /lib/modules/3.5.0-rc6+/build M=/home/perkelix/gspca-2.15.18/build modules make[1]: Entering directory `/usr/src/linux-headers-3.5.0-rc6+' /usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile:39: /usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile_32.cpu: No such file or directory make[1]: *** No rule to make target `/usr/src/linux-headers-3.5.0-rc6+/arch/x86/Makefile_32.cpu'. Stop. make[1]: Leaving directory `/usr/src/linux-headers-3.5.0-rc6+' make: *** [modules] Error 2 -- Martin-Éric -- 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] media: Add mem2mem deinterlacing driver.
On Wed 11 July 2012 12:02:48 javier Martin wrote: > Hi Hans, > thank you for your comments. > > On 11 July 2012 11:45, Hans Verkuil wrote: > > Hi Javier! > > > > Thanks for the patch. > > > > On Wed 11 July 2012 10:55:03 Javier Martin wrote: > >> Some video decoders such as tvp5150 provide separate > >> video fields (V4L2_FIELD_SEQ_TB). This driver uses > >> dmaengine to convert this format to V4L2_FIELD_INTERLACED_TB > >> (weaving) or V4L2_FIELD_NONE (line doubling) > > > > Which field is used for the line doubling? Top or bottom? Or is each field > > doubled, thus doubling the framerate? > > No, just top field is used. > I don't know if it's worth defining a new field format for doubling fields. Probably not, but just make sure it is clearly documented. > > I also recommend adding SEQ_BT/INTERLACED_BT support: NTSC transmits the > > bottom > > field first, so it is useful to have support for that. > > Adding that is quite easy but I cannot test it. > Maybe someone could add it later? It shouldn't be too hard to test: make the top field red and the bottom field blue and check if the resulting image is correct. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] media: mx2_camera: Fix mbus format handling
Hi Javier,
Thanks for the patch.
On Wednesday 11 July 2012 09:56:49 Javier Martin wrote:
> Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags
> so that the driver can negotiate with the attached sensor
> whether the mbus format needs convertion from UYUV to YUYV
> or not.
The commit message doesn't really match the content of the patch anymore, as
you don't remove the MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags but
just stop using them.
Could you please fix the commit message, and submit a patch that removes the
flag from arch/arm/plat-mxc/include/mach/mx2_cam.h for v3.6 ?
Please don't forget to add your SoB line.
> ---
> drivers/media/video/mx2_camera.c | 28 +++-
> 1 file changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/video/mx2_camera.c
> b/drivers/media/video/mx2_camera.c index 11a9353..0f01e7b 100644
> --- a/drivers/media/video/mx2_camera.c
> +++ b/drivers/media/video/mx2_camera.c
> @@ -118,6 +118,8 @@
> #define CSISR_ECC_INT(1 << 1)
> #define CSISR_DRDY (1 << 0)
>
> +#define CSICR1_FMT_MASK (CSICR1_PACK_DIR | CSICR1_SWAP16_EN)
> +
> #define CSICR1 0x00
> #define CSICR2 0x04
> #define CSISR(cpu_is_mx27() ? 0x08 : 0x18)
> @@ -230,6 +232,7 @@ struct mx2_prp_cfg {
> u32 src_pixel;
> u32 ch1_pixel;
> u32 irq_flags;
> + u32 csicr1;
> };
>
> /* prp resizing parameters */
> @@ -330,6 +333,7 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
> .ch1_pixel = 0x2ca00565, /* RGB565 */
> .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
> PRP_INTR_CH1FC | PRP_INTR_LBOVF,
> + .csicr1 = 0,
> }
> },
> {
> @@ -343,6 +347,21 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
> .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
> PRP_INTR_CH2FC | PRP_INTR_LBOVF |
> PRP_INTR_CH2OVF,
> + .csicr1 = CSICR1_PACK_DIR,
> + }
> + },
> + {
> + .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
> + .out_fmt= V4L2_PIX_FMT_YUV420,
> + .cfg= {
> + .channel= 2,
> + .in_fmt = PRP_CNTL_DATA_IN_YUV422,
> + .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
> + .src_pixel = 0x22000888, /* YUV422 (YUYV) */
> + .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
> + PRP_INTR_CH2FC | PRP_INTR_LBOVF |
> + PRP_INTR_CH2OVF,
> + .csicr1 = CSICR1_SWAP16_EN,
> }
Have you tested this patch with both YUYV8_2X8 and UYVY8_2X8 ? I'm not
familiar with the hardware, so I can't really comment on this specific hunk.
Knowing that it has been tested would be enough for me to ack the patch (after
fixing the commit message of course).
> },
> };
> @@ -1018,14 +1037,14 @@ static int mx2_camera_set_bus_param(struct
> soc_camera_device *icd) return ret;
> }
>
> + csicr1 = (csicr1 & ~CSICR1_FMT_MASK) | pcdev->emma_prp->cfg.csicr1;
> +
> if (common_flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
> csicr1 |= CSICR1_REDGE;
> if (common_flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
> csicr1 |= CSICR1_SOF_POL;
> if (common_flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> csicr1 |= CSICR1_HSYNC_POL;
This is a completely different issue (and thus v3.6 material, if needed), but
can common_flags change between invocations ? If so you should clear the
CSICR1_* flags before conditionally setting them.
> - if (pcdev->platform_flags & MX2_CAMERA_SWAP16)
> - csicr1 |= CSICR1_SWAP16_EN;
> if (pcdev->platform_flags & MX2_CAMERA_EXT_VSYNC)
> csicr1 |= CSICR1_EXT_VSYNC;
> if (pcdev->platform_flags & MX2_CAMERA_CCIR)
> @@ -1036,8 +1055,6 @@ static int mx2_camera_set_bus_param(struct
> soc_camera_device *icd) csicr1 |= CSICR1_GCLK_MODE;
> if (pcdev->platform_flags & MX2_CAMERA_INV_DATA)
> csicr1 |= CSICR1_INV_DATA;
> - if (pcdev->platform_flags & MX2_CAMERA_PACK_DIR_MSB)
> - csicr1 |= CSICR1_PACK_DIR;
>
> pcdev->csicr1 = csicr1;
>
> @@ -1112,7 +1129,8 @@ static int mx2_camera_get_formats(struct
> soc_camera_device *icd, return 0;
> }
>
> - if (code == V4L2_MBUS_FMT_YUYV8_2X8) {
> + if (code == V4L2_MBUS_FMT_YUYV8_2X8 ||
> + code == V4L2_MBUS_FMT_UYVY8_2X8) {
> formats++;
> if (xlate) {
> /*
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-me
Re: [PATCH 1/2] media: Add mem2mem deinterlacing driver.
Hi Hans, thank you for your comments. On 11 July 2012 11:45, Hans Verkuil wrote: > Hi Javier! > > Thanks for the patch. > > On Wed 11 July 2012 10:55:03 Javier Martin wrote: >> Some video decoders such as tvp5150 provide separate >> video fields (V4L2_FIELD_SEQ_TB). This driver uses >> dmaengine to convert this format to V4L2_FIELD_INTERLACED_TB >> (weaving) or V4L2_FIELD_NONE (line doubling) > > Which field is used for the line doubling? Top or bottom? Or is each field > doubled, thus doubling the framerate? No, just top field is used. I don't know if it's worth defining a new field format for doubling fields. > I also recommend adding SEQ_BT/INTERLACED_BT support: NTSC transmits the > bottom > field first, so it is useful to have support for that. Adding that is quite easy but I cannot test it. Maybe someone could add it later? -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pctv452e
On 07/11/2012 09:25 AM, Marx wrote: On 11.07.2012 01:13, Antti Palosaari wrote: All these tests shows your device is running as it should. There are errors in almost every case, they are absent in your example. Is it ok? You mean these: [mpeg2video @ 0x8d47940] mpeg_decode_postinit() failure [mp3 @ 0x8d4a5c0] Header missing [mpegts @ 0x9f1e900] max_analyze_duration reached [mpegts @ 0x9f1e900] Estimating duration from bitrate, this may be inaccurate [mpegts @ 0x9cc7900] PES packet size mismatch Those are OK. It is live video stream and thus having no header to tell info about stream content. ffmpeg is forced to read raw stream and guess used codes where may happen sometimes few problems. If you see correct picture when opening that stream in video player it is correct. It is likely happen if ffmpeg can detect it. Test VDR again to see if it breaks. VDR unfortunatelly doesn't work saying "frontend 0/0 timed out while tuning to channel 21, tp 26" and "ERROR: streamdev: protocol violation (VTP) from 127.0.0.1:38551". In fact I cannot play any stream directly via VDR, but it can be caused by some incompatibility between VDR and the newest kernel. VDR reads EPG properly so there is something wrong with it. But it's probem not for this list. Add more tuning delay to VDR. Today test works like yesterday. I will wait and test again later. 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] media: Add mem2mem deinterlacing driver.
Hi Javier!
Thanks for the patch.
On Wed 11 July 2012 10:55:03 Javier Martin wrote:
> Some video decoders such as tvp5150 provide separate
> video fields (V4L2_FIELD_SEQ_TB). This driver uses
> dmaengine to convert this format to V4L2_FIELD_INTERLACED_TB
> (weaving) or V4L2_FIELD_NONE (line doubling)
Which field is used for the line doubling? Top or bottom? Or is each field
doubled, thus doubling the framerate?
I also recommend adding SEQ_BT/INTERLACED_BT support: NTSC transmits the bottom
field first, so it is useful to have support for that.
Regards,
Hans
> so that the
> image can be displayed or processed.
>
> Of course there will be combing effect in the image but this
> can be accepted for some low quality applications.
>
> Currently YUV420 and YUYV formats are supported but
> can be extended later.
> ---
> drivers/media/video/Kconfig |8 +
> drivers/media/video/Makefile |2 +
> drivers/media/video/m2m-deinterlace.c | 1077
> +
> 3 files changed, 1087 insertions(+)
> create mode 100644 drivers/media/video/m2m-deinterlace.c
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 9cebf7b..c0b9233 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -1188,6 +1188,14 @@ config VIDEO_CODA
> Coda is a range of video codec IPs that supports
> H.264, MPEG-4, and other video formats.
>
> +config VIDEO_MEM2MEM_DEINTERLACE
> + tristate "Deinterlace support"
> + depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
> + select VIDEOBUF2_DMA_CONTIG
> + select V4L2_MEM2MEM_DEV
> + help
> + Generic deinterlacing V4L2 driver.
> +
> config VIDEO_SAMSUNG_S5P_G2D
> tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
> depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index a04c307..b6a01b1 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -189,6 +189,8 @@ obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
> obj-$(CONFIG_VIDEO_MX2_EMMAPRP) += mx2_emmaprp.o
> obj-$(CONFIG_VIDEO_CODA) += coda.o
>
> +obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o
> +
> obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
> obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
> obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) += s5p-mfc/
> diff --git a/drivers/media/video/m2m-deinterlace.c
> b/drivers/media/video/m2m-deinterlace.c
> new file mode 100644
> index 000..9642efd
> --- /dev/null
> +++ b/drivers/media/video/m2m-deinterlace.c
> @@ -0,0 +1,1077 @@
> +/*
> + * V4L2 deinterlacing support.
> + *
> + * Copyright (c) 2012 Vista Silicon S.L.
> + * Javier Martin
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define MEM2MEM_TEST_MODULE_NAME "mem2mem-deinterlace"
> +
> +MODULE_DESCRIPTION("mem2mem device which supports deinterlacing using
> dmaengine");
> +MODULE_AUTHOR("Javier Martin +MODULE_LICENSE("GPL");
> +MODULE_VERSION("0.0.1");
> +
> +static bool debug = true;
> +module_param(debug, bool, 0644);
> +
> +/* Flags that indicate a format can be used for capture/output */
> +#define MEM2MEM_CAPTURE (1 << 0)
> +#define MEM2MEM_OUTPUT (1 << 1)
> +
> +#define MEM2MEM_NAME "m2m-deinterlace"
> +
> +#define dprintk(dev, fmt, arg...) \
> + v4l2_dbg(1, debug, &dev->v4l2_dev, "%s: " fmt, __func__, ## arg)
> +
> +struct deinterlace_fmt {
> + char*name;
> + u32 fourcc;
> + enum v4l2_field field;
> + /* Types the format can be used for */
> + u32 types;
> +};
> +
> +static struct deinterlace_fmt formats[] = {
> + {
> + .name = "YUV 4:2:0 Planar (weaving)",
> + .fourcc = V4L2_PIX_FMT_YUV420,
> + .field = V4L2_FIELD_INTERLACED_TB,
> + .types = MEM2MEM_CAPTURE,
> + },
> + {
> + .name = "YUV 4:2:0 Planar (line doubling)",
> + .fourcc = V4L2_PIX_FMT_YUV420,
> + /* Line doubling, top field */
> + .field = V4L2_FIELD_NONE,
> + .types = MEM2MEM_CAPTURE,
> + },
> + {
> + .name = "YUYV 4:2:2 (weaving)",
> + .fourcc = V4L2_PIX_FMT_YUYV,
> + .field = V4L2_FIELD_INTERLACED_TB,
> + .types = MEM2MEM_CAPTURE,
> + },
> + {
> + .name = "YUYV 4:2:2 (line doubling)",
> + .fourcc = V4L2_PIX_FMT_YUYV,
> + /* Line doubling, top field */
> + .field
Re: [PATCH v2 2/3] media: coda: Add driver for Coda video codec.
Hi Philippe, Sascha, could you ack this patch please? Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] i.MX27: Visstrim_M10: Add support for deinterlacing driver.
Visstrim_M10 have a tvp5150 whose video output must be deinterlaced.
The new mem2mem deinterlacing driver is very useful for that purpose.
---
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 214e4ff..1566126 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -192,8 +192,8 @@ static struct soc_camera_link iclink_tvp5150 = {
.bus_id = 0,
.board_info = &visstrim_i2c_camera,
.i2c_adapter_id = 0,
- .power = visstrim_camera_power,
- .reset = visstrim_camera_reset,
+// .power = visstrim_camera_power,
+// .reset = visstrim_camera_reset,
};
static struct mx2_camera_platform_data visstrim_camera = {
@@ -232,7 +232,7 @@ static void __init visstrim_camera_init(void)
static void __init visstrim_reserve(void)
{
/* reserve 4 MiB for mx2-camera */
- mx2_camera_base = arm_memblock_steal(2 * MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base = arm_memblock_steal(3 * MX2_CAMERA_BUF_SIZE,
MX2_CAMERA_BUF_SIZE);
}
@@ -419,6 +419,30 @@ static void __init visstrim_coda_init(void)
return;
}
+/* DMA deinterlace */
+static struct platform_device visstrim_deinterlace = {
+ .name = "m2m-deinterlace",
+ .id = 0,
+};
+
+static void __init visstrim_deinterlace_init(void)
+{
+ int ret = -ENOMEM;
+ struct platform_device *pdev = &visstrim_deinterlace;
+ int dma;
+
+ ret = platform_device_register(pdev);
+
+ dma = dma_declare_coherent_memory(&pdev->dev,
+ mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE,
+ DMA_MEMORY_MAP |
DMA_MEMORY_EXCLUSIVE);
+ if (!(dma & DMA_MEMORY_MAP))
+ return;
+}
+
+
static void __init visstrim_m10_revision(void)
{
int exp_version = 0;
@@ -481,6 +505,7 @@ static void __init visstrim_m10_board_init(void)
platform_device_register_resndata(NULL, "soc-camera-pdrv", 0, NULL, 0,
&iclink_tvp5150, sizeof(iclink_tvp5150));
gpio_led_register_device(0, &visstrim_m10_led_data);
+ visstrim_deinterlace_init();
visstrim_camera_init();
visstrim_coda_init();
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] media: Add mem2mem deinterlacing driver.
Some video decoders such as tvp5150 provide separate
video fields (V4L2_FIELD_SEQ_TB). This driver uses
dmaengine to convert this format to V4L2_FIELD_INTERLACED_TB
(weaving) or V4L2_FIELD_NONE (line doubling) so that the
image can be displayed or processed.
Of course there will be combing effect in the image but this
can be accepted for some low quality applications.
Currently YUV420 and YUYV formats are supported but
can be extended later.
---
drivers/media/video/Kconfig |8 +
drivers/media/video/Makefile |2 +
drivers/media/video/m2m-deinterlace.c | 1077 +
3 files changed, 1087 insertions(+)
create mode 100644 drivers/media/video/m2m-deinterlace.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9cebf7b..c0b9233 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1188,6 +1188,14 @@ config VIDEO_CODA
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
+config VIDEO_MEM2MEM_DEINTERLACE
+ tristate "Deinterlace support"
+ depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
+ select VIDEOBUF2_DMA_CONTIG
+ select V4L2_MEM2MEM_DEV
+ help
+ Generic deinterlacing V4L2 driver.
+
config VIDEO_SAMSUNG_S5P_G2D
tristate "Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver"
depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index a04c307..b6a01b1 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -189,6 +189,8 @@ obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o
obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
+
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
diff --git a/drivers/media/video/m2m-deinterlace.c
b/drivers/media/video/m2m-deinterlace.c
new file mode 100644
index 000..9642efd
--- /dev/null
+++ b/drivers/media/video/m2m-deinterlace.c
@@ -0,0 +1,1077 @@
+/*
+ * V4L2 deinterlacing support.
+ *
+ * Copyright (c) 2012 Vista Silicon S.L.
+ * Javier Martin
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define MEM2MEM_TEST_MODULE_NAME "mem2mem-deinterlace"
+
+MODULE_DESCRIPTION("mem2mem device which supports deinterlacing using
dmaengine");
+MODULE_AUTHOR("Javier Martin v4l2_dev, "%s: " fmt, __func__, ## arg)
+
+struct deinterlace_fmt {
+ char*name;
+ u32 fourcc;
+ enum v4l2_field field;
+ /* Types the format can be used for */
+ u32 types;
+};
+
+static struct deinterlace_fmt formats[] = {
+ {
+ .name = "YUV 4:2:0 Planar (weaving)",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .field = V4L2_FIELD_INTERLACED_TB,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUV 4:2:0 Planar (line doubling)",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ /* Line doubling, top field */
+ .field = V4L2_FIELD_NONE,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUYV 4:2:2 (weaving)",
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .field = V4L2_FIELD_INTERLACED_TB,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUYV 4:2:2 (line doubling)",
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ /* Line doubling, top field */
+ .field = V4L2_FIELD_NONE,
+ .types = MEM2MEM_CAPTURE,
+ },
+ {
+ .name = "YUV 4:2:0 Planar (top-bottom)",
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .field = V4L2_FIELD_SEQ_TB,
+ .types = MEM2MEM_OUTPUT,
+ },
+ {
+ .name = "YUYV 4:2:2 (top-bottom)",
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .field = V4L2_FIELD_SEQ_TB,
+ .types = MEM2MEM_OUTPUT,
+ },
+};
+
+/* Per-queue, driver-specific private data */
+struct deinterlace_q_data {
+ unsigned intwidth;
+ unsigned intheight;
+ unsigned intsizeimage;
+ struct deinterlace_fmt *fmt;
+};
+
+enum {
+ V4L2_M2M_SRC = 0,
+ V4L2_M2M_DST = 1,
+};
+
+enum {
+ YUV420_DMA_Y_ODD,
+ YUV420_DMA_Y_EVEN,
+ YUV420_DMA_U_ODD,
+ YUV420_DMA_U_EVEN,
+
[PATCH 0/2] Add video deinterlacing support.
[PATCH 1/2] media: Add mem2mem deinterlacing driver. [PATCH 2/2] i.MX27: Visstrim_M10: Add support for deinterlacing -- 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: video: USB webcam fails since kernel 3.2
On Wed, 11 Jul 2012 10:02:27 +0300 Martin-Éric Racine wrote: [snip] > > wget http://moinejf.free.fr/gspca-2.15.18.tar.gz > > tar -zxf gspca-2.15.18.tar.gz > > cd gspca-2.15.18 > > make > > $ LC_ALL=C make > make -C /lib/modules/3.5.0-rc6+/build > M=/home/perkelix/gspca-2.15.18/build modules > make: *** /lib/modules/3.5.0-rc6+/build: No such file or directory. Stop. > make: *** [modules] Error 2 You need the linux headers of your running kernel to compile the tarball. [snip] > I don't recall Skype having required this in a long time. As I already > said, until recently, the camera "just worked". Good news! [snip] > > echo 0x1f > /sys/module/gspca_main/parameters/debug > > > > then, unplug/replug the webcam, > > No can do; this is an internal webcam. No problem. As I want to know the sensor type, instead of cutting the kernel messages starting from the webcam probe, please, filter them by something like: dmesg | fgrep gspca > gspca.txt Thanks. -- 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 v5] media: mx2_camera: Fix mbus format handling
Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags
so that the driver can negotiate with the attached sensor
whether the mbus format needs convertion from UYUV to YUYV
or not.
---
drivers/media/video/mx2_camera.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 11a9353..0f01e7b 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -118,6 +118,8 @@
#define CSISR_ECC_INT (1 << 1)
#define CSISR_DRDY (1 << 0)
+#define CSICR1_FMT_MASK (CSICR1_PACK_DIR | CSICR1_SWAP16_EN)
+
#define CSICR1 0x00
#define CSICR2 0x04
#define CSISR (cpu_is_mx27() ? 0x08 : 0x18)
@@ -230,6 +232,7 @@ struct mx2_prp_cfg {
u32 src_pixel;
u32 ch1_pixel;
u32 irq_flags;
+ u32 csicr1;
};
/* prp resizing parameters */
@@ -330,6 +333,7 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
.ch1_pixel = 0x2ca00565, /* RGB565 */
.irq_flags = PRP_INTR_RDERR | PRP_INTR_CH1WERR |
PRP_INTR_CH1FC | PRP_INTR_LBOVF,
+ .csicr1 = 0,
}
},
{
@@ -343,6 +347,21 @@ static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
.irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
PRP_INTR_CH2FC | PRP_INTR_LBOVF |
PRP_INTR_CH2OVF,
+ .csicr1 = CSICR1_PACK_DIR,
+ }
+ },
+ {
+ .in_fmt = V4L2_MBUS_FMT_UYVY8_2X8,
+ .out_fmt= V4L2_PIX_FMT_YUV420,
+ .cfg= {
+ .channel= 2,
+ .in_fmt = PRP_CNTL_DATA_IN_YUV422,
+ .out_fmt= PRP_CNTL_CH2_OUT_YUV420,
+ .src_pixel = 0x22000888, /* YUV422 (YUYV) */
+ .irq_flags = PRP_INTR_RDERR | PRP_INTR_CH2WERR |
+ PRP_INTR_CH2FC | PRP_INTR_LBOVF |
+ PRP_INTR_CH2OVF,
+ .csicr1 = CSICR1_SWAP16_EN,
}
},
};
@@ -1018,14 +1037,14 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
return ret;
}
+ csicr1 = (csicr1 & ~CSICR1_FMT_MASK) | pcdev->emma_prp->cfg.csicr1;
+
if (common_flags & V4L2_MBUS_PCLK_SAMPLE_RISING)
csicr1 |= CSICR1_REDGE;
if (common_flags & V4L2_MBUS_VSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_SOF_POL;
if (common_flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
csicr1 |= CSICR1_HSYNC_POL;
- if (pcdev->platform_flags & MX2_CAMERA_SWAP16)
- csicr1 |= CSICR1_SWAP16_EN;
if (pcdev->platform_flags & MX2_CAMERA_EXT_VSYNC)
csicr1 |= CSICR1_EXT_VSYNC;
if (pcdev->platform_flags & MX2_CAMERA_CCIR)
@@ -1036,8 +1055,6 @@ static int mx2_camera_set_bus_param(struct
soc_camera_device *icd)
csicr1 |= CSICR1_GCLK_MODE;
if (pcdev->platform_flags & MX2_CAMERA_INV_DATA)
csicr1 |= CSICR1_INV_DATA;
- if (pcdev->platform_flags & MX2_CAMERA_PACK_DIR_MSB)
- csicr1 |= CSICR1_PACK_DIR;
pcdev->csicr1 = csicr1;
@@ -1112,7 +1129,8 @@ static int mx2_camera_get_formats(struct
soc_camera_device *icd,
return 0;
}
- if (code == V4L2_MBUS_FMT_YUYV8_2X8) {
+ if (code == V4L2_MBUS_FMT_YUYV8_2X8 ||
+ code == V4L2_MBUS_FMT_UYVY8_2X8) {
formats++;
if (xlate) {
/*
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: mx2_camera: Don't modify non volatile parameters in try_fmt.
---
drivers/media/video/mx2_camera.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index d5355de..eda98fc 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1370,6 +1370,7 @@ static int mx2_camera_try_fmt(struct soc_camera_device
*icd,
__u32 pixfmt = pix->pixelformat;
struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
struct mx2_camera_dev *pcdev = ici->priv;
+ struct mx2_fmt_cfg *emma_prp;
unsigned int width_limit;
int ret;
@@ -1432,12 +1433,12 @@ static int mx2_camera_try_fmt(struct soc_camera_device
*icd,
__func__, pcdev->s_width, pcdev->s_height);
/* If the sensor does not support image size try PrP resizing */
- pcdev->emma_prp = mx27_emma_prp_get_format(xlate->code,
+ emma_prp = mx27_emma_prp_get_format(xlate->code,
xlate->host_fmt->fourcc);
memset(pcdev->resizing, 0, sizeof(pcdev->resizing));
if ((mf.width != pix->width || mf.height != pix->height) &&
- pcdev->emma_prp->cfg.in_fmt == PRP_CNTL_DATA_IN_YUV422) {
+ emma_prp->cfg.in_fmt == PRP_CNTL_DATA_IN_YUV422) {
if (mx2_emmaprp_resize(pcdev, &mf, pix, false) < 0)
dev_dbg(icd->parent, "%s: can't resize\n", __func__);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pctv452e
On 11.07.2012 01:13, Antti Palosaari wrote: All these tests shows your device is running as it should. There are errors in almost every case, they are absent in your example. Is it ok? Test VDR again to see if it breaks. VDR unfortunatelly doesn't work saying "frontend 0/0 timed out while tuning to channel 21, tp 26" and "ERROR: streamdev: protocol violation (VTP) from 127.0.0.1:38551". In fact I cannot play any stream directly via VDR, but it can be caused by some incompatibility between VDR and the newest kernel. VDR reads EPG properly so there is something wrong with it. But it's probem not for this list. Today test works like yesterday. I will wait and test again later. Marx -- 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: video: USB webcam fails since kernel 3.2
2012/7/10 Jean-Francois Moine : > So, it would be interesting to know if the (almost) last driver works. > Then, you may try the gspca-2.15.18.tar.gz from my web site: > > wget http://moinejf.free.fr/gspca-2.15.18.tar.gz > tar -zxf gspca-2.15.18.tar.gz > cd gspca-2.15.18 > make $ LC_ALL=C make make -C /lib/modules/3.5.0-rc6+/build M=/home/perkelix/gspca-2.15.18/build modules make: *** /lib/modules/3.5.0-rc6+/build: No such file or directory. Stop. make: *** [modules] Error 2 > su > make install > reboot > > You may then try cheese. For skype, don't forget to force the > use of the v4l library: > > export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so > skype I don't recall Skype having required this in a long time. As I already said, until recently, the camera "just worked". > If the problem is still there, I'd be glad to get some traces. > For that, as root, do: > > echo 0x1f > /sys/module/gspca_main/parameters/debug > > then, unplug/replug the webcam, No can do; this is an internal webcam. Martin-Éric -- 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
